rfc9928.original   rfc9928.txt 
Dynamic Host Configuration C. Porfiri Internet Engineering Task Force (IETF) C. Porfiri
Internet-Draft Ericsson Request for Comments: 9928 Ericsson
Intended status: Standards Track S. Krishnan Category: Standards Track S. Krishnan
Expires: 27 February 2026 Cisco ISSN: 2070-1721 Cisco
J. Arkko J. Arkko
M. Kühlewind M. Kühlewind
Ericsson Ericsson
26 August 2025 February 2026
DHCPv4-over-DHCPv6 with Relay Agent Support DHCPv4 over DHCPv6 with Relay Agent Support
draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06
Abstract Abstract
This document describes a mechanism for networks with legacy This document describes a mechanism for networks with legacy
IPv4-only clients to use services provided by DHCPv4-over-DHCPv6 in a IPv4-only clients to use services provided by DHCPv4 over DHCPv6 in a
Relay Agent. RFC7341 specifies use of DHCPv4-over-DHCPv6 in the Relay Agent. RFC 7341 specifies the use of DHCPv4 over DHCPv6 in the
client only. This document specifies a RFC7341-based approach that client only. This document specifies an approach based on RFC 7341
allows a Relay Agent to implement the DHCP 4o6 encapsulation and that allows a Relay Agent to implement the DHCP 4o6 encapsulation and
decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a
DHCPv4 client. DHCPv4 client.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-
dhcpv6-ra/.
Source for this draft and an issue tracker can be found at
https://github.com/mirjak/draft-dhc-dhcpv4-over-dhcpv6-ra.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9928.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 February 2026.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Applicability Scope . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability Scope
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions
3. DHCPv4 over DHCPv6 Relay Agent (4o6RA) . . . . . . . . . . . 4 3. DHCPv4-over-DHCPv6 Relay Agent (4o6RA)
3.1. Intermediate relays . . . . . . . . . . . . . . . . . . . 5 3.1. Intermediate Relays
3.2. 4o6RA and Topology Discovery . . . . . . . . . . . . . . 5 3.2. 4o6RA and Topology Discovery
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 4. Deployment Considerations
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References
7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.1. Normative References
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7.2. Informative References
Appendix A. Example Use Case: Topology Discovery for IPv4-only Appendix A. Example Use Case: Topology Discovery for IPv4-Only
Radio Unit in 3GPP RAN with Switched Fronthaul . . . . . 9 Radio Unit in 3GPP RAN with Switched Fronthaul
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses
1. Introduction 1. Introduction
[RFC7341] describes a transport mechanism for carrying DHCPv4 [RFC7341] describes a transport mechanism for carrying DHCPv4
[RFC2131] messages using DHCPv6 [draft-ietf-dhc-rfc8415bis] for [RFC2131] messages using DHCPv6 [RFC9915] for dynamic provisioning of
dynamic provisioning of IPv4 addresses and other DHCPv4 specific IPv4 addresses and other DHCPv4-specific configuration parameters
configuration parameters across IPv6-only networks. The deployment across IPv6-only networks. The deployment of [RFC7341] requires
of [RFC7341] requires support in DHCP clients and at the DHCPv6 support in DHCP clients and at the DHCPv6 server. However, if a
server. However, if a client is embedded in a host that only client is embedded in a host that only supports IPv4 and cannot
supports IPv4 and cannot easily be replaced or updated (which could easily be replaced or updated (which could be due to any number of
be due to any number of technical or business reasons), this approach technical or business reasons), this approach does not work.
does not work.
Similarly, the specifications for DHCPv6 Relay Agents such as Similarly, the specifications for DHCPv6 Relay Agents such as
Lightweight DHCPv6 Relay Agent (LDRA) [RFC6221] or DHCPv6 Relay Agent Lightweight DHCPv6 Relay Agent (LDRA) [RFC6221] or DHCPv6 Relay Agent
(L3RA) [draft-ietf-dhc-rfc8415bis] do not foresee the possibility to (L3RA) [RFC9915] do not foresee the possibility to handle legacy
handle legacy DHCPv4, other than implementing DHCP 4o6 in the client. DHCPv4, other than implementing DHCP 4o6 in the client.
This document specifies an [RFC7341] based solution that can be This document specifies a solution based on [RFC7341] that can be
implemented in intermediate nodes such as switches or routers, implemented in intermediate nodes such as switches or routers,
without putting any requirements on clients. No new protocols or without putting any requirements on clients. No new protocols or
extensions are needed; instead, this document specifies a new use extensions are needed; instead, this document specifies a new use
case for [RFC7341] that allows a Relay Agent to perform the DHCP 4o6 case for [RFC7341] that allows a Relay Agent to perform the DHCP 4o6
encapsulation and decapsulation instead of the client. encapsulation and decapsulation instead of the client.
1.1. Applicability Scope 1.1. Applicability Scope
The mechanisms described in this document apply to the configuration The mechanisms described in this document apply to the configuration
phase of hosts that need to receive an IPv4 address when a DHCP phase of hosts that need to receive an IPv4 address when a DHCP
server for IPv4 [RFC2131] is not reachable directly from the host. server for IPv4 [RFC2131] is not reachable directly from the host.
Furthermore, the host is unable to implement a DHCP client conformant Furthermore, the host is unable to implement a DHCP client conformant
to [RFC7341] as it is connected to an IPv4-only network. But there to [RFC7341], as it is connected to an IPv4-only network. However,
is a DHCPv6 server that can provide IPv4 addresses by means of the there is a DHCPv6 server that can provide IPv4 addresses by means of
mechanisms specified in [RFC7341]. the mechanisms specified in [RFC7341].
2. Conventions and Definitions 2. Conventions and Definitions
The following terms and acronyms are used in this document: The following terms and abbreviations are used in this document:
* DHCP: If not otherwise specified, DHCP refers to DHCPv4 and/or DHCP:
DHCPv6. If not otherwise specified, DHCP refers to DHCPv4 and/or DHCPv6.
* DHCPv4: DHCP as defined in [RFC2131]. DHCPv4:
DHCP as defined in [RFC2131].
* DHCPv4 over DHCPv6 (or 4o6): The architecture, the procedures, and DHCPv4 over DHCPv6 (DHCP 4o6):
the protocols specified in the DHCPv4-over-DHCPv6 document The architecture, the procedures, and the protocols specified in
[RFC7341]. the DHCPv4-over-DHCPv6 document [RFC7341].
* DHCP Relay Agent: This is a concept in all of the following DHCP Relay Agent:
protocols, although the details differ between them: BOOTP This is a concept in all of the following protocols, although the
[RFC951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6 details differ between them: the Bootstrap Protocol (BOOTP)
[draft-ietf-dhc-rfc8415bis]. [RFC0951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6
[RFC9915].
* Lightweight DHCPv6 Relay Agent (or LDRA): This is an extension of Lightweight DHCPv6 Relay Agent (LDRA):
the original DHCPv6 Relay Agent specification, to allow layer- This is an extension of the original DHCPv6 Relay Agent
2-only devices to perform a Relay Agent function [RFC6221]. specification, to allow Layer 2 (L2) only devices to perform a
Relay Agent function [RFC6221].
* DHCPv4 over DHCPv6 Relay Agent (or 4o6RA): Refers to a Relay Agent DHCPv4-over-DHCPv6 Relay Agent (4o6RA):
that implements the 4o6 transport as specified in this document. Refers to a Relay Agent that implements the 4o6 transport as
specified in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. DHCPv4 over DHCPv6 Relay Agent (4o6RA) 3. DHCPv4-over-DHCPv6 Relay Agent (4o6RA)
This document assumes a network, where IPv4-only hosts are connected This document assumes a network where IPv4-only hosts are connected
to a network that supports IPv6 and limited IPv4 services. to a network that supports IPv6 and limited IPv4 services.
To address such a network setup, this document extends DHCPv6 Relay To address such a network setup, this document extends DHCPv6 Relay
Agents with DHCPv4-over-DHCPv6, as shown in Figure 1. Agents with DHCPv4 over DHCPv6, as shown in Figure 1.
.-----------. .-----------. .-----------. .-----------.
| | | | | | | |
+--------+-+ L2 +-+-----------+-+ IPv6 +-+--------+ +--------+-+ L2 +-+-----------+-+ IPv6 +-+--------+
| DHCPv4 | Network | DHCPv6 | Network | DHCP 4o6 | | DHCPv4 | Network | DHCPv6 | Network | DHCP 4o6 |
| Client +---------+ Relay Agent +---------+ Server | | Client +---------+ Relay Agent +---------+ Server |
| | | with 4o6RA | | | | | | with 4o6RA | | |
+--------+-+ +-+-----------+-+ +-+--------+ +--------+-+ +-+-----------+-+ +-+--------+
| | | | | | | |
'-----------' '-----------' '-----------' '-----------'
Figure 1: Architecture Example with Legacy DHCP Client Figure 1: Architecture Example with Legacy DHCP Client
This document specifies the encapsulation and decapsulation specified This document specifies the encapsulation and decapsulation specified
in [RFC7341] to be performed in the Relay Agent without requiring any in [RFC7341] to be performed in the Relay Agent without requiring any
changes on the DHCPv4 client. In this case it is up to the Relay 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 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. 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 As the 4o6RA acts as a DHCP 4o6 client, all prerequisites and
configuration that apply to the DHCP client in Section 5 of [RFC7341] configurations that apply to the DHCP client in Section 5 of
are also applied to the 4o6RA. [RFC7341] are also applied to the 4o6RA.
As the 4o6RA takes the role of the client in respect to [RFC7341], it As the 4o6RA takes the role of the client in respect to [RFC7341], it
is responsible for determining a suitable interface where it acts as is responsible for determining a suitable interface where it acts as
a DHCPv6 client, and it is responsible for locating a suitable DHCPv6 a DHCPv6 client, and it is responsible for locating a suitable DHCPv6
server or relay agent and obtain the necessary IPv6 configuration.. server or Relay Agent and obtaining the necessary IPv6 configuration.
As specified in [RFC7341], the 4o6RA, acting as 4o6 client, therefore As specified in [RFC7341], the 4o6RA, acting as 4o6 client, therefore
has to request the DHCP 4o6 Server Address option from the server by has to request the DHCP 4o6 Server Address option from the server by
sending the Option Request option as described in sending the Option Request option as described in [RFC9915] before it
[draft-ietf-dhc-rfc8415bis] before it can use the 4o6 transport. can use the 4o6 transport.
To maintain interoperability with existing DHCPv6 relays and servers, To maintain interoperability with existing DHCPv6 relays and servers,
the message format is unchanged from [draft-ietf-dhc-rfc8415bis]. the message format is unchanged from [RFC9915]. The 4o6RA implements
The 4o6RA implements the same message types as a DHCPv6 Relay Agent the same message types as a DHCPv6 Relay Agent (see Section 6 of
Section 6 of [RFC7341]. [RFC7341]).
However, in this specification, the 4o6RA, instead of the client, However, in this specification, the 4o6RA, instead of the client,
creates the DHCPV4-QUERY Message and encapsulates the DHCP request creates the DHCPV4-QUERY message and encapsulates the DHCP request
message received from the legacy DHCPv4 client. message received from the legacy DHCPv4 client.
When DHCPV4-RESPONSE Message is received by the 4o6 Relay Agent, it When the DHCPV4-RESPONSE message is received by the 4o6 Relay Agent,
looks for the DHCPv4 Message option within this message. If this it looks for the DHCPv4 message option within this message. If this
option is not found or the DHCPv4-RESPONSE message is not well- option is not found or the DHCPv4-RESPONSE message is not well-
formed, it MUST be discarded. If the DHCPv4 Message option is formed, it MUST be discarded. If the DHCPv4 message option is
present and correct, the 4o6RA MUST extract the DHCPv4 message and present and correct, the 4o6RA MUST extract the DHCPv4 message and
forward the encapsulated DHCPv4-response to the requesting DHCPv4 forward the encapsulated DHCPv4-RESPONSE to the requesting DHCPv4
client, given that the encapsulated DHCPv4-response is correct and client, given that the encapsulated DHCPv4-RESPONSE is correct and
can be actually forwarded. can be actually forwarded.
Layer-2 Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE Layer 2 (L2) Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE
messages MUST handle them as specified in Section 6 of [RFC6221]. messages MUST handle them as specified in Section 6 of [RFC6221].
In any given environment, DHCPv6 servers to which DHCPV4-QUERY In any given environment, DHCPv6 servers to which DHCPV4-QUERY
requests are routed are expected to be compliant with 4o6 according requests are routed are expected to be compliant with 4o6 according
to [RFC7341]. No additional requirements on DHCPv6 servers are set to [RFC7341]. No additional requirements on DHCPv6 servers are set
by this specification. by this specification.
3.1. Intermediate relays 3.1. Intermediate Relays
Intermediate relays shall behave according to section 10 of Intermediate relays shall behave according to Section 10 of
[RFC7341]. [RFC7341].
3.2. 4o6RA and Topology Discovery 3.2. 4o6RA and Topology Discovery
In some networks, the configuration of a host may depend on the 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 topology. However, when a new host attaches to a network, it may be
unaware of the topology and, consequently, how it has to be unaware of the topology and, consequently, how it has to be
configured. configured.
DHCPv4 [RFC2131] and DHCPv6 [draft-ietf-dhc-rfc8415bis] DHCPv4 [RFC2131] and DHCPv6 [RFC9915] specifications describe how
specifications describe how addresses can be allocated to clients addresses can typically be allocated to clients based on network
based on network topology information provided by a DHCP relay, topology information provided by a DHCP relay.
typically.
Address/prefix allocation decisions are integral to the allocation of Address/prefix allocation decisions are integral to the allocation of
addresses and prefixes in DHCP, as described in detail in [RFC7969]. addresses and prefixes in DHCP, as described in detail in [RFC7969].
This specification aims to guarantee that the 4o6RA does not break This specification aims to guarantee that the 4o6RA does not break
any legacy capability when used for topology discovery. any legacy capability when used for topology discovery.
Topology discovery as described in [RFC7969] differs between IPv4 and Topology discovery as described in [RFC7969] differs between IPv4 and
IPv6: IPv6 as follows:
* IPv4: when using DHCP on IPv4 only the first Relay Agent SHOULD * IPv4: When using DHCP on IPv4, only the first Relay Agent SHOULD
set the giaddr field (section 3.1 of [RFC7969]). Thus, in a set the giaddr field (Section 3.1 of [RFC7969]). Thus, in a
network that has more than one Relay Agent only part of the network that has more than one Relay Agent, only part of the
topology is transported via DHCPv4. topology is transported via DHCPv4.
* IPv6: when using DHCPv6, all Relay Agents SHOULD send link-address * IPv6: When using DHCPv6, all Relay Agents SHOULD send link-address
and Interface-ID options, that provide information about the and Interface-ID options that provide information about the
complete path between the DHCPv6 client and the DHCPv6 server to complete path between the DHCPv6 client and the DHCPv6 server to
the DHCPv6 server. the DHCPv6 server.
In Layer-2 networks, Lightweight DHCPv6 Relay Agents [RFC6221] can be In Layer 2 networks, Lightweight DHCPv6 Relay Agents (LDRAs)
used. [RFC6221] can be used.
When provided, the topology information is available at the DHCPv6 When provided, the topology information is available at the DHCPv6
server in the form of a sequence of the link-address field and server in the form of a sequence of the link-address field and
Interface-ID option. Interface-ID option.
Then, topology information for the given IP address can be obtained Then, topology information for the given IP address can be obtained
from the DHCPv6 server and used for configuration or other purposes. from the DHCPv6 server and used for configuration or other purposes.
[RFC7341] enables the client to use DHCPv6 for topology discovery [RFC7341] enables the client to use DHCPv6 for topology discovery
even within a DHCPv4 context, as the DHCPv6 Relay Agent knows the even within a DHCPv4 context, as the DHCPv6 Relay Agent knows the
interface where the encapsulated DHCP request is received. As shown interface where the encapsulated DHCP request is received. However,
in Figure 2, however, the introduction of 4o6 at the edge of the IPv6 as shown in Figure 2, the introduction of 4o6 at the edge of the IPv6
network hides the Layer-2 network from the DHCPv6 RA. As such, network hides the Layer 2 network from the DHCPv6 RA. As such,
moving 4o6 to a intermediate node rather than performing it at the moving 4o6 to an intermediate node rather than performing it at the
client breaks the topology propagation, as 4o6RA-only solutions does client breaks the topology propagation, as 4o6RA-only solutions do
not provide any interface information in the encapsulated message. not provide any interface information in the encapsulated message.
.-----------------. .-------------------------. .-----------------. .-------------------------.
| L2 Network | | IPv6 Network | | L2 Network | | IPv6 Network |
+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+ +--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+
| DHCPv4 | | L2 | | 4o6 | | DHCPv6 | | DHCP 4o6 | | DHCPv4 | | L2 | | 4o6 | | DHCPv6 | | DHCP 4o6 |
| Client +--+ Switch +--+ Relay +----+ Relay +-------+ Server | | Client +--+ Switch +--+ Relay +----+ Relay +-------+ Server |
| | | | | Agent | | Agent | | | | | | | | Agent | | Agent | | |
+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+ +--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+
| | | | | | | |
'-----------------' '-------------------------' '-----------------' '-------------------------'
Figure 2: Broken topology information Figure 2: Broken Topology Information
In order to provide full topology information, it is RECOMMENDED that In order to provide full topology information, it is RECOMMENDED that
any implementation of 4o6RA be combined with an LDRA implementation any implementation of 4o6RA be combined with an LDRA implementation
[RFC6221] in a back-to-back structure, and that the LDRA [RFC6221] in a back-to-back structure and that the LDRA
implementation includes a mechanism to obtain interface information implementation includes a mechanism to obtain interface information
that can be used to provide the Interface-ID option to outgoing that can be used to provide the Interface-ID option to outgoing
DHCPV4-QUERY messages, as specified in Section 5.3.2 of [RFC6221]. DHCPV4-QUERY messages, as specified in Section 5.3.2 of [RFC6221].
The internal mechanisms to exchange interface information, their The internal mechanisms to exchange interface information, their
format and whether the interface information contains an indication format, and whether the interface information contains an indication
that a 4o6RA is involved are out of the scope for this document. that a 4o6RA is involved, are out of the scope for this document.
The resulting architecture is shown in Figure 3 where the Relay Agent The resulting architecture is shown in Figure 3 where the Relay Agent
is implementing 4o6RA and LDRA, and has an internal interface to is implementing 4o6RA and LDRA and has an internal interface to
propagate topology information from 4o6RA to LDRA. propagate topology information from 4o6RA to LDRA.
.-----------------. .------------------------. .-----------------. .------------------------.
| L2 Network or | | IPv6 Network | | L2 Network or | | IPv6 Network |
| IPv6-only link | | | | IPv6-Only Link | | |
+--------+-+ +---------+ +-+---+--+---------+ +------+---+ +--------+-+ +---------+ +-+---+--+---------+ +------+---+
| DHCPv4 | | L2 | | 4o6 | LDRA | | DHCP 4o6 | | DHCPv4 | | L2 | | 4o6 | LDRA | | DHCP 4o6 |
| Client +--+ Switch +--+ Relay + RFC6221 +------+ Server | | Client +--+ Switch +--+ Relay + RFC 6221+------+ Server |
| | | | | Agent | | | | | | | | | Agent | | | |
+--------+-+ +---------+ +-+---+--+---------+ +------+---+ +--------+-+ +---------+ +-+---+--+---------+ +------+---+
| | | | | | | |
'-----------------' '------------------------' '-----------------' '------------------------'
Figure 3: Topology information preserved with LDRA Figure 3: Topology Information Preserved with LDRA
In a simple case, where the same node hosts the 4o6RA and the DHCP4o6 In a simple case, where the same node hosts the 4o6RA and the DHCP
server, it might be enough to only use 4o6RA, as shown in Figure 4. 4o6 server, it might be enough to only use 4o6RA, as shown in
Figure 4.
.-----------. .-----------.
| L2 Network | | L2 Network |
+--------+-+ +-+------+----------+ +--------+-+ +-+------+----------+
| DHCP | | 4o6 | DHCP 4o6 | | DHCP | | 4o6 | DHCP 4o6 |
| Client +---------+ Relay + Server | | Client +---------+ Relay + Server |
| on CPE | | Agent | | | on CPE | | Agent | |
+--------+-+ +-+------+----------+ +--------+-+ +-+------+----------+
| | | |
'-----------' '-----------'
Figure 4: Topology information preserved by 4o6 Relay Agent in Figure 4: Topology Information Preserved by 4o6 Relay Agent in
DHCP server DHCP Server
4. Deployment Considerations 4. Deployment Considerations
As clients are unaware of the presence of 4o6RA, the network As clients are unaware of the presence of 4o6RA, the network
deployment needs to ensure that all DHCPv4 broadcast and unicast deployment needs to ensure that all DHCPv4 broadcast and unicast
messages to and from clients are steered via a 4o6RA. This can be messages to and from clients are steered via a 4o6RA. This can be
achieved by placing the 4o6RA in a central position that can achieved by placing the 4o6RA in a central position that can
intercept all traffic from the clients or by using Network Address intercept all traffic from the clients or by using Network Address
Translation (NAT) with the 4o6RA address for unicast messages. Translation (NAT) with the 4o6RA address for unicast messages.
5. Security Considerations 5. Security Considerations
This document specifies the applicability of 4o6 DHCP in a scenario This document specifies the applicability of DHCP 4o6 in a scenario
where legacy IPv4 clients are connected to 4o6 DHCP Relay Agents that where legacy IPv4 clients are connected to 4o6 DHCP Relay Agents that
perform the encapsulation and decapsulation. This document does not perform the encapsulation and decapsulation. This document does not
change anything else in the 4o6 DHCP specification and therefore the change anything else in the DHCP 4o6 specification; therefore, the
security considerations of [RFC7341] still apply. Specifically, security considerations of [RFC7341] still apply. Specifically,
since the legacy IPv4 client is not aware of the encapsulation and since the legacy IPv4 client is not aware of the encapsulation and
decapsulation, it is 4o6RA has to provide the protections that are decapsulation, 4o6RA has to provide the protections that are
specficed in the security considerations in Section 12 of [RFC7341]. specified in the security considerations in Section 12 of [RFC7341].
The mechanisms defined here differ from [RFC7341] as they allow the The mechanisms defined here differ from [RFC7341] as they allow the
DHCP client to send and receive DHCPv4 messages, whereas in [RFC7341] DHCP client to send and receive DHCPv4 messages, whereas in
the client only sends DHCPv6 messages. This makes it possible that [RFC7341], the client only sends DHCPv6 messages. This makes it
in improperly configured networks where the client is located on the possible that in improperly configured networks where the client is
same Layer-2 scope of a DHCPv4 server, DHCPv4 messages could reach a located on the same Layer 2 scope of a DHCPv4 server, DHCPv4 messages
DHCPv4 server without using the 4o6RA. While this can cause could reach a DHCPv4 server without using the 4o6RA. While this can
erroneous state in both clients and servers and potentially even lead cause erroneous state in both clients and servers and potentially
to misconfigurations that impact reachability, this is seen as a even lead to misconfigurations that impact reachability, this is seen
deployment error rather than a security concern. Further, even as a deployment error rather than a security concern. Further, even
though this mechanism may be used for attacks from within the though this mechanism may be used for attacks from within the
network, this is not a new concern introduced by this specification. network, this is not a new concern introduced by this specification.
More generally, legacy IPv4 clients are not aware of this mechanism, More generally, legacy IPv4 clients are not aware of this mechanism;
however, even when DHCP 4o6 is used, the client does not have any however, even when DHCP 4o6 is used, the client does not have any
control about the information provided by the Relay agent. As such control about the information provided by the Relay Agent. As such,
this change does not raise any additional security concerns. this change does not raise any additional security concerns.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. References 7. References
7.1. Normative References 7.1. Normative References
[draft-ietf-dhc-rfc8415bis]
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
June 2025, <https://datatracker.ietf.org/doc/draft-ietf-
dhc-rfc8415bis/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. [RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
DOI 10.17487/RFC6221, May 2011, DOI 10.17487/RFC6221, May 2011,
<https://www.rfc-editor.org/rfc/rfc6221>. <https://www.rfc-editor.org/info/rfc6221>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. [RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport",
RFC 7341, DOI 10.17487/RFC7341, August 2014, RFC 7341, DOI 10.17487/RFC7341, August 2014,
<https://www.rfc-editor.org/rfc/rfc7341>. <https://www.rfc-editor.org/info/rfc7341>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9915] Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", STD 102, RFC 9915, DOI 10.17487/RFC9915,
January 2026, <https://www.rfc-editor.org/info/rfc9915>.
7.2. Informative References 7.2. Informative References
[RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
DOI 10.17487/RFC0951, September 1985,
<https://www.rfc-editor.org/info/rfc951>.
[RFC1542] Wimer, W., "Clarifications and Extensions for the [RFC1542] Wimer, W., "Clarifications and Extensions for the
Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542, Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542,
October 1993, <https://www.rfc-editor.org/rfc/rfc1542>. October 1993, <https://www.rfc-editor.org/info/rfc1542>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/rfc/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/rfc/rfc2132>. <https://www.rfc-editor.org/info/rfc2132>.
[RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP
Configuration on the Basis of Network Topology", RFC 7969, Configuration on the Basis of Network Topology", RFC 7969,
DOI 10.17487/RFC7969, October 2016, DOI 10.17487/RFC7969, October 2016,
<https://www.rfc-editor.org/rfc/rfc7969>. <https://www.rfc-editor.org/info/rfc7969>.
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
DOI 10.17487/RFC0951, September 1985,
<https://www.rfc-editor.org/rfc/rfc951>.
Appendix A. Example Use Case: Topology Discovery for IPv4-only Radio Appendix A. Example Use Case: Topology Discovery for IPv4-Only Radio
Unit in 3GPP RAN with Switched Fronthaul Unit in 3GPP RAN with Switched Fronthaul
In 3GPP mobile network architecture, the User Equipments (UE) are In 3GPP mobile network architecture, the User Equipment (UE) is
connected via Radio Access Network (RAN). RAN is built up with connected via Radio Access Network (RAN). RAN is built up with
Baseband Units (BB) and Radio Units (RU). Radio Fronthaul Network Baseband Units (BBs) and Radio Units (RUs). Radio Fronthaul Network
(FH) connects RU and BB, each of RU and BB is an IP host, they may (FH) connects RUs and BBs. Each RU and BB is an IP host, and they
support IPv4 only, IPv6 only or both depending on the vendor and the may support IPv4 only, IPv6 only, or both, depending on the vendor
model. Each RU is unique as it is tied to a set of antennas, and and the model. Each RU is unique as it is tied to a set of antennas,
each antenna is serving a specific Cell and Sector. Each RU is and each antenna is serving a specific Cell and Sector. Each RU is
configured by the BB depending on the Cell and Sectors it serves. configured by the BB depending on the Cell and Sectors it serves.
However, that dependency is only specified by the cabling between RUs
However, that dependency is only specified by the cabling between RU and antennas. BBs can be cabled to RUs directly or via a Layer 2
and antennas. BB can be cabled to RU directly or via a Layer-2
switched network. switched network.
+--------+ +--------+
| RU2 +-----+ | RU2 +-----+
| | | | | |
+--------+ | +--------+ |
| |
+--------+ | +--------+ |
| RU3 | | | RU3 | |
| +--+ | +-----------+ | +--+ | +-----------+
skipping to change at page 10, line 30 skipping to change at line 441
+--------+ +-----| Unit | +--------+ +-----| Unit |
| RU4 +--+ +--| | | RU4 +--+ +--| |
| | | +-----------+ | | | +-----------+
+--------+ | +--------+ |
| |
+--------+ | +--------+ |
| RU2 +-----+ | RU2 +-----+
| | | |
+--------+ +--------+
Figure 5: 3GPP RAN where RU are cabled directly to BB Figure 5: 3GPP RAN Where RUs Are Cabled Directly to BB
In Figure 5 BB is directly cabled to a set of RUs, the BB can In Figure 5, the BB is directly cabled to a set of RUs, and the BB
recognize the relationship between RUs and Cell/Sectors based on the can recognize the relationship between RUs and Cell/Sectors based on
cabling between the RUs and antennas. the cabling between the RUs and antennas.
When BBs and RUs are connected via a Layer-2 switched network, the When BBs and RUs are connected via a Layer 2 switched network, the
added level of complexity requires the BBs to have a deeper knowledge added level of complexity requires the BBs to have a deeper knowledge
of the topology in order to properly configure the RUs, involving of the topology in order to properly configure the RUs, involving
knowledge of all the cabling in the switched network. knowledge of all the cabling in the switched network.
Examples for switched networks are shown in section 3 of [RFC7969] Examples for switched networks are shown in Section 3 of [RFC7969]
and demonstrate the different levels of complexity. An example of a and demonstrate the different levels of complexity. An example of a
FH is depicted in Figure 6. FH is depicted in Figure 6.
+--------+ +--------+
| RU1 | P1 +-+------+ | | | RU1 | P1 +-+------+ | |
| +--------| | L2RA | | +----+------+ | | +--------| | L2RA | | +----+------+ |
+--------+ | +------+ | | | L3RA | | +--------+ | +------+ | | | L3RA | |
| L2 | +--| +------+ | | L2 | +--| +------+ |
+--------+ P2 | switch | | | | | +--------+ P2 | Switch | | | | |
| RU2 +--------| #1 +-----| | Router +----| | RU2 +--------| #1 +-----| | Router +----|
| | +--------+ | +-----------+ | +---------+ | | +--------+ | +-----------+ | +---------+
+--------+ | | | | +--------+ | | | |
| +--| DHCP | | +--| DHCP |
+--------+ | | | Server | +--------+ | | | Server |
| RU3 | P1 +-+------+ | | | #1 | | RU3 | P1 +-+------+ | | | #1 |
| +--------| | L2RA | | +-----------+ | +---------+ | +--------| | L2RA | | +-----------+ | +---------+
+--------+ | +------+ | | | | +--------+ | +------+ | | | |
| L2 | +--| Baseband | | | L2 | +--| Baseband | |
+--------+ P2 | switch | | | Unit | | +--------+ P2 | Switch | | | Unit | |
| RU4 +--------| #2 +-----| | +----| | RU4 +--------| #2 +-----| | +----|
| | +--------+ | +-----------+ | | | +--------+ | +-----------+ |
+--------+ | | +--------+ | |
Figure 6: 3GPP RAN with Layer-2 Switched Fronthaul Example Figure 6: 3GPP RAN with Layer 2 Switched Fronthaul Example
If IPv6 is used and all RU are capable of DHCPv6 in Figure 6, DHCP If IPv6 is used and all RUs are capable of DHCPv6 in Figure 6, DHCP
topology knowledge can be used for solving the RU configuration topology knowledge can be used for solving the RU configuration
problem. Such solution would use the topology discovery mechanisms problem. Such solution would use the topology discovery mechanisms
described in section 3.2 of [RFC7969]. described in Section 3.2 of [RFC7969].
If RU are capable of IPv4 only but implement a 4o6 client according If RUs are capable of IPv4 only but implement a 4o6 client according
to [RFC7341], the same topology discovery mechanisms are applicable. to [RFC7341], the same topology discovery mechanisms are applicable.
If RU are capable of IPV4 only and cannot implement a 4o6 client If RUs are capable of IPv4 only and cannot implement a 4o6 client
according to [RFC7341], the topology discovery mechanisms described according to [RFC7341], the topology discovery mechanisms described
in section 3.2 of [RFC7969] can be used by introducing 4o6RA in the in Section 3.2 of [RFC7969] can be used by introducing 4o6RA in the
switches as decribed in this document. switches as described in this document.
Acknowledgments Acknowledgments
The authors would also like to acknowledge interesting discussions in The authors would like to acknowledge interesting discussions in this
this problem space with Sarah Gannon, Ines Ramadza, and Siddharth problem space with Sarah Gannon, Ines Ramadza, and Siddharth Sharma,
Sharma as well as reviews and comments provided by Eric Vyncke, as well as reviews and comments provided by Éric Vyncke, Mohamed
Mohamed Boucadair, David Lamparter, Michael Richardson, Alan DeKok, Boucadair, David Lamparter, Michael Richardson, Alan DeKok, Dale
Dale Worley, Paul Wouters, Deb Cooley, Erik Kline, Ketan Talaulikar, Worley, Paul Wouters, Deb Cooley, Erik Kline, Ketan Talaulikar, Mike
Mike Bishop and Roman Danyliw. Bishop, and Roman Danyliw.
Authors' Addresses Authors' Addresses
Claudio Porfiri Claudio Porfiri
Ericsson Ericsson
Email: claudio.porfiri@ericsson.com Email: claudio.porfiri@ericsson.com
Suresh Krishnan Suresh Krishnan
Cisco Cisco
Email: suresh.krishnan@gmail.com Email: suresh.krishnan@gmail.com
 End of changes. 85 change blocks. 
200 lines changed or deleted 189 lines changed or added

This html diff was produced by rfcdiff 1.48.