---
title: "DHCPv4-over-DHCPv6 "DHCPv4 over DHCPv6 with Relay Agent Support"
abbrev: "DHCP 4o6 Relay Agent"
number: 0000 9928
category: std
docname: draft-ietf-dhc-dhcpv4-over-dhcpv6-ra
submissiontype: IETF
number: 0000
date: 2025-09 February 2026
consensus: true
ipr: trust200902
pi: [toc, symrefs, sortrefs]
v: 3
lang: en
area: "INT"
workgroup: "dhc"
keyword:
 - dhcp

author:
 -
    ins: C. Porfiri
    name: Claudio Porfiri
    organization: Ericsson
    email: claudio.porfiri@ericsson.com
 -
    ins: S. Krishnan
    name: Suresh Krishnan
    organization: Cisco
    email: suresh.krishnan@gmail.com
 -
    ins: J. Arkko
    name: Jari Arkko
    organization: Ericsson
    email: jari.arkko@ericsson.com
 -
    ins: M. Kühlewind
    name: Mirja Kühlewind
    organization: Ericsson
    email: mirja.kuehlewind@ericsson.com

normative:
   RFC6221:
   RFC7341:
   I-D.ietf-dhc-rfc8415bis:
   RFC9915:

informative:
   RFC0951:
   RFC1542:
   RFC2131:
   RFC2132:
   RFC7969:

--- abstract

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

--- middle

# Introduction {#introduction}

{{RFC7341}} describes a transport mechanism for carrying DHCPv4 {{RFC2131}}
messages using DHCPv6 {{I-D.ietf-dhc-rfc8415bis}} {{RFC9915}} for dynamic provisioning
of IPv4 addresses and other DHCPv4 specific DHCPv4-specific configuration parameters
across IPv6-only networks. The deployment of {{RFC7341}} 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.

<!-- [rfced] Please review the text below. We were unable to find "L3RA" used in
[draft-ietf-dhc-rfc8415bis] (now published as RFC 9915).

Original:

   Similarly, the specifications for DHCPv6 Relay Agents such as
   Lightweight DHCPv6 Relay Agent (LDRA) [RFC6221] or DHCPv6 Relay Agent
   (L3RA) [draft-ietf-dhc-rfc8415bis] do not foresee the possibility to
   handle legacy DHCPv4, other than implementing DHCP 4o6 in the client.

-->

Similarly, the specifications for DHCPv6 Relay Agents such as Lightweight
DHCPv6 Relay Agent (LDRA) {{RFC6221}} or DHCPv6 Relay Agent (L3RA)
{{I-D.ietf-dhc-rfc8415bis}}
{{RFC9915}} do not foresee the possibility to handle legacy DHCPv4,
other than implementing DHCP 4o6 in the client.

This document specifies an {{RFC7341}} based a solution based on {{RFC7341}} 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 {{RFC7341}} that allows
a Relay Agent to perform the DHCP 4o6 encapsulation and decapsulation instead of
the client.

## Applicability Scope {#applicability}

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 {{RFC2131}} is not
reachable directly from the host. Furthermore, the host is unable to implement
a DHCP client conformant to {{RFC7341}} {{RFC7341}}, as it is connected to an IPv4-only
network. But However, there is a DHCPv6 server that can provide IPv4 addresses by means of
the mechanisms specified in {{RFC7341}}.

<!-- [rfced] Section 2:

a) May we adjust the items in this list to appear in alphabetical order?

b) May we make these list items consistent as follows?

Original:

   *  DHCP: If not otherwise specified, DHCP refers to DHCPv4 and/or
      DHCPv6.

   *  DHCPv4: DHCP as defined in [RFC2131].

   *  DHCPv4 over DHCPv6 (or 4o6): The architecture, the procedures, and
      the protocols specified in the DHCPv4-over-DHCPv6 document
      [RFC7341].

   *  DHCP Relay Agent: This is a concept in all of the following
      protocols, although the details differ between them: BOOTP
      [RFC951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6
      [draft-ietf-dhc-rfc8415bis].

   *  Lightweight DHCPv6 Relay Agent (or LDRA): This is an extension of
      the original DHCPv6 Relay Agent specification, to allow layer-
      2-only devices to perform a Relay Agent function [RFC6221].

   *  DHCPv4 over DHCPv6 Relay Agent (or 4o6RA): Refers to a Relay Agent
      that implements the 4o6 transport as specified in this document.

Perhaps:

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

   DHCPv4:
     Refers to DHCP as defined in [RFC2131].

   DHCPv4 over DHCPv6 (DHCP 4o6):
      Refers to the architecture, the procedures, and the protocols specified in
      the DHCPv4-over-DHCPv6 document [RFC7341].

   (etc.)

-->

# Conventions and Definitions

The following terms and acronyms abbreviations are used in this document:

*

{:vspace}
DHCP:
: If not otherwise specified, DHCP refers to DHCPv4 and/or DHCPv6.

*

DHCPv4:
: DHCP as defined in {{RFC2131}}.

*

DHCPv4 over DHCPv6 (or (DHCP 4o6):
: The architecture, the procedures, and the protocols specified in the
DHCPv4-over-DHCPv6 document {{RFC7341}}.

*

DHCP Relay Agent:
: This is a concept in all of the following protocols, although the details differ
between them: BOOTP {{RFC951}} the Bootstrap Protocol (BOOTP) {{RFC0951}} {{RFC1542}}, DHCPv4
{{RFC2131}} {{RFC2132}}, and DHCPv6 {{I-D.ietf-dhc-rfc8415bis}}.

* {{RFC9915}}.

Lightweight DHCPv6 Relay Agent (or LDRA): (LDRA):
: This is an extension of the original DHCPv6 Relay Agent specification, to allow
   layer-2-only
Layer 2 (L2) only devices to perform a Relay Agent function {{RFC6221}}.

* DHCPv4 over DHCPv6

DHCPv4-over-DHCPv6 Relay Agent (or 4o6RA): (4o6RA):
:  Refers to a Relay Agent that implements the 4o6
transport as specified in this document.

{::boilerplate bcp14-tagged}

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

This document assumes a network, 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, DHCPv4 over DHCPv6, as shown in {{fig_4o6RA}}.

~~~aasvg

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

~~~
{: #fig_4o6RA title="Architecture Example with Legacy DHCP Client" artwork-align="center"}

This document specifies the encapsulation
and decapsulation specified in {{RFC7341}} to be performed in the Relay Agent
without requiring any changes on the DHCPv4 client.
In this case case, it is up to the Relay Agent to provide the full DHCP
4o6 support 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 configuration configurations
that apply to the DHCP client in {{Section 5 of RFC7341}} are also applied to the 4o6RA.

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 a
DHCPv6 client, and it is responsible for locating a suitable DHCPv6
server or relay agent Relay Agent and obtain obtaining the necessary IPv6 configuration.. configuration.
As specified in {{RFC7341}}, the 4o6RA, acting as 4o6 client, therefore has to request
the DHCP 4o6 Server Address option from the server by sending the
Option Request option as described in {{I-D.ietf-dhc-rfc8415bis}} {{RFC9915}}
before it can use the 4o6 transport.

To maintain interoperability with existing DHCPv6 relays and servers,
the message format is unchanged from {{I-D.ietf-dhc-rfc8415bis}}. {{RFC9915}}. The 4o6RA implements
the same message types as a DHCPv6 Relay Agent (see {{Section 6 of RFC7341}}. RFC7341}}).

However, in this specification, the 4o6RA, instead of the client, creates the DHCPV4-QUERY Message message
and encapsulates the DHCP request message received from the legacy DHCPv4 client.

When the DHCPV4-RESPONSE Message message is received by the 4o6 Relay Agent,
it looks for the DHCPv4 Message 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 message option is present and correct, the 4o6RA MUST extract the DHCPv4
message and forward the encapsulated DHCPv4-response DHCPv4-RESPONSE to the requesting DHCPv4
client, given that the encapsulated DHCPv4-response DHCPv4-RESPONSE is correct and can be
actually forwarded.

Layer-2

Layer 2 (L2) Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE messages
MUST handle them as specified in {{Section 6 of RFC6221}}.

In any given environment, DHCPv6 servers to which DHCPV4-QUERY
requests are routed are expected to be compliant with 4o6 according
to {{RFC7341}}.  No additional requirements on DHCPv6 servers are set
by this specification.

## Intermediate relays Relays

Intermediate relays shall behave according to section {{Section 10 of {{RFC7341}}. RFC7341}}.

## 4o6RA and Topology Discovery {#topology_considerations}

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 {{RFC2131}} and DHCPv6 {{I-D.ietf-dhc-rfc8415bis}} {{RFC9915}} specifications
describe how addresses can typically be allocated to clients based on network
topology information provided by a DHCP relay, typically. relay.

Address/prefix allocation decisions are integral to the allocation of
addresses and prefixes in DHCP, as described in detail
in {{RFC7969}}. This specification aims to guarantee that the 4o6RA does not
break any legacy capability when used for topology discovery.

Topology discovery as described in {{RFC7969}} differs between
IPv4 and IPv6: IPv6 as follows:

* IPv4:
when When using DHCP on IPv4 IPv4, only the first Relay Agent SHOULD
set the giaddr field (section ({{Section 3.1 of {{RFC7969}}). RFC7969}}). Thus, in a
network that has more than one Relay Agent Agent, only part of the topology
is transported via DHCPv4.

* IPv6:
when When using DHCPv6, all Relay Agents SHOULD send
link-address and Interface-ID options, options that provide
information about the complete path
between the DHCPv6 client and the DHCPv6 server to the DHCPv6 server.

In Layer-2 Layer 2 networks, Lightweight DHCPv6 Relay Agents (LDRAs) {{RFC6221}}
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.

{{RFC7341}} 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.
As
However, as shown in {{fig_4o6RA_RA}}, however, the introduction of 4o6 at
the edge of the IPv6 network hides the Layer-2 Layer 2 network from the DHCPv6 RA.
As such, moving 4o6 to a an intermediate node rather than performing it at the client breaks
the topology propagation, as 4o6RA-only solutions does do not provide any interface
information in the encapsulated message.

~~~aasvg

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

~~~
{: #fig_4o6RA_RA title="Broken topology information" Topology Information" artwork-align="center"}

In order to provide full topology information, it is RECOMMENDED that
any implementation of 4o6RA be combined
with an LDRA implementation {{RFC6221}} in a back-to-back structure, 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 Section {{Section 5.3.2 of {{RFC6221}}. RFC6221}}.

The internal mechanisms to exchange interface information,
their format format, and whether the interface information contains an indication that a 4o6RA
is involved involved, are out of the scope for this document.

The resulting architecture is shown in {{fig_4o6LDRA}} where
the Relay Agent is implementing 4o6RA and LDRA, LDRA and has an internal interface to
propagate topology information from 4o6RA to LDRA.

~~~aasvg

           .-----------------.     .------------------------.
          |  L2 Network or    |   |       IPv6 Network       |
          |  IPv6-only link  IPv6-Only Link   |   |                          |
 +--------+-+  +---------+  +-+---+--+---------+      +------+---+
 |  DHCPv4  |  |   L2    |  |  4o6   |  LDRA   |      | DHCP 4o6 |
 |  Client  +--+ Switch  +--+  Relay + RFC6221 +------+ RFC 6221+------+  Server  |
 |          |  |         |  |  Agent |         |      |          |
 +--------+-+  +---------+  +-+---+--+---------+      +------+---+
          |                   |   |                          |
           '-----------------'     '------------------------'

~~~
{: #fig_4o6LDRA title="Topology information preserved Information Preserved with LDRA" artwork-align="center"}

In a simple case, where the same node hosts the 4o6RA and the DHCP4o6 DHCP 4o6 server,
it might be enough to only use 4o6RA, as shown in {{fig_4o6RAserver}}.

<!-- [rfced] Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviations
should be expanded upon first use. How and where should "CPE" be expanded as
it appears in Figure 4?

Original:

   In a simple case, where the same node hosts the 4o6RA and the DHCP4o6
   server, it might be enough to only use 4o6RA, as shown in Figure 4.

Perhaps:

   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 Figure 4, where
   CPE stands for "Customer Premises Equipment".

-->

~~~aasvg

           .-----------.
          | L2 Network  |
 +--------+-+         +-+------+----------+
 |   DHCP   |         |  4o6   | DHCP 4o6 |
 |  Client  +---------+  Relay +  Server  |
 |  on CPE  |         |  Agent |          |
 +--------+-+         +-+------+----------+
          |             |
           '-----------'

~~~
{: #fig_4o6RAserver title="Topology information preserved Information Preserved by 4o6 Relay Agent in DHCP server" Server" artwork-align="center"}

# 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.

<!-- [rfced] Security Considerations:

a) Would the following adjustment clarify what "the 4o6 DHCP specification"
refers to?

b) Please note that we have changed "4o6 DHCP" to "DHCP 4o6" in this
section for consistency with the rest of the document.

Original:

   This document does not change anything else in the 4o6 DHCP specification
   and therefore the security considerations of [RFC7341] still apply.

Perhaps:

   This document does not change anything else in the DHCP 4o6 specification [RFC7341];
   therefore, the security considerations of that document still apply.

-->

# Security Considerations {#seccons}

This document specifies the applicability of 4o6 DHCP 4o6 in a scenario where legacy IPv4 clients are
connected to 4o6 DHCP Relay Agents that perform the encapsulation and decapsulation. This document
does not change anything else in the 4o6 DHCP specification and therefore 4o6 specification; therefore, the
security considerations of {{RFC7341}} still apply.
Specifically, since the legacy IPv4 client is not aware of the encapsulation and decapsulation,
it is
4o6RA has to provide the protections that are specficed specified in the security
considerations in {{Section 12 of RFC7341}}.

The mechanisms defined here differ from {{RFC7341}} as they allow the DHCP client
to send and receive DHCPv4 messages, whereas in {{RFC7341}} {{RFC7341}}, 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 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, mechanism; however, even
when DHCP 4o6 is used, the client does not have any control about the
information provided by the Relay agent. Agent.
As such such, this change does not raise any additional security concerns.

# IANA Considerations

This document has no IANA actions.

--- back

<!-- [rfced] Appendix A: Please review our questions and suggested updates to
the text below, including the following items:

a) Should the abbreviation for "Baseband Units (BB)" be updated to "Baseband Units (BBUs)"
as seen in the text below? If so, please note that we would also update instances of
"BB"/"BBs" to "BBU"/"BBUs" accordingly throughout the rest of this section as well.

b) Should the abbreviation for "Radio Fronthaul Network (FH)" be adjusted for
clarity?

Original:

   In 3GPP mobile network architecture, the User Equipments (UE) are
   connected via Radio Access Network (RAN).  RAN is built up with
   Baseband Units (BB) and Radio Units (RU).  Radio Fronthaul Network
   (FH) connects RU and BB, each of RU and BB is an IP host, they may
   support IPv4 only, IPv6 only or both depending on the vendor and the
   model.

Perhaps:

   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.

-->

# Example Use Case: Topology Discovery for IPv4-only IPv4-Only Radio Unit in 3GPP RAN with Switched Fronthaul {#usecase}

In 3GPP mobile network architecture, the User Equipments Equipment (UE) are is connected
via Radio Access Network (RAN). RAN is built up with Baseband Units (BB) (BBs)
and Radio Units (RU). (RUs). Radio Fronthaul Network (FH) connects RU RUs and BB, each of BBs. Each
RU and BB is an IP host, and they may support IPv4 only, IPv6 only only, or both 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 BB depending on the Cell and Sectors it serves.
However, that dependency is only specified by the cabling between RU RUs and antennas.
BB
BBs can be cabled to RU RUs directly or via a Layer-2 Layer 2 switched network.

~~~aasvg
     +--------+
     |  RU2   +-----+
     |        |     |
     +--------+     |
                    |
     +--------+     |
     |  RU3   |     |
     |        +--+  |  +-----------+
     +--------+  |  +--|           |
                 +-----| Baseband  |
                       |           |
     +--------+  +-----|   Unit    |
     |  RU4   +--+  +--|           |
     |        |     |  +-----------+
     +--------+     |
                    |
     +--------+     |
     |  RU2   +-----+
     |        |
     +--------+
~~~
{: #bb_connected_to_ru title="3GPP RAN where RU are cabled directly Where RUs Are Cabled Directly to BB" artwork-align="center"}

In {{bb_connected_to_ru}} {{bb_connected_to_ru}}, the BB is directly cabled to a set of RUs, and the
BB can recognize the relationship between RUs and Cell/Sectors
based on the cabling between the RUs and antennas.

When BBs and RUs are connected via a Layer-2 Layer 2 switched network,
the added level of complexity requires the BBs 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 section {{Section 3 of {{RFC7969}} RFC7969}}
and demonstrate the different levels of complexity.
An example of a FH is depicted in {{l2_switched_fh}}.

~~~aasvg
     +--------+
     |  RU1   |     P1 +-+------+     |                   |
     |        +--------| | L2RA |     |  +----+------+    |
     +--------+        | +------+     |  |    | L3RA |    |
                       |  L2    |     +--|    +------+    |
     +--------+     P2 | switch Switch |     |  |           |    |
     |  RU2   +--------|  #1    +-----|  |   Router  +----|
     |        |        +--------+     |  +-----------+    |  +---------+
     +--------+                       |                   |  |         |
                                      |                   +--| DHCP    |
     +--------+                       |                   |  | Server  |
     |  RU3   |     P1 +-+------+     |                   |  |   #1    |
     |        +--------| | L2RA |     |  +-----------+    |  +---------+
     +--------+        | +------+     |  |           |    |
                       |  L2    |     +--| Baseband  |    |
     +--------+     P2 | switch Switch |     |  |   Unit    |    |
     |  RU4   +--------|  #2    +-----|  |           +----|
     |        |        +--------+     |  +-----------+    |
     +--------+                       |                   |
~~~
{: #l2_switched_fh title="3GPP RAN with Layer-2 Layer 2 Switched Fronthaul Example" artwork-align="center"}

If IPv6 is used and all RU RUs are capable of DHCPv6 in {{l2_switched_fh}},
DHCP topology knowledge can be used for solving the RU configuration problem.
Such solution would use the topology discovery mechanisms described in section {{Section 3.2
of {{RFC7969}}. RFC7969}}.

If RU RUs are capable of IPv4 only but implement a 4o6 client according to {{RFC7341}}, the same topology discovery mechanisms are applicable.

If RU RUs are capable of IPV4 IPv4 only and cannot implement a 4o6 client according to {{RFC7341}},
the topology discovery mechanisms described in section {{Section 3.2
of {{RFC7969}} RFC7969}} can be used by introducing 4o6RA in the switches as decribed described in this document.

# Acknowledgments
{:numbered="false"}

The authors would also like to acknowledge interesting discussions in
this problem space with Sarah Gannon, Ines Ramadza, {{{Sarah Gannon}}}, {{{Ines Ramadza}}}, and Siddharth Sharma {{{Siddharth Sharma}}},
as well as reviews and comments provided by Eric Vyncke, Mohamed Boucadair,
David Lamparter, Michael Richardson, Alan DeKok, Dale Worley, Paul Wouters,
Deb Cooley, Erik Kline, Ketan Talaulikar, Mike Bishop {{{Éric Vyncke}}}, {{{Mohamed Boucadair}}},
{{{David Lamparter}}}, {{{Michael Richardson}}}, {{{Alan DeKok}}}, {{{Dale Worley}}}, {{{Paul Wouters}}},
{{{Deb Cooley}}}, {{{Erik Kline}}}, {{{Ketan Talaulikar}}}, {{{Mike Bishop}}}, and {{{Roman Danyliw}}}.

<!-- [rfced] Terminology and Abbreviations:

a) We note that the phrase "4o6" appears a few times by itself throughout this
document. For consistency and Roman Danyliw. context, should these instances be updated to "DHCP 4o6"?

We have provided a few examples below:

the 4o6 transport
are expected to be compliant with 4o6
the introduction of 4o6 at the edge
moving 4o6 to a intermediate node
a 4o6 client

b) We note the following phrases appear after their abbreviations are
introduced. For consistency, should these terms (on the left) be updated to
their abbreviated form (on the right) after first use?

Expansion -> Abbreviation

DHCPv4-over-DHCPv6  ->  DHCP 4o6
4o6 Relay Agent     ->  4o6RA
Layer 2             ->  L2

c) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

Bootstrap Protocol (BOOTP)
Layer 2 (L2)

-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice. -->