[jcgl]

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.

[zamadatix]

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]

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.)

[wmf]

DHCPv6 now exists and every OS except Android supports it.

[jcgl]

> 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]

> 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://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

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

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/draft-ietf-v6ops-6mops...

[jcgl]

> 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-an...

[throw0101d]

> 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-clato...