Live data from Hacker News

United States IPv6 adoption over 50%

google.com

151–160 of 164 posts

Re: United States IPv6 adoption over 50%

#151
post #32

Earlier quoted context omitted.

Maybe a bit glib, but I see this as a good thing: a reason to finally fix whatever process requires you to transcribe IP addresses, which is a pain to do even with v4 ones.

Definitely not a pain for a LAN. Case in point: navigating to your router’s web interface. Very easy to do with IPv4 to do, a pain with IPv6. As my home router only supports stateless auto configuration, it’s an additional friction point to have stable addresses. Oh, and since the /56 is assigned by my ISP, it sometimes changes, so I can’t just rely on addresses being stable. I’m not saying that IPv6 is necessarily b…

So routers should inject DNS for LAN devices, that's how mine is set up. Admittedly it can be a small pain with some browsers defaulting to DNS over HTTPS and bypassing the router's DNS, but that's pretty recent and fixable.

I go to `router.localnet`, not some IP I have to remember.

Re: United States IPv6 adoption over 50%

#152

Earlier quoted context omitted.

It is - but if you have multiple subnets on your local lan you should have local DNS or similar (or know prefix:1::1 is the router, etc).

But in that case, that is considerably more difficult than just IPv4, as I now need to remember the prefix. Which isn’t stable, as it’s often reassigned by my ISP.

Are ISPs really doing dynamic IPs for v6? That seems incredibly silly.

Re: United States IPv6 adoption over 50%

#153

Earlier quoted context omitted.

That's latency impact (vs v4) not just latency. -10 would mean IPv6 connections typically had better latency than IPv4 connections. This was more an concern during the early days of IPv6 deployment.

Exactly, but we are not in the early days anymore. So how is, in today's world, v6 "10ms faster" than v4? ISPs didn't magically create v6-only exchanges that happen to be in a more direct path to Google.

As a clarification the more we are not in the early days anymore the lower the IPv6 latency is expected to be so being this far along is a supporting reason not a how come.

It's likely not the peering points creating the difference at this stage. Initially they created a difference in favor of v4, now they are about equal, and later they will create a difference in favor of v6. For the moment the directness of v6 to being routed out vs v4 being sent to some centralized translation entity then being routed out is the likely culprit. Particularly since these numbers are driven primarily by mobile carriers who sometimes don't even have native v4 to the end user at all.

Re: United States IPv6 adoption over 50%

#154

Before everyone laments their ISP is part of the slow half remember the majority of this migration is still driven by the switch to users browsing on mobile device networks rather than a traditional desktop on a hardline. E.g. T-Mobile is IPv6 only for a number of years now, using 464XLAT to let customers access IPv4 only services. Also I'll throw in the standard "HN is still v4 only" :).

What is the idea of 464XLAT? We have IoT style devices using AWS. And IPv6 has long not really been available on AWS. Yeah, it has become a bit better the last 3-5 years. So we have not really worked on IPv6 for our devices either. The kernel would support it, but our user space just does not use it. The typical excuse, someone else hasn't done their homework first... Our devices work just fine with T-Mobile US SIMs.…

In 464XLAT something on the client side (be it say Android phone itself or TMobile home router) acts as a CLAT to translate local v4 to v6. On the T-Mobile egress it'll act as a PLAT and convert back. There is some other glue to make these two work together. They had a good NANOG talk on it a few years back https://youtu.be/Xl-hIyZSAmA

For other offerings like NB-IoT or business PCN you're still able to do either it's just the normal consumer services that were pushed to v6 only service. Though I'm not sure if there are still any legacy connectivity options that will fallback to v4.

Re: United States IPv6 adoption over 50%

#155

maybe a silly question - if the internet was 100% ipv6, could we do away with NATs?

Yes, though realistically there is going to be an extremely long tail of things that need v4v6 NAT to get to that point and inevitably someone is going to use v6v6 NAT with some odd justification.

Re: United States IPv6 adoption over 50%

#156
post #152

Earlier quoted context omitted.

But in that case, that is considerably more difficult than just IPv4, as I now need to remember the prefix. Which isn’t stable, as it’s often reassigned by my ISP.

Are ISPs really doing dynamic IPs for v6? That seems incredibly silly.

They usually “do” but very long lived - every time my modem died I got a new prefix. Lightning.

Re: United States IPv6 adoption over 50%

#157
post #69
post #26

Earlier quoted context omitted.

There is a lot of cultural inertia that instantly biases against anything old and stable in developer circles. It's super annoying, tbh. A subset of developers only seem comfortable with technology invented in the past 18-24 months, regardless of how untested and unstable it is. “What's this? It was written 2 years ago? It must be old and useless. I’m going to require my app to use the latest version and I don’t care…

One developer's "old and stable" is another developer's "filled with vulnerabilities that nobody will ever find let alone bother to fix because everyone assumes it's old and stable." IPv6 has been a draft standard since 1998. Get a better argument.

Had this issue with a coworker who uses a decade old version of Linux and refuses to install anything other than base packages cus it's "Stable". Well I made an in house tool, and it's not stable, since his glibc had a bug that's been fixed for a decade that made it so pthreads would break. Everytime I tried telling him it's his system before someone else found the bugfix, he would go "YOU JUST DON'T KNOW HOW TO WRITE MULTITHREADED CODE! MAKE IT SINGLETHREADED AND FIND THE BUG!"

Re: United States IPv6 adoption over 50%

#158
post #10

Earlier quoted context omitted.

There is a lot of cultural inertia that instantly biases against anything new in sysadmin/netadmin circles. It's super annoying, tbh. A subset of technologists only seem comfortable with the technology that was available when they were 18-24, regardless of how old they get. "What's this? I never needed it before, what's the sysctl to turn it off?"

As a sysadmin, I'd be fine if the stuff on top supported ipv6. E.g., I'm not aware of support for ipv6 in Kubernetes. In anticipation, where can I catch up on ipv6 routing? Does the number of route entries explode? I do need a "business reason" to adopt it, since the Center for Internet Security benchmark dings your system if it is turned on.

On the contrary, the numbers of routes decline. Since you get a single IPv6 assignment, often a /48, you can summarize all your networks to that assignment. IPv4 is a mess in this regard. Small assignments to ISP's and businesses were made to be frugal and delay address space exhaustion. This has caused the address space to be very scattered. You can see at https://bgp.potaroo.net/index-bgp.html that IPv4 has about 900k advertised routes and IPv6 has about 150k advertised routes. The IPv4 address space will fragment further now the price for IPv4 addresses is going up fast. Everyone with enough unused space will fractures their assignment and sell the unused pieces.

That's also your business reason. The price for IPv4 connectivity will go up. At some point a startup will not use IPv4 anymore because it will be too expensive. If you don't have IPv6 access you will not be able to use the services of that startup.

Price of an IPv4 address has doubled last year and gone from about $7.50 in 2016 to about $40 now. https://ipv4marketgroup.com/ipv4-pricing/ https://ipv4.global/reports/

Re: United States IPv6 adoption over 50%

#159

Earlier quoted context omitted.

What is the idea of 464XLAT? We have IoT style devices using AWS. And IPv6 has long not really been available on AWS. Yeah, it has become a bit better the last 3-5 years. So we have not really worked on IPv6 for our devices either. The kernel would support it, but our user space just does not use it. The typical excuse, someone else hasn't done their homework first... Our devices work just fine with T-Mobile US SIMs.…

In 464XLAT something on the client side (be it say Android phone itself or TMobile home router) acts as a CLAT to translate local v4 to v6. On the T-Mobile egress it'll act as a PLAT and convert back. There is some other glue to make these two work together. They had a good NANOG talk on it a few years back https://youtu.be/Xl-hIyZSAmA For other offerings like NB-IoT or business PCN you're still able to do either it'…

That's interesting. We use a Sierra Wireless EM 7455 (IIRC, not in work mode now...) with generic global firmware. I am 100% sure our software performs no 4 to 6 translation. So it would need to be in the modem. But that would mean it needs to be a standardized operator-independent protocol. Never heard that such thing exists.

> I'm not sure if there are still any legacy connectivity options that will fallback to v4.

That sounds the most likely option to me.

PS. Not able to watch the video now. Hope not to forget at a more suitable moment.

Re: United States IPv6 adoption over 50%

#160
post #144

Earlier quoted context omitted.

It mostly only broke the things it had to break. v4 isn't forwards compatible to longer address lengths, so the lack of compatibility isn't the fault of any aspect of v6's design.

v6 128-bit address was an attempt to simplify the routing. The was fear that with big routing tables that v4 stated to require 25 years ago the performance would collapse. In practice it never became an issue. Yet with smaller address space, like with just 48 bits, connecting from v6 to v4 address would be possible with much less complex nat.

That was part of it, but there was also a desire to be very sure we had enough address space to avoid needing to go through this again. SEND and privacy extensions also make use of the 128-bit address to add some security.

It's already possible to connect from v6 to v4, and using 48-bit addresses wouldn't make doing so any easier. 48 bits would also be way too small; there'd be no point in going to this amount of effort to update IP only to then have to do it a second time straight afterwards.

Post reply on HN