3 ms·

And no wonder they think that when they ignore all of the benefits of doing v6 and only look at the costs _and_ ignore all of the costs of staying exclusively v

And no wonder they think that when they ignore all of the benefits of doing v6 and only look at the costs _and_ ignore all of the costs of staying exclusively v4. If you have a web store, subscriptions or ads, you'll have conversion metrics. Even small changes in your website's page load time (just hundreds of milliseconds) can have noticeable impacts on these metrics, and therefore on your income. Facebook say they see 10-15% faster page loads[1] on v6, so not having it is costing you money. [1] https://engineering.fb.com/2015/09/14/networking-traffic/ipv6-it-s-time-to-get-on-board/ https://engineering.fb.com/2015/09/14/networking-traffic/ipv... If you don't have v6, you have to do everything on v4. In practice that inevitably means dealing with RFC1918 and NAT, which means dealing with split DNS, VPNs, RFC1918 clashes and cross-NATing, and all the other problems which come with all that. That costs engineer time and therefore money. Most companies don't even know how much these two points are costing them. How can you balance this against the cost of doing v6 when you don't even know one of the values you're balancing? Most parts of v6 deployment should happen as part of your regular work: you shouldn't need to replace equipment specially for v6 because you should be buying v6-capable equipment as part of normal procurements, and you should be configuring v6 when you configure v4, and so on. So why is v6 deployment its own special project with its own budget, when the costs of v4 are rolled up into your regular budget and treated as if they're zero? Put all of this together and you end up with an incredible and unjustified bias against v6.

lxgr 3y ago
> they ignore all of the benefits of doing v6 and only look at the costs _and_ ignore all of the costs of staying exclusively v4. Nobody is ignoring all costs. People are just mostly interested about costs incurred by themselves only. This can and often does yield globally suboptimal outcomes. Not sure what exactly the game-theoretical term for this is. > Facebook say they see 10-15% faster page loads[1] This is quite surprising! Is there any explanation for this observed behavior? Are there saturated v4 paths that have a less congested v6 alternative? Are CG-NATs adding that much latency? > If you don't have v6, you have to do everything on v4. In practice that inevitably means dealing with RFC1918 and NAT, which means dealing with split DNS, VPNs, RFC1918 clashes and cross-NATing, and all the other problems which come with all that. That costs engineer time and therefore money. I think you're thinking about the eyeball ISP side here; I was mostly talking about the data center/cloud side of things, where the situation is quite different: As long as there is a non-negligible customer IPv4-only user base, you need to be dual-stack, which will always cost more in terms of management than IPv4 or IPv6 only. For eyeball ISPs, as I've mentioned in my post above, the economics can indeed be different: If they're IPv4-contrained, they'll probably need NAT anyway, and 464XLAT can make that significantly easier than doing IPv6-only CG-NAT, while also providing native IPv6 connectivity. Put together, this yields the following game-theoretical situation: - On the eyeball side, you need IPv4 (either natively or increasingly commonly via some version of CG-NAT) for IPv4-only services. You can add IPv6 for more efficient connections to dual-stack servers, and many eyeball ISPs already do. 464XLAT or DS-Lite make CG-NAT more scalable (some ISP networks are too large to fit into a private /8 network!). - On the server/hosting side, you need IPv4 (for IPv4-only eyeballs), and only IPv4 (since there are practically no IPv6-only eyeballs). You can add IPv6 for a bit more performance, but you need to be dual-stack capable, for the IPv4-only eyeballs which you can't afford to lose. The result is: The largest players support IPv6, yet we might well be stuck with a long tail of IPv4-only properties for the next decade or more.
- marcosdumay 3y ago
  > Are there saturated v4 paths that have a less congested v6 alternative? Every time I saw that kind of gain, it was mostly due to slow DNS and browsers or caches preferring IPv6 data. The entire internet needs to optimize for one of those, as they some times conflict. And the obvious one to optimize for is the one that will keep working in the future. But those conflicts tend to be on accidental features at the margin; there is a small amount of problems caused by the large routing tables of IPv4, but on the main networking problems they were designed to behave almost the same.
- Dagger2 3y ago
  > This is quite surprising! Is there any explanation for this observed behavior? Are there saturated v4 paths that have a less congested v6 alternative? Are CG-NATs adding that much latency? I can give a few theories. Some CGNAT setups do add a lot of latency (e.g. T-Mobile hand v6 traffic off locally where possible but v4 has to be hauled to one of their CGNAT installations, which might be a long way away). Some CGNATs are outright overloaded. v6 doesn't have a checksum, so routers don't need to update the checksum when they fiddle the TTL header. NAT must add some latency too. A "page load" involves lots of round-trips, so even a very small difference in round-trip time can add up to make a bigger difference in page load time. (This does suggest that improvements to HTTP and rate control algorithms to reduce the number of round-trips would narrow the difference.) > I think you're thinking about the eyeball ISP side here I was thinking about "company internal" networks, both their own internal networks but also the internal parts of their hosting setups. In hosting, it's generally true that you need to handle v4-only clients... but that can be handled entirely at the edge by your load balancers or by NAT46, it doesn't force you to use v4 inside at all. You can use v6 inside, and it'll be easier and cheaper than v4 for the reasons I mentioned. > we might well be stuck with a long tail of IPv4-only properties for the next decade or more NAT64 can handle the long tail of v4-only websites for v6-only clients, so this is actually okay. It's not blocking deployment of v6 or undeployment of v4. The only real problem it causes is that people use it as an excuse to not do v6...
  - lxgr 3y ago
    Well said – and it's mutually reinforcing excuses, even: Hosters don't need v6 because eyeballs support v4 anyway (through NAT); eyeballs don't need IPv6 because there's no v6-exclusive content. But I suspect that that'll resolve at the very latest when v4 exhaustion starts hurting hosters (and maybe ISPs, they still need a few for CG-NAT after all) in earnest. And once ISPs run out of internal v4 space and switches to v6 for that, there's no point in not just supplying public v6 addresses as well.

lxgr 3y ago

> they ignore all of the benefits of doing v6 and only look at the costs _and_ ignore all of the costs of staying exclusively v4. Nobody is ignoring all costs. People are just mostly interested about costs incurred by themselves only. This can and often does yield globally suboptimal outcomes. Not sure what exactly the game-theoretical term for this is. > Facebook say they see 10-15% faster page loads[1] This is quite surprising! Is there any explanation for this observed behavior? Are there saturated v4 paths that have a less congested v6 alternative? Are CG-NATs adding that much latency? > If you don't have v6, you have to do everything on v4. In practice that inevitably means dealing with RFC1918 and NAT, which means dealing with split DNS, VPNs, RFC1918 clashes and cross-NATing, and all the other problems which come with all that. That costs engineer time and therefore money. I think you're thinking about the eyeball ISP side here; I was mostly talking about the data center/cloud side of things, where the situation is quite different: As long as there is a non-negligible customer IPv4-only user base, you need to be dual-stack, which will always cost more in terms of management than IPv4 or IPv6 only. For eyeball ISPs, as I've mentioned in my post above, the economics can indeed be different: If they're IPv4-contrained, they'll probably need NAT anyway, and 464XLAT can make that significantly easier than doing IPv6-only CG-NAT, while also providing native IPv6 connectivity. Put together, this yields the following game-theoretical situation: - On the eyeball side, you need IPv4 (either natively or increasingly commonly via some version of CG-NAT) for IPv4-only services. You can add IPv6 for more efficient connections to dual-stack servers, and many eyeball ISPs already do. 464XLAT or DS-Lite make CG-NAT more scalable (some ISP networks are too large to fit into a private /8 network!). - On the server/hosting side, you need IPv4 (for IPv4-only eyeballs), and only IPv4 (since there are practically no IPv6-only eyeballs). You can add IPv6 for a bit more performance, but you need to be dual-stack capable, for the IPv4-only eyeballs which you can't afford to lose. The result is: The largest players support IPv6, yet we might well be stuck with a long tail of IPv4-only properties for the next decade or more.

marcosdumay 3y ago
> Are there saturated v4 paths that have a less congested v6 alternative? Every time I saw that kind of gain, it was mostly due to slow DNS and browsers or caches preferring IPv6 data. The entire internet needs to optimize for one of those, as they some times conflict. And the obvious one to optimize for is the one that will keep working in the future. But those conflicts tend to be on accidental features at the margin; there is a small amount of problems caused by the large routing tables of IPv4, but on the main networking problems they were designed to behave almost the same.
Dagger2 3y ago
> This is quite surprising! Is there any explanation for this observed behavior? Are there saturated v4 paths that have a less congested v6 alternative? Are CG-NATs adding that much latency? I can give a few theories. Some CGNAT setups do add a lot of latency (e.g. T-Mobile hand v6 traffic off locally where possible but v4 has to be hauled to one of their CGNAT installations, which might be a long way away). Some CGNATs are outright overloaded. v6 doesn't have a checksum, so routers don't need to update the checksum when they fiddle the TTL header. NAT must add some latency too. A "page load" involves lots of round-trips, so even a very small difference in round-trip time can add up to make a bigger difference in page load time. (This does suggest that improvements to HTTP and rate control algorithms to reduce the number of round-trips would narrow the difference.) > I think you're thinking about the eyeball ISP side here I was thinking about "company internal" networks, both their own internal networks but also the internal parts of their hosting setups. In hosting, it's generally true that you need to handle v4-only clients... but that can be handled entirely at the edge by your load balancers or by NAT46, it doesn't force you to use v4 inside at all. You can use v6 inside, and it'll be easier and cheaper than v4 for the reasons I mentioned. > we might well be stuck with a long tail of IPv4-only properties for the next decade or more NAT64 can handle the long tail of v4-only websites for v6-only clients, so this is actually okay. It's not blocking deployment of v6 or undeployment of v4. The only real problem it causes is that people use it as an excuse to not do v6...
- lxgr 3y ago
  Well said – and it's mutually reinforcing excuses, even: Hosters don't need v6 because eyeballs support v4 anyway (through NAT); eyeballs don't need IPv6 because there's no v6-exclusive content. But I suspect that that'll resolve at the very latest when v4 exhaustion starts hurting hosters (and maybe ISPs, they still need a few for CG-NAT after all) in earnest. And once ISPs run out of internal v4 space and switches to v6 for that, there's no point in not just supplying public v6 addresses as well.