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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf