DHCPv4-over-DHCPv6 (DHCP 4o6) Transport
Extracted elements (28)
DHCPv4 over DHCPv6 is intentionally a special-purpose mechanism for nodes that cannot access native DHCPv4; it should not be enabled by default and may be activated by an administrative control or a dual-stack transition mechanism such as Lightweight 4over6.
The DHCP 4o6 server lacks DHCPv4 context (giaddr, IPv4 interface address) because the DHCPv4 message is encapsulated in DHCPv6. The server therefore allocates addresses by administrator-defined local policy; for relayed messages it MAY use the Relay-forward link-address, and for direct messages it MAY use the IPv6 source address to determine the appropriate IPv4 subnet.
The Unicast flag in the DHCPv4-query is necessary because IPv6 is used as the outer transport, eliminating any relationship between the outer IPv6 destination address and the DHCPv4 broadcast/unicast semantics; the server cannot infer the client's DHCPv4 state (e.g., RENEWING vs. REBINDING) from the IPv6 address.
A client using stateless DHCPv6 (Information-request) MUST follow RFC 4242 to periodically refresh its DHCPv4-over-DHCPv6 configuration; clients using stateful DHCPv6 refresh when renewing their IPv6 address lease via Renew/Rebind.
BOOTP messages (RFC 951) MAY also be transported using the DHCPv4 over DHCPv6 mechanism, since DHCPv4 is a special type of BOOTP message and the encapsulation does not restrict message types to DHCPv4 only.
Relay agent separate-destination logic only applies to the relay agent closest to the client (single relay hop); multiple relaying hops are not considered when using separate relay destinations for DHCP 4o6.
DHCPv6 relay agents that do not recognize DHCPv4-query MUST forward the unknown message as described in RFC 7283. Relay agents that do recognize it MAY forward DHCPV4-QUERY to a separately configured DHCP 4o6 server address.
If the client receives the DHCP 4o6 Server Address option on an interface where DHCPv4 is already active, the client MUST stop using IPv4 configuration obtained via DHCPv4 on that interface and MUST NOT use DHCPv4 on it while receiving the 4o6 Server Address option.
If the DHCP 4o6 Server Address option is empty, the client MUST send requests to the All_DHCP_Relay_Agents_and_Servers multicast address. If it contains addresses, the client SHOULD send to each unique address in the option.
The client MUST follow normal DHCPv4 retransmission requirements per RFC 2131 Section 4.1 for DHCPv4-query messages; there are no separate transmission parameters for the DHCPv6 encapsulation layer.
The client MUST implement RFC 4361 (node-specific client identifiers) and MUST send a 'client identifier' option when using DHCPv4 over DHCPv6 to ensure correct device identification.
The client MUST NOT use DHCPv4 over DHCPv6 if the DHCPv6 server does not include the DHCP 4o6 Server Address option; if that option subsequently expires or disappears on renewal, the client MUST stop using DHCPv4 over DHCPv6.
The client MUST obtain IPv6 configuration from a DHCPv6 server before using DHCPv4 over DHCPv6, and MUST request the DHCP 4o6 Server Address option in every Solicit, Request, Renew, Rebind, and Information-request message.
The client MUST put exactly one DHCPv4 Message option into a single DHCPv4-query message and MUST NOT request the DHCP 4o6 Server Address option within the DHCPv4-query message.
The DHCP 4o6 server discards a DHCPv4-query message that contains no DHCPv4 Message option. If the query was received directly, the DHCPv4-response MUST be unicast from the interface on which the original message was received.
The DHCP 4o6 server SHOULD use the 'flags' field (specifically the Unicast flag) of the DHCPv4-query message to determine how to create the DHCPv4 response (unicast vs. broadcast semantics).
The DHCPv4-response flags field is reserved; the DHCP 4o6 server MUST set all bits to 0 and the client MUST ignore the content of this field.
When sending DHCPv4-query to a multicast address, the client MUST use a link-local source address per RFC 3315. When sending unicast, the source address MUST be an address of appropriate scope acquired in advance.
DHCPv4-query (message type 20) is a new DHCPv6 message sent by the DHCP 4o6 client to a DHCP 4o6 server, carrying a DHCPv4 message encapsulated in the DHCPv4 Message option to request IPv4 configuration parameters.
DHCPv4-response (message type 21) is a new DHCPv6 message sent by the DHCP 4o6 server to the client, carrying a DHCPv4 response message encapsulated in the DHCPv4 Message option.
IANA allocated two DHCPv6 option codes: OPTION_DHCPV4_MSG (87) and OPTION_DHCP4_O_DHCP6_SERVER (88) from the DHCPv6 'Option Codes' table, and two DHCPv6 message type codes: DHCPV4-QUERY (20) and DHCPV4-RESPONSE (21) from the 'Message Types' table of the DHCPv6 registry.
A rogue server may reply with a DHCP 4o6 Server Address option containing duplicate IPv6 addresses, enabling an amplification attack. The client MUST check for duplicate addresses and MUST ignore all but the first instance of each address.
Enabling DHCPv4-over-DHCPv6 grants the DHCPv6 server the ability to shut off DHCPv4 (and consequently IPv4) traffic on the configured interface. The mechanism should only be enabled where there is a clear trust relationship, such as a CPE device on its WAN interface toward an ISP.
Encapsulating arbitrary messages in DHCPv6 could be exploited to bypass firewalls or network authentication gateways. However, the risk is no greater than the existing threat surface of DHCPv4 and DHCPv6 in current deployments.
Both DHCPv4-query and DHCPv4-response messages share the same format: 1-octet msg-type field (20 or 21), 3-octet flags field, followed by variable-length options. The DHCPv4 Message option MUST be present.
The DHCP 4o6 Server Address option (OPTION_DHCP4_O_DHCP6_SERVER, code 88) carries zero or more 16-octet IPv6 addresses of DHCP 4o6 servers. option-len is a multiple of 16; minimal length is 0 (empty option signals use of multicast).
The DHCPv4 Message option (OPTION_DHCPV4_MSG, code 87) encodes a raw DHCPv4 message (no IP/UDP headers) with a 2-octet option-code, 2-octet option-len, and variable-length DHCPv4-message payload.
The DHCPv4-query flags field is 24 bits. Bit U (unicast flag, MSB) indicates whether the encapsulated DHCPv4 message would have been sent to a unicast (1) or broadcast (0) IPv4 address. Remaining bits (MBZ) MUST be set to zero on send and ignored on receive.