DHCPv4 over DHCPv6 with Relay Agent Support
Extracted elements (19)
In a simple case where the same node hosts both the 4o6RA and the DHCP 4o6 server (e.g., a CPE device), it may be sufficient to use only the 4o6RA without an accompanying LDRA, as topology information is preserved locally.
Introducing 4o6RA at the edge of the IPv6 network hides the Layer 2 network from the DHCPv6 relay, breaking topology propagation because the 4o6RA alone provides no interface information in the encapsulated message. This is illustrated as 'Broken Topology Information' in Figure 2.
No new protocols or extensions are needed for the 4o6RA mechanism; it is a new use case for RFC 7341 where the relay agent, rather than the client, performs the DHCPv4-over-DHCPv6 encapsulation and decapsulation.
Since legacy IPv4 clients have no control over the information provided by the Relay Agent even when DHCP 4o6 is in use, moving DHCP 4o6 functionality from the client to the relay agent does not raise additional security concerns beyond those in RFC 7341.
The 4o6RA approach was chosen because legacy IPv4-only clients cannot easily be replaced or updated to implement DHCPv4-over-DHCPv6 (RFC 7341). By moving the encapsulation/decapsulation to an intermediate relay agent (switch or router), IPv4 clients require no changes and remain unaware of the DHCPv6 transport.
Intermediate relays in a DHCP 4o6 deployment with a 4o6RA shall behave according to Section 10 of RFC 7341, without any modifications required.
To maintain interoperability with existing DHCPv6 relays and servers, the 4o6RA message format is unchanged from RFC 9915, and the 4o6RA implements the same message types as a DHCPv6 Relay Agent as described in Section 6 of RFC 7341. No additional requirements on DHCPv6 servers are introduced.
All prerequisites and configurations that apply to the DHCP 4o6 client in Section 5 of RFC 7341 also apply to the 4o6RA, as the 4o6RA takes the role of the client in respect to RFC 7341.
For IPv4 topology discovery via DHCP, only the first Relay Agent SHOULD set the giaddr field (per Section 3.1 of RFC 7969), meaning in networks with multiple relay agents, only part of the topology is conveyed via DHCPv4.
For IPv6 topology discovery, all Relay Agents SHOULD send link-address and Interface-ID options that provide information about the complete path between the DHCPv6 client and the DHCPv6 server.
If the DHCPv4 message option is present and correct in a received DHCPV4-RESPONSE, the 4o6RA MUST extract the DHCPv4 message and forward it to the requesting DHCPv4 client, provided the encapsulated DHCPv4-RESPONSE is correct and can be forwarded.
It is RECOMMENDED that any implementation of 4o6RA be combined with an LDRA implementation (RFC 6221) in a back-to-back structure, and that the LDRA implementation includes a mechanism to obtain interface information to provide the Interface-ID option to outgoing DHCPV4-QUERY messages per Section 5.3.2 of RFC 6221, in order to preserve full topology information.
Layer 2 Relay Agents that receive DHCPV4-QUERY or DHCPV4-RESPONSE messages MUST handle them as specified in Section 6 of RFC 6221 (Lightweight DHCPv6 Relay Agent).
The 4o6RA, acting as DHCP 4o6 client, must request the DHCP 4o6 Server Address option from the server by sending the Option Request option as described in RFC 9915 before it can use the DHCP 4o6 transport.
When the 4o6RA receives a DHCPV4-RESPONSE message that does not contain a DHCPv4 message option, or that is not well-formed, the message MUST be discarded.
The 4o6RA deployment requires that all DHCPv4 broadcast and unicast messages to and from clients be steered through the 4o6RA. This can be achieved by placing the 4o6RA in a central position to intercept all client traffic, or by using NAT with the 4o6RA address for unicast messages.
The DHCPv4-over-DHCPv6 Relay Agent (4o6RA) is a new relay agent role that performs DHCPv4-over-DHCPv6 encapsulation and decapsulation on behalf of legacy IPv4-only clients, which are unaware that their DHCPv4 messages are being transported over DHCPv6. The 4o6RA acts as a DHCP 4o6 client toward the DHCPv6 network, satisfying all RFC 7341 client prerequisites.
In improperly configured networks where the DHCPv4 client is on the same Layer 2 scope as a DHCPv4 server, DHCPv4 messages could reach the server without traversing the 4o6RA, potentially causing erroneous state or misconfiguration. This is classified as a deployment error rather than a security concern introduced by this specification.
The security considerations of RFC 7341 apply in full. Since the legacy IPv4 client is unaware of the encapsulation and decapsulation, the 4o6RA must provide the protections specified in Section 12 of RFC 7341 on behalf of the client.