I don't see a world where these compromises didn't exists and ipv6 would have been successful in rapidly replacing ipv4. The article seems to miss the forest for the trees, trying to think technical problems that prevented deployment, when it was actually political ones.
Nobody wanted to touch middleboxes, routers, etc. half of the internet is running on software that is 10 years old, trunk networking is several times older. Very reliable and known of all its quirks, so it's unlikely to be replaced. New ISP's are the most likely to deploy ipv6 natively, and such ISP have to compete with other new and old ISP. Consumers don't care as long as things work most of the times, which ipv4 is _good enough_.
I would love to have a way to route my entire host to the internet, as it would make certain things easier, but I'm in the minority. Government policy could help ease the pain by requiring public institutions to implement it, but that's also a political problem.
> trying to think technical problems that prevented deployment, when it was actually political ones
I'd say it's more human nature.
We can see the problem looming in the horizon, we think we have some solution but implementing it will be painful now. However, the current solution isn't very painful yet, so it's better near-term to procrastinate. And so we postpone the change.
If IPv4 had some flaws that seriously hurt back in the mid-90s, we'd surely be over on IPv6 or something else by now.
> IPv6 chose to have addresses on the interface connecting to the network instead of having addresses on the node. In contrast to IPv4, IPv6 supports multiple addresses on an interface, where each of the address has different properties.
IP Addresses were always interface-bound. And you always could have multiple addresse on the same interface. Your IPv4 loopback device has 2^24 addresses bound to it right in this moment. Do ping on 127.12.34.56 and you will see.
Not quite. The kernel documentation notes that IP aliasing was the original way to have multiple IPs per interface, but is now obsolete, as multiple IPs are directly supported now (and by "now" I mean 2009-ish, with the introduction of iproute2): https://docs.kernel.org/networking/alias.html
In addition, the manpage for ip-address makes this clear:
> The address is a protocol (IP or IPv6) address attached to a network device. Each device must have at least one address to use the corresponding protocol. It is possible to have several different addresses attached to one device. These addresses are not discriminated, so that the term alias is not quite appropriate for them and we do not use it in this document.
You changed your interface to not implement RFC 5735:
127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher-level protocol to an
address anywhere within this block loops back inside the host. This
is ordinarily implemented using only 127.0.0.1/32 for loopback.
In the UK there are FTTH products being rolled out by a variety of companies in addition to BTs (and virgins) fibre networks. Many of which are being bought out by the biggest of these alternative fibre providers CityFibre. Many of the ISPs on CityFibre aren't able to buy the IPv4 space they need and are too young to have acquired it years ago like the older ISPs have. Instead they use CGNAT to provide service IPv4. Carrier grade NAT is definitely an issue for the average person because the bank websites often don't work properly/kicks off security as they expect unique IPs for their customers.
The need for CGNAT on IPv4 I can understand, it shows the extent of the problem and cost of acquiring IPv4 addresses, but they are also choosing to not deploy IPv6. Unlike the older ISPs they have no legacy to worry about with hardware to be upgraded and reconfigured and potentially a complex roll out, some of these companies are mere years old. When that use case can't bring IPv6 to the ISPs I have no idea what will.
It basically means, you grab IPv4 implementation, extend address space
to 64bit, call it IPv6, vioala. Problem solved.
IPv4 was battle proven for years. It mistakes were sorted out (CIDR addressing, ARP poisoning, DHCP/BOOTP, etc). It was widely understood. NAT is okey, CGNAT is not. The only problem was the address space. And they failed it...
Yeah, Dan Bernstein explained a long time ago how they were doing it wrong.[1] That's not dated, but it must have been 20 years ago that I first read it. In short, by making it a separate, incompatible protocol, they created a situation where no one had an incentive (other than curiosity) to implement it on clients, servers, or in between, until everyone else did. There were better options.
If one of the main blockers in ipv6 adoption is updating routers and switches and all the networking gear and endpoints to support the new address scheme, how in the world would your “just extend ipv4 to 64 bits” solve that problem specifically?
123.123.123.123/48 or whatever would be completely useless and dropped by an incompatible router and a server wouldn’t know what the hell to send its packets back to if it even got a response from something with that.
> If one of the main blockers in ipv6 adoption is updating routers and switches and all the networking gear and endpoints to support the new address scheme, how in the world would your “just extend ipv4 to 64 bits” solve that problem specifically?
By reducing the amount of work needed in order to get the new thing implemented. IPv4 is super simple by comparison to IPv6. I'd say there's at least an order of magnitude more complexity and legacy in IPv6 than in IPv4. Just look at the number of IPv4 vs IPv6 RFCs.
> 123.123.123.123/48 or whatever would be completely useless and dropped by an incompatible router [...]
It would still have been a new protocol, just able to share a lot of source code with IPv4.
No we wouldn't, I worked on routers in 1997: the differences with IPv6 made our job much easier. The hard parts about IPv6 are changing the number of bits makes everything incompatible. That means all software and books needs to be rewritten to work with the new protocol and there is no way around that.
Of course you probably never worked with source routing in IPv4 - I spent a lot of time testing it because marketing couldn't prove none of our customers used it. Even then nearly all routers shipped configured to drop any packet with source address routing, but to comply with the rfcs we had to make it work.
Source routing? Can you tell me what you used it for?
The only place where source routing is used these days is MPLS-SR aka Segment Routing. The edge router precompute the path and sets all labels. Core routers just pop those labels and switch.
Most of time you just use normal routing or ocassionaly PBR (Policy Based Routing) with is not source routing. Src IP can be one of the parameters to decide.
It would have been adopted a lot faster if they had just done this. Just extend the address space, make a small part of it the previous ipv4 address space so translation between the two was trivial and it would have been easy to run them both side by side and transition appropriately with some translation services where IPv6 interfaced with IPv4.
I was at the Toronto IETF meeting in 1994(?) when they voted on 8-byte vs 16-byte addresses.
I share the author's suspicion that 8-byte addresses would have made a world of difference in IPv6 adoption. It's hard to understand nowadays just how slow many networks were back then - 28.8kb/s dialup modems were introduced in 1994, and 56k wasn't available until 1997 or 1998. Two 16-byte addresses take 9ms to transmit at that speed.
IPv6 did not tackle the router-side problem with CIDR: huge routing tables. In 1994 CIDR was causing a lot of hurt in the then backbone because routers needed more and more memory to hold ever larger routing tables. Keeping routing the same except adding more bits to the address space merely made the problem worse except for the hope that the address space wouldn't be too fragmented, and that something like the DNS A6 RR type (failed) would resolve address portability concerns.
IPv6 could have had a way to explicitly identify in the IPv6 header the route to the destination by AS number. I don't mean that applications should have been aware of AS numbers -- that could have been a system feature, or a first border gateway feature.
This would have made routers cheaper by making their routing tables much smaller (2^16 routes max) and would have made number portability easier by making it more tolerable to have huge IP->AS lookup tables outside the core routers. Though on the flip side it might have led to more fragmentation of the address space, so maybe it's better the way it is.
Re-reading https://apenwarr.ca/log/20170810 (linked elsewhere in this thread as well), right the thing that should have been solved first as the introduction of a TCP and UDP replacement suite that could handle mobility, since then switching IP versions at layer 3 would be much easier. But 30 years ago mobility wasn't as critical as 20 years ago and the IETF didn't foresee it. Also, introducing new transport protocols is quite difficult due to middleboxes -- at least that was the experience with SCTP, but a TCP that solves mobility would probably lead to middleboxes getting fixed quickly.
Nail on head. This is obvious not only in retrospect, but also to anyone just learning networking. We somehow expected the entire planet to become the death star with every blinking LED having a unique address.
I don’t think it’s obvious at all, not even in retrospect. People have historically been wildly underestimating how computing usage would evolve (“640KB of memory ought to be enough for anybody”), interfaces connected to the internet have indeed multiplied exponentially and it’s showing no sign of slowing down.
Because every node that is supposed to be able to route these packages need to be patched to understand the new package format. So its is equally difficult.
It's not equally difficult, because they decided to change a lot of other things, including some key details.
Not saying all those changes were bad, but at least for me it also makes thinking about IPv6 when using it much more foreign than if it had been just a larger address space.
At this point it's not so much the basic devices, it's very rare to have hardware still around that doesn't support ipv6, it's more the configuration of the networks themselves, as any given network needs to have its own set of decisions made on address allocation, etc to actuallly support it. And, since it's used by fewer people and there always needs to be a fallback to ipv4, for most networks the if ipv6 is broken it's not an emergency like ipv4 being broken, heck it might not even be noticed. Which is a self-perpetuating cycle as people will stay away from ipv6, especially committing 100% to it, while there's still frequent breakages.
(This does point to the fact that maybe ipv6 and the associated implementations should have been designed with a view to a dual-stack mode which is basically "flip a switch and it'll mirror your ipv4 setup so you don't have to think about it until you locally need more address space", but I don't know if that's something that would have actually been feasible. But a lot of the complaining about ipv6 is because it was designed to operate fairly differently from ipv4 in a few keys ways which are not necessarily always better and add friction to the migration process)
No, it's not really the same thing: with dual-stack you do need to think about your IPv6 configuration quite deeply, you can't just copy and paste what you're doing in IPv4, even if what you're doing in IPv4 could work just fine with essentially a fixed prefix on all your own addresses. (that said, I'm sure there's subtlety to this which makes it not so easy to implement as a standard. But AFAIK it wasn't even really a goal of IPv6)
Well yeah it would obviously constitute a new protocol and hardware/software would need to be upgraded, but beyond that everything that worked in IPv4 would continue to work in this theoretical protocol.
I just don't think IPv6 addresses are human readable compared to IPv4 addresses. I know DNS makes that a non issue for the majority of users but I still think it's an important quality for people in charge of maintaining networks and stuff.
I like IPv6 addresses more because they force you to use copy-paste, which removes the risk of typing errors. And nobody would try to dictate me an IPv6 address via phone.
> I just don't think IPv6 addresses are human readable compared to IPv4 addresses
Then you just didn't read enough into IPv6 documentation yet. IPv6 addresses can be short if you want because of the `::` operator.
Example: Instead of IPv4 where you'd have the addresses `10.0.0.2` - `10.0.0.100` for clients on your LAN + a single global IPv4 address, you just have `2001:db8::2` - `2001:db8::100` (where `2001:db8` is the "house address" part of your LAN and `2-100` is the specific device address)
I have a 56-bit prefix which cannot be shortened. That alone makes it very tedious to type by hand, never mind when the host has used SLAAC.
ULA makes it somewhat better, but not that much.
In my view, IPv6 requires DNS for all hosts to be manageable. We have mDNS which, when it works, makes that easier for internal hosts, but for external IPs using DynDNS is required.
The world had -just- gotten its parents and aunts and uncles and maybe some grandparents trained up on what an IP address is and looks like, and THEN the IETF approved this idiotic standard that said “forget all that, now it’s a bunch of hexadecimal digits with these confusing rules about colons to be ‘user-friendly.’ Also, be sure not to confuse your IPv6 address with the MAC address that’s printed on your devices.”
Whatever the technical merits/demerits of the protocol, I believe this brain-damaged approach to describing addresses is behind the “failure” of IPv6.
MAC addresses seem to thrive, both in Ethernet and Bluetooth. Sure, it's only 48 bits, but it's a bunch of hexadecimal digits with colons.
IPv6 failed because (1) it demanded too much of the networking hardware, (2) was a stupidly complex beast compared to IPv4 and (3) had the catch-22 of requiring both producers and consumers to upgrade at the same time to even make it usable, let alone widely beneficial. (Discounting 6to4 and other local patches.)
However, since I upgraded my AP, I realized my ISP actually does support IPv6 really well, so perhaps we're close now...
TFA talks about addresses being too long and the compromise to support variable-length addresses. 64-bits would have been fine.
Grandparent is engaging in the classic tech industry tradition of talking confidently about something they have very little knowledge about. Surely old people learning hex isn't what's stopping IPv6 adoption but why not, they explained IP addresses it to their Nana once at Christmas (you never visit!) and she nodded politely and so they're an expert on networking.
I don't think that it can be argued that IPv6 was complex and demanded more from the networking hardware.
On the contrary, the IPv6 headers have been explicitly simplified a lot in comparison with IPv4.
The increased complexity for the networking hardware has come only from the requirement of supporting both IPv4 and IPv6, instead of only one of them.
In my opinion, the most significant mistake of IPv6 has been that the IPv4 address space has not been considered a subset of the IPv6 address space.
Had this been done, it would have been relatively easy to mix arbitrarily in a network ancient IPv4 equipment that has never been updated with equipment implementing IPv6 and the gradual transition between the two protocols would have been very easy.
> In my opinion, the most significant mistake of IPv6 has been that the IPv4 address space has not been considered a subset of the IPv6 address space.
This suggestion has gotten brought up often over the past few decades.
Remember that every IP packet has a destination and source address. There is no physical way for a v4-only host to directly communicate with another host which has an address from a larger address space. Doing so requires NAT. Which can be and is used today for v4-v6 connectivity.
I don't think that it's a foregone conclusion that IPv6 "failed".
I'm rolling out services on v6 only now for my hobby projects. Just next week, I'll be switching over our company backups to v6 because I can have a dedicated port 22 on the backup machine instead of port forwarding. I've been running company VPNs v6-only (inside the VPNs) for some years now.
Our corporate services and my private hobby projects are all v6-enabled (in addition to v4), the latter since 2018 or something.
A non-techie friend of mine has CGNAT at home on v4, and simply used his consumer-grade router to open a port to the v6 address of his NAS. He and some friends and colleagues from his Uni been using that for half a year before they stumbled into a situation where somebody had no v6 address and could not access the NAS.
Aunts and uncles and grandparents rarely have to deal with MACs. Back in the day it was still quite common to have to manually enter some IP-addresses, although it was probably not common for "non-technical" people understand anything about IPv4 adresses either.
I for one to still to this day and age don't really understand IPv6 addresses, and admittedly haven't tried much. I typically disable IPv6 at the kernel because it's been nothing but trouble.
The most consequential one for slowing adoption was 128-bit addresses, because they are long and thus hard to remember or type. A 16-bit 4-tuple would be workable.
Also the post leaves something out that I think is equally bad: that hideous user hostile :-separated ASCII form. Just fixing this could really help adoption. What were they thinking? Using a character that requires a shift? And conflicts with the URL format?
“Use DNS” is the usual answer, and is a quick way to tell someone has never done IT or networking in the real world. DNS is a fragile inflexible protocol that requires standing up servers. It works for what it does but it does not eliminate the need for engineers to schlep IPs around.
Really? Not just being ipv4 with a bigger address space has slowed it down for my org. Too much auto magic configuration and dhcpv6 feeling like an afterthought and getting consistent behavior on different Linux network configuration manage systems has sucked
Nobody wanted to touch middleboxes, routers, etc. half of the internet is running on software that is 10 years old, trunk networking is several times older. Very reliable and known of all its quirks, so it's unlikely to be replaced. New ISP's are the most likely to deploy ipv6 natively, and such ISP have to compete with other new and old ISP. Consumers don't care as long as things work most of the times, which ipv4 is _good enough_.
I would love to have a way to route my entire host to the internet, as it would make certain things easier, but I'm in the minority. Government policy could help ease the pain by requiring public institutions to implement it, but that's also a political problem.