4 ms·

The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you). One major problem is dual stack. It doubles the workload for very limi

by ta1243 3y ago

The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you). One major problem is dual stack. It doubles the workload for very limited benefit. You have all the downsides of making ipv4 work in the first place. You've then got all sorts of messes like NAT66 (ipv6 was supposed to get rid of NAT), a lack of clarity on which patch to use (NPTv6 and NAT66 are two different options for the same problem, a problem which was built into ipv6 in the first place), messy hacks like DNS64 Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. You'd be able to communicate with ipv6 by using stateful NAT at the edge of your ipv6 network (as you do now at the edge of your RFC1918 network), you could expose services on your ipv6 only devices with natting (as you do now). You'd still have A and AAAA records, your client having an ipv6 stack could prefer AAAA instead of A, but if it needed to use an A record (or someone just tried to connect to 12.34.56.78) the stack would have gone "ok I'm ipv6 only, I'll connect to :ffff:12.34.56.78" and rely on the network to make it happen. Throw in things like NPTv6 and 464XLAT from the start (rather than 16+ years in) -- the addons which were created to address the fundamental architectural flaws in ipv6 -- and you'd have had a far smoother transition.

tsimionescu 3y ago
Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work. There was no way to make the transition to IPv6 without dual stack. The problem was much more that the precise dual-stack approach was not well thought out, when it should have been a fundamental part of the IPv6 RFC itself. Any ISP who wishes to move to IPv6 still to this day has to consider how it will handle clients that don't speak IPv6, servers that don't speak IPv6, routers they own that don't speak IPv6, and peers who don't speak IPv6. There is no way to make all of this work without having devices that translate between the two (losing most of the benefits of IPv6 when going through this translation, of course). When you've spent 10 million dollars or more on a router that doesn't speak IPv6, you don't change it one year later just because a new protocol has come up. That thing is there to stay for 5-10 years, and you just work around it as best you can.
- ta1243 3y ago
  ipv6 has been around for nearly 30 years. > Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work. 464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device Had ipv6 transition been thought about better back in the 90s then you could have deployed your new subnets as ipv6 only back in 2005 and still communicate with all your older kit. > That thing is there to stay for 5-10 years, and you just work around it as best you can. IPv6 is 30 years old. I sweat assets like there's no tomorrow but the oldest kit I've got active today is less than half that. Even for ipv4 only devices, a single legacy subnet would be reachable from my v6-only management devices via my ipv6 backbone via 464xlat
  - simiones 3y ago
    > 464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device > nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device How does that work if your ISP doesn't support IPv6? Can an OS developer deliver IPv6-only OSs to any end user? How about v4-only VPNs? Ultimately the answer is that devices must support both IPv4 and v6 until the day only one remains. Keeping both active at the same time may be more optional, but there is plenty of software which assumes IPv4 at other layers than simple connectivity. So running IPv6-only is generally a bad idea even today.
    - janc_ 3y ago
      If your ISP doesn't support IPv6 today, you should have switched to a competent ISP years ago.
      - tsimionescu 3y ago
        This whole discussion was about what should have been done differently at the start of the IPv6 rollout to help it complete in less than a lifetime, not about the situation some decades in.
elsjaako 3y ago
You say ipv6 was supposed to get rid of NAT. Can you explain why it doesn't? You then say the problem was built into ipv6 from the start. From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.
- ta1243 3y ago
  The existence of NAT66 and NPTv6 are proof that there is still a need for NAT in an ipv6 environment. Maybe not in your environment, but people wouldn't make these solutions if there wasn't a need.
  - robertlagrant 3y ago
    There's certainly a requirement for them, but it would be good to know what the justification of that requirement was before we know if there's a need. E.g. the justification could be "our SOPs say all network traffic must go through NAT", and if you dig deeper you might find that the SOP was written to save money on IPv4 addresses. That would not indicate a fundamental need.
    - ta1243 3y ago
      > There's certainly a requirement for them Thus proving that ipv6 failed in it's mission to get rid of nat
      - robertlagrant 3y ago
        I don't think this is a useful thing to say. If I keep trying to fill up my electric car with petrol, and get so annoyed that it keeps spilling on the floor that I pay someone to install a petrol cap and fuel tank, it would be equally silly to say that electric cars failed in their mission to get rid of petrol use.
    - Retric 3y ago
      NAT works well as an ultra simple firewall. All those ancient IoT devices don’t need to accept traffic from arbitrary addresses, but they may need to communicate with the outside world. Using a firewall is obviously an option, but why give an IP to something you don’t want accessible by the outside world?
Sesse__ 3y ago
> Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. This is, indeed, how dual-stack works; you open a PF_INET6 socket and use sockaddr_in6 addresses for everything, including IPv4 (which get mapped to ::ffff:/96 addresses). Been like that essentially forever. The “dual” in dual stack refers to the OS' stacks, not userspace.
- yrro 3y ago
  Don't forget you may need to opt in to get mapping to work. It's not available by default on all platforms. If you're unlucky you'll also have to sacrifice a goat to appease the JVM gods. JVM behaviours vary hugely across implementation, version and underlying platform. Not to mention the short sighted decision made by many sysadmins to disable IPv6 completely...
  - Sesse__ 3y ago
    Sure, that's one line and then you're done. And only if you care about very old (WinXP) or deliberately obnoxious (OpenBSD) platforms.
    - GoblinSlayer 3y ago
      WinXP implements sockaddr_storage from RFC 2553 - a sufficiently large generic socket address.
      - Sesse__ 3y ago
        But not mapped-v4 sockets; it has independent IPv4 and IPv6 stacks. In any case, hopefully we don't need to write code for it anymore…
ClumsyPilot 3y ago
> The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you) The year is 2023, The chromium engine is full blown operating system, it has notifications, background task management, GPU acceleration for general compute, it's larger than Windows XP, and can in fact run windows XP in the browser. Teams consumes 500 mb of ram to do the same job ICQ did in 2002 with 5 mb of ram. Cars have 4G, lightbulbs need updates and security patches. But Ipv6 features take a few extra bytes and are a problem.
- rewmie 3y ago
  > But Ipv6 features take a few extra bytes and are a problem. Some people pay for each extra byte they have to send through a network, and design whole systems around the goal of minimizing the amount of data they ship around. No one pays for the extra free gigabyte that Chrome takes over.
  - azernik 3y ago
    This concern about an extra few bytes is substantial in approximately zero organizations' IPv6 adoption decisions.
    - Macha 3y ago
      In fact some of the earliest adopters of IPv6 were Google, Microsoft, Netflix. Companies who when you're considering the problem of (N * a few bytes) have a very large N so are the most likely to have material costs from it. Yet even to them, it's a rounding error.
      - azernik 3y ago
        Pedantic note: For Netflix the cost is actually especially low. Cost as a percent of bandwidth is (a few bytes / packet size), and when you're streaming enormous media files packets are almost always max size.
  - MereInterest 3y ago

by ta1243 3y ago

tsimionescu 3y ago

Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work. There was no way to make the transition to IPv6 without dual stack. The problem was much more that the precise dual-stack approach was not well thought out, when it should have been a fundamental part of the IPv6 RFC itself. Any ISP who wishes to move to IPv6 still to this day has to consider how it will handle clients that don't speak IPv6, servers that don't speak IPv6, routers they own that don't speak IPv6, and peers who don't speak IPv6. There is no way to make all of this work without having devices that translate between the two (losing most of the benefits of IPv6 when going through this translation, of course). When you've spent 10 million dollars or more on a router that doesn't speak IPv6, you don't change it one year later just because a new protocol has come up. That thing is there to stay for 5-10 years, and you just work around it as best you can.

ta1243 3y ago
ipv6 has been around for nearly 30 years. > Any solution to the 4->6 transition that assumes that all devices of some class (be it clients, servers, or middleboxes) moved to IPv6 at once is deluded and would not work. 464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device Had ipv6 transition been thought about better back in the 90s then you could have deployed your new subnets as ipv6 only back in 2005 and still communicate with all your older kit. > That thing is there to stay for 5-10 years, and you just work around it as best you can. IPv6 is 30 years old. I sweat assets like there's no tomorrow but the oldest kit I've got active today is less than half that. Even for ipv4 only devices, a single legacy subnet would be reachable from my v6-only management devices via my ipv6 backbone via 464xlat
- simiones 3y ago
  > 464xlat allows communication from ipv6 only clients to legacy ipv4 ones without the need for a separate stack on your end device > nat46 allows communication from a legacy v4 device to a modern v6 device without the need for a separate stack on your end device How does that work if your ISP doesn't support IPv6? Can an OS developer deliver IPv6-only OSs to any end user? How about v4-only VPNs? Ultimately the answer is that devices must support both IPv4 and v6 until the day only one remains. Keeping both active at the same time may be more optional, but there is plenty of software which assumes IPv4 at other layers than simple connectivity. So running IPv6-only is generally a bad idea even today.
  - janc_ 3y ago
    If your ISP doesn't support IPv6 today, you should have switched to a competent ISP years ago.
    - tsimionescu 3y ago
      This whole discussion was about what should have been done differently at the start of the IPv6 rollout to help it complete in less than a lifetime, not about the situation some decades in.

elsjaako 3y ago

You say ipv6 was supposed to get rid of NAT. Can you explain why it doesn't? You then say the problem was built into ipv6 from the start. From looking it up it looks like it's mostly required when IP's change (e.g. when you change ISP), which for me is more of an argument to use DNS if you want fixed addresses.

ta1243 3y ago
The existence of NAT66 and NPTv6 are proof that there is still a need for NAT in an ipv6 environment. Maybe not in your environment, but people wouldn't make these solutions if there wasn't a need.
- robertlagrant 3y ago
  There's certainly a requirement for them, but it would be good to know what the justification of that requirement was before we know if there's a need. E.g. the justification could be "our SOPs say all network traffic must go through NAT", and if you dig deeper you might find that the SOP was written to save money on IPv4 addresses. That would not indicate a fundamental need.
  - ta1243 3y ago
    > There's certainly a requirement for them Thus proving that ipv6 failed in it's mission to get rid of nat
    - robertlagrant 3y ago
      I don't think this is a useful thing to say. If I keep trying to fill up my electric car with petrol, and get so annoyed that it keeps spilling on the floor that I pay someone to install a petrol cap and fuel tank, it would be equally silly to say that electric cars failed in their mission to get rid of petrol use.
  - Retric 3y ago
    NAT works well as an ultra simple firewall. All those ancient IoT devices don’t need to accept traffic from arbitrary addresses, but they may need to communicate with the outside world. Using a firewall is obviously an option, but why give an IP to something you don’t want accessible by the outside world?

Sesse__ 3y ago

> Instead had the approach been ipv6 only from the start, with no dual-stack, having the OS transparently deal with sockets to ipv4 devices by converting to the ipv6 mapped address (:ffff:xxxxxxx), and thus eliminating the need for dual stack from the start, things would have moved far far faster. This is, indeed, how dual-stack works; you open a PF_INET6 socket and use sockaddr_in6 addresses for everything, including IPv4 (which get mapped to ::ffff:/96 addresses). Been like that essentially forever. The “dual” in dual stack refers to the OS' stacks, not userspace.

yrro 3y ago
Don't forget you may need to opt in to get mapping to work. It's not available by default on all platforms. If you're unlucky you'll also have to sacrifice a goat to appease the JVM gods. JVM behaviours vary hugely across implementation, version and underlying platform. Not to mention the short sighted decision made by many sysadmins to disable IPv6 completely...
- Sesse__ 3y ago
  Sure, that's one line and then you're done. And only if you care about very old (WinXP) or deliberately obnoxious (OpenBSD) platforms.
  - GoblinSlayer 3y ago
    WinXP implements sockaddr_storage from RFC 2553 - a sufficiently large generic socket address.
    - Sesse__ 3y ago
      But not mapped-v4 sockets; it has independent IPv4 and IPv6 stacks. In any case, hopefully we don't need to write code for it anymore…

ClumsyPilot 3y ago

> The problem isn't ipv6 (even with the tons of extra features that ipv6 forces upon you) The year is 2023, The chromium engine is full blown operating system, it has notifications, background task management, GPU acceleration for general compute, it's larger than Windows XP, and can in fact run windows XP in the browser. Teams consumes 500 mb of ram to do the same job ICQ did in 2002 with 5 mb of ram. Cars have 4G, lightbulbs need updates and security patches. But Ipv6 features take a few extra bytes and are a problem.

rewmie 3y ago
> But Ipv6 features take a few extra bytes and are a problem. Some people pay for each extra byte they have to send through a network, and design whole systems around the goal of minimizing the amount of data they ship around. No one pays for the extra free gigabyte that Chrome takes over.
- azernik 3y ago
  This concern about an extra few bytes is substantial in approximately zero organizations' IPv6 adoption decisions.
  - Macha 3y ago
    In fact some of the earliest adopters of IPv6 were Google, Microsoft, Netflix. Companies who when you're considering the problem of (N * a few bytes) have a very large N so are the most likely to have material costs from it. Yet even to them, it's a rounding error.
    - azernik 3y ago
      Pedantic note: For Netflix the cost is actually especially low. Cost as a percent of bandwidth is (a few bytes / packet size), and when you're streaming enormous media files packets are almost always max size.
- MereInterest 3y ago