[arin-ppml] IPv6 adoption, map-encap for IPv4?

[Paul Vixie]

robin, you wrote, in response to dan:

> IPv6 may well be widely adopted at some time.  I just think the
> transition arrangements are a shambles and that it is a very long
> way from being widely adopted.  ...

nobody anywhere will disagree with that summary.  without intending to pile
on, or to blame bob hinden personally, i have several times now referenced
<http://playground.sun.com/ipv6/INET-IPng-Paper.html> which summarized the
reasons ipNG (ipv6 as we know it today) won the beauty contest even though
a lot of people were saying things like "too little, too soon" (tony li).  i
call your attention to this little gem in section 11 (transition mechanisms):

	The key transition objective is to allow IPv6 and IPv4 hosts to
	interoperate. A second objective is to allow IPv6 hosts and routers to
	be deployed in the Internet in a highly diffuse and incremental
	fashion, with few interdependencies. A third objective is that the
	transition should be as easy as possible for end- users, system
	administrators, and network operators to understand and carry out.

	...

	The IPng transition mechanisms ensures that IPv6 hosts can
	interoperate with IPv4 hosts anywhere in the Internet up until the
	time when IPv4 addresses run out, and allows IPv6 and IPv4 hosts
	within a limited scope to interoperate indefinitely after that. This
	feature protects the huge investment users have made in IPv4 and
	ensures that IPv6 does not render IPv4 obsolete. Hosts that need only
	a limited connectivity range (e.g., printers) need never be upgraded
	to IPv6.

	The incremental upgrade features of the IPng transition mechanisms
	allow the host and router vendors to integrate IPv6 into their product
	lines at their own pace, and allows the end users and network
	operators to deploy IPng on their own schedules.

had these statements been accurate, there would be no debate today about the
inevitability of ipv6, it wouldn't even be controversial.  but since there is
effectively no transition mechanism whose attributes are anything like those
described above, and since ipv6 likewise failed to address the real shortage
of global routing table slots, what we have is "ip with more address bits"
that makes the problems we already had in 1995 even worse, and only solving
a problem which in 1995 we did not have, and providing no soft or rolling
transition mechanism such that the cutover is massive, expensive, and painful.

however, general agreement on this point doesn't extend to your conclusion:

>                             ... I think the chicken and egg problem
> is far to big and that there is great scope for keeping most
> customers on IPv4, albeit in an increasingly ugly way if it involves
> less capable or multi-layer NAT.

with all respect to tony ("too little, too soon") li, it's no longer too soon
even though in 1995 it clearly was.  and while it may still be "too little",
it's what we've got, and we finally have the only problem ipv6 solves, and we
have several lurching, squeaking, bumpy ways to do dual-stack with IPv4-NAT
and IPv6-native, and since so many of us (even those who disliked the approach
taken in ipv6) qwest for a return to native end-to-end IP... we're moving
onward.  simply put, i do not expect you to get any kind of traction on a
plan that involves more ALG or NAT or IPv4.  that ship has already sunk.

paul