Distributing Address Selection Policy Using DHCPv6
Extracted elements (22)
The absence of a DHCP-distributed policy on a given interface should not be interpreted as the administrator being indifferent to address selection; it may instead indicate a preference for the default RFC 6724 policy, so the default SHOULD be applied where no override is provided.
The option is designed to serve as a hint rather than a hard override, allowing node administrators to retain control while enabling site-wide behavioral consistency. This design balances operator authority with end-user flexibility.
The policy table and related parameters are treated as node-global information because the outbound interface is typically chosen after destination address selection. Therefore, a host cannot usefully maintain multiple per-interface address selection policies even if physically multihomed.
Implementations MAY store distributed address selection policies per interface, which can be effective on implementations that adopt per-application interface selection. Implementations MAY also provide configuration options to enable this protocol on a per-interface basis.
A single-homed host SHOULD use the default address selection options, and hosts using advanced heuristics to handle multiple received policies SHOULD also use Address Selection options.
DHCPv6 clients SHOULD convert the label field value to a representation appropriate for the local implementation (e.g., a string), since it is an unsigned integer with no intrinsic numeric meaning.
If an OPTION_ADDRSEL_TABLE option is received with a prefix-len greater than 128, the entire enclosing Address Selection option MUST be ignored.
In the absence of a distributed policy for a given network interface, the default address selection policy SHOULD be used.
Network administrators SHOULD consider local limitations on the maximum DHCPv6 message size and SHOULD consider the number of options, total option size, and resulting message size when defining their policy table, as UDP fragmentation should not be assumed.
The A flag SHOULD be set to 0 only when Automatic Row Addition at client hosts is harmful for site-specific reasons; similarly, the P flag SHOULD be set to 0 only when temporary addresses should not be preferred for site-specific reasons.
The client implementation SHOULD provide two choices to the user: (a) replace existing flags and active policy table with DHCPv6-distributed values, or (b) preserve the existing flags and table. Choice (a) SHOULD be the default when no explicit user configuration exists.
The implementation SHOULD follow the described processing method uniformly to ease troubleshooting and reduce operational costs, even though the node's administrator ultimately controls how received policy information is handled.
The server MUST set the Reserved field in OPTION_ADDRSEL to 0, and the client MUST ignore its content.
When DHCP-server-supplied information goes stale (e.g., interface down, server unresponsive, Information Refresh Time expired), the distributed flags and policy table SHOULD be deprecated, and the local configuration SHOULD be restored.
When the A flag is set to 0, a client SHOULD NOT automatically add rows to the policy table. Additionally, if the Address Selection option includes a POLICY TABLE option, automatic row addition SHOULD NOT be performed against the distributed policy table regardless of the A flag.
IPv4 addresses must be represented as IPv4-mapped IPv6 addresses (per RFC 4291) when encoded as a prefix value in the OPTION_ADDRSEL_TABLE prefix field.
The Address Selection option may contain zero policy table options, in which case it conveys only the A and P flags. Multiple OPTION_ADDRSEL_TABLE options within one OPTION_ADDRSEL together constitute a single policy table.
IANA assigned DHCPv6 option code 84 to OPTION_ADDRSEL and option code 85 to OPTION_ADDRSEL_TABLE in the 'DHCP Option Codes' registry for DHCPv6 parameters.
A rogue DHCPv6 server could issue bogus address selection policies, causing a client to use incorrect addresses. Affected packets may be blocked by ingress filtering, incur additional charges, or be misdirected to an attacker. Mitigation includes IPsec, SEND, DHCP authentication (RFC 3315 Section 21), or Layer 2 DHCP snooping.
An attacker can send packets with different source addresses to a destination to solicit different source addresses in responses, exploiting the privacy concern described in RFC 6724. The introduction of this DHCPv6 option does not modify this threat, regardless of whether the host is multihomed.
OPTION_ADDRSEL (option-code 84) carries a Reserved field, a 1-bit Automatic Row Addition flag (A), a 1-bit Privacy Preference flag (P), and zero or more POLICY TABLE OPTIONS of variable length. The option-len covers the Reserved byte, the flags, and all nested policy table options.
OPTION_ADDRSEL_TABLE (option-code 85) contains an 8-bit label, an 8-bit precedence, an 8-bit prefix-len (0–128), and a variable-length prefix field padded to the nearest octet boundary using (prefix-len + 7)/8 octets (0–16 bytes). Each instance corresponds to one row in the RFC 6724 policy table.