Subject: [BEHAVE] TR: I-D Action:draft-boucadair-port-range-00.txt

From: <[email-masked]>
Date: Fri, 24 Oct 2008 15:16:30 +0200

Hi all,

I would like to draw your attention on the following draft.

We (the authors) are looking forward to reading your comments.

Regards

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 23 octobre 2008 14:45
À : [email-masked]
Objet : I-D Action:draft-boucadair-port-range-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Provider-Provisioned CPE: IPv4 Connectivity Access in the context of IPv4 address exhaustion
	Author(s)       : M. Boucadair, et al.
	Filename        : draft-boucadair-port-range-00.txt
	Pages           : 33
	Date            : 2008-10-23

This memo proposes a solution, based on fractional addresses, to face the IPv4 public address exhaustion.  It details the solution and presents a mock-up implementation, with the results of tests that validate the concept.  Finally, it makes a comparison with the alternative Carrier-Grade NAT (CG-NAT) solutions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-boucadair-port-range-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 24 Oct 2008 16:44:22 +0300

Hello,

On Friday 24 October 2008 16:16:30 ext [email-masked], you 
> We (the authors) are looking forward to reading your comments.

Section 5.4 is a bit unclear to me. It seems like you are referring to the 
inability of CG-NATs (or any nested NAT scenario for that matter) to handle 
UPnP IGD, NAT-PMP and/or manual port forwarding. That's true, and that is a 
problem for certain applications.

However, this seems to assume that all P2P applications rely on this. As far 
as I know, there are a bunch of P2P applications using "bilateral" NAT 
traversal, for instance VoIP clients or Teredo-based P2P file sharing apps.

More importantly, some questions (sorry if I missed the explanation in the 
document) as to how PRR works in the following cases:
* a contemporary CPE is attached to a PRR, that does not implement the DHCP or 
PPP PRR extension?
* a plain IPv4 host is attached directly to a PRR (no CPE at all)?
* shared-medium (non point-to-point) access networks, such as DOCSIS, which 
uses ARP if I'm not mistaken?

Regards,

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: <[email-masked]>
Date: Fri, 24 Oct 2008 16:50:28 +0300

Hi Pierre & all,

Please note that we have recently updated the "Dynamic Host Configuration Protocol (DHCP) Options for Port Restricted IP Address Assignment" to contain use cases and also e.g. considerations on relation to DS-Lite.

http://www.ietf.org/internet-drafts/draft-bajko-v6ops-port-restricted-ipaddr-assign-01.txt

(I will comment your draft next week when I have had time to properly read it trough).

Best regards,

	Teemu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext [email-masked]
>Sent: 24 October, 2008 16:17
>To: [email-masked]
>Subject: [BEHAVE] TR: I-D Action:draft-boucadair-port-range-00.txt
>
>Hi all,
>
>De : [email-masked] 
>[mailto:[email-masked]] De la part de 
>[email-masked] Envoyé : jeudi 23 octobre 2008 14:45 
>À : [email-masked] Objet : I-D 
>Action:draft-boucadair-port-range-00.txt 
>
>	Title           : Provider-Provisioned CPE: IPv4 
>Connectivity Access in the context of IPv4 address exhaustion
>This memo proposes a solution, based on fractional addresses, 
>to face the IPv4 public address exhaustion.  It details the 
>solution and presents a mock-up implementation, with the 
>results of tests that validate the concept.  Finally, it makes 
>a comparison with the alternative Carrier-Grade NAT (CG-NAT) solutions.
>
>Below is the data which will enable a MIME compliant mail 
>reader implementation to automatically retrieve the ASCII 
>version of the Internet-Draft.
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 24 Oct 2008 10:13:17 -0700

> We (the authors) are looking forward to reading your comments.

This seems to be the core of the idea:

   3.2.  Basic Principles

   The major idea is to assign the same IP address to several end-
   users' devices (e.g.  Home Gateways (HGW) embedding NAT) and to
   constraint the (source) port numbers to be used by each HGW.  In
   addition to the assigned IP address to access IP connectivity
   services, an additional parameter, called Port Mask, is also assigned
   to the customer's device.  This mask indicates which Port Range is to
   be used by the customers' devices.

If that is the core of the idea, the idea seems similar to both Remi Despres's
draft-despres-sam-00.txt and to "A Better Approach than Carrier Grade NAT"
<https://mice.cs.columbia.edu/getTechreport.php?techreportID=560> (which I
understand is being converted into an I-D).

Can you compare your proposal with SAM?  And with the
Maennel/Bush/Cittadini/Bellovin proposal?

I have noticed two deficiencies with pre-allocating a set of ports to a
subscriber:  some techniques suffer from an inability to randomize ports
(reference draft-ietf-tsvwg-port-randomization), and also prevent the user
from utilizing more ports even if more ports are available (in the middle of
the night, for example) -- much as that same user could use more bandwidth
when other users are not using bandwidth.  Can you comment on these two issues
as they relate to your proposal?

-d

---

From: <[email-masked]>
Date: Mon, 27 Oct 2008 08:29:24 +0100

Thank you Rémi for your questions, please find my answers in the text (>>PL):

-----Message d'origine-----
De : Rémi Denis-Courmont [mailto:[email-masked]] 
Envoyé : vendredi 24 octobre 2008 15:44
À : [email-masked]; VILLEFRANQUE Alain RD-CORE-CAE
Cc : LEVIS Pierre RD-CORE-CAE; BOUCADAIR Mohamed RD-CORE-CAE; [email-masked]
Objet : Re: [BEHAVE] TR: I-D Action:draft-boucadair-port-range-00.txt

	Hello,

> We (the authors) are looking forward to reading your comments.

Section 5.4 is a bit unclear to me. It seems like you are referring to the inability of CG-NATs (or any nested NAT scenario for that matter) to handle UPnP IGD, NAT-PMP and/or manual port forwarding. That's true, and that is a problem for certain applications.

However, this seems to assume that all P2P applications rely on this. As far as I know, there are a bunch of P2P applications using "bilateral" NAT traversal, for instance VoIP clients or Teredo-based P2P file sharing apps.
>>PL: You're right, we'll make it clearer

More importantly, some questions (sorry if I missed the explanation in the
document) as to how PRR works in the following cases:
* a contemporary CPE is attached to a PRR, that does not implement the DHCP or PPP PRR extension?
>>PL: Then it cannot use the PRR system, however it is not impacted by the presence of the PRR. Your question raises the important issue of who is going to have a shared address and who is going to have a unique public address. I guess the answer will depend on the ISP, its level of address shortage, and its policy.

>>PL: this case it not described in the draft, but the mechanism could easily be applied directly to terminals (it surely makes sense for mobile phones)

* shared-medium (non point-to-point) access networks, such as DOCSIS, which uses ARP if I'm not mistaken?
>>PL: The solution is compatible with shared-medium as Ethernet; this point is treated in the draft (description of the mock-up in § 4.3)with the use of a private address:
"The PRR proceeds to an ARP (Address Resolution Protocol) resolution (if not already achieved previously) and matches the [private addr EXT CPE-x] with the MAC (Media Access Control) address of EXT CPE x;"

Regards,

>>PL:
Regards,

Pierre

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Oct 2008 08:56:11 +0100

Dan,

IPv4 address extension based on port ranges is not only common to :

- My "Stateless Address mapping" (SAM)

- Randy Bush's "A+P",

- Mohamed Boucadair's "Port Provided CPEs" (which contains useful first
hand experience,  acquired with real tests)

But also to:

- Gabor Bajko & Teemu Savolainen's "Port-restricted IPv4 address
assignment".

- IVI where it is, in my understanding of the "port multiplexing"
section, a possible extension.

I find this very encouraging.

I hope that meeting in Minneapolis will help clarifying common grounds
and possible convergence.

If not in Behave, or in any scheduled meeting, I would like to propose,
when we are there,
a place and a time for an informal meeting, like the one we had in
Dublin after the APBP presentation.

Anyone interested in participating to this convergence work is welcome
to be
identified.

Regards,

RD

Dan Wing   (m/j/a) 10/24/08 7:13 PM:

3.2. Basic Principles

-d

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Oct 2008 09:39:25 +0100

Hi Pierre,

I find the draft most interesting, in particular the real experiment it
describes .

In sec 4.4  it says :"For one P2P (Peer-to-Peer) application tested, we
found that two  peers each behind a CPE sharing the same public address
cannot  download a SAME file from a source peer."

- Is there a problem in telling  which application this is?

- Do we know if this application works (for the same file) across NATs,
and if yes how?

Regards,

RD

[email-masked]   (m/j/a) 10/24/08 3:16 PM:

Hi all,

Regards

Pierre

---

From: <[email-masked]>
Date: Mon, 27 Oct 2008 14:23:06 +0100

Hi Dan,

Please find my answers in the text (>>PL): 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 24 octobre 2008 19:13
À : LEVIS Pierre RD-CORE-CAE; [email-masked]
Objet : RE: [BEHAVE] TR: I-D Action:draft-boucadair-port-range-00.txt

   3.2.  Basic Principles

If that is the core of the idea, the idea seems similar to both Remi Despres's draft-despres-sam-00.txt and to "A Better Approach than Carrier Grade NAT"
<https://mice.cs.columbia.edu/getTechreport.php?techreportID=560> (which I understand is being converted into an I-D).

Can you compare your proposal with SAM?  And with the Maennel/Bush/Cittadini/Bellovin proposal?

>>PL: As Rémi Després pointed out this proposal is one among several proposals that are all based on the idea of allocating a restricted set of ports. In this context, this draft is an effort to address the recommendation in <draft-arkko-townsley-coexistence-00> to develop new guidelines and specifications for some already known solutions.
What we more specifically bring is:
-Show the involvement of an ISP
-Present an early implementation
-Extend the notion of port range to non-contiguous values with the use of port range mask
-Propose a mechanism where the port allocation is handled by a DHCP proxy in order to let the already existing DHCP servers unaware

I have noticed two deficiencies with pre-allocating a set of ports to a
subscriber:  some techniques suffer from an inability to randomize ports (reference draft-ietf-tsvwg-port-randomization), and also prevent the user from utilizing more ports even if more ports are available (in the middle of the night, for example) -- much as that same user could use more bandwidth when other users are not using bandwidth.  Can you comment on these two issues as they relate to your proposal?

>>PL: Right, the idea of pre-allocating a set of ports seems contrary to the idea of randomizing the port choice. Intuitively, the smaller the port range is, the more predictable the port choice is. But this needs to be quantified.
 
As for the efficiency of port range allocation vs pure dynamic port allocation, this can be mitigated by:
-A more elaborated and dynamic way to split the port space is possible but this would bring much (too much?) complexity.
-A key parameter is the factor by which you want to multiply your address space. Maybe this factor is only some units (less than 10). The purpose of this kind of mechanism (port range, CG-NAT, or whatever) is "only" (I know this is not straightforward!) to survive until IPv6 is deployed enough that the use of IPv4 public addresses begins to decrease. Then the breadth (several thousands) of the port space can be sufficient to accommodate to almost any use cases (x8; ~8000 ports available).

Pierre
 
-d

---

From: <[email-masked]>
Date: Mon, 27 Oct 2008 15:14:20 +0100

Hi Rémi,
 
Thank you for your careful reading.
 
This is one of the most commonly used p2p application!
More seriously, we're bound to have the same issue as soon as we do address sharing, no matter the mechanism. So, I would say that it should not work accross a Carrier Grade NAT.

Regards,

Pierre

________________________________

De : Rémi Després [mailto:[email-masked]] 
Envoyé : lundi 27 octobre 2008 09:39
À : LEVIS Pierre RD-CORE-CAE
Cc : [email-masked]
Objet : Re: [BEHAVE] TR: I-D Action:draft-boucadair-port-range-00.txt

Hi Pierre,

I find the draft most interesting, in particular the real experiment it describes .

In sec 4.4  it says :"For one P2P (Peer-to-Peer) application tested, we found that two  peers each behind a CPE sharing the same public address cannot  download a SAME file from a source peer."
- Is there a problem in telling  which application this is?
- Do we know if this application works (for the same file) across NATs, and if yes how?

Regards,

RD

	Hi all,

	Regards

	Pierre

	-----Message d'origine-----
	De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
	Envoyé : jeudi 23 octobre 2008 14:45
	À : [email-masked]
	Objet : I-D Action:draft-boucadair-port-range-00.txt 

	

	

________________________________

---

From: Rémi Després <[email-masked]>
Date: Mon, 27 Oct 2008 15:31:00 +0100

[email-masked]   (m/j/a) 10/27/08 3:14 PM:

we're bound to have the same issue as soon as we do
address sharing, no matter the mechanism. So, I would say that it
should not work accross a Carrier Grade NAT.

And not more across "CPE" NATs that have only one IPv4 address to
share, right?

(This one instance where working in IPv6, if possible, is cleaner,
simpler, safer....)

RD

---

From: <[email-masked]>
Date: Mon, 27 Oct 2008 15:40:25 +0100

Right!

De : [email-masked] [mailto:[email-masked]] De la part de Rémi Després
Envoyé : lundi 27 octobre 2008 15:31
À : LEVIS Pierre RD-CORE-CAE
Cc : [email-masked]
Objet : Re: [BEHAVE] TR: I-D Action:draft-boucadair-port-range-00.txt

	 we're bound to have the same issue as soon as we do address sharing, no matter the mechanism. So, I would say that it should not work accross a Carrier Grade NAT.

And not more across "CPE" NATs that have only one IPv4 address to share, right?
(This one instance where working in IPv6, if possible, is cleaner, simpler, safer....)
RD

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 27 Oct 2008 11:38:13 -0700

I will go out on a limb, for the benefit of anyone reading these
archives in 5 years, that the application must be BitTorrent.

Assuming that is correct, the probably reason BitTorrent prevents simultaneous
downloading by two hosts with the same identifier (IP address) is to provide
fairer bandwidth sharing.  Without such protection, you could get 2x download
speed for a file if a person's two BitTorrent clients happened to download
from completely different peers.

-d

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Monday, October 27, 2008 7:14 AM
> To: [email-masked]
> Subject: Re: [BEHAVE] TR: I-D Action:draft-boucadair-port-range-00.txt
> 
> Hi Rémi,
>  
> More seriously, we're bound to have the same issue as soon as 
> we do address sharing, no matter the mechanism. So, I would 
> say that it should not work accross a Carrier Grade NAT.
>  
>  
> Regards,
>  
>  
> Pierre
> 
> In sec 4.4  it says :"For one P2P (Peer-to-Peer) application 
> tested, we found that two  peers each behind a CPE sharing 
> the same public address cannot  download a SAME file from a 
> source peer."
> 		Title           : Provider-Provisioned CPE: 
> IPv4 Connectivity Access in the context of IPv4 address exhaustion
> 	This memo proposes a solution, based on fractional 
> addresses, to face the IPv4 public address exhaustion.  It 
> details the solution and presents a mock-up implementation, 
> with the results of tests that validate the concept.  
> Finally, it makes a comparison with the alternative 
> Carrier-Grade NAT (CG-NAT) solutions.
> 	
> 	Below is the data which will enable a MIME compliant 
> mail reader implementation to automatically retrieve the 
> ASCII version of the Internet-Draft.
> 	  
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Oct 2008 11:55:50 -0700

Pierre,

I decided to test how BitTorrent works with two clients behind the same IP
address.  My results show that it works fine.  I tested by running both
uTorrent and Vuze (formerly called Azureus) on the same Windows PC, with one
IPv4 address towards the Internet (my trusty Linksys WRT54G running Tomato 3rd
party firmware).

For my torrent download, I used 2.9Gb copy of Wikipedia was recently made
available,
http://www.soschildrensvillages.org.uk/charity-news/2008-wikipedia-for-schools
.htm#download

Can you provide details on the test you performed that showed "one of the most
commonly used p2p applications" did not work at all when two hosts shared the
same IP address?  I am now suspicious it was the tracker causing the
restriction you observed, and not the BitTorrent protocol itself.

-d

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Monday, October 27, 2008 11:38 AM
> To: [email-masked]'; [email-masked]'
> Subject: RE: [BEHAVE] TR: I-D Action:draft-boucadair-port-range-00.txt
> 
> Assuming that is correct, the probably reason BitTorrent 
> prevents simultaneous downloading by two hosts with the same 
> identifier (IP address) is to provide fairer bandwidth 
> sharing.  Without such protection, you could get 2x download 
> speed for a file if a person's two BitTorrent clients 
> happened to download from completely different peers.
> 
> -d
> 
>

---

From: <[email-masked]>
Date: Wed, 29 Oct 2008 15:52:26 +0100

Dan,

Yes, the test you carried out work also in our lab (I have tested the same torrent download as yours on two different PCs sharing the same IP address).

In fact, the result we have mentionned in our draft is from another test which is much more constrained:

"For one P2P (Peer-to-Peer) application tested, we found that two
   peers each behind a CPE sharing the same public address cannot
   download a SAME file from a source peer."

By "SAME file from a source peer" we mean a single file on a single location.
Then, the two PCs with the same IP address tried to download the file from the very same location, by BitTorrent.

So, of course we cannot say that it does not work at all, we can only say that it does not work in these very particular conditions.

Pierre

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 28 octobre 2008 19:56
À : LEVIS Pierre RD-CORE-CAE
Cc : [email-masked]
Objet : BitTorrent with shared IP addresses [was RE: [BEHAVE] TR: I-D Action:draft-boucadair-port-range-00.txt]

Pierre,

I decided to test how BitTorrent works with two clients behind the same IP address.  My results show that it works fine.  I tested by running both uTorrent and Vuze (formerly called Azureus) on the same Windows PC, with one
IPv4 address towards the Internet (my trusty Linksys WRT54G running Tomato 3rd party firmware).

For my torrent download, I used 2.9Gb copy of Wikipedia was recently made available, http://www.soschildrensvillages.org.uk/charity-news/2008-wikipedia-for-schools
.htm#download

Can you provide details on the test you performed that showed "one of the most commonly used p2p applications" did not work at all when two hosts shared the same IP address?  I am now suspicious it was the tracker causing the restriction you observed, and not the BitTorrent protocol itself.

-d

> Assuming that is correct, the probably reason BitTorrent prevents 
> simultaneous downloading by two hosts with the same identifier (IP 
> address) is to provide fairer bandwidth sharing.  Without such 
> protection, you could get 2x download speed for a file if a person's 
> two BitTorrent clients happened to download from completely different 
> peers.
> 
> -d
> 
> 
> > More seriously, we're bound to have the same issue as soon as we do 
> > De : Rémi Després [mailto:[email-masked]] Envoyé : lundi 27 
> > octobre 2008 09:39 À : LEVIS Pierre RD-CORE-CAE Cc : [email-masked] 
> > In sec 4.4  it says :"For one P2P (Peer-to-Peer) application tested, 
> > we found that two  peers each behind a CPE sharing the same public 
> > address cannot  download a SAME file from a source peer."
> > 	This memo proposes a solution, based on fractional addresses, to 
> > face the IPv4 public address exhaustion.  It details the solution 
> > and presents a mock-up implementation, with the results of tests 
> > that validate the concept.
> > Finally, it makes a comparison with the alternative Carrier-Grade 
> > NAT (CG-NAT) solutions.
> > 	
> > 	Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > 	  
> >

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 29 Oct 2008 11:22:18 -0700

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, October 29, 2008 7:52 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: BitTorrent with shared IP addresses [was RE: 
> [BEHAVE] TR: I-D Action:draft-boucadair-port-range-00.txt]
> 
> Dan,
> 
> Yes, the test you carried out work also in our lab (I have 
> tested the same torrent download as yours on two different 
> PCs sharing the same IP address).
> 
> In fact, the result we have mentionned in our draft is from 
> another test which is much more constrained:
> 
> Then, the two PCs with the same IP address tried to download 
> the file from the very same location, by BitTorrent.
>
> So, of course we cannot say that it does not work at all, we 
> can only say that it does not work in these very particular 
> conditions.

Ah, okay.  So the failure occurs when a file that has only one 
seed in the BitTorrent swarm, like this:

             PC-A--+
                    \
                     NAT--seed
                    /
             PC-B--+

And PC-A is able to download the file, but PC-B can't download
the file.  

What happens after PC-A completes downloading the file --
can PC-B start downloading it immediately after PC-A finishes?  
Perhaps after the next tracker update, can PC-B start downloading 
it?   Or does your testing show that PC-B is *never* able to 
download the file because PC-A already downloaded it from the 
seed?

-d

---

From: <[email-masked]>
Date: Fri, 31 Oct 2008 14:12:20 +0100

The second can download the file when the first has finished and when it has re-launched the bittorent download.
After further investigation I saw in the BitTorrent seed (BitTorrent 6.0.3)in Options/Preferences/Advanced, the parameter:
bt.allow_same_ip
When this parameter is set to false the behavior is as mentioned.
When this parameter is set to true the two PCs sharing the same IP address can simultaneously download the file.

Pierre 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 29 octobre 2008 19:22
À : LEVIS Pierre RD-CORE-CAE
Cc : [email-masked]
Objet : RE: BitTorrent with shared IP addresses

> Yes, the test you carried out work also in our lab (I have tested the 
> same torrent download as yours on two different PCs sharing the same 
> IP address).
> 
> Then, the two PCs with the same IP address tried to download the file 
> from the very same location, by BitTorrent.
>
> So, of course we cannot say that it does not work at all, we can only 
> say that it does not work in these very particular conditions.

Ah, okay.  So the failure occurs when a file that has only one seed in the BitTorrent swarm, like this:

             PC-A--+
                    \
                     NAT--seed
                    /
             PC-B--+

-d

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 31 Oct 2008 15:26:43 +0200

> problem for certain applications.

On a second thought... is it not so that, with UPnP IGD, the application 
chooses the external port number, rather than the device? If so, port range 
based mechanism such as yours, or Rémi Després' will fail as badly as 
CG-NATs.

I would argue this would be an "IGD bug". In fact, it would seem that IGDv2 
would fix it. But I don't think we can rely on IGDv2 soon enough.

---

From: Rémi Després <[email-masked]>
Date: Fri, 31 Oct 2008 15:02:10 +0100

> When this parameter is set to true the two PCs sharing the same IP address can simultaneously download the file.
good news :-) (and good work!).
Cheers,
RD

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 31 Oct 2008 09:56:20 -0700

> Sent: Friday, October 31, 2008 6:12 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: BitTorrent with shared IP addresses
> 
> The second can download the file when the first has finished 
> and when it has re-launched the bittorent download.
> After further investigation I saw in the BitTorrent seed 
> (BitTorrent 6.0.3)in Options/Preferences/Advanced, the parameter:
> bt.allow_same_ip
> When this parameter is set to true the two PCs sharing the 
> same IP address can simultaneously download the file.

Thanks for your investigation on this.  Would you be willing to write
up an I-D describing this application behavior?  I expect we will find
other applications that expect each 'user' has one IP address - which
will no longer be true with IPv4 address sharing.  This affects NAT44 
(CGN), port borrowing, DS-Lite, and IPv6->IPv4 translation.

I touched on this problem a little bit in
http://tools.ietf.org/html/draft-wing-nat-pt-replacement-comparison-02#section
-9.1 but without specifics on BitTorrent, of course.

-d

> tested the 
> Ah, okay.  So the failure occurs when a file that has only 
> one seed in the BitTorrent swarm, like this:
> 
> 
>              PC-A--+
>                     \
>                      NAT--seed
>                     /
>              PC-B--+
> 
>