Live data from Hacker News

Google Hits 50% IPv6

blog.apnic.net

471–480 of 496 posts

Re: Google Hits 50% IPv6

#471
post #467

Earlier quoted context omitted.

Do I? I don't have v4 on this machine and I can reach GitHub, so that appears to be untrue. Also GitHub would need to continue having v4 so that v4 users could reach it, so it's untrue from that perspective too. At some point or another, you have to do the work to support longer addresses. In your proposal, where is that work being done? Because right now it looks like you're either massively underestimating how much…

Github.com doesn't have an AAAA record, so I don't know how you're reaching it if you don't have a v4 anywhere. Even if they had that, they said that basic features like cloning repos won't work over v6. Only one example of many services like this. > In your proposal, where is that work being done? Work for longer v5 addrs would be similar in difficulty to what v6 had to do, but it'd be done at a different time and p…

What do you mean when you say IPv5 works "instantly" with v4 routing tables, DHCP, DNS, and NAT? I think you're misunderstanding that any way you slice it, there will be a protocol translation. We already have many protocol translation options for v4v6, like NAT64, which I believe was referenced obliquely in the discussion about GitHub.

You should consider, if this "v4 with more bytes" idea works so well, why hasn't it been done already? Why hasn't anyone shown this idea working in practice? I'd say the answer is that, when discussing it in the abstract, it's easy to get confused by the printed address representation and miss that you're building in implicit protocol translations you don't realize have the exact same deployment difficulties as IPv6.

Take DNS as an example- when you say it works "instantly," I assume you mean "v4 works as normal, v5 reads A records and appends a zero byte"- congratulations, you've invented DNS64.

Re: Google Hits 50% IPv6

#472
post #321

Is this a failure? Absolutely. The article tries to brush this off, but there is no denying it. Operating without an IPv4 stack is not going to happen with v6.

I have no v4 on this machine. I'd disable the v4 stack on it if that was a thing Linux could do, but as it stands it's just sitting there doing nothing. The thing you're claiming is not going to happen is something I'm already doing.

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 protocol supersedes one or both.

Re: Google Hits 50% IPv6

#473
post #467

Earlier quoted context omitted.

Github.com doesn't have an AAAA record, so I don't know how you're reaching it if you don't have a v4 anywhere. Even if they had that, they said that basic features like cloning repos won't work over v6. Only one example of many services like this. > In your proposal, where is that work being done? Work for longer v5 addrs would be similar in difficulty to what v6 had to do, but it'd be done at a different time and p…

What do you mean when you say IPv5 works "instantly" with v4 routing tables, DHCP, DNS, and NAT? I think you're misunderstanding that any way you slice it, there will be a protocol translation. We already have many protocol translation options for v4 v6, like NAT64, which I believe was referenced obliquely in the discussion about GitHub. You should consider, if this "v4 with more bytes" idea works so well, why hasn't…

Meant that the states in those boxes work with ipv5. Yeah a totally unmodified ipv4 DHCP server would only accept queries over v4, but the address it leases would be valid for v5 too. I get why this part was unclear, it was assuming the aforementioned part about making things parse v5 packets was already done. Also doesn't make a lot of sense that a DHCP server would parse v5 but not support 8-byte addrs, but it could happen particularly if you put v5-v4 translation outside the box. The separation makes more sense for software-defined routers, where just making it able to parse v5 is a whole separate task from upgrading the routing tables to support 8 bytes.

Packet translation isn't strictly needed. Yeah in the 4-byte-addr phase, you could stick translators directly next to boxes, but probably better to just wait for at least routers to parse v5 packets natively. Then for the rest you do something like happy eyeballs to fall back from v5 to v4. The 8-byte phase only starts when v4 has been abandoned.

> I assume you mean "v4 works as normal, v5 reads A records and appends a zero byte"- congratulations, you've invented DNS64.

Yes to how v5 DNS works, but DNS64 doesn't work that way. It gives you a v4-mapped-v6, your packet goes there, and NAT64 translates the packet to v4. So you're still relying on ipv4, plus it takes a notoriously unpredictable route to reach the NAT64.

You could say that ipv5 is kinda like if you made v4-mapped-v6 the only way to use ipv6, didn't do NAT64, and then expanded those to >4 bytes at a later time.

> why hasn't it been done already?

It must've been considered. I'm guessing it's one or more of the IETF way back in 1998:

1. not wanting to maintain the old ipv4 blocks going forward, rather start with a clean slate to build more efficient routes

2. seeing the ipv6 design with SLAAC etc as more elegant, which in some ways it is, but some parts also didn't age well, hence the privacy extensions added later

3. thinking people would be more willing to switch

4. overestimating how many people wanted P2P connections; they were originally recommending v6 default-allow inbound, then later said consumer routers should default-deny, but this is still less idiotproof than NAT

Re: Google Hits 50% IPv6

#474
post #473

Earlier quoted context omitted.

What do you mean when you say IPv5 works "instantly" with v4 routing tables, DHCP, DNS, and NAT? I think you're misunderstanding that any way you slice it, there will be a protocol translation. We already have many protocol translation options for v4 v6, like NAT64, which I believe was referenced obliquely in the discussion about GitHub. You should consider, if this "v4 with more bytes" idea works so well, why hasn't…

Meant that the states in those boxes work with ipv5. Yeah a totally unmodified ipv4 DHCP server would only accept queries over v4, but the address it leases would be valid for v5 too. I get why this part was unclear, it was assuming the aforementioned part about making things parse v5 packets was already done. Also doesn't make a lot of sense that a DHCP server would parse v5 but not support 8-byte addrs, but it coul…

> You could say that ipv5 is kinda like if you made v4-mapped-v6 the only way to use ipv6, didn't do NAT64, and then expanded those to >4 bytes at a later time.

I guess I don't understand. This seems to boil down to: expand the address space, but don't actually use the additional space until a flag day that occurs after every piece of networking equipment on the Internet gets upgraded? Surely there would be even _less_ incentive to upgrade, because instead of getting local benefits that are incomplete until the entire network upgrades, you get _no_ benefits until the entire network upgrades.

This seems strictly worse than the situation we have now, where at least locally, you can reap benefits from IPv6's expanded address space. I benefit from having a routable /56 at home, even though I can't get to it from some legacy networks.

Re: Google Hits 50% IPv6

#475
post #473

Earlier quoted context omitted.

Meant that the states in those boxes work with ipv5. Yeah a totally unmodified ipv4 DHCP server would only accept queries over v4, but the address it leases would be valid for v5 too. I get why this part was unclear, it was assuming the aforementioned part about making things parse v5 packets was already done. Also doesn't make a lot of sense that a DHCP server would parse v5 but not support 8-byte addrs, but it coul…

> You could say that ipv5 is kinda like if you made v4-mapped-v6 the only way to use ipv6, didn't do NAT64, and then expanded those to >4 bytes at a later time. I guess I don't understand. This seems to boil down to: expand the address space, but don't actually use the additional space until a flag day that occurs after every piece of networking equipment on the Internet gets upgraded? Surely there would be even _les…

You can use the 8-byte addresses earlier if you want, just requires your hosts and stuff in between to support v5, same story as with v6 there.

The point is that you aren't asking everyone to do nearly as difficult of a migration to support v5. Github would've been on it already, all the v6 pieces are already there.

Re: Google Hits 50% IPv6

#476

Earlier quoted context omitted.

Sure they didn't just mean they'd change your static IPv4 address to a different one?

Quite possibly. But the way that they dealt with the whole thing smelt very "we don't know what we're talking about", enough to put us off. And shifting all the IP space about would have had costs with very little return, so little business appetite to go through it.

Was that real DIA??

I’ve seen this commonly from them with residential service. They mostly give you a private v4 address behind CGNAT in addition to IPv6. If you want a public v4 they put you on their old network which has no v6.

Re: Google Hits 50% IPv6

#477
post #342

Earlier quoted context omitted.

The way to pressure ISPs to support IPv6 is stupid but effective: 1. Sites that help shoppers choose can add a big visual red flag to any ISP that doesn’t support IPv6. Consumers don’t know what IPv6 is by and large but they do understand seeing a big red flag. 2. Same thing for websites. Add a banner that says “hey your ISP doesn’t support proper internet connectivity which this site utilizes. Contact them to let th…

From a US perspective, for your #1, the idea of people “shopping” for broadband, is astonishing. Most people here have available to them one single DOCSIS provider and that’s it. A few lucky ones have a FTTP option too, but that definitely not available to more than 25% of addresses. (It’s true that you can use cellular for your home internet, but I consider that extremely compromised.)

Indeed.

This is a funny legacy of how telecoms was run and regulated in different countries.

Now the US has the least consumer choice, and shitty ISP practices from exploiting peering relations to selling user data.

I often said net neutrality was fine, but it was an answer to a problem created by the legally-enforced monopolies in the US.

Re: Google Hits 50% IPv6

#478
post #381
post #342

Earlier quoted context omitted.

From a US perspective, for your #1, the idea of people “shopping” for broadband, is astonishing. Most people here have available to them one single DOCSIS provider and that’s it. A few lucky ones have a FTTP option too, but that definitely not available to more than 25% of addresses. (It’s true that you can use cellular for your home internet, but I consider that extremely compromised.)

You have to decouple the physical infrastructure from the service provider - how else are you supposed to have competition in a market with a natural monopoly? It's just about the only thing the EU did right during the mandated privatization of infrastructure.

Exactly. And because the infra was never public in the US, and thus no “privatisation with rules”, it’s been a bit of a disaster.

Re: Google Hits 50% IPv6

#479
post #288
post #202

Earlier quoted context omitted.

Maybe the solution is to make IPv4 prohibitively expensive.

Or even just expensive.

It definitely costs them a lot.

Implementing v6 without doubt saves money for ISPs. Especially in the CGNAT game as those boxes aren’t cheap.

Re: Google Hits 50% IPv6

#480
post #475

Earlier quoted context omitted.

> You could say that ipv5 is kinda like if you made v4-mapped-v6 the only way to use ipv6, didn't do NAT64, and then expanded those to >4 bytes at a later time. I guess I don't understand. This seems to boil down to: expand the address space, but don't actually use the additional space until a flag day that occurs after every piece of networking equipment on the Internet gets upgraded? Surely there would be even _les…

You can use the 8-byte addresses earlier if you want, just requires your hosts and stuff in between to support v5, same story as with v6 there. The point is that you aren't asking everyone to do nearly as difficult of a migration to support v5. Github would've been on it already, all the v6 pieces are already there.

https://xkcd.com/1112
Post reply on HN