4 ms·

> None of that was needed, but why make a proper fix when you can instead do a series of band-aids? Exactly! There can't be anything beyond duct tape "engineer

> None of that was needed, but why make a proper fix when you can instead do a series of band-aids? Exactly! There can't be anything beyond duct tape "engineering" in IT, because worse is "better"… You know? Doing things properly would cost money. Nobody is willing to pay. So nothing will ever change.

lxgr 3y ago
> Doing things properly would cost money. Nobody is willing to pay. So nothing will ever change. That's not a fair characterization of the problem: Unless everybody switches at the same time (~impossible), IPv6 requires paying for both stacks until the migration is complete. That's simply not economical, and not everybody on the internet can afford to disregard economics that way. I'm also running IPv6 on all my hobbyist projects, but I really can't blame anyone that doesn't.
- lloeki 3y ago
  It's a game theory problem: nobody wanted to foot the bill on their side, endlessly punting and waiting for others to foot it for them. End result is that now everyone foots a different, worse bill, yet will still have to foot the previous bill because the workarounds have their limits when the attrition game pans out.
- marcosdumay 3y ago
  > IPv6 requires paying for both stacks until the migration is complete Yeah, the IP licensing costs are sure to bankrupt you. Only hobbyists have enough money to do it. Large corporations can not afford the money and labor.
  - lxgr 3y ago
    Hobbyists: "Wanna do IPv6? It's cool and we'll do our part for incentivizing people to also switch! It should only take a couple of Saturday afternoons." "Sure, sounds cool, let's do it!" Meanwhile, at any average corporation: "Ok, so implementing IPv6 will cost us x$ and n person months, got it. And the upside is that we'd get a badge on some IPv6 readiness site, yes? And what would be the consequence, for us, of not doing this? Interesting, absolutely nothing you say, at least until every single customer is at least on IPv6 dual stack, since we need to provide our existing IPv4 stack too? Cool, thank you for presenting, please don't come again!" About the only large commercial entities that see any benefits of rolling out IPv6 are eyeball-heavy ISPs (since selling native IPv6 + CG-NAT for IPv4 is a slightly less horrible proposition than selling CG-NAT alone), and much less importantly any entity so large that CG-NAT capacity (memory and assigned IP/port tuples) is an issue for them.
    - Dagger2 3y ago
      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.

lxgr 3y ago

> Doing things properly would cost money. Nobody is willing to pay. So nothing will ever change. That's not a fair characterization of the problem: Unless everybody switches at the same time (~impossible), IPv6 requires paying for both stacks until the migration is complete. That's simply not economical, and not everybody on the internet can afford to disregard economics that way. I'm also running IPv6 on all my hobbyist projects, but I really can't blame anyone that doesn't.

lloeki 3y ago
It's a game theory problem: nobody wanted to foot the bill on their side, endlessly punting and waiting for others to foot it for them. End result is that now everyone foots a different, worse bill, yet will still have to foot the previous bill because the workarounds have their limits when the attrition game pans out.
marcosdumay 3y ago
> IPv6 requires paying for both stacks until the migration is complete Yeah, the IP licensing costs are sure to bankrupt you. Only hobbyists have enough money to do it. Large corporations can not afford the money and labor.
- lxgr 3y ago
  Hobbyists: "Wanna do IPv6? It's cool and we'll do our part for incentivizing people to also switch! It should only take a couple of Saturday afternoons." "Sure, sounds cool, let's do it!" Meanwhile, at any average corporation: "Ok, so implementing IPv6 will cost us x$ and n person months, got it. And the upside is that we'd get a badge on some IPv6 readiness site, yes? And what would be the consequence, for us, of not doing this? Interesting, absolutely nothing you say, at least until every single customer is at least on IPv6 dual stack, since we need to provide our existing IPv4 stack too? Cool, thank you for presenting, please don't come again!" About the only large commercial entities that see any benefits of rolling out IPv6 are eyeball-heavy ISPs (since selling native IPv6 + CG-NAT for IPv4 is a slightly less horrible proposition than selling CG-NAT alone), and much less importantly any entity so large that CG-NAT capacity (memory and assigned IP/port tuples) is an issue for them.
  - Dagger2 3y ago
    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.