Subject: Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Jul 2007 03:29:54 -0700

The way I look at the problem we have a gateway issue similar to those that we used to have with smtp in the days of decnet sna etc.

The only difference is that we have both sides of the gateway running IP albeit with different numbering schemes.

So terminating the application session at layer 7 and then originating a fresh one at the point where the numbering scheme changes appears to me to be a simple and principled approach.

Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From: 	Hannes Tschofenig [mailto:[email-masked]]
Sent:	Monday, July 16, 2007 01:30 AM Pacific Standard Time
To:	Brian E Carpenter
Cc:	Melinda Shore; [email-masked]
Subject:	Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 transition

Hi Brian,

regarding lack of simplicity: Different solutions build on different 
assumptions. If you make specific assumptions then the solution is much 
simpler.

There is a recent document that aims to compare some of the NAT / 
firewall protocol proposals:
http://www.ietf.org/internet-drafts/draft-eggert-middlebox-control-survey-01.txt

It is not yet finished but might give you an idea what the different 
assumptions of some of the proposals are.

Ciao
Hannes

Brian E Carpenter wrote:
> On 2007-07-14 00:07, Melinda Shore wrote:
>> On 7/13/07 5:43 PM, "[email-masked]" <[email-masked]> 
>> wrote:
>>> I believe that we need a more general protocol for hosts inside a site
>>> perimeter to communicate with the perimeter gateways and request
>>> services from them.
>>
>> We've actually got several of them, starting with SOCKS (which
>> could have been extended), continuing through RSIP, on to midcom
>> and SIMCO.  Note that "midcom" was so named under the assumption
>> that whatever was done would be extensible to other sorts of
>> middleboxes than firewalls and NATs
>>
>> We could spend an awful lot of time talking about why none
>> of them has caught on, but I think it's fair to say that that
>> failure has not been caused by a perceived lack of generality.
>
> Maybe by a lack of simplicity?
>
> draft-woodyatt-ald-01 is a recent proposal.
>
>     Brian
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jul 2007 13:27:25 +0200

Many SBC vendors would agree with your assessment. They would then add a 
list of the other advantages for putting application layer functionality 
into the network.
The problems of this approach are, however, well-known. Hence, I would 
like to avoid them by decoupling the two interactions.

Ciao
Hannes

---

From: Melinda Shore <[email-masked]>
Date: Mon, 16 Jul 2007 07:56:37 -0400

On 7/16/07 6:29 AM, "Hallam-Baker, Phillip" <[email-masked]> wrote:
> The way I look at the problem we have a gateway issue similar to those that we
> used to have with smtp in the days of decnet sna etc.

Maybe, but there are differences that make it harder.  Chief
among these is that there were one or two gateways for CSNet,
a handful for BITNET, and so on, and there was just the one
application.  Furthermore, there was no need to either modify
the endpoint or inform the endpoint that it should gateway
its email through a particular host.  The latter was handled
on the server.  

Melinda

---

From: Dave Cridland <[email-masked]>
Date: Mon, 16 Jul 2007 14:49:54 +0100

On Mon Jul 16 11:29:54 2007, Hallam-Baker, Phillip wrote:
> The way I look at the problem we have a gateway issue similar to 
> those that we used to have with smtp in the days of decnet sna etc.
> 
> The only difference is that we have both sides of the gateway 
> running IP albeit with different numbering schemes.

If I read this correctly, you're essentially stating that the 
Internet terminates at the ISP side of the NAT. So hosts located on 
the "wrong" side of the NAT are simply not part of the Internet - 
they merely happen to use the same technology.

Is that a correct paraphrase of what you're saying? That does strikes 
me as a fundamental failing of NATs if so.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 16 Jul 2007 07:43:15 -0700

> its email through a particular host.  The latter was handled

Widespread deployment of ALG's as mediators means you have to upgrade
the network to support new applications. or applications are built on
top of hostile tunnels over your alg infrastructure (sound familiar?).
While some enterprise networks seem to favor this, it's not really the
Internet.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 16 Jul 2007 11:04:47 -0400

> While some enterprise networks seem to favor this, it's not really the

At some point a lot of these things tend to look awfully
similar to one another (NATs look like tunnel endpoints look
like relays, etc.) but they tend to break out into broad
categories.  So, you have some mechanisms that operate at
the network layer and some that operate at the session or
application layer.  The lower in the stack they sit the
more general they can be, clearly, but then you tend to
encounter more problems around reachability and findability.

Melinda

---

From: Ted Hardie <[email-masked]>
Date: Mon, 16 Jul 2007 09:02:16 -0700

>So terminating the application session at layer 7 and then originating a fresh one at the point where the numbering scheme changes appears to me to be a simple and principled approach.

There are two ways I can read this, and I suspect I've got them both wrong.  The
first is the "flag day" meaning for "where the numbering scheme changes"--that is,
re-deploy all applications on some day at which we decide the numbering scheme
changes.  The second is that you mean that any device which serves as an
intersection point between v4 and v6 must also serve as a back-to-back user
agent for all applications that run across it.

That is, for the scenario

v6-endpoint---[boundary]--v4 segment---[boundary]--v6-endpoint

there would be a full-on termination of the application at each boundary,
and a new application flow, which is itself not guaranteed to reach the original
destination of the flow. 

Is either of those what you meant?  If not, can you clarify?

			thanks,
					Ted Hardie

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Jul 2007 19:46:07 -0700

What I was proposing was closer to the second.

>From my (no doubt incorrect as far as layer 4 folk are concerned) point of view the 'Internet' is defined by consistency of the name space, not the address space. So a user is on the Internet if they are in a situation where the machine they are using resolves a DNS name in a manner that is consistent with the result they would get at any other point that is by mutual consensus considered to be 'the Internet'.

As far as a user is concerned they should no more know or care about the value of their IP address or which particular numbering space that is is in than they would the SS7 termination number for their telephone service - provided that they receive the service they expect.

In my view of Internet architecture the inter-network is not a network, it is a network of networks. A host machine is never on the Internet, only a network (or at a higher level of abstraction a user) can be on the Internet. Even though you may have IPv4 run to the host the host is still on the network, not the Internet.

Obviously the easiest way to achieve this is for the address space to be consistent and universal. In the pure IPv6 world this is entirely practical. In the IPv4 world the fact is that we are running out of addresses and will shortly have to begin rationing them in some fashion. If we refuse to the market will ration them in a fashion that is both unpredictable and less likely to be to our liking.

I think that if we get SIP right we can ration the pool of IPv4 addresses in such a way that nobody is inconvenienced. All we need to do is to be a little carefull in protocol design. 

I don't see any reason to get bent out of shape about rationing IPv4 addresses, the IPv4 Internet is going to go away. If someone is going to design a new protocol for IPv4 they need to deal with the IP address rationing that will soon become the norm. If they can't deal with that they need to layer on IPv6 instead.

There are essentially three classes of network actor: client, server and peer. In any given interaction there is always an initiator and a responder. In most cases these correspond to the client and the server. In a peer-to-peer application a given machine may be either an initiator or a responder.

Except in rare situations (e.g. FTP) NAT does not cause problems when the initiator of the communication is behind a NAT. The problem with NAT comes when the responder is behind a NAT. When the message hits a NAT box it needs to know where to forward the packet. 

Now lets look at what the typical consumer does and does not want to put on the Internet. They do want to run peer-to-peer applications. They do want to run client applications such as the Web. Very few want to host servers and many explicitly do not want the inherent exposure that opening a server port entails.

I think that 95% of consumers would be more than happy with a solution that only gives them client and peer-to-peer on IPv4 but does so reliably and robustly. If we can satisfy those users needs with the 50% of the IPv4 address space that gives us the other 50% of the address space to meet the needs of the other 5%.

Don't think of it as NAT, think of it as a specialized form of IP header compression within a network that just happens to map IPv6 space to a 32 bit address space that may or may not be the IANA regulated one.

> From: Ted Hardie [mailto:[email-masked]] 
> Sent: Monday, July 16, 2007 12:02 PM
> To: Hallam-Baker, Phillip; Hannes Tschofenig; Brian E Carpenter
> >So terminating the application session at layer 7 and then 
> originating a fresh one at the point where the numbering 
> scheme changes appears to me to be a simple and principled approach.
> >
> 
> There are two ways I can read this, and I suspect I've got 
> them both wrong.  The first is the "flag day" meaning for 
> "where the numbering scheme changes"--that is, re-deploy all 
> applications on some day at which we decide the numbering 
> scheme changes.  The second is that you mean that any device 
> which serves as an intersection point between v4 and v6 must 
> also serve as a back-to-back user agent for all applications 
> that run across it.
> 
> there would be a full-on termination of the application at 
> each boundary, and a new application flow, which is itself 
> not guaranteed to reach the original destination of the flow. 
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 17 Jul 2007 21:33:04 -0700

>There are essentially three classes of network actor: client, server and peer. In any given interaction there is always an initiator and a responder. In most cases these correspond to the client and…

As you imply, at the IP layer the few in common use are: unicast flow initiator,
unicast flow destination, and multicast group (anycast in the typical use being a
mechanism to select which instance will be the unicast destination for a specific flow).
The difference between "peer" and "server" as unicast flow destination is zero.

Unless you mean peer in some specific sense, like a participant in a DHT-based
overlay topology, as the sip p2p working group is aiming for?  If so, is there
something about the overlay traversal that you believe will affect the v4
distribution? (At the moment that group is discussing reusing mechanisms
like ICE and STUN for setting up the traversal in the presence of NATs).

>Now lets look at what the typical consumer does and does not want to put on the Internet. They do want to run peer-to-peer applications. They do want to run client applications such as the Web. Very…

First, I think making judgements about what the typical consumer will want in
the future based on the existing situation is pretty limiting, if not downright likely
to crack your crystal ball.  Aside from "more and cheaper", few such predictions
are likely to be right.

I also think by making the distinction "server port" you are going past what the typical
consumer wants or understands.  If a company provides a mechanism that allows
them to do X in some environments but not in others, it will be perceived as a
flaw.  The music sharing built into iTunes is a case in point.  It provides
a mechanism that allows people to stream music from their collection to some
set of other people.   The restrictions to a subnet were, from the lay perspective,
perceived as just so much jargon.  You and I may recognize that making
the connection work through two NATs  is non-trivial, but the "typical consumer"
doesn't in my limited experience seem to know or care.  They want X to work,
and they don't see X in boxes like "client/server, peer, other".

> If we can satisfy those users needs with the 50% of the IPv4 address space that gives us the other 50% of the address space to meet the needs of the other 5%.

I guess I missed the how of this, in a world where peers routinely want to open
unicast flows to a potentially unbounded set of destinations (other peers). 
Or do you believe the peer network mechanisms at hand (like using public-IP
peers as "supernodes") scale well enough to make this work?
>Don't think of it as NAT, think of it as a specialized form of IP header compression within a network that just happens to map IPv6 space to a 32 bit address space that may or may not be the IANA re…

You had mentioned that your vision was closer to the second scenario I put forward.
That scenario was

The second is that you mean that any device
> also serve as a back-to-back user agent for all applications

That seems to me a good bit more than specialized header compression.

					Ted Hardie

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Jul 2007 23:09:15 -0700

> >There are essentially three classes of network actor: 
> client, server and peer. In any given interaction there is 
> always an initiator and a responder. In most cases these 
> correspond to the client and the server. In a peer-to-peer 
> application a given machine may be either an initiator or a responder.
> 
> As you imply, at the IP layer the few in common use are: 
> unicast flow initiator, unicast flow destination, and 
> multicast group (anycast in the typical use being a mechanism 
> to select which instance will be the unicast destination for 
> a specific flow).

It is as far as the network layer is concerned.

A client server interaction is mediated through the DNS exclusively.

A peer-peer interaction is typically mediated through DNS and a broker in combination. In the case of peer-to-peer messaging that is through SIP.

> Unless you mean peer in some specific sense, like a 
> participant in a DHT-based overlay topology, as the sip p2p 
> working group is aiming for?  If so, is there something about 
> the overlay traversal that you believe will affect the v4 
> distribution? (At the moment that group is discussing reusing 
> mechanisms like ICE and STUN for setting up the traversal in 
> the presence of NATs).

That is a logical approach if you assume that the NAT people insist that the net work around them.

But the NAT folk are more than willing to meet in the middle. There is a potential win-win here. The NAT folk can avoid the need to continue to build in work-arrounds into their product and application designers can build to something that can be expected to work interoperably.

All we need to do is to make the NAT a little less unpredictable.

> >
> >Now lets look at what the typical consumer does and does not 
> want to put on the Internet. They do want to run peer-to-peer 
> applications. They do want to run client applications such as 
> the Web. Very few want to host servers and many explicitly do 
> not want the inherent exposure that opening a server port entails.
> 
> First, I think making judgements about what the typical 
> consumer will want in the future based on the existing 
> situation is pretty limiting, if not downright likely to 
> crack your crystal ball.  Aside from "more and cheaper", few 
> such predictions are likely to be right.

Such predictions only need to hold until we arrive at the world of IPv6.

> I also think by making the distinction "server port" you are 
> going past what the typical consumer wants or understands.  
> If a company provides a mechanism that allows them to do X in 
> some environments but not in others, it will be perceived as 
> a flaw.  The music sharing built into iTunes is a case in 
> point.  It provides a mechanism that allows people to stream 
> music from their collection to some
> perceived as just so much jargon.  You and I may recognize 
> that making the connection work through two NATs  is 
> non-trivial, but the "typical consumer"
> doesn't in my limited experience seem to know or care.  They 
> want X to work, and they don't see X in boxes like 
> "client/server, peer, other".

Exactly, there must be a branding regime so that a consumer knows that if his NAT box has the 'It Just Works' brand that they are assured that it will just work with Itunes etc.

If you are a consumer trying to figure out why their videocam software won't work you are going to have a pretty ugly experience today. Even if you know about the basic networking concepts you will find it pretty difficult with most of the consumer oriented client to find information on the ports the protocol expects to be able to use.

> 
> > If we can satisfy those users needs with the 50% of the 
> IPv4 address space that gives us the other 50% of the address 
> space to meet the needs of the other 5%.
> 
> I guess I missed the how of this, in a world where peers 
> routinely want to open unicast flows to a potentially 
> unbounded set of destinations (other peers). 
> Or do you believe the peer network mechanisms at hand (like 
> using public-IP peers as "supernodes") scale well enough to 
> make this work?

I would certainly like to avoid the set of schemes that work around NAT by routing all traffic through a nearby node that has unrestricted connectivity. Alice calls Bob and it is routed through Carol's machine. Ugh!

Alice should be able to call Bob and the data packets travel directly from Alice to Bob even when Bob is behind a NAT. That is possible even with IP address pooling, all that is necessary is to configure the systems in such a way that Bob can advertise an IP address and port number in Internet IPv4 address space that will route to the port his peer is listening to in his NAT'ed address space.

> > which serves as an intersection point between v4 and v6 must also 
> > serve as a back-to-back user agent for all applications that run 
> > across it.
> 

It might not be necessary to go to that level. I do think that the NAT box has to be at least reporting its behavior at the application level. Having it act as SIP proxy might not be the best way to do that.