IPv6 non-alternatives: DJB's article, 13 years later
blog.sesse.net
blog.sesse.net
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.
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)
Multihoming is also not the normal case: for a long time ARIN refused to make IPv6 PI allocations to existing IPv4 PI.
Once all that is excluded, there isn't much infrastructure left.
I'm describing IPv4 that uses the current dotted-quad as the network address and adds a new host address: The routing tables don't get bigger, AS numbers are 32 bit anyway and unlikely to get bigger, DPI is actually easier than with NAT since there's no ambiguity, there's no new media types, and upgrades can be done piecemeal.
Seriously, it's better than IPv6 in every way but one: by being cheaper to deploy companies and consultants can't charge extra for IPv6 readiness over a few decades.
They do, because of route fragmentation, not because of address size.
> AS numbers are 32 bit anyway and unlikely to get bigger
No, AS numbers were 16 bit until well after the introduction of IPv6.
Routers have been able to handle IPv6 since quite a bit before the introduction of 32 bit AS numbers, so, if you wanted to be able to speak to 32 bit BGP peers, you had to upgrade to a router that can do IPv6 as an unavoidable side effect.
WLAN support doesn't require new hardware because of IPv6, it requires new hardware because old 3com 3c509 cards didn't support WLAN. Increasing number of customers require increasing number of customer-facing routers and router ports because each customer requires a connection, it's nothing specific to v6. And so on.
6in4 gives IPv4 hosts IPv6 addresses which means we only have to upgrade all the edges, but we still have to upgrade all of them.
What I propose (effectively) gives IPv6 (though I should call it something else) hosts IPv4 addresses: the exact opposite. You don't have to upgrade anything except the user's web browser (which clearly took less than 20 years).
No-one's turning off their IPv4 stacks though. Under your proposal if one or other edge was IPv4-only then they'd use ordinary IPv4, you'd only see any benefit if both edges were IPv4+, right? Which is the same as when using 6to4. (If you really need to avoid dual-stack even on the local network you can use 6to4 and NAT64).
(6to4 is largely a failure but the kind of approach you propose would have the same issues as far as I can see)
An IPv4+ address reserves 32 bits for the network address, and has (say) a 64 bit host address after it.
This means that IPv4+ hosts can be allocated by anyone with an IPv4 address.
Not so - if you have a single public IPv4 address you can turn that into an IPv6 /48 and put up to 16 bits worth of hosts behind it. Given that these are only for edges and not meant to have routing within them that should be plenty (having two different sets of routing logic applying to the same packets would be a recipe for difficult-to-debug disconnections and even-more-difficult-to-debug transient slowness).
Most of the internet knows how to route 4 bytes, but if I want to add new nodes, and there are only 8 billion people on the planet, surely between me and my neighbour we can share an IPv4 address -- and in fact we are with NAT, but you can't address a single device that I control -- you can only address the NAT machine, make sense?
That's actually okay though, because the only reason the NAT box can't forward the packet to my home server is because it doesn't know that's what you meant: It only knows about 4 bytes. If we teach it about 16 bytes, then it will have no problems.
The trick is, we overlap the upper 4 bytes with IPv4: This means most of the routing infrastructure (that doesn't need to know the difference between my home server and my router) can remain unchanged. This is (in fact) most of the Internet.
However an application that wants to access my server still needs to be updated.
Web browsers went through a similar problem, but they didn't use nat, they relied on the fact that the hostname could be used to identify the service. In this way, the DNS hostname which map to an IP address can be reused to address a specific web site. This information is stored in HTTP in the Host: header and in HTTPS in the SAN (subject alternative name field). The "router" (in this case usually called a web server or a proxy server) can route to the appropriate resource using this information.
This didn't happen immediately though: For a long time, many web browsers didn't use the Host: header, so before people could rely on the Host header to distinguish services, web browsers needed to be updated.
Not all of them, but enough web servers configured to remind users to upgrade their web browser eventually did the trick, and it didn't take twenty years either.
What I proposed is a general mechanism for doing this: to simply extend the address space at the application level.
We could have done it in the operating system -- say with a socket option, and I think it would still be faster than IPv6.
Does that make sense?
Yeah, you could use the IPv4 routing infrastructure for transport of this new protocol. That's also known as tunneling. You can do that with IPv6. Even with automatic assignment of addresses based on IPv4 addresses you already have, that's called 6to4. And while that was a nice idea for a transition mechanism (and in the form of 6rd still usefully employed by some ISPs), it's not really that useful in the long term, as backbone routers have been IPv6 capable for a long time, simply due to upgrades for higher bandwidths. To take a random example: Peak bandwidth at AMS-IX in 2002 was 12 Gbit/s. Now, it's 4.2 Tbit/s. And they didn't do that by multiplying the number of routers by 350.
Your analogy to HTTP and TLS also doesn't really hold up: Both are protocols that are only implemented at the edge of the network and pretty much only in software that is easy to update, while your suggested extension would have to be implemented from the boundary of the publicly routable IPv4 network outward, which in particular includes hundreds of millions of home routers where even updates to fix security vulnerabilities tend to be difficult to come by.
Also, it's not actually true that the v4 routing infrastructure wouldn't need to know the difference between your server and your router. What if you send a packet to an address that has no route? The router that determines that there is no route sends an ICMP network unreachable to the source address of your packet. How would your translation gateway know which inside address to forward it to? Or how about a fragmentation needed message? Should we break PMTUD for good?
IPv4+ solves the same problems that IPv6 does, is much simpler than IPv6, is cheaper than IPv6, and could have been deployed in less time than IPv6.
If we're going to learn from IPv6, then that means studying things like IPv4+.
Note I'm not suggesting we stop IPv6 efforts: I used to say that, but that's only because I think we'll have a 50% solution in another ten years, and IPv4+ could take up to ten years if we had consensus.
> while your suggested extension would have to be implemented from the boundary of the publicly routable IPv4 network outward, which in particular includes hundreds of millions of home routers where even updates to fix security vulnerabilities tend to be difficult to come by.
If you run a service on IPv4+, your router needs to support IPv4+, and your users need to support IPv4+. That's it.
This is very similar to the challenges that upgrading HTTP and HTTPS do had.
Note a user with an IPv4+ address can connect to non-IPv4+-capable systems since he also has NAT.
> addresses based on IPv4 addresses you already have, that's called 6to4
6to4 is a lot more complicated than IPv4+. It was harder to deploy, and building on IPv6 instead of IPv4 was probably a mistake.
If we don't consider the complexity of the implementation, 6to4 still took much longer to be suggested than IPv4+ (or similar) was.
> What if you send a packet to an address that has no route? The router that determines that there is no route sends an ICMP network unreachable to the source address of your packet.
NAT already has this problem. Broadcasting ICMP is an acceptable solution -- remember that IPv4+ for a client is an alternative to NAT.
What does "your users need to support IPv4+" mean? What does it take to make a "user" support IPv4+?
> Note a user with an IPv4+ address can connect to non-IPv4+-capable systems since he also has NAT.
Yeah, the same as with IPv6/v4 dual stack.
> NAT already has this problem. Broadcasting ICMP is an acceptable solution -- remember that IPv4+ for a client is an alternative to NAT.
No, it doesn't, no, it's not. ICMP error messages contain the first 8 bytes of the packet that couldn't be delivered, which in the case of TCP and UDP contains the port numbers, which a TCP/UDP NAT uses to NAT the ICMP messages. And broadasting is not an acceptable solution because delivery of ICMP messages happens to sockets, not to machines. If you deliver ICMP UDP port unreachable messages to all sockets in the respective IPv4+ address range where the port happens to match, that's going to cause chaos.
If so, what would the first packet the client sends look like? In particular, what would be the values in the protocol and source address fields? And what would be the values in the first reply packet from the server?
It's what I get for being on my phone.
6to4 would probably have been more successful had it not allowed tunnelling arbitrary IPv6 addresses, not used a different protocol type, or broken the IPv4 addresses (by adding the 2.0.0.2.ip6.arpa DNS zone), but I agree it's basically the same thing.
What does WiFi or a switch even have to do with this?
I happen to think DJB was right. If we could rewind history to, say, 1998 and implement an address space extension to IPv4 that was less of a severe change than IPv6 that probably would have been the better way forward.
Personally I would have implemented IP64, using the existing IPv4 space as the most significant 32 bits of a 64 bit address space. The advantage here is that an IP remains something that can fit in a typical 64-bit CPU register and remains short enough that it's type-able and at least a little bit memorable. 64 bits would be plenty to address every device on Earth. There are some nice things about having a larger address space but most of them are minor compared with the address shortage problem. IPv6 gives you enough space for reliable stateless auto configuration, but in practice that's going out of favor since it turns out you need DHCP (DHCPv6) for other reasons besides just assigning addresses.
Note those values and think of the significance.
These are all positive things we wouldn't have if we were still clinging to IPv4.
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.
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.
(but let's not discuss XHTML 2.0 now)
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)?
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.
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
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
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....
Or if you're doing DSR, the default route ordering rules are different.
What kind of tweaks have you required in your deployments because of this?
DSR is a special use case, and with each interface having a link-local address means you don't need to provide globally unique addresses, because the source/destination specify their route explicitly, each hop can use their link-local address. DSR would also require modification if it was using an extended version of IPv4...
Why does link local need to be complicated? Router interfaces facing clients should be fe80::1. That way, every client knows it's default route is fe80::1%eth0 (or similar). Works great for multiple addresses from different networks on the same host, too.
Here's where I got the idea of using fe80::1 everywhere for the link-local gateway: https://www.edge-cloud.net/2013/08/ipv6-link-local-addresses...
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.
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.
Yes, to the former, only device updates I've done was for a proprietary appliance and that was mainly get new Linux kernel built and then upgrade software. I have not had to deal with silicon level stuff.
I updated various proprietary applications over the course of a week to bind and function over IPv6. Logging was an issue with the new addresses since assumptions were made about IP length, but those were quickly fixed.
Clients that were using old functions instead of getaddrinfo() were easily updated, and in general my experience is that clients don't really care so much about what IP version they use to connect. Once again logging functions assumed that IP's were only IPv4 structs, so some changes and they could log either one.
Overall the transition was simple, the applications already supported binding to multiple addresses, so having it be dual stack ready (binding both IPv4 and IPv6 was simple), and those that didn't took a little longer but ultimately wasn't that much more difficult to get them upgraded.
I pay my network vendors to get me the latest standards, getting all of this right on their end may have been a lot of work, but ultimately that is a one-time cost of doing business, and in most cases I am paying for them to support my use cases.
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!).
And how is it "much more complicated"? IPv4 with layers of NAT bolted on top of it in an ad-hoc fashion doesn't strike me as a paragon of simplicity. The IPv6 world seems much cleaner to me.
Also, IPv4 addresses absolutely are complicated enough to have warranted their own Wikipedia articles: https://en.wikipedia.org/wiki/Classful_network, https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing. But it doesn't matter - for the most part, applications don't need to care about the structure of an 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
The above neatly encapsulates my problem with IPv6. I feel IPv6 would have much more widely adopted by now if people like myself—who have spent nominal time setting up small computer networks such as their home network—could more readily grok the deltas between v4 and v6. With the reality of v6 being so dramatically different, I have on about three separate occasions sat down to try to understand what I need to do in order to have v6 on my home network and each time I just give up after a few hours of reading.
It's just so much more complicated for the amateur network operators out there.
Additionally, it instills fear that if I turn on v6, I will inevitably have my home network in some tragically vulnerable state.
I don't mean to offend you, but I think that that suggests that you don't understand IPv4 either.
IPv6 isn't really all that different from IPv4--with one major exception: All of the workarounds for the shortcomings of IPv4 that dominate local networks nowadays are not needed anymore, actually making networks so much simpler again.
Now, many people who have learned IP networking in such environments in the last ten years or so (and I suspect you are one of those) seem to think that those workarounds are what defines IPv4 and then are confused by IPv6's lack of those workarounds, thinking that those are missing features.
Maybe you think that your "internal network" is in some way fundamentally different from "the internet" and that a router is a device that connects those two to give your local network "access to the internet"? That is a common misunderstanding caused by NAT. The internet without NAT, be it IPv4 or IPv6, doesn't know any distinction between "internal" or "external" networks. It is all one network, the internet. Your LAN is not somehow "connected to the internet", it is itself part of the internet. Your home router (without NAT) is no different in function than any other router on the internet: It is connected to more than one transmission medium and thus allows devices on one medium to reach devices connected to another medium, possibly transitively through yet another (series of) routers. And it's completely symmetrical in that regard: It allows devices on your LAN to send packets to devices outside your LAN (say one of Google's webservers), but equally allows devices outside your LAN to send packets to devices on your LAN (say a webserver on your laptop).
So, the most important thing you may have to completely unlearn is the idea of "private addresses" and "NAT" and "port forwarding". You don't get one address from your provider, you get a huge subnet with quadrillions of addresses that you can use to assign addresses to your devices, similar to the early days of IPv4. Your laptop gets an IPv6 address that is no different in function than the IPv6 address of Google's webserver.
Other than that, details and terms differ, but the general concepts of IPv6 aren't all that different from IPv4. ARP is now NDP, DHCP is now SLAAC (or maybe still DHCPv6 if you like), ...
Now, if you think that it seems problematic to have "public addresses" on your "private network": It's not, that's purely psychology. Yes, a stateful packetfilter at boundaries to other, non-trustworthy, networks might still be a good idea, just as with IPv4, whether you were using NAT or not. If anything, having one global address space makes things much less complicated, and thus more difficult to screw things up.
Once you get the hang of it, you will love it and start wondering why you ever considered NAT a reasonable idea. Ever had the problem that you had multiple machines behind a NAT offering the same service that you needed to access from the outside, so you had to put one of them on a different port on "the public address"? Ever tried to access a port-forwarded service from the network behind the NAT and had it either fail because of lack of hairpin NAT, or it was slow because of the bottleneck that was the hairpin NAT? All those problems simply vanish, never to return.
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.
The one comment you make on your blog post that is true is that Enhanced IP is not compatible with multiple layers of NAT.