3 ms·

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 situa

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?
        hylaride 2y ago
        Strictly speaking, it's perfectly standard and you can subdivide it (manually). However, for a variety of reasons subnetting smaller than a /64 is difficult and not supported at all via SLAAC (because the host portion is derived from the MAC which is already 48 bits, plus other overhead). So if you want to split up a /64 from your ISP, you're limited to manual configuration, DHCPv6 (and no android support), or other ways: https://version6.ru/en/dividing-the-indivisible https://version6.ru/en/dividing-the-indivisible If you're just dealing with a single network at home, a /64 is otherwise fine. But there's a reason the recommended handout from ISPs is a /56; the inventors of IPv6 (or more specifically SLAAC) just didn't take into consideration how intransigent big telecoms would be.
  - hylaride 2y ago
    SLAAC is awesome, but DNS support in it didn't show up until much later. The result is a mish-mash of DHCPv6/SLAAC support (and android famously doesn't support DHCPv6 at all and windows only supported DHCPv6 until windows 10).
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.

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?
      - hylaride 2y ago
        Strictly speaking, it's perfectly standard and you can subdivide it (manually). However, for a variety of reasons subnetting smaller than a /64 is difficult and not supported at all via SLAAC (because the host portion is derived from the MAC which is already 48 bits, plus other overhead). So if you want to split up a /64 from your ISP, you're limited to manual configuration, DHCPv6 (and no android support), or other ways: https://version6.ru/en/dividing-the-indivisible https://version6.ru/en/dividing-the-indivisible If you're just dealing with a single network at home, a /64 is otherwise fine. But there's a reason the recommended handout from ISPs is a /56; the inventors of IPv6 (or more specifically SLAAC) just didn't take into consideration how intransigent big telecoms would be.
- hylaride 2y ago
  SLAAC is awesome, but DNS support in it didn't show up until much later. The result is a mish-mash of DHCPv6/SLAAC support (and android famously doesn't support DHCPv6 at all and windows only supported DHCPv6 until windows 10).

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.