4 ms·

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 w

by 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.
        0x457 2y ago
        I understand that, but what I'm replying to says: "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."
        hylaride 2y ago
        RFC6177 specifically recommends a /48 to /56 because future security measures may require subnetting, even on home networks (eg having IoT devices on a secure DMZ). Basically, giving out a /64 is the modern equivalent to ISPs saying "you have to pay extra to have more computers on the internet and you're not allowed to use NAT" that was actually a thing up until the mid 2000s. The frustrating this is that there's no reason to do a /64 as IPv6 was literally designed to hand out huge IP ranges.
- 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).

by api 2y ago

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.
      - 0x457 2y ago
        I understand that, but what I'm replying to says: "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."
        hylaride 2y ago
        RFC6177 specifically recommends a /48 to /56 because future security measures may require subnetting, even on home networks (eg having IoT devices on a secure DMZ). Basically, giving out a /64 is the modern equivalent to ISPs saying "you have to pay extra to have more computers on the internet and you're not allowed to use NAT" that was actually a thing up until the mid 2000s. The frustrating this is that there's no reason to do a /64 as IPv6 was literally designed to hand out huge IP ranges.
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).