ietf
[Top] [All Lists]

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

2007-07-17 19:48:56
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.


-----Original Message-----
From: Ted Hardie [mailto:hardie(_at_)qualcomm(_dot_)com] 
Sent: Monday, July 16, 2007 12:02 PM
To: Hallam-Baker, Phillip; Hannes Tschofenig; Brian E Carpenter
Cc: Melinda Shore; ietf(_at_)ietf(_dot_)org
Subject: Re: The myth of NAT traversal, was: Re: IPv4 to IPv6 
transition

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


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf