IPv6-Only Preferred Option for DHCPv4
updates
- rfc-2563 — DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
Extracted elements (21)
Delaying the IPv4 request until IPv6 reachability is confirmed was rejected because it would penalize IPv4-only and dual-stack networks. Releasing IPv4 after IPv6 is confirmed was also rejected because it disrupts applications already using the assigned address. The option-based approach adds no delay to IP stack configuration on non-supporting networks.
DHCPv4 is used to signal IPv6-only capability because it is already the mechanism used for IPv4 configuration, avoids requiring separate network segments for IPv6-only and dual-stack hosts, and ensures IPv4 is disabled only when both client and server explicitly agree, limiting the attack surface to existing DHCPv4 threat vectors without introducing new ones.
The option is restricted to networks providing NAT64 because that is the only transition technology widely supported by end hosts at the time of writing. Adding support for hypothetical future transition technologies is deferred; if a future mechanism is incompatible with NAT64, a new DHCPv4 option would be needed.
Clients can support both the IPv6-Only Preferred option and the Auto-Configure option simultaneously. When both are sent, the server can prevent IPv4 link-local address configuration by responding with yiaddr=0.0.0.0 and Auto-Configure set to DoNotAutoConfigure.
RFC 2563 Section 2.3 specified that a DHCPDISCOVER without the Auto-Configure option is not answered when no address is chosen. This document updates RFC 2563 so that a DHCPDISCOVER containing the IPv6-Only Preferred option (but not the Auto-Configure option) is still processed per the IPv6-Only Preferred option rules, preventing clients from silently waiting for a response that would never arrive.
DHCPv4 clients running on IPv6-only-capable hosts SHOULD include the IPv6-Only Preferred option code in the Parameter Request List in DHCPDISCOVER and DHCPREQUEST messages for enabled interfaces.
If a client includes both a Rapid Commit option (RFC 4039) and an IPv6-Only Preferred option in DHCPDISCOVER, the server SHOULD NOT honor the Rapid Commit option if its response would contain the IPv6-Only Preferred option; it SHOULD respond with a DHCPOFFER instead.
If a server cannot offer 0.0.0.0, it MAY include an available IPv4 address in the DHCPOFFER per RFC 2131, but that address MUST be valid and not committed to any other client. The server SHOULD NOT reserve it or verify its uniqueness since the client is not expected to request it.
If the client includes the IPv6-Only Preferred option code in the Parameter Request List but the DHCPOFFER lacks a valid IPv6-Only Preferred option, the client MUST proceed normally with a DHCPREQUEST.
If the client receives a valid IPv6-Only Preferred option in a DHCPOFFER, it SHOULD NOT request the IPv4 address provided. It SHOULD set V6ONLY_WAIT to the option value if >= MIN_V6ONLY_WAIT, otherwise to MIN_V6ONLY_WAIT, and SHOULD stop DHCPv4 configuration for that duration or until a network attachment event.
If the IPv6-Only Preferred option is in the client's Parameter Request List and the pool is IPv6-mostly, the server MUST include the option in DHCPOFFER or DHCPACK. The server SHOULD NOT assign an address from the pool; instead it SHOULD return 0.0.0.0 as the offered address.
If the server pool is explicitly configured with a V6ONLY_WAIT timer, the server MUST set the Value field to that configured value; otherwise the server MUST set it to zero.
The DHCPv4 client on an IPv4-requiring host MUST NOT include the IPv6-Only Preferred option code in the Parameter Request List and MUST ignore that option in packets received from DHCPv4 servers.
The server MUST NOT include the IPv6-Only Preferred option in DHCPOFFER or DHCPACK if the selected pool is not configured as IPv6-mostly, or if the option was not present in the client's Parameter Request List.
The server MUST set the Length field to 4. The client MUST ignore the IPv6-Only Preferred option if the Length field value is not 4.
The IPv6-Only Preferred DHCPv4 option (code 108) allows a client to indicate it does not need an IPv4 address if the network provides IPv6-only connectivity via NAT64/DNS64. The server responds with a V6ONLY_WAIT timer value telling the client how long to suppress DHCPv4.
V6ONLY_WAIT is the duration (in seconds) for which a client SHOULD stop DHCPv4 configuration after receiving the IPv6-Only Preferred option. Default is 1800 seconds; it MUST NOT be less than MIN_V6ONLY_WAIT (300 seconds).
IANA assigned DHCPv4 option code 108 in the 'BOOTP Vendor Extensions and DHCP Options' registry for the IPv6-Only Preferred option, with Data Length 4, meaning 'Number of seconds that DHCPv4 should be disabled'.
An attacker can send a spoofed DHCPOFFER with the IPv6-Only Preferred option value set to 0xffffffff, effectively disabling DHCPv4 on supporting clients. On IPv4-only networks this causes complete connectivity loss; on dual-stack networks without NAT64, only IPv4-only destinations are affected. Recovery requires a network attachment event.
The rogue-DHCPOFFER attack vector enabled by this option is not materially worse than the pre-existing attack of offering an invalid address with Lease Time set to 0xffffffff (RFC 2132), which affects all hosts. Standard DHCPv4 server authentication and rogue-server protection mitigates both. Additionally, disabling IPv4 on receipt of the option reduces the IPv4 attack surface and can be considered a security benefit.
The IPv6-Only Preferred option consists of an 8-bit Code field (value 108), an 8-bit Length field (MUST be 4), and a 32-bit unsigned integer Value field encoding V6ONLY_WAIT in seconds. Total option length is 6 octets.