DHCPv6 Prefix-Length Hint Issues
Extracted elements (24)
Servers are not required to remember the prefix-length hint from a client's Solicit message. The client's preference may change over time, and requiring servers to store hints would add complexity; the Renew/Rebind message itself should carry the current preference.
The best way to guarantee a completely new delegated prefix is to use a new IAID in the IA_PD, but this requires persistent storage across reboots; without it, the device would revert to the original IAID after rebooting, so the prefix-length hint mechanism is used instead.
The general recommendation is for clients to always include a standalone IAPREFIX option with just the prefix-length hint (in addition to any specific IAPREFIX options) in all Solicit, Request, Renew, and Rebind messages. This ensures the server consistently receives the client's length preference regardless of message type.
The Renew/Rebind approach of including two IAPREFIX options (current prefix + hint) serves a dual purpose: it extends the lifetime of the currently used prefix to avoid connection disruption while simultaneously signaling the client's preference for a different prefix length, enabling a graceful switchover.
When a server cannot match the exact prefix-length hint, it should assign the next shorter (not longer) length closest to the hint. This is because a client such as one needing a /56 to split across interfaces may be completely non-functional if given a longer prefix like /64, making correctness of direction critical.
RFC 3633 was ambiguous about whether clients are permitted to include a prefix-length hint in Renew/Rebind messages and what servers should do in response. RFC 8168 clarifies that clients SHOULD include hints in Renew/Rebind and defines server behavior for each case.
When a client accepts a non-hint-matching prefix from an Advertise and continues to request its preferred prefix length in Renew/Rebind, it is operating within spec. The server's willingness to honor the hint versus preserving address stability is an explicit matter of server policy per Section 3.6.
During Renew/Rebind, if the client prefers a different prefix length than the one currently delegated, it SHOULD send the Renew/Rebind with the same IA_PD containing two IAPREFIX options: one with the currently delegated prefix and one with the prefix-length hint.
If a Solicit includes a specific prefix value that is unavailable but also includes a prefix-length hint in the same IA_PD, the server SHOULD check its pool for a prefix matching the hint length; if still unavailable, the server SHOULD provide the prefix whose length is shorter and closest to the hint.
If the client also solicited for other stateful configuration options (e.g., IA_NAs) and cannot use the offered IA_PD prefixes, the client SHOULD accept the other stateful configuration options and continue to request the desired IA_PD prefix in subsequent DHCPv6 messages as specified in RFC 7550.
If the client can use the prefixes in the Advertise messages despite them differing from the hint, it SHOULD choose the shortest prefix length that is closest to the prefix-length hint and SHOULD continue requesting the preferred prefix in subsequent DHCPv6 messages.
If the client sent a Solicit with only IA_PDs and cannot use the prefixes in the Advertise messages, it MUST ignore those Advertise messages and continue sending Solicit messages until it obtains the preferred prefix.
If the server does not know the client's bindings (e.g., a different server receiving a Rebind), the server SHOULD ignore the original delegated prefix and try to assign a new prefix of the requested length.
If the server is unable to provide the newly requested prefix during Renew/Rebind but can extend the lifetime of the old prefix, the client SHOULD continue using the old prefix.
If the server will not assign any prefixes to any IA_PDs in a subsequent Request from the client, the server MUST send an Advertise message as described in RFC 3633 Section 11.2.
To avoid traffic congestion when continuing to solicit after unusable Advertise messages, the client MUST send Solicit messages at defined intervals as specified in RFC 7083.
Upon receipt of a Renew/Rebind where the client included both a delegated prefix IAPREFIX option and a prefix-length hint IAPREFIX option in the IA_PD, the server SHOULD check whether it can extend the lifetime of the original prefix and whether it has any available prefix matching the hint within its limits.
Upon receipt of a Solicit containing only a prefix-length hint, the server SHOULD first check its prefix pool for a prefix whose length matches the hint value regardless of prior interaction records. If no exact match exists, the server SHOULD provide the prefix whose length is shorter and closest to the hint.
When a client prefers a prefix of a specific length, it MUST send a Solicit message using the same IAID in the IA_PD, include the preferred prefix-length value in the IAPREFIX 'prefix-length' field, and set the 'IPv6 prefix' field to zero.
When a client wants the same prefix back but is willing to accept a different length as fallback, it MUST send a Solicit with the same IAID, one IAPREFIX option containing the previously delegated prefix, and another IAPREFIX option containing only the prefix-length hint. No ordering requirement applies to the two IAPREFIX options.
A client may include multiple IAPREFIX options within a single IA_PD option to simultaneously express a preference for a previously delegated prefix and a fallback prefix-length hint. There is no required ordering between the two IAPREFIX options.
A prefix-length hint is communicated by setting the 'IPv6 prefix' field of an IAPREFIX option to zero and the 'prefix-length' field to a non-zero value, encapsulated within an IA_PD option. Servers are free to ignore the hint depending on server policy.
Upon receiving a Renew/Rebind with a prefix-length hint, the server MAY respond with one of five policy-based actions: (1) extend original prefix lifetime only; (2) extend original and assign new prefix; (3) invalidate original (0 lifetimes) and assign new prefix; (4) assign original a 0 preferred-lifetime with non-zero valid-lifetime and add new prefix; or (5) omit original and assign new prefix, letting original expire naturally.
This document does not introduce new security mechanisms; security considerations for DHCPv6 are addressed in RFC 3315 Section 23, and security considerations specific to DHCPv6 prefix delegation are addressed in RFC 3633 Section 15.