[TravisHusky]

Wow; that is a lot worse than I thought. I really wish IPv6 was better understood than it is now, it really is quite a good standard, but it is also quite a bit different than IPv4 which I think scares people away (it can also be hard to remember longer IPv6 addresses).

[akersten]

> it really is quite a good standard,

I think we need to start judging how good a standard is by how easy it is to implement for its intended purpose.

The purpose of IPv6 was to superscede IPv4. 25 years later, only 1/4 of the top sites from this link are IPv6 enabled. That's... well, at some point you have to stop blaming lazy sysadmins or stubborn vendors and start considering that it's genuinely just a bad and hard to understand standard.

In 2050 we'll still be on IPv4. That's how bad I think IPv6 is. Technically impressive? Sure. Viable as an understandable network paradigm and designed for widespread real-life use? Looking like no.

[nybble41]

It's not that IPv6 is bad. There are no other, more successful alternative proposals to grow the address space while maintaining end-to-end connectivity. It's just a difficult coordination problem. From a purely technical point of view IPv6 works, today. It's not hard to set up IPv6 networks and connect them together. But there is a lot of IPv4-only equipment, legacy applications, etc. in active use which would have problems with any new protocol.

[arp242]

Not wrong, but I have a feeling that a protocol which changed things less would have caught on a lot faster. IPv6 changes a lot more than just expanding the address space.

32bit IPv4 gives us 4.2 billion IP addresses (although there are fewer usable addresses due to reservations etc.). If we would have just tacked on another byte we'd have 1 trillion (theoretical) IP addresses. Two extra bytes and we'd have some number I don't even know the name of (~2.7e14).

Changing from 213.113.223.023 to 142.213.113.223.023 is a lot less invasive, both for users and implementations (although increasing the address space isn't necessarily easy, it doesn't require an entire new stack).

Now, these other IPv6 changes aren't necessarily bad and also address real problems as well, but it seems IPv6 changes too much in one step for its own good. In this regard, it's not that dissimilar to Python 3 (except even worse!)

Also: one think that struck me about that list is that sites who do implement IPv6 are all Western, and that none of the Asian (mostly Chinese) sites implement IPv6. You'd expect it to be the other way round because Asian/Chinese would benefit a lot more from IPv6 since they have fewer allocated addresses, and their infrastructure also tends to be newer so legacy hardware is less of a concern. I don't know what this means or why this is the case though.

[nybble41]

> I have a feeling that a protocol which changed things less would have caught on a lot faster.

Perhaps. IPv6 had more goals than just increasing the address space. Some of these goals were interdependent; for example, just increasing the address space without doing something about routing table complexity would have been a recipe for disaster, which is part of the reason why IPv6 uses much longer addresses with a fixed number of bits reserved for the local subnet, and why it also strongly discourages the non-hierarchical routing which has become commonplace in IPv4.

> Changing from 213.113.223.023 to 142.213.113.223.023 is a lot less invasive, both for users and implementations….

I would say 2602:7b:294e:d207::1 isn't much worse to remember or type than a dotted-quintet (based on, but not equal to, one of my real IPv6 addresses). Implementations don't have any issue with 128-bit addresses, and probably prefer that over an odd size like 40 bits due to alignment. Users usually don't have any reason to care about IP addresses; that's what DNS and mDNS are for. Or copy & paste if you absolutely must work with raw addresses.

> (although increasing the address space isn't necessarily easy, it doesn't require an entire new stack)

In practice, it does. You could certainly model it more closely on the original protocol, but the systems wouldn't be interoperable. System calls, library APIs, applications, and GUIs would all need to change. You'd have to rebuild all the routing hardware and redesign any protocols that embed IP addresses. Basically everything that needed to be updated to work with IPv6 would still need to be updated to work with "IPv4+1B". The changes might be smaller but it's the fact that you need to change these things at all that makes the process so difficult.

There are some other changes in IPv6 that are more debatable, like replacing DHCP with SLAAC when we could have probably just used a straightforward IPv6 adaptation of DHCPv4, at least in the beginning. SLAAC strikes me as the sort of thing that could have been deployed separately once IPv6 adoption was well underway. But I wouldn't say that these minor differences represent significant obstacles to IPv6 adoption.

It is interesting that most of Asia is trailing somewhat behind, whereas India is at the top of Akamai's charts for IPv6 adoption[0].

[0] https://www.akamai.com/visualizations/state-of-the-internet-...

[tialaramex]

Same with Security Keys, there are a bunch of technologies like this, where you can literally write documentation explaining "This is what we did at our multi-billion dollar business to successfully solve the problem" and people will walk past, fingers stuffed in their ears, hoping that some day the problem will be solved somehow, but, like, magically without them having to change or learn. Just keep doing what they're doing and then, somehow magically it'll be fine. See also: Climate change.

[notreallyserio]

For most people, IPv4 is a solution to a problem that didn’t require change or learning. It’s just what is used behind the scenes to make the web and chat and email happen. And happen it all does, without trouble, so why lots of money to replace it?

What is the sales pitch you would bring to the CEO of a Fortune 500?

[throw0101a]

> What is the sales pitch you would bring to the CEO of a Fortune 500?

When you buy or merge companies, and they both have RFC 1918 addresses, you'll probably have a conflict between the two entities. You'll probably have to implement NAT with-in your own network and hope the two sides don't have to talk to each other that much. (Or you completely re-IP the acquisition.)

With IPv6, either the companies will be using their own PI IPv6 space and/or they will be using unique ULA prefixes, so the chance of conflicts will be very small.

This at least was one of the business cases for Wells Fargo, "the fourth largest bank in the United States by total assets and is one of the largest as ranked by bank deposits and market capitalization":

* https://www.youtube.com/watch?v=EzTWjNUb4H4

[hansel_der]

for most companies the cost of an v6 transition is still greater than the cost of renumbering an aquisition.

[p1mrx]

Over time, ISPs are pushing more users to IPv6 + CGNATv4 because they don't have enough IPv4 addresses.

If an internet service needs to distinguish users by IP address, say for spam fighting reasons, then IPv6 will provide finer granularity because the addresses are not shared by multiple users. Depending on how the ISP implements CGNAT, IPv6 may also improve performance and geolocation accuracy.

(They'd also be doing those ISPs a favor, because offloading traffic to IPv6 lowers the operating costs of CGNAT.)

[dcow]

There isn't one until IPv6-only ISPs (or plans) pop up offering cheaper connectivity because you don't need an expensive v4 address. NAT sucks and everyone's job would be easier if they didn't have to deal with it, but the CEO likely doesn't care about that and probably just sees the "add IPv6 support" scope and cost estimate and NOPEs out.

I love IPv6 btw. I just don't think you'll see anything meaningful happen until FAANG drop IPv4 support. Imagine that. People would convert pretty quick if Google couldn't crawl your site or you couldn't buy an iPhone without IPv6...

[semi-extrinsic]

An IPv4 address still isn't very expensive. I'm paying about $1.30 per month to have a static IPv4 address from my home ISP.

[rnhmjoj]

That's not really the price of an IPv4 address: you don't have control over it, it's just not changing because they made a DHCP reservation or something. Owning an address means you can announce it to peers via BGP, set up PTR records, etc.

IPv4 addresses are expensive right now. Registries run out of new allocations years ago, so if you ask them you'll be put in a waiting list[1] hoping one for a block to be recovered. To get one right know you have to go on the market and negotiate a transfer: blocks are selling at ~50$/address right now. The price more than doubled in the last year or so: people are even speculating on it [2].

[1]: https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-pool

[2]: https://teddit.net/r/investing/comments/qdple3/i_am_planning...

[sedachv]

It's not just speculating, there is even large-scale IPv4 address allocation fraud going on:

https://www.internetgovernance.org/2021/08/19/a-fight-over-c...

[p1mrx]

Your ISP probably hasn't tried to acquire IPv4 addresses recently. https://ipv4.global/reports/ shows prices around $40/address, so it would take 2-3 years to break even at $1.30/month.

(Although, people rent apartments with break-even periods well beyond 10 years, so maybe 2-3 is still fine.)

[sedachv]

> There isn't one until IPv6-only ISPs (or plans) pop up offering cheaper connectivity because you don't need an expensive v4 address.

This has been happening for years with VPSes.

[Gigachad]

Consumer ISPs don't need an ip per customer. They just stick 1000 users on the same ip address behind CG-NAT

[seiferteric]

> it can also be hard to remember longer IPv6 addresses

mDNS helps since you can use hostname.local without having to set up a DNS server. I was going to make a joke blog post about using ipv4 addresses as hostnames so you can "keep using ipv4" while actually using ipv6, but I found you can't have "." in hostnames, so maybe instead use "-".

[arianvanp]

Problem is .local domains don't resolve everywhere . E.g. on mobile or chrome's own DNS stack :(

[nybble41]

If you run your own DNS resolver for your local network, you can use a Discovery Proxy (RFC 8766) to allow unicast DNS resolution of multicast DNS records. I'm using mdns-discovery-proxy[0] (slightly modified to support a newer version of the zeroconf Python library) with bind9 so that xyz.local is mirrored in unicast DNS as xyz.home.arpa. The script (proxy.py in Git; I renamed it) is run with this systemd service (/etc/systemd/system/mdns-discovery-proxy.service):

  [Unit]
  Description=DNS-SD Proxy
  After=network.target network.service

  [Service]
  Type=simple
  DynamicUser=yes
  ExecStart=/usr/local/bin/mdns-discovery-proxy.py home.arpa 35353
  Restart=always
  RestartSec=30

  [Install]
  WantedBy=multi-user.target

And the bind9 configuration to forward the zone is (in /etc/bind/named.conf.local):

  zone "home.arpa" {
    type forward;
    forward only;
    forwarders { 127.0.0.1 port 35353; };
  };

[0] https://github.com/nybble41/mdns-discovery-proxy

[iknowstuff]

For me, both iOS and Chrome on Windows resolve .local.

[rhn_mk1]

Does mDNS work across VPN tunnels? The main reason I delay IPv6 is because I access hosts across the VPN by their IPs, and I don't want to publish their DNS records.

[mustardo]

If you run your own internal DNS server: https://en.m.wikipedia.org/wiki/Split-horizon_DNS

[rhn_mk1]

I guess that's equivalent to setting up a hosts file... Unless the DNS resolver can be configured to treat a selected server on the VPN side as authoritative for .mynetwork.

[megous]

Not currently. ff02::fb is used, which has link-local scope.

[fuzzy2]

Also, ULA. You can have both “real” (internet-routable) IPv6 addresses for all devices as well as (fixed) ULA addresses for local communication and ease of use. fd00:dead:beef::/64

[pantalaimon]

Amazon invested so much in IPv4 address space, they have no interest in supporting IPv6.