4 ms·

> The only reason v6 is dual stack is because they're changing all the existing addresses and routing. If you're only creating a second header format that every

> The only reason v6 is dual stack is because they're changing all the existing addresses and routing. If you're only creating a second header format that everything is updated to support, it can be mostly unified. Routing tables etc would all shared. A new header format is a new version of IP. That's how it was designed. That's the compatibility story of IP. There is no way (there never was a way) to change the IPv4 header format without incrementing the version number. There is no way to not create a "second" stack when you increment the version number. Different versions are always different "stacks". They are always going to have different mechanics and need different hardware. All the other things that IPv6 changed didn't make it a different stack. Making a version 6 at all made a new stack and all the other things were changed to throw in additional improvements (and make things simpler) since there needed to be a different stack anyway. If version 6 had changed "just" the header it still would have been just as hard to upgrade to, but people would have even fewer reasons to upgrade.

hot_gril 3y ago
You can call it a separate stack if you want, either way, the difficulty of going v6 comes from having totally separate addresses and routes as opposed to sharing everything. Basically every system out there is already capable of handling ipv6 headers, but they don't use it.
- icedchai 3y ago
  If you increase the size of the address with "v4.1", you have the same situation as v6: a new protocol. How are you going to announce "v4.1" routes without updating BGP? You can't.
  - hot_gril 3y ago
    You'd update BGP and the routers. They'd support both v4 and v4.1 packets with unified routing. All existing ownership of /32s from ipv4 would get carried over. Say v4.1 addrs are 64-bit max. V4.1 dst=1.2.3.4.53.2.1 could get BGP-routed to a 1.2.3/24 router, routed to a 1.2.3.4/32, to 1.2.3.4.53/40, to the dst. Also, during the transition period, a v4.1 packet addressed to a 32-bit addr would get auto-translated to v4. This is unlike v6, which cannot address anything inside the v4 space. v6 and v4 are totally separate planes.
    - icedchai 3y ago
      Upgrading the routers is a monumental task and handling the "transition" when some routers are upgraded with v4.1 and some are not is impossible. What happens during the transition when a v4.1 source tries to send data to a v4 destination? The v4 can't talk back. You can't fit 64 bits in a 32 bit address. This is the same problem as with v6.
      - hot_gril 3y ago
        Right, it only converts to v4 if both src and dst are 32-bit, which is fine in v4.1 too. Everyone can adopt v4.1 hardware/software without even thinking about it but hold off on using >32-bit addrs until they feel like enough peers are on v4.1. Yes it's only a one-way compatibility, but that's way better than v6 which is incompatible both ways, creating gridlock. If you really want extra compatibility, idk if this is a good idea but it's an option... Go v4.1 using up to 40-bit addresses for now (but leave room for more). Translate a v4.1 TCP/IP packet with a 40-bit src and 32-bit dst to v4, truncating the last 8 bits of the src IP, provided the last 8 of the src port matches them. IPv4-only dst can respond fine. When that /32 v4.1 router receives the v4 response, set the last 8 bits of the dst IP to the last 8 of the dst port. So it's kinda like NAT except translating to a public /40 IPv4.1 instead of a private IPv4. Actual NAT on the /40 addrs gets the remaining 8 bits for the src port. And you just speak v4.1 without all this if the dst is >32 bits.
        icedchai 3y ago
        I think you underestimate the complexity of deploying a new protocol like that. Also, you know NAT64 exists, right? You can have a v6 only network connecting to v4 hosts. Is that not enough compatibility if you don't want dual stack hosts?
        hot_gril 3y ago
        I can't tell you the man-hours, but I can tell you it'd be easier than ipv6. And yes I'm aware that you can give a "v6 only network" a v4 address, which means you're still on ipv4.

hot_gril 3y ago

You can call it a separate stack if you want, either way, the difficulty of going v6 comes from having totally separate addresses and routes as opposed to sharing everything. Basically every system out there is already capable of handling ipv6 headers, but they don't use it.

icedchai 3y ago
If you increase the size of the address with "v4.1", you have the same situation as v6: a new protocol. How are you going to announce "v4.1" routes without updating BGP? You can't.
- hot_gril 3y ago
  You'd update BGP and the routers. They'd support both v4 and v4.1 packets with unified routing. All existing ownership of /32s from ipv4 would get carried over. Say v4.1 addrs are 64-bit max. V4.1 dst=1.2.3.4.53.2.1 could get BGP-routed to a 1.2.3/24 router, routed to a 1.2.3.4/32, to 1.2.3.4.53/40, to the dst. Also, during the transition period, a v4.1 packet addressed to a 32-bit addr would get auto-translated to v4. This is unlike v6, which cannot address anything inside the v4 space. v6 and v4 are totally separate planes.
  - icedchai 3y ago
    Upgrading the routers is a monumental task and handling the "transition" when some routers are upgraded with v4.1 and some are not is impossible. What happens during the transition when a v4.1 source tries to send data to a v4 destination? The v4 can't talk back. You can't fit 64 bits in a 32 bit address. This is the same problem as with v6.
    - hot_gril 3y ago
      Right, it only converts to v4 if both src and dst are 32-bit, which is fine in v4.1 too. Everyone can adopt v4.1 hardware/software without even thinking about it but hold off on using >32-bit addrs until they feel like enough peers are on v4.1. Yes it's only a one-way compatibility, but that's way better than v6 which is incompatible both ways, creating gridlock. If you really want extra compatibility, idk if this is a good idea but it's an option... Go v4.1 using up to 40-bit addresses for now (but leave room for more). Translate a v4.1 TCP/IP packet with a 40-bit src and 32-bit dst to v4, truncating the last 8 bits of the src IP, provided the last 8 of the src port matches them. IPv4-only dst can respond fine. When that /32 v4.1 router receives the v4 response, set the last 8 bits of the dst IP to the last 8 of the dst port. So it's kinda like NAT except translating to a public /40 IPv4.1 instead of a private IPv4. Actual NAT on the /40 addrs gets the remaining 8 bits for the src port. And you just speak v4.1 without all this if the dst is >32 bits.
      - icedchai 3y ago
        I think you underestimate the complexity of deploying a new protocol like that. Also, you know NAT64 exists, right? You can have a v6 only network connecting to v4 hosts. Is that not enough compatibility if you don't want dual stack hosts?
        hot_gril 3y ago
        I can't tell you the man-hours, but I can tell you it'd be easier than ipv6. And yes I'm aware that you can give a "v6 only network" a v4 address, which means you're still on ipv4.