1.1. Relationship to Previous DHCPv6 Standards (RFC 9915: Dynamic Host Configuration Protocol for IPv6 (DHCPv6))

[RFC8415] provided a unified, corrected, and cleaned-up definition of DHCPv6 that also covered all applicable errata filed against older RFCs at the time of its writing.
It also obsoleted a small number of mechanisms: delayed authentication, lifetime, and timer hints sent by a client.

This document obsoletes [RFC8415]. It applies verified errata reports and obsoletes two features that have not been widely implemented - the assignment of temporary
addresses using the IA_TA option and allowing clients to unicast some messages directly to the server if the server sent the Server Unicast option to a client in an early
exchange. It also clarifies the UDP ports used by clients, servers, and relay agents (Section 7.2). See Appendix A for a list of differences from [RFC8415].

4.5.1. Obtain Temporary Addresses (RFC 7844: Anonymity Profiles for DHCP clients)

[RFC3315] defines a special container (IA_TA, code 4) for requesting temporary addresses. This is a good mechanism in principle, but there are a number of issues
associated with it. First, this is not a widely used feature, so clients depending solely on temporary addresses may lock themselves out of service. Secondly, [RFC3315]
does not specify any lifetime or lease length for temporary addresses [voir remarque]. Therefore, support for renewing temporary addresses may vary between client
implementations, including no support at all. Finally, by requesting temporary addresses, a client reveals its desire for privacy and potentially risks countermeasures as
described in Section 2.5.

Because of these issues, clients interested in their privacy SHOULD NOT use IA_TA.

The addresses obtained according to Section 4.5 are meant to be non-temporary, but the anonymity profile uses them as temporary, and they will be discarded when
the link-layer address is changed. They thus meet most of the use cases of the temporary addresses defined in [RFC4941]. Clients interested in their privacy should
not publish their IPv6 addresses in the DNS or otherwise associate them with name services, and thus do not normally need two classes of addresses -- one public,
one temporary.

The use of mechanisms to allocate several IPv6 addresses to a client while preserving privacy is left for further study.

An IA_TA option does not include values for T1 and T2. A client MAY request that the valid lifetime on temporary addresses be extended by
including the addresses in an IA_TA option sent in a Renew or Rebind message to a server.

RFC 8415 : page 103

21.5. Identity Association for Temporary Addresses Option (RFC 8415 (obsolète): Dynamic Host Configuration Protocol for IPv6 (DHCPv6))

The client obtains new temporary addresses by sending an IA_TA option with a new IAID to a server. Requesting new temporary addresses from the server
is the equivalent of generating new temporary addresses as described in [RFC4941].  The server will generate new temporary addresses and return them
to the client. The client should request new temporary addresses before the lifetimes on the previously assigned addresses expire.

4.2.4. Address Generation Mechanisms (draft-rhl-dhc-dhcpv6-extensions-01: DHCPv6 Extension Practices and Considerations)

Currently, the DHCPv6 servers assign addresses, prefixes and other configuration options according to their configured policies. Generally, different networks
may prefer different address generation mechanisms. Several address generation mechanisms for SLAAC [RFC4862] (e.g., IEEE 64-bit EUI-64 [RFC2464],
Constant, semantically opaque [Microsoft], Temporary [RFC4941], and Stable, semantically opaque [RFC7217]) proposed for different requirements can be
utilized in DHCPv6 protocol as well. Note that [RFC7943] is the DHCPv6 version of Stable, semantically opaque [RFC7217]. The many types of IPv6 address
generation mechanisms available have brought about flexibility and diversity. Therefore, corresponding interfaces could be open and defined to allow other
address generation mechanisms to be configured.

[...]

For example, temporary addresses in [RFC4941] can be expressed as tempAddr(eui64, history) = Replace(Truncate(Hash(Concatenate(eui64, history)), 0, 63), 6, 6, 0),
where eui64 means the EUI-64 identifier defined in [RFC2464] and history means a history value defined in [RFC4941].

Je veux bien le nom de l'appli, svp.
Elle reste quand même utilisable sans root?