IPv6 non-alternatives: DJB's article, 13 years later
The real reason why IPv6 has been so slow to get deployed is precisely that you can <i>not</i> 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 <i>all sorts of ways</i>. 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 <i>usually</i> essentially identical (it isn&#x27;t necessarily but the differences often don&#x27;t matter for the simple common case), but <i>almost everything else changes</i>. &quot;DHCP&quot; changes. Vast new rules about all the classes of IPv6 addresses, and all network hardware needs to implement <i>new</i> code to handle all that. IPv6 addresses are <i>much</i> more complicated than IPv4 addresses.<p>In fact probably most of the people reading this only <i>think</i> 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 &quot;link local&quot; 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&#x27;t need to prove that in a reply. But I bet the majority of people reading this do not.)<p>Just look at this page: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;IPv6_address" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;IPv6_address</a><p>By contrast, I can&#x27;t link you to the &quot;Wikipedia page on IPv4 addresses&quot;, because <i>it doesn&#x27;t rate its own page</i>. It just gets rolled into a single section on the IPv4 page in general: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;IPv4#Addressing" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;IPv4#Addressing</a><p>And that&#x27;s <i>just</i> addresses. There&#x27;s huge swathes of other changes that require huge amounts of new code to be added to all network devices.<p>IPv6 isn&#x27;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 &quot;slightly modified&quot; to work, but torn down and replaced with a much larger and more complicated chunk of code. IPv6 is <i>not</i> &quot;just&quot; IPv4 with bigger addresses. IPv6 doesn&#x27;t fail to interoperate with IPv4 because of trivial networking issues, IPv6 fails to interoperate with IPv4 because it&#x27;s a <i>wildly different network stack</i> 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.<p>The advantage of the &quot;just extend it&quot; plan is that it <i>would</i> 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&#x27;s take this opportunity to stuff every wish-list item in there we can. We didn&#x27;t have to do <i>that</i>.<p>In a way, the article does a better job <i>defending</i> DJB&#x27;s thesis than attacking it, precisely by pointing out that DJB&#x27;s plan would have been relatively easy and feasible....