
IPv6 non-alternatives: DJB's article, 13 years later - teddyh
https://blog.sesse.net/blog/tech/2016-01-06-20-54_ipv6_non_alternatives_djbs_article_13_years_later.html
======
geocar
> you still need to upgrade all software on the planet and all routers on the
> planet.

No, you don't. The biggest benefit to using IPv4 as the routing-infrastructure
and extra bits (maybe an IP option) to describe the host is that most of the
Internet (routers, etc) don't need to get upgraded, only hosts. Routers don't
normally mess with the packets so only the first/last wifi/switch actually
need upgrading. This is a small number of devices (certainly much smaller than
all!).

There could be a few routers that lose the option, and one option is to just
fix _those_ routers (still a much smaller number than _all_ routers), but
another option is to rely on connection tracking only when the service is
behind such a router. The ubiquity of UPNP suggests this path would have
worked just fine.

NAT gives us a 32-bit port number pair, which requires memory, makes denial-
of-service attacks easier, and is complicated. An IP option means that the
hosts track the connection themselves.

Another option would be to move port numbers into DNS. This might've been
simple (48-bit addresses are pretty big), and only affected new services. We
upgraded all of the webservers and web browsers faster than IPv6 deployed, so
this probably would have just been a simple matter of mothballing IANA.

However, I worry we're not actually arguing about what we think someone a
decade (or two) ago thought could be the direction to talk about solving a
problem.

IPv6 is the biggest deploy attempted on the Internet, and it's been miserable.
We should be talking about its failings, its mistakes, and how we could do
better knowing what we learned, not patting ourselves on the back for doing
the best we could've done knowing what we knew. IPv6 might be inevitable at
this point, but that doesn't mean it was right.

~~~
lmm
> No, you don't. The biggest benefit to using IPv4 as the routing-
> infrastructure and extra bits (maybe an IP option) to describe the host is
> that most of the Internet (routers, etc) don't need to get upgraded, only
> hosts. Routers don't normally mess with the packets so only the first/last
> wifi/switch actually need upgrading. This is a small number of devices
> (certainly much smaller than all!).

That's the "BangIP" option discussed in the second half of the article and has
all the problems discussed there (e.g. it makes multihoming more-or-less
impossible)

~~~
geocar
Multihoming (PI) isn't impossible but it certainly requires more work. I'm not
yet convinced to throw the baby out with the bath water.

Multihoming is also not the normal case: for a long time ARIN refused to make
IPv6 PI allocations to existing IPv4 PI.

------
ctstover
I for one think the more incompatible V4 and V6 are the better! There are only
two things that ever made any sense: 1) try as hard as possible to be fully
inter-operable with each other, or 2) full clean break. Clearly, there was
never a 100% consensus on the goal. As is now, I see it as a chance to start
over with so many silly things (ie, 12 layers of NAT for everything in the
cloud). When you look at all the gripping about problems, it's so much of a
better pitch to think of it as this new global network to play with that opens
more doors instead of some never-going-to-happen retrofit from hell.

~~~
scurvy
Seconded. IPv6 brings a lot of nice things that we never would have had in an
IPv4 based or extended world. Router fragmentation? Gone! Simple subnetting?
Hello ipv6! DHCP? Gone (mostly)! Link local addresses? Got em!

These are all positive things we wouldn't have if we were still clinging to
IPv4.

------
maw
_From what I can see, he also readily admits that IPv4 and IPv4+ hosts cannot
talk to each other, or more clearly, we cannot start using the extended
address space before almost everybody has IPv4+ capable software._

I don't know whether to respond to that with "what?" or "yeah, so what?" but
I'm leaning toward the former. IPv4 and IPv4+ hosts would communicate with
each other, but IPv4 would only be able to communicate with the overlapping
range of IPv4+.

Addresses in this range would have initially been relatively valuable but
their value would be expected to decrease over time as more hosts started
working over IPv4+.

I think djb was right, but obviously we're unlikely to ever find out.

~~~
ambrice
"what"? Since you have a multiple IPv4+ hosts with the same IPv4 address, how
would an IPv4 host communicate with an IPv4+ host?

~~~
maw
The idea of multiple IPv4+ hosts with the same IPv4 address doesn't come into
it at all. (Questions of proxying in its various forms aren't really
relevant.) So, to answer your question: it wouldn't.

~~~
ambrice
What does proxying have to do with it? One of us is terribly misunderstanding
the concept. As I understand IPv4+ concept in this article, your router gets
address 1.2.3.4 then every device behind it gets 1.2.3.4.0.0.0.1, etc. That
way all the routers in between don't need to be upgraded, they just get the
packets to your router and don't care about the extra address bytes, and your
router gets them to a particular device. Which is great for routers in the
middle, but your web browser still has to use IPv4 and NAT workarounds until
all the web servers are upgraded to support IPv4+.

~~~
maw
_As I understand IPv4+ concept in this article, your router gets address
1.2.3.4 then every device behind it gets 1.2.3.4.0.0.0.1, etc._

This is the bit that wasn't in djb's original article AFAIR. My take was that
1.2.3.4 and 1.2.3.4.0.0.0.1 would be the same machine -- or at least allocated
to the same entity.

------
xaduha
IPv6 will get there eventually, there's no immediate need for it to happen
overnight, obviously.

~~~
solidangle
Indeed, at some point the situation with IPv4 will become so grave that it
will become impossible to ignore IPv6. Transitioning to something like BangIP
might be much easier, but it will be impossible to force people to adopt it,
which will only lead to fragmentation. IPv6 might cause massive fragmentation
on the internet right now, but once the IPv6 gets closer to 100% we can start
dismantling the IPv4 infrastructure, which will force the remaining few to
switch to IPv6. There's no way to do that with BangIP, as it involves keeping
the IPv4 infrastructure intact, which will allow people to continue browsing a
large part of the web and thus there will be little to no reason for a lot of
people to switch to BangIP. In the end IPv6 will be a much better solution
than BangIP.

~~~
cpeterso
> once the IPv6 gets closer to 100% we can start dismantling the IPv4
> infrastructure

It's taken 20 years for IPv6 to get to 10%. In another 20 years (2036), will
IPv6 be at 20%, 100%, or 0% (superseded by something else)?

~~~
Arnt
Nah. IPv6 didn't really start to get going until v4 exhaustion approached, so
20 years is an overestimate.

v4 will die when the routing table becomes too filtered and/or the number of
unreliable tunnels grows too large. You may remember how unpleasant v6 was
around 2005 with all the flaky tunnels. v4 may well be like that by 2020 if
address trading causes many long-prefix v4 routes.

Being yesterday's technology _and_ unreliable has a poor prognosis.

------
jerf
The real reason why IPv6 has been so slow to get deployed is precisely that
you can _not_ just take an IPv4-using program and network, fix all the structs
and API calls, and have an IPv6 program. This is a sideshow compared to the
real problem. IPv6 is profoundly different in _all sorts of ways_. Yes, if you
just want to open a TCP connection to a remote system you can use an IPv6
address instead of an IPv4 address and the resulting socket is _usually_
essentially identical (it isn't necessarily but the differences often don't
matter for the simple common case), but _almost everything else changes_.
"DHCP" changes. Vast new rules about all the classes of IPv6 addresses, and
all network hardware needs to implement _new_ code to handle all that. IPv6
addresses are _much_ more complicated than IPv4 addresses.

In fact probably most of the people reading this only _think_ they know what
an IPv6 address is... based on my experience with people who think they know
what IPv6 is, most are wrong. Do you know what the "link local" portion of the
address is off the top of your head? Do you know what an % sign in the IPv6
address signifies? (This being HN, of course a few thousand of you do; you
don't need to prove that in a reply. But I bet the majority of people reading
this do not.)

Just look at this page:
[https://en.wikipedia.org/wiki/IPv6_address](https://en.wikipedia.org/wiki/IPv6_address)

By contrast, I can't link you to the "Wikipedia page on IPv4 addresses",
because _it doesn 't rate its own page_. It just gets rolled into a single
section on the IPv4 page in general:
[https://en.wikipedia.org/wiki/IPv4#Addressing](https://en.wikipedia.org/wiki/IPv4#Addressing)

And that's _just_ addresses. There's huge swathes of other changes that
require huge amounts of new code to be added to all network devices.

IPv6 isn't a failure (inasmuch as we really should have been done by now)
because it requires a total upgrade of all network devices. Probably the vast
bulk of critical devices have been upgraded in the time since IPv6 was first
standardized. IPv6 was a failure because it also immensely complicated the
network protocol and code did not just have to be "slightly modified" to work,
but torn down and replaced with a much larger and more complicated chunk of
code. IPv6 is _not_ "just" IPv4 with bigger addresses. IPv6 doesn't fail to
interoperate with IPv4 because of trivial networking issues, IPv6 fails to
interoperate with IPv4 because it's a _wildly different network stack_ that
happens to offer similar enough TCP-like abstractions that user-level code
often is only slightly affected, but everything else in the stack is
profoundly affected.

The advantage of the "just extend it" plan is that it _would_ have been that
easy. Perhaps a judicious application of a few solutions to the worst IPv4
problems could have been added. But IPv6 is the technical equivalent of an
appropriations bill in the US Congress. We have to do this, so let's take this
opportunity to stuff every wish-list item in there we can. We didn't have to
do _that_.

In a way, the article does a better job _defending_ DJB's thesis than
attacking it, precisely by pointing out that DJB's plan would have been
relatively easy and feasible....

~~~
X-Istence
> wildly different network stack that happens to offer similar enough TCP-like
> abstractions that user-level code often is only slightly affected, but
> everything else in the stack is profoundly affected.

TCP itself hasn't changed. TCP is a protocol that sits on top of IP (version 4
or 6). Same with UDP. Yes the IP stack has changed, that kind of thing happens
when you bump the version number ;-)

So from an application standpoint TCP/UDP haven't changed, the only thing that
has changed is the structure to set up the IP connection, and even that is
hidden away for most users (getaddrinfo() deals with most of the complexities
for developers).

Percent signs in an address are only used on link-local segments with link-
local addresses, as they are the only way to distinguish what network
interface to use. In almost all cases where you are dealing with IPv6 you can
completely ignore that aspect because you won't have to deal with it,
especially as an application developer trying to make connections to IPv6
hosts, or even starting servers/listening for incoming connections.

> The advantage of the "just extend it" plan is that it would have been that
> easy.

I disagree. This still requires that the entire IP stack be upgraded to
support it, applications still need to update all of their network handling
code to deal with the extensions, we'd be in exactly the same boat.

~~~
jerf
As I said, _application_ programmers just using TCP have way less to deal with
than all the other hardware in the stack. The point is all the _other_
hardware has much larger changes to make than just "extending an address".
It's a brand new protocol, not an extension.

I've been involved in some relatively _trivial_ extension of application-level
network devices to IPv6, and even _that_ was a surprisingly large nightmare
because you embed all these assumptions about addresses everywhere without
even realizing it. Not just "they're a 4-byte integer"; one big one you embed
without even realizing it pretty deeply is that "A network address is _one
type_." In dual-stack code, you no longer have "an address". You have two
types. That's just an example of the problem.

I think perhaps anyone who is opining on how easy this should be should also
mention whether or not they've tried to convert an application or a network
device to IPv6 or not, because I've seen even within a network company a lot
of severe underestimations of the difficulty. (Some of these things are much
easier when you write new code for IPv4+IPv6, which is why I say _convert_. Of
course if you write new code on an abstraction layer that already solved this
problem it's easier.) IPv6 _is not_ IPv4, quite profoundly. It's not just
addressing changes. Converting to IPv6 _is not_ just "replacing all your
gear", it is _rewriting foundational aspects_ of all that gear and a non-
trivial amount of the software that uses it. Not mere surface aspects like
addressing schemes.

This all looks fine and dandy from 30,000 feet, but when you're on the ground,
it's a really hard transition.

~~~
azernik
I have (worked at a networking equipment company on IPv6 support, briefly).

The few bits that are totally different (ARP-to-ND, for example) are all very
small bits of code. The really hairy stuff was always the dual-stack - the
assumption of a single IP instance running over any given layer-2 network is
baked deeply into most systems, and changing that is a royal pain. That plus
the renumbering of constants (ugh ICMPv6).

The way I explained it to people was: IPv6 is exactly the same as IPv4, but
with incompatible field sizes and constants, different (but usually MUCH
simpler) address configuration, and no hop-by-hop fragmentation (oh frabjous
day!).

------
enip
What about Enhanced IP as in www.enhancedip.org?

~~~
teilo
Every problem noted in this article also exists in Enhanced IP. It still
requires all software and hardware layers to be redesigned.

Every potential alternative to IPV6 is pointless. IPV6 is already implemented
by every network vendor, and every modern operating system. Most consumer ISPs
have already implemented it. All remaining ISPs, including Enterprise
providers, are in the middle of implementing it.

No alternative protocol, including Enhanced IP, is going to be implemented.
Ever.

~~~
enip
While Enhanced IP requires software upgrades it does not require any hardware
upgrades. Enhanced IP rides over the IPv4 network without requiring re-peering
like IPv6 does. I have already used Enhanced IP over the Internet and it works
fine. Also, I wrote the kernel patches for Linux over a period of less than
six months. If I can do this the other operating systems vendors could do it
too. Instead of being at 10% network capability after 20 years, Enhanced IP
has an advantage because it transports packets over IPv4. Enhanced IP also
keeps protocols like ARP and DHCPv4 so there is less disruption here. Further,
Enhanced IP uses IPv6 AAAA records for DNS lookups so this area of the network
experiences less disruption too. You should consider reading about how we do
this as it is pretty interesting. Please read our paper or RFC for further
clarification or details. They can be found here:
[http://www.enhancedip.org/documentation.html](http://www.enhancedip.org/documentation.html)

The one comment you make on your blog post that is true is that Enhanced IP is
not compatible with multiple layers of NAT.

