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

IPv6 traffic crosses the 50% mark

google.com

Post reply on HN
Print view View original

471–480 of 643 posts

Re: IPv6 traffic crosses the 50% mark

#471

Post by cyberax »

throw0101d wrote: post #397
cyberax wrote: post #127

Earlier quoted context omitted.

IPv6 is a recursive WTF. It might _look_ like a conservative expansion of IPv4, but it's really not. A lot of operational experience and practices from IPv4 don't apply to IPv6. For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean. In IPv6 each host has multiple global addresses. But if your global connection goes down, these addresses…

> For example, in IPv4 each host has one local net address, and the gateway uses NAT to let it speak with the Internet. Simple and clean. If you think NAT is "simple and clean", you may wish to investigate STUN/TURN/ICE. An entire stack of protocols (and accompanying infrastructure) had to be invented to deal with NAT. Heaven help you if your ISP uses CG-NAT.

I can type entire SIP handshakes from memory. And by now I'm convinced that STUN/TURN are a superior solution to IPv6, even with CGNAT.

Others agree with me. Don't believe me? Try to find a SIP provider in the US that has IPv6 connectivity. Go on. Try it.

Re: IPv6 traffic crosses the 50% mark

#472

Post by himata4113 »

If anyone is confused on adoption is so slow when supporting it is easier than ever the reason is actually quite simple: it's expensive.

Switches and routers have a little thing called TCAM memory, the premise behind it is that it allows you to single-cycle O(1) lookup any ips destination. Usually to replicate it you could have a 4gb*2 preallocated contiguous buffer, but that's not something that is wildly supported or used and this completely breaks down when you expand to the IPv6 range.

The problem lies in that in a lot of cases TCAM can no longer hold the entire IPv4 routing table and now if you introduce IPv6 you are expected to handle double the routes which degrades switching performance as more active routes have to be evicted and fall back to software routing.

Routes are not the only thing that take up TCAM memory: the firewall rules, internal routing, vlans, everything becomes double and TCAM memory cannot be dynamically adjusted at runtime to allocate space so what happens is that you need to sacrifice IPv4 space in TCAM permenantly even if nobody is using IPv6.

This is where it gets worse: if you have ever attempted to use IPv6 you will notice that is significantly slower than IPv4 and that is because most ISPs simply opted to use software routing for IPv6 which coupled with 4-10 hops is nearly double the latency in some cases (0.5ms to 1ms) while having throttled bandwidth to not overload the CPU.

That's why network engineers will continue to refuse to (properly) support IPv6. If I had to guess the "properly" supported IPv6 percentage is less than 10%.

Re: IPv6 traffic crosses the 50% mark

#473

Post by unethical_ban »

ectospheno wrote: post #297
usui wrote: post #5

It has barely hit 50% and it's already plateauing. This adoption rate is ridiculous despite basically all network interfaces supporting it. I thought I would see IPv6 take over in my lifetime as the default for platforms to build on but I can see I was wrong. Enterprise and commercial companies are literally going to hold back internet progress around 60 to 75 years because it's in their best interest to ensure users…

> Also, notice how Android and iOS don't support turning off IPv4. You can trivially connect an iOS device via IPv6 only.

I think they're saying you can't force disable ipv4 entirely.

Re: IPv6 traffic crosses the 50% mark

#474

Post by mmbleh »

Hikikomori wrote: post #456
hkt wrote: post #453

Earlier quoted context omitted.

No, IPv6 as it is supposed to be implemented gives (say) a single server a /64, which is for all intents and purposes an inexhaustible supply of IPs. You could in principle have an IP per site you visit and have plenty left to spare. Random Google result with a bit more: https://www.captaindns.com/en/blog/ipv6-subnet-sizes-48-vs-5... So if I wanted to annoy GitHub, I could connect to them without ever using the same…

Its not harder to rate limit a /64 though.

It is because the IPv6 rollout has not been consistent. Some assign /64 per machine, some assign /64 per data center. Some even go the other way and do a /56 per machine. We've had to build up a list of overrides to do some ranges by /64 and others by /128 because of how they allocate addresses. This creates extra burden on server operators and it's not surprising that some just choose not to deal with it.

Re: IPv6 traffic crosses the 50% mark

#475

Post by vhcr »

CupricTea wrote: post #339
growse wrote: post #19

Earlier quoted context omitted.

A non-trivial minority of the time, they don't support IPv4 either!

GitHub is at the point where it immediately rate limits me if I try to look at a project's commit history without being logged in, as in the first time I even open a single URL to the commit history, I get "Too Many Requests" from GitHub thrown at me. I don't know if my work's antivirus stack is causing GitHub to be suspicious of me, but it's definitely egregious.

My theory is that they rate limit that URL aggressively due to AI scrapers. At this point it's faster to just clone the repo and do your searching locally.

Re: IPv6 traffic crosses the 50% mark

#476

Post by reincarnate0x14 »

sidewndr46 wrote: post #259
growse wrote: post #19

Earlier quoted context omitted.

A non-trivial minority of the time, they don't support IPv4 either!

should we try going back to IPX ?

Comically IPv6 now has almost all the neat stuff IPX did. There probably is an argument for more datagram centric networking these days as the underlying services are generally much faster and more reliable and there is so much more session tracking going on at higher application layers anyway.

Re: IPv6 traffic crosses the 50% mark

#477

Post by azernik »

colmmacc wrote: post #143

If GitHub flipped a switch and enabled IPv6 it would instantly break many of their customers who have configured IP based access controls [1]. If the customer's network supports IPv6, the traffic would switch, and if they haven't added their IPv6 addresses to the policy ... boom everything breaks. This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And cu…

> providers don't have an easy way to correlate addresses

Yes, they do. It's called DNSSEC.

Re: IPv6 traffic crosses the 50% mark

#478

Post by wolrah »

hkt wrote: post #453
nickserv wrote: post #443

Earlier quoted context omitted.

I don't understand, wouldn't it make it easier?

No, IPv6 as it is supposed to be implemented gives (say) a single server a /64, which is for all intents and purposes an inexhaustible supply of IPs. You could in principle have an IP per site you visit and have plenty left to spare. Random Google result with a bit more: https://www.captaindns.com/en/blog/ipv6-subnet-sizes-48-vs-5... So if I wanted to annoy GitHub, I could connect to them without ever using the same…

> No, IPv6 as it is supposed to be implemented gives (say) a single server a /64, which is for all intents and purposes an inexhaustible supply of IPs. You could in principle have an IP per site you visit and have plenty left to spare.

No, as it's supposed to be implemented a single internet-routable /64 is used per *network* and then most devices are expected to assign themselves a single address within that network using SLAAC.

ISPs are then expected to provide each connected *site* with at least a /56 and in some cases a /48 so the site's admins can then split that apart in to /64s for whatever networks they may have running at the site. That said, I'm on AT&T fiber and I am allocated a /60 instead, which IMO is still plenty for a home internet connection because even the most insane homelab setups are rarely going to need more than 16 subnets.

> So if I wanted to annoy GitHub, I could connect to them without ever using the same IP twice. Their response would have to be banning my /64, or possibly /56.

Well yeah, but it's not like it's exactly rocket science to implement any sorts of IP rate limiting or blocking at the subnet level instead of individual IP. For those purposes you can basically assume that a v6 /64 is equivalent to a v4 /32. A /56 is more or less comparable to /25 through /29 block assignments from a normal ISP, and a /48 is comparable to a /24 as the smallest network that can be advertised in the global routing tables.

Re: IPv6 traffic crosses the 50% mark

#479

Post by crest »

himata4113 wrote: post #472

If anyone is confused on adoption is so slow when supporting it is easier than ever the reason is actually quite simple: it's expensive. Switches and routers have a little thing called TCAM memory, the premise behind it is that it allows you to single-cycle O(1) lookup any ips destination. Usually to replicate it you could have a 4gb*2 preallocated contiguous buffer, but that's not something that is wildly supported…

What shitty ISP operates like that? I frequently see IPv6 have *lower* latency because of fewer middle boxes and fewer hops in general. Your routers in the default free zone shouldn't be close to their TCAM limits with a single IPv4 routing table.

Re: IPv6 traffic crosses the 50% mark

#480

Post by azernik »

marginalx wrote: post #373

Is most of that due to mobile? The real migration challenges are in the server side/consumer home internet space which I'm not sure if there are clear stats around the adoption there. I think IPV6 is a great example of over engineering, trying to do too much in one iteration. In an ideal scenario this could work, but in the context of large scale change with no single responsible party, it usually doesn't work well.

The problem has nothing to do with over engineering, or really anything to do with the actual contents of the IPv6 standard. It is just devilishly hard to make any backwards-incompatible change to layer 3, and address expansion is always going to be backwards incompatible.
Post reply on HN