<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?><!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06" category="std" consensus="true" submissionType="IETF" xml:lang="en" number="9928" tocInclude="true" sortRefs="true" symRefs="true" version="3"><!-- xml2rfc v2v3 conversion 3.30.0 --><link href="https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06" rel="prev"/> <front> <title abbrev="DHCP 4o6 RelayAgent">DHCPv4-over-DHCPv6Agent">DHCPv4 over DHCPv6 with Relay Agent Support</title> <seriesInfoname="Internet-Draft" value="draft-ietf-dhc-dhcpv4-over-dhcpv6-ra-06"/>name="RFC" value="9928"/> <author initials="C." surname="Porfiri" fullname="Claudio Porfiri"> <organization>Ericsson</organization> <address> <email>claudio.porfiri@ericsson.com</email> </address> </author> <author initials="S." surname="Krishnan" fullname="Suresh Krishnan"> <organization>Cisco</organization> <address> <email>suresh.krishnan@gmail.com</email> </address> </author> <author initials="J." surname="Arkko" fullname="Jari Arkko"> <organization>Ericsson</organization> <address> <email>jari.arkko@ericsson.com</email> </address> </author> <author initials="M." surname="Kühlewind" fullname="Mirja Kühlewind"> <organization>Ericsson</organization> <address> <email>mirja.kuehlewind@ericsson.com</email> </address> </author> <dateyear="2025" month="August" day="26"/> <area>Internet</area> <workgroup>Dynamic Host Configuration</workgroup>year="2026" month="March"/> <area>INT</area> <workgroup>dhc</workgroup> <keyword>dhcp</keyword> <abstract> <?line59?>54?> <t>This document describes a mechanism for networks with legacy IPv4-only clients to use services provided byDHCPv4-over-DHCPv6DHCPv4 over DHCPv6 in a Relay Agent.RFC7341RFC 7341 specifies the use ofDHCPv4-over-DHCPv6DHCPv4 over DHCPv6 in the client only. This document specifiesa RFC7341-basedan approach based on RFC 7341 that allows a Relay Agent to implement theDHCP 4o6DHCPv4-over-DHCPv6 encapsulation and decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a DHCPv4 client.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6-ra/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/mirjak/draft-dhc-dhcpv4-over-dhcpv6-ra"/>.</t> </note></front> <middle> <?line71?>66?> <section anchor="introduction"> <name>Introduction</name> <t><xref target="RFC7341"/> describes a transport mechanism for carrying DHCPv4 <xref target="RFC2131"/> messages using DHCPv6 <xreftarget="draft-ietf-dhc-rfc8415bis"/>target="RFC9915"/> for dynamic provisioning of IPv4 addresses and otherDHCPv4 specificDHCPv4-specific configuration parameters across IPv6-only networks. The deployment of <xref target="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.</t> <t>Similarly, thespecifications for DHCPv6 Relay Agents such as LightweightDHCPv6 Relay Agent(LDRA)specification defined in <xref target="RFC9915"/>, which also refers to <xref target="RFC6221"/>orfor the Lightweight DHCPv6 Relay Agent(L3RA) <xref target="draft-ietf-dhc-rfc8415bis"/> do(LDRA) behavior, does notforesee the possibilityprovide any mechanism to handle legacy DHCPv4,other than implementing DHCP 4o6 inexcept by requiring theclient.</t>client to implement the DHCPv4-over-DHCPv6 encapsulation and decapsulation.</t> <t>This document specifiesana solution based on <xref target="RFC7341"/>based solutionthat 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 <xref target="RFC7341"/> that allows a Relay Agent to perform theDHCP 4o6DHCPv4-over-DHCPv6 encapsulation and decapsulation instead of the client.</t> <section anchor="applicability"> <name>Applicability Scope</name> <t>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 <xref target="RFC2131"/> is not reachable directly from the host. Furthermore, the host is unable to implement a DHCP client conformant to <xreftarget="RFC7341"/>target="RFC7341"/>, as it is connected to an IPv4-only network.ButHowever, there is a DHCPv6 server that can provide IPv4 addresses by means of the mechanisms specified in <xref target="RFC7341"/>.</t> </section> </section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name> <t>The following terms andacronymsabbreviations are used in this document:</t><ul spacing="normal"> <li> <t>DHCP: If not otherwise specified, DHCP refers<dl newline="true"> <dt>DHCP:</dt> <dd> <t>Refers to DHCPv4 and/orDHCPv6.</t> </li> <li> <t>DHCPv4: DHCP as defined in <xref target="RFC2131"/>.</t> </li> <li> <t>DHCPv4 overDHCPv6(or 4o6): The architecture, the procedures, and the protocols specified in the DHCPv4-over-DHCPv6 document <xref target="RFC7341"/>.</t> </li> <li> <t>DHCPif not otherwise specified.</t> </dd> <dt>DHCP RelayAgent: This isAgent:</dt> <dd> <t>Refers to a common concept in all of the following protocols, although the details differ between them:BOOTPthe Bootstrap Protocol (BOOTP) <xreftarget="RFC951"/>target="RFC0951"/> <xref target="RFC1542"/>, DHCPv4 <xref target="RFC2131"/> <xref target="RFC2132"/>, and DHCPv6 <xreftarget="draft-ietf-dhc-rfc8415bis"/>.</t> </li> <li> <t>Lightweighttarget="RFC9915"/>.</t> </dd> <dt>DHCPv4:</dt> <dd> <t>Refers to DHCP as defined in <xref target="RFC2131"/>.</t> </dd> <dt>DHCPv4 over DHCPv6 (DHCP 4o6):</dt> <dd> <t>Refers to the architecture, the procedures, and the protocols specified in the DHCPv4-over-DHCPv6 document <xref target="RFC7341"/>.</t> </dd> <dt>DHCPv4-over-DHCPv6 Relay Agent(or LDRA): This(4o6RA):</dt> <dd> <t>Refers to a Relay Agent that implements the DHCP 4o6 transport as specified in this document.</t> </dd> <dt>Layer 3 Relay Agent (L3RA):</dt> <dd> <t>Refers to a DHCP Relay Agent as specified in <xref target="RFC9915"/> that is not a LDRA.</t> </dd> <dt>Lightweight DHCPv6 Relay Agent (LDRA):</dt> <dd> <t>Refers to an extension of the original DHCPv6 Relay Agent specification, to allowlayer-2-onlyLayer 2 (L2) only devices to perform a Relay Agent function <xref target="RFC6221"/>.</t></li> <li> <t>DHCPv4 over DHCPv6 Relay Agent (or 4o6RA): Refers to a Relay Agent that implements the 4o6 transport as specified in this document.</t> </li> </ul> <t>The</dd> </dl> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <?line -18?> </section> <section anchor="dhcpv4-over-dhcpv6-relay-agent-4o6ra"><name>DHCPv4 over DHCPv6<name>DHCPv4-over-DHCPv6 Relay Agent (4o6RA)</name> <t>This document assumes anetwork,network where IPv4-only hosts are connected to a network that supports IPv6 and limited IPv4 services.</t> <t>To address such a network setup, this document extends DHCPv6 Relay Agents withDHCPv4-over-DHCPv6,DHCPv4 over DHCPv6, as shown in <xref target="fig_4o6RA"/>.</t> <figure anchor="fig_4o6RA"> <name>Architecture Example with Legacy DHCP Client</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="208" width="480" viewBox="0 0 480 208" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,64 L 8,128" fill="none" stroke="black"/> <path d="M 80,48 L 80,64" fill="none" stroke="black"/> <path d="M 80,128 L 80,144" fill="none" stroke="black"/> <path d="M 96,64 L 96,128" fill="none" stroke="black"/> <path d="M 176,64 L 176,128" fill="none" stroke="black"/> <path d="M 192,48 L 192,64" fill="none" stroke="black"/> <path d="M 192,128 L 192,144" fill="none" stroke="black"/> <path d="M 288,48 L 288,64" fill="none" stroke="black"/> <path d="M 288,128 L 288,144" fill="none" stroke="black"/> <path d="M 304,64 L 304,128" fill="none" stroke="black"/> <path d="M 384,64 L 384,128" fill="none" stroke="black"/> <path d="M 400,48 L 400,64" fill="none" stroke="black"/> <path d="M 400,128 L 400,144" fill="none" stroke="black"/> <path d="M 472,64 L 472,128" fill="none" stroke="black"/> <path d="M 96,32 L 176,32" fill="none" stroke="black"/> <path d="M 304,32 L 384,32" fill="none" stroke="black"/> <path d="M 8,64 L 96,64" fill="none" stroke="black"/> <path d="M 176,64 L 304,64" fill="none" stroke="black"/> <path d="M 384,64 L 472,64" fill="none" stroke="black"/> <path d="M 96,96 L 176,96" fill="none" stroke="black"/> <path d="M 304,96 L 384,96" fill="none" stroke="black"/> <path d="M 8,128 L 96,128" fill="none" stroke="black"/> <path d="M 176,128 L 304,128" fill="none" stroke="black"/> <path d="M 384,128 L 472,128" fill="none" stroke="black"/> <path d="M 96,160 L 176,160" fill="none" stroke="black"/> <path d="M 304,160 L 384,160" fill="none" stroke="black"/> <path d="M 96,32 C 87.16936,32 80,39.16936 80,48" fill="none" stroke="black"/> <path d="M 176,32 C 184.83064,32 192,39.16936 192,48" fill="none" stroke="black"/> <path d="M 304,32 C 295.16936,32 288,39.16936 288,48" fill="none" stroke="black"/> <path d="M 384,32 C 392.83064,32 400,39.16936 400,48" fill="none" stroke="black"/> <path d="M 96,160 C 87.16936,160 80,152.83064 80,144" fill="none" stroke="black"/> <path d="M 176,160 C 184.83064,160 192,152.83064 192,144" fill="none" stroke="black"/> <path d="M 304,160 C 295.16936,160 288,152.83064 288,144" fill="none" stroke="black"/> <path d="M 384,160 C 392.83064,160 400,152.83064 400,144" fill="none" stroke="black"/> <g class="text"> <text x="140" y="68">L2</text> <text x="340" y="68">IPv6</text> <text x="52" y="84">DHCPv4</text> <text x="136" y="84">Network</text> <text x="236" y="84">DHCPv6</text> <text x="344" y="84">Network</text> <text x="412" y="84">DHCP</text> <text x="448" y="84">4o6</text> <text x="52" y="100">Client</text> <text x="216" y="100">Relay</text> <text x="264" y="100">Agent</text> <text x="428" y="100">Server</text> <text x="220" y="116">with</text> <text x="264" y="116">4o6RA</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .-----------. .-----------. | | | | +--------+-+ L2 +-+-----------+-+ IPv6 +-+--------+ | DHCPv4 | Network | DHCPv6 | Network | DHCP 4o6 | | Client +---------+ Relay Agent +---------+ Server | | | | with 4o6RA | | | +--------+-+ +-+-----------+-+ +-+--------+ | | | | '-----------' '-----------' ]]></artwork> </artset> </figure> <t>This document specifies the encapsulation and decapsulation specified in <xref target="RFC7341"/> to be performed in the Relay Agent without requiring any changes on the DHCPv4 client. In thiscasecase, it is up to the Relay Agent to provide the full DHCP 4o6supportsupport, 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 andconfigurationconfigurations that apply to the DHCP client in <xref section="5" sectionFormat="of" target="RFC7341"/> are also applied to the 4o6RA.</t> <t>As the 4o6RA takes the role of the client in respect to <xref target="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 orrelay agentRelay Agent andobtainobtaining the necessary IPv6configuration..configuration. As specified in <xref target="RFC7341"/>, the 4o6RA, acting as DHCP 4o6 client, therefore has to request the DHCP 4o6 Server Address option from the server by sending the Option Request option as described in <xreftarget="draft-ietf-dhc-rfc8415bis"/>target="RFC9915"/> before it can use the DHCP 4o6 transport.</t> <t>To maintain interoperability with existing DHCPv6 relays and servers, the message format is unchanged from <xreftarget="draft-ietf-dhc-rfc8415bis"/>.target="RFC9915"/>. The 4o6RA implements the same message types as a DHCPv6 Relay Agent (see <xref section="6" sectionFormat="of"target="RFC7341"/>.</t>target="RFC7341"/>).</t> <t>However, in this specification, the 4o6RA, instead of the client, creates the DHCPV4-QUERYMessagemessage and encapsulates the DHCP request message received from the legacy DHCPv4 client.</t> <t>When the DHCPV4-RESPONSEMessagemessage is received by the DHCP 4o6 Relay Agent, it looks for the DHCPv4Messagemessage option within this message. If this option is not found or the DHCPv4-RESPONSE message is not well-formed, it <bcp14>MUST</bcp14> be discarded. If the DHCPv4Messagemessage option is present and correct, the 4o6RA <bcp14>MUST</bcp14> extract the DHCPv4 message and forward the encapsulatedDHCPv4-responseDHCPv4-RESPONSE to the requesting DHCPv4 client, given that the encapsulatedDHCPv4-responseDHCPv4-RESPONSE is correct and can be actually forwarded.</t><t>Layer-2<t>Layer 2 (L2) Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE messages <bcp14>MUST</bcp14> handle them as specified in <xref section="6" sectionFormat="of" target="RFC6221"/>.</t> <t>In any given environment, DHCPv6 servers to which DHCPV4-QUERY requests are routed are expected to be compliant with DHCP 4o6 according to <xref target="RFC7341"/>. No additional requirements on DHCPv6 servers are set by this specification.</t> <section anchor="intermediate-relays"> <name>Intermediaterelays</name>Relays</name> <t>Intermediate relays shall behave according tosection 10 of<xref section="10" sectionFormat="of" target="RFC7341"/>.</t> </section> <section anchor="topology_considerations"> <name>4o6RA and Topology Discovery</name> <t>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.</t> <t>DHCPv4 <xref target="RFC2131"/> and DHCPv6 <xreftarget="draft-ietf-dhc-rfc8415bis"/>target="RFC9915"/> specifications describe how addresses can typically be allocated to clients based on network topology information provided by a DHCPrelay, typically.</t>relay.</t> <t>Address/prefix allocation decisions are integral to the allocation of addresses and prefixes in DHCP, as described in detail in <xref target="RFC7969"/>. This specification aims to guarantee that the 4o6RA does not break any legacy capability when used for topology discovery.</t> <t>Topology discovery as described in <xref target="RFC7969"/> differs between IPv4 andIPv6:</t>IPv6 as follows:</t> <ul spacing="normal"> <li> <t>IPv4:whenWhen using DHCP onIPv4IPv4, only the first Relay Agent <bcp14>SHOULD</bcp14> set the giaddr field(section 3.1 of <xref(<xref section="3.1" sectionFormat="of" target="RFC7969"/>). Thus, in a network that has more than one RelayAgentAgent, only part of the topology is transported via DHCPv4.</t> </li> <li> <t>IPv6:whenWhen using DHCPv6, all Relay Agents <bcp14>SHOULD</bcp14> send link-address and Interface-IDoptions,options that provide information about the complete path between the DHCPv6 client and the DHCPv6 server to the DHCPv6 server.</t> </li> </ul> <t>InLayer-2Layer 2 networks, Lightweight DHCPv6 Relay Agents (LDRAs) <xref target="RFC6221"/> can be used.</t> <t>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.</t> <t>Then, topology information for the given IP address can be obtained from the DHCPv6 server and used for configuration or other purposes.</t> <t><xref target="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.AsHowever, as shown in <xref target="fig_4o6RA_RA"/>,however,the introduction of DHCP 4o6 at the edge of the IPv6 network hides theLayer-2Layer 2 network from the DHCPv6 RA. As such, moving DHCP 4o6 toaan intermediate node rather than performing it at the client breaks the topology propagation, as 4o6RA-only solutionsdoesdo not provide any interface information in the encapsulated message.</t> <figure anchor="fig_4o6RA_RA"> <name>Brokentopology information</name>Topology Information</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="208" width="576" viewBox="0 0 576 208" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,64 L 8,128" fill="none" stroke="black"/> <path d="M 80,48 L 80,64" fill="none" stroke="black"/> <path d="M 80,128 L 80,144" fill="none" stroke="black"/> <path d="M 96,64 L 96,128" fill="none" stroke="black"/> <path d="M 120,64 L 120,128" fill="none" stroke="black"/> <path d="M 200,64 L 200,128" fill="none" stroke="black"/> <path d="M 224,64 L 224,128" fill="none" stroke="black"/> <path d="M 240,48 L 240,64" fill="none" stroke="black"/> <path d="M 240,128 L 240,144" fill="none" stroke="black"/> <path d="M 272,48 L 272,64" fill="none" stroke="black"/> <path d="M 272,128 L 272,144" fill="none" stroke="black"/> <path d="M 304,64 L 304,128" fill="none" stroke="black"/> <path d="M 344,64 L 344,128" fill="none" stroke="black"/> <path d="M 416,64 L 416,128" fill="none" stroke="black"/> <path d="M 480,64 L 480,128" fill="none" stroke="black"/> <path d="M 496,48 L 496,64" fill="none" stroke="black"/> <path d="M 496,128 L 496,144" fill="none" stroke="black"/> <path d="M 568,64 L 568,128" fill="none" stroke="black"/> <path d="M 96,32 L 224,32" fill="none" stroke="black"/> <path d="M 288,32 L 480,32" fill="none" stroke="black"/> <path d="M 8,64 L 96,64" fill="none" stroke="black"/> <path d="M 120,64 L 200,64" fill="none" stroke="black"/> <path d="M 224,64 L 304,64" fill="none" stroke="black"/> <path d="M 344,64 L 416,64" fill="none" stroke="black"/> <path d="M 480,64 L 568,64" fill="none" stroke="black"/> <path d="M 96,96 L 120,96" fill="none" stroke="black"/> <path d="M 200,96 L 224,96" fill="none" stroke="black"/> <path d="M 304,96 L 344,96" fill="none" stroke="black"/> <path d="M 416,96 L 480,96" fill="none" stroke="black"/> <path d="M 8,128 L 96,128" fill="none" stroke="black"/> <path d="M 120,128 L 200,128" fill="none" stroke="black"/> <path d="M 224,128 L 304,128" fill="none" stroke="black"/> <path d="M 344,128 L 416,128" fill="none" stroke="black"/> <path d="M 480,128 L 568,128" fill="none" stroke="black"/> <path d="M 96,160 L 224,160" fill="none" stroke="black"/> <path d="M 288,160 L 480,160" fill="none" stroke="black"/> <path d="M 96,32 C 87.16936,32 80,39.16936 80,48" fill="none" stroke="black"/> <path d="M 224,32 C 232.83064,32 240,39.16936 240,48" fill="none" stroke="black"/> <path d="M 288,32 C 279.16936,32 272,39.16936 272,48" fill="none" stroke="black"/> <path d="M 480,32 C 488.83064,32 496,39.16936 496,48" fill="none" stroke="black"/> <path d="M 96,160 C 87.16936,160 80,152.83064 80,144" fill="none" stroke="black"/> <path d="M 224,160 C 232.83064,160 240,152.83064 240,144" fill="none" stroke="black"/> <path d="M 288,160 C 279.16936,160 272,152.83064 272,144" fill="none" stroke="black"/> <path d="M 480,160 C 488.83064,160 496,152.83064 496,144" fill="none" stroke="black"/> <g class="text"> <text x="124" y="52">L2</text> <text x="168" y="52">Network</text> <text x="356" y="52">IPv6</text> <text x="408" y="52">Network</text> <text x="52" y="84">DHCPv4</text> <text x="156" y="84">L2</text> <text x="256" y="84">4o6</text> <text x="380" y="84">DHCPv6</text> <text x="508" y="84">DHCP</text> <text x="544" y="84">4o6</text> <text x="52" y="100">Client</text> <text x="156" y="100">Switch</text> <text x="264" y="100">Relay</text> <text x="376" y="100">Relay</text> <text x="524" y="100">Server</text> <text x="264" y="116">Agent</text> <text x="376" y="116">Agent</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .-----------------. .-------------------------. | L2 Network | | IPv6 Network | +--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+ | DHCPv4 | | L2 | | 4o6 | | DHCPv6 | | DHCP 4o6 | | Client +--+ Switch +--+ Relay +----+ Relay +-------+ Server | | | | | | Agent | | Agent | | | +--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+ | | | | '-----------------' '-------------------------' ]]></artwork> </artset> </figure> <t>In order to provide full topology information, it is <bcp14>RECOMMENDED</bcp14> that any implementation of 4o6RA be combined with an LDRA implementation <xref target="RFC6221"/> in a back-to-backstructure,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 inSection 5.3.2 of<xref section="5.3.2" sectionFormat="of" target="RFC6221"/>.</t> <t>The internal mechanisms to exchange interface information, theirformatformat, and whether the interface information contains an indication that a 4o6RA isinvolvedinvolved, are out of the scope for this document.</t> <t>The resulting architecture is shown in <xref target="fig_4o6LDRA"/> where the Relay Agent is implementing 4o6RA andLDRA,LDRA and has an internal interface to propagate topology information from 4o6RA to LDRA.</t> <figure anchor="fig_4o6LDRA"> <name>Topologyinformation preservedInformation Preserved with LDRA</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="224" width="528" viewBox="0 0 528 224" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,80 L 8,144" fill="none" stroke="black"/> <path d="M 80,48 L 80,80" fill="none" stroke="black"/> <path d="M 80,144 L 80,160" fill="none" stroke="black"/> <path d="M 96,80 L 96,144" fill="none" stroke="black"/> <path d="M 120,80 L 120,144" fill="none" stroke="black"/> <path d="M 200,80 L 200,144" fill="none" stroke="black"/> <path d="M 224,80 L 224,144" fill="none" stroke="black"/> <path d="M 240,48 L 240,80" fill="none" stroke="black"/> <path d="M 240,144 L 240,160" fill="none" stroke="black"/> <path d="M 272,48 L 272,80" fill="none" stroke="black"/> <path d="M 272,144 L 272,160" fill="none" stroke="black"/> <path d="M 296,80 L 296,144" fill="none" stroke="black"/> <path d="M 376,80 L 376,144" fill="none" stroke="black"/> <path d="M 432,80 L 432,144" fill="none" stroke="black"/> <path d="M 488,48 L 488,80" fill="none" stroke="black"/> <path d="M 488,144 L 488,160" fill="none" stroke="black"/> <path d="M 520,80 L 520,144" fill="none" stroke="black"/> <path d="M 96,32 L 224,32" fill="none" stroke="black"/> <path d="M 288,32 L 472,32" fill="none" stroke="black"/> <path d="M 8,80 L 96,80" fill="none" stroke="black"/> <path d="M 120,80 L 200,80" fill="none" stroke="black"/> <path d="M 224,80 L 376,80" fill="none" stroke="black"/> <path d="M 432,80 L 520,80" fill="none" stroke="black"/> <path d="M 96,112 L 120,112" fill="none" stroke="black"/> <path d="M 200,112 L 224,112" fill="none" stroke="black"/> <path d="M 376,112 L 432,112" fill="none" stroke="black"/> <path d="M 8,144 L 96,144" fill="none" stroke="black"/> <path d="M 120,144 L 200,144" fill="none" stroke="black"/> <path d="M 224,144 L 376,144" fill="none" stroke="black"/> <path d="M 432,144 L 520,144" fill="none" stroke="black"/> <path d="M 96,176 L 224,176" fill="none" stroke="black"/> <path d="M 288,176 L 472,176" fill="none" stroke="black"/> <path d="M 96,32 C 87.16936,32 80,39.16936 80,48" fill="none" stroke="black"/> <path d="M 224,32 C 232.83064,32 240,39.16936 240,48" fill="none" stroke="black"/> <path d="M 288,32 C 279.16936,32 272,39.16936 272,48" fill="none" stroke="black"/> <path d="M 472,32 C 480.83064,32 488,39.16936 488,48" fill="none" stroke="black"/> <path d="M 96,176 C 87.16936,176 80,168.83064 80,160" fill="none" stroke="black"/> <path d="M 224,176 C 232.83064,176 240,168.83064 240,160" fill="none" stroke="black"/> <path d="M 288,176 C 279.16936,176 272,168.83064 272,160" fill="none" stroke="black"/> <path d="M 472,176 C 480.83064,176 488,168.83064 488,160" fill="none" stroke="black"/> <g class="text"> <text x="108" y="52">L2</text> <text x="152" y="52">Network</text> <text x="196" y="52">or</text> <text x="348" y="52">IPv6</text> <text x="400" y="52">Network</text> <text x="136"y="68">IPv6-only</text>y="68">IPv6-Only</text> <text x="196"y="68">link</text>y="68">Link</text> <text x="52" y="100">DHCPv4</text> <text x="156" y="100">L2</text> <text x="256" y="100">4o6</text> <text x="332" y="100">LDRA</text> <text x="460" y="100">DHCP</text> <text x="496" y="100">4o6</text> <text x="52" y="116">Client</text> <text x="156" y="116">Switch</text> <text x="264" y="116">Relay</text> <textx="336" y="116">RFC6221</text>x="320" y="116">RFC</text> <text x="356" y="116">6221</text> <text x="476" y="116">Server</text> <text x="264" y="132">Agent</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .-----------------. .------------------------. | L2 Network or | | IPv6 Network | |IPv6-only linkIPv6-Only Link | | | +--------+-+ +---------+ +-+---+--+---------+ +------+---+ | DHCPv4 | | L2 | | 4o6 | LDRA | | DHCP 4o6 | | Client +--+ Switch +--+ Relay +RFC6221 +------+RFC 6221+------+ Server | | | | | | Agent | | | | +--------+-+ +---------+ +-+---+--+---------+ +------+---+ | | | | '-----------------' '------------------------' ]]></artwork> </artset> </figure> <t>In a simple case, where the same node hosts the 4o6RA and theDHCP4o6DHCP 4o6 server, it might be enough to only use 4o6RA, as shown in <xreftarget="fig_4o6RAserver"/>.</t>target="fig_4o6RAserver"/>, where CPE stands for "Customer Premises Equipment".</t> <figure anchor="fig_4o6RAserver"> <name>Topologyinformation preservedInformation Preserved by 4o6 Relay Agent in DHCPserver</name>Server</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="208" width="344" viewBox="0 0 344 208" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,64 L 8,128" fill="none" stroke="black"/> <path d="M 80,48 L 80,64" fill="none" stroke="black"/> <path d="M 80,128 L 80,144" fill="none" stroke="black"/> <path d="M 96,64 L 96,128" fill="none" stroke="black"/> <path d="M 176,64 L 176,128" fill="none" stroke="black"/> <path d="M 192,48 L 192,64" fill="none" stroke="black"/> <path d="M 192,128 L 192,144" fill="none" stroke="black"/> <path d="M 248,64 L 248,128" fill="none" stroke="black"/> <path d="M 336,64 L 336,128" fill="none" stroke="black"/> <path d="M 96,32 L 176,32" fill="none" stroke="black"/> <path d="M 8,64 L 96,64" fill="none" stroke="black"/> <path d="M 176,64 L 336,64" fill="none" stroke="black"/> <path d="M 96,96 L 176,96" fill="none" stroke="black"/> <path d="M 8,128 L 96,128" fill="none" stroke="black"/> <path d="M 176,128 L 336,128" fill="none" stroke="black"/> <path d="M 96,160 L 176,160" fill="none" stroke="black"/> <path d="M 96,32 C 87.16936,32 80,39.16936 80,48" fill="none" stroke="black"/> <path d="M 176,32 C 184.83064,32 192,39.16936 192,48" fill="none" stroke="black"/> <path d="M 96,160 C 87.16936,160 80,152.83064 80,144" fill="none" stroke="black"/> <path d="M 176,160 C 184.83064,160 192,152.83064 192,144" fill="none" stroke="black"/> <g class="text"> <text x="100" y="52">L2</text> <text x="144" y="52">Network</text> <text x="52" y="84">DHCP</text> <text x="208" y="84">4o6</text> <text x="276" y="84">DHCP</text> <text x="312" y="84">4o6</text> <text x="52" y="100">Client</text> <text x="216" y="100">Relay</text> <text x="292" y="100">Server</text> <text x="36" y="116">on</text> <text x="64" y="116">CPE</text> <text x="216" y="116">Agent</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .-----------. | L2 Network | +--------+-+ +-+------+----------+ | DHCP | | 4o6 | DHCP 4o6 | | Client +---------+ Relay + Server | | on CPE | | Agent | | +--------+-+ +-+------+----------+ | | '-----------' ]]></artwork> </artset> </figure> </section> </section> <section anchor="deployment-considerations"> <name>Deployment Considerations</name> <t>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.</t> </section> <section anchor="seccons"> <name>Security Considerations</name> <t>This document specifies the applicability of4o6DHCP 4o6 in a scenario where legacy IPv4 clients are connected to4o6DHCP 4o6 Relay Agents that perform the encapsulation and decapsulation. This document does not change anything else in the4o6DHCP 4o6 specificationand therefore<xref target="RFC7341"/>; therefore, the security considerations of<xref target="RFC7341"/>that document still apply. Specifically, since the legacy IPv4 client is not aware of the encapsulation and decapsulation,it is4o6RA has to provide the protections that arespecficedspecified in the security considerations in <xref section="12" sectionFormat="of" target="RFC7341"/>.</t> <t>The mechanisms defined here differ from <xref target="RFC7341"/> as they allow the DHCP client to send and receive DHCPv4 messages, whereas in <xreftarget="RFC7341"/>target="RFC7341"/>, the client only sends DHCPv6 messages. This makes it possible that in improperly configured networks where the client is located on the sameLayer-2Layer 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.</t> <t>More generally, legacy IPv4 clients are not aware of thismechanism,mechanism; however, even when DHCP 4o6 is used, the client does not have any control about the information provided by the Relayagent.Agent. Assuchsuch, this change does not raise any additional security concerns.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> </middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC6221"> <front> <title>Lightweight DHCPv6 Relay Agent</title> <author fullname="D. Miles" initials="D." role="editor" surname="Miles"/> <author fullname="S. Ooghe" initials="S." surname="Ooghe"/> <author fullname="W. Dec" initials="W." surname="Dec"/> <author fullname="S. Krishnan" initials="S." surname="Krishnan"/> <author fullname="A. Kavanagh" initials="A." surname="Kavanagh"/> <date month="May" year="2011"/> <abstract> <t>This document proposes a Lightweight DHCPv6 Relay Agent (LDRA) that is used to insert relay agent options in DHCPv6 message exchanges identifying client-facing interfaces. The LDRA can be implemented in existing access nodes (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet switches) that do not support IPv6 control or routing functions. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6221"/> <seriesInfo name="DOI" value="10.17487/RFC6221"/> </reference> <reference anchor="RFC7341"> <front> <title>DHCPv4-over-DHCPv6 (DHCP 4o6) Transport</title> <author fullname="Q. Sun" initials="Q." surname="Sun"/> <author fullname="Y. Cui" initials="Y." surname="Cui"/> <author fullname="M. Siodelski" initials="M." surname="Siodelski"/> <author fullname="S. Krishnan" initials="S." surname="Krishnan"/> <author fullname="I. Farrer" initials="I." surname="Farrer"/> <date month="August" year="2014"/> <abstract> <t>IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose.</t> </abstract> </front> <seriesInfo name="RFC" value="7341"/> <seriesInfo name="DOI" value="10.17487/RFC7341"/> </reference> <reference anchor="draft-ietf-dhc-rfc8415bis" target="https://datatracker.ietf.org/doc/draft-ietf-dhc-rfc8415bis/"> <front> <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title> <author> <organization/> </author> <date year="2025" month="June"/> </front> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6221.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7341.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9915.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC951"> <front> <title>Bootstrap Protocol</title> <author fullname="W.J. Croft" initials="W.J." surname="Croft"/> <author fullname="J. Gilmore" initials="J." surname="Gilmore"/> <date month="September" year="1985"/> <abstract> <t>This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows a diskless client machine to discover its own IP address, the address of a server host, and the name of a file to be loaded into memory and executed. The bootstrap operation can be thought of as consisting of TWO PHASES. This RFC describes the first phase, which could be labeled `address determination and bootfile selection'. After this address and filename information is obtained, control passes to the second phase of the bootstrap where a file transfer occurs. The file transfer will typically use the TFTP protocol, since it is intended that both phases reside in PROM on the client. However BOOTP could also work with other protocols such as SFTP or FTP. This RFC suggests a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="RFC" value="951"/> <seriesInfo name="DOI" value="10.17487/RFC0951"/> </reference> <reference anchor="RFC1542"> <front> <title>Clarifications and Extensions for the Bootstrap Protocol</title> <author fullname="W. Wimer" initials="W." surname="Wimer"/> <date month="October" year="1993"/> <abstract> <t>Some aspects of the BOOTP protocol were rather loosely defined in its original specification. In particular, only a general description was provided for the behavior of "BOOTP relay agents" (originally called "BOOTP forwarding agents"). The client behavior description also suffered in certain ways. This memo attempts to clarify and strengthen the specification in these areas. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="1542"/> <seriesInfo name="DOI" value="10.17487/RFC1542"/> </reference> <reference anchor="RFC2131"> <front> <title>Dynamic Host Configuration Protocol</title> <author fullname="R. Droms" initials="R." surname="Droms"/> <date month="March" year="1997"/> <abstract> <t>The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2131"/> <seriesInfo name="DOI" value="10.17487/RFC2131"/> </reference> <reference anchor="RFC2132"> <front> <title>DHCP Options and BOOTP Vendor Extensions</title> <author fullname="S. Alexander" initials="S." surname="Alexander"/> <author fullname="R. Droms" initials="R." surname="Droms"/> <date month="March" year="1997"/> <abstract> <t>This document specifies the current set of DHCP options. Future options will be specified in separate RFCs. The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2132"/> <seriesInfo name="DOI" value="10.17487/RFC2132"/> </reference> <reference anchor="RFC7969"> <front> <title>Customizing DHCP Configuration on the Basis of Network Topology</title> <author fullname="T. Lemon" initials="T." surname="Lemon"/> <author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/> <date month="October" year="2016"/> <abstract> <t>DHCP servers have evolved over the years to provide significant functionality beyond that described in the DHCP base specifications. One aspect of this functionality is support for context-specific configuration information. This memo describes some such features and explains their operation.</t> </abstract> </front> <seriesInfo name="RFC" value="7969"/> <seriesInfo name="DOI" value="10.17487/RFC7969"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0951.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1542.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2132.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7969.xml"/> </references> </references> <?line379?>376?> <section anchor="usecase"> <name>Example Use Case: Topology Discovery forIPv4-onlyIPv4-Only Radio Unit in 3GPP RAN with Switched Fronthaul</name> <t>In 3GPP mobile network architecture, the UserEquipmentsEquipment (UE)areis connected via a Radio Access Network (RAN). RAN is built up with Baseband Units(BB)(BBUs) and Radio Units(RU). Radio(RUs). A radio FronthaulNetwork(FH) network connectsRURUs andBB, each ofBBUs. Each RU andBBBBU is an IP host, and they may support IPv4 only, IPv6onlyonly, orbothboth, 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 theBBBBU depending on the Cell and Sectors it serves. However, that dependency is only specified by the cabling betweenRURUs and antennas.BBBBUs can be cabled toRURUs directly or via aLayer-2Layer 2 switched network.</t> <figure anchor="bb_connected_to_ru"> <name>3GPP RANwhere RU are cabled directlyWhere RUs Are Cabled Directly toBB</name>BBUs</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="368" width="256" viewBox="0 0 256 368" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,32 L 8,80" fill="none" stroke="black"/> <path d="M 8,112 L 8,160" fill="none" stroke="black"/> <path d="M 8,208 L 8,256" fill="none" stroke="black"/> <path d="M 8,288 L 8,336" fill="none" stroke="black"/> <path d="M 80,32 L 80,80" fill="none" stroke="black"/> <path d="M 80,112 L 80,160" fill="none" stroke="black"/> <path d="M 80,208 L 80,256" fill="none" stroke="black"/> <path d="M 80,288 L 80,336" fill="none" stroke="black"/> <path d="M 104,144 L 104,176" fill="none" stroke="black"/> <path d="M 104,208 L 104,224" fill="none" stroke="black"/> <path d="M 128,48 L 128,160" fill="none" stroke="black"/> <path d="M 128,224 L 128,304" fill="none" stroke="black"/> <path d="M 152,144 L 152,240" fill="none" stroke="black"/> <path d="M 248,144 L 248,240" fill="none" stroke="black"/> <path d="M 8,32 L 80,32" fill="none" stroke="black"/> <path d="M 80,48 L 128,48" fill="none" stroke="black"/> <path d="M 8,80 L 80,80" fill="none" stroke="black"/> <path d="M 8,112 L 80,112" fill="none" stroke="black"/> <path d="M 80,144 L 104,144" fill="none" stroke="black"/> <path d="M 152,144 L 248,144" fill="none" stroke="black"/> <path d="M 8,160 L 80,160" fill="none" stroke="black"/> <path d="M 128,160 L 144,160" fill="none" stroke="black"/> <path d="M 104,176 L 144,176" fill="none" stroke="black"/> <path d="M 8,208 L 80,208" fill="none" stroke="black"/> <path d="M 104,208 L 144,208" fill="none" stroke="black"/> <path d="M 80,224 L 104,224" fill="none" stroke="black"/> <path d="M 128,224 L 144,224" fill="none" stroke="black"/> <path d="M 152,240 L 248,240" fill="none" stroke="black"/> <path d="M 8,256 L 80,256" fill="none" stroke="black"/> <path d="M 8,288 L 80,288" fill="none" stroke="black"/> <path d="M 80,304 L 128,304" fill="none" stroke="black"/> <path d="M 8,336 L 80,336" fill="none" stroke="black"/> <g class="text"> <text x="40" y="52">RU2</text> <text x="40" y="132">RU3</text> <text x="196" y="180">Baseband</text> <text x="196" y="212">Unit</text> <text x="40" y="228">RU4</text> <text x="40" y="308">RU2</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ +--------+ | RU2 +-----+ | | | +--------+ | | +--------+ | | RU3 | | | +--+ | +-----------+ +--------+ | +--| | +-----| Baseband | | | +--------+ +-----| Unit | | RU4 +--+ +--| | | | | +-----------+ +--------+ | | +--------+ | | RU2 +-----+ | | +--------+ ]]></artwork> </artset> </figure> <t>In <xreftarget="bb_connected_to_ru"/> BBtarget="bb_connected_to_ru"/>, the BBU is directly cabled to a set of RUs, and theBBBBU can recognize the relationship between RUs and Cell/Sectors based on the cabling between the RUs and antennas.</t> <t>WhenBBsBBUs and RUs are connected via aLayer-2Layer 2 switched network, the added level of complexity requires theBBsBBUs 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.</t> <t>Examples for switched networks are shown insection 3 of<xref section="3" sectionFormat="of" target="RFC7969"/> and demonstrate the different levels of complexity. An example of a FH is depicted in <xref target="l2_switched_fh"/>.</t> <figure anchor="l2_switched_fh"> <name>3GPP RAN withLayer-2Layer 2 Switched Fronthaul Example</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="352" width="544" viewBox="0 0 544 352" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,32 L 8,80" fill="none" stroke="black"/> <path d="M 8,112 L 8,160" fill="none" stroke="black"/> <path d="M 8,192 L 8,240" fill="none" stroke="black"/> <path d="M 8,272 L 8,320" fill="none" stroke="black"/> <path d="M 80,32 L 80,80" fill="none" stroke="black"/> <path d="M 80,112 L 80,160" fill="none" stroke="black"/> <path d="M 80,192 L 80,240" fill="none" stroke="black"/> <path d="M 80,272 L 80,320" fill="none" stroke="black"/> <path d="M 152,48 L 152,144" fill="none" stroke="black"/> <path d="M 152,208 L 152,304" fill="none" stroke="black"/> <path d="M 168,48 L 168,80" fill="none" stroke="black"/> <path d="M 168,208 L 168,240" fill="none" stroke="black"/> <path d="M 224,48 L 224,144" fill="none" stroke="black"/> <path d="M 224,208 L 224,304" fill="none" stroke="black"/> <path d="M 272,48 L 272,320" fill="none" stroke="black"/> <path d="M 296,64 L 296,144" fill="none" stroke="black"/> <path d="M 296,224 L 296,304" fill="none" stroke="black"/> <path d="M 336,64 L 336,96" fill="none" stroke="black"/> <path d="M 392,64 L 392,144" fill="none" stroke="black"/> <path d="M 392,224 L 392,304" fill="none" stroke="black"/> <path d="M 432,48 L 432,320" fill="none" stroke="black"/> <path d="M 456,144 L 456,224" fill="none" stroke="black"/> <path d="M 536,144 L 536,224" fill="none" stroke="black"/> <path d="M 8,32 L 80,32" fill="none" stroke="black"/> <path d="M 152,48 L 224,48" fill="none" stroke="black"/> <path d="M 80,64 L 144,64" fill="none" stroke="black"/> <path d="M 296,64 L 392,64" fill="none" stroke="black"/> <path d="M 8,80 L 80,80" fill="none" stroke="black"/> <path d="M 168,80 L 224,80" fill="none" stroke="black"/> <path d="M 272,96 L 288,96" fill="none" stroke="black"/> <path d="M 336,96 L 392,96" fill="none" stroke="black"/> <path d="M 8,112 L 80,112" fill="none" stroke="black"/> <path d="M 80,128 L 144,128" fill="none" stroke="black"/> <path d="M 224,128 L 264,128" fill="none" stroke="black"/> <path d="M 392,128 L 424,128" fill="none" stroke="black"/> <path d="M 152,144 L 224,144" fill="none" stroke="black"/> <path d="M 296,144 L 392,144" fill="none" stroke="black"/> <path d="M 456,144 L 536,144" fill="none" stroke="black"/> <path d="M 8,160 L 80,160" fill="none" stroke="black"/> <path d="M 432,176 L 448,176" fill="none" stroke="black"/> <path d="M 8,192 L 80,192" fill="none" stroke="black"/> <path d="M 152,208 L 224,208" fill="none" stroke="black"/> <path d="M 80,224 L 144,224" fill="none" stroke="black"/> <path d="M 296,224 L 392,224" fill="none" stroke="black"/> <path d="M 456,224 L 536,224" fill="none" stroke="black"/> <path d="M 8,240 L 80,240" fill="none" stroke="black"/> <path d="M 168,240 L 224,240" fill="none" stroke="black"/> <path d="M 272,256 L 288,256" fill="none" stroke="black"/> <path d="M 8,272 L 80,272" fill="none" stroke="black"/> <path d="M 80,288 L 144,288" fill="none" stroke="black"/> <path d="M 224,288 L 264,288" fill="none" stroke="black"/> <path d="M 392,288 L 424,288" fill="none" stroke="black"/> <path d="M 152,304 L 224,304" fill="none" stroke="black"/> <path d="M 296,304 L 392,304" fill="none" stroke="black"/> <path d="M 8,320 L 80,320" fill="none" stroke="black"/> <g class="text"> <text x="40" y="52">RU1</text> <text x="132" y="52">P1</text> <text x="196" y="68">L2RA</text> <text x="364" y="84">L3RA</text> <text x="180" y="100">L2</text> <text x="132" y="116">P2</text> <text x="188"y="116">switch</text>y="116">Switch</text> <text x="40" y="132">RU2</text> <text x="180" y="132">#1</text> <text x="348" y="132">Router</text> <text x="484" y="180">DHCP</text> <text x="492" y="196">Server</text> <text x="40" y="212">RU3</text> <text x="132" y="212">P1</text> <text x="492" y="212">#1</text> <text x="196" y="228">L2RA</text> <text x="180" y="260">L2</text> <text x="340" y="260">Baseband</text> <text x="132" y="276">P2</text> <text x="188"y="276">switch</text>y="276">Switch</text> <text x="340" y="276">Unit</text> <text x="40" y="292">RU4</text> <text x="180" y="292">#2</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ +--------+ | RU1 | P1 +-+------+ | | | +--------| | L2RA | | +----+------+ | +--------+ | +------+ | | | L3RA | | | L2 | +--| +------+ | +--------+ P2 |switchSwitch | | | | | | RU2 +--------| #1 +-----| | Router +----| | | +--------+ | +-----------+ | +---------+ +--------+ | | | | | +--| DHCP | +--------+ | | | Server | | RU3 | P1 +-+------+ | | | #1 | | +--------| | L2RA | | +-----------+ | +---------+ +--------+ | +------+ | | | | | L2 | +--| Baseband | | +--------+ P2 |switchSwitch | | | Unit | | | RU4 +--------| #2 +-----| | +----| | | +--------+ | +-----------+ | +--------+ | | ]]></artwork> </artset> </figure> <t>If IPv6 is used and allRURUs are capable of DHCPv6 in <xref target="l2_switched_fh"/>, DHCP topology knowledge can be used for solving the RU configuration problem. Such solution would use the topology discovery mechanisms described insection 3.2 of<xref section="3.2" sectionFormat="of" target="RFC7969"/>.</t> <t>IfRURUs are capable of IPv4 only but implement a DHCP 4o6 client according to <xref target="RFC7341"/>, the same topology discovery mechanisms are applicable.</t> <t>IfRURUs are capable ofIPV4IPv4 only and cannot implement a DHCP 4o6 client according to <xref target="RFC7341"/>, the topology discovery mechanisms described insection 3.2 of<xref section="3.2" sectionFormat="of" target="RFC7969"/> can be used by introducing 4o6RA in the switches asdecribeddescribed in this document.</t> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>The authors wouldalsolike to acknowledge interesting discussions in this problem space withSarah Gannon, Ines Ramadza, and Siddharth Sharma<contact fullname="Sarah Gannon"/>, <contact fullname="Ines Ramadza"/>, and <contact fullname="Siddharth Sharma"/>, as well as reviews and comments provided byEric Vyncke, Mohamed Boucadair, David Lamparter, Michael Richardson, Alan DeKok, Dale Worley, Paul Wouters, Deb Cooley, Erik Kline, Ketan Talaulikar, Mike Bishop and Roman Danyliw.</t><contact fullname="Éric Vyncke"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="David Lamparter"/>, <contact fullname="Michael Richardson"/>, <contact fullname="Alan DeKok"/>, <contact fullname="Dale Worley"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Erik Kline"/>, <contact fullname="Ketan Talaulikar"/>, <contact fullname="Mike Bishop"/>, and <contact fullname="Roman Danyliw"/>.</t> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA61c63LcNpb+j6fAyj/GHrfakewosXYyM7o5VuKLRpKTSm1t udAkuhsjNtEhSMkd23mWfZD9tftiey4ACLLZkryZrkrcTRLAwbmf74Da3t4W takLvS+3jl8enV0/27bXutqm73vyxtRzea4LtZIHM13W8qJZLm1Vbwk1mVT6 2o+Sz+xe+tiWyFStZ7Za7UtX50LkNivVAhbJKzWtt42up9v5PMP/lmFJ+r63 Xantr/aEayYL45yxZb1awrjTk8sXomwWE13tixwm3xeZLZ0uXeP2ZV01WgAx T4WqtAKiTstaV6UGQm5sdTWrbLNEUldAhMnkS+tqeWTLqZk1laphkS1xpVfw aL4v5LZESsS1LhtYRcr7jJaSydz6GZYz5Ux+j4Pw+gw42EzgzsJU/1RXT5gB G/e+JYRq6rmtkBAYLqUpYYNHY3lmq6mpDF1jXh4VqsmN7dyx1UyV5jcia1+e VCZzzpZ0Sy+UKfZlxqPGSx71d+2fGWd20VnzYix/rIybl6pMFr1oKu3m3Tvd RY+My2y6oqMh4ys/5O8zvLy23A9jeVBdXdlkrR9UZZKLd+/tnzBgrHDA5m29 hm3973/PC31jyjxZ7DXKp3/r7iVJrOOrRvth3YVFaasFjL4mTZLnL472dnd3 wvdvnj6D7/ijZxbVNPv22c7XE+PoUfjUqprpGtRoXtdLt//kCdiAqiuVXelq jOPGQOoTMLMnG6d6shXmCva+UaHlWWVrm9lCTm0lT9ETPGSP8ChMQjYof2hK LXe/2v1aCFNO+3t9/nXc6s7Xz3bD992dpzvJ93j9m+d7z4Ed29vbUk0cbq4W 4nJunIR9NQt0P7l2WWUm2kklFzqbg3DcgogEY0dTd4JcVqFnKlsh5WBgZbEC rTcw3snaysZp6XR1bTKYZlnZa5PrXE5WYsD/mRIWShzbWHixSbfUmZkamALn s1M5PLqea7+2RDrGvf20s6igENsT5YAetQTSVDaHGVQtVFHYG9elBfdiFstC 00y4UHTFuszU0jUFC1OBMuc6vRLJBSY6p2awPtDqqY6X4MGJnqtiis8rzx6/ m7FgQS1MnhdaiAcSXG5l8yajBT4+MMnPz0J8/Oi39/lzR4gg5dJhROmJM1NV tUJH6lel8ag4nz+LSGDj4hN78MRGzYc1cc7c6zvJHEMLjBawNdQSqfIcvJRD ospcWmBnFdb2Qspk1rGRparAcUCccUJllXWODIXVLWjjWF6CXHK9LOyKxATL payo9K+NgXXBR1JcBTEQn6O+IjGqlS7sE1UXbF68tDcavoykAeEEHQPd0hAj c9Ro0t052jaqEKlfWIZIfSZw8kyVpa2lVs7A/YkGkpaFymA8cKxZopnn8uHN 3IAqZrYpcnwmbzRqnypXPibjvmoQYGkyVeDICcoG+AnTKXCG7tEIqADqolrn FnYNK1OARm26MAtTqKpYjWi3genEa0fy8wxITAD5BnMpJ1+Z2by+0fh/sf6c fPjq+PzgEbMePTCwfnBCePApPChuV6bcIuVIk3ZaE7lLkL+ZmMLUK+QMaDKY RXBDrEcjwVoF0ihbww0aTHbbcRjjvvNLnEXZ0SL2GM4WDSkmiRvkCpIScR1W CIN50ULnBsQKe8h1y0EHjjObo9lXEpIX1OsROVP4LpdNTZSCxIPOLoj/sJxX 1bF8A2zRN2heFDtoJv2hhhyNRAipGdzXoJr/DsHC1VrlXikG3SFOha41g82R +NMd0xbZKYo1p7jUFYaiO1yi7LpETxEosuiI4MEDebBcFqCIXroXmV1qcHAq vfoZZaVbH+aik8tZqOkucSRpCS3U9Slz2C36JLRbx9tEnuHTlc40BFcUfuqx 5M1co6XTTtk5hKjdcZvoG9DewCCByAloZw5SzGogZVpZ5hauOpYvmgoVdQHq PYqXcXhT0rg07gi/sPc/uBvMAlgQqcRAwwxNAo+UsCzvye+FnKbwTnMsDxvy eKAv6DG6jq/Vbh+6++57sgIxQFAJkkxkEtSLZJIQh2LGBOga7ZFUFdTjWE9N aeg3C3dqUd/QCtCGvGsGx1+uFqzcjRuQNiQ0f6YdYJZzOiXHQX7gxjjdUjRi NlZ6CnaHnPGxBxZ5Ej3VOMx1/YxyJhqiUNeA1GRXLPDkaYlZSeDjQ5gPLOIR TYEbU1U2N+C96yYIHFgLEQDT9hFt01/zZt1hI9wKpPSyn6jvXU4zTanNekKA aSRuUJBML2uKX0VBkaXD/UgI0Fage5rN6Ylc15CRAzfMFJiIc05AobQmGhf7 8vDt28szJgYSU1BJ+oqJ6efPI78BHJXaTPhOj5BW3CPZoE0mAWkwzoAQKCZ1 N1+2DjNs3FZmZkqIqgOzdILkiAwKuYRTwkMgil1OR3LN2W7iHLtec9qUPnFr I+Qm/elvA3Qp7OM8qm/PKaPNRp/haF8wDIe0CaBa06zEjDBDQF2FMl1ine7k 1ut3F5dbI/5XvnlL389P/vHu9PzkGL9fvDx49Sp+Ef6Ji5dv3706br+1I4/e vn598uaYB8NV2bkktl4f/LLFSrD19uzy9O2bg1dbA869IgcJSRLF2mWl0dUp JzoB4fDo7H/+awf987+Rgu08J2XDH9/ufPMMfqBX59VIgvwT+LYSED60qoJ5 QAwztSJjAP7N7U0p0XOi8P4DOfOf+/Ivk2y58+yv/gJuuHMx8KxzkXi2fmVt MDNx4NLAMpGbnes9TnfpPfil8zvwPbn4l78V4Pvk9s63f/urQD9+l8ayuvZz K+UcfOG8g6LQCFle6aSE5JCM8o0hTJCm+xGs5WmGvUfyKyCxRR2gOBUKT0zu bAzhnIPFiZyum2U/NyLHkLuB7NYxTLfughOdoNAAicZ72j4Z9++//66Uu54J X9HTZ7zdfsZSbrqTDPnUeerThu/wS8jHYfzj7cd46dUu/A++JzPTHWJd585j gbN50cLXN55TtITnCC/Z3omp3ycafMQZSksErpRqRvfOBWcbfvD6lvAbsZ0Y 2r+zec/0Gdjz+p3H/z8mt58/JWv8qfNY5w5pgvi4Lx9E/WCI6LutgyQzkCcf FHpw3vWrtrLxnN0C0yDWb6vCzMrvtjKsOqqtz5vLGAwDnbxcrOflm3I272R9 OIu5SCrRWL1wxRLqF0wHPbwRy+oW1jj1Dp3KDs5Ym2VI1vuFhs9AKT9pCg7R AlUulPMheeoUgkmxjtmguqGYQSGSLk40kkrpbi6ujQrJPU3M/mMsDmIUBXGp DD2TSx/kNUYUIyAIEQscyJLz1k7VIbiaSquSNKcnvl9ozg++xrQkyeqBcgg+ lkYbzukjWeBjOlTW6soLvbKFDvlNuwq4QhB2v3IYCeYK3oVc3GAFQmgOQi8L U5JYgeEQBfEWRd2pyrT33zA4cif4zsgb4MTw5IXFnKo7Mw8WvgzBKpm0QZE2 UKCeQALKSgXhAUGqasW+rMPuMQlvk16PWoaNkHIiwnVESqURgg8SqkWuDH9t tKtFp+D1DuzAhxi7JPnFUs9vA6olB2GFqhrI5N/yU+c8YRikeuXsrdmvmDBt hqs0LOH9jtpcj6PfArhFHCOZQVVdhRqbXIz+YFydAHzEblZfJt6NfIFHcKBk +JnrVLbxnLd7e7JOJRAraJuh0sROLdrZsb+T2Fgvq2gNZK9jILDRFqfznqWf tLfibjGIxDJGMoOSvfaWg2v/9Gz7H+9Ozn+Rr5k28pqtH02eDJoRd+ExhLzV gyHPBFT/jKCCX+z85OLs7ZuLk7AeG4yfCBQoiDdhCBltYe0VI3eJnw1zeNVC SQfGeCLBB0/5gn/G+8mpbUpCJdvZWtIWLWn47I0uim0ODEQKJb4IXBqXqSrX uV9kE1kGOwPaBcvObIVQSSIsnhFyMuxSJBMFcJqGAQHg2/NenNN5oN57HR28 ppdWC3uLoAIz4LUH9u6cjDAWold6gBeBQCCzgViwCkQhC8QrLhK7ySSLNhAR lc2jED+tM90JYobHPLHYXqvl1u0j1pinJUVl3qEur01lywVtuoP7kKNjGDol S3iecWJOuGVOX/WHZUSZJpiyg20bxKVC0gbOFdiEnk90Aw6kvW8oNSfwBwrv PuDZowtXg4xdkCX07Rvr1gfUHGlxV3ZkuPO1i5CtY8DGtgsifYFC3ITzDNz5 qtdEYJDSJwIg8Eu7tIWdgU1jIxZIXMmPD2p/8T12zSFn4VDkPhP/nV3o2LIY DcCS2P9hFHChEE1YaqpL6ckwc9KR8IgkIrg0SNW1Img5LZdGGCFwOpBOU1IS JLzjC1PidkaS+vwg5LLG3gBUMzjQR75JSykp9Hq36N6oTa/jEOt1WrGFF9mc CGfJlNev0KxhHB744rco4kZic9SWacsxJGwk/BHGGOyfYJtQ+Lj9BNzQ1HwI 6+F4yI9Ni6hj7JxVoKXehyQP2qnodrV4rrbZN1qL7IyhiZiSPN97ziGyr9dS mQVJYNYoiOq11q13YlWMDZ4JhK8rsnEfa8B3xUCPmkK4KYWJwK48aC4lCv2L A/lIpNWjfy5gf+LUo6iUiBEYe0rwqV85tl+sR9Wp1KeE3lSgup2zLwRsQALI 25wZ5C48p4tcPgzm+XS809onkfQI+dc4SgCU6IAFqMUIs3NPyJbdCoNIWUJV JXt2IUAaMZcCFmCNwJo/9hvcW9sgoQHgWjqu3kM1mAGKwpRQuvlskRgWMunt 02MfF8k5AN1ehUWq1mpiGbZnXwvZOdBez0UCwspO/h2Lox6+b9cvcpgI0ar1 VLeDrC5FM4U3XFS2kN8ESxx1vU66KwRlr8EkqALoNGJDIeAzfgJVyU+ys8pi gdNhLGvLBvZSx49wviFSQiLFkfL0LDilsDMuP9LcrstYXDSaWrcAhAvcm1w2 1dI6gqfSWltT48el9Zo/SOGXGLZeoZFSn+KpmGNa2PmHmpxPQmWq+VclNvbw Zr+cG8x+YpqbJKZcZA1gX+8R/qI4wsHKr9KeXQCxUXrA9ZTOZ1GSVMsFA56b 3HOkp5dr/MdK+IBBvhGYO6VWVA5hNFzryEqQSWwTe3gDR2AhW6cSIL/KXIqs B41eqpmvLLhsPD9g+DK0h130zBG/QN8cGd0xaq/cHY7HNP1uBDHFEdevb0QT X+1GGC9cizAXySC9O4CydYA8RtQe84/kXsDcbkEZaVUCKf0PlFog5lMQbyDt NsTxsbyg9rr/4ZWdiXnc+XUH+vip98NDl56i9Je8HYn8AzzqCqv3+bThekJI +0lxyBSnXL8e7w+gle9bwPKwslcYawb85y34JMQWyLM59gSbIDxvaJ6Rh4yS noU/o4VWFBAElbgSII8rkAm6Zz6gBraN7b/+gPSACvnMicqutmu7jf9KV1eN 79Jy7GSHIIZmMmVWNHnvoBzsz4NUrV9NzZ32kQTKPsg5ELNozqaeWSykOgVj qA5Ha9VgBBPHT8e7MVuKFeFl8PtYfCXte1hJf2BkZ5h+woNMFZAg5BFEDe9N N4yhcAQcoearKfOQ3zImyuLDfMuU17a49sUlZjo+Jjg6DsKxuduvvKSKHrwm Y3gplG6GQhNKkRt/UAn10WakID0y1JZ7OIz1AbNJVbasa/dbWxEiw4Y8h2KW h2ktzfkv8+899544d2Baz2MMe/d0eHvGDvOqux3OPR1f5yp+Hoch9w4LuDc0 xEjOlweExwEZict/cShY60N9eRC4gxf9BbrsvlMa7eeLvf+68yeGe99/OVxs a26k+LYVPH97IID8nQyNGkCjJOskNJgStHA2SydWGNK90KOBzBJxxwWVJhPM oPiciuWqDlPngPEPp6k8yT0btR2hpNnTnQ3IpA/Jas4629OuoOD3b6muKS7I 4ujspDdvX2W/lN4Nqri5CzqQPYSy815KNFn1ke6ApXip36JcD+Rxew74qAPD UaMsHvmtIiAWggxj0VxSerXhLhPDTMn5YjwsyJGyxNcu4kHJ4L4mlVU5qDZH xwbP67btAQboylxQNEjpcbUGO2CkQYXu3iX3SRkPg+imPYfw/LBvKIXGCtoV cgKBKigwTdt2zELEojNfSCk8NMXT1rGMCoRYalcxpBE03MNk4hLhEN8yfvjm 4PIR23tipKEAx2PNvW3T+T9ISpoKMamuaOTHB05nGWOltzWyO+dBQxFJmkG7 d7B9VRnrPUrygkLKaNE5HRln6IAajMAkZ1zvONrq4btAtojln0+lIG/FAn0m dYHdgzL2c1itu6gfuzrffsTc0wW2dYHl/kF3VxsQLfWYx+IizFkgogvyzHTa izrd1CP31nDHfkPDmOXugeI0i8UDhJyBemaShgNNQFJ7kCBsTPQ21ulm7Oz2 231rx4D5aCYJnbHJ0JTsnI3Fk118eK/ffxeE/ZcMGoUzwL23N3ycUm7tkEQ0 H8EgAB4h6r/o4RVkQe154B2fZS/CmQQ6rE7t2WKVoO0ByXRJjGyFFtBx3ySg 4BlwEk6ZCSsLb1j4iNl/KYVfOKATy/2HZTjcwf4gOXTw89wQ7d45ZQqDra4q W2rbQLCtMQmGXU0sOIj0PQvf0KF26hJUBDJt6pgRilVgYxZEsUBwK8HOXDzc iI1Af7iafABWI3ys0yH+Sa3jxFMjRVUH7FEyNaYMkvix8GexR0xEPO1K3dJQ 1YUmSsD2qN2CnVfUs9hgjeGipYssi9o0fr0IhIXG7kA76zVaPngiMAgy3w2e rG+2KcUJ+obbYqi6fQmCXqnyoKzXqOizuC9WEoeA1KKFncWmHktbSil+hctj cV5F2AnGBSqF57JxhaQD2JeLo7aePD14c7AWybsxAt1PaflJxT4nvDqFJT3O Es5VvYN1jyDp3B/q4IUT/Vz6nCt87/Ndacg8n35/BiHi4A2HPK4rYOsvQONB r5oCQhgwFPNZTnHp+YWdoJkEzHL9DDiQU8mTXxuz5Mbnw3cnj3qnHzEbYFIO MjzvEqPyQ6Dm0ZhowvNMjSlqPEVF9B0CHRM0MSQfpj08fEQW1+4JLp6/w+F0 pd1GnP3Fy0eBCifP35HxHh6CMqGfsFMRL/kz1adnlLPz+Vkyl3A+K7Z8Rlx6 EncxzwDfILjPid7FezHQ1dxWMd9fQDFQjMUJrgpL0sET82uj23cdan8kCi2b EAPslJWl8sfq2a/xJUF+orr2h47CK2dHGsMmPIsRx1ad1VpfHNQcdrxGdG8G Io08nUs6tuTDeChE1xXOzvEiwjZ+BUhwCpw8dHU8q8O+xgJI8CkhPsrbh4fi uybAP04iYzQI+hpe/0gKHp/7dxN+yPXP3+3GG+3VtBT41B+7Xhj0y4XhZ2m1 p/1542pcvX9Ka6BIUjohP9E5uLlOCw/41JrIBoJlt+AZoD/MJNlJ9LbzLBI+ TFOfl3fubng7w6T1aLlFkGviD7XbZPI+OqH3tX1fNaF8a10h5SSonVXUxKiD oJKHh7fDAB8/ri8C+RS7lDhRq+LRws/f8QmKYAjwpJ2V5jftT/hwjurmZpnY EOcfaKlPvJWKeJZgyOoopPlRrelxU/PwkK/T/dRd32F3fJhO0aujBXgFevOG W7kfMPTFV1XZ0Th+zRGjMTgO8ByVwK5dkfbLEqSxA7D3UsmwHUjcCWTFnXbm oqowYUPI0Nc9h4+lXOb17/tSNoAtsWPf69f7Q8gLkBKUojWTx6k7RnTijesy B3IKfHOH4zglti9ekqLopcnqcEih2H0fSHo/nXehnb6qtwayE23ibCfBQda8 wCYbjpN+ImwISqKuVacTDpsrPdxf13ec8HVZ//0WVxXBUtm6nLvXPduFIcyx lua1s+/DzoS934Oddlo/9pxebfUXh/3dOiV9D7h2bdgnDvJi6FoCim3i4j0m Is56+G6zKO9LUQLf+WtpHLynLvJlFsOXKuaXM3uDlqY7/SItTeJwMva+Whoj b3fzMfy2WrrbTtuj+Y9r6R9Rgxhwu55rPdgStO7jykD94b3ybRF3yvm3r/04 sOFppRDAl3QAJ/zdir1hh8oAQht22iCS9jQpNPgww5Gn/xJ2ZWGxxVhcYJUY X6u/ITAinGdfP+2y8e3v9mjYruiGmjHtfH2T7Um0SZO8OMnQazw+lZ4OXXuD gBCX24mklzc8alnozbT85GlJ/lzEl5Ik/mUs64hysoqIRdsU7WYHjk8LbngX n5DfgywoCp/9/7jPf9RC599tTVXh9JZ/vZ//MpPzmkDvvRTmiv8URtYqG8HZ /hw3brVxziOHjLx4/YLiis41UdGuKjWX3yNzSyhFSyD7XC1U/pviSvHC5Pkc rAeehH8WSsCmbqiwwxNP10bfhPd6FlytpwAI/tki+dOqzK6gtH9t5wpflzq0 TaZyZRB1U/Ao2O8CzxpiNfjagFQgATzHf6vcIU0HBfD9WP9or0byWIFq/Gyr QkPdfIYW/nP4gxHHeiKPrKU7sO6V/BFfzxzJH3UN4y9VAU+bK0WLAOcODaRj S85X7QJXUOWqMDdj8X+LkR+gmUwAAA== --></rfc>