3 ms·

Why is IPv6 designed in such a way that it is hard to migrate to? I've no idea if my website is IPv6 compatible. When Let's Encrypt became a thing, I pushed a

by edent 3y ago

Why is IPv6 designed in such a way that it is hard to migrate to? I've no idea if my website is IPv6 compatible. When Let's Encrypt became a thing, I pushed a button on my webhost's console and I had HTTPS. It worked for the majority of devices without needing any reconfiguration. Where's the one-click solution for IPv6?

izacus 3y ago
Because it's basically the technical standard equivalent of that junior engineer going "Let's not just increase our ID column to 64-bit, but let's REWRITE IT ALL TO BE AWSOMEST.". And then the rewrite stutters, stalls and everyone finds out that they really just wanted that 64-bit ID column.
- blueflow 3y ago
  Then explain how you are gonna increase the address field in IP packages without making the resulting protocol incompatible to IPv4. As to my current knowledge, this is not possible because any router not understanding these extensions would be unable to route packets with that extension correctly.
  - izacus 3y ago
    Noone here is claiming that the new protocol would be compatible with IPv4 and I'd rather you don't beat a strawman. But there's still a gradient on how much the new protocol actually differs from the old in how networks are structured and how much work router, switch and client firmware needs to support it. The fact that I haven't seen a single non-buggy router firmware (and I've deployed quite a few IPv6 networks) tells by itself just how overbloated the standard is.
    - deleted 3y ago
      [deleted]
chippiewill 3y ago
I don't think you could design it in such a way that it's easier to migrate to. It's a fundamental change at the IP protocol layer, there wasn't scope in that layer for backwards compatibility. There's loads of transition mechanisms that were introduced, but it's not as tractable of a problem. Assumptions around IPv4 have been baked in all over the place. Also there was more _reason_ to move to HTTPS. Virtually everything had already supported HTTPS for closing in on two decades at the point the mass rollout with LE happened. You could switch to HTTPS-only for your site without breaking it for your users because they already needed it for online banking etc. You can't just switch to exclusive IPv6 because half your users don't even have an IPv6 connection. And virtually everyone with IPv6 has an IPv4 connection anyway so the benefit in dual stacking is nil. Unlike supporting HTTPS where at least those that supported it got the benefit.
- kaliszad 3y ago
  Actually, dual-stacking a website has some benefits. In some countries the CGNAT boxes tend to be oversubscribed and introduce latency. Apple has observed that too and presented some numbers to developers. Having two protocols can introduce redundancy for those that support both. If there is some routing issue e.g. because of some cable cut most clients will automatically use the faster protocol. If you run some infrastructure, you have to dual stack only at the gateway to other networks. You can run IPv6-only or IPv4-only inside and reverse-proxy or tunnel the traffic. Running IPv6 only can save you some money in the cloud today, it is not much but for small things the charge can be in double digit percent.
- deleted 3y ago
  [deleted]
johannes1234321 3y ago
Let's encrypt isn't any real new technology. All it did was removing cost and fully automating all aspects of the process. Before let's encrypt certificates had to be paid by money. The trouble with IPv6 is the hen and egg. For ISPs it's troublesome as they have to run double stack, till the last site on the Internet is converted and for site owners the trouble is they have to double stack till last ISP converted. Doing anything backward compatible isn't an option as the trouble is I. The 32 bit address limiting number of addresses on IPv4, and any form of increase causes compatibility issues. (Of course one could build an IP protocol closer to IPv4 with just larger address space, but transition costs would still be very similar to IPv6)

by edent 3y ago

izacus 3y ago

Because it's basically the technical standard equivalent of that junior engineer going "Let's not just increase our ID column to 64-bit, but let's REWRITE IT ALL TO BE AWSOMEST.". And then the rewrite stutters, stalls and everyone finds out that they really just wanted that 64-bit ID column.

blueflow 3y ago
Then explain how you are gonna increase the address field in IP packages without making the resulting protocol incompatible to IPv4. As to my current knowledge, this is not possible because any router not understanding these extensions would be unable to route packets with that extension correctly.
- izacus 3y ago
  Noone here is claiming that the new protocol would be compatible with IPv4 and I'd rather you don't beat a strawman. But there's still a gradient on how much the new protocol actually differs from the old in how networks are structured and how much work router, switch and client firmware needs to support it. The fact that I haven't seen a single non-buggy router firmware (and I've deployed quite a few IPv6 networks) tells by itself just how overbloated the standard is.
  - deleted 3y ago
    [deleted]

chippiewill 3y ago

I don't think you could design it in such a way that it's easier to migrate to. It's a fundamental change at the IP protocol layer, there wasn't scope in that layer for backwards compatibility. There's loads of transition mechanisms that were introduced, but it's not as tractable of a problem. Assumptions around IPv4 have been baked in all over the place. Also there was more _reason_ to move to HTTPS. Virtually everything had already supported HTTPS for closing in on two decades at the point the mass rollout with LE happened. You could switch to HTTPS-only for your site without breaking it for your users because they already needed it for online banking etc. You can't just switch to exclusive IPv6 because half your users don't even have an IPv6 connection. And virtually everyone with IPv6 has an IPv4 connection anyway so the benefit in dual stacking is nil. Unlike supporting HTTPS where at least those that supported it got the benefit.

kaliszad 3y ago
Actually, dual-stacking a website has some benefits. In some countries the CGNAT boxes tend to be oversubscribed and introduce latency. Apple has observed that too and presented some numbers to developers. Having two protocols can introduce redundancy for those that support both. If there is some routing issue e.g. because of some cable cut most clients will automatically use the faster protocol. If you run some infrastructure, you have to dual stack only at the gateway to other networks. You can run IPv6-only or IPv4-only inside and reverse-proxy or tunnel the traffic. Running IPv6 only can save you some money in the cloud today, it is not much but for small things the charge can be in double digit percent.
deleted 3y ago
[deleted]

johannes1234321 3y ago

Let's encrypt isn't any real new technology. All it did was removing cost and fully automating all aspects of the process. Before let's encrypt certificates had to be paid by money. The trouble with IPv6 is the hen and egg. For ISPs it's troublesome as they have to run double stack, till the last site on the Internet is converted and for site owners the trouble is they have to double stack till last ISP converted. Doing anything backward compatible isn't an option as the trouble is I. The 32 bit address limiting number of addresses on IPv4, and any form of increase causes compatibility issues. (Of course one could build an IP protocol closer to IPv4 with just larger address space, but transition costs would still be very similar to IPv6)