rfc9928v1.txt   rfc9928.txt 
skipping to change at line 19 skipping to change at line 19
February 2026 February 2026
DHCPv4 over DHCPv6 with Relay Agent Support DHCPv4 over DHCPv6 with Relay Agent Support
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. RFC 7341 specifies the 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 an approach based on RFC 7341 client only. This document specifies an approach based on RFC 7341
that allows a Relay Agent to implement the DHCP 4o6 encapsulation and that allows a Relay Agent to implement the DHCPv4-over-DHCPv6
decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a encapsulation and decapsulation of DHCPv4 messages in DHCPv6 messages
DHCPv4 client. on behalf of a DHCPv4 client.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 82 skipping to change at line 82
[RFC7341] describes a transport mechanism for carrying DHCPv4 [RFC7341] describes a transport mechanism for carrying DHCPv4
[RFC2131] messages using DHCPv6 [RFC9915] for dynamic provisioning of [RFC2131] messages using DHCPv6 [RFC9915] for dynamic provisioning of
IPv4 addresses and other DHCPv4-specific configuration parameters IPv4 addresses and other DHCPv4-specific configuration parameters
across IPv6-only networks. The deployment of [RFC7341] requires across IPv6-only networks. The deployment of [RFC7341] requires
support in DHCP clients and at the DHCPv6 server. However, if a support in DHCP clients and at the DHCPv6 server. However, if a
client is embedded in a host that only supports IPv4 and cannot 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 easily be replaced or updated (which could be due to any number of
technical or business reasons), this approach does not work. technical or business reasons), this approach does not work.
Similarly, the specifications for DHCPv6 Relay Agents such as Similarly, the DHCPv6 Relay Agent specification defined in [RFC9915],
Lightweight DHCPv6 Relay Agent (LDRA) [RFC6221] or DHCPv6 Relay Agent which also refers to [RFC6221] for the Lightweight DHCPv6 Relay Agent
(L3RA) [RFC9915] do not foresee the possibility to handle legacy (LDRA) behavior, does not provide any mechanism to handle legacy
DHCPv4, other than implementing DHCP 4o6 in the client. DHCPv4, except by requiring the client to implement the DHCPv4-over-
DHCPv6 encapsulation and decapsulation.
This document specifies a solution based on [RFC7341] 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 DHCPv4-
encapsulation and decapsulation instead of the client. over-DHCPv6 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. However, to [RFC7341], as it is connected to an IPv4-only network. However,
there is a DHCPv6 server that can provide IPv4 addresses by means of there is a DHCPv6 server that can provide IPv4 addresses by means of
the mechanisms specified in [RFC7341]. the mechanisms specified in [RFC7341].
2. Conventions and Definitions 2. Conventions and Definitions
The following terms and abbreviations are used in this document: The following terms and abbreviations are used in this document:
DHCP: DHCP:
If not otherwise specified, DHCP refers to DHCPv4 and/or DHCPv6. 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) [RFC0951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and
DHCPv6 [RFC9915].
DHCPv4: DHCPv4:
DHCP as defined in [RFC2131]. Refers to DHCP as defined in [RFC2131].
DHCPv4 over DHCPv6 (DHCP 4o6): DHCPv4 over DHCPv6 (DHCP 4o6):
The architecture, the procedures, and the protocols specified in Refers to the architecture, the procedures, and the protocols
the DHCPv4-over-DHCPv6 document [RFC7341]. specified in the DHCPv4-over-DHCPv6 document [RFC7341].
DHCP Relay Agent: DHCPv4-over-DHCPv6 Relay Agent (4o6RA):
This is a concept in all of the following protocols, although the Refers to a Relay Agent that implements the DHCP 4o6 transport as
details differ between them: the Bootstrap Protocol (BOOTP) specified in this document.
[RFC0951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6
[RFC9915]. Layer 3 Relay Agent (L3RA):
Refers to a DHCP Relay Agent as specified in [RFC9915] that is not
a LDRA.
Lightweight DHCPv6 Relay Agent (LDRA): Lightweight DHCPv6 Relay Agent (LDRA):
This is an extension of the original DHCPv6 Relay Agent Refers to an extension of the original DHCPv6 Relay Agent
specification, to allow Layer 2 (L2) only devices to perform a specification, to allow Layer 2 (L2) only devices to perform a
Relay Agent function [RFC6221]. Relay Agent function [RFC6221].
DHCPv4-over-DHCPv6 Relay Agent (4o6RA):
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.
skipping to change at line 172 skipping to change at line 177
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
configurations that apply to the DHCP client in Section 5 of configurations that apply to the DHCP client in Section 5 of
[RFC7341] 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 obtaining 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 DHCP 4o6 client,
has to request the DHCP 4o6 Server Address option from the server by therefore has to request the DHCP 4o6 Server Address option from the
sending the Option Request option as described in [RFC9915] before it server by sending the Option Request option as described in [RFC9915]
can use the 4o6 transport. before it can use the DHCP 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 [RFC9915]. The 4o6RA implements the message format is unchanged from [RFC9915]. The 4o6RA implements
the same message types as a DHCPv6 Relay Agent (see Section 6 of 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, 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 the DHCPV4-RESPONSE message is received by the 4o6 Relay Agent, When the DHCPV4-RESPONSE message is received by the DHCP 4o6 Relay
it looks for the DHCPv4 message option within this message. If this Agent, it looks for the DHCPv4 message option within this message.
option is not found or the DHCPv4-RESPONSE message is not well- If this option is not found or the DHCPv4-RESPONSE message is not
formed, it MUST be discarded. If the DHCPv4 message option is well-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 (L2) 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 DHCP 4o6
to [RFC7341]. No additional requirements on DHCPv6 servers are set according to [RFC7341]. No additional requirements on DHCPv6 servers
by this specification. are set 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
skipping to change at line 250 skipping to change at line 255
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. However, interface where the encapsulated DHCP request is received. However,
as shown in Figure 2, the introduction of 4o6 at the edge of the IPv6 as shown in Figure 2, the introduction of DHCP 4o6 at the edge of the
network hides the Layer 2 network from the DHCPv6 RA. As such, IPv6 network hides the Layer 2 network from the DHCPv6 RA. As such,
moving 4o6 to an intermediate node rather than performing it at the moving DHCP 4o6 to an intermediate node rather than performing it at
client breaks the topology propagation, as 4o6RA-only solutions do the client breaks the topology propagation, as 4o6RA-only solutions
not provide any interface information in the encapsulated message. do 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 | | |
+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+ +--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+
| | | | | | | |
'-----------------' '-------------------------' '-----------------' '-------------------------'
skipping to change at line 298 skipping to change at line 303
| Client +--+ Switch +--+ Relay + RFC 6221+------+ 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 DHCP 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 4o6 server, it might be enough to only use 4o6RA, as shown in
Figure 4. Figure 4, where CPE stands for "Customer Premises Equipment".
.-----------. .-----------.
| L2 Network | | L2 Network |
+--------+-+ +-+------+----------+ +--------+-+ +-+------+----------+
| DHCP | | 4o6 | DHCP 4o6 | | DHCP | | 4o6 | DHCP 4o6 |
| Client +---------+ Relay + Server | | Client +---------+ Relay + Server |
| on CPE | | Agent | | | on CPE | | Agent | |
+--------+-+ +-+------+----------+ +--------+-+ +-+------+----------+
| | | |
'-----------' '-----------'
skipping to change at line 325 skipping to change at line 330
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 DHCP 4o6 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 DHCP 4o6 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 DHCP 4o6 specification; therefore, the change anything else in the DHCP 4o6 specification [RFC7341];
security considerations of [RFC7341] still apply. Specifically, therefore, the security considerations of that document still apply.
since the legacy IPv4 client is not aware of the encapsulation and Specifically, since the legacy IPv4 client is not aware of the
decapsulation, 4o6RA has to provide the protections that are encapsulation and decapsulation, 4o6RA has to provide the protections
specified in the security considerations in Section 12 of [RFC7341]. that are 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 DHCP client to send and receive DHCPv4 messages, whereas in
[RFC7341], the client only sends DHCPv6 messages. This makes it [RFC7341], the client only sends DHCPv6 messages. This makes it
possible that in improperly configured networks where the client is possible that in improperly configured networks where the client is
located on the same Layer 2 scope of a DHCPv4 server, DHCPv4 messages 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 could reach a DHCPv4 server without using the 4o6RA. While this can
cause erroneous state in both clients and servers and potentially cause erroneous state in both clients and servers and potentially
even lead to misconfigurations that impact reachability, this is seen even lead to misconfigurations that impact reachability, this is seen
as a deployment error rather than a security concern. Further, even as a deployment error rather than a security concern. Further, even
skipping to change at line 409 skipping to change at line 415
[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/info/rfc7969>. <https://www.rfc-editor.org/info/rfc7969>.
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 Equipment (UE) is In 3GPP mobile network architecture, the User Equipment (UE) is
connected via Radio Access Network (RAN). RAN is built up with connected via a Radio Access Network (RAN). RAN is built up with
Baseband Units (BBs) and Radio Units (RUs). Radio Fronthaul Network Baseband Units (BBUs) and Radio Units (RUs). A radio Fronthaul (FH)
(FH) connects RUs and BBs. Each RU and BB is an IP host, and they network connects RUs and BBUs. Each RU and BBU is an IP host, and
may support IPv4 only, IPv6 only, or both, depending on the vendor they may support IPv4 only, IPv6 only, or both, depending on the
and the model. Each RU is unique as it is tied to a set of antennas, vendor and the model. Each RU is unique as it is tied to a set of
and each antenna is serving a specific Cell and Sector. Each RU is antennas, and each antenna is serving a specific Cell and Sector.
configured by the BB depending on the Cell and Sectors it serves. Each RU is configured by the BBU depending on the Cell and Sectors it
However, that dependency is only specified by the cabling between RUs serves. However, that dependency is only specified by the cabling
and antennas. BBs can be cabled to RUs directly or via a Layer 2 between RUs and antennas. BBUs can be cabled to RUs directly or via
switched network. a Layer 2 switched network.
+--------+ +--------+
| RU2 +-----+ | RU2 +-----+
| | | | | |
+--------+ | +--------+ |
| |
+--------+ | +--------+ |
| RU3 | | | RU3 | |
| +--+ | +-----------+ | +--+ | +-----------+
+--------+ | +--| | +--------+ | +--| |
skipping to change at line 441 skipping to change at line 447
+--------+ +-----| Unit | +--------+ +-----| Unit |
| RU4 +--+ +--| | | RU4 +--+ +--| |
| | | +-----------+ | | | +-----------+
+--------+ | +--------+ |
| |
+--------+ | +--------+ |
| RU2 +-----+ | RU2 +-----+
| | | |
+--------+ +--------+
Figure 5: 3GPP RAN Where RUs Are Cabled Directly to BB Figure 5: 3GPP RAN Where RUs Are Cabled Directly to BBUs
In Figure 5, the BB is directly cabled to a set of RUs, and the BB In Figure 5, the BBU is directly cabled to a set of RUs, and the BBU
can recognize the relationship between RUs and Cell/Sectors based on can recognize the relationship between RUs and Cell/Sectors based on
the 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 BBUs 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 BBUs to have a deeper
of the topology in order to properly configure the RUs, involving knowledge of the topology in order to properly configure the RUs,
knowledge of all the cabling in the switched network. involving 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 | +--| +------+ |
skipping to change at line 483 skipping to change at line 489
| | +--------+ | +-----------+ | | | +--------+ | +-----------+ |
+--------+ | | +--------+ | |
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 RUs 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 RUs are capable of IPv4 only but implement a 4o6 client according If RUs are capable of IPv4 only but implement a DHCP 4o6 client
to [RFC7341], the same topology discovery mechanisms are applicable. according to [RFC7341], the same topology discovery mechanisms are
applicable.
If RUs are capable of IPv4 only and cannot implement a 4o6 client If RUs are capable of IPv4 only and cannot implement a DHCP 4o6
according to [RFC7341], the topology discovery mechanisms described client according to [RFC7341], the topology discovery mechanisms
in Section 3.2 of [RFC7969] can be used by introducing 4o6RA in the described in Section 3.2 of [RFC7969] can be used by introducing
switches as described in this document. 4o6RA in the switches as described in this document.
Acknowledgments Acknowledgments
The authors would like to acknowledge interesting discussions in this The authors would like to acknowledge interesting discussions in this
problem space with Sarah Gannon, Ines Ramadza, and Siddharth Sharma, problem space with Sarah Gannon, Ines Ramadza, and Siddharth Sharma,
as well as reviews and comments provided by Éric Vyncke, Mohamed as well as reviews and comments provided by Éric Vyncke, Mohamed
Boucadair, David Lamparter, Michael Richardson, Alan DeKok, Dale Boucadair, David Lamparter, Michael Richardson, Alan DeKok, Dale
Worley, Paul Wouters, Deb Cooley, Erik Kline, Ketan Talaulikar, Mike Worley, Paul Wouters, Deb Cooley, Erik Kline, Ketan Talaulikar, Mike
Bishop, and Roman Danyliw. Bishop, and Roman Danyliw.
 End of changes. 22 change blocks. 
68 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.48.