4 ms·

We eventually run out of IPv4 addresses and have to switch anyway

zinekeller 5y ago
That doesn't work as an explanation. NAT was developed. CGNAT was developed. HTTP Host differentiation was developed. SNI was developed. STUN was developed. TURN was developed. The main problem with IPv4 to IPv6 migration is the, frankly, overzealous utopia that "they will migrate anyway". Worse, it's very different that doesn't allow for a simple upgrade option of "IPv4, but longer addresses" because IPv6 is designed to be fundamentally different. Which is more insulting considering that BGP was seamlessly upgraded from 65536 ASes to more than a million because they only changed the bits in an AS and nothing more. As a router developer, you only need to do the relatively minute changes of extended ASes than the (relative) mess that is IPv6.
- neurostimulant 5y ago
  And now the internet got worse because you're no longer have technical freedom due to these NAT popping up everywhere. For example, previously if you want to release a video/voice chat app, you just release it and be done with it. Now it won't work like that due to NAT, so you'll have to maintain some STUN and TURN servers just to make your app usable to general public. Think about how many potential innovation got stifled because of added costs and complexity turned some people away before they even started.
  - Sunspark 5y ago
    I agree. It makes things much harder than it should be. I wanted to try installing the module into my router so it would pass the WebRTC test for STUN/TURN and perhaps make video even more efficient to allow point to point connection instead of having everything be relayed through a tertiary server, but there was no documentation and having never set up a STUN/TURN server before I couldn't get it to work. So I am dependent on what a third party has set up to facilitate connectivity. In the old days, you'd just connect to an IP address and that was it.
- wbl 5y ago
  IPv6 implementations are everywhere so the extra changes don't really impact networks.
  - zinekeller 5y ago
    Regardless of monentary charges (and I'm very aware of them, APNIC is even considering grants to help in IPv6 because it's in limbo for so long), even if we activate IPv6 synchronously there's still many, many problems with it, even when you permanently dual-stack it. One is connectivity. Even theoretically we should have the same network connectivity (so to speak), you can feel the pettiness when Hurricane-Electric and Cogent fought exclusively on IPv6 (https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/ https://www.theregister.com/2018/08/28/ipv6_peering_squabble...) I can't believe I'm saying this, but IPv6 isn't free (or at least costs the same as IPv4). Second is security. Yes, the world is no longer scannable, but consumer routers are a dud when it comes to IPv6 security. This router (https://pierrekim.github.io/blog/2021-01-12-fiberhome-ont-0day-vulnerabilities.html https://pierrekim.github.io/blog/2021-01-12-fiberhome-ont-0d...) has serious problems at IPv6 security, and because it's suffix is always at ::0000:0000:0000:0001 and you've eliminate around 18 bits more because of how networks are laid, you've got yourself an IPv6 botnet, which speaking by, how do you block them? A /64 would be a good start, but OVH provides a single address per server (https://www.ovhcloud.com/vps/compare/ https://www.ovhcloud.com/vps/compare/). That's it. Don't forget that fiasco with MAC addresses (https://datatracker.ietf.org/doc/html/rfc8981 https://datatracker.ietf.org/doc/html/rfc8981), but at least that's solved. Third, IPv6 should just work as you said. I wish that's true, but embedded devices will trip you up badly. Some don't fallback to IPv4 and instead try and try again using IPv6. This would be a concern while transitioning, but even after that, some would be still stuck because their servers are only operating on IPv4! Implementing IPv6 is not free lunch if you know the gritty details.
- pixl97 5y ago
  >NAT was developed. CGNAT was developed. HTTP Host differentiation was developed. SNI was developed. STUN was developed. TURN was developed And every one of those has introduced its own security flaws and implementation bugs increasing the complexity of applications.
  - zinekeller 5y ago
    I'm advocating and helping networks to migrate to IPv6, but I'll say that IPv6 was rather a rats-nest design that shot itself in the foot. It's elegant sure, but as Torvalds would say to critics about his frequent use of goto, it's theoretically good but not sound engineering practice. The thing is we would be addressing in 128-bit IP already if it was done the BGP way: just minimising the necessary changes to implement it. Look at the effectiveness of Itanium versus AMD64 at migrating customers: IPv6 feels like Itanium, while extended ASes work more like AMD64. Whoever designed IPv6 was focused too much at the theoreticals, than looking at what the real world is and then designing around it.
    - ksec 5y ago
      Do we have anything for IPv4 similar to AMD64? Or are we forever stuck with either going all in to IPv6 or the current hybrid?
      - zinekeller 5y ago
        Nope, but we're deep in IPv6 anyways so the best course of action is to finish that, just be careful of the pitfalls and not devolving into silliness like this peering fight: https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/ https://www.theregister.com/2018/08/28/ipv6_peering_squabble...
    - Dagger2 5y ago
      Can you suggest a way of extending v4's address space that works like BGP or AMD64 do? I've asked a lot of people this question, and the only answers I've ever gotten are either impossible or already implemented by v6. Perhaps you will be the person to finally explain how to do it -- but as far as I can tell, it's just not possible, and I don't think it's fair to criticise v6 for not doing the impossible.
- ikiris 5y ago
  tell me you're bad at math without telling me you're bad at math.

That doesn't work as an explanation. NAT was developed. CGNAT was developed. HTTP Host differentiation was developed. SNI was developed. STUN was developed. TURN was developed. The main problem with IPv4 to IPv6 migration is the, frankly, overzealous utopia that "they will migrate anyway". Worse, it's very different that doesn't allow for a simple upgrade option of "IPv4, but longer addresses" because IPv6 is designed to be fundamentally different. Which is more insulting considering that BGP was seamlessly upgraded from 65536 ASes to more than a million because they only changed the bits in an AS and nothing more. As a router developer, you only need to do the relatively minute changes of extended ASes than the (relative) mess that is IPv6.

neurostimulant 5y ago
And now the internet got worse because you're no longer have technical freedom due to these NAT popping up everywhere. For example, previously if you want to release a video/voice chat app, you just release it and be done with it. Now it won't work like that due to NAT, so you'll have to maintain some STUN and TURN servers just to make your app usable to general public. Think about how many potential innovation got stifled because of added costs and complexity turned some people away before they even started.
- Sunspark 5y ago
  I agree. It makes things much harder than it should be. I wanted to try installing the module into my router so it would pass the WebRTC test for STUN/TURN and perhaps make video even more efficient to allow point to point connection instead of having everything be relayed through a tertiary server, but there was no documentation and having never set up a STUN/TURN server before I couldn't get it to work. So I am dependent on what a third party has set up to facilitate connectivity. In the old days, you'd just connect to an IP address and that was it.
wbl 5y ago
IPv6 implementations are everywhere so the extra changes don't really impact networks.
- zinekeller 5y ago
  Regardless of monentary charges (and I'm very aware of them, APNIC is even considering grants to help in IPv6 because it's in limbo for so long), even if we activate IPv6 synchronously there's still many, many problems with it, even when you permanently dual-stack it. One is connectivity. Even theoretically we should have the same network connectivity (so to speak), you can feel the pettiness when Hurricane-Electric and Cogent fought exclusively on IPv6 (https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/ https://www.theregister.com/2018/08/28/ipv6_peering_squabble...) I can't believe I'm saying this, but IPv6 isn't free (or at least costs the same as IPv4). Second is security. Yes, the world is no longer scannable, but consumer routers are a dud when it comes to IPv6 security. This router (https://pierrekim.github.io/blog/2021-01-12-fiberhome-ont-0day-vulnerabilities.html https://pierrekim.github.io/blog/2021-01-12-fiberhome-ont-0d...) has serious problems at IPv6 security, and because it's suffix is always at ::0000:0000:0000:0001 and you've eliminate around 18 bits more because of how networks are laid, you've got yourself an IPv6 botnet, which speaking by, how do you block them? A /64 would be a good start, but OVH provides a single address per server (https://www.ovhcloud.com/vps/compare/ https://www.ovhcloud.com/vps/compare/). That's it. Don't forget that fiasco with MAC addresses (https://datatracker.ietf.org/doc/html/rfc8981 https://datatracker.ietf.org/doc/html/rfc8981), but at least that's solved. Third, IPv6 should just work as you said. I wish that's true, but embedded devices will trip you up badly. Some don't fallback to IPv4 and instead try and try again using IPv6. This would be a concern while transitioning, but even after that, some would be still stuck because their servers are only operating on IPv4! Implementing IPv6 is not free lunch if you know the gritty details.
pixl97 5y ago
>NAT was developed. CGNAT was developed. HTTP Host differentiation was developed. SNI was developed. STUN was developed. TURN was developed And every one of those has introduced its own security flaws and implementation bugs increasing the complexity of applications.
- zinekeller 5y ago
  I'm advocating and helping networks to migrate to IPv6, but I'll say that IPv6 was rather a rats-nest design that shot itself in the foot. It's elegant sure, but as Torvalds would say to critics about his frequent use of goto, it's theoretically good but not sound engineering practice. The thing is we would be addressing in 128-bit IP already if it was done the BGP way: just minimising the necessary changes to implement it. Look at the effectiveness of Itanium versus AMD64 at migrating customers: IPv6 feels like Itanium, while extended ASes work more like AMD64. Whoever designed IPv6 was focused too much at the theoreticals, than looking at what the real world is and then designing around it.
  - ksec 5y ago
    Do we have anything for IPv4 similar to AMD64? Or are we forever stuck with either going all in to IPv6 or the current hybrid?
    - zinekeller 5y ago
      Nope, but we're deep in IPv6 anyways so the best course of action is to finish that, just be careful of the pitfalls and not devolving into silliness like this peering fight: https://www.theregister.com/2018/08/28/ipv6_peering_squabbles/ https://www.theregister.com/2018/08/28/ipv6_peering_squabble...
  - Dagger2 5y ago
    Can you suggest a way of extending v4's address space that works like BGP or AMD64 do? I've asked a lot of people this question, and the only answers I've ever gotten are either impossible or already implemented by v6. Perhaps you will be the person to finally explain how to do it -- but as far as I can tell, it's just not possible, and I don't think it's fair to criticise v6 for not doing the impossible.
ikiris 5y ago
tell me you're bad at math without telling me you're bad at math.