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@xxxxxxxxxxxx] > Sent: Monday, July 16, 2007 12:02 PM > To: Hallam-Baker, Phillip; Hannes Tschofenig; Brian E Carpenter > Cc: Melinda Shore; ietf@xxxxxxxx > 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf