wdiff rfc9527xml2.original.xml rfc9527.xml

<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.1 --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY I-D.ietf-homenet-front-end-naming-delegation SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-homenet-front-end-naming-delegation.xml">
<!ENTITY RFC8415 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml">
<!ENTITY RFC7858 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml">
<!ENTITY RFC9103 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9103.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC7368 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7368.xml">
<!ENTITY RFC7227 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7227.xml">
<!ENTITY I-D.andrews-dnsop-pd-reverse SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.andrews-dnsop-pd-reverse.xml">
<!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml"> nbsp    "&#160;">
  <!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"> zwsp   "&#8203;">
  <!ENTITY RFC6672 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6672.xml"> nbhy   "&#8209;">
  <!ENTITY I-D.sury-dnsext-cname-dname SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.sury-dnsext-cname-dname.xml"> wj     "&#8288;">
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-homenet-naming-architecture-dhc-options-24" category="std"> number="9527" submissionType="IETF" category="std" consensus="true" obsoletes="" updates="" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="DHCPv6 Options for the HNA">DHCPv6 Options for Home Network the Homenet Naming Authority</title>
    <seriesInfo name="RFC" value="9527"/>
    <author initials="D." surname="Migault" fullname="Daniel Migault">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8275 Trans Canada Route</street>
          <city>Saint Laurent, QC</city> Laurent</city>
	  <region>QC</region>
          <code>4S 0B6</code>
          <country>Canada</country>
        </postal>
        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>
    <author initials="R." surname="Weber" fullname="Ralf Weber">
      <organization>Akamai</organization>
      <address>
        <email>ralf.weber@akamai.com</email>
      </address>
    </author>
    <author initials="T." surname="Mrugalski" fullname="Tomek Mrugalski">
      <organization>Internet
      <organization abbrev="ISC">Internet Systems Consortium, Inc.</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <code>94063</code>
          <country>US</country>
          <street>PO Box 360</street>
          <city>Newmarket</city>
	  <region>NH</region>
          <code>03857</code>
          <country>United States of America</country>
        </postal>
        <email>tomasz.mrugalski@gmail.com</email>
      </address>
    </author>
    <date year="2022" month="October" day="31"/>

    <area>Internet</area>
    <workgroup>Homenet</workgroup>
    <keyword>Internet-Draft</keyword> year="2024" month="January"/>
    <area>int</area>
    <workgroup>homenet</workgroup>

<abstract>
      <t>This document defines DHCPv6 options so that a Homenet Naming Authority (HNA) can automatically proceed to set the appropriate configuration and outsource the authoritative naming service for the home network.
In most cases, the outsourcing mechanism is transparent for the end user.</t>
    </abstract>
  </front>
  <middle>

    <section anchor="terminology" title="Terminology">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<t>The reader should be familiar with <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>.</t>

</section>
<section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="I-D.ietf-homenet-front-end-naming-delegation"/> target="RFC9526" format="default"/> specifies how an entity designated as the Homenet Naming Authority (HNA) outsources a Public Homenet Zone to an a DNS Outsourcing Infrastructure (DOI).</t>
      <t>This document describes how a network can provision the HNA with a specific DOI.
This could be particularly useful for a DOI partly managed by an ISP, ISP or to make home networks resilient to HNA replacement. The ISP delegates an IP prefix to the home network as well as and the associated reverse zone. zone to the home network.
The ISP is thus aware of the owner of that IP prefix, and prefix and, as such such, becomes a natural candidate for hosting the Homenet Reverse Zone - -- that is is, the Reverse Distribution Manager (RDM) and potentially the Reverse Public Authoritative Servers.</t>
      <t>In addition, ISPs often identify the line of the home network with a name.
Such name is used for their internal network management operations and is not a name the home network owner has registered to. ISPs may leverage such infrastructure and provide the home network with a specific domain name designated as per <xref target="I-D.ietf-homenet-front-end-naming-delegation"/> a Homenet Registered Domain. Homenet Domain <xref target="RFC9526" format="default"/>.
Similarly to the reverse zone, ISPs are aware of who owns that domain name and may become a natural candidate for hosting the Homenet Zone - -- that is is, the Distribution Manager (DM) and the Public Authoritative Servers.</t>
<t>This document describes DHCPv6 options that enable an ISP to provide the necessary parameters to the HNA, HNA to proceed. More specifically, the ISP provides the Registered Homenet Domain, Domain and the necessary information on the DM and the RDM so the HNA can manage and upload the Public Homenet Zone and the Reverse Public Homenet Zone as described in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>.</t> target="RFC9526" format="default"/>.</t>

      <t>The use of DHCPv6 options may make the configuration completely transparent to the end user and provides a similar level of trust as the one used to provide the IP prefix - prefix, when provisioned via DHCP.</t>
    </section>
      <section anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
      <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 in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <t>The reader should be familiar with <xref target="RFC9526" format="default"/>.</t>
    </section>
    <section anchor="sec-overview" title="Procedure Overview"> numbered="true" toc="default">
      <name>Procedure Overview</name>
      <t>This section illustrates how a an HNA receives the necessary information via DHCPv6 options to outsource its authoritative naming service to the DOI. For the sake of simplicity, and similarly to <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>, target="RFC9526" format="default"/>, this section assumes that the HNA and the home network DHCPv6 client are colocated on the  Customer Edge Premises Equipment (CPE) router <xref target="RFC7368"/>.
Note also target="RFC7368" format="default"/>. Also, note that this is not mandatory mandatory, and the DHCPv6 client may instruct remotely instruct the HNA with a protocol that will be standardized in the future.
In addition, this section assumes that the responsible entity for the DHCPv6 server is provisioned with the DM and RDM information - information, which is associated with the requested Registered Homenet Domain . Domain.
This means a Registered Homenet Domain can be associated with the DHCPv6 client.</t>
      <t>This scenario is believed to be the most popular scenario.
This document does not ignore scenarios where the DHCPv6 server does not have privileged relations with the DM or RDM.
These cases are discussed in <xref target="sec-scenario"/>. target="sec-scenario" format="default"/>.
Such scenarios do not necessarily require configuration for the end user and can also be zero-config.</t> zero configuration.</t>
      <t>The scenario considered in this section is as follows:</t>

<t><list style="numbers">
  <t>The
      <ol spacing="normal" type="1">
	<li>The HNA is willing to outsource the Public Homenet Zone or Homenet Reverse Zone.
The DHCPv6 client is configured to include in its Option Request Option (ORO) the Registered Homenet Domain Option (OPTION_REGISTERED_DOMAIN), the Forward Distribution Manager Option (OPTION_FORWARD_DIST_MANAGER) (OPTION_FORWARD_DIST_MANAGER), and the Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) option codes.</t>
  <t>The codes.</li>
        <li>The DHCPv6 server responds to the DHCPv6 client with the requested DHCPv6 options based on the identified homenet. The DHCPv6 client passes the information to the HNA.</t>
  <t>The HNA.</li>
        <li>The HNA is authenticated (see Section “Securing "Securing the Control Channel” Channel" (Section <xref target="RFC9526" sectionFormat="bare" section="6.6"/>) of <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>) target="RFC9526" sectionFormat="bare" format="default"/>) by the DM and the RDM. The HNA builds the Homenet Zone (or the Homenet Reverse Zone) and proceed proceeds as described in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>. target="RFC9526" format="default"/>. The DHCPv6 options provide the necessary non optional non-optional parameters described in Appendix B of <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>. target="RFC9526" format="default"/>.
The HNA may complement the configurations with additional parameters via means not yet defined.
Appendix B of <xref target="I-D.ietf-homenet-front-end-naming-delegation"/> target="RFC9526" format="default"/> describes such parameters that may take some specific non default value.</t>
</list></t> non-default value.</li>
      </ol>
    </section>
    <section anchor="sec-format" title="DHCPv6 Option"> numbered="true" toc="default">
      <name>DHCPv6 Options</name>
      <t>This section details the payload of the DHCPv6 options following the guidelines of <xref target="RFC7227"/>.</t> target="RFC7227" format="default"/>.</t>
      <section anchor="o_rd" title="Registered numbered="true" toc="default">
        <name>Registered Homenet Domain Option"> Option</name>
        <t>The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the FQDN fully qualified domain name (FQDN) associated with the home network.</t>
        <figure title="Registered anchor="fig-rhd">
          <name>Registered Domain Option" anchor="fig-rhd"><artwork><![CDATA[ Option</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   OPTION_REGISTERED_DOMAIN    |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                   Registered Homenet Domain                   /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style="symbols">
  <t>option-code
]]></artwork>
        </figure>
        <dl spacing="normal">
          <dt>option-code (16 bits): OPTION_REGISTERED_DOMAIN, bits):</dt><dd>OPTION_REGISTERED_DOMAIN; the option code for the Registered Homenet Domain  (TBD1).</t>
  <t>option-len (145).</dd>
          <dt>option-len (16 bits): length bits):</dt><dd>Length in octets of the Registered Homenet Domain field as described in <xref target="RFC8415"/>.</t>
  <t>Registered target="RFC8415" format="default"/>.</dd>
          <dt>Registered Homenet Domain (variable): the (variable):</dt><dd>The FQDN registered for the homenet encoded as described in Section 10 of <xref target="RFC8415"/>.</t>
</list></t> target="RFC8415" sectionFormat="of" section ="10"/>.</dd>
        </dl>
      </section>
      <section anchor="o_dm" title="Forward numbered="true" toc="default">
        <name>Forward Distribution Manager Option"> Option</name>
        <t>The Forward Distributed Distribution Manager Option (OPTION_FORWARD_DIST_MANAGER) provides the HNA with the FQDN of the DM as well as the transport protocols for the communication between the HNA and the DM.
As opposed to IP addresses, the FQDN requires a DNS resolution before establishing the communication between the HNA and the DM. However, the use of a an FQDN provides multiple advantages over IP addresses. Firstly, it makes the DHCPv6 Option option easier to parse and smaller - smaller, especially when IPv4 and IPv6 addresses are expected to be provided.
Then Then, the FQDN can reasonably be seen as a more stable identifier than IP addresses, addresses as well as a pointer to additional information that may be useful, in the future, to establish the communication between the HNA and the DM.</t>
        <figure title="Forward anchor="fig-dm">
          <name>Forward Distribution Manager Option" anchor="fig-dm"><artwork><![CDATA[ Option</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  OPTION_FORWARD_DIST_MANAGER  |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Supported Transport       |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                                                               |
/                  Distribution Manager FQDN                    /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style="symbols">
  <t>option-code
]]></artwork>
        </figure>
        <dl spacing="normal">
          <dt>option-code (16 bits): OPTION_FORWARD_DIST_MANAGER, bits):</dt><dd>OPTION_FORWARD_DIST_MANAGER; the option code for the Forward Distribution Manager Option (TBD2).</t>
  <t>option-len (146).</dd>
          <dt>option-len (16 bits): length bits):</dt><dd>Length in octets of the enclosed data as described in <xref target="RFC8415"/>.</t>
  <t>Supported target="RFC8415" format="default"/>.</dd>
          <dt>Supported Transport (16 bits): defines bits):</dt><dd>Defines the supported transport Supported Transport by the DM (see <xref target="sec-st"/>). target="sec-st" format="default"/>).
Each bit represents a supported transport, and a DM MAY <bcp14>MAY</bcp14> indicate the support of multiple modes.
The bit for DNS over mutually authenticated TLS (DomTLS) MUST <bcp14>MUST</bcp14> be set.</t>
  <t>Distribution set.</dd>
          <dt>Distribution Manager FQDN (variable): the (variable):</dt><dd>The FQDN of the DM encoded as described in Section 10 of <xref target="RFC8415"/>.</t>
</list></t> target="RFC8415" sectionFormat="of" section="10"/>.</dd>
        </dl>
        <t>It is worth noticing noting that the DHCP Option DHCPv6 option specifies the Supported Transport without specifying any explicit port. Unless the HNA and the DM have agreed on using a specific port - -- for example example, by configuration, or any out of band out-of-band mechanism -, -- the default port is used and must be specified. The specification of such default port may be defined in the specification of the designated Supported Transport or in any other document. In the case of DNS over mutually authenticated TLS (DomTLS), DomTLS, the default port value is 853 as per DNS over TLS <xref target="RFC7858"/> target="RFC7858" format="default"/> and DNS Zone Transfer over TLS <xref target="RFC9103"/>.</t> target="RFC9103" format="default"/>.</t>
        <t>The need to associate in the DHCP Option the port value to each Supported Transport in the DHCPv6 option has been balanced with the difficulty of handling a list of tuples ( transport, port ) as well as (transport, port) and the possibility to use of using a dedicated IP address for the DM in case the default port was is already in use.</t>
      </section>
      <section anchor="reverse-distribution-manager-server-option" title="Reverse numbered="true" toc="default">
        <name>Reverse Distribution Manager Server Option"> Option</name>
        <t>The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) provides the HNA with the FQDN of the DM as well as the transport protocols for the communication between the HNA and the DM.</t>
        <figure title="Reverse anchor="fig-rdm">
          <name>Reverse Distribution Manager Option" anchor="fig-rdm"><artwork><![CDATA[ Option</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_REVERSE_DIST_MANAGER   |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Supported Transport       |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                                                               |
/              Reverse Distribution Manager FQDN                /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t><list style="symbols">
  <t>option-code
]]></artwork>
        </figure>
        <dl spacing="normal">
          <dt>option-code (16 bits): OPTION_REVERSE_DIST_MANAGER, bits):</dt><dd>OPTION_REVERSE_DIST_MANAGER; the option code for the Reverse Distribution Manager Option (TBD3).</t>
  <t>option-len (147).</dd>
          <dt>option-len (16 bits): length bits):</dt><dd>Length in octets of the option-data field as described in <xref target="RFC8415"/>.</t>
  <t>Supported target="RFC8415" format="default"/>.</dd>
          <dt>Supported Transport (16 bits): defines bits):</dt><dd>Defines the supported transport Supported Transport by the RDM (see <xref target="sec-st"/>). target="sec-st" format="default"/>). Each bit represents a supported transport, and a an RDM MAY <bcp14>MAY</bcp14> indicate the support of multiple modes.
	  The bit for DNS over mutually authenticated TLS DomTLS <xref target="RFC7858"/> MUST target="RFC7858" format="default"/> <bcp14>MUST</bcp14> be set.</t>
  <t>Reverse set.</dd>
          <dt>Reverse Distribution Manager FQDN (variable): the (variable):</dt><dd>The FQDN of the RDM encoded as described in section 10 of <xref target="RFC8415"/>.</t>
</list></t> target="RFC8415" sectionFormat="of" section="10"/>.</dd>
        </dl>
        <t>For the port number associated to the Supported Transport, the same considerations as described in <xref target="o_dm"/> holds.</t> target="o_dm" format="default"/> apply.</t>
      </section>
      <section anchor="sec-st" title="Supported Transport"> numbered="true" toc="default">
        <name>Supported Transport</name>
        <t>The Supported Transport field of the DHCPv6 option indicates the supported transport Supported Transport protocols. Each bit represents a specific transport mechanism. A bit sets set to 1 indicates the associated transport protocol is supported. The corresponding bits are assigned as described in <xref target="tab-st"/> and <xref target="sec-iana"/>.</t>

<figure title="Supported Transport" anchor="tab-st"><artwork><![CDATA[
Bit Position | Transport Protocol |  Mnemonic | Reference
left to right| Description        |           |
-------------+--------------------+-----------+-----------
      0      | target="tab-iana" format="default"/>.</t>
   <dl spacing="normal">
     <dt> DNS over mutually  | DomTLS    | This-RFC
             | authenticated TLS  |           |
     1-15    | unallocated        |  -        |  -
]]></artwork></figure>

<t>DNS over mutually authenticated TLS (DomTLS): indicates (DomTLS):</dt><dd> Indicates the support of DNS over TLS <xref target="RFC7858"/>, target="RFC7858" format="default"/> and DNS Zone Transfer over TLS <xref target="RFC9103"/> target="RFC9103" format="default"/> as described in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>.</t> target="RFC9526" format="default"/>.</dd>
   </dl>

<t>As an example, the Supported Transport field expressing support for
DomTLS looks as follows and has a numeric value of 0x0001:</t>

 <artwork name="" type="" align="left" alt=""><![CDATA[
 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        must be zero         |1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  ]]></artwork>
      </section>
    </section>
    <section anchor="sec-dhcp-behavior" title="DHCPv6 Behavior"> numbered="true" toc="default">
      <name>DHCPv6 Behavior</name>
      <section anchor="dhcpv6-server-behavior" title="DHCPv6 numbered="true" toc="default">
        <name>DHCPv6 Server Behavior">

<t>Sections 17.2.2 and 18.2 of <xref target="RFC8415"/> govern Behavior</name>

        <t><xref target="RFC8415" sectionFormat="of" section="18.3"/> governs server operation regarding option assignment. As a convenience to the reader, we mention here that the server will send option foo only if configured with specific values for foo and if the client requested it.
In particular, when configured configured, the DHCPv6 server sends the Registered Homenet Domain Option, Distribution Manager Option, the and Reverse Distribution Manager Option when requested by the DHCPv6 client by including necessary option codes in its ORO.</t>
      </section>
      <section anchor="dhcpv6-client-behavior" title="DHCPv6 numbered="true" toc="default">
        <name>DHCPv6 Client Behavior"> Behavior</name>
        <t>The DHCPv6 client includes the Registered Homenet Domain Option, Distribution Manager Option, the and Reverse Distribution Manager Option in an ORO as specified in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, <xref target="RFC8415" sectionFormat="bare" section="18.2"/> and 21.7 <xref target="RFC8415" sectionFormat="bare" section="21.7"/> of <xref target="RFC8415"/>.</t> target="RFC8415" format="default"/>.</t>
        <t>Upon receiving a DHCPv6 option option, as described in this document document, in the Reply
message, the HNA SHOULD <bcp14>SHOULD</bcp14> proceed as described in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>.</t> target="RFC9526" format="default"/>.</t>
      </section>
      <section anchor="sec-dhcp-relay" title="DHCPv6 numbered="true" toc="default">
        <name>DHCPv6 Relay Agent Behavior"> Behavior</name>
        <t>There are no additional requirements for the DHCPv6 Relay agents.</t>
      </section>
    </section>
    <section anchor="sec-iana" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="dhcpv6-option-codes" title="DHCPv6 numbered="true" toc="default">
        <name>DHCPv6 Option Codes"> Codes</name>
        <t>IANA is requested to assign has assigned the following new DHCPv6 Option Codes in the "Option Codes" registry maintained in: https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2.</t>

<figure><artwork><![CDATA[
Value Description                   Client ORO     Singleton Option  Reference
TBD1  OPTION_REGISTERED_DOMAIN       Yes            No               [This-RFC] at <eref target="https://www.iana.org/assignments/dhcpv6-parameters" brackets="angle"/>.</t>
<table anchor="tab-2">
  <name>Option Codes Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Client ORO</th>
      <th>Singleton Option</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>145</td>
      <td>OPTION_REGISTERED_DOMAIN</td>
      <td>Yes</td>
      <td>No</td>
      <td>RFC 9527, Section 4.1
TBD2  OPTION_FORWARD_DIST_MANAGER    Yes            Yes              [This-RFC] 4.1</td>
    </tr>
    <tr>
      <td>146</td>
      <td>OPTION_FORWARD_DIST_MANAGER</td>
      <td>Yes</td>
      <td>Yes</td>
      <td>RFC 9527, Section 4.2
TBD3  OPTION_REVERSE_DIST_MANAGER    Yes            Yes              [This-RFC] 4.2</td>
    </tr>
     <tr>
      <td>147</td>
      <td>OPTION_REVERSE_DIST_MANAGER</td>
      <td>Yes</td>
      <td>Yes</td>
      <td>RFC 9527, Section 4.3
]]></artwork></figure> 4.3</td>
   </tr>
  </tbody>
</table>
      </section>
      <section anchor="supported-transport-parameter" title="Supported numbered="true" toc="default">
        <name>Supported Transport parameter"> parameter</name>
        <t>IANA is requested to maintain has created and maintains a new registry of called "Supported Transport" under the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry at <eref target="https://www.iana.org/assignments/dhcpv6-parameters" brackets="angle"/>. This registry contains Supported Transport parameter parameters in the Distributed Manager Option (OPTION_FORWARD_DIST_MANAGER) or the Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The different parameters are defined in <xref target="tab-st"/> in <xref target="sec-st"/>.</t>

<t>The Name of the registry is: Supported Transport parameter</t> target="tab-iana" format="default"/> (<xref target="supported-transport-parameter" format="default"/>).</t>
        <t>The registry description is:  The Supported Transport field of the DHCPv6 option is a two octet two-octet field that indicates the supported transport Supported Transport protocols. Each bit represents a specific transport mechanism.</t>

<t>The parent grouping is Dynamic Host Configuration Protocol for IPv6 (DHCPv6) at https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2.</t>
        <t>New entry MUST entries <bcp14>MUST</bcp14> specify the bit position, the Transport Protocol Description transport protocol description, a Mnemonic mnemonic, and a Reference as defined in <xref target="tab-iana"/>.</t>

<t>The initial registry is reference as specified shown in <xref target="tab-iana"/>.</t> target="tab-iana" format="default"/>.</t>
        <t>Changes of to the format or policies of the registry is left to are managed by the IETF via the IESG.</t>
        <t>Future code points are assigned under RFC Required as per <xref target="RFC8126"/>.</t>

<figure title="Supported Transport" anchor="tab-iana"><artwork><![CDATA[
Bit Position | target="RFC8126" format="default"/>. The initial registry is as specified in <xref target="tab-iana" format="default"/> below.</t>
<table anchor="tab-iana">
  <name>Supported Transport Protocol |  Mnemonic | Reference
left Registry</name>
  <thead>
    <tr>
      <th>Bit Position (least to right| Description        |           |
-------------+--------------------+-----------+-----------
      0      | DNS most significant)</th>
      <th>Transport Protocol Description</th>
      <th>Mnemonic</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>DNS over mutually  | DomTLS    | This-RFC
             | authenticated TLS  |           |
     1-15    | unallocated        |  -        |  -

]]></artwork></figure> TLS</td>
      <td>DomTLS</td>
      <td>RFC 9527</td>
    </tr>
    <tr>
      <td>1-15</td>
      <td>Unassigned</td>
      <td></td>
      <td></td>
    </tr>
  </tbody>
</table>
      </section>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations in <xref target="RFC8415"/> target="RFC8415" format="default"/> are to be considered.
The trust associated with the information carried by the DHCPv6 Options options described in this document is similar to the one associated with the IP prefix - prefix, when configured via DHCPv6.</t>
      <t>In some cases, the ISP MAY <bcp14>MAY</bcp14> identify the HNA by its wire line, that is to say physically line (i.e., physically), which may not require to rely relying on TLS to authenticate the HNA. As the use of TLS is mandatory to be used, mandatory, it is expected that the HNA is will be provisioned with a certificate.
In some cases, the HNA may use a self signed self-signed certificate.</t>
    </section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>We would like to thank Marcin Siodelski, Bernie Volz and Ted Lemon
  </middle>
  <back>

<displayreference target="I-D.andrews-dnsop-pd-reverse" to="PD-REVERSE"/>
<displayreference target="I-D.sury-dnsop-cname-plus-dname" to="CNAME-PLUS-DNAME"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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"/>

<!-- draft-ietf-homenet-front-end-naming-delegation-27
companion document in AUTH48 as 9526 - checked title (no changes)-->
<reference anchor="RFC9526" target="https://www.rfc-editor.org/info/rfc9526">
<front>
<title>Simple Provisioning of Public Names for their comments on the design Residential Networks</title>
<author initials='D' surname='Migault' fullname='Daniel Migault'>
<organization />
</author>
<author initials='R' surname='Weber' fullname='Ralf Weber'>
<organization />
</author>
<author initials='M' surname='Richardson' fullname='Michael Richardson'>
<organization />
</author>
<author initials='R' surname='Hunter' fullname='Ray Hunter'>
<organization />
</author>
<date year='2024' month='January' />
</front>
<seriesInfo name="RFC" value="9526"/>
<seriesInfo name="DOI" value="10.17487/RFC9526"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9103.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7368.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7227.xml"/>

	<!-- [I-D.andrews-dnsop-pd-reverse] IESG state Expired as of 01/22/24. Entered the DHCPv6 options.
We would also like long way to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their remarks on get the architecture design. The designed solution has been largely been inspired right intials and date -->
<reference anchor="I-D.andrews-dnsop-pd-reverse" target="https://datatracker.ietf.org/doc/html/draft-andrews-dnsop-pd-reverse-02">
  <front>
    <title>Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation</title>
    <author fullname="Mark P. Andrews" initials="M." surname="Andrews">
      <organization>ISC</organization>
    </author>
    <date day="5" month="November" year="2013"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-andrews-dnsop-pd-reverse-02"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6672.xml"/>

<!-- [I-D.sury-dnsext-cname-dname] Replaced by Mark Andrews’s document <xref target="I-D.andrews-dnsop-pd-reverse"/> [I-D.sury-dnsop-cname-plus-dname] IESG state Expired, as well as discussions with Mark.
We also thank Ray Hunter and Michael Richardson for its reviews, its comments and for suggesting an appropriated terminology.</t>

</section>
<section anchor="contributors" title="Contributors">

<t>The co-authors would like to thank Chris Griffiths and Wouter Cloetens that provided a significant contribution in the early versions of the document.</t>

</section>

  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC8174;
&I-D.ietf-homenet-front-end-naming-delegation;
&RFC8415;
&RFC7858;
&RFC9103;
&RFC8126; 01/22/24-->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.sury-dnsop-cname-plus-dname.xml"/>

      </references>

    <references title='Informative References'>

&RFC7368;
&RFC7227;
&I-D.andrews-dnsop-pd-reverse;
&RFC2181;
&RFC1034;
&RFC6672;
&I-D.sury-dnsext-cname-dname;
    </references>
    <section anchor="sec-scenario" title="Scenarios numbered="true" toc="default">
      <name>Scenarios and impact Impact on the End User"> User</name>
      <t>This appendix details various scenarios and discuss discusses their impact on the end user.
This appendix is not normative and limits the description of a limited scope of scenarios that are assumed to be representative. Many other scenarios may be derived from these.</t>
      <section anchor="sec-scenario-1" title="Base Scenario"> numbered="true" toc="default">
        <name>Base Scenario</name>
        <t>The base scenario is the one scenario, as described in <xref target="sec-overview"/> target="sec-overview" format="default"/>, is one in which an ISP manages the DHCPv6 server, the DM DM, and RDM.</t>
        <t>The end user subscribes to the ISP (foo), and at subscription time time, it registers for foo.example as its Registered Homenet Domain foo.example.</t> Domain.</t>
        <t>In this scenario, the DHCPv6 server, DM DM, and RDM are managed by the ISP ISP, so the DHCPv6 server and as such can provide authentication credentials of the HNA to enable secure authenticated transaction with the DM and the Reverse DM.</t>
        <t>The main advantage of this scenario is that the naming architecture is configured automatically and transparently for the end user. The drawbacks are that the end user uses a Registered Homenet Domain managed by the ISP and that it relies on the ISP naming infrastructure.</t>
      </section>
      <section anchor="scenario-2" title="Third Party numbered="true" toc="default">
        <name>Third-Party Registered Homenet Domain"> Domain</name>
        <t>This appendix considers the case when where the end user wants its home network to use example.com but does not want it to be managed by her the ISP (foo) as a Registered Homenet Domain.
This appendix still considers Domain, and the ISP manages the home network and still provides foo.example as a Registered Homenet Domain.</t>
        <t>When the end user buys the domain name example.com, it may request to redirect the name example.com to foo.example using static redirection with CNAME <xref target="RFC2181"/>, target="RFC1034" format="default"/> <xref target="RFC1034"/>, target="RFC2181" format="default"/>, DNAME <xref target="RFC6672"/> target="RFC6672" format="default"/>, or CNAME+DNAME <xref target="I-D.sury-dnsext-cname-dname"/>. target="I-D.sury-dnsop-cname-plus-dname" format="default"/>.
The only information the end user needs to know is the domain name assigned by the ISP. Once the redirection has been configured, the HNA may be changed, and the zone can be updated as described in <xref target="sec-scenario-1"/> target="sec-scenario-1" format="default"/> without any additional configuration from the end user.</t>
        <t>The main advantage of this scenario is that the end user benefits from the Zero Configuration zero configuration of the Base Scenario base scenario in <xref target="sec-scenario-1"/>. target="sec-scenario-1" format="default"/>. Then, the end user is able to register for its home network an unlimited number of domain names provided by an unlimited number of different third party providers. third-party providers for its home network. The drawback of this scenario may be that the end user still needs to rely on the ISP naming infrastructure. Note that the only case this may be inconvenient is when in the case where the DNS servers provided by the ISPs results result in high latency.</t>
      </section>
      <section anchor="scenario-3" title="Third Party numbered="true" toc="default">
        <name>Third-Party DNS Infrastructure"> Infrastructure</name>
        <t>This scenario considers that involves the end user uses using example.com as a Registered Homenet Domain, Domain and does not want to rely relying on the authoritative servers provided by the ISP.</t>
        <t>In this appendix appendix, we limit the outsourcing to of the DM and Public Authoritative Server(s) to a third party. The Reverse Public Authoritative Server(s) and the RDM remain managed by the ISP as the IP prefix is managed by the ISP.</t>
        <t>Outsourcing to a third party third-party DM can be performed in the following ways:</t>

<t><list style="numbers">
  <t>Updating
        <ol spacing="normal" type="1">
	  <li>Updating the DHCPv6 server Information. information. One can imagine a GUI interface that enables the end user to modify its profile parameters. Again, this configuration update is done once-for-ever.</t>
  <t>Upload only needs to be performed one time.</li>
          <li>Uploading the configuration of the DM to the HNA. In some cases, the provider of the CPE router hosting the HNA may be the registrar registrar, and the registrar may provide the CPE router already configured. In other cases, the CPE router may request the end user to log into the registrar to validate the ownership of the Registered Homenet Domain and agree on the necessary credentials to secure the communication between the HNA and the DM. As described in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>, target="RFC9526" format="default"/>, such settings could be performed in an almost automatic way as to limit the necessary interactions with the end user.</t>
</list></t> user.</li>
        </ol>
      </section>
      <section anchor="scenario-4" title="Multiple ISPs"> numbered="true" toc="default">
        <name>Multiple ISPs</name>
        <t>This scenario considers a involves an HNA connected to multiple ISPs.</t>
        <t>Suppose the HNA has been configured each of its interfaces independently with each ISPS ISP as described in <xref target="sec-scenario-1"/>. target="sec-scenario-1" format="default"/>.
Each ISP provides a different Registered Homenet Domain.</t>
        <t>The protocol and DHCPv6 options described in this document are fully compatible with a an HNA connected to multiple ISPs with multiple Registered Homenet Domains.
However, the HNA should be able to handle different Registered Homenet Domains.
This is an implementation issue issue, which is outside the scope of the current this document.</t>
        <t>If a an HNA is not able to handle multiple Registered Homenet Domains, the HNA may remain connected to multiple ISP ISPs with a single Registered Homenet Domain. In this case, one entity is chosen to host the Registered Homenet Domain. This entity may be one of the an ISP or a third party.
Note that having multiple ISPs can be motivated motivation for bandwidth aggregation, aggregation or connectivity fail-over. failover.
In the case of connectivity fail-over, failover, the fail-over failover concerns the access network network, and a failure of the access network may not impact the core network where the DM and Public Authoritative Primaries are hosted. In that sense, choosing one of the ISP ISPs even in a scenario of multiple ISPs may make sense.
However, for the sake of simplicity, this scenario assumes that a third party has been chosen to host the Registered Homenet Domain. Configuration is performed as described in Appendices <xref target="scenario-2"/> target="scenario-2" format="counter"/> and <xref target="scenario-3"/>.</t> target="scenario-3" format="counter"/>.</t>
        <t>With the configuration described in <xref target="scenario-2"/>, target="scenario-2" format="default"/>, the HNA is expected to be able to handle multiple Homenet Registered Domain, Homenet Domains as the third party third-party redirect to one of the ISPs ISP's servers. With the configuration described in <xref target="scenario-3"/>, target="scenario-3" format="default"/>, DNS zone zones are hosted and maintained by the third party. A single DNS(SEC) Homenet Zone is built and maintained by the HNA. This latter configuration is likely to match most HNA implementations.</t>
        <t>The protocol and DHCPv6 options described in this document are fully compatible with a an HNA connected to multiple ISPs.
To Whether to configure the HNA or not not, and how to configure the HNA HNA, depends on the HNA facilities. Appendices <xref target="sec-scenario-1"/> target="sec-scenario-1" format="counter"/> and <xref target="scenario-2"/> target="scenario-2" format="counter"/> require the HNA to handle multiple Registered Homenet Domain, Domains, whereas <xref target="scenario-3"/> target="scenario-3" format="default"/> does not have such a requirement.</t>
      </section>
        <section anchor="acknowledgments" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>We would like to thank <contact fullname="Marcin Siodelski"/>, <contact fullname="Bernie Volz"/>, and <contact fullname="Ted Lemon"/> for their comments on the design of the DHCPv6 options. We would also like to thank <contact fullname="Mark Andrews"/>, <contact fullname="Andrew Sullivan"/>, and <contact fullname="Lorenzo Colliti"/> for their remarks on the architecture design. The designed solution has been largely inspired by <contact fullname="Mark Andrews's"/> document <xref target="I-D.andrews-dnsop-pd-reverse" format="default"/> as well as discussions with <contact fullname="Mark"/>. We also thank <contact fullname="Ray Hunter"/> and <contact fullname="Michael Richardson"/> for their reviews and comments and for suggesting appropriate terminology.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="default">
      <name>Contributors</name>
      <t>The coauthors would like to thank <contact fullname="Chris Griffiths"/> and <contact fullname="Wouter Cloetens"/> for providing significant contributions to the early draft versions of this document.</t>
    </section>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAILrX2MAA+0823Ibt5Lv/Aqs/bBSQtKW5KuqtnJkSYlVZV1CyXHlbG2l
wBmQRHk4wzOYEUNf8i37Lftl2xcAAwxHlGQ7Z1Nbh6lY5FyARt+70Y3BYNDr
VbrK1L44en14cf1MnC8qXeRGTIpSvC7mSpypalmU78WZnOt8Kg7qalaUulr1
5HhcquvuF88OemmR5HIOA6elnFQDrarJYAYD5qoa5DTWQJbJTFcqqepSDdJZ
Mih4jMHuk55elPuiKmtT7T5+/PLxbk+WSu6Lk7xSJQzRW073CT78/n7Z3Bgc
4XS9RFb7wlRpLylSmGpf1DD9i15vofd7QpSTRKWmWuG6V8rAlapIgq86T1Ve
uQumKKtSTYz/vZpHP6tSJ/7hpJgDUJW/q/NM534aQMpcLhYEEV7pSUInwoSf
gf2Lr8EIR0Nxqqeyzip/nVF6JHOtsrWbRQnDHgM0xhS5vwrwKQXwvdh9/lRc
lRJodChzmUoxKupK+ecSIOq+uJQ6r8QbCSTJq774+bC5X6Qw9ZNL8fjVs+Bi
nVclvMdD+utqLnUGtCdAh3MG9G/KwjYELHUveTQU79RYla0Fj2Q2ad2gxR68
lzBRe6nxkuIFrEHeBrmEqYZLnOpvkka/GdgroE9ZT2Vm3usWwFfAmu877hLU
jlfF5cpUag70AKYHJtP1vA83k+Ea7V4+fSwOZ7KE98QlXWuRbaTSZVGk4hAl
M6bYyyePn+2tE+ztZXvlVTGX5sNw7oD+2xSv0/J7vcFgIOQY4JFJ1etdzbRB
Zq6R10WqJsDjxmkCK8UgN0I6GV1TH2ILlMS2SGQuQAZg5konMstWYlEWiVIp
QCOqmRIgLWWxKLWsFMCeT/S0LiWOL2SeCmBgU9RlovhZOzjcv1aClYwwqrzW
8ADqJXwIdZDIWakNeye5mBemAjiMMn16wI2JL89VMgMWNnMB661QdhYSBcOP
pgCIGqYYMobmOk0zBeh6KK5UCfMXWTFdIb6UeK9WAiZNjXhw+vby6kGf/4qz
c/o+Ov757cno+Ai/X74+ePPGf+nZJy5fn799c9R8a948PD89PT474pfhqogu
9R6cHvwKdxBhD84vrk7Ozw7ePAAWhhWEZISVIdbHCm4Boy1KVQEdpOmlyiSl
HsMPeOfV4cX//PfOE/Hx47+Nfjzc3dl5+fmz/fFi5/kT+LGcqZxnK3IgKP8E
ZIHJWCyULHEUIDXgfAG0ygDtEphlVixzMVOlAlQSvkDfp8DucKPOUoRqAgTN
NLy/1NUMpzwZHA0juzIpi7waAE2chUlVpqbELp8/D5EqIHplkdYJXur17j2G
MAuV6IkGZgd4YY3AABVyM6BIT3PJCCPOuIXxPecaEJKLepzpxL/y9yInSsDw
R2eX4jxgyJN8UkqQwpqMptg6Oj/ZHq7LI9PLAum4nYQNpOlaG5QfAvLsgLEp
3coSAUMOecDEYR6YHsSzzmQJ9AR2n9QZSYDEh+kuXJ+DBZjC+scrBPzk8qIv
UEgKuPE+FjsDtDVASoQV7iMQpVpkMlEI/lAQ+WEAYVGPOIIRLwB40DS/O9UQ
DolYXypgKot9CWYm0UQPcFJUaZT4AFgd+qFRnmc1DLxEti8mLPrLHDiOfsiq
mZCZGZm0TmaAD9CIRDagNygjZOQ81SlqKETKDPQJkipkgpGFgSg74OE1Q+pu
HWl0JMY16bZTwmUptkZHp9s0+6KokNVIRYavWdY5iFTfJeg8uAuMAfpNpqnG
Qfu4bgOrg4GERgdHT3gs9FAcCiKkWtZAkwZUucTV43cEHbggdVpQl6wxcsCF
e5W5gdixWChW2YZWAi/nRWWHXZ+TaTCTyCRTwAloBDQGoKoR+rlciQyXDoMz
OXQsEYQr5PG0Y+w2q6dgd0AZESCxBAPI99cwgbkbNbAf0STD3qUG9UUSZPk3
ZExLHORFz5HLWYHYMMwuIay4SMQEs+K9OLGDA7s5zzEePnELk92kfVr+AM2p
cjnOlNUQiImQWLkCfWhkuUKdAgsFBBqHLdASffs8+gfD3mkBaHKkRLlg843D
2jGdgHlSOCQwSfrBfMBFRTlnx8LqxqNTv36QQvRmnMZEPcr8TU/Ui6yQEaIi
ZPtBYomNnzEiMrJfYtxQs4FUIue0EI+sQkoYwYidKOCfRQZ4Rq4M3BuLc+fd
hFKFis8wK5MkZqQ5MFBzuhcXROqhRd1GgQ/IKWhsETx7rSWBPSTn6QKJnKI8
n1+j/6aW4uNDoyBCtD8/W66Da7QOnWU1OqeVN3psVRIFrGpazBUS280b8mkR
+JW6Mpv9Sosqspo/Wq/QILIBLYCnBdAarD6bEBOqgHvTuM/+mlsymLh6rqxY
OdZ0zBapPbu+hC0uapcE/NKEdJ1ldnEI6IN3SnGcAltvHV4cb4sS40PUgz+A
c/d879kL5LMzMETgvpE40MQAklXpIBOge4py5cGIZ0Y+hMCJdDXQZl4w3+H0
gSMCXAEheJHx+EugLLogpsLBy1R/YAnBtyY1qvxhbORuwBGqW7MA8mpUP9Zr
c168BdOQRsPVhJxJYAUKAZVByEGD0NnwD5fqH7UyeOlG/SOsmzVXGJPLDQ+i
whmrznkiDDtdbBJQs6UucCljBbeuWRrHLIgU8SyKBTp0/llyuyI9XigmK5hF
UrX2QYPCW6oOxPk3ZhLkBIK2aw3cSy5YZh2AEJmAfMAluWSgtigCI+ZMtUlq
Y5wmRLF3cyMDkhvSAJMWNKWTbg0chbjXZVvVtUM2IibFn8jMgJoPqiwG/I5V
px6PCTJOSqRxYZPXPAb13qTIsmJp9nu9naG4ssKoDbEvmeCiFat2WQGbcms7
jNYhjmWJ3HNeHtNW50lWpxi7kc7idByMQ2zofm6dj863N1vF5lGKFH8bHf90
cnl1DJHpb0fnpwcnZ9tsZ0HXgaOSdnsPrTF+PB+9OxjBADDSb6cHZwc/HY+2
1wzjXUYaHf9yPLo8bo3EmpvyHeiP7DIJYuZk8U+9PxGjs0NuW1ZhLE2jLq37
rOGKVd3DDhotQGCt8gkVRuPQAKx7EbugpcGRWTdvGYVuFvPZA/hSl86dOyww
kM0wKZTnKnuA1ubeBmUbY7V1V8fyG4I0rnWWxvEsceqWlaUudt123gKlcb6B
ZxMg1hGj22nM0XmjJ8AVDjzICICDxQJmAifk1RfhbOhxg9aM3SdSl2u+lVV2
zjLFIKHbwXoflddKuSQa+LVfCWDgf1N8FHrSaFAR7Ar9E4Mugg+FEHcAAqZp
xbXMakXpkii3b10wZuS2A5aqSuqMWWUhV+QR25CyRTtWlY6RpzXQMaP0Ia2W
XI3d3eecr3l4u576+LD4rUw/s8JeC7tu12bAEynJG8P+489HZ52GNs4b9np/
/PFHTzwW65+djmu7Hdf28PUduLUnnoin4pl4Ll6Il/e51vt+8JX/9T4BIDeh
BoH85MFl8g0y8NuDz6dvBMPXfD71HnVcvZlx1j+PvgEMX48H5KiP+w9BgwzK
GWhj3Jf7jwc3sfQDYPnvHFXQ8omtnWdiDLZ/e/9GktoMd2MuvVe0AV1bV6+O
djDL+F3IBMFs8HNaYSZGFEmlKuME/+YxwXJmnbYBs8hPdp6S9H+3YYCta/DL
MJMA03uxDRJGYbYfX1M5rnZ9Smdddx5bZRsCgPrnLm4OqqB0blXQ2gsw0b3c
oih54eMiv0inVE/bKU+O34uy8hGU8WjAXck6RzWH849BiynVZIB9tAbO+AFQ
b7EobPgOITvYL3Cd/O6IRTQ52Bi0YIIavhVZbYeeYKwAHhQQR5uZU/N3BkD0
XhdL9CZ4OpvQkDyvR80czJReYB4pvZZ5BcgFsNHLCwGGeFyXpsLEkK4oAWJC
e2SJoaTRivLUYCkNp2vMXGYZXBzAQtBAUtaVUhYnF9dP6JETHKKZiwIX9Ts8
XPlQy0Kbsj+VN+jDoKOEeQvMha0oukVsSMTnnEKtipJk3stEInIGPKBGQH4I
mgvKwNKuQeNwRF6nM/5jZVP4/TiOpuyaJ9w92eZ+5pA+f2WbuEFAQ5vYbRS/
nU28rBco0MBRV1647Rxfb49uHeFPscudepTFYv3zl7PL6dyZ5TvYBbTQt5ro
Lha72UrfKegGc737JeYabGRGij+VlbzdOHcxZzCLKwqgfKh/tDFSTehJYa7N
81QQlQ57xxL32TQmCReg7rCeBrPO66PYnTkc5fTgV+/Kh5Pi6ry5mHOGAO00
Do9oRQNGpmMOWpAUfRyEX725FFvgdcDfbUEb9qSvK8JBJx2ImTsdlMZ2f5E/
ckJpHwhAgHoQNuqEratN/6JZczzQbFNTdrWLVOhVFHVlH13hUDJfoQ2jjLXA
h4bibZ6BuelQ+Zzjk9NScVakNjRCE1DSJANCsfpdYpiMJI8iZNogxkkRDlju
mPa1fMnFgOXARaU0oNt5pCdxz2HsY1g0tJS0c1tCvJkz4TA4GsWaQRtyOzO4
9iLP7rcFu7BYcDUDrgGeLn32lJLSZEKl3ZK5B5t1rJtCcly9ePF0z21Q+jHx
ZeaV5y+evsCNSEAP3qVkDUE7wY3t+NmXO4/3/M5RbmtufOjrsBKyFQX3DTjo
L6CkdiEGN3DH6C2MZSbzJIykUz2ZYDVBtULEALHTjHkH/A7ig6oGbjFiK5Rz
GnS77fOCo2r0WGeYzAdo0FuUgLjUIrVxmJpUPybvmSprSF6iK5Vh3QnuU+Bo
4LpxEmJDhpL3QS2KXBriazOa/7dBwP8vb24DosW/vLm7fta8uY1M3uXQ/TW8
OevOCc6zNA7dHWSWHLo7JF3W+WxT3uUOqgI8ur0v8ejs0+TP3THl8m28utG3
cetGf7JfF9nMtm93O39v8vFGG5w8s8nJczUEtMa8no9xp7LJR9vNow4y9W3p
wVz57UpXdbVGdMpXfRazIksN59m76M75flPZzFbXI8xVXYn+Vl69i1m8ibqR
NZwz2bzj3UMwzQf0hkGGB7TstGYMkbY2JbpSHiRmnKQo7R4heiNjKvwoaRhw
ADt3sio5JtYmbmVO18AfREbUMq8AuovCUDYGdHyDtQsHBSjE01zNC7DK8H2k
wEsDplG9TE2oCKfU01n1SRzRvIxWpwojtTgIP98POj7f3/DdFoE/dqOuiw1e
JL+UH8BdnwEwbE+En08d0hXDKAS/sTPYecoX6hzGt2UozVOD8LuLvRnTTlV3
MOIDAUx6m8hHTvZ+N4NGvjrriB+8juhvcqrtk+xVf5OKrmYD7pWCcEuDZmCR
TGfJYjC21z6T/NoHrTPqnu/1bEBpxM7z4e5wl1h15wV8aWkeMcWF5G633Nds
YlIdy25AJKxcs0BwkHOAUgra5lrlGhm3KW3E2u0+uKYCH8TXbM2IDVbtNFTd
Y7Aiww4+KQquGteTsL6BvF+vDSj6YL8Wn6eiUtZAduO92cTXHIk1Bcx9zuOG
tRNrpQII0C21g9Y09zfZ7f6dDTyB1ADtUiNRMcF4ZUs8kBTNnndY+uBrP0bn
dvfCDnHIQzRc0VFPwuUj5p+1ZIqaEVKqq3YRfJACMcSmw50+/921f5/Yv0/t
32fsK+zuDJ93GNO3C+JgrALkEDM2UZGExs0QNvodqUW26s0R2VPV98GSbcC4
ucjhC2TdU2ukMrkSB9OQZKHgYzXVim0y2if4P4+y/nZ3htrQ2iVuPLbEsQ03
RICDSv1Hgb/Ac5EpiwCzpDskXuv16FVtAsbl/AFoB95W8Bv9uVp2jmGRzPt2
JRap6rySNiezL2ZVtTD7jx4tl8shQjMsyumjRv2YR4iO62eDpsRh/crw91k1
zx6uXR/sWiP9C6UyOixs8LHyg9yKn0tYU6aqwlcXBJYb90o3b6nD51dYe/A5
K1rz/aczsv/lE4JPhjs49u4texNrY7d+3jD2Lo69J24Jlb9s7D1C800+pqfI
TQzleIL6WJYNr4Cwbx7P5a++dB/2PgHaplwOZyUx6aVKrgrzBTlU7dgkIQOP
sql8rHyK7gxde+tqezRos78ZD66Zyj6fBoyO74ov8ezR6lfLgqNN+yR3FNzD
5xdf4vTzamyV+rQsauylRYCOVqhXsaAS/MTDqPDTe9uoC2nfdovXsy0A5D9d
yZwB1yrsueQI0+bbCUFjyrMb3ZjOjhghVE2yCRdshOwUD9ugFiv5aOSKShA1
9g+FrLNme1uvYXXhVPl0guDdZJSMRYG7BM2tcFAXvOD1k+OrH6nYjX9c/oQR
Lm03cxqE9q1bgVadY98faBGqXtVl1JFDbYa7z/4VY327GCsMspD0t4VZDwWX
olarTseB7gziFITNILi77QRFKxEVdKI2hdccpLtGk/X6vLDWIZFlqdccaXdC
wSavz/jeFsvA3J2zPt1aM0sQUTQ9JdyBR5WWQYcxtihRWitswqNy2xX570ss
XseayL7wfVqFMOC4LWYrY/uklzMN2hN3srCC1JW8Iz9jUwUgAdkDHbKAZ3zd
scDIDR/A9gPftcEox/01qpiBe01Fy8zXKK/1RkAEqMqKd85wx6Rjxa5eljdo
jMqwN4aEPXyVIt6D5H1eLDOVTkn99nrvlFhSI2qm39sAU+bvwQRjRyz4YqBG
sFu9D75yCVGo+KXIPpB2vILh36DgB32K7ngGV8jN23vdlarDZmpqEVib/704
yNNSLWGR/AUMaZbpa8nN6W8KUDQfChASuFjpAApwziW2wVogwnMwLETWaVAW
S76+ym+rAYtOFRUPYTcnSCfpSWCgEK5/D1j748cfMCiRfGeQ5qZYDBbpwHYh
csrCbSXZFoymihlHJXy4zh/AwAgI+rqmsiNc7inwo1SZGOHfMjUW78jQMIcm
NOEPTwJ8CZ8w9RSMTMU70GHDP7Bd00RP0QqVvaMTVpSmZ7N2A27PMp1ccjgr
gWV/KnHLsZrxnO+4rekwK8BIu75EV6xF3W3TnFgSsJa4CW3MSnUS1MGFWCP8
uI1iv/PLRwGMZfKedKXvVKE8xXwhk8oR/hiuvMVWFJtpdV0utrZaukpwV1yN
+eaiNkH3C45piWV5K56hOZ8gHtF2bOWsMq+57C0D1VcZJxfeGlL9Hd1DTkyK
Bfe2eRgIf9aCAwpc+Zt36miCIfrMbpe8edfvxJcae5QgSp7j/EZxVvoV7tM6
DLawNNixVgU7M6KWJ6e3WzF51D9ILjbrUNuLyh2dUYkg54P6fq+Vu7+sP+X7
iEw9dhX3zuuB4bYmRbFtNzIq94zdRtdz5YtVfR5r6MokQP6QDBuqZ5uH2cBU
YdNXv2sFQe8aUiro1XfwmmL9vajv3Z8ekKrQqJC9BSC5O92LA2p8rA/gdl8y
/Krlv5B/LzlMbDfZRZGXwzgt3ld88kytbjefYLRdmpFqjXum4mNHaNKmAzZb
rfWLsQOSlnKJos0+q5/OM0NNxaAbiNeBel4wGno05Bm51bm/a1cS97mzeIBM
l6m4kCW4VDfPCGLjRGZ3TbU4B8s01SpLV6zqF7WUqK+RKaO+Ultx4VgRFLtr
A3UrRGH3wsCVqjfC2VZRYBHwkJAIvracxkdAYOUuveSrJ1pitXH23ru1dY/r
lVWHQfN9sFxbWLxyGQt2v1IwxYnnwhg/8EAIE1dNGVSRiX/Ty8Ph2cHpsd1W
2N15sYMbEPxr5/HeE96OaJ549uz5Lqg14Fp673t/D82+qcsV2nz1ezWgc7ng
B/zr+pk45R5VCwdowNog0m3omTkFG51H4EK3hqmHvfPctjqG6/L+SyOIsYeI
Pj9FnfY6Ho7g+l/rRerOZ1jrDAVr8NnXtKGlCRKirT5Qa2PCs3vuq10aDgEW
mqBg+FH/rsqilYCwKrFlzNbAJ1LYPICfACUCNShxFvOud6ta3A/BnrPSdt8Y
Jg7IZBonh89o6Xze56kqUi4LUi72xdLESnAdSZaE64hiwXSxyS26jXrM/RjE
nLZiS3uXQed+34nLIp30YnTN5itesJ2TDp+ps4p4aAaxP7jS4AYmK5uED3Uq
DtU6cSdQpnuf2+3WobLqNAyhKtisj9hz8B3VqIHD4I7ChuhYgg1LDpwEr12X
il06xnBwwpBrj2U7vOHkjy2zTfFlyCjDqPztlpfD0zUwIrrBOJpWvM0ha+sx
WOJ5vIgILlyOVSILVaKaa8o+m22KpVzZDu63qGlc70rsEp00WnIozq1y0nM5
xUN0pPjp7QkfhjORieVh9oFMzA6Y2S5SDP5RkoFoE52pIDc8FAdTYoNqFrgt
rE9YDwpKXGDbOCha7MocINq5/fltcyRJ0qWKAB1BF7LoiNidxLs3Di+O3XkQ
0bEyjdoO0oAyOjGk/b4rsWxMAEHAoUEAQvBKZGNbaITgEDFetACAC9cy48Nw
iMfxXCEz04vbu9PI68XKZidpzXZr6OliTob9WsbzXTucDr62NKDPDrlRFdIh
PKcr5G062YCOevCeLnI4CVQRCH94LgqgQyZB83LLTIJ6PHUlV6RKA234ZIM2
5NNY4Hfu+6Pm4TgwNCUbjc9QdTkKXGwM1NOkvK2M4ddUoVZjt53gpidh5MuO
rdl1s3tsnw6PuGns4CaX8YolhRPNVHQd9zpvSDVi+DCpMfTAJnKgDlp5m0/b
jC1+yl+6ET5Aa9RLh6M2p+k5r4Lqr9Vd1mush67pODbtOt+l3RMytbIBNTyA
FsWJvk8ZkJjUZcmni/h0ycnELtmdDBZDdoeFxi6ktSU3ItAfA0bbuJvo66wm
KqU+pRTswTF4DdSgosMcUB9u1igWcfZlqy+L5tA1BIqO04tMaeMFYQ0AnkYZ
cYG1Z/MCzCq5xegWYgvFUqe4vum0tBqD+iwsOvQ1HXwjdUa5kLU+he7HGMH+
Jz6VqDK3hXYJKpAoDJP0bN2crNd6xqWtbbKK9WcZHNTWnDCzwQ+5KMHultp2
XyIZcJvgxPY6AnWQakCngqKsFr5BLrgKpVFYYUWpP22ODs6isQJxorRlxyFP
sTMcndAU+yONersXG8VxhTaBxu9QdE3U70sUG98VN9DeOR0fOwkbxukLL2rR
9kDRoVI8Lm88FK/v2xYC1DQBdNGimXFO7vC+kO+52j0KJxtusSfp+aoT61BG
YnjgFAW8v3V5fLgdH4WCRyzVOqtuGIpOeSHphzCjYtGJSYgJaz4RDGw0bukg
HxCCIw1r3Lmo/3R7A/AXjRlGXUJaOk/ppLUqvOd4gw2yT2PhJbDV2KejsU67
I3TH4do86ze1mnzinW1Cn3UI8FfMBq1DqsiRCgqmEMn/C3XUdH0WXQAA

-->
</rfc>