3 ms·

It’s too bad the original IP could not have included some kind of stronger header integrity lock to block middle boxes. It would have forced us to adopt V6 and

by api 2y ago

It’s too bad the original IP could not have included some kind of stronger header integrity lock to block middle boxes. It would have forced us to adopt V6 and… my god… the network would be so much cleaner and superior in every way. Things would just have addresses, and protocol innovation at L3 would be possible.

hylaride 2y ago
I'd like to agree with you, but IPv6 had such a classic case of suffocation by committee during its birth that I doubt it would have been pushed by such a situation. IPSec was mandated in the original IPv6 RFC, for god's sake. That alone delayed a lot of work in implementing it as crypto code needed to be integrated into kernels, which was not common in those days. That's to say nothing about the fact that IPSec is loosely defined enough that setting it up between different vendors is always an adventure - adding support to an IP stack was a big headache (I followed OpenBSD at the time they were integrating IPv6 in the early 2000s and there was a lot of hard problems around compatibility). Header integrity was so far off of consideration during IPv4's implementation because the internet was a dozen universities and DoD sites that it was overkill (and possibly a waste of limited CPU cycles at the time). What's far more likely to have happened is that we'd see more proxies instead of NATs (SOCKS, etc). I don't think that'd be better than NAT.
- api 2y ago
  There's some history I'm not aware of here. I didn't know just how bad the V6 second system committee shitshow was. Today V6 has been stripped down almost to what it should have been: bigger addresses, then stop. All that's left to get there is to deprecate SLAAC or make it optional.
  - kstrauser 2y ago
    SLAAC’s awesome, though. It’s one of the good parts we definitely want to keep.
    - api 2y ago
      Let's say your ISP gives you a /64. Now you have to use V6 NAT... or assign a /96 internally. SLAAC won't let you do that. That, among other things, is a problem. SLAAC is too limited. You can use DHCPv6 but then you can't use Android because Android, and I think they're alone here, stubbornly and dogmatically refuses to implement it. I guess you could go around and statically assign V6 IPs to Android devices, or run NATv6 with SLAAC for those and DHCPv6 for everything else, but that's annoying as hell.
      - labcomputer 2y ago
        Then your ISP isn’t following the RFCs. You might as well ask what you would do if you ISP gives your router a 17.0.0.0/8 address via DHCP. These are completely invented problems in your head. SLAAC can absolutely advertise a single /64 internally. It can advertise any /64 you tell it to. DHCPv6 can absolutely respond with DNS servers (and nothing else) in parallel. Configuring your SLAAC daemon to tell clients to get DNS servers via DHCPv6 is a 15 minute exercise with google.
        api 2y ago
        > Then your ISP isn’t following the RFCs. Oh, summer child...
      - kstrauser 2y ago
        Android's right on this one (and I don't own an Android device that I know of, so this isn't me fanboying them). TBH ISPs that hand out /64's shouldn't be allowed to say that they support IPv6 because it's a completely non-standard — not as in "uncommon", but as in "violates the documented standards" - setup.
        0x457 2y ago
        Wait, what's not standard about /64?
        2y ago
- graealex 2y ago
  It's funny that you mention IPSec, since that would have made most of the application-level encryption we see today obsolete. They did have good intentions, and if it was widely accepted, it would have meant that barely any applications would have had to deal with the details of encryption, including the ever-looming possibility of doing it wrong (doing encryption right is hard!). Now we have a slew of protocols that either implement TLS, or roll their own custom thing, or have X-over-HTTPS protocols, including SSTP and DoH.
  - hylaride 2y ago
    IPSec was far too complicated, loosely defined, and over-engineered to have ever been widely accepted. Any host verification would need to involve application level verification anyways to make sure the other end is who you expect. So your browser would need to verify the encrypted tunnel is in face connected to google, or whoever. There’s a reason SSL/TLS is done at the application level.

by api 2y ago

hylaride 2y ago

I'd like to agree with you, but IPv6 had such a classic case of suffocation by committee during its birth that I doubt it would have been pushed by such a situation. IPSec was mandated in the original IPv6 RFC, for god's sake. That alone delayed a lot of work in implementing it as crypto code needed to be integrated into kernels, which was not common in those days. That's to say nothing about the fact that IPSec is loosely defined enough that setting it up between different vendors is always an adventure - adding support to an IP stack was a big headache (I followed OpenBSD at the time they were integrating IPv6 in the early 2000s and there was a lot of hard problems around compatibility). Header integrity was so far off of consideration during IPv4's implementation because the internet was a dozen universities and DoD sites that it was overkill (and possibly a waste of limited CPU cycles at the time). What's far more likely to have happened is that we'd see more proxies instead of NATs (SOCKS, etc). I don't think that'd be better than NAT.

api 2y ago
There's some history I'm not aware of here. I didn't know just how bad the V6 second system committee shitshow was. Today V6 has been stripped down almost to what it should have been: bigger addresses, then stop. All that's left to get there is to deprecate SLAAC or make it optional.
- kstrauser 2y ago
  SLAAC’s awesome, though. It’s one of the good parts we definitely want to keep.
  - api 2y ago
    Let's say your ISP gives you a /64. Now you have to use V6 NAT... or assign a /96 internally. SLAAC won't let you do that. That, among other things, is a problem. SLAAC is too limited. You can use DHCPv6 but then you can't use Android because Android, and I think they're alone here, stubbornly and dogmatically refuses to implement it. I guess you could go around and statically assign V6 IPs to Android devices, or run NATv6 with SLAAC for those and DHCPv6 for everything else, but that's annoying as hell.
    - labcomputer 2y ago
      Then your ISP isn’t following the RFCs. You might as well ask what you would do if you ISP gives your router a 17.0.0.0/8 address via DHCP. These are completely invented problems in your head. SLAAC can absolutely advertise a single /64 internally. It can advertise any /64 you tell it to. DHCPv6 can absolutely respond with DNS servers (and nothing else) in parallel. Configuring your SLAAC daemon to tell clients to get DNS servers via DHCPv6 is a 15 minute exercise with google.
      - api 2y ago
        > Then your ISP isn’t following the RFCs. Oh, summer child...
    - kstrauser 2y ago
      Android's right on this one (and I don't own an Android device that I know of, so this isn't me fanboying them). TBH ISPs that hand out /64's shouldn't be allowed to say that they support IPv6 because it's a completely non-standard — not as in "uncommon", but as in "violates the documented standards" - setup.
      - 0x457 2y ago
        Wait, what's not standard about /64?
        2y ago
graealex 2y ago
It's funny that you mention IPSec, since that would have made most of the application-level encryption we see today obsolete. They did have good intentions, and if it was widely accepted, it would have meant that barely any applications would have had to deal with the details of encryption, including the ever-looming possibility of doing it wrong (doing encryption right is hard!). Now we have a slew of protocols that either implement TLS, or roll their own custom thing, or have X-over-HTTPS protocols, including SSTP and DoH.
- hylaride 2y ago
  IPSec was far too complicated, loosely defined, and over-engineered to have ever been widely accepted. Any host verification would need to involve application level verification anyways to make sure the other end is who you expect. So your browser would need to verify the encrypted tunnel is in face connected to google, or whoever. There’s a reason SSL/TLS is done at the application level.