7 ms·

Which is why you make stuff dualstack first. Except most ISPs don't even seem to get that far...

tsimionescu 5y ago
The problem being that dualstack is worse in every way than IPv4, and worse in every way than IPv6. The very fact that IPv6 adoption actually requires dual-stack IPv4+IPv6 adoption first is the very reason that adoption took such a hugely long time. If IPv6 could have been made backwards compatible somehow (it's probably mathematically impossible) then adoption would have been much faster (just look at HTTP -> HTTP2 -> HTTP3 already).
- mprovost 5y ago
  There were proposals at the time (1992!) for a backwards compatible version but they were rejected in favour of a clean slate approach. https://dl.acm.org/doi/pdf/10.17487/RFC1385 https://dl.acm.org/doi/pdf/10.17487/RFC1385
- scott00 5y ago
  From a backwards compatibility perspective, HTTP2->HTTP3 is really very similar to IPv4->IPv6. HTTP3 isn't really backwards compatible with HTTP2. The client just establishes a lower version connection and then the server (which must implement both versions) adds a header to the response telling the client they can establish a HTTP3 connection if they want to. In IP land you get to skip the lower version initial connection because you've already figured it out from DNS, but other than that pretty much the same deal. In both cases both clients and servers that use a new version are dual-stacked because there are plenty of both clients and servers that only support the lower version.
  - tsimionescu 5y ago
    Yes, that was a poor example. Thinking about it more, the salient difference is that HTTP->HTTP2->HTTP3 is not a network-level problem to a similar extent (apart from clients and servers, you do have proxies and CDNs that need to support both, but these are far fewer actors, and it's much easier to switch CDN to one that supports HTTPx than it is to switch ISP as a server operator), that is the reason why adoption was much faster.
- marcosdumay 5y ago
  IPv6 clients can be backward compatible, servers aren't. There shouldn't really be any rush to move servers into IPv6, it's end users' ISPs that should. Somehow things are happening completely backwards.
  - rootusrootus 5y ago
    Why put in the effort to give users IPv6 if there's nowhere for them to go? I recall that DJB made pretty much this argument in the distance past when he predicted IPv6 would fail.
    - bombcar 5y ago
      We basically needed ipv5 what would have been literally ipv4 but with 128 bit address-safe.
      - welterde 5y ago
        How exactly would have that solved anything? It would have exactly the same transition issues IPv6 has, since the main issue is that IPv4-only hosts cannot communicate with IPv6-only hosts. And there is no way around that - for any alternative proposal.
        bombcar 5y ago
        By making the transition from ipv4 to ipv5 as painless as possible and more like the switch from 32 bit to 64 bit addressing in CPU architectures. At some point everything is 32 byte safe by default and then it’s just working. IPv4 to IPv6 is nowhere as simple, IPv6 brings tons of new baggage along with it.
        welterde 5y ago
        Switch of CPU architecture is only a local problem. Switching the communication protocol is a local, remote and all the parts in between problem.
- nijave 5y ago
  It eliminates NAT traversal for peers that are also IPv6. I think the most relevant consumer usecase is probably gaming.
  - tsimionescu 5y ago
    Well, you still need firewall traversal, so you still can't do peer-to-peer connections, something still needs to allow you to punch a hole in the firewall. The only advantage that IPv6 with public IPs behind a firewall has compared to NAT is that each host can use the same port behind the firewall, you don't need a unique port for each host. I don't see this as a major advantage for an end-user (though it is helpful for large internal networks).
    - zajio1am 5y ago
      Firewall traversal for mediated PtP through basic stateful firewalls is simple - both sides start sending UDP packets to each other and outgoing packets open hole in firewall for incoming packets. The same approach does not work reliably with NAT, mainly because you do not know translated port numbers. It also may fail if both sides are behind the same NAT, as NAT pinning is sometimes not implemented.
      - fomine3 5y ago
        So is UDP hole punching the only modern way to traverse firewall?
        can16358p 5y ago
        Which is a very hacky way. I wouldn't rely on it for anything serious as it might break at any time.
        zajio1am 5y ago
        Why? It seems like simple, reliable and trivial. It is not hacky, it is essentially how stateful outgoing-only firewall is supposed to work for UDP.
vetinari 5y ago
Even if they go with dualstack, they do DS-Lite instead (public IPv6, CGNAT-ed IPv4). For customers that have already public IPv4, that's negative incentive to even consider switching to it, thus the IPv6 ranks are not growing, even if they could.

The problem being that dualstack is worse in every way than IPv4, and worse in every way than IPv6. The very fact that IPv6 adoption actually requires dual-stack IPv4+IPv6 adoption first is the very reason that adoption took such a hugely long time. If IPv6 could have been made backwards compatible somehow (it's probably mathematically impossible) then adoption would have been much faster (just look at HTTP -> HTTP2 -> HTTP3 already).

mprovost 5y ago
There were proposals at the time (1992!) for a backwards compatible version but they were rejected in favour of a clean slate approach. https://dl.acm.org/doi/pdf/10.17487/RFC1385 https://dl.acm.org/doi/pdf/10.17487/RFC1385
scott00 5y ago
From a backwards compatibility perspective, HTTP2->HTTP3 is really very similar to IPv4->IPv6. HTTP3 isn't really backwards compatible with HTTP2. The client just establishes a lower version connection and then the server (which must implement both versions) adds a header to the response telling the client they can establish a HTTP3 connection if they want to. In IP land you get to skip the lower version initial connection because you've already figured it out from DNS, but other than that pretty much the same deal. In both cases both clients and servers that use a new version are dual-stacked because there are plenty of both clients and servers that only support the lower version.
- tsimionescu 5y ago
  Yes, that was a poor example. Thinking about it more, the salient difference is that HTTP->HTTP2->HTTP3 is not a network-level problem to a similar extent (apart from clients and servers, you do have proxies and CDNs that need to support both, but these are far fewer actors, and it's much easier to switch CDN to one that supports HTTPx than it is to switch ISP as a server operator), that is the reason why adoption was much faster.
marcosdumay 5y ago
IPv6 clients can be backward compatible, servers aren't. There shouldn't really be any rush to move servers into IPv6, it's end users' ISPs that should. Somehow things are happening completely backwards.
- rootusrootus 5y ago
  Why put in the effort to give users IPv6 if there's nowhere for them to go? I recall that DJB made pretty much this argument in the distance past when he predicted IPv6 would fail.
  - bombcar 5y ago
    We basically needed ipv5 what would have been literally ipv4 but with 128 bit address-safe.
    - welterde 5y ago
      How exactly would have that solved anything? It would have exactly the same transition issues IPv6 has, since the main issue is that IPv4-only hosts cannot communicate with IPv6-only hosts. And there is no way around that - for any alternative proposal.
      - bombcar 5y ago
        By making the transition from ipv4 to ipv5 as painless as possible and more like the switch from 32 bit to 64 bit addressing in CPU architectures. At some point everything is 32 byte safe by default and then it’s just working. IPv4 to IPv6 is nowhere as simple, IPv6 brings tons of new baggage along with it.
        welterde 5y ago
        Switch of CPU architecture is only a local problem. Switching the communication protocol is a local, remote and all the parts in between problem.
nijave 5y ago
It eliminates NAT traversal for peers that are also IPv6. I think the most relevant consumer usecase is probably gaming.
- tsimionescu 5y ago
  Well, you still need firewall traversal, so you still can't do peer-to-peer connections, something still needs to allow you to punch a hole in the firewall. The only advantage that IPv6 with public IPs behind a firewall has compared to NAT is that each host can use the same port behind the firewall, you don't need a unique port for each host. I don't see this as a major advantage for an end-user (though it is helpful for large internal networks).
  - zajio1am 5y ago
    Firewall traversal for mediated PtP through basic stateful firewalls is simple - both sides start sending UDP packets to each other and outgoing packets open hole in firewall for incoming packets. The same approach does not work reliably with NAT, mainly because you do not know translated port numbers. It also may fail if both sides are behind the same NAT, as NAT pinning is sometimes not implemented.
    - fomine3 5y ago
      So is UDP hole punching the only modern way to traverse firewall?
      - can16358p 5y ago
        Which is a very hacky way. I wouldn't rely on it for anything serious as it might break at any time.
        zajio1am 5y ago
        Why? It seems like simple, reliable and trivial. It is not hacky, it is essentially how stateful outgoing-only firewall is supposed to work for UDP.

vetinari 5y ago

Even if they go with dualstack, they do DS-Lite instead (public IPv6, CGNAT-ed IPv4). For customers that have already public IPv4, that's negative incentive to even consider switching to it, thus the IPv6 ranks are not growing, even if they could.