The IPv6 Transition

https://cr.yp.to/djbdns/ipv6mess.html still as relevant as the day it was written

Time has not been kind to this article. It's basically a compete list of fallacies that people believe about ipv6.

Oh, is IPv6 now backwards compatible with IPv4? No? I guess not a complete list of fallacies.

I can route to v4 endpoints on my v6-only network just fine. Shrugs

They aren’t compatible. There is a device in the middle doing a translation for you.

That’s like saying HTTP can talk to FTP servers as long as there is an HTTP to FTP proxy.

The only thing that makes them seem compatible is there is a well formed address space in v6 that clients send v4 requests to. But it’s still v6 and a 64 proxy needs to have an actual IPv4 address to translate the source to before sending it via v4 to the actual destination.

I'm aware there's a middle box. My point is that the middle box is a compatibility layer which, by definition, has the effect of enabling compatibility (at least in one direction).

The usual "they should have designed it to be compatible" nonsense usually comes from the crowd with zero suggestions of how to have a 32-bit addressed device send to packets to something with an address outside its universe.

Point is that djb was as wrong then as they are now.

Which is to say, not.

> They aren’t compatible. There is a device in the middle doing a translation for you.

Which was true of all the IPng candidates, and not just the one that ended up being chosen for "IPv6".

There is no way to expand the addresses space (as found in IPv4) to something greater that 32-bits in a compatible: new API calls, data structures, DNS records, etc, were always going to be needed.

To list "not compatible" as a con of IPng/IPv4 is non-sensical.

DJB point about the magic moment makes sense to me. What is the point of a separate network that has 33% adoption? It has virtually no impact to alleviate IP address exhaustion, and therefore there is no incentive.

The vast majority of that ~%40 of internet traffic is in direct disagreement with said prophecy though. Mobile carriers like T-Mobile, Verizon, AT&T, Telstra, Deutsch Telekom, Orange, (...you get the idea) all used pure IPv6 backbones with NAT64 edges to role out mobile telecommunications without needing double/CG-NAT or boatloads of public IPv4. Each connection made via IPv6 is transparently 1 less NAT session out a public v4 address and the IPv6 design greatly optimized the way the mobile network cores were built out. This is what has driven the growth of IPv6 on the internet (as more users switch to mobile) rather than an explosion of wireline and business users making the switch.

Where pressure is still lacking is in "small" enterprise type case (like most businesses, regional health systems, local government facilities, and so on) where the difference isn't really that much vs networks with 100 million or more clients riding). Only when corps get to the size of e.g. Microsoft do they really start seeing similar value at the moment. Everyone else can scrape by just getting that small bit of IPv4 and forgetting about it for now.

> They aren’t compatible. There is a device in the middle doing a translation for you.

The same could be said of the awful mess we have currently with IPv4 NAT almost everywhere on the current IPv4 network (and CG-NAT as well).

Well, finding out the author works at my alma mater the weirdest way possible: recognizing our Class B in the opening paragraph. I still catch myself typing 131.193 when I go to type in IP addresses on the numpad, just a force of habit.

Of course, my home network's IPv4 space uses the same 10 block as the subnets I worked with most of my time there.

It's even what the T stands for.

IPv6 clients (or in theory any kind of IPv4 successor) can reach IPv4 servers via some kind of translation layer (for example NAT64) - so IPv6 is backwards-compatible with IPv4 in that direction. The inverse direction (IPv4 client to IPv6 server) is however not possible, since IPv4 is not forward-compatible with any possible successor, because it is not possible to encode more information into 32-bit than 32-bit.