← Back to context

Comment by woah

16 hours ago

IPv6 has a huge amount of bloat created by guys in cargo shorts and pony tails being flown out to exotic locales 3x a year for IETF conferences to argue about minutia and try to get their name on some IPv6 spec document. All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.

> All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.

There is no 'just' extending the address length:

      So it's a matter of mathematical and physical fact that to expand
      the address size, you must change the protocol, and that means 
      [three] things immediately:

            You have to change the version number.

            You have to add new code to handle the new version.

      […]

            You need a coexistence technique so that updated systems, 
            with the new protocol, can connect to old systems that know 
            nothing of the new protocol.

      Two minutes of thought show that this third requirement has only 
      two solutions:

            (3A) Dual stack, in which the new machines speak both 
                 the old (IPv4) and new (IPng) protocol.

            (3B) Translation, in which something translates addresses
                 between the old and new protocols.

* https://github.com/becarpenter/misc/blob/main/why6why.md

* https://datatracker.ietf.org/doc/html/rfc1671

You also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)

In any 'address extension' plan the legacy code cannot use the new address space; you have to:

* update the IP stack (like with IPv6)

* tell applications about new DNS records (like IPv6)

* set up translation layers for legacy-only code that cannot be update to reach extended-address-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)

Wasn't it from academics in their ivory towers? That's kind of the opposite of flying out to exotic locales.

Of course, back here in the real world you can look at the RFCs yourself and see that they're credited to places like Ipsilon Networks, Xerox and Sun Microsystems. Boring corporate network companies.

  • No literally, the IETF meets 3x a year in a different location each time and all the guys from with cargo shorts from the companies you named argue about IPv6 minutia all day and spend their per diem by night. It's actually a lot of fun.

That's what they did and you're here complaining about it

  • IPv6 invalidated the existing IPv4 addresses, changed the addressing scheme, and de facto got rid of DHCP and NAT in favor of SLAAC and global routing. It doesn't share any state with v4. This was a very different set of choices from just adding more bits to v4.

Nah, the details in the spec all have good reasons, but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.

  • > […] but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.

    This was not a "mistake":

          So it's a matter of mathematical and physical fact that to expand
          the address size, you must change the protocol, and that means 
          [three] things immediately:
    
                You have to change the version number.
    
                You have to add new code to handle the new version.
    
          […]
    
                You need a coexistence technique so that updated systems, 
                with the new protocol, can connect to old systems that know 
                nothing of the new protocol.
    
          Two minutes of thought show that this third requirement has only 
          two solutions:
    
                (3A) Dual stack, in which the new machines speak both 
                     the old (IPv4) and new (IPng) protocol.
    
                (3B) Translation, in which something translates addresses
                     between the old and new protocols.
    

    * https://github.com/becarpenter/misc/blob/main/why6why.md

    * https://datatracker.ietf.org/doc/html/rfc1671

    • Yes it's 3A. They didn't need to make the new protocol have separate state from the old one. Let me keep my old address on the new protocol.

      3 replies →