4 ms·

Similar discussion from a couple of months ago: https://news.ycombinator.com/item?id=46468625 https://news.ycombinator.com/item?id=46468625 I personally feel t

by avidiax 7mo ago

Similar discussion from a couple of months ago: https://news.ycombinator.com/item?id=46468625 https://news.ycombinator.com/item?id=46468625 I personally feel that IPv6 is one of the clearest cases of second system syndrome. What we needed was more address bits. What we got was a nearly total redesign-by-committee with many elegant features but had difficult backwards compatibility. https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect

lxgr 7mo ago
Which IPv6 “gratuitious” features (i.e. anything other than the decision to make a breaking change to address formats and accordingly require adapters) would you argue made adoption more difficult? IPv6 gets a lot of hate for all the bells and whistles, but on closer examination, the only one that really matters is always “it’s a second network and needs me to touch all my hosts and networking stack”. Don’t like SLAAC? Don’t use it! Want to keep using DHCP instead? Use DHCPv6! Love manual address configuration? Go right ahead! It even makes the addresses much shorter. None of that stuff is essential to IPv6. In fact, in my view TFA makes a very poor case for a counterfactual IPv4+ world. The only thing it really simplifies is address space assignment.
- iso1631 7mo ago
  Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance The removal of arp and removal of broadcast, the enforcement of multicast The almost-required removal of NAT and the quasi-relgious dislike from many network people. Instead of simply src-natting your traffic behind ISP1 or ISP2, you are supposed to have multiple public IPs and somehow make your end devices choose the best routing rather than your router. All of these were choices made in addition to simply expanding the address scope.
  - lxgr 7mo ago
    > Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance Only use the real one then (unless you happen to be implementing ND or something)! > The removal of arp and removal of broadcast, the enforcement of multicast ARP was effectively only replaced by ND, no? Maybe there are many disadvantages I'm not familiar with, but is there a fundamental problem with it? > The almost-required removal of NAT Don't like that part? Don't use it, and do use NAT66. It works great, I use it sometimes!
    - simoncion 7mo ago
      In fairness, aside from whining about the minority attitude towards NAT [0] the person you're replying to absolutely met your definition of "gratuitous": (i.e. anything other than the decision to make a breaking change to address formats and accordingly require adapters) I (and I expect the fellow you're replying to) believe that if you're going to have to rework ARP to support 128-bit addresses, you might as well come up with a new protocol that fixes things you think are bad about ARP. And if the fellow you're replying to doesn't know that broadcast is another name for "all-hosts multicast", then he needs to read a bit more. [0] Several purity-minded fools wanted to pretend that IPv6 NAT wasn't going to exist. That doesn't mean that IPv6 doesn't support NAT... NAT is and has always been a function of the packet mangling done by a router that sits between you and your conversation partner.
  - labcomputer 7mo ago
    > The removal of arp and removal of broadcast, the enforcement of multicast Wait, wait, wait. Let me get this straight. You think it's a bad thing that IPv6 prevents spoofed MAC -> IP resolution? Sorry, but this is not a serious conversation.
- avidiax 7mo ago
  It's not that they loaded it up with features, it's that elegance was prized over practicality. Simplifying address space assignment is a huge deal. IPv4+ allows the leaves of the network to adopt IPv4+ when it makes sense for them. They don't lose any investment in IPv4 address space, they don't have to upgrade to all IPv6 supporting hardware, there's no parallel configuration. You just support IPv4 on the terminals that want or need it, and on the network hardware when you upgrade. It's basically better NAT that eventually disappears and just becomes "routing".
  - lxgr 7mo ago
    > They don't lose any investment in IPv4 address space What investment? IP addresses used to be free until we started running out, and I don't think anything of value would be lost for humanity as a whole if they became non-scarce again. > they don't have to upgrade to all IPv6 supporting hardware But they do, unless you're fine with maintaining an implicitly hierarchical network (or really two) forever. > It's basically better NAT How is it better? It also still requires NAT for every 4x host trying to reach a 4 only one, so it's exactly NAT. > that eventually disappears Driven by what mechanism?
    - pocksuppet 7mo ago
      >> They don't lose any investment in IPv4 address space > What investment? IP addresses used to be free Well they're not now, so it's an investment. Any entity that has IP addresses doesn't want its competition to get IP addresses, even when this leads to bad outcomes overall.
      - lxgr 7mo ago
        And would you say this is a dynamic worth preserving by policy?
        pocksuppet 7mo ago
        It doesn't matter whether it's worth preserving. It matters whether it will be preserved.
- aboardRat4 7mo ago
  />Don’t like SLAAC? Don’t use it! It doesn't work like this. SLAAC is a standard compliant way of distributing addresses, so you MUST support it unless you're running a very specific isolated setup. Most people using Android will come to your home and ask "do you have WiFi here?"
  - throw0101c 7mo ago
    > Most people using Android will come to your home and ask "do you have WiFi here?" The Android implementation of IPv6 completely boggles my mind. They have completely refused to implemented DHCPv6 since 2012: * https://issuetracker.google.com/issues/36949085 https://issuetracker.google.com/issues/36949085 But months after client-side DHCP-PD was made an RFC they're implementing that? * https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html https://android-developers.googleblog.com/2025/09/simplifyin... In what universe does implementing DHCP-PD but not 'regular' DHCPv6 make any kind of sense?
    - aboardRat4 7mo ago
      >In what universe does implementing DHCP-PD but not 'regular' DHCPv6 make any kind of sense? Their policy makes a lot of sense. It's hindering ipv6 deployment, but it is preventing ISPs from allocating less than /64 to customers. It has nothing to do with standards actually. Dhcp-pd makes a lot of sense though, because if an isp is willing to give you a prefix, they are by default nice guys.
      - lxgr 7mo ago
        You really think they’re doing all of this as some elaborate “all or nothing” v6 deployment bargaining chip?
        aboardRat4 7mo ago
        Yes. I'm not an insider, of course.
- zadikian 7mo ago
  Just making DHCP+NAT default in ipv6 might've helped. Those who want SLAAC and know what they're doing can set it up.
adrian_b 7mo ago
In my opinion the redesign of IPv6 was perfectly fine. The IPv6 headers are significantly simpler that those of IPv4 and much easier to process at great speed. There was only 1 mistake, but it was huge and all backwards compatibility problems come from it. The IPv4 32-bit address space should have been included in the IPv6 address space, instead of having 2 separate address spaces. IPv6 added very few features, but it mostly removed or simplified the IPv4 features that were useless.
- xorcist 7mo ago
  > The IPv4 32-bit address space should have been included in the IPv6 address space, That's ... exactly how IPv6 works? Look at the default prefix table at https://en.wikipedia.org/wiki/IPv6_address#Default_address_selection https://en.wikipedia.org/wiki/IPv6_address#Default_address_s... . Or did you mean something else? You still need a dual stack configuration though, there's nothing getting around that when you change the address space. Hence "happy eyeballs" and all that.
  - iso1631 7mo ago
    > You still need a dual stack configuration though, there's nothing getting around that when you change the address space Yes there is, at least outside of the machine. All you need to do is have an internal network (100.64/16, 169.254/16, wherever) local to the machine. If you machine is on say 2001::1, then when an application attempts to listen on an ipv4 address it opens a socket listening on 2001::1 instead, and when an application writes a packet to 1.0.0.1, your OS translates it to ::ffff:100:1. This can be even more hidden than things like internal docker networks. Your network then has a route to ::ffff:0:0/96 via a gateway (typically just the default router), with a source of 2001::1 When the packet arrives at a router with v6 and v4 on (assume your v4 address is 2.2.2.2), that does a 6:4 translation, just like a router does v4:v4 nat The packet then runs over the v4 network until it reaches 1.0.0.1 with a source of 2.2.2.2, and a response is sent back to 2.2.2.2 where it is de-natted to a destination of 2001:1 and source of ::ffff:100.1 That way you don't need to change any application unless you want to reach ipv6 only devices, you don't need to run separate ipv4 and ipv6 stacks on your routers, and you can migrate easilly, with no more overhead than a typical 44 nat for rfc1918 devices. Likewise you can serve on your ipv6 only devices by listening on 2001::1 port 80, and having a nat which port forwards traffic coming to 2.2.2.2:80 to 2001::1 port 80 with a source of ::ffff:(whatever) (using colons as a deliminator wasn't great either, you end up with http://[2001::1]:80/ which is horrible)
pocksuppet 7mo ago
Everyone is saying this but... what are the new features, actually? There are a couple of cleanups to the header, removal of fragmentation, and a bunch of things like SLAAC you don't have to use if you don't want to?

by avidiax 7mo ago

lxgr 7mo ago

Which IPv6 “gratuitious” features (i.e. anything other than the decision to make a breaking change to address formats and accordingly require adapters) would you argue made adoption more difficult? IPv6 gets a lot of hate for all the bells and whistles, but on closer examination, the only one that really matters is always “it’s a second network and needs me to touch all my hosts and networking stack”. Don’t like SLAAC? Don’t use it! Want to keep using DHCP instead? Use DHCPv6! Love manual address configuration? Go right ahead! It even makes the addresses much shorter. None of that stuff is essential to IPv6. In fact, in my view TFA makes a very poor case for a counterfactual IPv4+ world. The only thing it really simplifies is address space assignment.

iso1631 7mo ago
Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance The removal of arp and removal of broadcast, the enforcement of multicast The almost-required removal of NAT and the quasi-relgious dislike from many network people. Instead of simply src-natting your traffic behind ISP1 or ISP2, you are supposed to have multiple public IPs and somehow make your end devices choose the best routing rather than your router. All of these were choices made in addition to simply expanding the address scope.
- lxgr 7mo ago
  > Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance Only use the real one then (unless you happen to be implementing ND or something)! > The removal of arp and removal of broadcast, the enforcement of multicast ARP was effectively only replaced by ND, no? Maybe there are many disadvantages I'm not familiar with, but is there a fundamental problem with it? > The almost-required removal of NAT Don't like that part? Don't use it, and do use NAT66. It works great, I use it sometimes!
  - simoncion 7mo ago
    In fairness, aside from whining about the minority attitude towards NAT [0] the person you're replying to absolutely met your definition of "gratuitous": (i.e. anything other than the decision to make a breaking change to address formats and accordingly require adapters) I (and I expect the fellow you're replying to) believe that if you're going to have to rework ARP to support 128-bit addresses, you might as well come up with a new protocol that fixes things you think are bad about ARP. And if the fellow you're replying to doesn't know that broadcast is another name for "all-hosts multicast", then he needs to read a bit more. [0] Several purity-minded fools wanted to pretend that IPv6 NAT wasn't going to exist. That doesn't mean that IPv6 doesn't support NAT... NAT is and has always been a function of the packet mangling done by a router that sits between you and your conversation partner.
- labcomputer 7mo ago
  > The removal of arp and removal of broadcast, the enforcement of multicast Wait, wait, wait. Let me get this straight. You think it's a bad thing that IPv6 prevents spoofed MAC -> IP resolution? Sorry, but this is not a serious conversation.
avidiax 7mo ago
It's not that they loaded it up with features, it's that elegance was prized over practicality. Simplifying address space assignment is a huge deal. IPv4+ allows the leaves of the network to adopt IPv4+ when it makes sense for them. They don't lose any investment in IPv4 address space, they don't have to upgrade to all IPv6 supporting hardware, there's no parallel configuration. You just support IPv4 on the terminals that want or need it, and on the network hardware when you upgrade. It's basically better NAT that eventually disappears and just becomes "routing".
- lxgr 7mo ago
  > They don't lose any investment in IPv4 address space What investment? IP addresses used to be free until we started running out, and I don't think anything of value would be lost for humanity as a whole if they became non-scarce again. > they don't have to upgrade to all IPv6 supporting hardware But they do, unless you're fine with maintaining an implicitly hierarchical network (or really two) forever. > It's basically better NAT How is it better? It also still requires NAT for every 4x host trying to reach a 4 only one, so it's exactly NAT. > that eventually disappears Driven by what mechanism?
  - pocksuppet 7mo ago
    >> They don't lose any investment in IPv4 address space > What investment? IP addresses used to be free Well they're not now, so it's an investment. Any entity that has IP addresses doesn't want its competition to get IP addresses, even when this leads to bad outcomes overall.
    - lxgr 7mo ago
      And would you say this is a dynamic worth preserving by policy?
      - pocksuppet 7mo ago
        It doesn't matter whether it's worth preserving. It matters whether it will be preserved.
aboardRat4 7mo ago
/>Don’t like SLAAC? Don’t use it! It doesn't work like this. SLAAC is a standard compliant way of distributing addresses, so you MUST support it unless you're running a very specific isolated setup. Most people using Android will come to your home and ask "do you have WiFi here?"
- throw0101c 7mo ago
  > Most people using Android will come to your home and ask "do you have WiFi here?" The Android implementation of IPv6 completely boggles my mind. They have completely refused to implemented DHCPv6 since 2012: * https://issuetracker.google.com/issues/36949085 https://issuetracker.google.com/issues/36949085 But months after client-side DHCP-PD was made an RFC they're implementing that? * https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html https://android-developers.googleblog.com/2025/09/simplifyin... In what universe does implementing DHCP-PD but not 'regular' DHCPv6 make any kind of sense?
  - aboardRat4 7mo ago
    >In what universe does implementing DHCP-PD but not 'regular' DHCPv6 make any kind of sense? Their policy makes a lot of sense. It's hindering ipv6 deployment, but it is preventing ISPs from allocating less than /64 to customers. It has nothing to do with standards actually. Dhcp-pd makes a lot of sense though, because if an isp is willing to give you a prefix, they are by default nice guys.
    - lxgr 7mo ago
      You really think they’re doing all of this as some elaborate “all or nothing” v6 deployment bargaining chip?
      - aboardRat4 7mo ago
        Yes. I'm not an insider, of course.
zadikian 7mo ago
Just making DHCP+NAT default in ipv6 might've helped. Those who want SLAAC and know what they're doing can set it up.

adrian_b 7mo ago

In my opinion the redesign of IPv6 was perfectly fine. The IPv6 headers are significantly simpler that those of IPv4 and much easier to process at great speed. There was only 1 mistake, but it was huge and all backwards compatibility problems come from it. The IPv4 32-bit address space should have been included in the IPv6 address space, instead of having 2 separate address spaces. IPv6 added very few features, but it mostly removed or simplified the IPv4 features that were useless.

xorcist 7mo ago
> The IPv4 32-bit address space should have been included in the IPv6 address space, That's ... exactly how IPv6 works? Look at the default prefix table at https://en.wikipedia.org/wiki/IPv6_address#Default_address_selection https://en.wikipedia.org/wiki/IPv6_address#Default_address_s... . Or did you mean something else? You still need a dual stack configuration though, there's nothing getting around that when you change the address space. Hence "happy eyeballs" and all that.
- iso1631 7mo ago
  > You still need a dual stack configuration though, there's nothing getting around that when you change the address space Yes there is, at least outside of the machine. All you need to do is have an internal network (100.64/16, 169.254/16, wherever) local to the machine. If you machine is on say 2001::1, then when an application attempts to listen on an ipv4 address it opens a socket listening on 2001::1 instead, and when an application writes a packet to 1.0.0.1, your OS translates it to ::ffff:100:1. This can be even more hidden than things like internal docker networks. Your network then has a route to ::ffff:0:0/96 via a gateway (typically just the default router), with a source of 2001::1 When the packet arrives at a router with v6 and v4 on (assume your v4 address is 2.2.2.2), that does a 6:4 translation, just like a router does v4:v4 nat The packet then runs over the v4 network until it reaches 1.0.0.1 with a source of 2.2.2.2, and a response is sent back to 2.2.2.2 where it is de-natted to a destination of 2001:1 and source of ::ffff:100.1 That way you don't need to change any application unless you want to reach ipv6 only devices, you don't need to run separate ipv4 and ipv6 stacks on your routers, and you can migrate easilly, with no more overhead than a typical 44 nat for rfc1918 devices. Likewise you can serve on your ipv6 only devices by listening on 2001::1 port 80, and having a nat which port forwards traffic coming to 2.2.2.2:80 to 2001::1 port 80 with a source of ::ffff:(whatever) (using colons as a deliminator wasn't great either, you end up with http://[2001::1]:80/ which is horrible)

pocksuppet 7mo ago

Everyone is saying this but... what are the new features, actually? There are a couple of cleanups to the header, removal of fragmentation, and a bunch of things like SLAAC you don't have to use if you don't want to?