alt Hacker NewsI don't like to admit this, but at this point honestly I think ipv6 is largely a failure, and I say this as someone that wrote a blog post for APNIC on how to turn on ipv6.
I'll get endless pushback for this, but the reality is that adoption isn't at 100%, it very closely needs to be, and there are still entire ISPs that only assign ipv4, to say nothing of routers people are buying and installing that don't have ipv6 enabled out of the box.
A much better solution here would have been an incredibly conservative "written on a napkin" change to ipv4 to expand the number of available address space. It still would have been difficult to adopt, but it would have the benefit of being a simple change to a system everyone already understands and on top of a stack that largely already exists.
I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
Replies
This whole discussion reminds me of the beautiful design of UTF-8. They used the lower bits to be ASCII which made backwards compatibility so much easier. It also reminds me of the failure of Intels Itanium and the success of AMD x64. Engineers often want to abandon backwards compatibility to make a new "beautiful" design, but it's the design that has full backwards compatibility that's actual impressive.
The only solution is a gov't mandate. China went from almost no adoption to leading the world in adoption (77% of all Chinese internet users) in a few years because they explicitly prioritized it in their last 5-year-plan.
The ISPs aren't gonna do it on their own.
I wouldn't say "failure". There are many, many IPv6 client devices out there, mostly on mobile networks. And it works great and they do well and the tools all support it very well.
But IPv4 will never, ever die. The rise of NAT as a pervasive security paradigm[1] basically neuters the one true advantage IPv6 brought to the table by hiding every client environment behind a single address, and the rise of "cloud everything" means that no one cares enough about reaching peer devices anyway. Just this morning my son asked me to share a playlist, so of course I just send him a link to a YouTube Music URL. Want to work on a spreadsheet for family finances with your spouse in the next room? It lives in a datacenter in The Dalles.
[1] And yes, we absolutely rely as a collective society on all our local devices being hidden. Yes, I understand how it works, and how firewalls could do this with globally writable addresses too, yada yada. But in practice NAT is best. It just is.
Yep, just call it IPv8 and make it double the length of IPv4.
Ultimately, an address system that replaces “1.1.1.1” with “JEDBSO:7372B6D6A:727:8:72829:762927” or whatever just isn’t viable.
Even AWS doesn’t let you use IPv6 with anything… and they charge you for using IPv4 now.
Circa 1999 I was working for Cisco as a sysadmin. I got my CCNP through internal training and considered making a career of network administration, but ipv6 changed my mind. It seemed so much more difficult and unpleasant to deal with. I didn't want that to be my day to day work.
I think the same thing happens on a different scale with ISPs. They don't want to deal with it until they have to for largely the same reason.
I actually think it would have had a better chance of success if ipv6 had embraced the breaking changes to add some killer feature that would have made it worthwhile to upgrade even for entities who didn't need to worry about running out of ipv4 addresses.
I'm not sure what that feature would be though.
IPv6's failure was mostly caused by the IETF's ivory tower dwellers, who seem to generally have no practical experience or understanding whatsoever of how networks are actually built and run today, especially at the small to mid scale.
Small site multihoming, for example, is an absolute disaster. Good luck if you're trying to add a cellular backup to your residential DSL connection.
IETF says you should either have multiple routers advertising multiple provider-assigned prefixes (a manageability nightmare), or that you should run BGP with provider independent address space; have fun getting your residential ISP or cellular carrier onboard with this idea.
I've been thinking we could simply extend the ipv4 address to be 11 bytes by (ab)using the options field. That is, add an option that holds more bytes for the source and destination address, which are to be appended to the address already present in the header.
I am thinking that since an option starts with 2 bytes and everything must be padded to a multiple of 4 bytes, we can add 16 bytes to the packet, which would hold 7 extra address bytes per source and destination, giving us 11 byte addresses. ISPs would be given a bunch of 4-byte toplevel addresses and can generate 7-byte suffixes dynamically for their subscribers, in a way that is almost the same as CGNAT used today but without all the problems that has.
Most routers will only need to be updated to pass along the option and otherwise route as normal, because the top level address is already enough to route the packet to the ISP's routers. Then only at the edge will you need to do extra work to route the packet to the host. Not setting the option would be equivalent to setting it to all 0s, so all existing public hosts will be automatically addressable with the new scheme.
There will of course need to be a lot more work done for DNS, DHCP, syntax in programs, etc, but it would be a much easier and more gradual transition than IPv6 is demanding.
ipv6 adoption is still steadily rising. Not as fast as anyone hoped, but at least steadily. There is no way it can be abandoned at this point even if we wanted to.
Truth is there are too many devices that only speak IPv4 or have untested IPv6 stack. People still can’t even agree on how ipv6 address is represented.
Stripped of all the other baggage that came with it (e.g. SLAAC, IPsec, etc) IPv6 is an incredibly conservative addressing extension. The only thing even more conservative than v6 would have been to drop the lower 64 bits of the address and the associated EUI-64 local addressing scheme. Which... to be fair, that turned out to be a very bad idea, but the length of the field isn't what was holding up v6 adoption.
I suspect by "incredibly conservative" you mean "backwards compatible", which... no. You can't make an addressing extension backwards compatible with hardware that doesn't read all of the address. Of course, we did that anyway with CGNAT, and predictably it causes huge problems with end-to-end connectivity, which is the whole point of IPv6. You're probably thinking more along the lines of an explicit "extension addressing header" for v4. Problem is, that'd mean a more awkward version of IPv6's /64 address split[0], combined with all sorts of annoying connectivity problems. The same corporate middleboxes that refuse to upgrade to IPv6 also choke on anything that isn't TCP traffic to ports 80 and 443. So you'd need Happy Eyeballs style racing between CGNAT IPv4 and "extended IPv4".
Also, that would just be a worse version of 6in4. Because they also thought of just tunneling IPv6 traffic in IPv4 links. I don't think you understand how incredibly conservative IPv6 actually is.
The problem with "incredibly conservative" IP extensions is that nothing beats the conservatism of doing literally nothing. IT infrastructure is never ripped out and replaced unless there is a business case for doing so. The current problem with IPv6 adoption is that nobody has yet said "let's stop processing IPv4 traffic", they've only said "let's get more dual-stack hosts online", which is a process that only asymptotes to 100% IPv6, and never reaches it.
IPv4 was not the first version of the Internet protocol. That honor goes to Network Control Protocol (NCP). The reason why we don't have an asymptotic long tail of Internet hosts still demanding NCP connectivity is because this was back when "having a connection to the Internet" meant "having a connection to ARPANET". The US military could just refuse to process NCP packets and actively did this to force people onto IPv4. Now imagine if someone big like Google said "we're going to stop accepting IPv4 connections" - people would jump onto v6 immediately.
[0] Let's say we add a 32-bit extension header onto IPv4
I think this is defeatist talk where it’s not warranted. I remember IPX networks in the 90s were still a thing because people believed they could eke out a little more performance for their games. It’s taking a long time to move to IPv6 in some parts of the world. eg: anyone who doesn’t feel the pain of the IPv4 address crunch likely due to having a large chunk to begin with. Many influential organizations in North America definitely fall in that category.
IPv6 is a success IMHO because it is used in so many places. Google’s IPv6 traffic graph shows close to 50% adoption and still trending up. We can’t possibly expect the world to be near 100% overnight… the internet is a big place with the whole spectrum of humans influencing IT; There will always be someone who will cling to IPv4 for dear life.
> I'm not proposing to abandon ipv6, but at this point I'm really not sure how we proceed here. The status quo is maintaining two separate competing protocols forever, which was not the ultimate intention.
The end game will be a cryptographically large address space allocated based on some cryptographic operation, rather than a committee carving up the space arbitrarily.
Tor already does this, addresses allocation is not a problem. I think they used to use hashes, but now use Ed25519 public keys. Obviously, Tor is not suitable for most tasks. No one should have to pay for the extra latency if they don't need the anonymity.
The real problem is routing in these address spaces, and there have been a few projects like CJDNS which try to solve it.
Imagine every address along a major road is 3 digits, and some shortsighted post office code assumes 3. Your business is 845 Oak St. One day they say hey, this road is getting too long, let's update that code to support 10 digits and we never worry about this again.
Oh and btw, your address is now 9245593924 Oak St.
> A much better solution here would have been an incredibly conservative change to ipv4 to expand the number of available address space
"And what do you base this belief on?
Fact is you'd run into exactly the same problems as with IPv6. Sure, network-enabled software might be easier to rewrite to support 40-bit IPv4+, but any hardware-accelerated products (routers, switches, network cards, etc.) would still need replacement (just as with IPv6), and you'd still need everyone to be assigned unique IPv4+ addresses in order to communicate with each other (just as with IPv6)."[0]
0: https://news.ycombinator.com/item?id=37120422