Unfortunately my perception is that IPv6 deployment is stalled (due to inaction by ISPs). In my company we have recently dismantled some of our IPv6 infrastructure because it became apparent that ubiquitous v6 connectivity was not coming any time soon (e.g. we have locations served by Charter/Spectrum, and they have no IPv6 and no plan to deploy it). We've instead deployed a private IPv4 overlay network between our sites and assets using GRE tunnels.

Also somewhat exasperating that the "running out of IPv4 addresses" saga has played out across almost my entire career. I remember attending the CIDR meetings at the IETF in around 1992, for example. So one of the first technical problems I encountered in my career remains unsolved nearly 30 years later.

I now receive a block of IPv6 from Comcast. I allow the router to assign them to devices on the network, but I admit that I am somewhat worried that my local PC is no longer isolated from the Internet by a private IP.

I find DJB's take on this interesting: https://cr.yp.to/djbdns/ipv6mess.html

EDIT: Dan has many excellent points, but I'd like to quote my favorite:

The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.

Indeed, what were they thinking!

It's certainly an undeniable fact that IPv6 adoption has been a disaster, taking much longer than hoped for. Frankly, I expect to see IPv4 coexist with IPv6 for the next hundred years - not ideal.

When I was at UCLA, I learned this new architecture called NDN https://named-data.net/. It does not rely on addressable device or host. It give addresses to content. Not sure how industry think of this new idea. I watched several talks about NDN. They all have great stories and believe it's the future.

Corrections: CIDR stands for Classless Inter Domain Routing (because it superseded the Class A/Class B/Class C arrangement, which allowed only three particular allocation block sizes).

I know the author is Spanish; I'd like to point out Orange Spain has been deploying IPv6 addresses to end customers these last weeks using the Dual Stack lite transition system.

All the big ISPs have been testing IPv6 for years now and I'm sure it's just a matter of flipping a switch. Now that a new contender is in town (a 4th ISP) and they're having huge problems because they have no IP addresses left to assign to their customers, I suppose the rest of ISPs will stall even more their transition to IPv6 so they can try and "suffocate" the new ISP.

Just my two cents...

I've only worked at one company that had full IPv6 support. Even on my current 1GbE fibre setup with a small startup, they still don't have IPv6 rolled out to residents yet. :(

I feel like one big hurdle is IPv6 usability. You can write down and easily remember IPv4 addresses. IPv6 netmasks can get really confusing. They make sense if you expand out every block, but in reality, IPv6 requires a lot of tooling to chop up and work with address spaces in an intuitive way.

If you enjoyed this, this is a great resource current state of prefix utilization in the global routing tables:

http://www.cidr-report.org/as2.0/

IPv4 is like any commodity. Now that it's not easily to get from ARIN, a market has sprung up around buying and selling it.

It's still relatively easy to get IPv4 blocks for a buck or two per IP through auction houses.

Would have been awfully nice to have a reserved bit in hindsight. 7 bit ASCII was an amazing accident. (Maybe it wasn't, time to brush up on my history...)

IANA sold the blocks. There are still a lot of unused IPv4 addresses. IANA sold the blocks.

PS IPv6 sucks.

We only use 32 bits of each 48 bit ipv4 address. The problem isn't exhaustion, it's using DNS to do service location rather than IP.

> The IPv6 designers made a fundamental conceptual mistake: they designed the IPv6 address space as an alternative to the IPv4 address space, rather than an extension to the IPv4 address space.

I respect djb and his contributions to cryptography, but he is off base here. The sin was committed when IPv4 was made and not initially designed to allow for variable / expanded address space.

Adding an IP Option to IPv4 packets that could carry extra address bits was not an option either -- IP options aren't preserved much at all on the Internet. Furthermore, even if most routers didn't drop IP options, adding "v6" address space via IP option in a packet that old/v4-only devices would nevertheless attempt to parse would have been hell operationally.

IPv6 has lots of flaws/idiosyncrasies/weirdnesses (multicast, mobility, slaac, ndp, etc.) that only looked good in the 90s, that definitely made ipv6 adoption a lot more painful than it needed to be, and ended up as difference for just difference's sake; but the one thing that was unambiguously done right with v6 was a completely clear separation of address spaces from IPv4.

I think anyone who thinks DJB's proposal was a realistic easy option needs to look at the history of the class E address space (240.0.0.0/4), and the proposals to allocate it for normal use.

Despite not changing the address length at all, the idea of doing this was abandoned because of the widespread compatibility problems across different OSes.

Sure, you could hand-wave another layer of NAT to "fix" it, just like the extended address proposals.

Hell, even using MAC addresses which begin with a number devices haven't seen before is enough to cause issues, despite following the existing standards: https://news.ycombinator.com/item?id=13090945

And all the existing NAT / firewall / middleware devices - they're supposed to handle the extensions transparently? Having seen the many ways that ASA protocol / application fixup can mangle packets - I find it very hard to believe.

One thing I never understood in these proposals: how would two computers, one with only an extended address and the other with only an IPv4 address, talk to each other? Or two computers with extended addresses, but with a single router in the middle of their path which doesn't understand extended addresses?

All these proposals I've seen appear to assume that extended addresses start being distributed only after every or almost every host and router in the whole world had all of its software upgraded to understand extended addresses. But that's not realistic, since without being able to actually use it, there would be no incentive to modify every single piece of network-facing software and hardware to be able to use extended addresses. It's a Catch-22.

If you assume that IPv6 adoption is only due to IPv4 address shortage, then the rate of adoption makes a lot of sense. Whatever alternative to IPv6 you can come up with, as long as there is plenty of IPv4 space, nothing will happen. Unless you can find a killer app in a different area, which hasn't happened.

Now that you have to buy IPv4 addresses at around $10 for a single address, the game has changed.

With carrier grade NAT, content has to slowly migrate to IPv6 for geo-location reasons. Any content that sees a high amount of abuse also has to avoid CGN.

Once big parties like google, facebook, etc. have a lot of traffic on IPv6, it stops making sense for them to invest in IPv4. So they will try to pressure ISPs into offering IPv6. Likewise, if an ISP sees that big content providers are on IPv6, then it stops making sense to invest in IPv4. Pressuring smaller content providers to offer IPv6.

And then IPv4 joins the ranks of IPX, NetBIOS, Apple Talk. Some pockets may continue to exists, but the rest of the world has moved on.

IPv10[0] makes IPv4 an extension of the IPv6 space. It'll be interesting to see if this takes off, but it doesn't really seem to solve the whole problem. All nodes in the path would have to support IPv10 for it to work.

[0] https://datatracker.ietf.org/doc/draft-omar-ipv10/

DJB's point is certainly valid, but in practice, while I had always shared the opinion that the Big Plan of all those committees to seamlessly migrate to IPv6 seemed a bit sketchy, in reality, it's worked quite well.

Funnily, having worked on adding dual-stack support to several pieces of software and protocols, my main grips with IPv6 remain how addresses are represented to humans. Despite compression and all, I realize there was no obvious way to make addresses easier to memorize and that's basically the price to pay to have a staggering 1'500 addresses per square meter of earth.

However, and it may sound a bit silly but I still consider that the choice of ':' as a separator was an unfortunate one, I'd have a hard time listing all the nasty implications it has in terms of parsing :)

I was just writing up my own comment to say exactly this when I noticed your comment. It's particularly unfortunate that ipv6 was not made backwards-compatible because it would not have been difficult to do: extra address bits could have been included in the options portion of the header. An IPv4 packet could be routed over an IPv6 network simply by setting the (missing) extended address bits to some canonical default value (most likely 0). The net result would be similar to an HTTP/1.0 client accessing an HTTP/1.1 server with multiple virtual servers running on it: accessing an IPv4 host at A.B.C.D would be the same as accessing an IPv6 host at A.B.C.D.0....0

Such a missed opportunity.

That post is incredibly obsolete. In reality, a big chunk of the Internet is already running IPv6 in production as we speak.