ietf
[Top] [All Lists]

Re: the evilness of NAT-PT, was: chicago IETF IPv6 connectivity

2007-07-05 09:38:06
On 2-jul-2007, at 22:38, 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.

Sorry, I have to disagree. Realistic thinking is when there is a messy solution, you create a non-messy solution first before killing the messy one.

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.

...with no end in sight.

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.

Well, that depends. I grant you that this is certainly something that _could_ happen. The risk here is that if we provide something relatively simple that works for a relatively limited set of applications/protocols, people will want to apply this mechanism to additional applications/protocols, and then the trouble starts. But is not having the mechanism in the first place the best solution to avoid this?

There are basically two types of applications/protocols: the simple client/server ones (that work through NAT without changes) and anything else that's more complex. In my opinion, it would be a huge win to allow the former to work through some kind of IPv6-IPv4 translation because then all the hosts that only use these types of applications don't need IPv4 anymore and life becomes simple for the people who need to manage these hosts. The solution for hosts that need to do more complex stuff all the time is obvious: those need an IPv4 address.

This leaves the case of hosts who need to run more complex stuff some of the time unaddressed. I think some sort of IPv4 address leasing tunneled over IPv6 would work here. This has a number of advantages:

- the host has an actual IPv4 address, so no weirdness because the two ends see different IP versions (avoiding NAT for the IPv4 part is left as an exercise for the reader) - the IPv4 address is only used when needed so the number of addresses is much smaller than with traditional IPv4 provisioning (more like dial-up) - there is no need to subnet, the IPv4 addresses can be used individually (also like dial-up)

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.

http://www.ietf.org/internet-drafts/draft-van-beijnum-v6ops-connect- method-00.txt

Iljitsch

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