rfc9928.original.xml   rfc9928.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4. <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.30 (Ruby 2.5.
4) --> 9) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-dhc-dhcpv4-over-dhcpv6-ra-06" category="std" consensus="true" submissionTy -ietf-dhc-dhcpv4-over-dhcpv6-ra" category="std" consensus="true" submissionType=
pe="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3"> "IETF" xml:lang="en" number="9928" tocInclude="true" sortRefs="true" symRefs="tr
<!-- xml2rfc v2v3 conversion 3.30.0 --> ue" version="3">
<!-- xml2rfc v2v3 conversion 3.31.0 -->
<link href="https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6
-ra" rel="prev"/>
<front> <front>
<title abbrev="DHCP 4o6 Relay Agent">DHCPv4-over-DHCPv6 with Relay Agent Sup <title abbrev="DHCP 4o6 Relay Agent">DHCPv4 over DHCPv6 with Relay Agent Sup
port</title> port</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-dhc-dhcpv4-over-dhcpv6-r <seriesInfo name="RFC" value="9928"/>
a-06"/>
<author initials="C." surname="Porfiri" fullname="Claudio Porfiri"> <author initials="C." surname="Porfiri" fullname="Claudio Porfiri">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>claudio.porfiri@ericsson.com</email> <email>claudio.porfiri@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="S." surname="Krishnan" fullname="Suresh Krishnan"> <author initials="S." surname="Krishnan" fullname="Suresh Krishnan">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<email>suresh.krishnan@gmail.com</email> <email>suresh.krishnan@gmail.com</email>
skipping to change at line 39 skipping to change at line 40
<address> <address>
<email>jari.arkko@ericsson.com</email> <email>jari.arkko@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="M." surname="Kühlewind" fullname="Mirja Kühlewind"> <author initials="M." surname="Kühlewind" fullname="Mirja Kühlewind">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>mirja.kuehlewind@ericsson.com</email> <email>mirja.kuehlewind@ericsson.com</email>
</address> </address>
</author> </author>
<date year="2025" month="August" day="26"/> <date year="2026" month="February"/>
<area>Internet</area> <area>INT</area>
<workgroup>Dynamic Host Configuration</workgroup> <workgroup>dhc</workgroup>
<keyword>dhcp</keyword> <keyword>dhcp</keyword>
<abstract> <abstract>
<?line 59?> <?line 54?>
<t>This document describes a mechanism for networks <t>This document describes a mechanism for networks
with legacy IPv4-only clients to use services provided by with legacy IPv4-only clients to use services provided by
DHCPv4-over-DHCPv6 in a Relay Agent. DHCPv4 over DHCPv6 in a Relay Agent.
RFC7341 specifies use of DHCPv4-over-DHCPv6 in the client only. RFC 7341 specifies the use of DHCPv4 over DHCPv6 in the client only.
This document specifies a RFC7341-based approach that This document specifies an approach based on RFC 7341 that
allows a Relay Agent to implement the DHCP 4o6 encapsulation and allows a Relay Agent to implement the DHCP 4o6 encapsulation and
decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a decapsulation of DHCPv4 messages in DHCPv6 messages on behalf of a
DHCPv4 client.</t> DHCPv4 client.</t>
</abstract> </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> </front>
<middle> <middle>
<?line 71?> <?line 66?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t><xref target="RFC7341"/> describes a transport mechanism for carrying D HCPv4 <xref target="RFC2131"/> <t><xref target="RFC7341"/> describes a transport mechanism for carrying D HCPv4 <xref target="RFC2131"/>
messages using DHCPv6 <xref target="draft-ietf-dhc-rfc8415bis"/> for dynamic pro messages using DHCPv6 <xref target="RFC9915"/> for dynamic provisioning
visioning of IPv4 addresses and other DHCPv4-specific configuration parameters
of IPv4 addresses and other DHCPv4 specific configuration parameters
across IPv6-only networks. The deployment of <xref target="RFC7341"/> requires s upport in across IPv6-only networks. The deployment of <xref target="RFC7341"/> requires s upport in
DHCP clients and at the DHCPv6 server. DHCP clients and at the DHCPv6 server.
However, if a client is embedded in a host that only supports IPv4 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 and cannot easily be replaced or updated (which could be due to any
number of technical or business reasons), this approach does not number of technical or business reasons), this approach does not
work.</t> work.</t>
<t>Similarly, the specifications for DHCPv6 Relay Agents such as Lightweig <!-- [rfced] Please review the text below. We were unable to find "L3RA" u
ht sed 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.
-->
<t>Similarly, the specifications for DHCPv6 Relay Agents such as Lightweight
DHCPv6 Relay Agent (LDRA) <xref target="RFC6221"/> or DHCPv6 Relay Agent (L3RA) DHCPv6 Relay Agent (LDRA) <xref target="RFC6221"/> or DHCPv6 Relay Agent (L3RA)
<xref target="draft-ietf-dhc-rfc8415bis"/> do not foresee the possibility to han dle legacy DHCPv4, <xref target="RFC9915"/> do not foresee the possibility to handle legacy DHCPv4,
other than implementing DHCP 4o6 in the client.</t> other than implementing DHCP 4o6 in the client.</t>
<t>This document specifies an <xref target="RFC7341"/> based solution that can be <t>This document specifies a solution based on <xref target="RFC7341"/> th at 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 extensions are needed; 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"/> tha t allows instead, this document specifies a new use case for <xref target="RFC7341"/> tha t allows
a Relay Agent to perform the DHCP 4o6 encapsulation and decapsulation instead of a Relay Agent to perform the DHCP 4o6 encapsulation and decapsulation instead of
the client.</t> the client.</t>
<section anchor="applicability"> <section anchor="applicability">
<name>Applicability Scope</name> <name>Applicability Scope</name>
<t>The mechanisms described in this document apply to the configuration phase <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 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 reachable directly from the host. Furthermore, the host is unable to implement
a DHCP client conformant to <xref target="RFC7341"/> as it is connected to an IP a DHCP client conformant to <xref target="RFC7341"/>, as it is connected to an I
v4-only Pv4-only
network. But there is a DHCPv6 server that can provide IPv4 addresses by means o network. However, there is a DHCPv6 server that can provide IPv4 addresses by me
f ans of
the mechanisms specified in <xref target="RFC7341"/>.</t> the mechanisms specified in <xref target="RFC7341"/>.</t>
</section> <!-- [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.)
-->
</section>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The following terms and acronyms are used in this document:</t> <t>The following terms and abbreviations are used in this document:</t>
<ul spacing="normal"> <dl newline="true">
<li> <dt>DHCP:</dt>
<t>DHCP: <dd>
If not otherwise specified, DHCP refers to DHCPv4 and/or DHCPv6.</t> <t>If not otherwise specified, DHCP refers to DHCPv4 and/or DHCPv6.</t
</li> >
<li> </dd>
<t>DHCPv4: <dt>DHCPv4:</dt>
DHCP as defined in <xref target="RFC2131"/>.</t> <dd>
</li> <t>DHCP as defined in <xref target="RFC2131"/>.</t>
<li> </dd>
<t>DHCPv4 over DHCPv6 (or 4o6): <dt>DHCPv4 over DHCPv6 (DHCP 4o6):</dt>
The architecture, the procedures, and the protocols specified in the <dd>
DHCPv4-over-DHCPv6 document <xref target="RFC7341"/>.</t> <t>The architecture, the procedures, and the protocols specified in th
</li> e
<li> DHCPv4-over-DHCPv6 document <xref target="RFC7341"/>.</t>
<t>DHCP Relay Agent: </dd>
This is a concept in all of the following protocols, although the details diffe <dt>DHCP Relay Agent:</dt>
r <dd>
between them: BOOTP <xref target="RFC951"/> <xref target="RFC1542"/>, DHCPv4 <t>This is a concept in all of the following protocols, although the d
<xref target="RFC2131"/> <xref target="RFC2132"/>, and DHCPv6 <xref target="dra etails differ
ft-ietf-dhc-rfc8415bis"/>.</t> between them: the Bootstrap Protocol (BOOTP) <xref target="RFC0951"/> <xref targ
</li> et="RFC1542"/>, DHCPv4
<li> <xref target="RFC2131"/> <xref target="RFC2132"/>, and DHCPv6 <xref target="RFC9
<t>Lightweight DHCPv6 Relay Agent (or LDRA): 915"/>.</t>
This is an extension of the original DHCPv6 Relay Agent specification, to allow </dd>
layer-2-only devices to perform a Relay Agent function <xref target="RFC6221"/> <dt>Lightweight DHCPv6 Relay Agent (LDRA):</dt>
.</t> <dd>
</li> <t>This is an extension of the original DHCPv6 Relay Agent specificati
<li> on, to allow
<t>DHCPv4 over DHCPv6 Relay Agent (or 4o6RA): Layer 2 (L2) only devices to perform a Relay Agent function <xref target="RFC622
Refers to a Relay Agent that implements the 4o6 1"/>.</t>
transport as specified in this document.</t> </dd>
</li> <dt>DHCPv4-over-DHCPv6 Relay Agent (4o6RA):</dt>
</ul> <dd>
<t>Refers to a Relay Agent that implements the 4o6
transport as specified in this document.</t>
</dd>
</dl>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <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>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<?line -18?> <?line -18?>
</section> </section>
<section anchor="dhcpv4-over-dhcpv6-relay-agent-4o6ra"> <section anchor="dhcpv4-over-dhcpv6-relay-agent-4o6ra">
<name>DHCPv4 over DHCPv6 Relay Agent (4o6RA)</name> <name>DHCPv4-over-DHCPv6 Relay Agent (4o6RA)</name>
<t>This document assumes a network, where IPv4-only hosts are connected <t>This document assumes a network where IPv4-only hosts are connected
to a network that supports IPv6 and limited IPv4 services.</t> to a network that supports IPv6 and limited IPv4 services.</t>
<t>To address such a network setup, this document extends <t>To address such a network setup, this document extends
DHCPv6 Relay Agents with DHCPv4-over-DHCPv6, as shown in <xref target="fig_4o6RA "/>.</t> DHCPv6 Relay Agents with DHCPv4 over DHCPv6, as shown in <xref target="fig_4o6RA "/>.</t>
<figure anchor="fig_4o6RA"> <figure anchor="fig_4o6RA">
<name>Architecture Example with Legacy DHCP Client</name> <name>Architecture Example with Legacy DHCP Client</name>
<artset> <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"> <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 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,48 L 80,64" fill="none" stroke="black"/>
<path d="M 80,128 L 80,144" 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 96,64 L 96,128" fill="none" stroke="black"/>
<path d="M 176,64 L 176,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,48 L 192,64" fill="none" stroke="black"/>
skipping to change at line 219 skipping to change at line 269
+--------+-+ +-+-----------+-+ +-+--------+ +--------+-+ +-+-----------+-+ +-+--------+
| | | | | | | |
'-----------' '-----------' '-----------' '-----------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>This document specifies the encapsulation <t>This document specifies the encapsulation
and decapsulation specified in <xref target="RFC7341"/> to be performed in the R elay Agent and decapsulation specified in <xref target="RFC7341"/> to be performed in the R elay Agent
without requiring any changes on the DHCPv4 client. without requiring any changes on the DHCPv4 client.
In this case it is up to the Relay Agent to provide the full DHCP In this case, it is up to the Relay Agent to provide the full DHCP
4o6 support and the legacy DHCPv4 client is not aware that it is being served 4o6 support, and the legacy DHCPv4 client is not aware that it is being served
via a DHCP 4o6 service. via a DHCP 4o6 service.
As the 4o6RA acts as a DHCP 4o6 client, all prerequisites and configuration As the 4o6RA acts as a DHCP 4o6 client, all prerequisites and configurations
that apply to the DHCP client in <xref section="5" sectionFormat="of" target="RF C7341"/> are also applied to the 4o6RA.</t> that apply to the DHCP client in <xref section="5" sectionFormat="of" target="RF C7341"/> are also applied to the 4o6RA.</t>
<t>As the 4o6RA takes the role of the client in respect to <xref target="R FC7341"/>, <t>As the 4o6RA takes the role of the client in respect to <xref target="R FC7341"/>,
it is responsible for determining a suitable interface where it acts as a it is responsible for determining a suitable interface where it acts as a
DHCPv6 client, and it is responsible for locating a suitable DHCPv6 DHCPv6 client, and it is responsible for locating a suitable DHCPv6
server or relay agent and obtain the necessary IPv6 configuration.. server or Relay Agent and obtaining the necessary IPv6 configuration.
As specified in <xref target="RFC7341"/>, the 4o6RA, acting as 4o6 client, there fore has to request As specified in <xref target="RFC7341"/>, the 4o6RA, acting as 4o6 client, there fore has to request
the DHCP 4o6 Server Address option from the server by sending the the DHCP 4o6 Server Address option from the server by sending the
Option Request option as described in <xref target="draft-ietf-dhc-rfc8415bis"/> Option Request option as described in <xref target="RFC9915"/>
before it can use the 4o6 transport.</t> before it can use the 4o6 transport.</t>
<t>To maintain interoperability with existing DHCPv6 relays and servers, <t>To maintain interoperability with existing DHCPv6 relays and servers,
the message format is unchanged from <xref target="draft-ietf-dhc-rfc8415bis"/>. the message format is unchanged from <xref target="RFC9915"/>. The 4o6RA impleme
The 4o6RA implements nts
the same message types as a DHCPv6 Relay Agent <xref section="6" sectionFormat=" the same message types as a DHCPv6 Relay Agent (see <xref section="6" sectionFor
of" target="RFC7341"/>.</t> mat="of" target="RFC7341"/>).</t>
<t>However, in this specification, the 4o6RA, instead of the client, creat <t>However, in this specification, the 4o6RA, instead of the client, creat
es the DHCPV4-QUERY Message es the DHCPV4-QUERY message
and encapsulates the DHCP request message received from the legacy DHCPv4 client .</t> and encapsulates the DHCP request message received from the legacy DHCPv4 client .</t>
<t>When DHCPV4-RESPONSE Message is received by the 4o6 Relay Agent, <t>When the DHCPV4-RESPONSE message is received by the 4o6 Relay Agent,
it looks for the DHCPv4 Message option within this message. it looks for the DHCPv4 message option within this message.
If this option is not found or the DHCPv4-RESPONSE message is not well-formed, If this option is not found or the DHCPv4-RESPONSE message is not well-formed,
it <bcp14>MUST</bcp14> be discarded. it <bcp14>MUST</bcp14> be discarded.
If the DHCPv4 Message option is present and correct, the 4o6RA <bcp14>MUST</bcp1 If the DHCPv4 message option is present and correct, the 4o6RA <bcp14>MUST</bcp1
4> extract the DHCPv4 4> extract the DHCPv4
message and forward the encapsulated DHCPv4-response to the requesting DHCPv4 message and forward the encapsulated DHCPv4-RESPONSE to the requesting DHCPv4
client, given that the encapsulated DHCPv4-response is correct and can be client, given that the encapsulated DHCPv4-RESPONSE is correct and can be
actually forwarded.</t> actually forwarded.</t>
<t>Layer-2 Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE messages <t>Layer 2 (L2) Relay Agents receiving DHCPV4-QUERY or DHCPV4-RESPONSE mes sages
<bcp14>MUST</bcp14> handle them as specified in <xref section="6" sectionFormat= "of" target="RFC6221"/>.</t> <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 <t>In any given environment, DHCPv6 servers to which DHCPV4-QUERY
requests are routed are expected to be compliant with 4o6 according requests are routed are expected to be compliant with 4o6 according
to <xref target="RFC7341"/>. No additional requirements on DHCPv6 servers are s et to <xref target="RFC7341"/>. No additional requirements on DHCPv6 servers are s et
by this specification.</t> by this specification.</t>
<section anchor="intermediate-relays"> <section anchor="intermediate-relays">
<name>Intermediate relays</name> <name>Intermediate Relays</name>
<t>Intermediate relays shall behave according to section 10 of <xref tar <t>Intermediate relays shall behave according to <xref section="10" sect
get="RFC7341"/>.</t> ionFormat="of" target="RFC7341"/>.</t>
</section> </section>
<section anchor="topology_considerations"> <section anchor="topology_considerations">
<name>4o6RA and Topology Discovery</name> <name>4o6RA and Topology Discovery</name>
<t>In some networks, the configuration of a host may depend on the topol ogy. <t>In some networks, the configuration of a host may depend on the topol ogy.
However, when a new host attaches to a network, it may be unaware 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> of the topology and, consequently, how it has to be configured.</t>
<t>DHCPv4 <xref target="RFC2131"/> and DHCPv6 <xref target="draft-ietf-d <t>DHCPv4 <xref target="RFC2131"/> and DHCPv6 <xref target="RFC9915"/> s
hc-rfc8415bis"/> specifications pecifications
describe how addresses can be allocated to clients based on network describe how addresses can typically be allocated to clients based on network
topology information provided by a DHCP relay, typically.</t> topology information provided by a DHCP relay.</t>
<t>Address/prefix allocation decisions are integral to the allocation of <t>Address/prefix allocation decisions are integral to the allocation of
addresses and prefixes in DHCP, as described in detail addresses and prefixes in DHCP, as described in detail
in <xref target="RFC7969"/>. This specification aims to guarantee that the 4o6RA does not in <xref target="RFC7969"/>. This specification aims to guarantee that the 4o6RA does not
break any legacy capability when used for topology discovery.</t> break any legacy capability when used for topology discovery.</t>
<t>Topology discovery as described in <xref target="RFC7969"/> differs b etween <t>Topology discovery as described in <xref target="RFC7969"/> differs b etween
IPv4 and IPv6:</t> IPv4 and IPv6 as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>IPv4: <t>IPv4: When using DHCP on IPv4, only the first Relay Agent <bcp14>
when using DHCP on IPv4 only the first Relay Agent <bcp14>SHOULD</bcp14> SHOULD</bcp14>
set the giaddr field (section 3.1 of <xref target="RFC7969"/>). Thus, in a set the giaddr field (<xref section="3.1" sectionFormat="of" target="RFC7969"/>)
network that has more than one Relay Agent only part of the topology . Thus, in a
network that has more than one Relay Agent, only part of the topology
is transported via DHCPv4.</t> is transported via DHCPv4.</t>
</li> </li>
<li> <li>
<t>IPv6: <t>IPv6: When using DHCPv6, all Relay Agents <bcp14>SHOULD</bcp14> s
when using DHCPv6, all Relay Agents <bcp14>SHOULD</bcp14> send end
link-address and Interface-ID options, that provide link-address and Interface-ID options that provide
information about the complete path information about the complete path
between the DHCPv6 client and the DHCPv6 server to the DHCPv6 server.</t> between the DHCPv6 client and the DHCPv6 server to the DHCPv6 server.</t>
</li> </li>
</ul> </ul>
<t>In Layer-2 networks, Lightweight DHCPv6 Relay Agents <xref target="RF C6221"/> <t>In Layer 2 networks, Lightweight DHCPv6 Relay Agents (LDRAs) <xref ta rget="RFC6221"/>
can be used.</t> can be used.</t>
<t>When provided, the topology information is available at the DHCPv6 <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 opti on.</t> server in the form of a sequence of the link-address field and Interface-ID opti on.</t>
<t>Then, topology information for the given IP address <t>Then, topology information for the given IP address
can be obtained from the DHCPv6 server and used for configuration can be obtained from the DHCPv6 server and used for configuration
or other purposes.</t> or other purposes.</t>
<t><xref target="RFC7341"/> enables the client to use DHCPv6 for topolog y discovery <t><xref target="RFC7341"/> enables the client to use DHCPv6 for topolog y discovery
even within a DHCPv4 context, as the DHCPv6 Relay Agent knows even within a DHCPv4 context, as the DHCPv6 Relay Agent knows
the interface where the encapsulated DHCP request is received. the interface where the encapsulated DHCP request is received.
As shown in <xref target="fig_4o6RA_RA"/>, however, the introduction of 4o6 at However, as shown in <xref target="fig_4o6RA_RA"/>, the introduction of 4o6 at
the edge of the IPv6 network hides the Layer-2 network from the DHCPv6 RA. the edge of the IPv6 network hides the Layer 2 network from the DHCPv6 RA.
As such, moving 4o6 to a intermediate node rather than performing it at the clie As such, moving 4o6 to an intermediate node rather than performing it at the cli
nt breaks ent breaks
the topology propagation, as 4o6RA-only solutions does not provide any interface the topology propagation, as 4o6RA-only solutions do not provide any interface
information in the encapsulated message.</t> information in the encapsulated message.</t>
<figure anchor="fig_4o6RA_RA"> <figure anchor="fig_4o6RA_RA">
<name>Broken topology information</name> <name>Broken Topology Information</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="208" width="576" viewBox="0 0 576 208" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="208" width="576" viewBox="0 0 576 208" class="diagr am" 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 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,48 L 80,64" fill="none" stroke="black"/>
<path d="M 80,128 L 80,144" 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 96,64 L 96,128" fill="none" stroke="black"/>
<path d="M 120,64 L 120,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 200,64 L 200,128" fill="none" stroke="black"/>
<path d="M 224,64 L 224,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,48 L 240,64" fill="none" stroke="black"/>
skipping to change at line 385 skipping to change at line 433
| | | | | Agent | | Agent | | | | | | | | Agent | | Agent | | |
+--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+ +--------+-+ +---------+ +-+---+---+ +--------+ +-+--------+
| | | | | | | |
'-----------------' '-------------------------' '-----------------' '-------------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In order to provide full topology information, it is <bcp14>RECOMMEND ED</bcp14> that <t>In order to provide full topology information, it is <bcp14>RECOMMEND ED</bcp14> that
any implementation of 4o6RA be combined any implementation of 4o6RA be combined
with an LDRA implementation <xref target="RFC6221"/> in a back-to-back structure , and that the with an LDRA implementation <xref target="RFC6221"/> in a back-to-back structure and that the
LDRA implementation includes a mechanism to obtain interface information that LDRA implementation includes a mechanism to obtain interface information that
can be used to provide the Interface-ID option to outgoing can be used to provide the Interface-ID option to outgoing
DHCPV4-QUERY messages, as specified in Section 5.3.2 of <xref target="RFC6221"/> .</t> DHCPV4-QUERY messages, as specified in <xref section="5.3.2" sectionFormat="of" target="RFC6221"/>.</t>
<t>The internal mechanisms to exchange interface information, <t>The internal mechanisms to exchange interface information,
their format and whether the interface information contains an indication that a their format, and whether the interface information contains an indication that
4o6RA a 4o6RA
is involved are out of the scope for this document.</t> is involved, are out of the scope for this document.</t>
<t>The resulting architecture is shown in <xref target="fig_4o6LDRA"/> w here <t>The resulting architecture is shown in <xref target="fig_4o6LDRA"/> w here
the Relay Agent is implementing 4o6RA and LDRA, and has an internal interface to the Relay Agent is implementing 4o6RA and LDRA and has an internal interface to
propagate topology information from 4o6RA to LDRA.</t> propagate topology information from 4o6RA to LDRA.</t>
<figure anchor="fig_4o6LDRA"> <figure anchor="fig_4o6LDRA">
<name>Topology information preserved with LDRA</name> <name>Topology Information Preserved with LDRA</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="224" width="528" viewBox="0 0 528 224" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="224" width="528" viewBox="0 0 528 224" class="diagr am" 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 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,48 L 80,80" fill="none" stroke="black"/>
<path d="M 80,144 L 80,160" 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 96,80 L 96,144" fill="none" stroke="black"/>
<path d="M 120,80 L 120,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 200,80 L 200,144" fill="none" stroke="black"/>
<path d="M 224,80 L 224,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,48 L 240,80" fill="none" stroke="black"/>
skipping to change at line 445 skipping to change at line 493
<path d="M 96,176 C 87.16936,176 80,168.83064 80,160" 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 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 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"/> <path d="M 472,176 C 480.83064,176 488,168.83064 488,160" fill=" none" stroke="black"/>
<g class="text"> <g class="text">
<text x="108" y="52">L2</text> <text x="108" y="52">L2</text>
<text x="152" y="52">Network</text> <text x="152" y="52">Network</text>
<text x="196" y="52">or</text> <text x="196" y="52">or</text>
<text x="348" y="52">IPv6</text> <text x="348" y="52">IPv6</text>
<text x="400" y="52">Network</text> <text x="400" y="52">Network</text>
<text x="136" y="68">IPv6-only</text> <text x="136" y="68">IPv6-Only</text>
<text x="196" y="68">link</text> <text x="196" y="68">Link</text>
<text x="52" y="100">DHCPv4</text> <text x="52" y="100">DHCPv4</text>
<text x="156" y="100">L2</text> <text x="156" y="100">L2</text>
<text x="256" y="100">4o6</text> <text x="256" y="100">4o6</text>
<text x="332" y="100">LDRA</text> <text x="332" y="100">LDRA</text>
<text x="460" y="100">DHCP</text> <text x="460" y="100">DHCP</text>
<text x="496" y="100">4o6</text> <text x="496" y="100">4o6</text>
<text x="52" y="116">Client</text> <text x="52" y="116">Client</text>
<text x="156" y="116">Switch</text> <text x="156" y="116">Switch</text>
<text x="264" y="116">Relay</text> <text x="264" y="116">Relay</text>
<text x="336" y="116">RFC6221</text> <text x="320" y="116">RFC</text>
<text x="356" y="116">6221</text>
<text x="476" y="116">Server</text> <text x="476" y="116">Server</text>
<text x="264" y="132">Agent</text> <text x="264" y="132">Agent</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
.-----------------. .------------------------. .-----------------. .------------------------.
| L2 Network or | | IPv6 Network | | L2 Network or | | IPv6 Network |
| IPv6-only link | | | | IPv6-Only Link | | |
+--------+-+ +---------+ +-+---+--+---------+ +------+---+ +--------+-+ +---------+ +-+---+--+---------+ +------+---+
| DHCPv4 | | L2 | | 4o6 | LDRA | | DHCP 4o6 | | DHCPv4 | | L2 | | 4o6 | LDRA | | DHCP 4o6 |
| Client +--+ Switch +--+ Relay + RFC6221 +------+ Server | | Client +--+ Switch +--+ Relay + RFC 6221+------+ Server |
| | | | | Agent | | | | | | | | | Agent | | | |
+--------+-+ +---------+ +-+---+--+---------+ +------+---+ +--------+-+ +---------+ +-+---+--+---------+ +------+---+
| | | | | | | |
'-----------------' '------------------------' '-----------------' '------------------------'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In a simple case, where the same node hosts the 4o6RA and the DHCP4o6 server, <t>In a simple case, where the same node hosts the 4o6RA and the DHCP 4o 6 server,
it might be enough to only use 4o6RA, as shown in <xref target="fig_4o6RAserver" />.</t> it might be enough to only use 4o6RA, as shown in <xref target="fig_4o6RAserver" />.</t>
<figure anchor="fig_4o6RAserver"> <!-- [rfced] Per Section 3.6 of RFC 7322 ("RFC Style Guide"), abbreviati
<name>Topology information preserved by 4o6 Relay Agent in DHCP server ons
</name> 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".
-->
<figure anchor="fig_4o6RAserver">
<name>Topology Information Preserved by 4o6 Relay Agent in DHCP Server
</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="208" width="344" viewBox="0 0 344 208" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="208" width="344" viewBox="0 0 344 208" class="diagr am" 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 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,48 L 80,64" fill="none" stroke="black"/>
<path d="M 80,128 L 80,144" 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 96,64 L 96,128" fill="none" stroke="black"/>
<path d="M 176,64 L 176,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,48 L 192,64" fill="none" stroke="black"/>
<path d="M 192,128 L 192,144" 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 248,64 L 248,128" fill="none" stroke="black"/>
skipping to change at line 543 skipping to change at line 609
</section> </section>
</section> </section>
<section anchor="deployment-considerations"> <section anchor="deployment-considerations">
<name>Deployment Considerations</name> <name>Deployment Considerations</name>
<t>As clients are unaware of the presence of 4o6RA, the network <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 deployment needs to ensure that all DHCPv4 broadcast and unicast messages to and
from clients are steered via a 4o6RA. from clients are steered via a 4o6RA.
This can be achieved by placing the 4o6RA in a central position 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 that can intercept all traffic from the clients or by using Network Address
Translation (NAT) with the 4o6RA address for unicast messages.</t> Translation (NAT) with the 4o6RA address for unicast messages.</t>
</section> <!-- [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 [RF
C7341];
therefore, the security considerations of that document still apply.
-->
</section>
<section anchor="seccons"> <section anchor="seccons">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>This document specifies the applicability of 4o6 DHCP in a scenario whe re legacy IPv4 clients are <t>This document specifies the applicability of DHCP 4o6 in a scenario whe re legacy IPv4 clients are
connected to 4o6 DHCP Relay Agents that perform the encapsulation and decapsulat ion. This document connected to 4o6 DHCP Relay Agents that perform the encapsulation and decapsulat ion. This document
does not change anything else in the 4o6 DHCP specification and therefore the does not change anything else in the DHCP 4o6 specification; therefore, the
security considerations of <xref target="RFC7341"/> still apply. security considerations of <xref target="RFC7341"/> still apply.
Specifically, since the legacy IPv4 client is not aware of the encapsulation and decapsulation, 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 in the security 4o6RA has to provide the protections that are specified in the security
considerations in <xref section="12" sectionFormat="of" target="RFC7341"/>.</t> considerations in <xref section="12" sectionFormat="of" target="RFC7341"/>.</t>
<t>The mechanisms defined here differ from <xref target="RFC7341"/> as the y allow the DHCP client <t>The mechanisms defined here differ from <xref target="RFC7341"/> as the y allow the DHCP client
to send and receive DHCPv4 messages, whereas in <xref target="RFC7341"/> the cli ent to send and receive DHCPv4 messages, whereas in <xref target="RFC7341"/>, the cl ient
only sends DHCPv6 messages. This makes it possible that in improperly configured only sends DHCPv6 messages. This makes it possible that in improperly configured
networks where the client is located on the same Layer-2 scope of a DHCPv4 serve r, networks where the client is located on the same Layer 2 scope of a DHCPv4 serve r,
DHCPv4 messages could reach a DHCPv4 server without using the 4o6RA. DHCPv4 messages could reach a DHCPv4 server without using the 4o6RA.
While this can cause erroneous state in both clients and servers While this can cause erroneous state in both clients and servers
and potentially even lead to misconfigurations that impact reachability, and potentially even lead to misconfigurations that impact reachability,
this is seen as a deployment error rather than a security concern. 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 netw ork, Further, even though this mechanism may be used for attacks from within the netw ork,
this is not a new concern introduced by this specification.</t> this is not a new concern introduced by this specification.</t>
<t>More generally, legacy IPv4 clients are not aware of this mechanism, ho wever, even <t>More generally, legacy IPv4 clients are not aware of this mechanism; ho wever, even
when DHCP 4o6 is used, the client does not have any control about the when DHCP 4o6 is used, the client does not have any control about the
information provided by the Relay agent. information provided by the Relay Agent.
As such this change does not raise any additional security concerns.</t> As such, this change does not raise any additional security concerns.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC6221"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<front> 221.xml"/>
<title>Lightweight DHCPv6 Relay Agent</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="D. Miles" initials="D." role="editor" surname="Mil 341.xml"/>
es"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="S. Ooghe" initials="S." surname="Ooghe"/> 915.xml"/>
<author fullname="W. Dec" initials="W." surname="Dec"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/> 119.xml"/>
<author fullname="A. Kavanagh" initials="A." surname="Kavanagh"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<date month="May" year="2011"/> 174.xml"/>
<abstract>
<t>This document proposes a Lightweight DHCPv6 Relay Agent (LDRA)
that is used to insert relay agent options in DHCPv6 message exchanges identifyi
ng client-facing interfaces. The LDRA can be implemented in existing access node
s (such as Digital Subscriber Link Access Multiplexers (DSLAMs) and Ethernet swi
tches) 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 I
Pv6. Users require IPv4 configuration even if the uplink to their service provid
er supports IPv6 only. This document describes a mechanism for obtaining IPv4 co
nfiguration information dynamically in IPv6 networks by carrying DHCPv4 messages
over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are d
efined 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://datatracke
r.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</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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</ti
tle>
<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 protoco
l 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>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC951"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
<front> 951.xml"/>
<title>Bootstrap Protocol</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<author fullname="W.J. Croft" initials="W.J." surname="Croft"/> 542.xml"/>
<author fullname="J. Gilmore" initials="J." surname="Gilmore"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<date month="September" year="1985"/> 131.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<t>This RFC describes an IP/UDP bootstrap protocol (BOOTP) which a 132.xml"/>
llows a diskless client machine to discover its own IP address, the address of a <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
server host, and the name of a file to be loaded into memory and executed. The 969.xml"/>
bootstrap operation can be thought of as consisting of TWO PHASES. This RFC desc
ribes the first phase, which could be labeled `address determination and bootfil
e selection'. After this address and filename information is obtained, control p
asses to the second phase of the bootstrap where a file transfer occurs. The fil
e 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 pr
otocols 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</tit
le>
<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 pro
vided for the behavior of "BOOTP relay agents" (originally called "BOOTP forward
ing agents"). The client behavior description also suffered in certain ways. Thi
s memo attempts to clarify and strengthen the specification in these areas. [STA
NDARDS-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 frame
work for passing configuration information to hosts on a TCPIP network. DHCP is
based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allo
cation of reusable network addresses and additional configuration options. [STAN
DARDS-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 i
s also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRAC
K]</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 Topolo
gy</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>
</references> </references>
</references> </references>
<?line 379?> <?line 467?>
<!-- [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 Uni
ts (BBUs)"
as seen in the text below? If so, please note that we would also update instance
s of
"BB"/"BBs" to "BBU"/"BBUs" accordingly throughout the rest of this section as we
ll.
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.
-->
<section anchor="usecase"> <section anchor="usecase">
<name>Example Use Case: Topology Discovery for IPv4-only Radio Unit in 3GP <name>Example Use Case: Topology Discovery for IPv4-Only Radio Unit in 3GP
P RAN with Switched Fronthaul</name> P RAN with Switched Fronthaul</name>
<t>In 3GPP mobile network architecture, the User Equipments (UE) are conne <t>In 3GPP mobile network architecture, the User Equipment (UE) is connect
cted ed
via Radio Access Network (RAN). RAN is built up with Baseband Units (BB) via Radio Access Network (RAN). RAN is built up with Baseband Units (BBs)
and Radio Units (RU). Radio Fronthaul Network (FH) connects RU and BB, each of and Radio Units (RUs). Radio Fronthaul Network (FH) connects RUs and BBs. Each
RU and BB is an IP host, they may support IPv4 only, IPv6 only or both RU and BB is an IP host, and they may support IPv4 only, IPv6 only, or both,
depending on the vendor and the model. depending on the vendor and the model.
Each RU is unique as it is tied to a set of antennas, and each antenna Each RU is unique as it is tied to a set of antennas, and each antenna
is serving a specific Cell and Sector. is serving a specific Cell and Sector.
Each RU is configured by the BB depending on the Cell and Sectors it serves. 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 and antenna However, that dependency is only specified by the cabling between RUs and antenn
s. as.
BB can be cabled to RU directly or via a Layer-2 switched network.</t> BBs can be cabled to RUs directly or via a Layer 2 switched network.</t>
<figure anchor="bb_connected_to_ru"> <figure anchor="bb_connected_to_ru">
<name>3GPP RAN where RU are cabled directly to BB</name> <name>3GPP RAN Where RUs Are Cabled Directly to BB</name>
<artset> <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"> <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,32 L 8,80" fill="none" stroke="black"/>
<path d="M 8,112 L 8,160" 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,208 L 8,256" fill="none" stroke="black"/>
<path d="M 8,288 L 8,336" 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,32 L 80,80" fill="none" stroke="black"/>
<path d="M 80,112 L 80,160" 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,208 L 80,256" fill="none" stroke="black"/>
<path d="M 80,288 L 80,336" fill="none" stroke="black"/> <path d="M 80,288 L 80,336" fill="none" stroke="black"/>
skipping to change at line 797 skipping to change at line 793
| | | +-----------+ | | | +-----------+
+--------+ | +--------+ |
| |
+--------+ | +--------+ |
| RU2 +-----+ | RU2 +-----+
| | | |
+--------+ +--------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In <xref target="bb_connected_to_ru"/> BB is directly cabled to a set o f RUs, the <t>In <xref target="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 BB can recognize the relationship between RUs and Cell/Sectors
based on the cabling between the RUs and antennas.</t> based on the cabling between the RUs and antennas.</t>
<t>When BBs and RUs are connected via a Layer-2 switched network, <t>When BBs and RUs are connected via a Layer 2 switched network,
the added level of complexity requires the BBs to have a deeper the added level of complexity requires the BBs to have a deeper
knowledge of the topology in order to properly configure the RUs, knowledge of the topology in order to properly configure the RUs,
involving knowledge of all the cabling in the switched network.</t> involving knowledge of all the cabling in the switched network.</t>
<t>Examples for switched networks are shown in section 3 of <xref target=" RFC7969"/> <t>Examples for switched networks are shown in <xref section="3" sectionFo rmat="of" target="RFC7969"/>
and demonstrate the different levels of complexity. and demonstrate the different levels of complexity.
An example of a FH is depicted in <xref target="l2_switched_fh"/>.</t> An example of a FH is depicted in <xref target="l2_switched_fh"/>.</t>
<figure anchor="l2_switched_fh"> <figure anchor="l2_switched_fh">
<name>3GPP RAN with Layer-2 Switched Fronthaul Example</name> <name>3GPP RAN with Layer 2 Switched Fronthaul Example</name>
<artset> <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"> <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,32 L 8,80" fill="none" stroke="black"/>
<path d="M 8,112 L 8,160" 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,192 L 8,240" fill="none" stroke="black"/>
<path d="M 8,272 L 8,320" 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,32 L 80,80" fill="none" stroke="black"/>
<path d="M 80,112 L 80,160" 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,192 L 80,240" fill="none" stroke="black"/>
<path d="M 80,272 L 80,320" fill="none" stroke="black"/> <path d="M 80,272 L 80,320" fill="none" stroke="black"/>
skipping to change at line 873 skipping to change at line 869
<path d="M 152,304 L 224,304" 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 296,304 L 392,304" fill="none" stroke="black"/>
<path d="M 8,320 L 80,320" fill="none" stroke="black"/> <path d="M 8,320 L 80,320" fill="none" stroke="black"/>
<g class="text"> <g class="text">
<text x="40" y="52">RU1</text> <text x="40" y="52">RU1</text>
<text x="132" y="52">P1</text> <text x="132" y="52">P1</text>
<text x="196" y="68">L2RA</text> <text x="196" y="68">L2RA</text>
<text x="364" y="84">L3RA</text> <text x="364" y="84">L3RA</text>
<text x="180" y="100">L2</text> <text x="180" y="100">L2</text>
<text x="132" y="116">P2</text> <text x="132" y="116">P2</text>
<text x="188" y="116">switch</text> <text x="188" y="116">Switch</text>
<text x="40" y="132">RU2</text> <text x="40" y="132">RU2</text>
<text x="180" y="132">#1</text> <text x="180" y="132">#1</text>
<text x="348" y="132">Router</text> <text x="348" y="132">Router</text>
<text x="484" y="180">DHCP</text> <text x="484" y="180">DHCP</text>
<text x="492" y="196">Server</text> <text x="492" y="196">Server</text>
<text x="40" y="212">RU3</text> <text x="40" y="212">RU3</text>
<text x="132" y="212">P1</text> <text x="132" y="212">P1</text>
<text x="492" y="212">#1</text> <text x="492" y="212">#1</text>
<text x="196" y="228">L2RA</text> <text x="196" y="228">L2RA</text>
<text x="180" y="260">L2</text> <text x="180" y="260">L2</text>
<text x="340" y="260">Baseband</text> <text x="340" y="260">Baseband</text>
<text x="132" y="276">P2</text> <text x="132" y="276">P2</text>
<text x="188" y="276">switch</text> <text x="188" y="276">Switch</text>
<text x="340" y="276">Unit</text> <text x="340" y="276">Unit</text>
<text x="40" y="292">RU4</text> <text x="40" y="292">RU4</text>
<text x="180" y="292">#2</text> <text x="180" y="292">#2</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
+--------+ +--------+
| RU1 | P1 +-+------+ | | | RU1 | P1 +-+------+ | |
| +--------| | L2RA | | +----+------+ | | +--------| | L2RA | | +----+------+ |
+--------+ | +------+ | | | L3RA | | +--------+ | +------+ | | | L3RA | |
| L2 | +--| +------+ | | L2 | +--| +------+ |
+--------+ P2 | switch | | | | | +--------+ P2 | Switch | | | | |
| RU2 +--------| #1 +-----| | Router +----| | RU2 +--------| #1 +-----| | Router +----|
| | +--------+ | +-----------+ | +---------+ | | +--------+ | +-----------+ | +---------+
+--------+ | | | | +--------+ | | | |
| +--| DHCP | | +--| DHCP |
+--------+ | | | Server | +--------+ | | | Server |
| RU3 | P1 +-+------+ | | | #1 | | RU3 | P1 +-+------+ | | | #1 |
| +--------| | L2RA | | +-----------+ | +---------+ | +--------| | L2RA | | +-----------+ | +---------+
+--------+ | +------+ | | | | +--------+ | +------+ | | | |
| L2 | +--| Baseband | | | L2 | +--| Baseband | |
+--------+ P2 | switch | | | Unit | | +--------+ P2 | Switch | | | Unit | |
| RU4 +--------| #2 +-----| | +----| | RU4 +--------| #2 +-----| | +----|
| | +--------+ | +-----------+ | | | +--------+ | +-----------+ |
+--------+ | | +--------+ | |
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>If IPv6 is used and all RU are capable of DHCPv6 in <xref target="l2_sw itched_fh"/>, <t>If IPv6 is used and all RUs are capable of DHCPv6 in <xref target="l2_s witched_fh"/>,
DHCP topology knowledge can be used for solving the RU configuration problem. DHCP topology knowledge can be used for solving the RU configuration problem.
Such solution would use the topology discovery mechanisms described in section 3 Such solution would use the topology discovery mechanisms described in <xref sec
.2 tion="3.2" sectionFormat="of" target="RFC7969"/>.</t>
of <xref target="RFC7969"/>.</t> <t>If RUs are capable of IPv4 only but implement a 4o6 client according to
<t>If RU are capable of IPv4 only but implement a 4o6 client according to <xref target="RFC7341"/>, the same topology discovery mechanisms are applicable
<xref target="RFC7341"/>, the same topology discovery mechanisms are applicable. .</t>
</t> <t>If RUs are capable of IPv4 only and cannot implement a 4o6 client accor
<t>If RU are capable of IPV4 only and cannot implement a 4o6 client accord ding to <xref target="RFC7341"/>,
ing to <xref target="RFC7341"/>, the topology discovery mechanisms described in <xref section="3.2" sectionFormat
the topology discovery mechanisms described in section 3.2 ="of" target="RFC7969"/> can be used by introducing 4o6RA in the switches as des
of <xref target="RFC7969"/> can be used by introducing 4o6RA in the switches as cribed in this document.</t>
decribed in this document.</t>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The authors would also like to acknowledge interesting discussions in <t>The authors would like to acknowledge interesting discussions in
this problem space with Sarah Gannon, Ines Ramadza, and Siddharth Sharma this problem space with <contact fullname="Sarah Gannon"/>, <contact fullname="I
as well as reviews and comments provided by Eric Vyncke, Mohamed Boucadair, nes Ramadza"/>, and <contact fullname="Siddharth Sharma"/>,
David Lamparter, Michael Richardson, Alan DeKok, Dale Worley, Paul Wouters, as well as reviews and comments provided by <contact fullname="Éric Vyncke"/>, <
Deb Cooley, Erik Kline, Ketan Talaulikar, Mike Bishop and Roman Danyliw.</t> contact fullname="Mohamed Boucadair"/>,
</section> <contact fullname="David Lamparter"/>, <contact fullname="Michael Richardson"/>,
<contact fullname="Alan DeKok"/>, <contact fullname="Dale Worley"/>, <contact f
ullname="Paul Wouters"/>,
<contact fullname="Deb Cooley"/>, <contact fullname="Erik Kline"/>, <contact ful
lname="Ketan Talaulikar"/>, <contact fullname="Mike Bishop"/>, and <contact full
name="Roman Danyliw"/>.</t>
<!-- [rfced] Terminology and Abbreviations:
a) We note that the phrase "4o6" appears a few times by itself throughout this
document. For consistency and context, should these instances be updated to "DHC
P 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. -->
</section>
</back> </back>
<!-- ##markdown-source: <!-- ##markdown-source:
H4sIAAAAAAAAA61c63LcNpb+j6fAyj/GHrfakewosXYyM7o5VuKLRpKTSm1t H4sIAK3wlWkAA60823IbN5bvrOI/YOiHtcYUHcmKEyuZeChZnmjii0aXcaVc
udAkuhsjNtEhSMkd23mWfZD9tftiey4ACLLZkryZrkrcTRLAwbmf74Da3t4W LhfYDZIYNbt7Gt2SObbnff9iP2Sfdn5szwVAoy+UZCeqSkw20cDBud+A7e3t
takLvS+3jl8enV0/27bXutqm73vyxtRzea4LtZIHM13W8qJZLm1Vbwk1mVT6 4aDUZaL2xejZz4cnV3siu1KFoM+PxbUul+JUJXItpguVluKsyvOsKEfDgZzN
2o+Sz+xe+tiWyFStZ7Za7UtX50LkNivVAhbJKzWtt42up9v5PMP/lmFJ+r63 CnVlXxN72eNwHPyeVquZKvbFkye73w8HkSzVIivW+8KU8XAQZ1EqV7BoXMh5
Xantr/aEayYL45yxZb1awrjTk8sXomwWE13tixwm3xeZLZ0uXeP2ZV01WgAx ua1VOd+OlxH+l1/tbSMI/PnxdiGHA1PNVtoYnaXlOoe3jo/On8MkMOe+eK5m
T4WqtAKiTstaV6UGQm5sdTWrbLNEUldAhMnkS+tqeWTLqZk1laphkS1xpVfw RSWLtdj9ZvcxLJSlRqWmMvuiLCo1HOi8oI+m3P3mmyff7A4Hud4Xb8ssGguz
aL4v5LZESsS1LhtYRcr7jJaSydz6GZYz5Ux+j4Pw+gw42EzgzsJU/1RXT5gB XhVqbuAD7Ak/vRsOYEuPhoNEpot9oVLYZ6Ek7PL41Tls6jorLhdFVuXwBOCD
G/e+JYRq6rmtkBAYLqUpYYNHY3lmq6mpDF1jXh4VqsmN7dyx1UyV5jcia1+e J5dqDQ/j/eFAbAsEeTiAd6pymRX0DP6DP50CPIcTcZIVc11ofsgYOExkFeus
VCZzzpZ0Sy+UKfZlxqPGSx71d+2fGWd20VnzYix/rIybl6pMFr1oKu3m3Tvd +VNWLGSq/yVL2PK+OCp0ZEyW8m9qJXWyLyJ+b5Lze39WdtAkylathc8m4pdC
RY+My2y6oqMh4ys/5O8zvLy23A9jeVBdXdlkrR9UZZKLd+/tnzBgrHDA5m29 m2Uq03Dls6pQZtn6qbnyoTZR1ljW0EuTS/vSnxf4uGfNv07EtLi8zMIF/yoL
hm3973/PC31jyjxZ7DXKp3/r7iVJrOOrRvth3YVFaasFjL4mTZLnL472dnd3 HT69wy7/Aa9MJL5y0wZfwgb/87/LRF3rNA5XfKmLf8jOb3dYd4UvTi4rZV9s
wvdvnj6D7/ijZxbVNPv22c7XE+PoUfjUqprpGtRoXtdLt//kCdiAqiuVXelq rQ7snRUrmOBK7dN7p88PH+/u7vgv3z3aq788ebLz7T6+pNN557Vvnnxbj9z5
jOPGQOoTMLMnG6d6shXmCva+UaHlWWVrm9lCTm0lT9ETPGSP8ChMQjYof2hK dm/Xf9ndebQTfql/+e7J4yc04XCwvb0t5MyUhYxK/H6+1EaAeFUrFNdYmajQ
LXe/2v1aCFNO+3t9/nXc6s7Xz3bD992dpzvJ93j9m+d7z4Ed29vbUk0cbq4W M2WEFCsVLWHbZiUACJGqEpnZAE+jjCdqIaO1OD5B6UuTNbCXhgmMKDNRGSWM
4nJunIR9NQt0P7l2WWUm2kklFzqbg3DcgogEY0dTd4JcVqFnKlsh5WBgZbEC Kq50BPPkRXalYxWL2Xo46NEYOoWlAk0wGQ4AYIH4ECZXkZ5rmKVcKpo2m4v+
rTcw3snaysZp6XR1bTKYZlnZa5PrXE5WYsD/mRIWShzbWHixSbfUmZkamALn OXAAgyAQnEl7Y/VUEhbMASoZLcVMGoAsS4VfslxKQItMkuzaNAHDnelVniia
s1M5PLqea7+2RDrGvf20s6igENsT5YAetQTSVDaHGVQtVFHYG9elBfdiFstC D9fzikylkcxNlRCDwAKosFT4qAZ7pYyRCwADYLbQ+0cwcKaWMpnjeOmxxdua
00y4UHTFuszU0jUFC1OBMuc6vRLJBSY6p2awPtDqqY6X4MGJnqtiis8rzx6/ 1ORb6ThOFH67J47TssjiKqJlPt7TwdfPOOLjR8tcnz83iAv0Tw1q5haZI1kU
m7FgQS1MnhdaiAcSXG5l8yajBT4+MMnPz0J8/Oi39/lzR4gg5dJhROmJM1NV a50uHLz0PjLWZ5jOQ1oZP+QxD0GWhSVwingNsqQjpjzqYBg7HMCWkFmEjGNQ
tUJH6lel8ag4nz+LSGDj4hN78MRGzYc1cc7c6zvJHEMLjBawNdQSqfIcvJRD CIYIAagHPFoy7m1bGkUCdPJcL6qCkZfLAmSzVAXwnoyKzBic6TGznWPLiTgH
ospcWmBnFdb2Qspk1rGRparAcUCccUJllXWODIXVLWjjWF6CXHK9LOyKxATL isQqT7I1EQjWC/deqH9WGhYGfUQGCfDPCPaMi+DImrCwMeRhVQDif86uFXwa
payo9K+NgXXBR1JcBTEQn6O+IjGqlS7sE1UXbF68tDcavoykAeEEHQPd0hAj Cw10cWwG3KXAYsXI28TEy8yUxD/EgW4hAnYPIIfpI5mmWSmUNBoGzBRAlScy
c9Ro0t052jaqEKlfWIZIfSZw8kyVpa2lVs7A/YkGkpaFymA8cKxZopnn8uHN QhYsRJWjfYrF/eulBtaMsiqJcUxcKWQ9ma6djcS9lUC1VEcywVdnSA9AKswn
3IAqZrYpcnwmbzRqnypXPibjvmoQYGkyVeDICcoG+AnTKXCG7tEIqADqolrn QeWYrTHAAfB5Po8z2DkszQaJWOnHPwAnvS3msPo7cZLAiwjOlVbXhIJSfShh
FnYNK1OARm26MAtTqKpYjWi3genEa0fy8wxITAD5BnMpJ1+Z2by+0fh/sf6c dRCDiXijxLUqQABTOUsImDloODF68eh0OkKxjAmbb1u2Geb+fm/n25k278T9
fPjq+PzgEbMePTCwfnBCePApPChuV6bcIuVIk3ZaE7lLkL+ZmMLUK+QMaDKY NLsWeTVLwArAcGlI4pBptiYCwXld6IVOZUJaCpTWmV7pRBbJekzgONYgjjDE
RXBDrEcjwVoF0ihbww0aTHbbcRjjvvNLnEXZ0SL2GM4WDSkmiRvkCpIScR1W ZpZIgYQicWGz0tAML/RiWV4r/H/PWHH/xbPT6ZZ4axXxO9E7Jc10HzcKQ2/Y
CIN50ULnBsQKe8h1y0EHjjObo9lXEpIX1OsROVP4LpdNTZSCxIPOLoj/sJxX X5whehEuZZQikHNgVD3TiS7XgDKaCOQMBNfpTub6sZUBYJy01i9OvEi9NNQb
1bF8A2zRN2heFDtoJv2hhhyNRAipGdzXoJr/DsHC1VrlXikG3SFOha41g82R o2t7+yf85zdhKcSQVTa9KCIxQhyBGPXOaBFklY3VBLdipB8boCi+DB1dGxao
+NMd0xbZKYo1p7jUFYaiO1yi7LpETxEosuiI4MEDebBcFqCIXroXmV1qcHAq evDTkoqUiNf0oVIgYQWhBEYHW+sWY3kGTaqKlYo1CCXsJFY13gxYwGiJCrsQ
vfoZZaVbH+aik8tZqOkucSRpCS3U9Slz2C36JLRbx9tEnuHTlc40BFcUfuqx 4NuhZhqzWYQvwOUlwQsC67TOitAOi1tdMxGvADsgaSCe4FdmCU0FEgeOKFEO
5M1co6XTTtk5hKjdcZvoG9DewCCByAloZw5SzGogZVpZ5hauOpYvmgoVdQHq fEj4XYFq+QGdAFMqGVuZ7t0mzoXmMUIpRrJ3dskWDdRQ26TlqkAf4xaDJpr2
PYqXcXhT0rg07gi/sPc/uBvMAlgQqcRAwwxNAo+UsCzvye+FnKbwTnMsDxvy zIIEigiigSYt7t0T0zxPgAktpc+iLFdgmmT49DOTTdXWx3jzFDOFw73iu8Qz
eKAv6DG6jq/Vbh+6++57sgIxQFAJkkxkEtSLZJIQh2LGBOga7ZFUFdTjWE9N tFjTOixhz2ReUP8a3i3iDocXKlLgO6HND42PuF4q1Ni0X9byhLXjlsVDHU9a
aeg3C3dqUd/QCtCGvGsGx1+uFqzcjRuQNiQ0f6YdYJZzOiXHQX7gxjjdUjRi E/QqgInKLwZyRiUAMy8yRhouOxHPqwL5dgXsPvaP8f1aaXoGQyoEpoc2hG4e
NlZ6CnaHnPGxBxZ5Ej3VOMx1/YxyJhqiUNeA1GRXLPDkaYlZSeDjQ5gPLOIR EyQg3Ri5TdM0MCaFhXlbdjtkAcEosAmcCG+mEBKFb8mmKasZ3nplbZM8WwNB
TYEbU1U2N+C96yYIHFgLEQDT9hFt01/zZt1hI9wKpPSyn6jvXU4zTanNekKA wDHwhA3I4/iNyBMA2bUmZ4rdkV1S5nJLvASGuwYqxP+oDFtYXaqV8XQGq0Bb
aSRuUJBML2uKX0VBkaXD/UgI0Fage5rN6Ylc15CRAzfMFJiIc05AobQmGhf7 BzIrWZA1TYCuM1VaCxer4inONfNzreQlKRXgd3qbJ8RgDr4Ry6D+I6Z/2mdf
8vDt28szJgYSU1BJ+oqJ6efPI78BHJXaTPhOj5BW3CPZoE0mAWkwzoAQKCZ1 /igINRAazklPkda51kbV+xwzkSDMAwFH8KxLBOLwMCvY+xcWwZPmtFd7+/yy
N1+2DjNs3FZmZkqIqgOzdILkiAwKuYRTwkMgil1OR3LN2W7iHLtec9qUPnFr RLYGa8lYe2s5611neMOdvQ+sCFK4tU8+jSyiJewuKivHWkA8wDPGVWN2NhkS
I+Qm/elvA3Qp7OM8qm/PKaPNRp/haF8wDIe0CaBa06zEjDBDQF2FMl1ine7k +5NVKA1yeafGhsp2ISdfboa3lqht+EKdgUAByYi5AN2RyksmWEJuyVJZtJPT
1ut3F5dbI/5XvnlL389P/vHu9PzkGL9fvDx49Sp+Ef6Ji5dv3706br+1I4/e x9N6oADcBJXkYkkDY1VC7AQY0nNAMShhMEaKgF3ti4PXr89PQsAg7HlHHzDm
vn598uaYB8NV2bkktl4f/LLFSrD19uzy9O2bg1dbA869IgcJSRLF2mWl0dUp eTd2iPM4dZ/wN9RYvEc/w2bjHWz2Np8BCEM2MUBCWuttkpqaFpllub6ZGpZ6
JzoB4fDo7H/+awf987+Rgu08J2XDH9/ufPMMfqBX59VIgvwT+LYSED60qoJ5 TLyPSBMwAsjjZtllHzdWHEoF2rqpxudVyhLnvZmbGay9J2A22tSpZ3XZcYJo
QAwztSJjAP7N7U0p0XOi8P4DOfOf+/Ivk2y58+yv/gJuuHMx8KxzkXi2fmVt U6A9vBbjoAytRR1LyA7fBVqcYDpRxRIMiRNDlkG7wGm/pPkob6OkToLZUPR6
MDNx4NLAMpGbnes9TnfpPfil8zvwPbn4l78V4Pvk9s63f/urQD9+l8ayuvZz 57tNFvsE0RnErX2Hg3rO8i6yeYNQhqxyg2x2hfK+KqPJVuAFYhx4mKVX6CiR
K+UcfOG8g6LQCFle6aSE5JCM8o0hTJCm+xGs5WmGvUfyKyCxRR2gOBUKT0zu 94DcjzvV9N2ZWi+XAj0bG/BQUk5bhxHdDuvON0lH5Pq4f2VyiFY+s7MIz75e
bAzhnIPFiZyum2U/NyLHkLuB7NYxTLfughOdoNAAicZ72j4Z9++//66Uu54J e4Zq01INp+uhU2COg9GbyXRHpXmLtnTr9JOkbf06OpLBuKOavKN+BOvXUJA4
X9HTZ7zdfsZSbrqTDPnUeerThu/wS8jHYfzj7cd46dUu/A++JzPTHWJd585j 4iDLSkzl5OLEziHuk+K0XjvmisCNoc+oNtGl4I1ZZ936Oe4zDaiVZxja00bv
gbN50cLXN55TtITnCC/Z3omp3ycafMQZSksErpRqRvfOBWcbfvD6lvAbsZ0Y FFM1d9/Uj1+rGGFp1IxiF9bY3RJfqBaDCCbgoQZtG9uw+hD3sUknblKG4DZ9
2r+zec/0Gdjz+p3H/z8mt58/JWv8qfNY5w5pgvi4Lx9E/WCI6LutgyQzkCcf gTZEVr1U4NCAi2PE6OXF2flozP+KV6/p8+nR3y6OT4+e4eezn6cvXvgPAzvi
FHpw3vWrtrLxnN0C0yDWb6vCzMrvtjKsOqqtz5vLGAwDnbxcrOflm3I272R9 7OfXFy+e1Z/qNw9fv3x59OoZvwxPRePRYPRy+uuI6T16fXJ+/PrV9MWox/ku
OIu5SCrRWL1wxRLqF0wHPbwRy+oW1jj1Dp3KDs5Ym2VI1vuFhs9AKT9pCg7R yH2dKY6J8kKVFMIPGg77weHJ//3PDrrPfyBe2nlCfIVfvt/5bg++oNPNqxH5
AlUulPMheeoUgkmxjtmguqGYQSGSLk40kkrpbi6ujQrJPU3M/mMsDmIUBXGp +CugbT0I/b4E/NNcl5KkARC4zK5Tgf7sZDD441vEzLt98eMsynf2frIPcMON
DD2TSx/kNUYUIyAIEQscyJLz1k7VIbiaSquSNKcnvl9ozg++xrQkyeqBcgg+ hw5njYeEs+6TzsuMxJ5HPct4bDaetzDdhHf6a+O7w3vw8MenCSg/sb3z/dOf
lkYbzukjWeBjOlTW6soLvbKFDvlNuwq4QhB2v3IYCeYK3oVc3GAFQmgOQi8L rHa/G8N2Q2FpDHzgCJGCBMR6oYK0LQdNSGIfYQALZ8EbxOhhMusx0TDRK418
U5JYgeEQBfEWRd2pyrT33zA4cif4zsgb4MTw5IXFnKo7Mw8WvgzBKpm0QZE2 QBGEy/YyU2c+zuKI2U9lVFnl7TiW1ENs+jIQhutJXZUfsAaZCIgH3xMOrID/
UKCeQALKSgXhAUGqasW+rMPuMQlvk16PWoaNkHIiwnVESqURgg8SqkWuDH9t +9//ltJcLazFdH+T7fpvIsSmX8J3PjWGfdrwGb7BSw/cDA+2H+CzF7vwP/gc
tKtFp+D1DuzAhxi7JPnFUs9vA6olB2GFqhrI5N/yU+c8YRikeuXsrdmvmDBt zE2/EA4bvzyAtz95FwQ+vrIY+1SHGHbR+hcfrX/itw85mqzBwLVCNmn+csYh
hqs0LOH9jtpcj6PfArhFHCOZQVVdhRqbXIz+YFydAHzEblZfJt6NfIFHcKBk oXu7uy38RPgnzLZ/uWHf9Nez7+4vD74W1fXffwWr/FdjXOMXyxXoxYh7nl0E
+JnrVLbxnLd7e7JOJRAraJuh0sROLdrZsb+T2Fgvq2gNZK9jILDRFqfznqWf lTL/NJoG7oI4+iBRrfPeX9TZKYvgEUgLkWBbJnqR/mkUYc6oGH2+KROF1qGR
tLfibjGIxDJGMoOSvfaWg2v/9Gz7H+9Ozn+Rr5k28pqtH02eDJoRd+ExhLzV VOGEcDOrsinCttrXGrk6omu46C79xCknl4DC6N2WFmo/s07XHFtdj3mjsc00
gyHPBFT/jKCCX+z85OLs7ZuLk7AeG4yfCBQoiDdhCBltYe0VI3eJnw1zeNVC VLnzbtuZIpszIOelSth8DwfIgVY91J5VI6kXZMzRWZTXZFHIftLDmUJwKUUB
SQfGeCLBB0/5gn/G+8mpbUpCJdvZWtIWLWn47I0uim0ODEQKJb4IXBqXqSrX yge8UZeaoalZtQCwU29kgXAyQrVlwpG8yphsCBgpQoQBqrKn28gaGcxuyFZe
uV9kE1kGOwPaBcvObIVQSSIsnhFyMuxSJBMFcJqGAQHg2/NenNN5oN57HR28 KUzJEAFcHuNbdFxqaiD0YJ4oXZFozsh4wEj9NCAt5aVlgCJLlPOB6nVAUQLd
ppdWC3uLoAIz4LUH9u6cjDAWold6gBeBQCCzgViwCkQhC8QrLhK7ySSLNhAR O6mf4YCRgz9jVgOTSFRdwUrISqdEYUA8mEr8iUzzHLxzq+HhZY8ir1o9hgAf
lc2jED+tM90JYobHPLHYXqvl1u0j1pinJUVl3qEur01lywVtuoP7kKNjGDol /bMnGXpezaldIG1zSDAqZAyy5zNwVAki3BpYEawTFWtWdA3EMxk3Mfq4RtsY
S3iecWJOuGVOX/WHZUSZJpiyg20bxKVC0gbOFdiEnk90Aw6kvW8oNSfwBwrv wSdATIO4lNrCpLJYSsMpvn9WypScrvK8YJXb1NqhLCdC+pyd3cpsDZ/S2AI+
PuDZowtXg4xdkCX07Rvr1gfUHGlxV3ZkuPO1i5CtY8DGtgsifYFC3ITzDNz5 HLzmYac8pXtLtlKTgVOMPjkBozmthjnYTlTsjOIKcIR4YlplIM4uRUqaRn3Q
qtdEYJDSJwIg8Eu7tIWdgU1jIxZIXMmPD2p/8T12zSFn4VDkPhP/nV3o2LIY pgzKagUimXmXwcUkM+fkqAonuDTMOUaW85h3GHrtFA0xI9bOKs9j5KqeDPsk
DcCS2P9hFHChEE1YaqpL6ckwc9KR8IgkIrg0SNW1Img5LZdGGCFwOpBOU1IS AoFqOxiYwq8F4nFDILZog3WNzOqUtidfU7bOHgeiMBZRoWRpRQVh+Pve9t8u
JLzjC1PidkaS+vwg5LLG3gBUMzjQR75JSykp9Hq36N6oTa/jEOt1WrGFF9mc jk5/dTCyyqy1aDDUcYHfjk38xjXJ+zQSAf5mqdJwzdOjs5PXr86O/FwkJnY6
CGfJlNev0KxhHB744rco4kZic9SWacsxJGwk/BHGGOyfYJtQ+Lj9BNzQ1HwI 4BhH3wA/LKxJll1y0SVQtW4Sy0tIaYcg+xOq4Tk/sYOsnpxnVUqVwSBD0Acc
6+F4yI9Ni6hj7JxVoKXehyQP2qnodrV4rrbZN1qL7IyhiZiSPN97ziGyr9dS jr1WSbLN1oGBIb8Yq4faRLKIKUdyPL8BMo2lemWcSEdZgYnugG48JXhr2DkQ
mQVJYNYoiOq11q13YlWMDZ4JhK8rsnEfa8B3xUCPmkK4KYWJwK48aC4lCv2L TOTLwvQewADqPW4ZPBV3NmCVpiVcXXEeDhw/LADjKduJW2ejDDlBLGyhlWo6
A/lIpNWjfy5gf+LUo6iUiBEYe0rwqV85tl+sR9Wp1KeE3lSgup2zLwRsQALI AGkF5mDtwLKpokYs2fA3mdAOGs+BNmHRwx0gS4QXW8zC0LwT93UFJ4hFj1My
25wZ5C48p4tcPgzm+XS809onkfQI+dc4SgCU6IAFqMUIs3NPyJbdCoNIWUJV 1LxZlV7pIktXtP9G6p50HVeGQ8iwNEEIZB+eqlExfVQfcl8vmKF3D9KvscTg
JXt2IUAaMZcCFmCNwJo/9hvcW9sgoQHgWjqu3kM1mAGKwpRQuvlskRgWMunt XDpQsICymPK0TdsDrvEr8uEpfwRxeruM1YIMlwPXHpThukf0bePCPepVqEtq
02MfF8k5AN1ehUWq1mpiGbZnXwvZOdBez0UCwspO/h2Lox6+b9cvcpgI0ar1 hHbDGAgeW61nlmjFsRsCqzcOULaRDpk73zTUkKs+Wf8AuOA8y7MkW4DQY1cS
VLeDrC5FM4U3XFS2kN8ESxx1vU66KwRlr8EkqALoNGJDIeAzfgJVyU+ys8pi gLoWH++V9uF7qhXEyjoEny0tTLZSvqlg3FNvwtYMLu6sJOYgckUBLRfN7dxh
gdNhLGvLBvZSx49wviFSQiLFkfL0LDilsDMuP9LcrstYXDSaWrcAhAvcm1w2 y4AtNWGFjt6SZSmpeBgGWeR74XwzqrKjg0QlrXBS3NKYKhxI8bTEoi9EQPim
1dI6gqfSWltT48el9Zo/SOGXGLZeoZFSn+KpmGNa2PmHmpxPQmWq+VclNvbw NYWzGlbL6N0mjg3ZnVbpeOhje1qiLhChYIGpwLIMdzBgdiaSls9cK4Uvttrt
Zr+cG8x+YpqbJKZcZA1gX+8R/qI4wsHKr9KeXQCxUXrA9ZTOZ1GSVMsFA56b IYPZTfiOpiwNW4OcH0fkZx+K13wISmmuP7h18DVwmnVdJkVjuiiASV1Kth6I
3HOkp5dr/MdK+IBBvhGYO6VWVA5hNFzryEqQSWwTe3gDR2AhW6cSIL/KXIqs 6fhmuwlPVnffjDvGnXNuWHS1EvHk8RM2o22+FlKvCO2LSoKpL5WqdRXzYN11
B41eqpmvLLhsPD9g+DK0h130zBG/QN8cGd0xaq/cHY7HNP1uBDHFEdevb0QT MQPTdklybs0QqDJv/JFBKOtKpsMhKnY8a92H9uN+t4TBtRlD40oqwNk29Wrj
X+1GGC9cizAXySC9O4CydYA8RtQe84/kXsDcbkEZaVUCKf0PlFog5lMQbyDt d18bo8TuHymI3xdvGBJfbM+4zDjmfA25/boAFm70d1JqBJ1D3vlCI8ZhoEpi
NsTxsbyg9rr/4ZWdiXnc+XUH+vip98NDl56i9Je8HYn8AzzqCqv3+bThekJI cb8W1keTHSetBOIWorQy5C5IX8NkDCI7YyGVmwCytBGJWGhyCMJES0KAaqZ2
+0lxyBSnXL8e7w+gle9bwPKwslcYawb85y34JMQWyLM59gSbIDxvaJ6Rh4yS uwArGEqwCEz8Ph939knpBNA2DUNgUz7oHg4HiU4h2rO+JGHRedvbx8+sAbWV
noU/o4VWFBAElbgSII8rkAm6Zz6gBraN7b/+gPSACvnMicqutmu7jf9KV1eN Z8vTQesecsoMIzPWJeiEgZ7LZblsZHRFw0f3gVSrfpt1Hzor4oxarbxuztYa
79Jy7GSHIIZmMmVWNHnvoBzsz4NUrV9NzZ32kQTKPsg5ELNozqaeWSykOgVj TteaRoMHNt6mpIWMVSGELCep46ZGCveIud4rEB0KGRp9VD5ysGErZWpJjbIm
qA5Ha9VgBBPHT8e7MVuKFeFl8PtYfCXte1hJf2BkZ5h+woNMFZAg5BFEDe9N i3xQ1MAzs9AGbLvsKaWIe6BxXhib1eMTp8L8/jhkCR3EJqZxXS+UDQsAirmw
N4yhcAQcoearKfOQ3zImyuLDfMuU17a49sUlZjo+Jjg6DsKxuduvvKSKHrwm PTt5VeSZsWmvMGBXVPQ3YaRn+yLtKv2iPhwoBNc6idI7q1mK7VikrAJIQzG8
Y3gplG6GQhNKkRt/UAn10WakID0y1JZ7OIz1AbNJVbasa/dbWxEiw4Y8h2KW TKm7g0rrrUiw13fyDnPg3IZWa0N67T1m2JgJwk5DpB95FDYMU/HC05QUjhPv
h2ktzfkv8+899544d2Baz2MMe/d0eHvGDvOqux3OPR1f5yp+Hoch9w4LuDc0 pY4tVlrc2iEDRdJTziCOQRuQT0ZhFbU/dLpzBBDH9w3ZTAm+gnFwGdKBVLFF
xEjOlweExwEZict/cShY60N9eRC4gxf9BbrsvlMa7eeLvf+68yeGe99/OVxs lacA8HcuFzZS4YjzdMoJUtdBZFxHk0uDoDb3uG7Ku2X0BtZrb/9O6ckwSdl9
a26k+LYVPH97IID8nQyNGkCjJOskNJgStHA2SydWGNK90KOBzBJxxwWVJhPM vjlV+WLXZwjdM589I1KEv/al7xo5Qk7VPeAvwW8umXdTCpPWpRSo/YLUc+B8
oPiciuWqDlPngPEPp6k8yT0btR2hpNnTnQ3IpA/Jas4629OuoOD3b6muKS7I cnR2wN2Yznwgzqjlyn6xnM/gPGh8uy21+an1xSZGLUzhN3FLmvO34KlJstbf
4ujspDdvX2W/lN4Nqri5CzqQPYSy815KNFn1ke6ApXip36JcD+Rxew74qAPD pw3PQ1DqvzDJGSZBu8/97/2p0Pd1NvSgyC5BDXmf47hm7RuTn2CEqFUnTBZS
UaMsHvmtIiAWggxj0VxSerXhLhPDTMn5YjwsyJGyxNcu4kHJ4L4mlVU5qDZH orBPRbt0Y1AoEbb5GgXL5SpkoF8AQo5kZqi5bSM6iDuasfYbYdMi6dKZjC63
xwbP67btAQboylxQNEjpcbUGO2CkQYXu3iX3SRkPg+imPYfw/LBvKIXGCtoV y2wb/xWmLCpO9rKdZRUBgWHPTDqNkipudcTDDtmCBOo21AC8k8CWthOoPTaN
cgKBKigwTdt2zELEojNfSCk8NMXT1rGMCoRYalcxpBE03MNk4hLhEN8yfvjm Jq3KRUYhWV8GxJbE+mPLbyePJrvd+PLcmQQM5IJ2LlhMfeC0Uf8eONukC5tn
4PIR23tipKEAx2PNvW3T+T9ISpoKMamuaOTHB05nGWOltzWyO+dBQxFJmkG7 4qwhmBSrZje8RcYK8GJYS8fOWeZ0K1OR/DSdXmXJFboU6MWjf2QNhqF+QTbg
d7B9VRnrPUrygkLKaNE5HRln6IAajMAkZ1zvONrq4btAtojln0+lIG/FAn0m ffVSMONVwqnBMGuv+ywW0pMrjxhQtXPaCEXYYVpHjsQH+AFdUWduEIH1nrGl
dYHdgzL2c1itu6gfuzrffsTc0wW2dYHl/kF3VxsQLfWYx+IizFkgogvyzHTa 15mNDS4R2TSbBM5ozt9V+7eVf6D6AXktTbJB94fvU1P9a7R5L8APu10T3VUn
izrd1CP31nDHfkPDmOXugeI0i8UDhJyBemaShgNNQFJ7kCBsTPQ21ulm7Oz2 Np7i3wP3yt2tBm4PaeIB+gp78YB6zlE0HnhwvtRSdGpgX2EjbsNHe4km0m+n
231rx4D5aCYJnbHJ0JTsnI3Fk118eK/ffxeE/ZcMGoUzwL23N3ycUm7tkEQ0 Sf33xcah1zYQ4q1p6LMJ4gTzhli8sSWzZ3gs4GY7Ab4/iZ6tPNWeKiWlyaFz
H8EgAB4h6r/o4RVkQe154B2fZS/CmQQ6rE7t2WKVoO0ByXRJjGyFFtBx3ySg 7bwqkMtGjp89dU53rijImaHPxe0zGYeJ6HK7ekK/S8uz9LWxngBj1OGrS92J
4BlwEk6ZCSsLb1j4iNl/KYVfOKATy/2HZTjcwf4gOXTw89wQ7d45ZQqDra4q 7x7t7or7I/x4Vq5hC3+pQKmPtsbNZiqIepbuCIf6kAP0gJ8qR7VAQTRARh27
W2rbQLCtMQmGXU0sOIj0PQvf0KF26hJUBDJt6pgRilVgYxZEsUBwK8HOXDzc Tq1iDo1fGB2eHI0ar+GJBl3a9lhKXjynJI/Y6+1t/e34pUYWmMmiWHw5hh2A
iI1Af7iafABWI3ys0yH+Sa3jxFMjRVUH7FEyNaYMkvix8GexR0xEPO1K3dJQ fU1/vw/9fycAx846wGyAeHANYCFO448OK1NmK2AD4PCVxiTS0T8rnaO9GE2C
1YUmSsD2qN2CnVfUs9hgjeGipYssi9o0fr0IhIXG7kA76zVaPngiMAgy3w2e Bry7tBs0BTt0028voQeVdKswGQstLeVU5Rc0BnRVIDAooqE5c1v5fTnMG5Ta
rG+2KcUJ+obbYqi6fQmCXqnyoKzXqOizuC9WEoeA1KKFncWmHktbSil+hctj DbX8fjfVJULupI5m63alxiX+7K5vVFP3xLP6ONlhI1tsi7z+6Fjh07bOi+Fa
cV5F2AnGBSqF57JxhaQD2JeLo7aePD14c7AWybsxAt1PaflJxT4nvDqFJT3O Cqc2LPdxbdQmRIOTanhYgf2xFA/LCndew1nFWZHJGOSEk0IVnvqqK12cR8Yk
Es5VvYN1jyDp3B/q4IUT/Vz6nCt87/Ndacg8n35/BiHi4A2HPK4rYOsvQONB FXkbIUSmVMDYnAWTvjp9zvV+ckwl+E/KIgoPorkKrq0XopgiQjC7mmdGc/bD
r5oCQhgwFPNZTnHp+YWdoJkEzHL9DDiQU8mTXxuz5Mbnw3cnj3qnHzEbYFIO nyEgX4gaGxFYGDXHs3s+kHegZFRn5XSb4/mpy8acY7bOtj/cfzU932ITEki9
MjzvEqPyQ6Dm0ZhowvNMjSlqPEVF9B0CHRM0MSQfpj08fEQW1+4JLp6/w+F0 ywbhCbnW1ntPHlQFJlWb5NoX9iDCG1Kwze5LPpVAlIgSWeg5pmRhiyNX6ONT
pd1GnP3Fy0eBCifP35HxHh6CMqGfsFMRL/kz1adnlLPz+Vkyl3A+K7Z8Rlx6 ImHqd4RlF9sW6M4l2CN0aVZaCl5jifpKCVeaHbm5RkgyfwreN9xhmizyySt/
EncxzwDfILjPid7FezHQ1dxWMd9fQDFQjMUJrgpL0sET82uj23cdan8kCi2b kiFa1ygpqCrNDNbwi9sWoHWo1+ahLSiYucAE00KoxCiXrOjfKc1mNa+tu3P9
EAPslJWl8sfq2a/xJUF+orr2h47CK2dHGsMmPIsRx1ad1VpfHNQcdrxGdG8G 3OK5WURB2Hy7MvCfBr6gFos+K/AVMNamv5GI90v+QBN7UMe3wUp0qrt1WvAG
Io08nUs6tuTDeChE1xXOzvEiwjZ+BUhwCpw8dHU8q8O+xgJI8CkhPsrbh4fi 3dUb+Ep8vAezR658dFPzT+P0kzsP7I6zgTUEOQPey6wlDE5XhyJNtxXUx4A8
uybAP04iYzQI+hpe/0gKHp/7dxN+yPXP3+3GG+3VtBT41B+7Xhj0y4XhZ2m1 yRpZXU5DB6e6bjnMNWlSAu9a+GpS/NBCPvH0JuyHCdMm7s/cnAkWuUBzRCqs
p/1542pcvX9Ka6BIUjohP9E5uLlOCw/41JrIBoJlt+AZoD/MJNlJ9LbzLBI+ 4R9v6imyonHLhsfUswS6xZbNwrAcW7FZCi0iSZG2j9K4TfHtEcGuGgH5zm63
TFOfl3fubng7w6T1aLlFkGviD7XbZPI+OqH3tX1fNaF8a10h5SSonVXUxKiD PnnePvLGfe5EdHsMpm7hcP1GxEFre0Kk1alEtVusUtA+3Xm3ZonfWB9Hmt5+
oJKHh7fDAB8/ri8C+RS7lDhRq+LRws/f8QmKYAjwpJ2V5jftT/hwjurmZpnY GzcRpzuxF7N9Mt2yyIo6mcDV4oOciWviooOa1NCSrIMKpK/qmMC/q8nm6oa2
EOcfaKlPvJWKeJZgyOoopPlRrelxU/PwkK/T/dRd32F3fJhO0aujBXgFevOG dkqOn8sKcw6AagR2K97Zb23NnpOmA3rt0cL1xLHxCXu03iw1gW9tYSTRS1RF
W7kfMPTFV1XZ0Th+zRGjMTgO8ByVwK5dkfbLEqSxA7D3UsmwHUjcCWTFnXbm kaUqqww6gSWx+iwD1RueELc1b+5FyTM8aqapFkqZ+wTbWoAgK8zoh/1mwrWL
oqowYUPI0Nc9h4+lXOb17/tSNoAtsWPf69f7Q8gLkBKUojWTx6k7RnTijesy Y++EPU1IqoCyLNwqb7ASRB04gXOAMBWN5LZsaLRIFVgMsccPxwyGP0NAXSYu
B3IKfHOH4zglti9ekqLopcnqcEih2H0fSHo/nXehnb6qtwayE23ibCfBQda8 Z+Xqy66qQZVo7FhBhvONKd5HCSAjCaMStl3RZ/9dS0xv0f8lmgtQSiAeJMgb
wCYbjpN+ImwISqKuVacTDpsrPdxf13ec8HVZ//0WVxXBUtm6nLvXPduFIcyx tFpbgEOgf8D6M5ckcGfDAVVLa91paDshH9eWhHsHUkITQJvUZbhmtj4sQ7dS
lua1s+/DzoS934Oddlo/9pxebfUXh/3dOiV9D7h2bdgnDvJi6FoCim3i4j0m RGENgpmFVaJfo5B46AUXCdol2vQxrgVCHE9fTXtcyabhQLWUZjxWsi4KLn/A
Is56+G6zKO9LUQLf+WtpHLynLvJlFsOXKuaXM3uDlqY7/SItTeJwMva+Whoj /GXH75nm2IagP4jpfussf1YVgjts3MkgUy1AbkqKRmPuospsOcSf+R/brKcT
b3fzMfy2WrrbTtuj+Y9r6R9Rgxhwu55rPdgStO7jykD94b3ybRF3yvm3r/04 m9pbonOW7lzn2dL7U2Hsy8HTAUAxwwUvUo3FxoODLYpq3T0H6AR1x1wYGAWT
sOFppRDAl3QAJ/zdir1hh8oAQht22iCS9jQpNPgww5Gn/xJ2ZWGxxVhcYJUY W3GwLFlD9hSPHJlsDP5q19+6JnCoN5NXoVYzmeIpEWCt4WB0cDB6CP8z7IPB
X6u/ITAinGdfP+2y8e3v9mjYruiGmjHtfH2T7Um0SZO8OMnQazw+lZ4OXXuD cvT1Ar77JhMqdRcoQK5oW7tdJKWR6wrEpis+jj+7BRenEm/seQ7qBUCtEu8H
gBCX24mklzc8alnozbT85GlJ/lzEl5Ik/mUs64hysoqIRdsU7WYHjk8LbngX 33/+MyOFnVAWTOyAksg/m4L7R385ORGrbIYqzNXPugeeLkBV1fEqIPfiaIud
n5DfgywoCp/9/7jPf9RC599tTVXh9JZ/vZ//MpPzmkDvvRTmiv8URtYqG8HZ CJil9iMwOmDwphH2bdawnU5fbU0gUJy+oibdSiclNgejpqA5eghMDMaz2Yen
/hw3brVxziOHjLx4/YLiis41UdGuKjWX3yNzSyhFSyD7XC1U/pviSvHC5Pkc FzRH//75OBvgwMFjxOkFzXFwAAKPKh0tqHtkzxMdn1BugM+OoFbjTIC914O0
rAeehH8WSsCmbqiwwxNP10bfhPd6FlytpwAI/tki+dOqzK6gtH9t5wpflzq0 C5qyMec8yaphDIKanNt1kI+t1QGdEmeF83BpolUWKyCr6E9cfA3uGfXa9GD+
TaZyZRB1U/Ao2O8CzxpiNfjagFQgATzHf6vcIU0HBfD9WP9or0byWIFq/Gyr 98M9CE4f9g1MMwU11cQ/4TwNiBDg31hsX4DZF0dIA0+AizYFLN7uRoWxI8P4
QkPdfIYW/nP4gxHHeiKPrKU7sO6V/BFfzxzJH3UN4y9VAU+bK0WLAOcODaRj i+ngXXFUoq4/H5AsDgEP+32NXu44Pye0a6SgRiEaImopsOJUMdCjRs/He2BV
S85X7QJXUOWqMDdj8X+LkR+gmUwAAA== MDPl0pW/herhwZrbhK2P3j20Nlvsf/TQ+iZN00dlIDLSeDjYKGUhje9IX0pv
3ERgS9zhwPEXNTFrMFT1jQelba1Hf4fUL/ZYpam05zfZ4eNHVFCigwLcue7u
ETpUGFTAYHTJs6K5Xu2oOsMPe+/A3ZqCgCMf0ITtEhxI0rsUsWMvL3nTPnKw
S0AEmODsrvHHEcLtDSYFmrj8DI5mJOA4f/UE4JF1h3eXHQu7qyCaSUmbmGtl
4z6BernY9b8Ej8NE3afO6z15u046b8NoWvJRZ26/JFdrPoWZyhqwcE4e0jgi
1AMQv/GpFqBNYItmWrJvF24uwVqkvak9D/0GuNpovX2PGza1Ab42QDcRtocj
fKJ1Nnvv9dX7MntfVC7X6rXmGwrmkCOnBWpg4tFnjjmBWcHJuqX88/Fjdx0X
jrIG8sxey4BXBLD0uDYVMB7FBYZni1T/S1mXjWN9s9R5R9hQph9aeQbfzTWr
9sknxQNdGbVtcSiqpIcvWkcob5FPe5BD0t1hCagQOhTOvYEfMHDwt5UxQgxf
l4ThDGgZUDPgI2LHVxI2WgUl6EYbRissd1vCuhmV4HG7jckomxvgwiU9+pSM
tcWcn22PsGnouujmq2mNVlB3FG4F5CoLqqYvXTYE7SghyDQxhIEZnixnT4AS
Bc9/Jr5RuY5K1xuR7L53QL2fLzuHQztiUMvPjpeYk52gqNHRFRvl3E/7ico9
p9OW5IczbhBoGt1e2bYq4Y1b9vNNOs1X0kWtme6w8skuvGNr6B7szonMDQqH
9eS9nXpe+/Ip3ZVlH25QjF1Y2qqy82yD8uzFR9+zoNK1EZV3mInQa8tyN1D0
rjCFZTn7MLSdd+RKfsy0+GIW/QqMb+DXcLNfxq+B7Q5fviu/emPdQoC32DW/
7tbztsD+Hfj1N7FDYJ6bCq1jmrn/wlqdnsDGquubzfOcXXqbW2PTh+3xzsjh
0YWkvor1cb+qtana2izVNiZsiyO7Ya0QW6b2/W5FBqutsCqAlwn4C/041+MO
XHZ7qTfeLBeeSdilUzb1MQ+7/56t+oAHgrPg3g8urPqm/eZBpVaenTLcNwNK
R4ttpShRdwInuFf0S6FqNUH/JtQ1iDpb+wRx3VfXdCNM5/xKt9vvHkTJjmvs
udWP+3wFqor/NJrLxKiRv0mQ79A2ljESfcnXpkY131HB2h42xM1WxtiqjU11
W14TdM0RC9NH2LMs5FL8BXGcfkZiwrPjFHZwKlcy/pf87C7NwbE6jpcgXEtx
Bv+s6DfKZl5THGlsWtYdSV9xai7MQMMk//nvAoLXv6/T6FK5BV9mS4lH/w+y
KpKx1AXPDL88k/AuCP0Kj8Sowr+ggYbgWJ7iv0VsatinCZDqmfolu3RPnkng
qjdZkai1e3SC6uINX25ZL6Vm4jDLgmFHhb4Uv+B9Je7JL6qE6c9lAhPoSxnA
AwQ50OAN5iHCTrMVQiPTdaKvP/e1YZ3TcXd/BE5Mwy4rl4l+E2aCqZC3LDA9
PKIKu2uckmKO19vqFV91qEujknkz24tZOs+E4nmrEm8vEuDTGMZnfE2YaG6l
uH2d/yllst7YrgBPcoZJOT+akty0K1eU9wea6Gr52891+lMgPcczhDudMRy0
jlR0T1TgLZW1FuHk2yzEdOMKK0K3cTc4ynnJTcK66F4xhoGHqx51UNxCK99U
dt9GZ4mal1tNBLsmZb8K25SVf6fAtrAtC5FvvXvKwUsu+WKq7Z8abLXhjigc
FrSftVuL8A9H2B5nZ4bDP/z5xS7jMtoSz389FtvCsQSHg8oBxTFVE3vN/sHh
IP+yFsVJqzikKPPnV3Qq2leiIqAWNvCvg+4ke8war5smWd18BVnznHWQxr3l
6unRMdaeDNaxX8h0UckFOCwoAOEVYindkQROQb0/8eOyLHOz//Dh9fX1BKbf
Bm7GtF9WLB4aHLfAYQ9RT+4+vKfdKu8Tu8pPHIkmCrFL/gpd+B1co1LfyzsB
39KWz1xlKJXUiO6Px2KTELaqI1rpOGNe4MlVYGO73tge6IZ3lyrJAdNE8kJJ
iN4Zu6+8UsNCHlrLvATbFfMFAYnkW174+jBNV6WXOqoSWYzJT+GKFQvUcMBN
FjOHbL6HW8IDg6easNQYqYkgIv0/wLil6+hjAAA=
--> -->
</rfc> </rfc>
 End of changes. 69 change blocks. 
500 lines changed or deleted 549 lines changed or added

This html diff was produced by rfcdiff 1.48.