Subject: [BEHAVE] Scalability of endpoint independent mapping

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 9 May 2008 19:01:10 +0200

Hi all,

After being deprecated about a year ago, NAT-PT (network address  
translation - protocol translation between IPv6 and IPv4) is again on  
the table after discussions in v6ops.

Now obviously it makes sense for a NAT-PT (let me call it NAT64 = a  
NAT that sits between IPv6 clients and IPv4 servers) to conform to the  
BEHAVE requirements. However... One of these requirements is that  
mappings are endpoint independent. So if I talk to www.google.com with  
source port 49152, I don't get to also talk to www.yahoo.com using  
source port 49152.

Unless I'm mistaken, this basically allows the setup of an outgoing  
session to be an implicit reservation of the source port for  
subsequent incoming sessions, so peer-to-peer applications can work  
through the NAT without the need for an explicit hole punching  
mechanism.

The trouble with this is that it limits the number of active mappings  
per public IPv4 in a NAT to ~64k per transport protocol. In today's  
world, that's probably not a big issue, as IPv4 addresses are still in  
relative plentiful supply. So if you want to NAT a million people,  
it's generally not a big deal if you need to get something like 5000  
IPv4 addresses to do that. However, in the future this can easily  
change. Today, big ISPs request and receive blocks of hundreds of  
thousands to millions of IPv4 addresses. In 3 - 5 years, the supply of  
IPv4 addresses will be depleted, and getting new IPv4 addresses in  
those numbers will no longer be possible. Obviously most of the  
existing ISPs already have large amounts of IPv4 address so those can  
repurpose their existing addresses.

The trouble will be with new ISPs that grow fast. For them, being  
limited to 64k mappings per IPv4 addresses may be a significant issue.  
I'm not sure how many users can be supported with 64k port numbers,  
but I'm pretty sure the answer isn't "so many that it will never be an  
issue".

A few data points: with a BitTorrent download gives me 80 TCP sessions  
in ESTABLISHED, 7 in FIN_WAIT1 and 2 in TIME_WAIT.

The sad part is that only VERY few mappings will ever actually see  
incoming sessions that benefit from the endpoint independent behavior:  
most sessions are for client-server protocols. To be more precise:  
most sessions are for HTTP, which eats up TCP sessions at an  
incredible rate, especially considering today's web design practices.  
A visit to washingtonpost.com creates 17 TCP sessions. Strangely,  
clicking on a link a bit later even more at 28. For microsoft.com it's  
13 and 13, wikipedia.org 8. Then my RSS app refreshed its feeds and  
generated 50 sessions. Three IMAP counts hover at around 8 continous  
sessions. The TIME_WAIT state is shorter than I thought it would be  
(on my Mac) so I'd say that HTTP sessions stick around for 30 seconds,  
60 seconds at most. Still, that means that someone who is clicking on  
a link every 30 seconds can easily use up 10 port numbers on a  
continuous basis.

What I'm hoping for is that it would be possible to tighten the  
requirements such that we get closer to reserving ports for  
applications that really need reserved ports and get to reuse ports  
for client-server applications so that a BEHAVE-compliant NAT can  
support a much larger user base with the same number of public IPv4  
addresses as these addresses start to run out.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 10 May 2008 13:20:46 -0700

> addresses as these addresses start to run out.

I don't understand the relationship between endpoint independent mapping
and the desire to free up the ports earlier.   I think you are only 
really asking for the NAT's TCP TIME_WAIT to be short.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 11 May 2008 15:48:22 +0200

Hi Dan,

I think Iljitsch is talking about the same scenario

Consider a host H1 behind a nat which has a single public address T.
Suppose H1 initiates a communications towards an external host H2 at port w.

So, packet from H1 to the NAT has, source (H1,v) and destination (H2,w)

Now, when the packet is received at the NAT is creates a mapping
(H1,v) <->(T,u) and the nat sends the packet with source (T,u) and 
destination (H2,w)

Now, suppose another host H3 initiates a communication toward a node H4 
at port j.
The packet from H3 towards the nat has source (H3,i) and estiantion (H4,j)

when the packet from He reaches the NAT, does the NAT can crate a 
mapping (H3,i)<->(T,u)

As i understand it, if we want to have endpoint independent mapping, 
this is not possible (this is so, because if later on H1 sends a packet 
towards H4 at port j, and we want to use the same mapping H1 is already 
using, we would end up in a conflict)

So, this basically means, that when the mapping for H1 (H1,v) <->(T,u) 
is created in the NAT, the transport address (T,u) cannot be used for 
ANY other rmapping (cause needs to be reserved for future potential 
communications of H1 with other destiantions.

So basically with endpoint independent mappings, each internally 
initiated communication eats up one port of the nat, reducing the number 
of simultaneous communications the NAT can handle. If we had address 
dependent mapping, the mapping takes into account the destination 
address also, so even if you may need more than one mapping when the 
same source transport address is used for two different external 
destinations, the NAT does not needs to reserve the port exclusively for 
the internal source address, so it is likely that a better usage of port 
range of the nat is achieved.

I mean, this is the price we need to pay for endpoint independence

Am i missing something?

Regards, marcelo

---

From: Rémi Després <[email-masked]>
Date: Sun, 11 May 2008 17:34:33 +0200

I FULLY SUPPORT the requirement of "reserving ports for
applications that really need reserved ports and get to reuse ports
for client-server applications".

This becomes more and more necessary as address mappings are more and 
more performed, or envisaged, within ISP infrastructures.

For this, the approach I see is as follows:
- NATs SHOULD do end-point INDEPENDENT mapping (that of "full cone" 
NATs) when packets that initiate addresss-port mappings indicate that 
this is needed.
- They MAY do end-point DEPENDENT mappings in all other case.
- They SHOULD do end-point DEPENDENT mappings wherever sparing use of 
public IPv4 addresses is desirable.

IMU, packets that indicate in a standard way a need for end-point 
independent mapping are those sent to:
- STUN and TURN servers (server port 1990, 1991 or 1992)
- Teredo servers (server port 3544)

Would this satisfy what you had in mind?

Regards.

Rémi

Iljitsch van Beijnum wrote :
>  NAT that sits between IPv6 clients and IPv4 servers) to conform to
> the BEHAVE requirements. However... One of these requirements is that
>  mappings are endpoint independent. So if I talk to www.google.com
> with source port 49152, I don't get to also talk to www.yahoo.com
> using source port 49152.
> 
>  world, that's probably not a big issue, as IPv4 addresses are still
> in relative plentiful supply. So if you want to NAT a million people,
> thousands to millions of IPv4 addresses. In 3 - 5 years, the supply
> of IPv4 addresses will be depleted, and getting new IPv4 addresses in
> limited to 64k mappings per IPv4 addresses may be a significant
> issue. I'm not sure how many users can be supported with 64k port
> numbers, but I'm pretty sure the answer isn't "so many that it will
> never be an issue".
> 
> A few data points: with a BitTorrent download gives me 80 TCP
> sessions in ESTABLISHED, 7 in FIN_WAIT1 and 2 in TIME_WAIT.
> 
> incoming sessions that benefit from the endpoint independent
> behavior: most sessions are for client-server protocols. To be more
> precise: most sessions are for HTTP, which eats up TCP sessions at an
>  incredible rate, especially considering today's web design
> practices. A visit to washingtonpost.com creates 17 TCP sessions.
> Strangely, clicking on a link a bit later even more at 28. For
> microsoft.com it's 13 and 13, wikipedia.org 8. Then my RSS app
> refreshed its feeds and generated 50 sessions. Three IMAP counts
> hover at around 8 continous sessions. The TIME_WAIT state is shorter
> than I thought it would be (on my Mac) so I'd say that HTTP sessions
> stick around for 30 seconds, 60 seconds at most. Still, that means
> that someone who is clicking on a link every 30 seconds can easily
> use up 10 port numbers on a continuous basis.
> 
> _______________________________________________ Behave mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/behave
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 11 May 2008 14:49:07 -0700

Thanks for explaining.

A reasonable approach is for a NAT to wait until a TCP connection has been
established (3-way handshake completed), and then allow re-using that same
public TCP port for a new connection to another remote host.

-d

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Sunday, May 11, 2008 6:48 AM
> To: Dan Wing
> Cc: 'Iljitsch van Beijnum'; [email-masked]
> Subject: Re: [BEHAVE] Scalability of endpoint independent mapping
> 
> Hi Dan,
>

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 12 May 2008 09:47:43 +0300

> through the NAT without the need for an explicit hole punching

No.

Whether hole punching is needed depends on the *filtering* behavior. Only if 
the filtering is endpoint independent, then hole punching is not needed (but 
still a good idea if only for diagnostics). If filtering is endpoint 
dependent, hole punching is required. BEHAVE does not preclude either type of 
*filtering*.

BEHAVE requires endpoint independent *mapping* so that communication is 
possible between two peers when both are NAT'd. With endpoint dependent 
mapping (a.k.a. symmetric NATs), a peer needs to communicate to the other 
endpoint to determine its own mapping. In other words, both peers need to 
know the other one's mapping to learn their own - an obvious chicken-and-egg 
deadlock.

> per public IPv4 in a NAT to ~64k per transport protocol.

I am well aware of that, but endpoint dependent mappings are such a hassle, 
that I think it would be a terrible idea to allow it. It would also break 
(old-style) STUN, Teredo and ICE/STUNbis.

-- 
Rémi Denis-Courmont

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 May 2008 10:05:07 +0200

but this breaks

   REQ-1:  A NAT MUST have an "Endpoint Independent Mapping" behavior
      for TCP.

described in draft-ietf-behave-tcp-07.txt

doesn't it?

Dan Wing escribió:
>>>> applications that really need reserved ports and get to 
>>>>         
>> reuse ports  
>>     
>>>> support a much larger user base with the same number of 
>>>>         
>> public IPv4  
>>     
>>> I don't understand the relationship between endpoint 
>>>       
>> independent mapping
>>

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 May 2008 11:01:08 +0200

Rémi Denis-Courmont wrote :
> Le Sunday 11 May 2008 18:34:33 ext Rémi Després, vous avez écrit :
> You are mixing *mapping* and *filtering*.

Can you be more specific, and indicate why this would NOT be right?
(I don't understand where the "mixing" takes place.)

> Makes no sense to me. When doing say, RTP/RTCP, the port numbers are typically 
> dynamic, so this won't work - and that's what ICE typically deals with.
> Also, when both sides are NATted, obviously neither of them can use a fixed 
> port. Hence, I believe your proposed scheme will fail terribly in the current 
> world.

IMU:
- Connections that are established with ICE would work with my proposal 
as they did without it: the mapping for them having been established 
with a STUN port as initial server port, traversed NATs would do the 
desired "end-point independent" mapping.

- On the other hand, if client "C1", using its port "c1", calls an HTTP 
server at public address "S1" on port 80, and if another client "C2" 
behind a common NAT, using its port "c2", calls another HTTP server at 
public address "S2", then the NAT may use its same public address and 
port couple (Ni ni) for both connections.
Mappings for this would be:
   (C1-c1, S1-80, TCP) <--> (Ni-ni, S1-80, TCP)
   (C2-c2, S2-80, TCP) <--> (Ni-ni, S2-80, TCP)
or:
   (C1-c1, S1-80) <--> (Ni-ni, S1-80)
   (C2-c2, S2-80) <--> (Ni-ni, S2-80)
(Client C2 may be the same as C1.)

Regards.

Rémi

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 12 May 2008 12:18:49 +0300

> (I don't understand where the "mixing" takes place.)

A full cone NAT is a NAT with endpoint independent mapping *AND* filtering.

Many NATs do independent mapping yet are not at all full cone NATs.

> desired "end-point independent" mapping.

There is no obligation to use STUN binding discovery for ICE. For instance, a 
client can do Binding Discovery using TURN (which has no fixed port number 
AFAIK).

And finally, there are not only IETF protocols in the peer-to-peer world.

Your proposal would break the long tail of peer-to-peer and/or gaming 
protocols. Recipe for a market failure, I'm afraid. Especially when it comes 
to the large ISPs which is precisely what this is all about.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 12 May 2008 12:49:11 +0300

> described in draft-ietf-behave-tcp-07.txt

Yes, I think so too.

This does imply a limit the order of 1,000 users per IP address behind a 
BEHAVE-compliant translator, in comparison to the order of 10,000 behind 
an "aggressively" symmetric translator. Such is the cost of end-to-end 
communication (I don't dare to say end-to-end transparency here). As Iljitsch 
noted.

That's assuming well-mannered user applications. It is fairly trivial to mount 
a DoS against the ports range of a BEHAVE-compliant translator, unless a 
limited number of port allocations per-user is enforced.

As it happens, the BEHAVE requirements where written pretty much on purpose. 
They DO actually solve problems. I believe a certain number of applications 
benefit from BEHAVE-ish NATs, and matter to a large number of paying 
customers for large ISPs. In the western world, if these ISPs can allocate 
one IP per customer today, they should be able to allocate one IP per 500 
customers in the foreseeable future.

Also, in managed networks, BEHAVE-compliance is probably not such a big deal. 
There, you have firewalls and gateways. And peer-to-peer/end-to-end is not 
really aimed for. In fact, it's typically fought against.

Well, scalability may be a problem in IP-deprived areas. If it happens, BEHAVE 
will not be complied with. Too bad. But I believe "breaking" the current 
BEHAVE requirements would be even worse overall.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 12 May 2008 09:53:48 +0300

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 May 2008 12:17:11 +0200

Hi  Remi,

the question that comes next is: what happens when we run out of IPv4 
addresses and all the world becomes (in a more or less manner) an 
IP-deprived area?

Regards, marcelo
PS: FWIW i also think that the endpoint independence is a requierement 
we must meet, but just want to make sure we all understand its cost

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 12 May 2008 11:37:38 -0400

I agree.  And even if the hypothetical savings in the number of IPv4 
addresses needed for NATs is realized, going to endpoint-dependent 
mapping would require every major ISP that deploys one of these things 
to deploy a number of TURN relays since their customers won't be able to 
connect directly with those behind similar NATs.  So you're trading a 
lot of bandwidth and machines deployed as relays for a savings of IP 
addresses.   If you were doing a full voip (or gaming or whatever) 
deployment, it isn't actually clear to me that you won't need to deploy 
as many relays  (with public IP addresses) as you theoretically saved by 
using a symmetric NAT.

Bruce

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 May 2008 17:39:34 +0200

> A full cone NAT is a NAT with endpoint independent mapping *AND* filtering.

Thanks for the explanation.
My proposal should then avoid the reference to cone NATs.

(For your answer to be complete, can you indicate where I could have 
read your definition?)

> client can do Binding Discovery using TURN (which has no fixed port number 
IMU, and according to draft-ietf-behave-turn-tcp-00, TURN servers use 
TURN specific requests, responses, attributes and response codes, but 
should use the same port number as STUN.

BUT see also the conclusion below, whereby this is no longer a concern.

> protocols. Recipe for a market failure, I'm afraid. 
The concern is of course legitimate.

CONCLUSION
In view of your remarks (thanks or them), my initial proposal can be 
improved, to become:

  1. NATs SHOULD do end-point INDEPENDENT mapping if packets that 
initiate addresss-port mappings don't have destination ports indicating 
that endpoint DEPENDENT mapping is acceptable.
  2. In general, NATs MAY do endpoint INDEPENDENT mapping if packets 
that initiate addresss-port mappings have destination ports indicating 
that endpoint DEPENDENT mapping is acceptable.
  3. Where sparing use of public IPv4 addresses is desirable, NATs 
SHOULD use endpoint DEPENDENT mapping if packets that initiate 
addresss-port mappings indicate that endpoint DEPENDENT mapping is 
acceptable.
  2. Destination port numbers that indicate that endpoint DEPENDENT 
mapping is acceptable are those of: HTTP, SMTP, POP3, NNTP, Telnet, SNMP 
(and a few others, list to be completed)

Regards.

Rémi

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 12 May 2008 17:58:49 +0200

> for client-server applications".

Excellent.

I see several others say "peer-to-peer is more important than  
scalability", which is an artificial dichotomy: if we work a bit  
harder we can have both.

> Would this satisfy what you had in mind?

No, because then only Teredo (which should never be used through NAT- 
PT, which is the part that I'm concerned about) and STUN/TURN have the  
endpoint independent behavior, not the actual peer-to-peer application  
protocols.

A more useful approach would be to assume that all protocols that use  
a < 1024 well-known port number are client-server and don't need  
endpoint independence. (Perhaps with a few exceptions.) The main thing  
that this catches is web and mail, web uses many short lived sessions  
and mail may use several long lived sessions. With these out of the  
way endpoint independent mapping for the protocols on port numbers >  
1023 shouldn't be too problematic.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 May 2008 18:14:53 +0200

> we must meet, but just want to make sure we all understand its cost

IMU, it is still possible to avoid the cost of endpoint independence in
cases where NATs can easily and safely detect that it isn't necessary.

My proposal for this, following Rémi Denis-Courmont's remarks, has become:

  1. NATs SHOULD do end-point INDEPENDENT mapping if packets that
initiate addresss-port mappings don't have destination ports indicating
that endpoint DEPENDENT mapping is acceptable.
  2. In general, NATs MAY also do endpoint INDEPENDENT mapping if
packets that initiate addresss-port mappings have destination ports
indicating that endpoint DEPENDENT mapping is acceptable.
  3. But, where sparing use of public IPv4 addresses is desirable, NATs
SHOULD use endpoint DEPENDENT mapping if packets that initiate
addresss-port mappings indicate that endpoint DEPENDENT mapping is
acceptable.
  2. Destination ports that indicate that endpoint DEPENDENT mapping is
acceptable are those of: HTTP, SMTP, POP3, NNTP, Telnet, SNMP (and a few
others, list to be completed)

So far, I don't see why this wouldn't work.

IMU, the saving on address-port consumption could be huge in view of 
examples given by Iljitsch in
http://www.ietf.org/mail-archive/web/behave/current/msg03821.html.

Regards.

Rémi

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 May 2008 10:00:36 -0700

> Sent: Monday, May 12, 2008 1:05 AM
> To: Dan Wing

Yes.

But does re-using the same public TCP port, after the 3-way handshake
completes, cause something to break?  It feels pretty safe to me.

-d

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 12 May 2008 13:14:13 -0400

> My proposal for this, following Rémi Denis-Courmont's remarks, has become:

First, is this idea restricted to TCP?  The argument seems to make the 
most sense there.

> that endpoint DEPENDENT mapping is acceptable.

Why make this a SHOULD?  This should be a MUST.  There's no point in 
writing a draft that requires nothing to be compliant with it.

> indicating that endpoint DEPENDENT mapping is acceptable.

That's implicit in rule 1, regardless of whether it's SHOULD or MUST.

> addresss-port mappings indicate that endpoint DEPENDENT mapping is

would be better off saying MAY use dependent mapping in specific cases 
of well known TCP ports < 1024 if address conservation is desirable.

> others, list to be completed)

I doubt most of these are a factor internet-wide other than HTTP, but 
certainly http, pop3, imap, and maybe snmp and ssh are the most common.

> So far, I don't see why this wouldn't work.

For well-known TCP services, I can't think of a strong argument that it 
wouldn't.  I still think this requires a lot more thought.

> http://www.ietf.org/mail-archive/web/behave/current/msg03821.html.

Of course, the bit torrent example in that email is precisely the 
application that making this type of change is likely to break.  Should 
be OK with the well-known ports below 1024.  However, given that there's 
a common hack of running other protocols on port 80 just because port 80 
tends not to be filtered, I'm confident this proposal would break some 
applications.  (but breaking that particular hack may not be the most 
evil thing ever done)

Bruce

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 May 2008 10:30:40 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bruce Lowekamp
> Sent: Monday, May 12, 2008 8:38 AM
> To: Rémi Denis-Courmont
> Cc: [email-masked]
> as many relays  (with public IP addresses) as you 
> theoretically saved by using a symmetric NAT.

All of Iljitsch's examples were for TCP applications.  Thus, I assume
the primary concern is TCP port consumption (rather than UDP port
consumption).  TCP may well be easier to fix, anyway, as it has a 3-way
handshake after which no other host can send data into the TCP flow
anyway.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 May 2008 10:32:44 -0700

> From: Rémi Denis-Courmont [mailto:[email-masked]] 
> Sent: Monday, May 12, 2008 2:49 AM
> To: [email-masked]
> Cc: ext marcelo bagnulo braun; Dan Wing

Waiting until the 3-way handshake completes still allows for TCP
simultaneous open (which is one of the big reasons for that BEHAVE
requirement), and still allows interesting ideas such as the TCP
anycast mechanism described on page 6 of RFC1546, which may not
have been implemented by anybody (due to firewalls and NATs and
TCP stacks not working well with it), but still it is something
that we should not unnecessarily break, either.  My proposal should
work fine with it.  That paragraph of RFC1546 reads:

   The solution to this problem is to only permit anycast addresses as
   the remote address of a TCP SYN segment (without the ACK bit set).  A
   TCP can then initiate a connection to an anycast address.  When the
   SYN-ACK is sent back by the host that received the anycast segment,
   the initiating TCP should replace the anycast address of its peer,
   with the address of the host returning the SYN-ACK.  (The initiating
   TCP can recognize the connection for which the SYN-ACK is destined by
   treating the anycast address as a wildcard address, which matches any
   incoming SYN-ACK segment with the correct destination port and
   address and source port, provided the SYN-ACK's full address,
   including source address, does not match another connection and the
   sequence numbers in the SYN-ACK are correct.)  This approach ensures
   that a TCP, after receiving the SYN-ACK is always communicating with
   only one host.

-d

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 May 2008 19:47:35 +0200

> First, is this idea restricted to TCP?  The argument seems to make the 

AFAIK, It doesn't need to be restricted to TCP, but even restricted to 
to TCP it could make a lot of good.

> writing a draft that requires nothing to be compliant with it.

I guess you are right.
MUST seems better.

> That's implicit in rule 1, regardless of whether it's SHOULD or MUST.

I agree that it is not necessary.

> of well known TCP ports < 1024 if address conservation is desirable.

Not sure what you mean.
IMU, no need to change, but may nedd more discussion.

> wouldn't.  I still think this requires a lot more thought.

I agree, but IMO that's worth it.

> applications.  (but breaking that particular hack may not be the most 
Finding how bit torrent would break, if it is, is beyond my current 
knowledge of how it works.
In particular, does it work across restricted cone NATs, and across 
symmetric NATs, and if yes how?

Thanks for your remarks.

BTW, I will be unable to read my emails from tonight to May 20.
If I don'answer quickly to further comments this will be the reason.

Regards.

Rémi

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 May 2008 21:35:49 +0200

Iljitsch van Beijnum wrote :
> On 12 mei 2008, at 19:47, Rémi Després wrote:

> the default BitTorrent ports are 6881-6889.
> 
>  you'd probably want BitTorrent to be on the list 
> of apps that forego endpoint independence or change the apps to reuse 
> the port.)

Agreed: unless a new fact is unveiled, the bit torrent range of ports 
6881-6889 would be one to be added to the list of those that address 
sparing NATs, in order to practice endpoint independent mapping where it 
doesn't hurt, have to recognize.

> Also, BitTorrent has good IPv4->IPv6 transition properties: as long as a 
> reasonable fraction of the peers is dual stack and they use the DHT, it 
> works because there is no need for every peer to talk to every other peer.
> 
>>> Should
> The main thing that BitTorrent needs to work efficiently is for a host 
> to be able to accept incoming TCP sessions. AFAIK, there is no out of 
> band mechanism to negotiate the setup of specific sessions, just the 
> distribution of addresses/ports on which prospective peers are 
> reachable. I.e., it doesn't support ICE.
It would be appreciated if someone with a thorough knowledge of bit 
torrent could help making sure we work with reality.

Thanks.

Rémi

---

From: David Barrett <[email-masked]>
Date: Mon, 12 May 2008 12:52:20 -0700

>> the default BitTorrent ports are 6881-6889.

I think the default depends on the BitTorrent client, and is perhaps 
even randomly selected by some clients.  For example, I'm using 
Transmission on Ubuntu and it's using 51413 for incoming TCP.

Also, the torrent protocol doesn't support NAT penetration at all: peers 
establish unsolicited TCP connections with other peers.  So if you can't 
accept incoming TCP you can only access the subset of peers that do -- 
NAT'd peers can't talk to other NAT'd peers at all, not even 
fullcone/fullcone.  (Unless one uses UPnP or manually establishes a port 
forward, that is.)

-david

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 12 May 2008 16:06:22 -0400

Rémi Després wrote:
>>  you'd probably want BitTorrent to be on the list of apps that forego 
>> endpoint independence or change the apps to reuse the port.)
> 

Um, I'm confused.  Did you mean *dependent* mapping in that last 
sentence?  My understanding was that the proposal was to have a set of 
ports for which dependent mapping was acceptable (such as http).  Since 
6881-6889 are not one of those ports used by well-known safe protocols, 
they would of course have independent mapping.

I'm concerned that last paragraph is introducing a slippery slope.  One 
of the reasons to have behave-compliant NATs is so that every NAT 
doesn't have to be upgraded every time a new application comes out. 
Regardless of the ports current bittorrent applications are using now 
and regardless of whether they currently support ICE, a behave-compliant 
NAT should not break new applications.

I can see an argument that it might be OK to allow dependent mapping in 
a situation where it is known not to hurt applications (http).  But the 
default still needs to be independent mapping, otherwise applications break.

> torrent could help making sure we work with reality.

Somewhat, but the goal isn't to achieve compatibility with the 10 
applications we happen to care about at the moment.  It's to make sure 
new applications can be developed that work on the internet.

Bruce

---

From: Rémi Després <[email-masked]>
Date: Mon, 12 May 2008 22:42:38 +0200

>> sparing NATs, in order to practice endpoint independent mapping where 
>> it doesn't hurt, have to recognize.
>>
> 
> sentence?

Yes, "dependent" was the right word. (Sorry for that.)

> My understanding was that the proposal was to have a set of 

It seems to me that dependent mapping for bit torrent, if reasonably 
simple to ensure, must remain a goal.
If a host behind a shared NAT establishes many connections (with non 
natted peers since this is the case), it is very useful to avoid that 
each connection consumes a full address-port pair.
> NAT should not break new applications.

An improved combination could be:
  - If the packet that initiates the mapping has a well known 
destination port (< 1024), then dependent mapping is restricted to a 
short list (HTTP plus a few others).
  - If the destination port is beyond 1023, then dependent mapping is 
freely practiced.

New applications for which INdependent mapping is required would have to 
use ports below 1024.

Other new applications would preferably use ports in the registered port 
range (1024 to 49151).

Rémi

* Sorry I won't be able to pursue this (interesting and hopefully 
productive) discussion for one week.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Bruce Lowekamp <[email-masked]>
Date: Mon, 12 May 2008 16:52:43 -0400

Rémi Després wrote:
>> My understanding was that the proposal was to have a set of ports for 
>> which dependent mapping was acceptable (such as http).  Since 
>> 6881-6889 are not one of those ports used by well-known safe 
>> protocols, they would of course have independent mapping.
> 

Your proposed solution prevents anyone behind a nat from serving pieces 
of the file.  You then suggest that all of these connections are going 
to be with non-NATted peers, but your entire scenario is based on the 
idea that it's going to be needed in a time when IPv4 address space is 
completely exhausted and being reclaimed as ASes are converting to IPv6. 
   Which means that these non-NATed peers are going to be much scarcer 
than they are now.   Which means that you need to have peers behind NATs 
serving pieces.  Which means they need to have independent mapping.

So, no, bittorrent is exactly the application you DON'T want to have 
dependent mapping for.

>>
>> I'm concerned that last paragraph is introducing a slippery slope.  
>> One of the reasons to have behave-compliant NATs is so that every NAT 
>> and regardless of whether they currently support ICE, a 
>> behave-compliant NAT should not break new applications.
> 
>  - If the packet that initiates the mapping has a well known destination 
> port (< 1024), then dependent mapping is restricted to a short list 
> (HTTP plus a few others).

no.  you can't make dependent mapping the default.  Why not just go full 
symmetric and break every application that tries to allow inbound 
connections?

> New applications for which INdependent mapping is required would have to 

Now that is asking for both port preservation and root privilege (on a 
lot of platforms) for p2p applications.

Bruce

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 12 May 2008 20:52:29 +0200

>> application that making this type of change is likely to break.

How?? Even assuming that the BitTorrent application uses endpoint  
indepedent mapping as an implicit NAT hole punching technique (which I  
haven't encountered, they usually use UPnP/NAT-PMP or manual mappings)  
the default BitTorrent ports are 6881-6889.

(Note that because BitTorrent sets up A LOT of sessions (configurable,  
but certainly dozens and more than 100 or 200 is possible) and keeps  
trying to set up new sessions, it would use up endpoint independent  
port numbers really fast so you'd probably want BitTorrent to be on  
the list of apps that forego endpoint independence or change the apps  
to reuse the port.)

Also, BitTorrent has good IPv4->IPv6 transition properties: as long as  
a reasonable fraction of the peers is dual stack and they use the DHT,  
it works because there is no need for every peer to talk to every  
other peer.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 12 May 2008 21:59:45 +0200

> Transmission on Ubuntu and it's using 51413 for incoming TCP.

It's very common to use non-standard ports. Some BitTorrent  
communities even block the default ports in an effort to obscure  
BitTorrent use against prying service provider eyes.

> fullcone/fullcone.  (Unless one uses UPnP or manually establishes a  

Right. However, even with no NAT traversal BitTorrent works because  
there are enough peers that can accept incoming connections. It's just  
much faster if you set things up so that incoming connections work  
because you can talk to more peers and more easily to other peers.

(Please note that this message probably won't make it to the list.)
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 12 May 2008 18:54:18 -0700

> So far, I don't see why this wouldn't work.

It won't work because it will be impossible to reach closure on a finite set
of port numbers for this special behavior.

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 13 May 2008 09:25:09 +0300

> completes, cause something to break?  It feels pretty safe to me.

In theory, ICE-TCP as it currently is.
Whether this is a real issue is a different matter.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 13 May 2008 09:29:27 +0300

> work fine with it.  That paragraph of RFC1546 reads:

Waiting until the 3-way handshake does not break TCP-SO per se. But it breaks 
TCP Binding Discovery, which renders TCP-SO pretty unusable. Or did I miss 
something?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 13 May 2008 09:46:21 +0200

> completes, cause something to break?  It feels pretty safe to me.
the connection will not break, agree
The problem i guess is that you will need to always use TURN relay to 
receive incoming TCP connections and that seems to be not the best option.

Having endpoint independent mappings for TCP would allow internal hosts 
to receive incoming communications without turn relay.

Regards, marcelo

>>>> Consider a host H1 behind a nat which has a single public 
>>>>         
>> address T.
>>     
>>>> As i understand it, if we want to have endpoint 
>>>>         
>> independent mapping, 
>>     
>>>> is created in the NAT, the transport address (T,u) cannot 
>>>>         
>> be used for 
>>     
>>>> ANY other rmapping (cause needs to be reserved for future 
>>>>         
>> potential 
>>     
>>>> of simultaneous communications the NAT can handle. If we 
>>>>         
>> had address 
>>     
>>>> address also, so even if you may need more than one 
>>>>         
>> mapping when the 
>>     
>>>>>> for client-server applications so that a 
>>>>>>             
>> BEHAVE-compliant NAT can  
>>     
>>>>> and the desire to free up the ports earlier.   I think 
>>>>>           
>> you are only 
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 13 May 2008 09:50:43 +0200

please disregard this message, i finally understood what Dan's point was.

sorry for the noise

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 13 May 2008 15:22:37 +0200

> handshake after which no other host can send data into the TCP flow

but a different host could use the same destination and port address to 
establish a new TCP connection towards the internal host, if endpoint 
independent mapping is used, right?

I mean, consider the following scenario:
                                                   (163.1.1.1, 2000)+--+
                                                 +------------------|H2|
                         +-----+(16.1.1.1,5000)  |                  +--+
 +---+(10.1.1.1, 30000)  | NAT |-----------------+                 
 | H1|-------------------|     |-----------------+
 +---+                   +-----+                 |                  +--+
                                                 +------------------|H3|
                                                     (23.1.1.1,8000)+--+
Now suppose H1 starts a communication with H2 and the NAT assigns 
(16.1.1.1,5000) to H1
the TCP connection is identified by [(16.1.1.1,5000),(163.1.1.1,2000)]
So, as you say, no other host can send packets toward that connection

However, if the NAT is doing e3ndpoint independent mapping, then H3 can 
actually initiate a new TCP connection towards 16.1.1.1,5000, using its 
own transport address (the new connection woudl be identified by 
[(23.1.1.1,8000),(16.1.1.1,5000)]

If we do not require endpoint independent mapping, then the only 
alternative would be to use a stun server to allow incoming 
communications towards H1

So, while i agree that nothing breaks, not requiring endpoint indepednet 
mapping requires, as people have been saying, the usage of a stun server 
for incoming communications.

Regards, marcelo

>>> Le Friday 09 May 2008 20:01:10 ext Iljitsch van Beijnum, 
>>>       
>> vous avez écrit :
>>     
>>>> NAT that sits between IPv6 clients and IPv4 servers) to 
>>>>         
>> conform to the
>>     
>>>> mappings are endpoint independent. So if I talk to 
>>>>         
>> www.google.com with
>>     
>>> Whether hole punching is needed depends on the *filtering* 
>>>       
>> behavior. Only if 
>>     
>>> the filtering is endpoint independent, then hole punching 
>>>       
>> is not needed (but 
>>     
>>> still a good idea if only for diagnostics). If filtering is 
>>>       
>> endpoint 
>>     
>>> dependent, hole punching is required. BEHAVE does not 
>>>       
>> preclude either type of 
>>     
>>> *filtering*.
>>>
>>> BEHAVE requires endpoint independent *mapping* so that 
>>>       
>> communication is 
>>     
>>> possible between two peers when both are NAT'd. With 
>>>       
>> endpoint dependent 
>>     
>>> mapping (a.k.a. symmetric NATs), a peer needs to 
>>>       
>> communicate to the other 
>>     
>>> endpoint to determine its own mapping. In other words, both 
>>>       
>> peers need to 
>>     
>>> know the other one's mapping to learn their own - an 
>>>       
>> obvious chicken-and-egg 
>>     
>>> deadlock.
>>>
>>>       
>>>> The trouble with this is that it limits the number of 
>>>>         
>> active mappings
>>     
>>> I am well aware of that, but endpoint dependent mappings 
>>>       
>> are such a hassle, 
>>     
>>> that I think it would be a terrible idea to allow it. It 
>>>       
>> would also break 
>>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 13 May 2008 15:27:26 +0200

> serving pieces.  Which means they need to have independent mapping.

Note that both ends can both serve and receive, regardless of which  
end set up the session.

> So, no, bittorrent is exactly the application you DON'T want to have

The thing is, that all the BitTorrent clients that I'm aware of,  
exclusively rely on manual mappings, UPnP or NAT-PMP. They don't use  
any of the BEHAVE mechanisms.

Now with an ISP-operated NAT, UPnP and NAT-PMP aren't going to work  
because they need the NAT to be on the local subnet, AFAIK. Manual  
mappings isn't entirely impossible but I don't see this working too  
well in practice.

Now there are two possible ways forward: the BitTorrent clients start  
making use of endpoint independent mapping and stop using up large  
numbers of port numbers, OR they keep their current behavior but the  
NATs figure out a way to make sure that BitTorrent doesn't use  
endpoint independent mapping because this uses up too much port numbers.

A logical way forward would be for NATs to limit the number of ports  
that a single host can use up, and create a way to differentiate  
between applications that need endpoint independence and ones that  
don't. I think defining a small set of destination port number ranges  
for this would be the easiest solution.

>> destination

> no.  you can't make dependent mapping the default.

Indeed. Make < 1024 endpoint dependent, this is is where the main  
offenders and most client-server apps reside. Then make everything  
else endpoint independent except maybe a small range somewhere for  
apps that don't need/want this but can't easily run on < 1024 ports.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 May 2008 07:56:31 -0700

> Sent: Tuesday, May 13, 2008 12:46 AM
> To: Dan Wing

I don't see TURN being needed with my idea.  I will write it up
in more detail and (as is often the case when I write things down
in detail) may find my idea is flawed.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 May 2008 08:25:36 -0700

> because they need the NAT to be on the local subnet, AFAIK.

Right.

It may be worth considering proxying UPnP or NAT-PMP into a 
address-port-borrowing-protocol -- so that the host still runs
UPnP/NAT-PMP and talks to its local router which (unbeknownst to
the host) operates an address-port-borrowing-protocol to the
ISP's big v4/v6 NAT-in-the-sky and returns a public v4 address 
to the host.

-d

> Manual

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 13 May 2008 17:40:24 +0200

> ISP's big v4/v6 NAT-in-the-sky and returns a public v4 address

If my understanding of all the protocols in question is correct, it  
would even be possible for a UPnP/NAT-PMP proxy to connect to a STUN  
server and then pass on the port that the STUN server sees on to the  
application. If the NAT is then endpoint independent the application  
will be able to receive incoming sessions through the port/address in  
question.

Getting this to work for TCP is left as an exercise for the reader...
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 May 2008 08:50:16 -0700

> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Tuesday, May 13, 2008 8:40 AM
> To: Dan Wing
> Cc: 'Bruce Lowekamp'; [email-masked]
> application.

Mostly, yes.  The difficulty is that both UPnP and NAT-PMP require that
any public mapping be completely non-filtered by the router.  With
STUN, we have no way to know what kind of filtering or mapping behavior
the NAT will use.  Thus, if such a UPnP/NAT-PMP proxy merely used STUN, 
the NAT might not meet UPnP/NAT-PMP's requirements, and the 'legacy'
application would get a public IP address and port that does not work
like when it is behind a "real" UPnP/NAT-PMP-capable router on v4.

> If the NAT is then endpoint independent the application  
> will be able to receive incoming sessions through the 
> port/address in question.
> 

Heh.  A master of understatement.

-d

---

From: Bruce Lowekamp <[email-masked]>
Date: Tue, 13 May 2008 12:51:45 -0400

Iljitsch van Beijnum wrote:
> Note that both ends can both serve and receive, regardless of which end 
> set up the session.
> 
> exclusively rely on manual mappings, UPnP or NAT-PMP. They don't use any 
> of the BEHAVE mechanisms.
> 
> mappings isn't entirely impossible but I don't see this working too well 
> in practice.
> 

This is my concern.  If the scarce address scenario becomes more common, 
it seems like new techniques will be required, and that points toward 
needing the independent mappings.

> NATs figure out a way to make sure that BitTorrent doesn't use endpoint 
> independent mapping because this uses up too much port numbers.
> 

If NATs support indepdendent mapping and TCP-SO, there won't be a reason 
to allocate hundreds of ports.  If that solution works more reliably 
than others, it would be adopted by new software and also solve the 
scalability problem.

> that a single host can use up, and create a way to differentiate between 
> applications that need endpoint independence and ones that don't. I 
> think defining a small set of destination port number ranges for this 
> would be the easiest solution.

I thought many existing NATs would either start sending RSTs or ignore 
new connections.  Don't know how common that behavior is, though.

Bruce

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 13 May 2008 21:31:34 +0200

> like when it is behind a "real" UPnP/NAT-PMP-capable router on v4.

Well, but this is a problem that can be fixed without protocol  
changes, so although it would be an issue in practice it's not a big  
deal as far as the IETF is concerned.

> Heh.  A master of understatement.

Unless I'm missing something this should actually be fairly  
straightforward: just STUN for TCP + endpoint independent mapping.

On 13 mei 2008, at 18:51, Bruce Lowekamp wrote:

>> well

> needing the independent mappings.

I have no problem with giving the apps that need it independent  
mappings, we just need to figure out something to avoid applications  
from using up too many port numbers. As I wrote before, we can do this  
if we can recognize the most common client/server apps and give those  
endpoint dependent mappings.

And don't forget that even though IPv4 addresses may become scarce, we  
still have IPv6. Applications like BitTorrent can transition from IPv4  
to IPv6 very gracefully so I'm not worried about those.

> than others, it would be adopted by new software and also solve the

Right!

Note though that simultaneous open would probably hard to put into  
BitTorrent. Using an initial session as an implicit hole punch with  
endpoint independence would be easier.

Now we just need to fix HTTP/POP/IMAP...
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 13 May 2008 12:41:37 -0700

> deal as far as the IETF is concerned.

Agreed.

> straightforward: just STUN for TCP + endpoint independent mapping.

STUN for TCP exists (draft-ietf-behave-rfc3489bis now specifies how
STUN-over-TCP works).  The trouble is, many NATs don't do endpoint
independent mapping for TCP.  See Saikat's results at 
http://nutss.gforge.cis.cornell.edu/stunt.php, for example.

Of course with NAT64 we could specify exactly how a NAT64 is supposed
to work and maybe bypass much of the problem that STUNT found with
existing NATs.  The difficulty persists if NAT64 needs to work
with today's off-the-shelf Linksys/Dlink/Belkin/etc. NAPTs that
everyone buys at the local computer store.  

-d

---

From: Philip Matthews <[email-masked]>
Date: Tue, 13 May 2008 22:22:09 -0400

If I understand things correctly, what Iljitsch is suggesting is not  
"address-dependent" mapping as I understand it. My understanding of  
"address-dependent" mapping is that a new transport address (on the  
public side of the NAT) is assigned by the NAT to every new  
destination. However, Iljitsch wants instead to re-use the same  
transport address for many different destinations.

Let me give an example.
Let A and B be two nodes on the private side of the NAT.
Let X and Y be two nodes on the public side of the NAT.
Let (T,t) be some transport address assigned to the public side of the  
NAT.

Now consider the following flows:
Private       Public
Node          Node
(A,a) ------> (X,x1)
(A,a) ------> (X,x2)
(A,a) ------> (Y,y1)
(B,b2) -----> (Y,y2)

- Endpoint-independent mapping would assign the same transport address  
to the first three, and a different transport addresses to the last one.
- Address-dependent mapping would assign the same transport address to  
the first two, and different transport addresses to the last two.
- Address-and-port-dependent mapping would assign different transport  
addresses to all of these.
- But what Iljitsch wants to do is to assign the same transport  
address (T,t) for all of these.
 From the NAT perspective, (T,t) can be used for all of these because,  
when the response comes back from the public node, the NAT can  
determine the private node to forward it to by which public node sent  
the packet. For example, it would have a rule that says: if the packet  
is destined for (T,t) and came from (X,x1), then change the  
destination address to (A,a).

I don't yet understand the implications of this, but I thought I  
should point it out.

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 14 May 2008 09:36:13 +0300

> ISP's big v4/v6 NAT-in-the-sky and returns a public v4 address

Indeed, this could work for ISP-provisioned CPEs.

In fact, this may be a good thing to have *if* v4-v6-v4 actually happens.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 May 2008 00:04:10 -0700

> Indeed, this could work for ISP-provisioned CPEs.

Sure, most users won't have a clue and will be happy to
just get a brand new, 189228GHz and 100Gbps wireless box with
blue LEDs from their ISP that "Just Works".

But if we standardize the protocol, this could be a service the 
ISP runs even with non-ISP-provisioned CPE.  It could be as simple 
as your ISP saying: "you can retain v4 access, as you have it 
today, for an additional $NNN/month.  Or you can get v6 access 
for the same price you're getting today; if you need to 
communicate with a v4 host, you can run such-and-such 
address-port-borrowing-protocol with our NAT64 box at <such-
and-such> IP address.  Your authentication credentials for 
accessing the NAT64 box are the same as the username/password
used for our other ISP-provided services (email, USENET, and 
PPPoE)."

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 May 2008 10:50:57 +0200

> STUN-over-TCP works).

Excellent.

> existing NATs.

Right. The good thing here is that we're not constrained by hundreds  
of existing implementations that all behave differently. And existing  
CPEs can't work on the v6 side of a NAT64 universe anyway, so those  
aren't an issue at all.

I was thinking:

If an application wants to make use of endpoint independent mapping  
behavior by the NAT, wouldn't its first packets be towards a STUN(T)  
server? If we can detect this, providing endpoint independent behavior  
where it's needed and using endpoint dependent mappings everywhere  
else is easy.

For TCP, another option would be a TCP option in the SYN from the host  
to the STUNT server, or in the SYN/ACK from the STUNT server back to  
the host, this is probably easier to do than deep packet inspection to  
determine whether a random TCP session is used for STUNT.

On 14 mei 2008, at 4:22, Philip Matthews wrote:

> But what Iljitsch wants to do is to assign the same transport

I don't think I understand what you're trying to say, but I'm fairly  
sure it's not what I said. I don't think a single behavior applied to  
all sessions will give us both the peer-to-peer usability that we want  
and enough scalability.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Wed, 14 May 2008 05:08:58 -0400

> all sessions will give us both the peer-to-peer usability that we want

Sure.
The proposal to do endpoint-independent mapping for some ports, and  
this new "transport-address-reuse" mapping for other ports seems  
interesting. I was just trying to point out that what you want is not  
address-dependent mapping (at least as I understand it), but some new  
mapping behavior that uses the same transport address for unrelated  
sessions.

- Philip

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 May 2008 09:33:41 -0700

> Sent: Wednesday, May 14, 2008 1:51 AM
> To: Dan Wing; Philip Matthews
> Cc: [email-masked]

Someone else (Rémi Després, I believe) had proposed doing that using
port numbers.  Doing it with port numbers would also be the first time 
that TCP behavior is different for different port numbers (the port 
1024 restriction does not change the behavior of TCP itself).  But
I see (below) that you are considering DPI rather than TCP port
numbers.

Another idea floating in my head is to use STUN-over-TCP to the 
NAT64's public IP address itself, which is trivial for the NAT64
to notice.  Essentially that is what is described in 
<http://tools.ietf.org/html/draft-wing-behave-nat-control-stun-usage-05>,
which is an expired draft.

> For TCP, another option would be a TCP option in the SYN from 
> the host to the STUNT server, or in the SYN/ACK from the STUNT 
> server back to the host, this is probably easier to do than deep 
> packet inspection to determine whether a random TCP session is 
> used for STUNT.

If the NAT64-aware box at the customer premise could make the decision
(somehow; I'm not sure how it could do that yet), the NAT64-aware box
could communicate the decision to the ISP's big NAT64-box-in-the-sky
using a simple-to-see trigger like that.

Unfortunately the application and host OS (Windows, OSX) couldn't set 
that TCP bit without changes to the TCP API and the TCP stack itself 
- which means an OS upgrade or, at minimum (if the vendors are 
motivated) an OS patch.

-d

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 May 2008 19:22:35 +0200

On 14 mei 2008, at 18:33, Dan Wing wrote:

>> server? If we can detect this, providing endpoint independent
>> behavior where it's needed and using endpoint dependent mappings  
>> everywhere
>> else is easy.

> I see (below) that you are considering DPI rather than TCP port

I was.

If STUN always uses port 3478 then that's obviously a good way to  
detect sessions towards a STUN server.

So if a host first contacts some random destination using source port  
8000 and destination 3478, we know it's talking to a STUN server so we  
need to make the mapping for source port 8000 address independent. But  
if a session goes towards port 80 or what have you and the source port  
isn't used in recent history by that host, we know the host doesn't  
require endpoint independent mapping.

> to notice.

Yes, but how do hosts know to only use the NAT64's address as their  
STUN server?

Don't STUN-aware applications use STUN servers that are preconfigured  
by the application?

> using a simple-to-see trigger like that.

Right. Maybe add a router alert for good measure.  :-)

> - which means an OS upgrade or, at minimum (if the vendors are

Right, that's why I was thinking the option could also flow in the  
direction from the STUN server to the NAT. Presumably, a STUN server  
can more easily be set up to include such an option.

But if we can simply look for port 3478 that's a lot easier.

Iljitsch

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 14 May 2008 10:29:09 -0700

> Sent: Wednesday, May 14, 2008 10:23 AM
> To: Dan Wing
> Cc: 'Philip Matthews'; [email-masked]
> Don't STUN-aware applications use STUN servers that are 
> preconfigured by the application?

Yes, so you could configure that application so its STUN server is
the public IP address of the NAT64 box.  Or the application could
talk to any STUN server on the Internet and learn the IP address of
its NAT64 box (which is the mechanism described in 
draft-wing-behave-nat-control-stun-usage).

> Right. Maybe add a router alert for good measure.  :-)

heh.

> But if we can simply look for port 3478 that's a lot easier.

I am worried that could tie NAT64 too much to STUN.

-d

---

From: Rémi Després <[email-masked]>
Date: Wed, 21 May 2008 16:15:44 +0200

>> behavior  
> port numbers.
Right.

AFAIK, this is still quite effective a solution, and IMU a really simple 
one:
It goes like this:

1. To be an *address-port sparing NAT*, a NAT MUST do mappings that are 
endpoint-dependent if initiated with external-host ports equal to 80 
(HTTP) or in the range 6881-6889 (BitTorrent).

2. To be well behaved, a NAT  MUST do  mappings that are 
endpoint-independent if initiated with external-host ports in the 
1990-1992 range (STUN).

- This range is that of STUN, STUNT and TURN.
- As such, they are AFAIK those of the only IETF approved public address 
and port discovery mechanisms (if not, the rule has to be completed).
- STUN and TURN are used in paricular by ICE, the tool for SIP to 
operate across existing NATS, a major source of sessions needing 
endpoint-independent mapping).
- Note that, after discovery, ANY application, standard or proprietary, 
may use the reserved address&port couple.

3. NATs MAY also do mappings that are endpoint-independent if initiated 
with external-host ports known to be those of applications compatible 
with it (POP3, SMTP, IMAP, NNTP, Telnet, SNMP, IPsec over UDP...)

> Doing it with port numbers would also be the first time 
> 1024 restriction does not change the behavior of TCP itself). 
IMU, there are no more differences between possible TCP behaviors with 
this approach than with NAT traversal (=> neither theoretical nor 
practical problem).

Regards.

Rémi

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 21 May 2008 23:25:01 -0400

Sorry for chiming in late here.

Philip is making a REALLY important point. This has NOTHING to do with 
with endpoint independent vs. endpoint dependent mapping. Iljitsch is 
raising issues about a currently undefined behavior that, frankly, 
fundamentally redefines the assumptions in RFC 4787.

RFC 4787 fundamentally assumes that NATs maintain mapping rules which 
translate one IP address and port to another IP address and port, and 
that this translation is a function ONLY of the address being 
translated. In particular, RFC 4787 assumes that, once a mapping is 
defined, a packet received on the external side of the NAT can be natted 
by looking up the destination IP/port in a table and translating it to 
the associated internal IP/port. Similarly in the reverse direction. 
That is, though the initial assignment of the mapping may be a function 
of the 5-tuple, the actual translation operation performed by the NAT is 
a function of the translated IP address and port ONLY.

What Iljitsch is suggesting is that:

1. this translation can be a function of the full 5-tuple, such that two 
packets received on the external interface, whose destination IP/ports 
are the same, but whose source IP/ports are different, can be mapped to 
different internal IP addresses and ports, and

2. the result is that two internal IP addresses and ports which are 
different can be translated to the same external IP address and port

That kind of behavior does not map to any of the existing mapping rules. 
  Lets look at all of them:

endpoint independent mapping:

          The NAT reuses the port mapping for subsequent packets sent
          from the same internal IP address and port (X:x) to any
          external IP address and port.  Specifically, X1':x1' equals
          X2':x2' for all values of Y2:y2.

This implies that two different internal transport addresses X:x and A:a 
cannot share the same mapping X1':x1'. So endpoint independent mapping 
'rules out' the case Iljitsch is talking about.

address-dependent mapping:

          The NAT reuses the port mapping for subsequent packets sent
          from the same internal IP address and port (X:x) to the same
          external IP address, regardless of the external port.
          Specifically, X1':x1' equals X2':x2' if and only if, Y2 equals
          Y1.

Well, this says nothing at all about the behavior of mappings across two 
different internal IP addresses and ports. Its only talking about the 
mappings from a single internal IP address and port (X:x).

address and port-dependent mapping:

  The NAT reuses the port mapping for subsequent packets sent
          from the same internal IP address and port (X:x) to the same
          external IP address and port while the mapping is still active.
          Specifically, X1':x1' equals X2':x2' if and only if, Y2:y2
          equals Y1:y1.

As above. Says nothing about the mappings as they relate to different IP 
addresses and ports.

So really, the model that is being suggested looks different than the 
figure in the Figure on page 6. Instead, we need to draw a picture that 
looks like this:

   Please view in a fixed-width font such as
                    Courier.

                                              E
           +------+                 +------+  x
           |  Y1  |                 |  Y2  |  t
           +--+---+                 +---+--+  e
              | Y1:y1            Y2:y2  |     r
              +----------+   +----------+     n
                         |   |                a
                 X1':x1' |   | X2':x2'        l
                      +--+---+-+
           ...........|   NAT  |...............
                      +--+---+-+              I
                         |   |                n
                         |   |                t
                         |   |                e
                  +------+   +------+         r
                  |                 |         n
                  |x1               |x2       a
               +-----+           +-----+      l
               | X1  |           | X2  |
               +-----+           +-----+

        From internal to external:

        X1':x1' = f(X1:x1,Y1:y1)
        X2':x2' = f(X2:x2,Y2:y2)

        From external to internal:

        X1:x2 = f(Y1:y1,X1':x1')
        X2:x2 = f(Y2:y2,X2':x2')

Note that, I believe this model would allow for mapping rules to be 
defined which still work well for p2p apps but give you the benefits of 
address and port reuse across different sessions, without needing to 
define rules based on what application is being used.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 May 2008 12:29:11 +0200

Hi,

>               +----------+   +----------+     n
I am not sure i understand how would that be.
I mean, consider the following case (using your figure)
In this case we are reusing the transport address X'1,x'1, as was 
suggested, for both communications

                                              E
           +------+                 +------+  x
           |  Y1  |                 |  Y2  |  t
           +--+---+                 +---+--+  e
              | Y1:y1            Y2:y2  |     r
                 X1':x1' |   | X1':x1'        l

        X1':x1' = f(X1:x1,Y1:y1)
        X1':x1' = f(X2:x2,Y2:y2)

        X1:x2 = f(Y1:y1,X1':x1')
        X2:x2 = f(Y2:y2,X2':x2')

So, now suppose that Y2:y2 wants to send packets toward X1,x1, how would 
he do that?
wouldn't that be a problem for p2p apps?
I mean, if the goal of X1 was to create a mpping so it can later on 
receive incoming communications through X'1,x'1, this would break that, 
right?

Regards, marcelo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 May 2008 17:47:07 -0400

inline:

>> defined which still work well for p2p apps but give you the benefits 
>> of address and port reuse across different sessions, without needing 
>> to define rules based on what application is being used.
>>
>>   

Not if your NAT is also doing address and port restricted filtering.

So lets say, X1 sends to Y1. The NAT assigns the mapping (X1':x1',Y1:y1) 
-> X1:x1. Note that the mapping here now is from the full five tuple. So 
when Y1:y1 sends back, it gets passed to X1:x1. Of course, should Y2:y2 
send to X1':x1', there is no filter (and no mapping) so its dropped.

So now X2 sends to A1. Nat assigns the mapping (X1':x1',A1:a1) -> X2:x2. 
Note that the same external IP/port is assigned, but the mapping is for 
the full five-tuple which includes the target A1:a1.

Now X1 sends to a different host - Y2. The mapping (X1':x1',Y2:y2) is 
not currently assigned, so its assigned to X1:x1. Now, both a mapping 
and a filter are put into place. So now, Y2:y2 can send packets back to 
X1:x1. Note that, this looks EXACTLY like endpoint independent mapping, 
but we have shared the external IP/port across different internal hosts! 
The mapping can be shared and you can have behavior that appears like 
endpoint independent mapping, so long as there is no overlap in the 
TARGET addresses reached by each internal host. Remember, in this model 
of NAT, the peer IP and port is part of the index used to define the 
mapping.

It is true that you cannot guarantee mappings that are endpoint 
independent, but it can be made probabilistic with arbitrarily high 
confidence by trading off mapping reuse. That works extremely well with 
stuff like ICE which don't make assumptions and just work better as the 
percentage of endpoint independent natting increases.

-Jonathan R.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 May 2008 12:00:32 -1000

> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Friday, May 23, 2008 11:47 AM
> To: marcelo bagnulo braun
> Cc: Behave WG; Philip Matthews; Iljitsch van Beijnum

You described ALGO-1 from draft-wing-behave-dynamic-tcp-port-reuse-00.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 24 May 2008 12:34:34 +0200

Jonathan Rosenberg escribió:
>> So, now suppose that Y2:y2 wants to send packets toward X1,x1, how 
>> would he do that?
>> receive incoming communications through X'1,x'1, this would break 
>> that, right?
>

but this is NOT recommended according to the behave requirements, right?
I mean, endpoint independent filters are recommended and if more 
stringent filtering is needed, then address dependent filtering is 
recommended, but never address and port dependent filtering, right?
>
> So lets say, X1 sends to Y1. The NAT assigns the mapping 
> (X1':x1',Y1:y1) -> X1:x1. Note that the mapping here now is from the 
> full five tuple. So when Y1:y1 sends back, it gets passed to X1:x1. Of 
> course, should Y2:y2 send to X1':x1', there is no filter (and no 
> mapping) so its dropped.
>
> So now X2 sends to A1. Nat assigns the mapping (X1':x1',A1:a1) -> 
> X2:x2. Note that the same external IP/port is assigned, but the 
> mapping is for the full five-tuple which includes the target A1:a1.
>
> and a filter are put into place. So now, Y2:y2 can send packets back 
> to X1:x1. Note that, this looks EXACTLY like endpoint independent 
> mapping, but we have shared the external IP/port across different 
> internal hosts! 
> TARGET addresses reached by each internal host. 

right, but having the same target host doesn't seems to be a rare 
situation... imagine the target is google.com at port 80

So with this scheme, you can achieve something similar to endpoint 
indepednet mapping with address and port filtering as long as the target 
transport addresses don't collide.

My concerns are:
- target addresses are very likely to collide
- address and port filtering is not recommended by behave requirements 
and both recommended behaviours, i.e. endpoint independent filtering and 
address dependent filtering cannot be achieved

am i missing something?

> Remember, in this model of NAT, the peer IP and port is part of the 
> index used to define the mapping.
>
> confidence by trading off mapping reuse. 

that i don't understand... what do you mean that you can make it 
probabilistic with arbitrarily high confidence? You mean that you assume 
a uniform distribution of the target transport addresses?

> That works extremely well with stuff like ICE which don't make 
> assumptions and just work better as the percentage of endpoint 
> independent natting increases.
>
right, but as i see it, there are two different efforts being done in 
the nat world. One is to have tools like ICE which work no matter how 
bad is the nat behaviour and the other one is to try to get nats to 
behave in a reasonable way.

I understand that this discussion belongs to th first kind of effort, 
where we try to make nats behave reasonably

Regards, marcelo

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 26 May 2008 09:29:14 +0300

> recommended, but never address and port dependent filtering, right?

In real life, there are a number of applications still using "legacy" STUN or 
similar techniques, i.e. unilateral NAT traversal. ICE is bilateral, 
but/hence a lot trickier and invasive to implement.

It would be a mistake to assume that everything will use ICE. In fact, support 
for legacy applications is one of the use-case for protocol translation, is 
it not?

(...)
> - target addresses are very likely to collide

Yep. Many clients may likely have many AJAX-et-al connections to the same 
GMail IP:port each. I think there is no way around it, without changing how 
TCP works. In other words, the number of concurrent connections per NAT IP 
addresses times NAT ports to a single (web)server is a ONE. No matter what 
algorithm you are using for port allocation.

> address dependent filtering cannot be achieved

BEHAVE does NOT recommend which _filtering_ to use. Independent filtering is 
recommended _if_ application-transparency is to be favored.