Ericsson

claudio.porfiri@ericsson.com

Cisco

suresh.krishnan@gmail.com

Ericsson

jari.arkko@ericsson.com

Ericsson

mirja.kuehlewind@ericsson.com

INT dhc dhcp This document describes a mechanism for networks with legacy IPv4-only clients to use services provided by DHCPv4 over DHCPv6 in a Relay Agent. RFC 7341 specifies the use of DHCPv4 over DHCPv6 in the client only. This document specifies an approach based on RFC 7341 that allows a Relay Agent to implement the DHCPv4-over-DHCPv6 encapsulation and decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a DHCPv4 client.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
  • .  Applicability Scope
• .  Conventions and Definitions
• .  DHCPv4-over-DHCPv6 Relay Agent (4o6RA)
  • .  Intermediate Relays
  • .  4o6RA and Topology Discovery
• .  Deployment Considerations
• .  Security Considerations
• .  IANA Considerations
• .  References
  • .  Normative References
  • .  Informative References
• .  Example Use Case: Topology Discovery for IPv4-Only Radio Unit in 3GPP RAN with Switched Fronthaul
• Acknowledgments
• Authors' Addresses

Introduction describes a transport mechanism for carrying DHCPv4 messages using DHCPv6 for dynamic provisioning of IPv4 addresses and other DHCPv4-specific configuration parameters across IPv6-only networks. The deployment of requires support in DHCP clients and at the DHCPv6 server. However, if a client is embedded in a host that only supports IPv4 and cannot easily be replaced or updated (which could be due to any number of technical or business reasons), this approach does not work. Similarly, the DHCPv6 Relay Agent specification defined in , which also refers to for the Lightweight DHCPv6 Relay Agent (LDRA) behavior, does not provide any mechanism to handle legacy DHCPv4, except by requiring the client to implement the DHCPv4-over-DHCPv6 encapsulation and decapsulation. This document specifies a solution based on that can be implemented in intermediate nodes such as switches or routers, without putting any requirements on clients. No new protocols or extensions are needed; instead, this document specifies a new use case for that allows a Relay Agent to perform the DHCPv4-over-DHCPv6 encapsulation and decapsulation instead of the client.

Applicability Scope The mechanisms described in this document apply to the configuration phase of hosts that need to receive an IPv4 address when a DHCP server for IPv4 is not reachable directly from the host. Furthermore, the host is unable to implement a DHCP client conformant to , as it is connected to an IPv4-only network. However, there is a DHCPv6 server that can provide IPv4 addresses by means of the mechanisms specified in .

Conventions and Definitions The following terms and abbreviations are used in this document:

DHCP:

Refers to DHCPv4 and/or DHCPv6 if not otherwise specified.

DHCP Relay Agent:

Refers to a common concept in all of the following protocols, although the details differ between them: the Bootstrap Protocol (BOOTP) , DHCPv4 , and DHCPv6 .

DHCPv4:

Refers to DHCP as defined in .

DHCPv4 over DHCPv6 (DHCP 4o6):

Refers to the architecture, the procedures, and the protocols specified in the DHCPv4-over-DHCPv6 document .

DHCPv4-over-DHCPv6 Relay Agent (4o6RA):

Refers to a Relay Agent that implements the DHCP 4o6 transport as specified in this document.

Layer 3 Relay Agent (L3RA):

Refers to a DHCP Relay Agent as specified in that is not a LDRA.

Lightweight DHCPv6 Relay Agent (LDRA):

Refers to an extension of the original DHCPv6 Relay Agent specification, to allow Layer 2 (L2) only devices to perform a Relay Agent function .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

DHCPv4-over-DHCPv6 Relay Agent (4o6RA) This document assumes a network where IPv4-only hosts are connected to a network that supports IPv6 and limited IPv4 services. To address such a network setup, this document extends DHCPv6 Relay Agents with DHCPv4 over DHCPv6, as shown in .

Architecture Example with Legacy DHCP Client .-----------. .-----------. | | | | +--------+-+ L2 +-+-----------+-+ IPv6 +-+--------+ | DHCPv4 | Network | DHCPv6 | Network | DHCP 4o6 | | Client +---------+ Relay Agent +---------+ Server | | | | with 4o6RA | | | +--------+-+ +-+-----------+-+ +-+--------+ | | | | '-----------' '-----------'

This document specifies the encapsulation and decapsulation specified in to be performed in the Relay Agent without requiring any changes on the DHCPv4 client. In this case, it is up to the Relay Agent to provide the full DHCP 4o6 support, and the legacy DHCPv4 client is not aware that it is being served via a DHCP 4o6 service. As the 4o6RA acts as a DHCP 4o6 client, all prerequisites and configurations that apply to the DHCP client in are also applied to the 4o6RA. As the 4o6RA takes the role of the client in respect to , it is responsible for determining a suitable interface where it acts as a DHCPv6 client, and it is responsible for locating a suitable DHCPv6 server or Relay Agent and obtaining the necessary IPv6 configuration. As specified in , the 4o6RA, acting as DHCP 4o6 client, therefore has to request the DHCP 4o6 Server Address option from the server by sending the Option Request option as described in before it can use the DHCP 4o6 transport. To maintain interoperability with existing DHCPv6 relays and servers, the message format is unchanged from . The 4o6RA implements the same message types as a DHCPv6 Relay Agent (see ). However, in this specification, the 4o6RA, instead of the client, creates the DHCPV4-QUERY message and encapsulates the DHCP request message received from the legacy DHCPv4 client. When the DHCPV4-RESPONSE message is received by the DHCP 4o6 Relay Agent, it looks for the DHCPv4 message option within this message. If this option is not found or the DHCPv4-RESPONSE message is not well-formed, it MUST be discarded. If the DHCPv4 message option is present and correct, the 4o6RA MUST extract the DHCPv4 message and forward the encapsulated DHCPv4-RESPONSE to the requesting DHCPv4 client, given that the encapsulated DHCPv4-RESPONSE is correct and can be actually forwarded. Layer 2 (L2) Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE messages MUST handle them as specified in . In any given environment, DHCPv6 servers to which DHCPV4-QUERY requests are routed are expected to be compliant with DHCP 4o6 according to . No additional requirements on DHCPv6 servers are set by this specification.

Intermediate Relays Intermediate relays shall behave according to .

4o6RA and Topology Discovery In some networks, the configuration of a host may depend on the topology. However, when a new host attaches to a network, it may be unaware of the topology and, consequently, how it has to be configured. DHCPv4 and DHCPv6 specifications describe how addresses can typically be allocated to clients based on network topology information provided by a DHCP relay. Address/prefix allocation decisions are integral to the allocation of addresses and prefixes in DHCP, as described in detail in . This specification aims to guarantee that the 4o6RA does not break any legacy capability when used for topology discovery. Topology discovery as described in differs between IPv4 and IPv6 as follows:

• IPv4: When using DHCP on IPv4, only the first Relay Agent SHOULD set the giaddr field (). Thus, in a network that has more than one Relay Agent, only part of the topology is transported via DHCPv4.
• IPv6: When using DHCPv6, 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 to the DHCPv6 server.

In Layer 2 networks, Lightweight DHCPv6 Relay Agents (LDRAs) can be used. When provided, the topology information is available at the DHCPv6 server in the form of a sequence of the link-address field and Interface-ID option. Then, topology information for the given IP address can be obtained from the DHCPv6 server and used for configuration or other purposes. enables the client to use DHCPv6 for topology discovery even within a DHCPv4 context, as the DHCPv6 Relay Agent knows the interface where the encapsulated DHCP request is received. However, as shown in , the introduction of DHCP 4o6 at the edge of the IPv6 network hides the Layer 2 network from the DHCPv6 RA. As such, moving DHCP 4o6 to an intermediate node rather than performing it at the client breaks the topology propagation, as 4o6RA-only solutions do not provide any interface information in the encapsulated message.

Broken Topology Information .-----------------. .-------------------------. | L2 Network | | IPv6 Network | +--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+ | DHCPv4 | | L2 | | 4o6 | | DHCPv6 | | DHCP 4o6 | | Client +--+ Switch +--+ Relay +----+ Relay +-------+ Server | | | | | | Agent | | Agent | | | +--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+ | | | | '-----------------' '-------------------------'

In order to provide full topology information, it is RECOMMENDED that any implementation of 4o6RA be combined with an LDRA implementation in a back-to-back structure and that the LDRA implementation includes a mechanism to obtain interface information that can be used to provide the Interface-ID option to outgoing DHCPV4-QUERY messages, as specified in . The internal mechanisms to exchange interface information, their format, and whether the interface information contains an indication that a 4o6RA is involved, are out of the scope for this document. The resulting architecture is shown in where the Relay Agent is implementing 4o6RA and LDRA and has an internal interface to propagate topology information from 4o6RA to LDRA.

Topology Information Preserved with LDRA .-----------------. .------------------------. | L2 Network or | | IPv6 Network | | IPv6-Only Link | | | +--------+-+ +---------+ +-+---+--+---------+ +------+---+ | DHCPv4 | | L2 | | 4o6 | LDRA | | DHCP 4o6 | | Client +--+ Switch +--+ Relay + RFC 6221+------+ Server | | | | | | Agent | | | | +--------+-+ +---------+ +-+---+--+---------+ +------+---+ | | | | '-----------------' '------------------------'

In a simple case, where the same node hosts the 4o6RA and the DHCP 4o6 server, it might be enough to only use 4o6RA, as shown in , where CPE stands for "Customer Premises Equipment".

Topology Information Preserved by 4o6 Relay Agent in DHCP Server .-----------. | L2 Network | +--------+-+ +-+------+----------+ | DHCP | | 4o6 | DHCP 4o6 | | Client +---------+ Relay + Server | | on CPE | | Agent | | +--------+-+ +-+------+----------+ | | '-----------'

Deployment Considerations As clients are unaware of the presence of 4o6RA, the network deployment needs to ensure that all DHCPv4 broadcast and unicast messages to and from clients are steered via a 4o6RA. This can be achieved by placing the 4o6RA in a central position that can intercept all traffic from the clients or by using Network Address Translation (NAT) with the 4o6RA address for unicast messages.

Security Considerations This document specifies the applicability of DHCP 4o6 in a scenario where legacy IPv4 clients are connected to DHCP 4o6 Relay Agents that perform the encapsulation and decapsulation. This document does not change anything else in the DHCP 4o6 specification ; therefore, the security considerations of that document still apply. Specifically, since the legacy IPv4 client is not aware of the encapsulation and decapsulation, 4o6RA has to provide the protections that are specified in the security considerations in . The mechanisms defined here differ from as they allow the DHCP client to send and receive DHCPv4 messages, whereas in , the client only sends DHCPv6 messages. This makes it possible that in improperly configured networks where the client is located on the same Layer 2 scope of a DHCPv4 server, DHCPv4 messages could reach a DHCPv4 server without using the 4o6RA. While this can cause erroneous state in both clients and servers and potentially even lead to misconfigurations that impact reachability, this is seen as a deployment error rather than a security concern. Further, even though this mechanism may be used for attacks from within the network, this is not a new concern introduced by this specification. More generally, legacy IPv4 clients are not aware of this mechanism; however, even when DHCP 4o6 is used, the client does not have any control about the information provided by the Relay Agent. As such, this change does not raise any additional security concerns.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. [STANDARDS-TRACK] IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document obsoletes RFC 8415. It incorporates verified errata and obsoletes the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). Informative References This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements. Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called "BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK] The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK] This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK] DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation.

Example Use Case: Topology Discovery for IPv4-Only Radio Unit in 3GPP RAN with Switched Fronthaul In 3GPP mobile network architecture, the User Equipment (UE) is connected via a Radio Access Network (RAN). RAN is built up with Baseband Units (BBUs) and Radio Units (RUs). A radio Fronthaul (FH) network connects RUs and BBUs. Each RU and BBU is an IP host, and they may support IPv4 only, IPv6 only, or both, depending on the vendor and the model. Each RU is unique as it is tied to a set of antennas, and each antenna is serving a specific Cell and Sector. Each RU is configured by the BBU depending on the Cell and Sectors it serves. However, that dependency is only specified by the cabling between RUs and antennas. BBUs can be cabled to RUs directly or via a Layer 2 switched network.

3GPP RAN Where RUs Are Cabled Directly to BBUs +--------+ | RU2 +-----+ | | | +--------+ | | +--------+ | | RU3 | | | +--+ | +-----------+ +--------+ | +--+ | +-----+ Baseband | | | +--------+ +-----+ Unit | | RU4 +--+ +--+ | | | | +-----------+ +--------+ | | +--------+ | | RU2 +-----+ | | +--------+

In , the BBU is directly cabled to a set of RUs, and the BBU can recognize the relationship between RUs and Cell/Sectors based on the cabling between the RUs and antennas. When BBUs and RUs are connected via a Layer 2 switched network, the added level of complexity requires the BBUs to have a deeper knowledge of the topology in order to properly configure the RUs, involving knowledge of all the cabling in the switched network. Examples for switched networks are shown in and demonstrate the different levels of complexity. An example of a FH is depicted in .

3GPP RAN with Layer 2 Switched Fronthaul Example +--------+ | RU1 | P1 +-+------+ | | | +--------+ | L2RA | | +----+------+ | +--------+ | +------+ | | | L3RA | | | L2 | +--+ +------+ | +--------+ P2 | Switch | | | | | | RU2 +--------+ #1 +-----+ | Router +----+ | | +--------+ | +-----------+ | +---------+ +--------+ | | | | | +--+ DHCP | +--------+ | | | Server | | RU3 | P1 +-+------+ | | | #1 | | +--------+ | L2RA | | +-----------+ | +---------+ +--------+ | +------+ | | | | | L2 | +--+ Baseband | | +--------+ P2 | Switch | | | Unit | | | RU4 +--------+ #2 +-----+ | +----+ | | +--------+ | +-----------+ | +--------+ | |

If IPv6 is used and all RUs are capable of DHCPv6 in , DHCP topology knowledge can be used for solving the RU configuration problem. Such solution would use the topology discovery mechanisms described in . If RUs are capable of IPv4 only but implement a DHCP 4o6 client according to , the same topology discovery mechanisms are applicable. If RUs are capable of IPv4 only and cannot implement a DHCP 4o6 client according to , the topology discovery mechanisms described in can be used by introducing 4o6RA in the switches as described in this document.

Acknowledgments The authors would like to acknowledge interesting discussions in this problem space with , , and , as well as reviews and comments provided by , , , , , , , , , , , and .

Authors' Addresses Ericsson

claudio.porfiri@ericsson.com

Cisco

suresh.krishnan@gmail.com

Ericsson

jari.arkko@ericsson.com

Ericsson

mirja.kuehlewind@ericsson.com