Iljitsch van Beijnum wrote:
On 1-jul-2007, at 18:46, Keith Moore wrote:
NAT-PT really needs to be wiped off the face of the earth. It provides
all of the disadvantages of IPv4+NAT with all of the transition costs of
IPv6. If there is ever any significant penetration of NAT-PT, then the
pseudo-IPv6 network will not be able to support any more kinds of
applications than the NATted IPv4 does today.
First of all, this is the worst kind of ivory tower thinking.
uh, no. it's realistic thinking. I've written distributed applications
before and after NAT, and the amount of additional complexity and
infrastructure required for such an application to function and scale in
the presence of NAT is staggering. the presence of NATs in the v4
Internet has held back application development for around 10 years now.
How am I supposed to run IPv6 and access the IPv4 world without a
mechanism like NAT-PT?
There are solutions for corner cases that involve address translation.
For instance, if you have a legacy IPv4-only device, say a printer, and
you want IPv6-only hosts to be able to access it, you can put a device
in the signal path that translates between IPv6 and IPv4 and vice
versa. It will look a lot like a NAT-PT box. The difference is that
it's not a general purpose solution. It only works for specific
applications that don't attach any significance to addresses. But as
soon as you start trying to front an entire network with such a box,
you've killed the ability of that network to support certain kinds of
applications. And if such devices get widely deployed in such a manner,
then the IPv6 network becomes just as crippled as the IPv4 network has
become.
Similarly if you are on an IPv6-only network and you want to make some
services accessible to IPv4, you can set up a tunnel between a specific
application and a point of presence on the IPv4 network. Something like
NAT-PT works in some cases, in other cases an application-specific proxy
or a SOCKS-like protocol work better. But even if the NAT-PT like
approach is used it's not a general solution, it's something that is set
up for a particular application on a particular host and port based on
knowledge of the specific needs of that application.
Killing that without providing an alternative was a very bad move that
will come back to haunt the IETF. (And although the problems with
NAT-PT are real, they're not THAT bad.)
Disagree. All of the documentation that IETF has done on the problems
with NAT only scratches the surface. And NAT-PT is worse than NAT,
because it promotes use of two-faced DNS which has its own set of evils
that are approximately as bad as those for NAT.
And you're wrong, too. With NAT-PT and a DNS ALG in effect, you have
NAT-incumbered access to the IPv4 world, which is not good because
IPv6 stuff isn't built to work with NAT. But at least you have access
to the IPv4 world. But your access to the IPv6 world is completely
trouble free, which is the point.
no it's not, because that assumes that a host or an application is
either purely IPv4 or IPv6, and it assumes that DNS results from IPv4
queries don't get exposed to IPv6-aware apps. neither of those is true.
The following draft should appear in due course (it's only 4 pages):
http://www.muada.com/drafts/draft-van-beijnum-v6ops-connect-method-00.txt
I'll look for it.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf