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