Issues and Recommendations with Multiple Stateful DHCPv6 Options
Extracted elements (25)
Confirm is restricted to IAs with addresses because the on-link verification mechanism compares the link's /64 prefix against the prefix-length-first bits of IA_NA/IA_TA addresses. IA_PD requires verifying that the delegating router holds the binding, which only Rebind can accomplish.
In a multiple IA option type model, T1/T2 timers are protocol-level timers that should be independent of individual IA options. Had DHCPv6 been redesigned from scratch, T1/T2 would be carried in a separate option rather than within each IA option.
RFC 7550 recommends that clients use a single DHCPv6 session and state machine when requesting both IA_NA and IA_PD options, rather than resetting the state machine or creating separate sessions per IA type. Separate sessions cause additional resource use, extra protocol traffic, duplication of configuration options, and divergence across IA-type specifications.
This document assumes all DHCPv6 servers on a network belong to a single provisioning domain, consistent with RFC 3315 and RFC 3633. Support for multiple provisioning domains — where a client obtains different IA types from different servers — is explicitly out of scope.
This document addresses three existing errata against RFC 3315 and RFC 3633: Errata 2469 (RFC 3633 Section 11.1 Advertise ignore rule), Errata 2471 (RFC 3315 Section 17.1.3 NoAddrsAvail ignore rule), and Errata 2472 (RFC 3315 Section 17.2.2 server Advertise formatting when no addresses available).
Implementations of DHCPv6 servers have varied on placement of the NoAddrsAvail status code in Advertise messages — some strictly following RFC 3315 (top-level) and others encapsulating it in the IA option as for Reply messages. Clients must tolerate both placements for backward compatibility.
Some client implementations incorrectly send a Release for all bindings after sending a Decline for a conflicting address. This document clarifies that a Decline event for one IA MUST NOT trigger Release of unrelated IAs that remain valid.
A client MUST have a binding with an IA containing addresses (IA_NA or IA_TA) to use the Confirm message. A client that has only IA_PD bindings (no address IAs) MUST use the Rebind message instead of Confirm. When a client has both address IAs and delegated prefix IAs, it MUST use Rebind and MUST include all bindings.
A client MUST ignore an Advertise message that contains no addresses (IAADDR in IA_NA/IA_TA) and no delegated prefixes (IAPREFIX in IA_PD), except that the client MUST still process any included SOL_MAX_RT and INF_MAX_RT options per RFC 7083, and MUST NOT restart the Solicit retransmission timer.
A client requesting multiple IA option types SHOULD use a single DHCPv6 session and, when the server only fulfills a subset of requested IAs, SHOULD continue including unfulfilled IA options in subsequent messages to the server rather than restarting the discovery process.
A client SHOULD accept Advertise messages even when not all requested IA option types are being offered, and SHOULD include the not-offered IA option types in its subsequent Request message. A client SHOULD only ignore an Advertise when none of the requested IAs include offered addresses or delegated prefixes.
A client SHOULD NOT send a Release message for non-conflicting bindings merely because it sent a Decline for a conflicting address. The client SHOULD retain non-conflicting bindings and treat the failed binding as simply unobtained when sending subsequent Renew/Rebind messages.
Clients MUST handle all three Advertise message formats for NoAddrsAvail: (1) IA_NA with encapsulated NoAddrsAvail and no top-level status, (2) top-level NoAddrsAvail with no IA_NA/IA_TA, and (3) both top-level and IA-encapsulated NoAddrsAvail. The latter two formats exist for backward compatibility with servers not updated to this specification.
For each IA in a Renew message for which the server cannot find a client binding, the server may create a new binding (if configured to do so), return NoAddrsAvail (if configured to create bindings but cannot assign addresses), or return NoBinding (if not configured to create bindings for Renew). The server MUST include Server Identifier and Client Identifier in the Reply.
For IA_PD, a requesting router MAY include IA_PD options without any prefixes (or with IPv6 prefix field set to 0) in Renew or Rebind messages to request bindings it desires but has been unable to obtain. The delegating router SHOULD assign prefixes in response to such requests per its configuration.
Section 18.1.2 of RFC 3315 required a client to MUST initiate a Confirm when it may have moved to a new link; RFC 7550 relaxes this to SHOULD, because a client may have determined link movement via other techniques (e.g., RFC 6059). A client with delegated prefixes MUST still send a Rebind instead.
Servers MUST return the NoAddrsAvail Status Code option encapsulated within the IA_NA/IA_TA option and MUST NOT return a top-level NoAddrsAvail Status Code when no addresses will be assigned in an Advertise message. This aligns Advertise handling with Reply message behavior.
The client MUST select T1 and T2 times as the minimum across all received IA options, guaranteeing that Renew/Rebind messages are sent no later than the earliest T1/T2 time associated with any binding. For example, a T1 of 0 from any IA means renew time is at the client's discretion but cannot exceed the corresponding T2.
The server MUST set T1/T2 times to the same values across all IA options in a Reply or Advertise message. The server MUST determine T1/T2 times considering all of the client's applicable bindings, to enable the client to renew all bindings simultaneously.
When a client receives a Reply to a Renew or Rebind containing a NoBinding status code for any IA, the client sends a Request message for only those IAs with NoBinding, while continuing to use other bindings that did not return an error. If IAs are missing from the Reply entirely, the client MUST limit the rate of subsequent Renew/Rebind messages to avoid a storm.
When processing a Rebind for an IA with no client binding, a server SHOULD only create new bindings if it is configured to respond to Solicit messages with Rapid Commit, to avoid the same issue of multiple servers creating bindings from a single Rebind broadcast.
When sending a Rebind message, the client SHOULD continue to include IA options received from the server and MAY include additional IA options to request creation of additional bindings that were previously unobtainable.
When sending a Renew message, the client SHOULD include IA options for existing bindings as well as IA options for all desired bindings it has been unable to obtain. An IA option for a desired-but-unobtained binding MUST NOT contain any addresses but MAY contain an IA Address option with IPv6 address set to 0 as a lifetime hint.
When the client receives a NoAddrsAvail status for an IA in a Reply, it may operate with addresses from other IAs and MAY include the NoAddrsAvail IAs (with no addresses) in subsequent Renew/Rebind messages to retry obtaining those addresses.
RFC 7550 introduces no new security considerations beyond those already present in RFC 3315 and RFC 3633. All existing DHCPv6 security considerations continue to apply.