3 ms·

A lot of it's just laziness. Perhaps we'd see more support if C included a built-in 128-bit type so IPv6 addresses could be shoved into a variable.

by api 11y ago

kalessin 11y ago
That's what addrlen in all socket functions and struct sockaddr_storage are for?
mprovost 11y ago
You've actually hit upon (part of) the answer right there. While IPv4 was designed around the (then) new 32 bit processors of the day, the committee that came up with v6 decided to ignore the underlying hardware reality. There's no corresponding type in C (or the underlying hardware, without going into SSE) that can store a v6 address natively. It just acts as a handbrake and makes it that much harder to implement. The question should be turned around, why didn't they design a protocol that could fit into a built-in type in C? After all, we've only just "run out" of v4 addresses about 20 years after it was first predicted to happen. Going to 64 bit would have kicked the can another few decades down the road, and could have led to a much faster implementation. You can't blame the "designers" of C (since there aren't any really, it's just the CPU manufacturers), it's the IETF that ignored the reality of hardware and programming languages.
- api 11y ago
  IP64 would have worked, and would have kicked the can much further than another few decades. If I were asked to invent IP 2.0 I'd have suggested just extending the V4 address space by another 32 bits and calling it a day. But I do see the advantage of big addresses. They give you room for meaningful cryptographic semantic information and stateless auto configuration, both of which are very valuable in big distributed systems and for security. So yeah, could have been simpler but not a big deal. Things like struct sockaddr_storage make programming it pretty easy too, but most older devs aren't familiar with them.
  - zzalpha 11y ago
    IP64 would have worked, and would have kicked the can much further than another few decades. If I were asked to invent IP 2.0 I'd have suggested just extending the V4 address space by another 32 bits and calling it a day. And you'd still have to rewrite all software to take advantage of it. Everyone who thinks they could've come up with a better solution seems to conveniently forget that no solution would've both extended the address space while providing free backward compatibility with v4. Those are, quite literally, incompatible goals. Any hacky solution you do come up with (like, say, NAT64) applies to IPv6, as well. Meanwhile, IPv6 goes on to address a whole host of other issues, like the mess that is CIDR, simplified autoconfiguration, built in address randomization/privacy extensions, etc.
    - mprovost 11y ago
      I don't think that's true - there were proposals that extended the address space in a backwards-compatible way but they were rejected in favour of a clean-slate approach that required rewriting everything and breaking existing networks.
      - zzalpha 11y ago
        Specifics, please. How do you extend the address space such that old devices in legacy addresses can communicate with new devices in an extended address space without NAT64-like hacks.
        mprovost 11y ago
        This is probably the best historical document looking at the original discussions around IPng (which eventually became v6). Interestingly these debates were happening right around the time of the invention of the www so there isn't a lot online today. https://tools.ietf.org/html/rfc1454 https://tools.ietf.org/html/rfc1454 Section 6 (Transition Plans) talks about plans to use new headers or IP Options to carry the extra information for the new protocol in an IPv4 packet. In the end they went for the alternative which was not to have a transition plan, they went for the dual stack approach instead. The SIP proposal is interesting, it's basically the same as v4 but with 64 bit addresses. They were worried that it might not be enough, of course their predictions about exhausting the 32 bit address space were off by decades.
- zzalpha 11y ago
  You've actually hit upon (part of) the answer right there. While IPv4 was designed around the (then) new 32 bit processors of the day, the committee that came up with v6 decided to ignore the underlying hardware reality. There's no corresponding type in C (or the underlying hardware, without going into SSE) that can store a v6 address natively Huh? That's what abstractions like sockaddr_storage are for. Who cares how the address maps to the underlying CPU word size? It's the same reason you shouldn't be storing pointers in ints. Portability requires effort. That's just life.
- marcosdumay 11y ago
  > After all, we've only just "run out" of v4 addresses about 20 years after it was first predicted to happen. Look, if by the 50's somebody make some calculations and said "if we don't change our ways, we'll be out of X by 2030", and X runs out in 2030, this person will be perfectly on time, not late by 80 years.

A lot of it's just laziness. Perhaps we'd see more support if C included a built-in 128-bit type so IPv6 addresses could be shoved into a variable.

by api 11y ago

A lot of it's just laziness. Perhaps we'd see more support if C included a built-in 128-bit type so IPv6 addresses could be shoved into a variable.

kalessin 11y ago

That's what addrlen in all socket functions and struct sockaddr_storage are for?

mprovost 11y ago

You've actually hit upon (part of) the answer right there. While IPv4 was designed around the (then) new 32 bit processors of the day, the committee that came up with v6 decided to ignore the underlying hardware reality. There's no corresponding type in C (or the underlying hardware, without going into SSE) that can store a v6 address natively. It just acts as a handbrake and makes it that much harder to implement. The question should be turned around, why didn't they design a protocol that could fit into a built-in type in C? After all, we've only just "run out" of v4 addresses about 20 years after it was first predicted to happen. Going to 64 bit would have kicked the can another few decades down the road, and could have led to a much faster implementation. You can't blame the "designers" of C (since there aren't any really, it's just the CPU manufacturers), it's the IETF that ignored the reality of hardware and programming languages.

api 11y ago
IP64 would have worked, and would have kicked the can much further than another few decades. If I were asked to invent IP 2.0 I'd have suggested just extending the V4 address space by another 32 bits and calling it a day. But I do see the advantage of big addresses. They give you room for meaningful cryptographic semantic information and stateless auto configuration, both of which are very valuable in big distributed systems and for security. So yeah, could have been simpler but not a big deal. Things like struct sockaddr_storage make programming it pretty easy too, but most older devs aren't familiar with them.
- zzalpha 11y ago
  IP64 would have worked, and would have kicked the can much further than another few decades. If I were asked to invent IP 2.0 I'd have suggested just extending the V4 address space by another 32 bits and calling it a day. And you'd still have to rewrite all software to take advantage of it. Everyone who thinks they could've come up with a better solution seems to conveniently forget that no solution would've both extended the address space while providing free backward compatibility with v4. Those are, quite literally, incompatible goals. Any hacky solution you do come up with (like, say, NAT64) applies to IPv6, as well. Meanwhile, IPv6 goes on to address a whole host of other issues, like the mess that is CIDR, simplified autoconfiguration, built in address randomization/privacy extensions, etc.
  - mprovost 11y ago
    I don't think that's true - there were proposals that extended the address space in a backwards-compatible way but they were rejected in favour of a clean-slate approach that required rewriting everything and breaking existing networks.
    - zzalpha 11y ago
      Specifics, please. How do you extend the address space such that old devices in legacy addresses can communicate with new devices in an extended address space without NAT64-like hacks.
      - mprovost 11y ago
        This is probably the best historical document looking at the original discussions around IPng (which eventually became v6). Interestingly these debates were happening right around the time of the invention of the www so there isn't a lot online today. https://tools.ietf.org/html/rfc1454 https://tools.ietf.org/html/rfc1454 Section 6 (Transition Plans) talks about plans to use new headers or IP Options to carry the extra information for the new protocol in an IPv4 packet. In the end they went for the alternative which was not to have a transition plan, they went for the dual stack approach instead. The SIP proposal is interesting, it's basically the same as v4 but with 64 bit addresses. They were worried that it might not be enough, of course their predictions about exhausting the 32 bit address space were off by decades.
zzalpha 11y ago
You've actually hit upon (part of) the answer right there. While IPv4 was designed around the (then) new 32 bit processors of the day, the committee that came up with v6 decided to ignore the underlying hardware reality. There's no corresponding type in C (or the underlying hardware, without going into SSE) that can store a v6 address natively Huh? That's what abstractions like sockaddr_storage are for. Who cares how the address maps to the underlying CPU word size? It's the same reason you shouldn't be storing pointers in ints. Portability requires effort. That's just life.
marcosdumay 11y ago
> After all, we've only just "run out" of v4 addresses about 20 years after it was first predicted to happen. Look, if by the 50's somebody make some calculations and said "if we don't change our ways, we'll be out of X by 2030", and X runs out in 2030, this person will be perfectly on time, not late by 80 years.