Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Hits 50% IPv6

blog.apnic.net

Post reply on HN
Print view View original

491–496 of 496 posts

Re: Google Hits 50% IPv6

#491

Post by tgma »

Dagger2 wrote: post #484
tgma wrote: post #472

Earlier quoted context omitted.

I was talking about internet at large. You , and many clients, are of course able to do it on your box, but to use the whole internet, you will at some point hit a translation point which uses v4. The point is the internet at large is never going to reach a point where there won't be two internets; at this point it is pretty clear v6-only will not be a thing with the current set of technologies before a future protoc…

There were always expected to be v4 hosts on the Internet effectively indefinitely. That's not a failure condition for v6. "There are a couple of v4-only hosts out there somewhere" would be kind of irrelevant if most ISPs stop bothering to provide v4 service.

It won't be just a couple. That's the point.

The curve is at 50% after an astonishingly long time and is already flattening.

Re: Google Hits 50% IPv6

#492

Post by lloeki »

well_ackshually wrote: post #173
BrandoElFollito wrote: post #75

Earlier quoted context omitted.

You mean that Free's ipv6 is not implemented correctly?

Free has ipv6 enabled on 100% of their customers, and while sometimes their software has a few issues, it's working perfectly fine. People just get pissy because Free refuses to pay for peering with Google for e.g. Youtube, and it feels slower, even more on v6. The only ISP not putting out v6 widely is SFR, and thankfully they've gone bankrupt and we will be rid of this scourge.

I've been on SFR and had IPv6 for a decade at this point (through multiple moves and on mobile). It's been absolutely reliable in every way.

One of the huge holdups for v6 deployment was the absorbtion of the then DOCSIS2-based Numericable, which required a huge migration to DOCSIS3 to even support it, as well as integration of the whole network backhaul that came with it.

The reputation _was_ justified at some point far back but they turned the ship around a long time ago and is now entirely an unjustified meme.

These past years it's been SFR (via RED) who was keeping the prices competitive, so I can't wait to see the remaining three vultures collude to raise the prices back up again /s.

> People just get pissy because Free refuses to pay for peering with Google for e.g. Youtube, and it feels slower, even more on v6.

Well when one's paying for a heavily marketed "the fastest around" 1Gbps+ connection or something, and it indeed negotiates the link at that, but one can't play a 720p video over that tube because backhaul routing sucks, one has a right to be annoyed.

Re: Google Hits 50% IPv6

#493

Post by adithyassekhar »

mahboi wrote: post #450
adithyassekhar wrote: post #176

Whenever I turn on ipv6 on my router (isp supports it, dual stack) randomly I get half the download speeds, YouTube video freezes, and eventually a captcha screen on google. The moment I disable v6 even only at the client side I get to max out my bandwidth. Tested on google drive, sites on azure and aws and netflix’s fast.com which show’s your ip just to confirm I was connecting over v6.

Maybe your ISP is really tunneling v6 over v4?

No the server is getting an ipv6 address and verified on those test sites. This seems bad routing.

Re: Google Hits 50% IPv6

#494

Post by jck86 »

BadBadJellyBean wrote: post #126
jck86 wrote: post #60

Earlier quoted context omitted.

In my experience not true in practice cause I have experienced way more issues with the IPv6 endpoints of sites than their IPv4 counterparts. This becomes noticeable when pipelines on IPv6 connected servers suddenly have random request/post failures to public services. Then either the whole service is temporarily having issues or there are a few bad IPv6 endpoints while all the IPv4 endpoints are fine. Seemingly this…

I have been on a dual stack IPv4 and IPv6 connection for a while now. IPv6 is the preferred protocol. I think I'd have noticed if there were widespread IPv6 issues. It used to be worse, but that was years ago.

It is not widespread. Not for the major services at least. But saying IPv6 is better than IPv4 with lower latency due to better routing and lower overhead simply is not true. Apparently there are other factors at play that also matter a great deal and still lead to teething problems.

Re: Google Hits 50% IPv6

#495

Post by jck86 »

Dagger2 wrote: post #418
jck86 wrote: post #138

Earlier quoted context omitted.

There were indeed consistent failures to specific IPv6 endpoints, clearly identifiable through curl, while all the IPv4 endpoints were ok. This happened with pypi (IPv6 BGP routing problem caused by a bad route from one of our peers combined with their fastly CDN not reply to us on IPv6 from the other side of the ocean for some weird reason), but also with yum and apt mirrors (seemingly random problems with the IPv6…

Try `ip link set mtu 1280 dev eth0` (or equivalent for your OS). pMTUd breakage exists on v6 just like it exists on v4, and requires workarounds just like it does on v4. I get the impression a lot of people are applying a workaround on v4 but not on v6, then blaming the resulting failures on v6 without bothering to do any troubleshooting to figure out what's actually wrong.

This was not a path mtu problem since it was random IPv6 endpoints having issues.

And if all the IPv6 endpoints of a major service go down we should pin our mtu to the bare minimum? Nonsense.

The inconvenient truth is that IPv4 will be more stable than IPv6 until the former gets demoted to second class fallback protocol instead of the major driver of the internet. And when that happens no one knows.

Re: Google Hits 50% IPv6

#496

Post by Dagger2 »

jck86 wrote: post #495
Dagger2 wrote: post #418

Earlier quoted context omitted.

Try `ip link set mtu 1280 dev eth0` (or equivalent for your OS). pMTUd breakage exists on v6 just like it exists on v4, and requires workarounds just like it does on v4. I get the impression a lot of people are applying a workaround on v4 but not on v6, then blaming the resulting failures on v6 without bothering to do any troubleshooting to figure out what's actually wrong.

This was not a path mtu problem since it was random IPv6 endpoints having issues. And if all the IPv6 endpoints of a major service go down we should pin our mtu to the bare minimum? Nonsense. The inconvenient truth is that IPv4 will be more stable than IPv6 until the former gets demoted to second class fallback protocol instead of the major driver of the internet. And when that happens no one knows.

People running servers don't seem to be reliably capable of making sure that either pMTUd works or isn't needed on their network, so... it is indeed broken on random servers.

We've mostly decided to go with TCP MSS clamping rather than using the minimum MTU, which is still nonsense but it's nonsense that we already decided to go with for the same problem in v4.

Of course, I don't have enough info to tell if this was the problem or if it was something else, or a mix of the two, but pMTUd does seem to be a leading cause of "fails to load for some weird reason" problems.

Post reply on HN