3 ms·

I think your summary is really great. One of the better refutations I've seen about the "what about v4 but longer??" question. However, I think people do get t

by jcgl 6mo ago

I think your summary is really great. One of the better refutations I've seen about the "what about v4 but longer??" question. However, I think people do get tripped up by the paradigm shift from DHCP -> SLAAC. That's not something that is an inevitable consequence of increasing address size. And compared to other details (e.g. the switch to multicasting, NDP, etc.), it's a change that's very visible to all operators and really changes how things work at a conceptual level.

wmf 6mo ago
DHCPv6 now exists and every OS except Android supports it.
- jcgl 6mo ago
  > except Android That alone is significant. Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly.
  - throw0101d 6mo ago
    > Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly. Why would DHCPv6 hold back privacy addresses? Can't DHCPv6 servers generate random host address bits and assign them in DHCP Offer packets? Couldn't clients generate random addresses and put them in Request packets? See perhaps OPTION_IA_TA (Temporary Address): * https://datatracker.ietf.org/doc/html/rfc8415#section-21.5 https://datatracker.ietf.org/doc/html/rfc8415#section-21.5 * https://en.wikipedia.org/wiki/DHCPv6#Option_Codes https://en.wikipedia.org/wiki/DHCPv6#Option_Codes DHCPv6 temporary addresses have the same properties as SLAAC temporary addresses (see Section 4.6). On the other hand, the properties of DHCPv6 non-temporary addresses typically depend on the specific DHCPv6 server software being employed. Recent releases of most popular DHCPv6 server software typically lease random addresses with a similar lease time as that of IPv4. Thus, these addresses can be considered to be "stable, semantically opaque". [DHCPv6-IID] specifies an algorithm that can be employed by DHCPv6 servers to generate "stable, semantically opaque" addresses. * https://datatracker.ietf.org/doc/html/rfc7721#section-4.7 https://datatracker.ietf.org/doc/html/rfc7721#section-4.7 How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled: * https://datatracker.ietf.org/doc/html/rfc8925 https://datatracker.ietf.org/doc/html/rfc8925 And hosts would also have to send out an IPv6 RS, and the RA can signal IPv6-mostly: * https://datatracker.ietf.org/doc/html/rfc8781 https://datatracker.ietf.org/doc/html/rfc8781 * https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6mops-07 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6mops...
    - jcgl 6mo ago
      > See perhaps OPTION_IA_TA (Temporary Address): I was unaware of this, so thanks. Sounds like it addresses (pun intended) my concern. > How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled It's not the signalling that's the problem--it's the configuration of the CLAT which requires SLAAC, afaiu. This is in fact the subject of the latest IPv6 Buzz podcast episode: https://packetpushers.net/podcasts/ipv6-buzz/ipb197-slaac-and-the-end-of-dhcp/ https://packetpushers.net/podcasts/ipv6-buzz/ipb197-slaac-an...
      - throw0101d 6mo ago
        > It's not the signalling that's the problem--it's the configuration of the CLAT which requires SLAAC, afaiu. This operational difficulty has been recognized and alternatives are being put forward: * https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-claton-15#name-obtaining-clat-ipv6-address https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-clato...
zamadatix 6mo ago
The real friction with SLAAC was that certain people (particularly some at Google) tried to force it as the only option on users, not that IPv6 ever forced it as the only option. The same kind of thing would likely occur with any new IP version rolling out. For comparison IPv4 had: - Static (1980 - original spec) - RARP (1984 - standalone spec) - BOOTP (1985 - standalone spec) - DHCP (1993 - standalone spec) And for IPv6: - Static (1995 - pre, 1998 final spec) - SLAAC (1996 - pre standalone, 1998 final standalone) - DHCPv6 (2003 - standalone) Some of these have had subsequent minor updates, e.g. DHCP was updated in 1997 and so on.
WorldMaker 6mo ago
SLAAC isn't something that is an inevitable consequence of increasing address size, it's something that is a useful advantage of increasing address size. Almost no one had big enough blocks in IPv4 where "just choose a random address and as long as no else seems to be currently claiming it it is yours" was a viable strategy for assigning an address. There are some nice benefits of SLAAC over DHCP such as modest privacy: if device addresses are randomized they become harder to guess/scan; if there's not a central server with a registration list of every device even more so (the first S, Stateless). That's a great potential win for general consumers and a far better privacy strategy than NAT44 accidental (and somewhat broken) privacy screening. It's at odds with corporate device management strategies where top-down assignment "needs to be the rule" and device privacy is potentially a risk, but that doesn't make SLAAC a bad idea as it just increases the obvious realization that consumer needs and big corporate needs are both very different styles of sub-networks of the internet and they are conflicting a bit. (Also those conflicting interests are why consumer equipment is leading the vanguard to IPv6 and corporate equipment is languishing behind in command-and-control IPv4 enclaves.)

by jcgl 6mo ago

wmf 6mo ago

DHCPv6 now exists and every OS except Android supports it.

jcgl 6mo ago
> except Android That alone is significant. Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly.
- throw0101d 6mo ago
  > Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more importantly) IPv6 Mostly. Why would DHCPv6 hold back privacy addresses? Can't DHCPv6 servers generate random host address bits and assign them in DHCP Offer packets? Couldn't clients generate random addresses and put them in Request packets? See perhaps OPTION_IA_TA (Temporary Address): * https://datatracker.ietf.org/doc/html/rfc8415#section-21.5 https://datatracker.ietf.org/doc/html/rfc8415#section-21.5 * https://en.wikipedia.org/wiki/DHCPv6#Option_Codes https://en.wikipedia.org/wiki/DHCPv6#Option_Codes DHCPv6 temporary addresses have the same properties as SLAAC temporary addresses (see Section 4.6). On the other hand, the properties of DHCPv6 non-temporary addresses typically depend on the specific DHCPv6 server software being employed. Recent releases of most popular DHCPv6 server software typically lease random addresses with a similar lease time as that of IPv4. Thus, these addresses can be considered to be "stable, semantically opaque". [DHCPv6-IID] specifies an algorithm that can be employed by DHCPv6 servers to generate "stable, semantically opaque" addresses. * https://datatracker.ietf.org/doc/html/rfc7721#section-4.7 https://datatracker.ietf.org/doc/html/rfc7721#section-4.7 How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled: * https://datatracker.ietf.org/doc/html/rfc8925 https://datatracker.ietf.org/doc/html/rfc8925 And hosts would also have to send out an IPv6 RS, and the RA can signal IPv6-mostly: * https://datatracker.ietf.org/doc/html/rfc8781 https://datatracker.ietf.org/doc/html/rfc8781 * https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6mops-07 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-6mops...
  - jcgl 6mo ago
    > See perhaps OPTION_IA_TA (Temporary Address): I was unaware of this, so thanks. Sounds like it addresses (pun intended) my concern. > How does DHCPv6 hold back IPv6-mostly? First, most clients will send out a DHCPv4 request in case IPv4 is the only option, in which case IPv6-mostly can be signalled It's not the signalling that's the problem--it's the configuration of the CLAT which requires SLAAC, afaiu. This is in fact the subject of the latest IPv6 Buzz podcast episode: https://packetpushers.net/podcasts/ipv6-buzz/ipb197-slaac-and-the-end-of-dhcp/ https://packetpushers.net/podcasts/ipv6-buzz/ipb197-slaac-an...
    - throw0101d 6mo ago
      > It's not the signalling that's the problem--it's the configuration of the CLAT which requires SLAAC, afaiu. This operational difficulty has been recognized and alternatives are being put forward: * https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-claton-15#name-obtaining-clat-ipv6-address https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-clato...

zamadatix 6mo ago

The real friction with SLAAC was that certain people (particularly some at Google) tried to force it as the only option on users, not that IPv6 ever forced it as the only option. The same kind of thing would likely occur with any new IP version rolling out. For comparison IPv4 had: - Static (1980 - original spec) - RARP (1984 - standalone spec) - BOOTP (1985 - standalone spec) - DHCP (1993 - standalone spec) And for IPv6: - Static (1995 - pre, 1998 final spec) - SLAAC (1996 - pre standalone, 1998 final standalone) - DHCPv6 (2003 - standalone) Some of these have had subsequent minor updates, e.g. DHCP was updated in 1997 and so on.

WorldMaker 6mo ago

SLAAC isn't something that is an inevitable consequence of increasing address size, it's something that is a useful advantage of increasing address size. Almost no one had big enough blocks in IPv4 where "just choose a random address and as long as no else seems to be currently claiming it it is yours" was a viable strategy for assigning an address. There are some nice benefits of SLAAC over DHCP such as modest privacy: if device addresses are randomized they become harder to guess/scan; if there's not a central server with a registration list of every device even more so (the first S, Stateless). That's a great potential win for general consumers and a far better privacy strategy than NAT44 accidental (and somewhat broken) privacy screening. It's at odds with corporate device management strategies where top-down assignment "needs to be the rule" and device privacy is potentially a risk, but that doesn't make SLAAC a bad idea as it just increases the obvious realization that consumer needs and big corporate needs are both very different styles of sub-networks of the internet and they are conflicting a bit. (Also those conflicting interests are why consumer equipment is leading the vanguard to IPv6 and corporate equipment is languishing behind in command-and-control IPv4 enclaves.)