[137149] in North American Network Operators' Group
IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Wed Feb 9 16:38:38 2011
From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <AANLkTikzN8GTzcPLvprWZmDJj5DuFKW35GPssLwNjaCC@mail.gmail.com>
Date: Wed, 9 Feb 2011 22:35:59 +0100
To: William Herrin <bill@herrin.us>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 9 feb 2011, at 21:26, William Herrin wrote:
>> You're kidding, right? How long did it take exactly to get where
>> we are now with IPv6? 18, 19 years?
> Tech like carrier NAT theoretically yeilds address reclamation in
> excess of 80%.
Most IPv4 space is unused anyway, but it's not being reclaimed much =
despite that. (How many IP addresses does the US federal government =
need? Few people would think ~ 10 /8s. Especially since many of them =
aren't even lit up.)
>>> * Next protocol should really be designed to support =
interoperability
>>> with the old one from the bottom up. IPv6 does not
>> That's because it's not the headers that aren't incompatible (the
>> protocol translation is ok even though it could have been a bit
>> better) but the addresses.
> No, it's because decisions were made to try to abandon the old DFZ
> table along with IPv4 and institute /64 as a standard subnet mask. But
> for those choices, you could directly translate the IPv4 and IPv6
> headers back and forth, at least until one of the addresses topped 32
> bits. The transition to IPv6 could be little different than the
> transition to 32-bit AS numbers -- a nuisance, not a crisis. You
> recompile your software with the new IN_ADDR size and add IP header
> translation to the routers, but there's no configuration change, no
> new commands to learn, etc.
It's not that simple. But I agree on one thing: it could have been =
better.
What needs to be done to move from IPv4 to IPv6 is three things:
1. the headers
2. the addresses
3. the applications
Today, only IPv6 applications can use IPv6 addresses and only when IPv6 =
applications use IPv6 addresses will there be IPv6 headers. It would =
have been better to roll out the headers first. That would have meant =
changes to routers, because routers touch the headers. But if =
translating between IPv6 with 32-bit addresses and IPv4 can be done with =
low overhead (which is more or less the case today, BTW) then it would =
have been possible to upgrade from IPv4 to IPv6 subnet by subnet. This =
way, there wouldn't have had to be any dual stack, and once people had =
deployed IPv6 they would have kept using it. Today, and especially some =
years ago, IPv6 would/will often atrophy after having been deployed =
initially because of lack of use.
Apps could have been upgraded the same way they have now, with the only =
difference that using an IPv4-mapped IPv6 address meant generating an =
IPv6 packet, not an IPv4 packet as is done today. Once 128-bit addresses =
are being used going from an IPv6 subnet to an IPv4 subnet becomes =
problematic, but this can be solved with stateful translation so most =
stuff keeps working anyway. And remember, servers and apps that can't =
work through a stateful translator can still get 32-bit addresses so =
everything keeps working without trouble.
However, it's easy to come up with all of this in 2011. In 1993 the =
world was very different, and many things we take for granted today were =
still open questions then. It's very illuminating to read up on the =
mailinglist discussions from back then. People complained about IPv6 a =
decade or half a decade ago, too. Back then there may have been a chance =
to come up with a different protocol as a successor for IPv4, but it's =
way too late for that now.
Anyway, most non-legacy applications support 128-bit addresses now and =
we have a pretty decent NAT64 spec sitting in the RFC editor queue (even =
if I do say so myself) so it's just a matter of sitting tight until =
we're through the painful part of the transition.=
