Subject: [BEHAVE] Question on port preservation

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Nov 2008 23:12:32 -0300

Folks,

I was wondering if there are any specific applications that actually 
need (?) port preservation. If that were the case, I guess one could 
do port preservation for specific port numbers, rather than 
enabling/disabling port preservation globally.

Any thoughts?

Thanks!

Kind regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Nov 2008 19:13:34 -0800

> enabling/disabling port preservation globally.

If you find such an application, I would ask:  what happens when 
two intendances of that application are running (on the same host 
or on two different hosts) behind the same NAT?

-d

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Nov 2008 00:22:19 -0300

>or on two different hosts) behind the same NAT?

I completely agree with you. My point is, precisely, that I cannot 
see what's the big deal of making port randomization a SHOULD. (If it 
breaks an app, I'd argue that the app is already broken (i.e., they 
cannot interoperate with hosts behind the other %50 of NATs that do 
not do port preservation).

Nevertheless, I'd like to know if these apps that need port 
reservation always use some specific source port, or what. If that 
were the case, we could simply preserve only those ports, and that's it.

Thanks!

Kind regards,

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 11 Nov 2008 20:11:54 -0800

Again, read RFC 4787. We discuss this.

We had at some point in the draft process a recommendation to randomize, but
it was taken out because people complained.

(But I agree with you to be honest: I believe random failures are a worst
problem than "it just doesn't work)

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 11 Nov 2008 20:29:13 -0800

Crappy VoIP implementations (pre-SIP) that break if there are more than one
endpoint trying to use the same port from behind the same NAT.

I suspect some games too (which is probably more important).

In other words, it breaks things that don't use a fully-fledge ICE-like
protocol for NAT/FW traversal.

(...don't shoot the messenger: I didn't like that we backed out of this in
RFC 4787).

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 12 Nov 2008 09:40:41 +0200

> enabling/disabling port preservation globally.

As far as I know, UPnP IGD works in such a way that you forward one specific 
port to your own IP address - the internal and external port number is the 
same. And yes, this breaks if you have two nodes using the same applications 
(on the same port) behind the same NAT. That probably was not envisioned back 
then.

I understand many video game protocols assume a fixed port or fixed port 
range. At least my brother asked for a bunch of those when I was managing the 
my parents NAT (without IGD).

But anyway, I don't see it as the NAT job to _increase_ the randomness of port 
numbers. And if the NAT is not in the same "trust domain" as the NAT'ed host 
(CGN), then it's even pointless. (Of course, it should avoid statistically 
decreasing that randomness).

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

---

From: Dave Hudson <[email-masked]>
Date: Wed, 12 Nov 2008 07:49:53 +0000

Fernando Gont wrote:
> I completely agree with you. My point is, precisely, that I cannot see 
> what's the big deal of making port randomization a SHOULD. (If it breaks 
> an app, I'd argue that the app is already broken (i.e., they cannot 
> interoperate with hosts behind the other %50 of NATs that do not do port 
> preservation).

Port preservation is a significant benefit to end users who have no idea 
what TCP or UDP is, let alone what a port is.  There are quite a number 
of apps (particularly older apps and I'm thinking about thinks like IM 
clients and games) that don't use UPnP and which require users to 
manually set port forwarding rules in the absence of port preservation. 
  Nothing breaks by not having it but those apps don't "just work".

> Nevertheless, I'd like to know if these apps that need port reservation 
> always use some specific source port, or what. If that were the case, we 
> could simply preserve only those ports, and that's it.

The apps in question invariably use a specific source port but that port 
is usually defined on an app-specific basis and there are hundreds or 
probably thousands of different apps, each using different ports.  From 
memory I've seen almost completely random ports in the rang 1024 to 64k 
being used by such apps.

Another thing to consider here is that while some SOHO routers don't do 
port preservation by default almost all of them (in fact all of the ones 
I've looked at in the last 5 years) do have a "DMZ host" option.  The 
DMZ host option forwards all packets for which there is no active 
mapping to one particular host and without changing the port mapping. 
Any traffic originating from the DMZ host is forwarded with port 
preservation.  Such DMZ host operations are designed specifically to 
help with the sorts of apps I noted above.

Regards,
Dave

---

From: Dave Hudson <[email-masked]>
Date: Wed, 12 Nov 2008 08:09:49 +0000

> or on two different hosts) behind the same NAT?

The normal problem case is 2 hosts - if the same app can run on the same 
host multiple times then it invariably can't use the same port because 
only one instance of the app can't bind the socket.

In many cases the first host to use the port "wins" but in other cases 
it's possible to set up a different port for the second host so you now 
get 2 unique ports.

For some IM clients I've frequently found this "first host wins" 
scenario, but another common usage is for games where one of the players 
acts as a game server in which case often only host needs the preserved 
port - in those cases on the server needs to win.

It's somewhat hit and miss of course, but in general port preservation 
gives a better experience to current end users, especially with legacy apps.

FWIW within the Ubicom routing stack we made port preservation a runtime 
option - it's enabled by default though.

Regards,
Dave

---

From: Dave Hudson <[email-masked]>
Date: Wed, 12 Nov 2008 08:29:44 +0000

> (on the same port) behind the same NAT. That probably was not envisioned back 

IGD supports establishing a fixed mapping but the private and public 
port numbers can be different.  In practice though I think most clients 
tend to set these to the same value.

> decreasing that randomness).

I can't see how a NAT can avoid decreasing the randomness of some 
private host if the NAT second guesses it and chooses its own idea of a 
random port.  Statistically the NAT may be significantly less random in 
its choice than the host.

Regards,
Dave

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Nov 2008 05:28:39 -0300

At 05:29 a.m. 12/11/2008, Dave Hudson wrote:

>>But anyway, I don't see it as the NAT job to _increase_ the 
>>randomness of port numbers. And if the NAT is not in the same 
>>"trust domain" as the NAT'ed host (CGN), then it's even pointless. 
>>(Of course, it should avoid statistically decreasing that randomness).
>
>private host if the NAT second guesses it and chooses its own idea 
>of a random port.  Statistically the NAT may be significantly less 
>random in its choice than the host.

Consider this scenario:
A host behind a NAT implements port randomization
The NAT overwrites the source port number, and assigns port numbers 
sequentially (traditional BSD port selection algorithm)

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Nov 2008 05:31:58 -0300

>decreasing that randomness).

If the NAT is going to overwrite the source port 
of outgoing packets, it basically has two choices:
a) Assign port numbers incrementally
b) Randomize the source port numbers

If you do "a", chances are that the host behind 
the NAT was doing port randomization, and you are 
"de-randomizing" :-) the source ports.
That's why I think you should do "b", unless you're doing port preservation.

Thanks!

Kind regards,

---

From: Dave Hudson <[email-masked]>
Date: Wed, 12 Nov 2008 09:02:43 +0000

Fernando Gont wrote:
> If the NAT is going to overwrite the source port of outgoing packets, it 
> basically has two choices:
> If you do "a", chances are that the host behind the NAT was doing port 
> randomization, and you are "de-randomizing" :-) the source ports.

But that assumes the NAT is able to choose more-random ports than the 
host was able to do.  We have to assume the host is designed to give as 
much randomness as it deemed necessary but we can't assume the NAT is 
able to meet those same requirements.  I've seen far too many subtly 
broken random number generation solutions in the past :-)

Regards,
Dave

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 12 Nov 2008 11:08:18 +0200

On Wednesday 12 November 2008 10:31:58 ext Fernando Gont, you wrote:
> >numbers. And if the NAT is not in the same "trust domain" as the NAT'ed
> > host (CGN), then it's even pointless. (Of course, it should avoid
> > statistically decreasing that randomness).
>

Yes, and I agree that's bad because it decreases randomness.

> That's why I think you should do "b", unless you're doing port

But you could do:
c) Pick the "next" available external port number from the internal port.

(c) does some efforts at port preservation, and will not or barely decrease 
randomness.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Nov 2008 06:42:06 -0300

>(c) does some efforts at port preservation, and will not or barely decrease

If you are not actually preserving the port, 
what's the reason for not randomizing it? 
(assuming the source port was not in the range 0-1023)

Kind regards,

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 12 Nov 2008 12:05:16 +0200

On Wednesday 12 November 2008 11:42:06 ext Fernando Gont, you wrote:
> >(c) does some efforts at port preservation, and will not or barely
> > decrease randomness.
>

That you are trying to preserve the port but happened to get into a conflict.
That you don't have good seeding for an RNG, or don't want to spoil it.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Nov 2008 08:36:40 -0300

>That you don't have good seeding for an RNG, or don't want to spoil it.

My point is: the only argument against port 
randomization has so far been that port 
preservation allows some applications to work 
that would otherwise not work if the ports are not preserved.

Now, if you try to do port preservation, but find 
that you cannot actually preserve the port, 
what's the point of sticking to non-random port 
numbers that will be neither security-wise nor 
will provide benefits from an interoperability point of view?

FWIW, I'd argue that algorithms #3 and #4 in 
http://www.gont.com.ar/drafts/port-randomization/draft-ietf-tsvwg-port-randomization-02.txt 
may provide benefits not only from a security 
point of view, but also from an interoperability 
point of view (they may help to avoid collisions of connection-ids).

Thanks!

Kind regards,

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Wed, 12 Nov 2008 13:47:36 +0200

On Wednesday 12 November 2008 13:36:40 ext Fernando Gont, you wrote:
> >That you are trying to preserve the port but happened to get into a
> > conflict. That you don't have good seeding for an RNG, or don't want to
> > spoil it.
>

Again, no need for an RNG, or to feed said RNG.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Nov 2008 09:55:30 -0800

> -----Original Message-----
> From: Dave Hudson [mailto:[email-masked]] 
> Sent: Tuesday, November 11, 2008 11:50 PM
> To: Fernando Gont
> Cc: Dan Wing; 'Behave Mailing List'
> Subject: Re: [BEHAVE] Question on port preservation
> 
> Fernando Gont wrote:

Port forwarding (as generally described at http://www.portforward.com
by configuration, and as implemented in a protocol by UPnP IGD
and NAT-PMP) is not the same as port preservation.  

Port preservation refers to how a NAT chooses the port on the public
side for a new connection.  A "port preserving NAT" will use the same
source port on the public side.  A "non-port preserving NAT" would not
use the same source port on the public side.

-d

> reservation

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Nov 2008 11:28:44 -0800

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rémi Denis-Courmont
> Sent: Tuesday, November 11, 2008 11:41 PM
> To: [email-masked]
> (on the same port) behind the same NAT. That probably was not 
> envisioned back then.

The UPnP IGD 1.0 specification can be found by going to
http://www.upnp.org/standardizeddcps/igd.asp.  There you will 
find a 1,446KB zip file.  The interesting file inside is
"UPnP_IGD_WANIPConnection 1.0.pdf", which says the following
(I am highlighting the point you are making with "<<<<"):

 #
 #  2.4.16.AddPortMapping
 #
 # This action creates a new port mapping or overwrites an existing 
 # mapping with the same internal client. If the ExternalPort and 
 # PortMappingProtocol pair is already mapped to another internal 
 # client, an error is returned.
 #
 # NOTE: Not all NAT implementations will support:
 # • Wildcard value (i.e. 0) for ExternalPort
 # • InternalPort values that are different from ExternalPort <<<<<
 # • Dynamic port mappings i.e. with non-Infinite 
 #   PortMappingLeaseDuration
 #

> I understand many video game protocols assume a fixed port or 
> fixed port range. At least my brother asked for a bunch of those 
> when I was managing the my parents NAT (without IGD).

Yep.  Such applications will break unless they learn how to
communicate 48 bits of information (IP address and port) rather
than 32 bits of information (IP address).

> "trust domain" as the NAT'ed host (CGN), then it's even 
> pointless. (Of course, it should avoid statistically 

-d

---

From: Dave Hudson <[email-masked]>
Date: Thu, 13 Nov 2008 09:54:15 +0000

> use the same source port on the public side.

Quite true - in fact though port forwarding is often subtly different to 
what UPnP IGD does though.  IGD allows a different private port to be 
mapped to the public port, whereas port forwarding almost always 
forwards the same port (in practice though IGD clients rarely seem to 
use this port changing capability so they often appear to do the same 
thing).

Normally port forwarding also maps very large numbers of ports (it's not 
uncommon to find forwarding rules for some games that attempt to forward 
10+ ports and forwarding rules that attempt to forward 1000+ ports 
aren't unknown).  Of course these rules tend to be imprecise because the 
host is selecting random ports in a range of possible ports but it's 
almost impossible for the user to manually configure a precise 
forwarding rule under those conditions.

Port preservation does, however, enter into this and make end-users 
lives easier and often avoids the need for a port forwarding rule though:

Consider the case where an app picks one of 10k possible ports to use 
for some purpose and where it advertises which port it selected in some 
protocol transaction (rather like many media and IM protocols).  This 
same app doesn't use UPnP or NAT-PMP (which may not be available 
anyway).  The same app also sends packets using the same port that it 
randomly selected.  Both hosts advertise the port they're using and our 
port preserving NAT preserves the port on behalf of our private host 
when our host sends its first packet.  The NAT now maintains the 
necessary binding to allow for successful hole punching without the need 
for a rendezvous server and thus the user's app "just works" even though 
they didn't create a port forwarding rule or a default forwarding rule 
via a "DMZ host".

As an aside the port preservation behaviour here also eliminates the 
need to forward a huge range of ports via a manually-configured 
forwarding rule and is thus much more friendly to other hosts/apps 
behind the NAT.

Port preservation doesn't replace port forwarding (it does nothing in 
cases where there's not simultaneous open behaviour) but can eliminate 
the need for it in some number of common applications (and is especially 
helpful in SOHO scenarios where users rarely host servers but do use IM, 
VoIP, video chat, P2P file sharing and games).  I would also note that 
port preservation solutions also invariably work better when 
endpoint-independent filtering is being applied too since most port 
forwarding rules aren't restricted to specific public addresses.

Regards,
Dave

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 13 Nov 2008 09:55:10 -0500

> Yes, and I agree that's bad because it decreases randomness.

I agree with you that this decreases randomness...  but why is that  
inherently bad?

I'm not sure I understand exactly what the goal is here, but I'm  
pretty sure that maximizing randomness is not the end goal. :-)

I understand that many hosts choose sequential port numbers for client  
connections, and that this is one of the pieces of information that an  
external attacker can use to correlate a set of connections with a  
single node behind the NAT box.  Is this the problem that you are  
trying to solve?  Or are you trying to make it harder for an external  
attacker to know what applications are being used behind the NAT box,  
by obfuscating whatever default ports they may use?

Ignoring, for the moment, the problems that can be caused for some  
applications, I understand why it would be advantageous for a host to  
choose random port numbers for client connections.  If there is no NAT  
in the path, connections can be correlated to a single host by IP  
address, but port randomization could help to hide what applications  
are running on the host.  If there is a port-preserving NAT in the  
path, randomizing the ports will achieve both goals described above.   
And, if there is a port-obfuscating NAT in the path that overwrites  
the host's random port, the host hasn't lost anything (except a few  
processing cycles per connection).

However, I don't understand why it is better for the _NAT_ to use  
randomly selected port numbers, whether the internal hosts uses random  
port numbers or not.  In either case, all of the traffic from a given  
site can be correlated by IP address. If the NAT randomizes port  
numbers, the traffic will appear to come from a single host that  
randomizes port numbers.  Or, if the NAT chooses sequential port  
numbers, the traffic will appear to come from a single host that uses  
sequential port numbers.  In neither case will an external hosts be  
able to use the original port numbers to determine what applications  
are being used in the network or on a specific host.

Is there another goal here that I'm missing?  Or something that I am  
misunderstanding?

Thanks,
Margaret

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Thu, 13 Nov 2008 17:22:21 +0200

> I agree with you that this decreases randomness...  but why is that

This is a security issue. DNS is an example where this is a widely used 
mitigation against spoofing attacks. Address latching (such as with SIP 
B2BUAs) is also very sensitive to this.

If the NAT destroys the randomness of the source port, then the mitigation 
scheme breaks. This has nothing to do with ease of NAT traversal.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Nov 2008 08:58:28 -0800

> > source port on the public side.  A "non-port preserving 
> > NAT" would not use the same source port on the public side.
> 
> for a rendezvous server and thus the user's app "just works" 
> even though they didn't create a port forwarding rule or a default 
> forwarding rule via a "DMZ host".
> 

This is a very good analysis.  I believe it boils down to a rule
something like:

  if a NAT is configured to forward a port to an internal
  host (using, for example, UPnP IGD, NAT-PMP, or a web
  page configuration), the NAT will forward incoming
  unsolicited traffic to the internal host.  Additionally,
  for traffic originating from the internal host using the
  host's mapped port, NAT MUST perform the same mapping.

  For example, if the NAT is configured to forward traffic
  on TCP/80 to an internal host 192.168.1.1/8080, any
  outgoing traffic from 192.168.1.1/8080 must be mapped
  to port 8080 on the NAT's public interface.

We don't have text like that in any document, but that's
because we don't talk about NATs being configured for
port forwarding.  Perhaps we should?

-d

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Nov 2008 11:29:40 -0600

> problem than "it just doesn't work)

It's not always "random failures" -- for example, bittorrent will work 
okay without port preservation, but work much better (faster finding of 
peers, finding additional peers, better overall throughput) if port 
preservation happens.

So what you have is "randomly working better," where the only other 
option is "always working worse."

/a

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 13 Nov 2008 11:36:07 -0600

Interesting... Thanks for the input.

Am I reading into this that we want to keep the status quo of 4787 of
not recommending one way or another? 

> From: Adam Roach [mailto:[email-masked]] 
> Sent: Thursday, November 13, 2008 09:30
> To: Audet, Francois (SC100:3055)
> Cc: Fernando Gont; 'Behave Mailing List'
> > We had at some point in the draft process a recommendation to 
> > randomize, but it was taken out because people complained.
> >
> > (But I agree with you to be honest: I believe random failures are a 
> > worst problem than "it just doesn't work)
> 
> It's not always "random failures" -- for example, bittorrent 
> will work okay without port preservation, but work much 
> better (faster finding of peers, finding additional peers, 
> better overall throughput) if port preservation happens.
> 
> So what you have is "randomly working better," where the only 
> other option is "always working worse."
> 
> /a
>

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 13 Nov 2008 13:22:15 -0500

The problem I've always had with port preservation is that several
NATs I've used that attempt it wind up doing address and port
dependent mapping to solve a port collision when two internal hosts
use the same source port to contact the same external address and
port.  I think port preservation is fine (I really prefer random
allocation because port preservation can hide implementation
mistakes), but I think that 4787 should have been stronger in that if
port preservation is implemented, the behavior

"if the port is already in use on all available
   external IP addresses, then these NATs will pick a different port
   (i.e., they don't do port preservation anymore)".

should have been mandatory.  Really, you can't do it any other way if
you follow 4787's req-1 for endpoint-independent mapping.

(note that I don't know if any more recent NATs have this port
preservation/dependent mapping problem)

Bruce

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 13 Nov 2008 12:26:35 -0600

Heuh, it is mandatory in RFC 4787:
    REQ-3:  A NAT MUST NOT have a "Port assignment" behavior of "Port
      overloading".

No?

> From: Bruce Lowekamp [mailto:[email-masked]] 
> Sent: Thursday, November 13, 2008 10:22
> Cc: Adam Roach; Behave Mailing List
> The problem I've always had with port preservation is that 
> several NATs I've used that attempt it wind up doing address 
> and port dependent mapping to solve a port collision when two 
> internal hosts use the same source port to contact the same 
> external address and port.  I think port preservation is fine 
> (I really prefer random allocation because port preservation 
> can hide implementation mistakes), but I think that 4787 
> should have been stronger in that if port preservation is 
> implemented, the behavior
> 
> should have been mandatory.  Really, you can't do it any 
> other way if you follow 4787's req-1 for endpoint-independent mapping.
> 
> (note that I don't know if any more recent NATs have this 
> port preservation/dependent mapping problem)
> 
> Bruce
> 
> 
> >> It's not always "random failures" -- for example, bittorrent will 
> >> work okay without port preservation, but work much better (faster 
> >> finding of peers, finding additional peers, better overall 
> >> throughput) if port preservation happens.
> >>

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Nov 2008 12:31:46 -0600

> not recommending one way or another?

I don't have a strong opinion about whether we should avoid a 
recommendation or recommend port preservation. I think recommending 
*against* port preservation will be harmful to a non-trivial number of 
bittorrent clients (and any other applications that have similar 
properties).

/a

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Nov 2008 10:33:51 -0800

RFC4787 is UDP.  Most of BitTorrent is TCP (except peer exchange (PEX) and
DHT, which I believe both use UDP).

To Adam's point, I don't believe port preservation is needed for PEX, DHT, or
normal BitTorrent, *except* for the port that is configured to be forwarded to
the host running BitTorrent -- much as I wrote in
<http://www.ietf.org/mail-archive/web/behave/current/msg04849.html>.  The port
forwarding is configured via a protocol (UPnP IGD or NAT-PMP) or manually
(HTTP or CLI on the NAT).  

Adam, do you concur, or are you saying ports need to be preserved for all TCP
and all UDP traffic initiated by the BitTorrent host behind the NAT?  If so,
BitTorrent (the protocol, and/or its implementations) will need to evolve as
IPv4 address sharing becomes more common.

-d

> [mailto:[email-masked]] On Behalf Of Bruce Lowekamp
> Sent: Thursday, November 13, 2008 10:22 AM
> To: Francois Audet
> Cc: Behave Mailing List

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 13 Nov 2008 13:34:48 -0500

You're right.  I somehow skimmed that just now and thought that it was
defining port overloading to mean that X1'=X2' and x1=x2=x1'=x2' when
Y1=Y2 and y1=y2.

As stupid as it sounds, we had a NAT that did that (it latched
incoming packets to the first internal machine using the port).  We
simply threw it away as unusable.

Bruce

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 13 Nov 2008 12:36:28 -0600

Yeah, I've seen NATs like this too. 

> Sent: Thursday, November 13, 2008 10:35
> You're right.  I somehow skimmed that just now and thought 
> that it was defining port overloading to mean that X1'=X2' 
> and x1=x2=x1'=x2' when
> Y1=Y2 and y1=y2.
> 
> As stupid as it sounds, we had a NAT that did that (it 
> latched incoming packets to the first internal machine using 
> the port).  We simply threw it away as unusable.
> 
> Bruce
> 
> 
> other way if 
> >> On Thu, Nov 13, 2008 at 12:36 PM, Francois Audet 
> <[email-masked]> 
> >> wrote:

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Nov 2008 12:55:37 -0600

Dan Wing wrote:
> and all UDP traffic initiated by the BitTorrent host behind the NAT?
>   

"Need" isn't the proper term. "Benefit from" is what I'm trying to 
convey. The manual NAT configuration is a relatively advanced activity 
that not all users will bother with. However, with port preservation -- 
at least, as far as I understand that term -- users who don't bother 
with NAT configuration will get the same effect.

At least, that's what I've observed as a user. I haven't been sniffing 
packets, and my client is rather old. Things may have changed, or my 
understanding of what the UI renders to me may be imperfect.

/a

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 13 Nov 2008 14:08:03 -0500

I'm not an expert on BitTorrent apps, but I think the issue here is
that BitTorrent et al weren't designed for NATs with
endpoint-independent filtering behavior for TCP because such didn't
really exist (don't think they're that common now, still).  Using UPnP
etc to open up port forwarding has been essentially required, and
since that allows you to get specific external ports, the concept of
"default port" still exists even though the apps are designed to work
through NATs.

Whether the availability of more NATs that support endpoint
independent filtering for TCP would encourage changes in apps is still
an interesting question.  Ultimately, especially with hierarchical
NATs, it may become more reliable.

Stanislav (copied) is a good person to answer these questions, though.
 (unfortunately, much of this conversation is in different threads at
http://www.ietf.org/mail-archive/web/behave/current/index.html)

Bruce

On Thu, Nov 13, 2008 at 1:55 PM, Adam Roach <[email-masked]> wrote:
> "Need" isn't the proper term. "Benefit from" is what I'm trying to convey.
> The manual NAT configuration is a relatively advanced activity that not all
> users will bother with. However, with port preservation -- at least, as far
> as I understand that term -- users who don't bother with NAT configuration
> will get the same effect.
>

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 14 Nov 2008 10:00:31 +0200

>   to port 8080 on the NAT's public interface.

Yeah. For TCP, not so useful. But for UDP it's been a big problem.

I understand IGDv2 will mandate this behavior for IGD port mappings.