Hacker News Reader

Comment by shmerl | Hacker News Reader

IPv6 adoption is surprisingly slow. Shouldn't it happen faster?

It's a classic chicken and egg problem. IPv4 is still "good enough" as far as most people are concerned, so even with the squeeze on available addresses, there's just not quite enough need to come over the inertial against supporting IPv6. Because of that, there's no demand driving adoption from any particular side: ISPs can get away with giving people IPv4 addresses only because IPv4 space is where all the content is, hosting providers have no great impetus so long as they're not seeing much IPv6 traffic[1], their customers know IPv4 and the benefits of all the additional address space are either too abstract or too scary ('Oh, my! That IP address is huge!'), and there's still enough legacy networking equipment, both professional and home, that only supports IPv4 that it can be hard to make a business case to get rid of.

[1] Which is a pity, though not at all universal. The hosting company I work for takes pride in the fact that nearly our whole network, except for some colo boxes, some rapidly disappearing legacy boxes, and the like, is dual stack. Not all hosting providers think this way, and even when they do, they're customers often just ignore IPv6 because they know IPv4 and that's good enough for them. It doesn't help that an embarrassing number of ccTLD registries don't support IPv6 glue records.

Few of the big cloud providers -- EC2, Azure, etc. -- support IPv6. That's the big bottleneck.

Fundamentally I think IPv6 itself is fine, but the transition was utterly botched. They should have unshelved 240.0.0.0/4 and mapped IPv6 onto it, allowing IPv4 applications to access select "early adopter" regions of IPv6. That would have been a start.

IPv4 to IPv6 mapping exists for a long time https://en.wikipedia.org/wiki/6to4

No, no no no. 6to4 as a mechanism is the worst mistreatment you can do to your users because of the way it works with asymmetric traffic paths traversing the gateways you can not control.

I think what you meant to post was this: https://en.wikipedia.org/wiki/NAT64

Neither of these are actually usable in the real world.

re. 6to4: agreed, and never will, see https://tools.ietf.org/html/rfc7526

re NAT64: not so agreed...

1. T-Mobile USA: they have few millions of IPv6-only subscribers using 464XLAT which has NAT64 as a component.

2. Starting from iOS9, every app submitted to App Store will have to work with IPv6 or across the NAT64 as a criterion for appstore submission:

http://www.internetsociety.org/deploy360/blog/2015/06/apple-...

3. my own anecdata from the IPv6-only default WiFi SSID at FOSDEM conference in Brussels this year is that ~40% of the total devices were able to use IPv6-only SSID behind NAT64 - up from about 15-20% last year. Will be interesting to see the numbers for the next year - with Android 5.0 shipping RDNSS and Apple's move with iOS, this number should go up noticeably.

A lot of SMB and even large-ish companies are in total denial mode, still. Most use IPv4 exclusively for all network connectivity. Some places disable IPv6 across the board, in other places it remains enabled by default but ignored.

Some devices won't work, people need retraining, security with less tested stacks is a concern, addresses are harder to remember. It's a nontrivial change to push on to an established network, with a horizon for payoffs beyond the standard political term.

A recent presentation [1] at RIPE conference highlighted that only 6 of the top 30 carriers in the world (based on customer value) are doing anything visible with IPv6. I suspect the rest have some IPv6 strategy cooking on the back burner, but are in no hurry to deploy until their hand is forced.

[1] https://youtu.be/hrEh40_H4r4?t=730

Reply on news.ycombinator.com