3 ms·

> except Android That alone is significant. Furthermore, DHCPv6 holds you back from various desirable things like privacy addresses and (arguably even more im

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

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