Hacker News new | ask | show | jobs
by throw0101d 79 days 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://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...

1 comments

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

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