<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.21 (Ruby 3.0.2) -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

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

<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.21 (Ruby 3.0.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-homenet-front-end-naming-delegation-27" number="9526" submissionType="IETF" category="exp" consensus="true" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="public-names">Simple abbrev="Public Names for Residential Networks">Simple Provisioning of Public Names for Residential Networks</title>
    <seriesInfo name="RFC" value="9526"/>
    <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>Nominum</organization>
      <address>
        <postal>
          <street>2000 Seaport Blvd</street> Blvd.</street>
          <city>Redwood City</city>
	  <region>CA</region>
          <code>94063</code>
          <country>US</country>
          <country>United States of America</country>
        </postal>
        <email>ralf.weber@nominum.com</email>
      </address>
    </author>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <postal>
          <street>470 Dawson Avenue</street>
          <city>Ottawa, ON</city>
          <city>Ottawa</city>
	  <region>ON</region>
          <code>K1Z 5V7</code>
          <country>Canada</country>
        </postal>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <author initials="R." surname="Hunter" fullname="Ray Hunter">
      <organization>Globis Consulting BV</organization>
      <address>
        <postal>
          <street>Weegschaalstraat 3</street>
          <city>Eindhoven</city>
          <code>5632CW</code>
          <country>NL</country>
          <country>Netherlands</country>
        </postal>
        <email>v6ops@globis.net</email>
      </address>
    </author>
    <date year="2023" month="February" day="08"/> year="2024" month="January"/>

    <area>Internet</area>
    <workgroup>Homenet</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>Home network owners may have devices or services hosted on their home network that they wish to access from the Internet (i.e., from a network outside of the home network). Home networks are increasingly numbered using IPv6 addresses, which in principle makes this access simpler, but their access accessing home networks from the Internet requires the names and IP addresses of these devices and services to be made available in the public DNS.</t>
      <t>This document describes how an a Home Naming Authority (NHA) instructs the outsourced infrastructure to publish these pieces of information in the public DNS.
The names and IP addresses of the home network are set in the Public Homenet Zone by the Homenet Naming Authority (HNA), which in turn instructs an outsourced infrastructure to publish the zone on behalf of the home network owner.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t>Home network owners may have devices or services hosted on their home network
that they wish to access from the Internet (i.e., from a network outside of the
home network).
The use of IPv6 addresesses addresses in the home makes makes, in principle principle, the actual network access simpler, while on the other hand, the addresses are much harder to remember, remember and are subject to regular renumbering.
To make this situation simpler for typical home owners to manage, there needs to be an easy way for the names and IP addresses of these devices and services to be published in the public DNS.</t>
      <t>As depicted in {fig-outsourcing-overview}, he <xref target="fig-outsourcing-overview"/>, the names and IP address of the home network are made availble available in the Public Homenet Zone by the Homenet Naming Authority (HNA), which in turn instructs the DNS Outsourcing Infrastructure (DOI) to publish the zone on behalf of the HNA.
This document describes how an HNA can instruct a DOI to publish a Public Homenet Zone on its behalf.</t>

<t>The
      <t>This document introduces the Synchronization Channel and the Control Channel between the HNA and the  Distribution Manager (DM), which is the main interface to the DNS Outsourcing Infrastructure (DOI).</t> DOI.</t>
      <t>The Synchronization Channel (see <xref target="sec-synch"/>) is used to synchronize the Public Homenet Zone.</t>
      <figure title="High level architecture overview anchor="fig-outsourcing-overview">
        <name>High-Level Architecture Overview of outsourcing Outsourcing the Public Homenet Zone" anchor="fig-outsourcing-overview"><artwork Zone</name>
        <artwork align="center"><![CDATA[
                               Internet
.---------------------.           .-------------------.
|      Home Network   | Control   |        DOI        |
|.-------------------.| Channel   |.-----------------.|
||         HNA       |<----------->|  Distribution   ||
||.-----------------.||           ||  Manager        ||
|||  Public Homenet |||           ||                 ||
|||       Zone      ||<----------->|                 ||
||| myhome.example  ||| Synchron- |'-----------------'|
||'-----------------'|| ization   |         |         |
|'-------------------'| Channel   |         V         |
|                     |           |.-----------------.|
|                     |           ||  Public Homenet ||
'---------------------'           ||       Zone      ||
                                  || myhome.example  ||
                                  |'-----------------'|
                                  '---^--^--^--^--^---'
                                      |  |  |  |  |
                                 (served on the Internet)

]]></artwork></figure>
]]></artwork>
      </figure>
      <t>The Synchronization Channel is a zone transfer, with the HNA configured as a primary, primary server and the Distribution Manager configured as a secondary. secondary server.
Some operators refer to this kind of configuration as a "hidden primary", but that term is not used in this document as it is not precisely defined anywhere, but it has many slightly different meanings to many.</t>
      <t>The Control Channel (see <xref target="sec-ctrl"/>) is used to set up the Synchronization Channel.
      This channel is in the form of a dynamic DNS update process, authenticated by TLS.</t>

      <t>For example, to build the Public Homenet Zone, the HNA needs the authoritative servers (and associated IP addresses) of the DOI's servers (the visible primaries) of the DOI that are actually serving the zone.
Similarly, the DOI needs to know the IP address of the (hidden) primary (HNA) as well as potentially the hash of the Key Signing Key (KSK) in the DS RRset to secure the DNSSEC delegation with the parent zone.</t>
<t>The remainder of the document is as follows.</t>
      <t><xref target="terminology"/> defines the terminology.
<xref target="selectingnames"/> presents the general problem of publishing names and IP addresses.</t>

<t><xref addresses. <xref target="sec-deployment"/> briefly describes some potential envisioned deployment scenarios.
 And <xref target="sec-arch-desc"/> provides an architectural view of the  HNA, DM DM, and DOI as well as their different communication channels (Control Channel, Synchronization Channel, and DM Distribution Channel) respectively described in Sections <xref target="sec-ctrl"/>, target="sec-ctrl" format="counter"/>, <xref target="sec-synch"/> target="sec-synch" format="counter"/>, and <xref target="sec-dist"/>.</t>

<t>Then target="sec-dist" format="counter"/>, respectively.</t>
      <t>Then, Sections <xref target="sec-ctrl"/> target="sec-ctrl" format="counter"/> and <xref target="sec-synch"/> target="sec-synch" format="counter"/> deal with the two channels that interface to the home.
<xref target="sec-dist"/> provides a set of requirements and expectations on how the distribution system works.  This section is non-normative and not subject to standardization, standardization but reflects how many scalable DNS distribution systems operate.</t>

<t><xref target="sec-cpe-sec-policies"/>
      <t>Sections <xref target="sec-cpe-sec-policies" format="counter"/> and <xref target="sec-dnssec-deployment"/> target="sec-dnssec-deployment" format="counter"/> respectively detail HNA security policies as well as DNSSEC compliance within the home network.</t>
      <t><xref target="sec-renumbering"/> discusses how renumbering should be handled.</t>
      <t>Finally, Sections <xref target="sec-privacy"/> target="sec-privacy" format="counter"/> and <xref target="sec-security"/> target="sec-security" format="counter"/> respectively discuss privacy and security considerations when outsourcing the Public Homenet Zone.</t>
      <t>The appendices discuss several the following aspects: management (see <xref target="sec-reverse"/>) target="sec-reverse"/>), provisioning (see <xref target="sec-reverse"/>), configurations (see <xref target="info-model"/>) target="info-model"/>), and deployment (see <xref target="sec-deployment"/> and <xref target="sec-ex-manu"/>) aspects.</t> target="sec-ex-manu"/>).</t>
    </section>
    <section anchor="terminology"><name>Terminology</name> anchor="terminology">
      <name>Terminology</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <dl>
        <dt>Customer Premises Equipment:</dt> Equipment (CPE):</dt>
        <dd>
    <t>(CPE) is a
          <t>A router providing connectivity to the home network.</t>
        </dd>
        <dt>Homenet Zone:</dt>
        <dd>
    <t>is the
          <t>The DNS zone for use within the boundaries of the home network: 'home.arpa' "home.arpa" (see <xref target="RFC8375"/>).
This zone is not considered public and is out of scope for this document.</t>
        </dd>
        <dt>Registered Homenet Domain:</dt>
        <dd>
    <t>is the
          <t>The domain name that is associated with the home network. A given home network may have multiple Registered Homenet Domain.</t> Domains.</t>
        </dd>
        <dt>Public Homenet Zone:</dt>
        <dd>
    <t>contains
          <t>Contains the names in the home network that are expected to be publicly resolvable on the Internet. A home network can have multiple Public Homenet Zones.</t>
        </dd>
        <dt>Homenet Naming Authority(HNA):</dt> Authority (HNA):</dt>
        <dd>
    <t>is a
          <t>A function responsible for managing the Public Homenet Zone.
This includes populating the Public Homenet Zone, signing the zone for DNSSEC, as well as managing the distribution of that Homenet Zone to the DNS Outsourcing Infrastructure (DOI).</t> DOI.</t>
        </dd>
        <dt>DNS Outsourcing Infrastructure (DOI):</dt>
        <dd>
    <t>is the
          <t>The infrastructure responsible for receiving the Public Homenet Zone and publishing it on the Internet.
It is mainly composed of a Distribution Manager and Public Authoritative Servers.</t>
        </dd>
        <dt>Public Authoritative Servers:</dt>
        <dd>
    <t>are the
          <t>The authoritative name servers for the Public Homenet Zone.
Name resolution requests for the Registered Homenet Domain are sent to these servers.
Some DNS operators would refer to these as public secondaries, and for higher resiliency networks, networks are often implemented in an anycast fashion.</t>
        </dd>
        <dt>Homenet Authoritative Servers:</dt>
        <dd>
    <t>are
          <t>The authoritative name servers for the Homenet Zone within the Homenet network itself. These are sometimes called the hidden "hidden primary servers.</t> servers".</t>
        </dd>
        <dt>Distribution Manager (DM):</dt>
        <dd>
    <t>is the (set of) server(s) to which
          <t>The server (or set of servers) that the HNA synchronizes the Public Homenet Zone, Zone to and which that then distributes the relevant information to the Public Authoritative Servers. This server has been historically known as the Distribution Master.</t>
        </dd>
        <dt>Public Homenet Reverse Zone:</dt>
        <dd>
          <t>The reverse zone file associated with the Public Homenet Zone.</t>
        </dd>
        <dt>Reverse Public Authoritative Servers:</dt>
        <dd>
    <t>equivalent
          <t>These are equivalent to Public Authoritative Servers Servers, specifically for reverse resolution.</t>
        </dd>
        <dt>Reverse Distribution Manager:</dt>
        <dd>
    <t>equivalent
          <t>This is equivalent to the Distribution Manager Manager, specifically for reverse resolution.</t>
        </dd>
  <dt>Homenet DNS(SEC)
        <dt>DNS Resolver:</dt>
        <dd>
    <t>a
          <t>A resolver that performs a DNS(SEC) DNS resolution on the home network Internet for the Public Homenet Zone.
	  The resolution is performed by requesting the Homenet Public Authoritative Servers.</t> Servers. While the resolver does not necessarily perform DNSSEC resolutions, it is <bcp14>RECOMMENDED</bcp14> that DNSSEC is enabled. </t>
	    <t>Note that when "DNS Resolver" is used in this document, it refers to "DNS or DNSSEC Resolver".</t>
        </dd>
  <dt>DNS(SEC)
  <dt>Homenet DNS Resolver:</dt>
        <dd>
    <t>a
          <t>A resolver that performs a DNS or DNSSEC resolution on the Internet home network for the Public Homenet Zone. The resolution is performed by requesting the Public Homenet Authoritative Servers.</t>
        </dd>
      </dl>
    </section>
    <section anchor="selectingnames"><name>Selecting anchor="selectingnames">
      <name>Selecting Names and Addresses to Publish</name>
      <t>While this document does not create any normative mechanism to select the names to publish, this document anticipates it does anticipate that the home network administrator (a human being), being) will be presented with a list of current names and addresses either directly on the HNA or via another device such as a smartphone.</t>
      <t>The administrator would will mark which devices and services (by name), name) are to be published. The HNA would will then collect the IP address(es) associated with that device or service, service and put the name into the Public Homenet Zone. The address of the device or service can be collected from a number of places: mDNS Multicast DNS (mDNS) <xref target="RFC6762"/>, DHCP <xref target="RFC8415"/>, UPnP, PCP Universal Plug and Play (UPnP), the Port Control Protocol (PCP) <xref target="RFC6887"/>, or manual configuration.</t>
      <t>A device or service SHOULD <bcp14>SHOULD</bcp14> have Global Unicast Addresses (GUA) (GUAs) (IPv6 <xref target="RFC3787"/> target="RFC3587"/> or IPv4), IPv4) but MAY <bcp14>MAY</bcp14> also have IPv6 Unique Local IPv6 Addresses (ULA) (ULAs) <xref target="RFC4193"/>, IPv6-Link-Local addresses<xref target="RFC4291"/><xref target="RFC7404"/>, IPv4-Link-Local IPv6 Link-Local Addresses (LLAs) <xref target="RFC4291"/> <xref target="RFC3927"/> (LLA), target="RFC7404"/>, IPv4 LLAs <xref target="RFC3927"/>, and finally, private IPv4 addresses <xref target="RFC1918"/>.</t>
      <t>Of these these, the link-local LLAs are almost never useful for the Public Zone, Zone and should be omitted.</t>
      <t>The IPv6 ULA and the private IPv4 addresses may be useful to publish, if the home network environment features a VPN that would allow the home owner to reach the network.
RFC1918 <xref target="RFC1918"/> addresses in public zones are generally filtered out by many DNS servers as they are considered rebind attacks <xref target="REBIND"/>.</t>
      <t>In general, one expects the GUA to be the default address to be published.
A direct advantage of enabling local communication is to enable communications even in case of Internet disruption.
Since communications Since communications are established with names which that remain a global identifier, the communication can be protected (at the very least with integrity protection) by TLS the same way it is protected on the global Internet - -- by using certificates.  </t> certificates.</t>
    </section>
    <section anchor="sec-deployment"><name>Envisioned deployment scenarios</name> anchor="sec-deployment">
      <name>Envisioned Deployment Scenarios</name>
      <t>A number of deployment scenarios have been envisioned, envisioned; this section aims at
providing a brief description. The use cases are not limitations limitations, and this section is not normative.</t>
      <t>The main difference between the various deployments concerns the provisioning of the HNA - -- that is is, how it is configured to outsource the Public Homenet Zone to the DOI - -- as well as how the Public Homenet Zone is being provisioned before being outsourced.<br /> outsourced.
In both cases, these configuration aspects are out of the scope of the this document.</t>
      <t>Provisioning the configuration related to the DOI is expected to be automated as much as possible and require as little as possible interaction with the end user.  <br /> user as little as possible.
Zero configuration can only be achieved under some circumstances circumstances, and <xref target="I-D.ietf-homenet-naming-architecture-dhc-options"/> target="RFC9527"/> provides one such example under the assumption that the ISP provides the DOI. <xref target="sec-cpe-vendor"/> describes another variant where the CPE Customer Premises Equipment (CPE) is provided preconfigured with the DOI.
<xref target="sec-agnostic-cpe"/> describes how an agnostic CPE may be configured by the home network administrator.
      Of course even in this case, the configuration can leverage mechanisms to prevent the end user from manually entering all information.</t>
      <t>On the other hand, provisioning the Public Homenet Zone needs to combine the ability to closely reflect what the end user wishes to publish on the Internet while easing such interaction.
The HNA may implement such interactions using Web GUI web-based GUIs or specific mobile applications.</t>
      <t>With the CPE configured with the DOI, the HNA contacts the DOI to build a template for the
Public Homenet Zone, Zone and then provision provisions the Public Homenet Zone.
Once the Public Homenet Zone is built, the HNA strats starts synchronizing it with the DOI on the Synchronization channel.</t> Channel.</t>
      <section anchor="sec-cpe-vendor"><name>CPE anchor="sec-cpe-vendor">
        <name>CPE Vendor</name>
        <t>A specific vendor with that has specific relations with a registrar or a registry
may sell a CPE that is provisioned with a domain name.
Such a domain name is probably not human friendly, friendly and may consist of some kind of serial number associated with the device being sold.</t>
        <t>One possible scenario is that the vendor provisions the HNA with a private key, key with an associated certificate used for the mutual TLS authentication.
Note that these keys are not expected to be used for DNSSEC signing.</t>

<t>Instead
<t>Instead, these keys are solely used by the HNA for the authentication to the DM.
Normally
Normally, the keys should be are necessary and sufficient to proceed to the authentication.</t>
        <t>When the home network owner plugs in the CPE at home, the relation between the HNA and DM is expected to work out-of-the-box.</t> out of the box.</t>
      </section>
      <section anchor="sec-agnostic-cpe"><name>Agnostic anchor="sec-agnostic-cpe">
        <name>Agnostic CPE</name>
        <t>A CPE that is not preconfigured may also use the protocol
defined in this document document, but some configuration steps will be needed.</t>

<t><list style="numbers">
  <t>The
<ol spacing="normal" type="1">
  <li>The owner of the home network buys a domain name from a registrar, and registrar and,
as such such, creates an account on that registrar</t>
  <t>the registrar.</li>
  <li>The registrar may also be providing provide the outsourcing infrastructure infrastructure,
or the home network may need to create a specific account on the
outsourcing infrastructure.</t>
</list></t>

<t><list style="symbols">
  <t>If infrastructure.</li>
        </ol>
        <ul spacing="normal">
          <li>If the DOI is the DNS Registrar, it has by design a proof of ownership of the domain name by the  homenet  Homenet owner.
In this case, it is expected that the DOI provides the necessary parameters to the home network owner to configure the HNA. One potential mechanism to provide the parameters would be to provide the user with a JSON object which that they can copy and paste into the CPE - CPE, such as described in <xref target="info-model"/>.
But,
But what matters to the infrastructure is that the HNA is able to authenticate itself to the DOI.</t>
  <t>If DOI.</li>
          <li>If the DOI is not the DNS Registrar, then the proof of ownership needs to be established using some other protocol.
ACME
	  Automatic Certificate Management Environment (ACME) <xref target="RFC8555"/> is one protocol that would allow an owner of an existing domain name to prove their ownership (but it requires that they have DNS already setup!) set up!). There are other ways to establish proof such as putting providing a DOI generated DOI-generated TXT record, or web site contents, as championed by entities like Google's Sitemaster and Postmaster protocols.
<xref target="I-D.ietf-dnsop-domain-verification-techniques"/> describes a few ways ownership or control of a domain can be achieved.</t>
</list></t> achieved.</li>
        </ul>
      </section>
    </section>
    <section anchor="sec-arch-desc"><name>Architecture anchor="sec-arch-desc">
      <name>Architecture Description</name>
      <t>This section provides an overview of the architecture for outsourcing the authoritative naming service from the HNA to the DOI.
As a consequence, this prevents HNA to handle from handling the DNS traffic from the Internet that is associated with the resolution of the Homenet Zone.</t>
      <t>The device assigned device-assigned zone or user configurable user-configurable zone to use that is used as the domain to publicly serve hostnames in the home network is called the Public Homenet Zone.
In this document, "myhome.example" is used as the example for an enduser owned end-user-owned domain configured as a Public Homenet Zone.</t>
      <t>More specifically, DNS resolution for the Public Homenet Zone (here myhome.example) "myhome.example") from Internet DNSSEC resolvers is handled by the DOI as opposed to the HNA.
The DOI benefits from a cloud infrastructure while the HNA is dimensioned for a home network and and, as such such, is likely unable to support any load.
In the case where the HNA is a CPE, outsourcing to the DOI reduces the attack surface of the home network to  DDoS DDoS, for example.
      Of course course, the DOI needs to be informed dynamically about the content of myhome.example. The description of such a synchronization mechanism is the purpose of this document.</t>

      <t>Note that <xref target="info-model"/> shows the necessary parameters to configure the HNA.</t>
      <section anchor="sec-arch-overview"><name>Architecture anchor="sec-arch-overview">
        <name>Architecture Overview</name>
        <figure title="Homenet anchor="fig-naming-arch">
          <name>Homenet Naming Architecture" anchor="fig-naming-arch"><artwork Architecture</name>
          <artwork align="center"><![CDATA[
.----------------------------.         .-----------------------------.
|        Home Network        |         |          Internet           |
| .-----------------------.  | Control |  .-----------------------.  |
| |          HNA          |  | Channel |  |          DOI          |  |
| |   (hidden primary)    |<------------->|   (hidden secondary)  |  |
| |                       |  | DNSUPD  |  |  Distribution Manager |  |
| | .-------------------. |  |         |  |                       |  |
| | |  Public Homenet   | |  |         |  |  .-------------------.|  |
| | |       Zone        |<------------------>| Public        |<------------------>|Public Homenet Zo || Zone||  |
| | | myhome.example    | |  |Synchron-|  |  | myhome.example    ||  |
| | '-------------------' |  | ization  |ization  |  |  '-------------------'|  |
| '-----------------------'  |Channel  |  |             |         |  |
|             ^              |  AXFR   |  |             |         |  |
|             |              |         |  |             v         |  |
| .-----------------------.  |         |  |.---------------------.|  |
| | Homenet Authoritative |  |         |  || Public Authoriative || Authoritative||  |
| |        Server         |  |         |  || (secondary) Servers ||  |
| | + myhome.example      |  |         |  || + myhome.example    ||  |
| | + home.arpa           |  |         |  || + x.y.z.ip6.arpa    ||  |
| | + x.y.z.ip6.arpa      |  |         |  ||                     ||  |
| '-----------------------'  |         |  ||                     ||  |
|        |       ^           |         |  |'---------------------'|  |
|        |       |           |         |  |  ^            |       |  |
|        |       |           |         |  '--|------------|-------'  |
|        v       |           |         |     |            v          |
|  .----------------------.  |         | .------------------------.  |
|  | Homenet DNS Resolver |  |         | |   Internet Resolvers   |  |
|  '----------------------'  |         | '------------------------'  |
|                            |         |                             |
'----------------------------'         |                             |
                                       '-----------------------------'
]]></artwork></figure>
]]></artwork>
        </figure>
        <t><xref target="fig-naming-arch"/> illustrates the architecture where the HNA outsources the publication of the Public Homenet Zone to the DOI.
The DOI will serve every DNS request of the Public Homenet Zone coming from outside the home network. When the request is coming from within the home network, the resolution is expected to be handled by the Homenet DNS Resolver as detailed in further details detailed below.</t>
        <t>In this example, The the Public Homenet Zone is identified by the Registered Homenet Domain name -- myhome.example. "myhome.example".
	This diagram also shows a reverse IPv6 map being hosted.</t>

<t>The ".local" as well as

        <t>".local" and ".home.arpa" are explicitly not considered as Public Homenet zones and Zones; therefore, they are represented as a Homenet Zone in <xref target="fig-naming-arch"/>.
They are resolved locally, locally but are not published as because they are considered local content.</t>
        <t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the HNA implements DNSSEC, in which case the HNA MUST signs <bcp14>MUST</bcp14> sign the Public Homenet Zone with DNSSEC.</t>
        <t>The HNA handles all operations and keying material required for DNSSEC, so there is no provision made in this architecture for transferring private DNSSEC related DNSSEC-related keying material between the HNA and the DM.</t>
        <t>Once the Public Homenet Zone has been built, the HNA communicates and synchronizes it with the DOI using a primary/secondary setting as depicted in <xref target="fig-naming-arch"/>.
The HNA acts as a stealth server (see <xref target="RFC8499"/>) while the DM behaves as a hidden secondary. It is responsible for distributing the Public Homenet Zone to the multiple Public Authoritative Servers Server instances that DOI is responsible for. The DM has three communication channels:</t>

<t><list style="symbols">
  <t>DM
        <ul spacing="normal">
          <li>DM Control Channel (<xref target="sec-ctrl"/>) to configure the HNA and the DOI. This includes necessary parameters to configure the primary/secondary relation as well as some information provided by the DOI that needs to be included by the HNA in the Public Homenet Zone.</t>
  <t>DM Zone.</li>
          <li>DM Synchronization Channel (<xref target="sec-synch"/>) to synchronize the Public Homenet Zone on the HNA and on the DM with the appropriately configured primary/secondary.
This is a zone transfer over mutually authenticated TLS.</t>
  <t>one TLS.</li>
          <li>One or more Distribution Channels (<xref target="sec-dist"/>) that distribute the Public Homenet Zone from the DM to the Public Authoritative Servers serving the Public Homenet Zone on the Internet.</t>
</list></t> Internet.</li>
        </ul>
        <t>There might be multiple DM's, DMs and multiple servers per the DM.
This document assumes a single DM server for simplicity, but there is no reason why each channel needs to be implemented on the same server or use the same code base.</t>
        <t>It is important to note that while the HNA is configured as an authoritative server, it is not expected to answer DNS requests from the <em>public</em> Internet for the Public Homenet Zone.
More specifically, the addresses associated with the HNA SHOULD NOT <bcp14>SHOULD NOT</bcp14> be mentioned in the NS records of the Public Homenet zone, Zone, unless additional security provisions necessary to protect the HNA from external attack have been taken.</t>
        <t>The DOI is also responsible for ensuring the DS record has been updated in the parent zone.</t>
        <t>Resolution is performed by DNS(SEC) resolvers. DNS Resolvers.
When the resolution is performed outside the home network, the DNS(SEC) DNS Resolver resolves the DS record on the Global DNS and the name associated with the Public Homenet Zone (myhome.example) on the Public Authoritative Servers.</t>
        <t>In order to provide resilience to the Public Homenet Zone in case of WAN connectivity disruption, the Homenet DNS(SEC) DNS Resolver MUST <bcp14>MUST</bcp14> be able to perform the resolution on the Homenet Authoritative Servers.
Note that the use of the Homenet resolver DNS Resolver enhances privacy since the user on the home network would no longer be leaking interactions with internal services to an external DNS provider and to an on-path observer.
These servers are not expected to be mentioned in the Public Homenet Zone, Zone nor to be accessible from the Internet.
As such such, their information as well as the corresponding signed DS record MAY <bcp14>MAY</bcp14> be provided by the HNA to the Homenet DNS(SEC) DNS Resolvers, e.g., by using HNCP the Home Networking Control Protocol (HNCP) <xref target="RFC7788"/> or a by configuring a trust anchor <xref target="I-D.ietf-dnsop-dnssec-validator-requirements"/>.
Such configuration is outside the scope of this document.
Since the scope of the Homenet Authoritative Servers is limited to the home network, these servers are expected to serve the Homenet Zone as represented in <xref target="fig-naming-arch"/>.</t>
      </section>
      <section anchor="sec-comms"><name>Distribution anchor="sec-comms">
        <name>Distribution Manager (DM) Communication Channels</name>
        <t>This section details the DM channels, that is channels: the Control Channel, the Synchronization Channel Channel, and the Distribution Channel.</t>
        <t>The Control Channel and the Synchronization Channel are the interfaces used between the HNA and the DOI. The entity within the DOI responsible to handle for handling these communications is the DM. Communications between the HNA and the DM MUST <bcp14>MUST</bcp14> be protected and mutually authenticated.
<xref target="sec-ctrl-security"/> discusses in more depth the
The different security protocols that could can be used to secure.</t> for security are discussed in more depth in <xref target="sec-ctrl-security"/>.</t>
        <t>The information exchanged between the HNA and the DM uses DNS messages protected by DNS over TLS (DoT) <xref target="RFC7858"/>.
	This is configured identically to that described in <xref target="RFC9103"/>, Section 9.3.3.</t> target="RFC9103" sectionFormat="comma" section="9.3.3"/>.</t>

        <t>It is worth noting that both the DM and HNA need to agree on a common configuration in order to set up the synchronization channel as well as to Synchronization Channel and build and server serve a coherent Public Homenet Zone.
As previously noted, the visible NS records of the Public Homenet Zone (built by the HNA) remain pointing at the IP address of the DOI's Public Authoritative Servers' IP address. Servers.
Unless the HNA is able to support the traffic load, the HNA SHOULD NOT <bcp14>SHOULD NOT</bcp14> appear as a visible NS records record of the Public Homenet Zone.
In addition, and depending on the configuration of the DOI, the DM also needs to update the parent zone's NS, DS DS, and associated A or AAAA glue records.
Refer to <xref target="sec-chain-of-trust"/> for more details.</t>
        <t>This specification assumes:</t>

<t><list style="symbols">
  <t>the
        <ul spacing="normal">
          <li>The DM serves both the Control Channel and Synchronization Channel on a single IP address, on a single port port, and by using a single transport protocol.</t>
  <t>By protocol.</li>
          <li>By default, the HNA uses a single IP address for both the Control and Synchronization channel.
However, channels; however, the HNA MAY <bcp14>MAY</bcp14> use distinct IP addresses for the Control Channel and the Synchronization Channel - -- see Sections <xref target="sec-synch"/> target="sec-synch" format="counter"/> and <xref target="sec-sync-info"/> target="sec-sync-info" format="counter"/> for more details.</t>
</list></t> details.</li>
        </ul>
        <t>The Distribution Channel is internal to the DOI and and, as such such, is not normatively defined by this specification.</t>
      </section>
    </section>
    <section anchor="sec-ctrl"><name>Control anchor="sec-ctrl">
      <name>Control Channel</name>
      <t>The DM Control Channel is used by the HNA and the DOI to exchange information related to the configuration of the delegation delegation, which includes information to build the Public Homenet Zone (<xref target="sec-pbl-homenet-zone"/>), information to build the DNSSEC chain of trust (<xref target="sec-chain-of-trust"/>) target="sec-chain-of-trust"/>), and information to set the Synchronization Channel (<xref target="sec-sync-info"/>).</t>
      <t>Some information is carried from the DOI to the HNA, as described in the next section.
The HNA updates the DOI with the the IP address on which the zone is to be transferred using the synchronization channel. Synchronization Channel.
The HNA is always initiating the exchange in both directions.</t>
      <t>As such such, the HNA has a prior knowledge of the DM identity (via X509 an X.509 certificate), the IP address and port number to use use, and the protocol to establish a secure session.
      The DM acquires knowledge of the identity of the HNA (X509 (X.509 certificate) as well as the Registered Homenet Domain. For more detail to see on how this can be achieved, please see <xref target="hna-provisioning"/>.</t>
      <section anchor="sec-pbl-homenet-zone"><name>Information to Build anchor="sec-pbl-homenet-zone">
        <name>Building the Public Homenet Zone</name>
        <t>The HNA builds the Public Homenet Zone based on a template that is returned by the DM to the HNA.  <xref target="sec-ctrl-messages"/> explains how this leverages the AXFR Authoritative Transfer (AXFR) mechanism.</t>
        <t>In order to build its zone completely, the HNA needs the names (and possibly IP addresses) of the Public Authoritative Name Servers.
These are used to populate the NS records for the zone.
All the content of the zone MUST <bcp14>MUST</bcp14> be created by the HNA, HNA because the zone is DNSSEC signed.</t>
        <t>In addition, the HNA needs to know what to put into the MNAME of the SOA, and only the DOI knows what to put there.
The DM MUST <bcp14>MUST</bcp14> also provide useful operational parameters such as other fields of the SOA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE EXPIRE, and MINIMUM), MINIMUM); however, the HNA is free to override these values based upon local configuration.
For instance, an HNA might want to change these values if it thinks that a renumbering event is approaching.</t>

<t>As
        <t>Because the information associated with the DM is necessary for the HNA to proceed and the information is associated with the DM, proceed, this information exchange is mandatory.</t>
        <t>The HNA then performs a DNS Update operation to the DOI, updating the DOI with an NS, a DS, and A and AAAA records. These indicates indicate where its Synchronization Channel is.
The DOI does not publish this NS record, record but uses it to perform zone transfers.</t>
      </section>
      <section anchor="sec-chain-of-trust"><name>Information to build anchor="sec-chain-of-trust">
        <name>Building the DNSSEC chain Chain of trust</name> Trust</name>
        <t>The HNA MUST <bcp14>MUST</bcp14> provide the hash of the KSK via the DS RRset, RRset so that the DOI can provide this value to the parent zone.
A common deployment use case is that the DOI is the registrar of the Registered Homenet Domain and as such, Domain; therefore, its relationship with the registry of the parent zone enables it to update the parent zone. When such relation exists, the HNA should be able to request the DOI to update the DS RRset in the parent zone.
A direct update is especially necessary to initialize the chain of trust.</t>
        <t>Though the HNA may also later directly update the values of the DS via the Control Channel, Channel at a later time, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to use other mechanisms such as CDS and CDNSKEY <xref target="RFC7344"/> for transparent updates during key roll overs.</t> rollovers.</t>
        <t>As some deployments may not provide a DOI that will be able to update the DS in the parent zone, this information exchange is OPTIONAL.</t> <bcp14>OPTIONAL</bcp14>.</t>
        <t>By accepting the DS RR, the DM commits to advertise the DS to the parent zone.
On the other hand hand, if the DM does not have the capacity to advertise the DS to the parent  zone, it indicates this by refusing the update to the DS RR.</t>
      </section>
      <section anchor="sec-sync-info"><name>Information to set up anchor="sec-sync-info">
        <name>Setting Up the Synchronization Channel</name>
        <t>The HNA works as a hidden primary authoritative DNS server, server while the DM works like a secondary. secondary one.
As a result, the HNA needs to provide the IP address that the DM should use to reach the HNA.</t>
        <t>If the HNA detects that it has been renumbered, then it MUST <bcp14>MUST</bcp14> use the Control Channel to update the DOI with the new IPv6 address it has been assigned.</t>
        <t>The Synchronization Channel will be set between the new IPv6 (and IPv4) address and the IP address of the DM.
By default, the IP address used by the HNA in the Control Channel is considered by the DM DM, and the explicit specification of the IP by the HNA is only OPTIONAL. <bcp14>OPTIONAL</bcp14>.
The transport channel (including the port number) is the same as the one used between the HNA and the DM for the Control Channel.</t>
      </section>
      <section anchor="deleting-the-delegation"><name>Deleting anchor="deleting-the-delegation">
        <name>Deleting the delegation</name> Delegation</name>
        <t>The purpose of the previous sections were is to exchange information in order to set a delegation.
The HNA MUST <bcp14>MUST</bcp14> also be able to delete a delegation with a specific DM.</t>
        <t><xref target="sec-zone-delete"/> explains how a DNS Update operation on the Control Channel is used.</t>
        <t>Upon an receiving the instruction of deleting to delete the delegation, the DM MUST <bcp14>MUST</bcp14> stop serving the Public Homenet Zone.</t>
        <t>The decision to delete an inactive HNA by the DM is part of the commercial agreement between the DOI and HNA.</t>
      </section>
      <section anchor="sec-ctrl-messages"><name>Messages anchor="sec-ctrl-messages">
        <name>Message Exchange Description</name>
        <t>Multiple ways were considered on how the control information could be exchanged between  the HNA and the DM.</t>
        <t>This specification defines a mechanism that re-uses reuses the DNS zone transfer format.
Note that while information is provided using DNS exchanges, the exchanged information is not expected to be set in any zone file, instead file; instead, this information is used as commands between the HNA and the DM.
This was found to be simpler on the home router side, as the HNA already has to have code to deal with all the DNS encodings/decodings.
Inventing a new way to encode the DNS information in, for instance, JSON, JSON seemed to add complexity for no return on investment.</t>
        <t>The Control Channel is not expected to be a long-term session.
After a predefined timer - similar (similar to those used for TCP - TCP), the Control Channel is expected to be terminated - by closing the transport channel. The Control Channel MAY <bcp14>MAY</bcp14> be re-opened reopened at any time later.</t> later time.</t>
        <t>The use of a TLS session tickets (see <xref section="4.6.1" sectionFormat="comma" target="RFC8446"/> target="RFC8446"/>) is RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</t>
        <t>The authentication of the channel MUST <bcp14>MUST</bcp14> be based on certificates for both the DM and each HNA.
The DM may also create the initial configuration for the delegation zone in the parent zone during the provisioning process.</t>
        <section anchor="zonetemplate"><name>Retrieving information anchor="zonetemplate">
          <name>Retrieving Information for the Public Homenet Zone</name>
          <t>The information provided by the DM to the HNA is retrieved by the HNA with an AXFR exchange <xref target="RFC1034"/>.
AXFR enables the response to contain any type of RRsets.</t>
          <t>To retrieve the necessary information to build the Public Homenet Zone, the HNA MUST <bcp14>MUST</bcp14> send a DNS request of type AXFR associated with the Registered Homenet Domain.</t>
          <t>The zone that is returned by the DM is used by the HNA as a template to build its own zone.</t>
          <t>The zone template MUST <bcp14>MUST</bcp14> contain a an RRset of type SOA, one or multiple RRset RRsets of type NS NS, and zero or more RRset RRsets of type A or AAAA (if the NS are is in-domain <xref target="RFC8499"/>). The zone template will include Time To Live Time-To-Live (TTL) values for each RR, and the HNA SHOULD <bcp14>SHOULD</bcp14> take these as suggested maximum values, but MAY it <bcp14>MAY</bcp14> use lower values for operational reasons, such as for impending renumbering events.</t>

<t><list style="symbols">
  <t>The
          <ul spacing="normal">
            <li>The SOA RR indicates to the HNA the value of the MNAME of the Public Homenet Zone.</t>
  <t>The Zone to the HNA.</li>
            <li>The NAME of the SOA RR MUST <bcp14>MUST</bcp14> be the Registered Homenet Domain.</t>
  <t>The Domain.</li>
            <li>The MNAME value of the SOA RDATA is the value provided by the DOI to the HNA.</t>
  <t>Other HNA.</li>
            <li>Other RDATA values (RNAME, REFRESH, RETRY, EXPIRE EXPIRE, and MINIMUM) are provided by the DOI as suggestions.</t>
</list></t> suggestions.</li>
          </ul>
          <t>The NS RRsets carry the Public Authoritative Servers of the DOI.
Their associated NAME MUST <bcp14>MUST</bcp14> be the Registered Homenet Domain.</t>
          <t>In addition to the considerations above about default TTL, the HNA SHOULD <bcp14>SHOULD</bcp14>
take care to not pick a TTL larger than the parent NS, based upon the resolver's guide lines: guidelines in <xref target="I-D.ietf-dnsop-ns-revalidation"/> and <xref target="I-D.ietf-dnsop-dnssec-validator-requirements"/>.
	  The RRsets of Type A and AAAA MUST <bcp14>MUST</bcp14> have their NAME matching the NSDNAME of one of the NS RRsets.</t>

          <t>Upon receiving the response, the HNA MUST <bcp14>MUST</bcp14> validate the format and properties of the SOA, NS NS, and A or AAAA RRsets.
If an error occurs, the HNA MUST <bcp14>MUST</bcp14> stop proceeding and MUST <bcp14>MUST</bcp14> log an error.
Otherwise, the HNA builds the Public Homenet Zone by setting the MNAME value of the SOA as indicated by the SOA provided by the AXFR response. The HNA MUST not <bcp14>MUST NOT</bcp14> exceed the values of NAME, REFRESH, RETRY, EXPIRE EXPIRE, and MINIMUM of the SOA to those provided by the AXFR response. The HNA MUST <bcp14>MUST</bcp14> insert the NS and corresponding A or AAAA RRset RRsets in its Public Homenet Zone. The HNA MUST <bcp14>MUST</bcp14> ignore other RRsets.</t>
          <t>If an error message is returned by the DM, the HNA MUST <bcp14>MUST</bcp14> proceed as a regular DNS resolution. Error messages SHOULD <bcp14>SHOULD</bcp14> be logged for further analysis.
If the resolution does not succeed, the outsourcing operation is aborted and the HNA MUST <bcp14>MUST</bcp14> close the Control Channel.</t>
        </section>
        <section anchor="sec-ds"><name>Providing information anchor="sec-ds">
          <name>Providing Information for the DNSSEC chain Chain of trust</name> Trust</name>
          <t>To provide the DS RRset to initialize the DNSSEC chain of trust trust, the HNA MAY <bcp14>MAY</bcp14> send a DNS update <xref target="RFC3007"/> message.</t>
          <t>The DNS update message is composed of a Header section, a Zone section, a Pre-requisite Prerequisite section, and an Update section section, and an additional section.
The Zone section MUST <bcp14>MUST</bcp14> set the ZNAME to the parent zone of the Registered Homenet Domain - that Domain, which is where the DS records should be inserted. As described in <xref target="RFC2136"/>, ZTYPE is set to SOA and ZCLASS is set to the zone's class.
The Pre-requisite Prerequisite section MUST <bcp14>MUST</bcp14> be empty.
The Update section is a DS RRset with its NAME set to the Registered Homenet Domain Domain, and the associated RDATA corresponds to the value of the DS.
The Additional Data section MUST <bcp14>MUST</bcp14> be empty.</t>
          <t>Though the pre-requisite Prerequisite section MAY <bcp14>MAY</bcp14> be ignored by the DM, this value is fixed to remain coherent with a standard DNS update.</t>
          <t>Upon receiving the DNS update request, the DM reads the DS RRset in the Update section.
The DM checks that ZNAME corresponds to the parent zone. The DM MUST <bcp14>MUST</bcp14> ignore the Pre-requisite Prerequisite and Additional Data sections, if present. The DM MAY <bcp14>MAY</bcp14> update the TTL value before updating the DS RRset in the parent zone. Upon a successful update, the DM should return a NOERROR response as a commitment to update the parent zone with the provided DS. An error indicates that the DM does not update the DS, and the HNA needs to act accordingly or other accordingly; otherwise, another method should be used by the HNA.</t>
          <t>The regular DNS error message MUST <bcp14>MUST</bcp14> be returned to the HNA when an error occurs. In particular particular, a FORMERR is returned when a format error is found, this includes including when unexpected RRSets RRsets are added or when RRsets are missing. A SERVFAIL error is returned when a an internal error is encountered.
A NOTZONE error is returned when update the Update and Zone sections are not coherent, and a NOTAUTH error is returned when the DM is not authoritative for the Zone section. A REFUSED error is returned when the DM refuses to proceed to the configuration and or performing the requested action.</t>
        </section>
        <section anchor="sec-ip-hna"><name>Providing information anchor="sec-ip-hna">
          <name>Providing Information for the Synchronization Channel</name>
          <t>The default IP address used by the HNA for the Synchronization Channel is the IP address of the Control Channel. To provide a different IP address, the HNA MAY <bcp14>MAY</bcp14> send a DNS UPDATE message.</t>

<t>Similarly
          <t>Similar to the what is described in <xref target="sec-ds"/>, the HNA MAY <bcp14>MAY</bcp14> specify the IP address using a DNS update message. The Zone section sets its ZNAME to the parent zone of the Registered Homenet Domain, ZTYPE is set to SOA SOA, and ZCLASS is set to the zone's type.
Pre-requisite Prerequisite is empty. The Update section is a an RRset of type NS. The Additional Data section contains the RRsets of type A or AAAA that designates designate the IP addresses associated with the primary (or the HNA).</t>
          <t>The reason to provide these IP addresses is to keep them unpublished and prevent them to be from being resolved. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the IP address of the HNA is be randomly chosen to prevent it from being easily discovered as well.</t>
          <t>Upon receiving the DNS update request, the DM reads the IP addresses and checks that the ZNAME corresponds to the parent zone. The DM MUST <bcp14>MUST</bcp14> ignore a non-empty Pre-requisite Prerequisite section. The DM configures the secondary with the IP addresses and returns a NOERROR response to indicate it is committed to serve as a secondary.</t>

<t>Similarly
          <t>Similar to what is described in <xref target="sec-ds"/>, DNS errors are used used, and an error indicates the DM is not configured as a secondary.</t>
        </section>
        <section anchor="sec-zone-delete"><name>HNA instructing deleting anchor="sec-zone-delete">
          <name>Initiating Deletion of the delegation</name> Delegation</name>
          <t>To instruct to delete initiate the delegation deletion of the delegation, the HNA sends a DNS UPDATE Delete message.</t>
          <t>The Zone section sets its ZNAME to the Registered Homenet Domain, the ZTYPE to SOA SOA, and the ZCLASS to the zone's type. The Pre-requisite Prerequisite section is empty. The Update section is a an RRset of type NS with the NAME set to the Registered Domain Name.
	  As indicated by <xref target="RFC2136"/> Section 2.5.2 target="RFC2136" sectionFormat="comma" section="2.5.2"/>, the delete instruction is set initiated by setting the TTL to 0, the Class CLASS to ANY, the and RDLENGTH to 0 0, and the RDATA MUST <bcp14>MUST</bcp14> be empty. The Additional Data section is empty.</t>
          <t>Upon receiving the DNS update request, the DM checks the request and removes the delegation. The DM returns a NOERROR response to indicate the delegation has been deleted.
Similarly Similar to what is described in <xref target="sec-ds"/>, DNS errors are used used, and an error indicates that the delegation has not been deleted.</t>
        </section>
      </section>
      <section anchor="sec-ctrl-security"><name>Securing anchor="sec-ctrl-security">
        <name>Securing the Control Channel</name>
        <t>TLS <xref target="RFC8446"/>) MUST target="RFC8446"/> <bcp14>MUST</bcp14> be used to secure the transactions between the DM and the HNA HNA, and the DM and HNA MUST <bcp14>MUST</bcp14> be mutually authenticated.
The DNS exchanges are performed using DNS over TLS <xref target="RFC7858"/>.</t>
        <t>The HNA may be provisioned by the manufacturer, manufacturer or during some user-initiated onboarding process, for example, with a browser, by signing up to a service provider, and with a resulting OAUTH2 OAuth 2.0 token to be provided to the HNA. Such a process may result in a passing of a settings from a Registrar registrar into the HNA through an http API interface. (This is not in scope)</t> scope for this document.)</t>
        <t>When the HNA connects to the DM's control channel, Control Channel, TLS will be used, and the connection will be mutually authenticated.
The DM will authenticate the HNA's certificate based upon having participating participated in some provisioning process that is not standardized by this document. The results of the provisioning process is a series of settings described in <xref target="hna-provisioning"/>.</t>
        <t>The HNA will validate the DM's control channel Control Channel certificate by doing an <xref target="I-D.ietf-uta-rfc6125bis"/> performing a DNS-ID check on the name.</t> name as described in <xref target="RFC9525"/>.</t>
        <t>In the future, other specifications may consider protecting DNS messages with other transport layers, among others, layers such as DNS over DTLS <xref target="RFC8094"/>, or DNS over HTTPs HTTPS (DoH) <xref target="RFC8484"/> target="RFC8484"/>, or DNS over QUIC <xref target="RFC9250"/>.</t>
      </section>
    </section>
    <section anchor="sec-synch"><name>Synchronization anchor="sec-synch">
      <name>Synchronization Channel</name>
      <t>The DM Synchronization Channel is used for communication between the HNA and the DM for synchronizing the Public Homenet Zone. Note that the Control Channel and the Synchronization Channel are by construction different channels by construction even though there they may use the same IP address. Suppose the HNA and the DM are using a single IP address and let designate designated by XX. XX, and YYYYY and ZZZZZ are the various ports involved in the communications.</t>

<t>The Control Channel is between the between</t>
<ul>
  <li>the HNA working as a client using port number YYYYY (an ephemeral also commonly designated as a high range port) toward a and</li>
  <li>a service provided by the DM at port 853, when using DoT.</t> DoT.</li>
  </ul>

  <t>On the other hand, the Synchronization Channel is set between the between</t>
<ul>
  <li>the DM working as a client using port ZZZZZ (another ephemeral port) toward a and</li>
  <li>a service provided by the HNA at port 853.</t> 853.</li>
</ul>
      <t>As a result, even though the same pair of IP addresses may be involved involved, the Control Channel and the Synchronization Channel are always distinct channels.</t>
      <t>Uploading and dynamically updating the zone file on the DM can be seen as zone provisioning between the HNA (Hidden Primary) (hidden primary server) and the DM (Secondary Server). (secondary server).
This is handled using the normal zone transfer mechanism involving AXFR/IXFR.</t> the AXFR and Incremental Zone Transfer (IXFR).</t>
      <t>Part of this zone update the process to update the zone involves the owner of the zone (the hidden primary, primary server, the HNA) sending a DNS Notify to the secondaries. In this situation situation, the only destination that is known by the HNA is the DM's Control Channel, and so DNS notifies Notifies are sent over the Control Channel, secured by a mutually authenticated TLS.</t>
      <t>Please note that, that DNS Notifies are not critical to normal operation, as the DM will be checking the zone regularly based upon SOA record comments.  DNS Notifies do speed things up as they cause the DM to use the Synchronization channel Channel to immediately do an SOA Query query to detect any updates.  If there are any changes changes, then the DM immediately transfers the zone updates.</t>
      <t>This specification standardizes the use of a primary / secondary primary/secondary mechanism <xref target="RFC1996"/> rather than an extended series of DNS update messages. The primary / secondary primary/secondary mechanism was selected as it scales better and avoids DoS attacks.
As Because this AXFR runs over a TCP channel secured by a mutually authenticated TLS, then the DNS Update update is just more complicated.</t>
      <t>Note that this document provides no standard way to distribute a DNS primary between multiple devices. As a result, if multiple devices are candidate candidates for hosting the Hidden Primary, hidden primary server, some specific mechanisms should be designed so the home network only selects a single HNA for the Hidden Primary. hidden primary server. Selection mechanisms based on HNCP <xref target="RFC7788"/> are good candidates for future work.</t>
      <section anchor="sec-synch-security"><name>Securing anchor="sec-synch-security">
        <name>Securing the Synchronization Channel</name>
        <t>The Synchronization Channel uses mutually authenticated TLS, as described by <xref target="RFC9103"/>.</t>
        <t>There is a TLS client certificate used by the DM to authenticate itself.
The DM uses the same certificate which that was configured into the HNA for authenticating the Control Channel, but as a client certificate rather than a server certificate.</t>
<t><xref target="RFC9103"/> makes no requirements or recommendations on any extended key usage flags for zone transfers, and this document adopts the view that none should be required.
 and leave it up Note that once an update to <xref target="RFC9103"/> to get updated for is published, this document's normative reference to <xref target="RFC9103"/> will be considered updated as well.</t>
        <t>For the TLS server certificate, the HNA uses the same certificate which that it uses to authenticate itself to the DM for the Control Channel.</t>
        <t>The HNA MAY <bcp14>MAY</bcp14> use this certificate as the authorization for the zone transfer, or the HNA MAY <bcp14>MAY</bcp14> have been configured with an Access Control List (ACL) that will determine if the zone transfer can proceed. This is a local configuration option, option as it is premature to determine which will be operationally simpler.</t>
        <t>When the HNA expects to do zone transfer authorization by certificate only, the HNA MAY <bcp14>MAY</bcp14> still apply an ACL on inbound connection requests to avoid load.
In this case, the HNA MUST <bcp14>MUST</bcp14> regularly check (via a DNS resolution) that the validity of the address(es) of the DM in the filter is still valid.</t> filter.</t>
      </section>
    </section>
    <section anchor="sec-dist"><name>DM anchor="sec-dist">
      <name>DM Distribution Channel</name>
      <t>The DM Distribution Channel is used for communication between the DM and the Public Authoritative Servers.
The architecture and communication used for the DM Distribution Channels are outside the scope of this document, and but there are many existing solutions available, e.g., rsync, DNS AXFR, REST, and DB copy.</t>
    </section>
    <section anchor="sec-cpe-sec-policies"><name>HNA anchor="sec-cpe-sec-policies">
      <name>HNA Security Policies</name>
      <t>The HNA HNA, as the hidden primary server, processes only a limited message exchanges on it's Internet facing its Internet-facing interface.
This should be enforced using security policies - to allow only a subset of DNS requests to be received by HNA.</t>
      <t>The Hidden Primary Server hidden primary server on the HNA differs from the regular authoritative server for the home network due to:</t> to the following:</t>
      <dl>
        <dt>Interface Binding:</dt>
  <dd>
    <t>the Hidden Primary Server
        <dd>The hidden primary server will almost certainly listen on the WAN Interface, whereas a regular Homenet Authoritative Servers would Server will listen on the internal home network interface.</t> interface.
        </dd>
        <dt>Limited exchanges:</dt>
  <dd>
    <t>the Exchanges:</dt>
        <dd>The purpose of the Hidden Primary Server hidden primary server is to synchronize with the DM, not to serve any zones to end users, users or the public Internet. This results in a limited number of possible exchanges (AXFR/IXFR) with a small number of IP addresses addresses, and an implementation MUST <bcp14>MUST</bcp14> enable filtering policies: it should only respond to queries that are required to do zone transfers.
That list includes SOA queries and AXFR/IXFR queries.</t> queries.
        </dd>
      </dl>
    </section>
    <section anchor="sec-reverse"><name>Public anchor="sec-reverse">
      <name>Public Homenet Reverse Zone</name>

<t>Public
      <t>The Public Homenet Reverse Zone works similarly to the Public Homenet Zone.
The main difference is that the ISP that provides the IPv6 connectivity is likely to also be the owner of the corresponding IPv6 reverse zone and administrating who administrates the Reverse Public Authoritative Servers. The configuration and the setting of the Synchronization Channel and Control Channel can largely be automated using DHCPv6 messages that are a part of the IPv6 Prefix Delegation prefix delegation process.</t>
      <t>The Public Homenet Zone is associated with a Registered Homenet Domain Domain, and the ownership of that domain requires a specific registration from the end user as well as the HNA being provisioned with some authentication credentials. Such steps are mandatory unless the DOI has some other means to authenticate the HNA. Such situation may occur, for example, when the ISP provides the Homenet Domain as well as the DOI.</t>
      <t>In this case, the HNA may be authenticated by the physical link layer, in which case the authentication of the HNA may be performed without additional provisioning of the HNA.
While this may not be so common for the Public Homenet Zone, this situation is expected to be quite common for the Reverse Homenet Zone as the ISP owns the IP address or IP prefix.</t>
      <t>More specifically, a common case is that the upstream ISP provides the IPv6 prefix to the Homenet with an identity association for a IA_PD prefix delegation (IA_PD) option <xref target="RFC8415"/> option and manages the DOI of the associated reverse zone.</t>
      <t>This leaves a place for setting up automatically the relation between the HNA and the DOI automatically as described in <xref target="I-D.ietf-homenet-naming-architecture-dhc-options"/>.</t> target="RFC9527"/>.</t>
      <t>In the case of the reverse zone, the DOI authenticates the source of the updates by IPv6 Access Control Lists.
In the case of the reverse zone, ACLs, and the ISP knows exactly what addresses have been delegated.
The Therefore, the HNA SHOULD therefore <bcp14>SHOULD</bcp14> always originate Synchronization Channel updates from an IP address within the zone that is being updated. Exceptionally, the synchronization channel Synchronization Channel might be from a different zone delegated to the HNA (if there were multiple zones, zones or renumbering events were in progress).</t>
<t>For example, if the ISP has assigned 2001:db8:f00d::/64 2001:db8:f00d:1234::/64 to the WAN interface (by DHCPv6, DHCPv6 or PPP/RA), PPP with Router Advertisement (RA)), then the HNA should originate Synchronization Channel updates from, for example, 2001:db8:f00d::2.</t>

<t>An 2001:db8:f00d:1234::2.</t>

      <t>If an ISP that has delegated 2001:db8:aeae::/56 to the HNA via DHCPv6-PD, then the HNA should originate Synchronization Channel updates to an IP address within that subnet, such as 2001:db8:aeae:1::2.</t>
      <t>With this relation automatically configured, the synchronization between the Home network and the DOI happens similarly as for in a similar way to the synchronization of the Public Homenet Zone described earlier in this document.</t>
<t>Note that for home networks connected to by multiple ISPs, each ISP provides only the DOI of the reverse zones associated with the delegated prefix. It is also likely that the DNS exchanges will need to be performed on dedicated interfaces as to be accepted by the ISP. More specifically, the reverse zone update associated with prefix 1 will not be possible to cannot be performs performed by the HNA using an IP address that belongs to prefix 2.  Such constraints does do not raise major concerns either for hot standby or load sharing load-sharing configuration.</t>
      <t>With IPv6, the reverse domain space for IP addresses associated with a subnet a subnet such as ::/64 is so large that the reverse zone may be confronted with scalability issues.
How the reverse zone is generated is out of scope of this document.
<xref target="RFC8501"/> provides guidance on how to address scalability issues.</t>
    </section>
    <section anchor="sec-dnssec-deployment"><name>DNSSEC compliant anchor="sec-dnssec-deployment">
      <name>DNSSEC-Compliant Homenet Architecture</name>
      <t><xref target="RFC7368"/> in Section 3.7.3 target="RFC7368" sectionFormat="of" section="3.7.3"/> recommends that DNSSEC to be deployed on both the authoritative server and the resolver.</t>
      <t>The resolver side is out of scope of this document, and only the authoritative part of the server is considered.
      Other documents such as <xref target="RFC5011"/> deal with the continuous update of trust anchors required for operation of a DNSSEC resolver.</t> Resolver.</t>

<t>The HNA MUST DNSSEC sign the Public Homenet Zone and the Public Reverse Zone.</t> Zone <bcp14>MUST</bcp14> be DNSSEC signed by the HNA.</t>
      <t>Secure delegation is achieved only if the DS RRset is properly set in the parent zone.
Secure delegation can be performed by the HNA or the DOIs DOIs, and the choice highly depends on which entity is authorized to perform such updates.
Typically, the DS RRset is updated manually through a registrar interface, interface and can be maintained with mechanisms such as CDS <xref target="RFC7344"/>.</t>
      <t>When the operator of the DOI is also the Registrar registrar for the domain, then it is a trivial matter for the DOI to initialize the relevant DS records in the parent zone.
In other cases, some other initialization will be required, and that will be specific to the infrastructure involved.
It is beyond the scope of this document.</t>
      <t>There may be some situations where the HNA is unable to arrange for secure delegation of the zones, but the HNA MUST <bcp14>MUST</bcp14> still sign the zones.</t>
    </section>
    <section anchor="sec-renumbering"><name>Renumbering</name> anchor="sec-renumbering">
      <name>Renumbering</name>
      <t>During a renumbering of the home network, the HNA IP address may be changed and the Public Homenet Zone will be updated by the HNA with new AAAA records.</t>
      <t>The HNA will then advertise to the DM via a NOTIFY on the Control Channel.
The DM will need to note the new originating IP for the connection, and it will need to update it's its internal database of Synchronization Channels.
A new zone transfer will occur with the new records for the resources that the HNA wishes to publish.</t>
      <t>The remaining remainder of the section provides recommendations regarding the provisioning of the Public Homenet Zone - Zone, especially the IP addresses.</t>
      <t>Renumbering has been extensively described in <xref target="RFC4192"/> and analyzed in <xref target="RFC7010"/> target="RFC7010"/>, and the reader is expected to be familiar with them before reading this section.
In the make-before-break renumbering scenario, the new prefix is advertised, and the network is configured to prepare the transition to the new prefix. During a period of time, the two prefixes old (old and new coexist, new) coexist before the old prefix is completely removed. New resources resource records containing the new prefix SHOULD <bcp14>SHOULD</bcp14> be published, while the old resource records with the old prefixes SHOULD <bcp14>SHOULD</bcp14> be withdrawn. If the HNA anticipates that the period of overlap is will be long (perhaps due to the knowledge of router and DHCPv6 lifetimes), it MAY <bcp14>MAY</bcp14> publish the old prefixes with a significantly lower time to live.</t> TTL.</t>
      <t>In break-before-make renumbering scenarios, including flash renumbering scenarios <xref target="RFC8978"/>, the old prefix becomes unuseable unusable before the new prefix is known or advertised.
As explained in <xref target="RFC8978"/>, some flash renumberings occur due to power cycling of the HNA, where ISPs do not properly remember what prefixes have been assigned to which user.</t>
      <t>An HNA that boots up MUST <bcp14>MUST</bcp14> immediately use the Control Channel to update the location for the Synchronization Channel. This is a reasonable thing to do on every boot, as the HNA has no idea how long it has been offline, offline or if the (DNSSEC) zone has perhaps expired during the time the HNA was powered off.</t>
      <t>The HNA will have a list of names that should be published, but it might not yet have IP addresses for those devices. This could be because at the time of power on, the other devices are were not yet online.
If the HNA is sure that the prefix has not changed, then it should use the previously known addresses, with a very low TTL.</t>
      <t>Although the new and old IP addresses may be stored in the Public Homenet Zone, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that only the newly reachable IP addresses be published.</t>
      <t>Regarding the Public Homenet Reverse Zone, the new Public Homenet Reverse Zone has to be populated as soon as possible, and the old Public Homenet Reverse Zone will be deleted by the owner of the zone (and the owner of the old prefix prefix, which is usually the ISP) once the prefix is no longer assigned to the HNA.
The ISP MUST <bcp14>MUST</bcp14> ensure that the DNS cache has expired before re-assigning reassigning the prefix to a new home network.
This may be enforced by controlling the TTL values.</t>
      <t>To avoid reachability disruption, IP connectivity information provided by the DNS MUST <bcp14>MUST</bcp14> be coherent with the IP in use.
In our case, this means the old IP address MUST NOT <bcp14>MUST NOT</bcp14> be provided via the DNS when it is not reachable anymore.</t>
      <t>In the make-before-break scenario, it is possible to make the transition seamless.
Let T be the TTL associated with a an RRset of the Public Homenet Zone.
Let Zone;
Time_NEW be the time the new IP address replaces the old IP address in the Homenet Zone, Zone; and Time_OLD_UNREACHABLE be the time the old IP will not be reachable anymore.</t>
      <t>In the case of the make-before-break, make-before-break scenario, seamless reachability is provided as long as Time_OLD_UNREACHABLE - T_NEW &gt; (2 * T).
If this is not satisfied, then devices associated with the old IP address in the home network may become unreachable for 2 * T - (Time_OLD_UNREACHABLE - Time_NEW).</t>
      <t>In the case of a break-before-make, break-before-make scenario, Time_OLD_UNREACHABLE = Time_NEW, and the device may become unreachable up to 2 * T.
Of course course, if Time_NEW &gt;= Time_OLD_UNREACHABLE, then then the outage is not seamless.</t>
    </section>
    <section anchor="sec-privacy"><name>Privacy anchor="sec-privacy">
      <name>Privacy Considerations</name>
      <t>Outsourcing the DNS Authoritative service from the HNA to a third party raises a few privacy related privacy-related concerns.</t>
      <t>The Public Homenet Zone lists the names of services hosted in the home network.
Combined with blocking of AXFR queries, the use of NSEC3 <xref target="RFC5155"/> (vs NSEC (vs.&nbsp;NSEC <xref target="RFC4034"/>) prevents an  attacker from being able to walk the zone, zone to discover all the names.
However, recent work <xref target="GPUNSEC3"/> or <xref target="ZONEENUM"/> have has shown that the protection provided by NSEC3 against dictionary attacks should be considered cautiously cautiously, and <xref target="RFC9276"/> provides guidelines to configure NSEC3 properly. In addition, the attacker may be able to walk the reverse DNS zone, zone or use other reconnaissance techniques to learn this information as described in <xref target="RFC7707"/>.</t>
<t>The zone may be also exposed during the synchronization between the primary and the secondary. The casual risk of this occuring occurring is low, and the use of <xref target="RFC9103"/> significantly reduces this. Even if DNS zone transfer over TLS <xref target="RFC9103"/> is used by the DNS Outsourcing Infrastructure, DOI, it may still leak the existence of the zone through Notifies. The protocol described in this document does not increase that risk, as all Notifies use the encrypted Control Channel.</t>
<t>In general general, a home network owner is expected to publish only names for which there is some need to be able to reference them externally. Publication of the name does not imply that the service is necessarily reachable from any or all parts of the Internet. <xref target="RFC7084"/> mandates that the outgoing-only policy <xref target="RFC6092"/> be available, and in many cases cases, it is configured by default.
A well designed User Interface well-designed user interface would combine a policy for making a service public by a name with a policy on who may access it.</t>
      <t>In many cases, and for privacy reasons, the home network owner wished has wanted to publish names only for services that they will be able to access. The access control may consist of an IP source address range, or access may be restricted via some VPN functionality. The main advantages of publishing the name names are that the service may be access accessed by the same name both within the home and outside the home home, and that the DNS resolution can be handled similarly both within the home and outside the home. This considerably eases the ability to use VPNs where the VPN can be chosen according to the IP address of the service. Typically, a user may configure its device to reach its homenet Homenet devices via a VPN while the remaining of the traffic is accessed directly.</t>
      <t>Enterprise networks have generally adopted another strategy designated as split-horizon-DNS. While such strategy might appear as providing more privacy at first sight, its implementation remains challenging and the privacy advantages needs need to be considered carefully. In split-horizon-DNS, names are designated with internal names that can only be resolved within the corporate network. When such strategy is applied to the homenet, VPNs needs need to be both configured with a naming resolution policies and routing policies. Such an approach might be reasonable with a single VPN, but maintaining a coherent DNS space and IP space among various VPNs comes with serious complexities. Firstly, if multiple homenets are using the same domain name -- like home.arpa -- it becomes difficult to determine on which network the resolution should be performed. As a result, homenets should at least be differentiated by a domain name. Secondly, the use of split-horizon-DNS requires each VPN being to be associated with a resolver and specific resolutions being to be performed by the dedicated resolver. Such policies can easily raises raise some conflicts (with significant privacy issues) while remaining hard to be implemented.</t>
      <t>In addition to the Public Homenet Zone, pervasive DNS monitoring can also monitor the traffic associated with the Public Homenet Zone.
This traffic may provide an indication of the services an end user accesses, plus how and when they use these services. Although, caching may obfuscate this information inside the home network, it is likely that outside your  home network this information will not be cached.</t> cached outside the home network.</t>
    </section>
    <section anchor="sec-security"><name>Security anchor="sec-security">
      <name>Security Considerations</name>
      <t>The HNA never answers DNS requests from the Internet.
These requests are instead served by the DOI.</t>
      <t>While this limits the level of exposure of the HNA, the HNA still has some exposure to attacks from the Internet.
This section analyses the attack surface associated with these communications, the data published by the DOI, as well as operational considerations.</t>
      <section anchor="registered-homenet-domain"><name>Registered anchor="registered-homenet-domain">
        <name>Registered Homenet Domain</name>
        <t>The DOI MUST NOT <bcp14>MUST NOT</bcp14> serve any Public Homenet Zone that when it has is not strong confidence confident that the HNA owns the Registered Homenet Domain.
Proof of ownership is outside the document scope of this document, and it is assumed that such a phase has preceded the outsourcing of the zone.</t>
      </section>
      <section anchor="hna-dm-channels"><name>HNA anchor="hna-dm-channels">
        <name>HNA DM channels</name> Channels</name>
        <t>The channels between HNA and DM are mutually authenticated and encrypted with TLS <xref target="RFC8446"/> target="RFC8446"/>, and its associated security considerations apply.</t>
        <t>To ensure that the multiple TLS session sessions are continuously authenticating the same entity, TLS may take advantage of second factor second-factor authentication as described in <xref target="RFC8672"/> for the TLS server certificate for the Control Channel. The HNA should also cache the TLS server certificate used by the DM, in order to authenticate the DM during the setup of the Synchronization Channel. (Alternatively, the HNA is configured with an ACL from which Synchronization Channel connections will originate)</t> originate.)</t>
        <t>The Control Channel and the Synchronization Channel respectively follow <xref follow the guidelines in <xref target="RFC7858"/> and <xref target="RFC9103"/> guidelines.</t> target="RFC9103"/>, respectively.</t>
        <t>The DNS protocol is subject to reflection attacks, attacks; however, these attacks are largely applicable when DNS is carried over UDP. The interfaces between the HNA and DM are using TLS over TCP, which prevents such reflection attacks.
Note that Public Authoritative servers hosted by the DOI are subject to such attacks, but that is out of scope of our this document.</t>
        <t>Note that in the case of the Reverse Homenet Zone, the data is less subject to attacks than in the Public Homenet Zone. In addition, the DM and Reverse Distribution Manager (RDM) may be provided by the ISP - -- as described in <xref target="I-D.ietf-homenet-naming-architecture-dhc-options"/>, target="RFC9527"/>, in which case DM and RDM might be less exposed to attacks - -- as communications within a network.</t>
      </section>
      <section anchor="sec-name-less-secure"><name>Names are less secure anchor="sec-name-less-secure">
        <name>Names Are Less Secure than IP addresses</name> Addresses</name>
        <t>This document describes how an end user can make their services and devices from their home network reachable on the Internet by using names rather than IP addresses.
	This exposes the home network to attackers, since attackers because names are expected to include less entropy than IP addresses. IPv4 Addresses addresses are 4 bytes 4-bytes long leading to 2**32 2<sup>32</sup> possibilities.
With IPv6 addresses, the Interface Identifier is 64 bits 64-bits long leading to up to 2^64 2<sup>64</sup> possibilities  for a given subnetwork. This is not to mention that the subnet prefix is also of 64 bits 64-bits long, thus providing up to 2^64 2<sup>64</sup> possibilities. On the other hand, names used either for either the home network domain or for the devices present less entropy (livebox, router, printer, nicolas, jennifer, ...) and thus potentially exposes expose the devices to dictionary attacks.</t>
      </section>
      <section anchor="sec-name-less-volatile"><name>Names are less volatile anchor="sec-name-less-volatile">
        <name>Names Are Less Volatile than IP addresses</name> Addresses</name>
        <t>IP addresses may be used to locate a device, a host host, or a service.
However, home networks are not expected to be assigned a time invariant time-invariant prefix by ISPs. In addition addition, IPv6 enables temporary addresses that makes them even more volatile <xref target="RFC8981"/>. As a result, observing IP addresses only provides some ephemeral information about who is accessing the service. On the other hand, names are not expected to be as volatile as IP addresses. As a result, logging names over time may be more valuable than logging IP addresses, especially to profile an end user's characteristics.</t>
        <t>PTR provides a way to bind an IP address to a name.
In that sense, responding to PTR DNS queries may affect the end user's privacy.
For that reason reason, PTR DNS queries and MAY instead <bcp14>MAY</bcp14> be configured to return with NXDOMAIN.</t> NXDOMAIN instead.</t>
      </section>
      <section anchor="deployment-considerations"><name>Deployment anchor="deployment-considerations">
        <name>Deployment Considerations</name>
        <t>The HNA is expected to sign the DNSSEC zone and and, as such such, hold the private KSK/ZSK.</t>

<t>There KSK and Zone Signing Key (ZSK).</t>
        <t>In this case, there is no strong justification in this case to use a separate KSK and ZSK.
If an attacker can get access to one of them, it is likely that they will access both of them.
If the HNA is run in a home router with a secure element (SE) or TPM, trusted platform module (TPM), storing the private keys in the secure element would be a useful precaution. The DNSSEC keys are generally needed on an hourly to weekly basis, but not more often.</t>
        <t>While there is some risk that the DNSSEC keys might be disclosed by malicious parties, the bigger risk is that they will simply be lost if the home router is factory reset, reset or just thrown out/replaced out / replaced with a newer model.</t>
        <t>Generating new DNSSEC keys is relatively easy, easy; they can be deployed using the Control Channel to the DM.
The key that is used to authenticate that connection is the critical key that needs protection, protection and should ideally be backed up to offline storage. (Such storage (such as a USB key)</t> key).</t>
      </section>
      <section anchor="operational-considerations"><name>Operational anchor="operational-considerations">
        <name>Operational Considerations</name>

<t>HomeNet
        <t>Homenet technologies makes make it easier to expose devices and services to the
Internet.  This imposes broader operational considerations for the operator and
the Internet:</t>

<t><list style="symbols">
  <t>The Internet as follows:</t>
        <ul spacing="normal">
          <li>The home network operator must carefully assess whether a device or service
previously fielded only on a home network is robust enough to be exposed to the
Internet</t>
  <t>The
Internet.</li>
          <li>The home network operator will need to increase the diligence to regularly
managing these exposed devices due to their increased risk posture of being
exposed to the Internet</t>
  <t>Depending Internet.</li>
          <li>Depending on the operational practices of the home network operators, there
is an increased risk to the Internet through the possible
introduction of additional internet-exposed system Internet-exposed systems that are poorly managed and
likely to be compromised.</t>
</list></t> compromised.</li>
        </ul>
      </section>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no actions for IANA.</t>

</section>
<section anchor="acknowledgment"><name>Acknowledgment</name>

<t>The authors wish to thank Philippe Lemordant for his contributions on
the early versions of the draft; Ole Troan for pointing out issues with
the IPv6 routed home concept and placing the scope of this document in a
wider picture; Mark Townsley for encouragement and injecting a healthy
debate on the merits of the idea; Ulrik de Bie for providing alternative
solutions; Paul Mockapetris, Christian Jacquenet, Francis Dupont and
Ludovic Eschard for their remarks on HNA and low power devices; Olafur
Gudmundsson for clarifying DNSSEC capabilities of small devices; Simon
Kelley for its feedback as dnsmasq implementer; Andrew Sullivan, Mark
Andrew, Ted Lemon, Mikael Abrahamson, Stephen Farrell, and Ray Bellis
for their feedback on handling different views as well as clarifying the
impact of outsourcing the zone signing operation outside the HNA; Mark
Andrew and Peter Koch for clarifying the renumbering.</t>

<t>The authors would like to thank Kiran Makhijani for her in-depth review that contributed in shaping the final version.</t>

<t>The authors would like to thank our Area Directorate Éric Vyncke for his constant support and pushing the document through the IESG as well as the many reviewers from various directorates including Anthony Somerset, Geoff Huston, Tim Chown, Tim Wicinski, Matt Brown, Darrel Miller, Chirster Holmberg.</t>

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

<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> IANA actions.</t>
    </section>
  </middle>
  <back>

    <references title='Normative References'>

<reference anchor='RFC2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></author>
<date month='March' year='1997'/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference anchor='RFC8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></author>
<date month='May' year='2017'/>
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<reference anchor='RFC8375'>
<front>
<title>Special-Use Domain 'home.arpa.'</title>
<author fullname='P. Pfister' initials='P.' surname='Pfister'><organization/></author>
<author fullname='T. Lemon' initials='T.' surname='Lemon'><organization/></author>
<date month='May' year='2018'/>
<abstract><t>This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks.  The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.</t></abstract>
</front>
<seriesInfo name='RFC' value='8375'/>
<seriesInfo name='DOI' value='10.17487/RFC8375'/>
</reference>

<reference anchor='RFC1918'>
<front>
<title>Address Allocation for Private Internets</title>
<author fullname='Y. Rekhter' initials='Y.' surname='Rekhter'><organization/></author>
<author fullname='B. Moskowitz' initials='B.' surname='Moskowitz'><organization/></author>
<author fullname='D. Karrenberg' initials='D.' surname='Karrenberg'><organization/></author>
<author fullname='G. J. de Groot' initials='G. J.' surname='de Groot'><organization/></author>
<author fullname='E. Lear' initials='E.' surname='Lear'><organization/></author>
<date month='February' year='1996'/>
<abstract><t>This document describes address allocation for private internets.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='5'/>
<seriesInfo name='RFC' value='1918'/>
<seriesInfo name='DOI' value='10.17487/RFC1918'/>
</reference>

<reference anchor='RFC8499'>
<front>
<title>DNS Terminology</title>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></author>
<author fullname='A. Sullivan' initials='A.' surname='Sullivan'><organization/></author>
<author fullname='K. Fujiwara' initials='K.' surname='Fujiwara'><organization/></author>
<date month='January' year='2019'/>
<abstract><t>The Domain Name System (DNS) is defined in literally dozens of different RFCs.  The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined.  This document gives current definitions for many of the terms used in the DNS in a single document.</t><t>This document obsoletes RFC 7719 and updates RFC 2308.</t></abstract>
</front>
<seriesInfo name='BCP' value='219'/>
<seriesInfo name='RFC' value='8499'/>
<seriesInfo name='DOI' value='10.17487/RFC8499'/>
</reference>

<reference anchor='RFC7858'>
<front>
<title>Specification for DNS over Transport Layer Security (TLS)</title>
<author fullname='Z. Hu' initials='Z.' surname='Hu'><organization/></author>
<author fullname='L. Zhu' initials='L.' surname='Zhu'><organization/></author>
<author fullname='J. Heidemann' initials='J.' surname='Heidemann'><organization/></author>
<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></author>
<author fullname='D. Wessels' initials='D.' surname='Wessels'><organization/></author>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></author>
<date month='May' year='2016'/>
<abstract><t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS.  Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626.  In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t><t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group.  It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t></abstract>
</front>
<seriesInfo name='RFC' value='7858'/>
<seriesInfo name='DOI' value='10.17487/RFC7858'/>
</reference>

<reference anchor='RFC9103'>
<front>
<title>DNS Zone Transfer over TLS</title>
<author fullname='W. Toorop' initials='W.' surname='Toorop'><organization/></author>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/></author>
<author fullname='S. Sahib' initials='S.' surname='Sahib'><organization/></author>
<author fullname='P. Aras' initials='P.' surname='Aras'><organization/></author>
<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></author>
<date month='August' year='2021'/>
<abstract><t>DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with respect to the recommended number of connections between a client and server for each transport.</t></abstract>
</front>
<seriesInfo name='RFC' value='9103'/>
<seriesInfo name='DOI' value='10.17487/RFC9103'/>
</reference>

<reference anchor='RFC7344'>
<front>
<title>Automating DNSSEC Delegation Trust Maintenance</title>
<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></author>
<author fullname='O. Gudmundsson' initials='O.' surname='Gudmundsson'><organization/></author>
<author fullname='G. Barwood' initials='G.' surname='Barwood'><organization/></author>
<date month='September' year='2014'/>
<abstract><t>This document describes a method to allow DNS Operators to more easily update DNSSEC Key Signing Keys using the DNS as a communication channel.  The technique described is aimed at delegations in which it is currently hard to move information from the Child to Parent.</t></abstract>
</front>
<seriesInfo name='RFC' value='7344'/>
<seriesInfo name='DOI' value='10.17487/RFC7344'/>
</reference>

<reference anchor='RFC8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/></author>
<date month='August' year='2018'/>
<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='8446'/>
<seriesInfo name='DOI' value='10.17487/RFC8446'/>
</reference>

<reference anchor='RFC1034'>
<front>
<title>Domain names - concepts and facilities</title>
<author fullname='P. Mockapetris' initials='P.' surname='Mockapetris'><organization/></author>
<date month='November' year='1987'/>
<abstract><t>This RFC is the revised basic definition of The Domain Name System.  It obsoletes RFC-882.  This memo describes the domain style names and their used for host address look up and electronic mail forwarding.  It discusses the clients and servers in the domain name system and the protocol used between them.</t></abstract>
</front>
<seriesInfo name='STD' value='13'/>
<seriesInfo name='RFC' value='1034'/>
<seriesInfo name='DOI' value='10.17487/RFC1034'/>
</reference>

<reference anchor='RFC3007'>
<front>
<title>Secure Domain Name System (DNS) Dynamic Update</title>
<author fullname='B. Wellington' initials='B.' surname='Wellington'><organization/></author>
<date month='November' year='2000'/>
<abstract><t>This document proposes a method for performing secure Domain Name System (DNS) dynamic updates.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3007'/>
<seriesInfo name='DOI' value='10.17487/RFC3007'/>
</reference>

<reference anchor='I-D.ietf-uta-rfc6125bis'>
   <front>
      <title>Service Identity in TLS</title>
      <author fullname='Peter Saint-Andre' initials='P.' surname='Saint-Andre'>
         <organization>independent</organization>
      </author>
      <author fullname='Rich Salz' initials='R.' surname='Salz'>
         <organization>Akamai Technologies</organization>
      </author>
      <date day='25' month='January' year='2023'/>
      <abstract>
	 <t>   Many application technologies enable secure communication between two
   entities by means of Transport Layer Security (TLS) with Internet
   Public Key Infrastructure Using X.509 (PKIX) certificates.  This
   document specifies procedures for representing and verifying the
   identity of application services in such interactions.

   This document obsoletes RFC 6125.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-uta-rfc6125bis-10'/>

</reference>

<reference anchor='RFC1996'>
<front>
<title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>
<author fullname='P. Vixie' initials='P.' surname='Vixie'><organization/></author>
<date month='August' year='1996'/>
<abstract><t>This memo describes the NOTIFY opcode for DNS, by which a master server advises a set of slave servers that the master's data has been changed and that a query should be initiated to discover the new data. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='1996'/>
<seriesInfo name='DOI' value='10.17487/RFC1996'/>
</reference>

<reference anchor='RFC5155'>
<front>
<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>
<author fullname='B. Laurie' initials='B.' surname='Laurie'><organization/></author>
<author fullname='G. Sisson' initials='G.' surname='Sisson'><organization/></author>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></author>
<author fullname='D. Blacka' initials='D.' surname='Blacka'><organization/></author>
<date month='March' year='2008'/>
<abstract><t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence.  However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5155'/>
<seriesInfo name='DOI' value='10.17487/RFC5155'/>
</reference>

<reference anchor='RFC4034'>
<front>
<title>Resource Records for the DNS Security Extensions</title>
<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></author>
<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></author>
<author fullname='M. Larson' initials='M.' surname='Larson'><organization/></author>
<author fullname='D. Massey' initials='D.' surname='Massey'><organization/></author>
<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>
<date month='March' year='2005'/>
<abstract><t>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC).  The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS.  This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records.  The purpose and format of each resource record is described in detail, and an example of each resource record

<displayreference target="I-D.ietf-dnsop-domain-verification-techniques" to="DOMAIN-VALIDATION"/>
<displayreference target="I-D.ietf-dnsop-dnssec-validator-requirements" to="DRO-RECS"/>
<displayreference target="I-D.ietf-dnsop-ns-revalidation" to="NS-REVALIDATION"/>
<displayreference target="I-D.richardson-homerouter-provisioning" to="HOMEROUTER-PROVISION"/>

    <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"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8375.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.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.7344.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.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.3007.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1996.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>

	<!-- [I-D.ietf-uta-rfc6125bis] is given. </t><t> This document obsoletes RFC 2535 and incorporates changes from all updates to now RFC 2535.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4034'/>
<seriesInfo name='DOI' value='10.17487/RFC4034'/>
</reference> 9525 -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9525.xml"/>

      </references>

    <references title='Informative References'>
      <references>
        <name>Informative References</name>

        <reference anchor="GPUNSEC3" target="https://doi.org/10.1109/NCA.2014.27">
          <front>
            <title>GPU-Based NSEC3 Hash Breaking</title>
            <author initials="M." surname="Wander">
      <organization></organization>
              <organization/>
            </author>
            <author initials="L." surname="Schwittmann">
      <organization></organization>
              <organization/>
            </author>
            <author initials="C." surname="Boelmann">
      <organization></organization>
              <organization/>
            </author>
            <author initials="T." surname="Weis">
      <organization></organization>
              <organization/>
            </author>
            <date year="n.d."/> month="August" year="2014"/>
          </front>
	   <seriesInfo name="DOI" value="10.1109/NCA.2014.27" />
        </reference>

        <reference anchor="ZONEENUM" > anchor="ZONEENUM">
          <front>
            <title>An efficient DNSSEC zone enumeration algorithm</title>
            <author initials="Z." surname="Wang">
      <organization></organization>
              <organization/>
            </author>
            <author initials="L." surname="Xiao">
      <organization></organization>
              <organization/>
            </author>
            <author initials="R." surname="Wang">
      <organization></organization>
              <organization/>
            </author>
            <date year="n.d."/> month="April" year="2014"/>
          </front>
	  <seriesInfo name="DOI" value="10.2495/MIIT130591" />
        </reference>

        <reference anchor="REBIND" target="https://en.wikipedia.org/wiki/DNS_rebinding"> target="https://en.wikipedia.org/w/index.php?title=DNS_rebinding&amp;oldid=1173433859">
          <front>
            <title>DNS rebinding</title>
    <author >
      <organization></organization>
            <author>
              <organization>Wikipedia</organization>
            </author>
            <date year="n.d."/> month="September" year="2023"/>
          </front>
        </reference>

<reference anchor='RFC6762'>
<front>
<title>Multicast DNS</title>
<author fullname='S. Cheshire' initials='S.' surname='Cheshire'><organization/></author>
<author fullname='M. Krochmal' initials='M.' surname='Krochmal'><organization/></author>
<date month='February' year='2013'/>
<abstract><t>As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important.  In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.</t><t>Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server.  In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.</t><t>The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.</t></abstract>
</front>
<seriesInfo name='RFC' value='6762'/>
<seriesInfo name='DOI' value='10.17487/RFC6762'/>
</reference>

<reference anchor='RFC8415'>
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author fullname='T. Mrugalski' initials='T.' surname='Mrugalski'><organization/></author>
<author fullname='M. Siodelski' initials='M.' surname='Siodelski'><organization/></author>
<author fullname='B. Volz' initials='B.' surname='Volz'><organization/></author>
<author fullname='A. Yourtchenko' initials='A.' surname='Yourtchenko'><organization/></author>
<author fullname='M. Richardson' initials='M.' surname='Richardson'><organization/></author>
<author fullname='S. Jiang' initials='S.' surname='Jiang'><organization/></author>
<author fullname='T. Lemon' initials='T.' surname='Lemon'><organization/></author>
<author fullname='T. Winters' initials='T.' surname='Winters'><organization/></author>
<date month='November' year='2018'/>
<abstract><t>This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes.  DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC).</t><t>This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283).  In addition, this document clarifies the interactions between models of operation (RFC 7550).  As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.</t></abstract>
</front>
<seriesInfo name='RFC' value='8415'/>
<seriesInfo name='DOI' value='10.17487/RFC8415'/>
</reference>

<reference anchor='RFC6887'>
<front>
<title>Port Control Protocol (PCP)</title>
<author fullname='D. Wing' initials='D.' role='editor' surname='Wing'><organization/></author>
<author fullname='S. Cheshire' initials='S.' surname='Cheshire'><organization/></author>
<author fullname='M. Boucadair' initials='M.' surname='Boucadair'><organization/></author>
<author fullname='R. Penno' initials='R.' surname='Penno'><organization/></author>
<author fullname='P. Selkirk' initials='P.' surname='Selkirk'><organization/></author>
<date month='April' year='2013'/>
<abstract><t>The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.</t></abstract>
</front>
<seriesInfo name='RFC' value='6887'/>
<seriesInfo name='DOI' value='10.17487/RFC6887'/>
</reference>

<reference anchor='RFC3787'>
<front>
<title>Recommendations for Interoperable IP Networks using Intermediate System to Intermediate System (IS-IS)</title>
<author fullname='J. Parker' initials='J.' role='editor' surname='Parker'><organization/></author>
<date month='May' year='2004'/>
<abstract><t>This document discusses a number of differences between the Intermediate System to Intermediate System (IS-IS) protocol used to route IP traffic as described in RFC 1195 and the protocol as it is deployed today.  These differences are discussed as a service to those implementing, testing, and deploying the IS-IS Protocol to route IP traffic.  A

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml"/>
        <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.6887.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3587.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7404.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3927.xml"/>

<!-- [I-D.ietf-homenet-naming-architecture-dhc-options] companion document describes the differences between the protocol described in ISO 10589 and current practice.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='3787'/>
<seriesInfo name='DOI' value='10.17487/RFC3787'/>
</reference>

<reference anchor='RFC4193'>
<front>
<title>Unique Local IPv6 Unicast Addresses</title>
<author fullname='R. Hinden' initials='R.' surname='Hinden'><organization/></author>
<author fullname='B. Haberman' initials='B.' surname='Haberman'><organization/></author>
<date month='October' year='2005'/>
<abstract><t>This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4193'/>
<seriesInfo name='DOI' value='10.17487/RFC4193'/>
</reference>

<reference anchor='RFC4291'>
<front>
<title>IP Version 6 Addressing Architecture</title>
<author fullname='R. Hinden' initials='R.' surname='Hinden'><organization/></author>
<author fullname='S. Deering' initials='S.' surname='Deering'><organization/></author>
<date month='February' year='2006'/>
<abstract><t>This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol.  The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t><t>This document obsoletes RFC 3513, &quot;IP Version 6 Addressing Architecture&quot;.   [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4291'/>
<seriesInfo name='DOI' value='10.17487/RFC4291'/>
</reference>

<reference anchor='RFC7404'>
<front>
<title>Using Only Link-Local Addressing inside an IPv6 Network</title>
<author fullname='M. Behringer' initials='M.' surname='Behringer'><organization/></author>
<author fullname='E. Vyncke' initials='E.' surname='Vyncke'><organization/></author>
<date month='November' year='2014'/>
<abstract><t>In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers.  This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.</t></abstract>
</front>
<seriesInfo name='RFC' value='7404'/>
<seriesInfo name='DOI' value='10.17487/RFC7404'/>
</reference>

<reference anchor='RFC3927'>
<front>
<title>Dynamic Configuration of IPv4 Link-Local Addresses</title>
<author fullname='S. Cheshire' initials='S.' surname='Cheshire'><organization/></author>
<author fullname='B. Aboba' initials='B.' surname='Aboba'><organization/></author>
<author fullname='E. Guttman' initials='E.' surname='Guttman'><organization/></author>
<date month='May' year='2005'/>
<abstract><t>To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server.  Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available.  This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link.</t><t>IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks).  This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='3927'/>
<seriesInfo name='DOI' value='10.17487/RFC3927'/>
</reference> 9527 -->
<reference anchor='I-D.ietf-homenet-naming-architecture-dhc-options'> anchor="RFC9527" target="https://www.rfc-editor.org/info/rfc9527">
<front>
<title>DHCPv6 Options for Home Network the Homenet Naming Authority</title>
<author initials='D' surname='Migault' fullname='Daniel Migault' initials='D.' surname='Migault'>
         <organization>Ericsson</organization> Migault'>
<organization />
</author>
<author initials='R' surname='Weber' fullname='Ralf Weber' initials='R.' surname='Weber'>
         <organization>Akamai</organization> Weber'>
<organization />
</author>
<author initials='T' surname='Mrugalski' fullname='Tomek Mrugalski' initials='T.' surname='Mrugalski'>
         <organization>Internet Systems Consortium, Inc.</organization> Mrugalski'>
<organization />
</author>
<date day='31' month='October' year='2022'/>
      <abstract>
	 <t>   This document defines DHCPv6 options so a Homenet Naming Authority
   (HNA) can automatically proceed to 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> year='2024' month='January' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-homenet-naming-architecture-dhc-options-24'/> name="RFC" value="9527"/>
<seriesInfo name="DOI" value="10.17487/RFC9527"/>
</reference>

<reference anchor='RFC8555'>
<front>
<title>Automatic Certificate Management Environment (ACME)</title>
<author fullname='R. Barnes' initials='R.' surname='Barnes'><organization/></author>
<author fullname='J. Hoffman-Andrews' initials='J.' surname='Hoffman-Andrews'><organization/></author>
<author fullname='D. McCarney' initials='D.' surname='McCarney'><organization/></author>
<author fullname='J. Kasten' initials='J.' surname='Kasten'><organization/></author>
<date month='March' year='2019'/>
<abstract><t>Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication

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

<!-- [I-D.ietf-dnsop-domain-verification-techniques] IESG state	I-D Exists as of domain names.  Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in 1/22/24; entered the certificate.  As of this writing, this verification is done through a collection of ad hoc mechanisms.  This document describes a protocol that a CA and an applicant can use long way to automate get the process of verification and certificate issuance.  The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t></abstract>
</front>
<seriesInfo name='RFC' value='8555'/>
<seriesInfo name='DOI' value='10.17487/RFC8555'/>
</reference> correct author initials -->
	<reference anchor='I-D.ietf-dnsop-domain-verification-techniques'> anchor="I-D.ietf-dnsop-domain-verification-techniques" target="https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03">
  <front>
      <title>Survey of Domain Verification Techniques
    <title>Domain Control Validation using DNS</title>
    <author fullname='Shivan fullname="Shivan Kaul Sahib' initials='S. K.' surname='Sahib'> Sahib" initials="S." surname="Sahib">
      <organization>Brave Software</organization>
    </author>
    <author fullname='Shumon Huque' initials='S.' surname='Huque'> fullname="Shumon Huque" initials="S." surname="Huque">
      <organization>Salesforce</organization>
    </author>
    <author fullname='Paul Wouters' initials='P.' surname='Wouters'> fullname="Paul Wouters" initials="P." surname="Wouters">
      <organization>Aiven</organization>
    </author>
    <author fullname="Erik Nygren" initials="E." surname="Nygren">
      <organization>Akamai Technologies</organization>
    </author>
    <date day='28' month='July' year='2022'/>
      <abstract>
	 <t>   Many services on the Internet need to verify ownership or control of
   a domain in the Domain Name System (DNS) [RFC1034] [RFC1035].  This
   verification is often done by requesting a specific DNS record to be
   visible in the domain.  This document surveys various techniques in
   wide use today, the pros and cons of each, and proposes some
   practices to avoid known problems.

	 </t>
      </abstract> day="17" month="October" year="2023"/>
  </front>
  <seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-domain-verification-techniques-00'/> name="Internet-Draft" value="draft-ietf-dnsop-domain-verification-techniques-03"/>
</reference>

<reference anchor='RFC7788'>
<front>
<title>Home Networking Control Protocol</title>
<author fullname='M. Stenberg' initials='M.' surname='Stenberg'><organization/></author>
<author fullname='S. Barth' initials='S.' surname='Barth'><organization/></author>
<author fullname='P. Pfister' initials='P.' surname='Pfister'><organization/></author>
<date month='April' year='2016'/>
<abstract><t>This document describes the Home Networking Control Protocol (HNCP), an extensible configuration protocol, and a set of requirements for home network devices.  HNCP is described

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

        <!-- [I-D.ietf-dnsop-dnssec-validator-requirements] IESG state I-D Exists: Revised I-D Needed -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-dnsop-dnssec-validator-requirements.xml"/>

<!-- [I-D.ietf-dnsop-ns-revalidation] IESG state Expired as a profile of and extension to the Distributed Node Consensus Protocol (DNCP).  HNCP enables discovery of network borders, automated configuration of addresses, name resolution, service discovery, and the use of any routing protocol that supports routing based on both 1/22/24; entered the source and destination address.</t></abstract>
</front>
<seriesInfo name='RFC' value='7788'/>
<seriesInfo name='DOI' value='10.17487/RFC7788'/>
</reference>

<reference anchor='I-D.ietf-dnsop-dnssec-validator-requirements'>
   <front>
      <title>Recommendations for DNSSEC Resolvers Operators</title>
      <author fullname='Daniel Migault' initials='D.' surname='Migault'>
         <organization>Ericsson</organization>
      </author>
      <author fullname='Edward Lewis' initials='E.' surname='Lewis'>
         <organization>ICANN</organization>
      </author>
      <author fullname='Dan York' initials='D.' surname='York'>
         <organization>ISOC</organization>
      </author>
      <date day='25' month='January' year='2023'/>
      <abstract>
	 <t>   The DNS Security Extensions (DNSSEC) define a process for validating
   received data and assert them authentic and complete as opposed long way to
   forged.

   This document clarifies get the scope and responsibilities of DNSSEC
   Resolver Operators (DRO) as well as operational recommendations that
   DNSSEC validators operators SHOULD put in place in order to implement
   sufficient trust that makes DNSSEC validation output accurate.  The
   recommendations described in this document include, provisioning
   mechanisms as well as monitoring and management mechanisms.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-dnssec-validator-requirements-04'/>

</reference> right author intials -->
<reference anchor='I-D.ietf-dnsop-ns-revalidation'> anchor="I-D.ietf-dnsop-ns-revalidation" target="https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation-04">
  <front>
    <title>Delegation Revalidation by DNS Resolvers</title>
    <author fullname='Shumon Huque' initials='S.' surname='Huque'> fullname="Shumon Huque" initials="S." surname="Huque">
      <organization>Salesforce</organization>
    </author>
    <author fullname='Paul fullname="Paul A. Vixie' initials='P. A.' surname='Vixie'>
         <organization>Farsight Security</organization> Vixie" initials="P." surname="Vixie">
      <organization>SIE Europe, U.G.</organization>
    </author>
    <author fullname='Ralph Dolmans' initials='R.' surname='Dolmans'> fullname="Ralph Dolmans" initials="R." surname="Dolmans">
      <organization>NLnet Labs</organization>
    </author>
    <date day='6' month='September' year='2022'/>
      <abstract>
	 <t>   This document recommends improved DNS [RFC1034] [RFC1035] resolver
   behavior with respect to the processing of Name Server (NS) resource
   record sets (RRset) during iterative resolution.  When following a
   referral response from an authoritative server to a child zone, DNS
   resolvers should explicitly query the authoritative NS RRset at the
   apex of the child zone and cache this in preference to the NS RRset
   on the parent side of the zone cut.  Resolvers should also
   periodically revalidate the child delegation by re-quering the parent
   zone at the expiration of the TTL of the parent side NS RRset.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-ns-revalidation-03'/>

</reference>

<reference anchor='RFC2136'>
<front>
<title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
<author fullname='P. Vixie' initials='P.' role='editor' surname='Vixie'><organization/></author>
<author fullname='S. Thomson' initials='S.' surname='Thomson'><organization/></author>
<author fullname='Y. Rekhter' initials='Y.' surname='Rekhter'><organization/></author>
<author fullname='J. Bound' initials='J.' surname='Bound'><organization/></author>
<date month='April' year='1997'/>
<abstract><t>Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone.  Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2136'/>
<seriesInfo name='DOI' value='10.17487/RFC2136'/>
</reference>

<reference anchor='RFC8094'>
<front>
<title>DNS over Datagram Transport Layer Security (DTLS)</title>
<author fullname='T. Reddy' initials='T.' surname='Reddy'><organization/></author>
<author fullname='D. Wing' initials='D.' surname='Wing'><organization/></author>
<author fullname='P. Patil' initials='P.' surname='Patil'><organization/></author>
<date month='February' year='2017'/>
<abstract><t>DNS queries and responses are visible to network elements on the path between the DNS client and its server.  These queries and responses can contain privacy-sensitive information, which is valuable to protect.</t><t>This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks.  As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size.  The proposed mechanism runs over port 853.</t></abstract>
</front>
<seriesInfo name='RFC' value='8094'/>
<seriesInfo name='DOI' value='10.17487/RFC8094'/>
</reference>

<reference anchor='RFC8484'>
<front>
<title>DNS Queries over HTTPS (DoH)</title>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></author>
<author fullname='P. McManus' initials='P.' surname='McManus'><organization/></author>
<date month='October' year='2018'/>
<abstract><t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS.  Each DNS query-response pair is mapped into an HTTP exchange.</t></abstract>
</front>
<seriesInfo name='RFC' value='8484'/>
<seriesInfo name='DOI' value='10.17487/RFC8484'/>
</reference>

<reference anchor='RFC9250'>
<front>
<title>DNS over Dedicated QUIC Connections</title>
<author fullname='C. Huitema' initials='C.' surname='Huitema'><organization/></author>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/></author>
<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></author>
<date month='May' year='2022'/>
<abstract><t>This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.</t></abstract>
</front>
<seriesInfo name='RFC' value='9250'/>
<seriesInfo name='DOI' value='10.17487/RFC9250'/>
</reference>

<reference anchor='RFC8501'>
<front>
<title>Reverse DNS in IPv6 for Internet Service Providers</title>
<author fullname='L. Howard' initials='L.' surname='Howard'><organization/></author>
<date month='November' year='2018'/>
<abstract><t>In IPv4, Internet Service Providers (ISPs) commonly provide IN-ADDR.ARPA information for their customers by prepopulating the zone with one PTR record for every available address.  This practice does not scale in IPv6.  This document analyzes different approaches and considerations for ISPs in managing the IP6.ARPA zone.</t></abstract>
</front>
<seriesInfo name='RFC' value='8501'/>
<seriesInfo name='DOI' value='10.17487/RFC8501'/>
</reference>

<reference anchor='RFC7368'>
<front>
<title>IPv6 Home Networking Architecture Principles</title>
<author fullname='T. Chown' initials='T.' role='editor' surname='Chown'><organization/></author>
<author fullname='J. Arkko' initials='J.' surname='Arkko'><organization/></author>
<author fullname='A. Brandt' initials='A.' surname='Brandt'><organization/></author>
<author fullname='O. Troan' initials='O.' surname='Troan'><organization/></author>
<author fullname='J. Weil' initials='J.' surname='Weil'><organization/></author>
<date month='October' year='2014'/>
<abstract><t>This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing.  The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements.  The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking.  The architecture describes the need for specific protocol extensions for certain additional functionality.  It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network.  There are no recommendations in this text for the IPv4 part of the network.</t></abstract>
</front>
<seriesInfo name='RFC' value='7368'/>
<seriesInfo name='DOI' value='10.17487/RFC7368'/>
</reference>

<reference anchor='RFC5011'>
<front>
<title>Automated Updates of DNS Security (DNSSEC) Trust Anchors</title>
<author fullname='M. StJohns' initials='M.' surname='StJohns'><organization/></author>
<date month='September' year='2007'/>
<abstract><t>This document describes a means for automated, authenticated, and authorized updating of DNSSEC &quot;trust anchors&quot;.  The method provides protection against N-1 key compromises of N keys in the trust point key set.  Based on the trust established by the presence of a current anchor, other anchors may be added at the same place in the hierarchy, and, ultimately, supplant the existing anchor(s).</t><t>This mechanism will require changes to resolver management behavior (but not resolver resolution behavior), and the addition of a single flag bit to the DNSKEY record.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='74'/>
<seriesInfo name='RFC' value='5011'/>
<seriesInfo name='DOI' value='10.17487/RFC5011'/>
</reference>

<reference anchor='RFC4192'>
<front>
<title>Procedures for Renumbering an IPv6 Network without a Flag Day</title>
<author fullname='F. Baker' initials='F.' surname='Baker'><organization/></author>
<author fullname='E. Lear' initials='E.' surname='Lear'><organization/></author>
<author fullname='R. Droms' initials='R.' surname='Droms'><organization/></author>
<date month='September' year='2005'/>
<abstract><t>This document describes a procedure that can be used to renumber a network from one prefix to another.  It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a &quot;make-before-break&quot; transition, as well as addresses naming and configuration management issues.  It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='4192'/>
<seriesInfo name='DOI' value='10.17487/RFC4192'/>
</reference>

<reference anchor='RFC7010'>
<front>
<title>IPv6 Site Renumbering Gap Analysis</title>
<author fullname='B. Liu' initials='B.' surname='Liu'><organization/></author>
<author fullname='S. Jiang' initials='S.' surname='Jiang'><organization/></author>
<author fullname='B. Carpenter' initials='B.' surname='Carpenter'><organization/></author>
<author fullname='S. Venaas' initials='S.' surname='Venaas'><organization/></author>
<author fullname='W. George' initials='W.' surname='George'><organization/></author>
<date month='September' year='2013'/>
<abstract><t>This document briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements associated with IPv6 renumbering.  The content is mainly a gap analysis that provides a basis for future works to identify and develop solutions or to stimulate such development as appropriate.  The gap analysis is organized by the main steps of a renumbering process.</t></abstract>
</front>
<seriesInfo name='RFC' value='7010'/>
<seriesInfo name='DOI' value='10.17487/RFC7010'/>
</reference>

<reference anchor='RFC8978'>
<front>
<title>Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events</title>
<author fullname='F. Gont' initials='F.' surname='Gont'><organization/></author>
<author fullname='J. Žorž' initials='J.' surname='Žorž'><organization/></author>
<author fullname='R. Patterson' initials='R.' surname='Patterson'><organization/></author>
<date month='March' year='2021'/>
<abstract><t>In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit and reliable signaling of that condition (such as when a Customer Edge router crashes and reboots without knowledge of the previously employed prefixes), hosts on the local network may continue using stale prefixes for an unacceptably long time (on the order of several days), thus resulting in connectivity problems. This document describes this issue and discusses operational workarounds that may help to improve network robustness. Additionally, it highlights areas where further work may be needed.</t></abstract>
</front>
<seriesInfo name='RFC' value='8978'/>
<seriesInfo name='DOI' value='10.17487/RFC8978'/>
</reference>

<reference anchor='RFC9276'>
<front>
<title>Guidance for NSEC3 Parameter Settings</title>
<author fullname='W. Hardaker' initials='W.' surname='Hardaker'><organization/></author>
<author fullname='V. Dukhovni' initials='V.' surname='Dukhovni'><organization/></author>
<date month='August' year='2022'/>
<abstract><t>NSEC3 is a DNSSEC mechanism providing proof of nonexistence by asserting that there are no names that exist between two domain names within a zone.  Unlike its counterpart NSEC, NSEC3 avoids directly disclosing the bounding domain name pairs.  This document provides guidance on setting NSEC3 parameters based on recent operational deployment experience.  This document updates RFC 5155 with guidance about selecting NSEC3 iteration and salt parameters.</t></abstract>
</front>
<seriesInfo name='BCP' value='236'/>
<seriesInfo name='RFC' value='9276'/>
<seriesInfo name='DOI' value='10.17487/RFC9276'/>
</reference>

<reference anchor='RFC7707'>
<front>
<title>Network Reconnaissance in IPv6 Networks</title>
<author fullname='F. Gont' initials='F.' surname='Gont'><organization/></author>
<author fullname='T. Chown' initials='T.' surname='Chown'><organization/></author>
<date month='March' year='2016'/>
<abstract><t>IPv6 offers a much larger address space than that of its IPv4 counterpart.  An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or fewer unique addresses.  As a result, it is widely assumed that it would take a tremendous effort to perform address-scanning attacks against IPv6 networks; therefore, IPv6 address-scanning attacks have been considered unfeasible.  This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address-scanning techniques apply to IPv6 networks and exploring some additional techniques that can be employed for IPv6 network reconnaissance.</t></abstract>
</front>
<seriesInfo name='RFC' value='7707'/>
<seriesInfo name='DOI' value='10.17487/RFC7707'/>
</reference>

<reference anchor='RFC7084'>
<front>
<title>Basic Requirements for IPv6 Customer Edge Routers</title>
<author fullname='H. Singh' initials='H.' surname='Singh'><organization/></author>
<author fullname='W. Beebee' initials='W.' surname='Beebee'><organization/></author>
<author fullname='C. Donley' initials='C.' surname='Donley'><organization/></author>
<author fullname='B. Stark' initials='B.' surname='Stark'><organization/></author>
<date month='November' year='2013'/>
<abstract><t>This document specifies requirements for an IPv6 Customer Edge (CE) router.  Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it.  The document also covers IP transition technologies.  Two transition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document.  The document obsoletes RFC 6204.</t></abstract>
</front>
<seriesInfo name='RFC' value='7084'/>
<seriesInfo name='DOI' value='10.17487/RFC7084'/>
</reference>

<reference anchor='RFC6092'>
<front>
<title>Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service</title>
<author fullname='J. Woodyatt' initials='J.' role='editor' surname='Woodyatt'><organization/></author>
<date month='January' year='2011'/>
<abstract><t>This document identifies a set of recommendations for the makers of devices and describes how to provide for &quot;simple security&quot; capabilities at the perimeter of local-area IPv6 networks in Internet-enabled homes and small offices.  This document is not  an Internet Standards Track specification; it is published for  informational purposes.</t></abstract>
</front>
<seriesInfo name='RFC' value='6092'/>
<seriesInfo name='DOI' value='10.17487/RFC6092'/>
</reference>

<reference anchor='RFC8672'>
<front>
<title>TLS Server Identity Pinning with Tickets</title>
<author fullname='Y. Sheffer' initials='Y.' surname='Sheffer'><organization/></author>
<author fullname='D. Migault' initials='D.' surname='Migault'><organization/></author>
<date month='October' year='2019'/>
<abstract><t>Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate. These mechanisms are either not widely deployed or limited to public web browsing.</t><t>This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership of the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions are required.</t></abstract>
</front>
<seriesInfo name='RFC' value='8672'/>
<seriesInfo name='DOI' value='10.17487/RFC8672'/>
</reference>

<reference anchor='RFC8981'>
<front>
<title>Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6</title>
<author fullname='F. Gont' initials='F.' surname='Gont'><organization/></author>
<author fullname='S. Krishnan' initials='S.' surname='Krishnan'><organization/></author>
<author fullname='T. Narten' initials='T.' surname='Narten'><organization/></author>
<author fullname='R. Draves' initials='R.' surname='Draves'><organization/></author>
<date month='February' year='2021'/>
<abstract><t>This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes hosts to generate temporary addresses with randomized interface identifiers for each prefix advertised with autoconfiguration enabled. Changing addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network-activity correlation when the same address is employed for multiple transactions by the same host. Additionally, it reduces the window of exposure of a host as being accessible via an address that becomes revealed as a result of active communication. This document obsoletes RFC 4941.</t></abstract>
</front>
<seriesInfo name='RFC' value='8981'/>
<seriesInfo name='DOI' value='10.17487/RFC8981'/>
</reference>

<reference anchor='RFC6749'>
<front>
<title>The OAuth 2.0 Authorization Framework</title>
<author fullname='D. Hardt' initials='D.' role='editor' surname='Hardt'><organization/></author>
<date month='October' year='2012'/>
<abstract><t>The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.  This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6749'/>
<seriesInfo name='DOI' value='10.17487/RFC6749'/>
</reference>

<reference anchor='RFC8610'>
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
<author fullname='H. Birkholz' initials='H.' surname='Birkholz'><organization/></author>
<author fullname='C. Vigano' initials='C.' surname='Vigano'><organization/></author>
<author fullname='C. Bormann' initials='C.' surname='Bormann'><organization/></author>
<date month='June' year='2019'/>
<abstract><t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t></abstract>
</front>
<seriesInfo name='RFC' value='8610'/>
<seriesInfo name='DOI' value='10.17487/RFC8610'/>
</reference>

<reference anchor='I-D.richardson-homerouter-provisioning'>
   <front>
      <title>Provisioning Initial Device Identifiers into Home Routers</title>
      <author fullname='Michael Richardson' initials='M.' surname='Richardson'>
         <organization>Sandelman Software Works</organization>
      </author>
      <date day='14' month='November' year='2021'/>
      <abstract>
	 <t>   This document describes a method to provisioning an 802.1AR-style
   certificate into a router intended for use in the home.

   The proceedure results in a certificate which can be validated with a
   public trust anchor (&quot;WebPKI&quot;), using a name rather than an IP
   address.  This method is focused on home routers, but can in some
   cases be used by other classes of IoT devices.

   (RFCEDITOR please remove: this document can be found at
   https://github.com/mcr/homerouter-provisioning)

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-richardson-homerouter-provisioning-02'/>

</reference> day="13" month="March" year="2023"/>
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-ns-revalidation-04"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8501.xml"/>
        <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.5011.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4192.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7010.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8978.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9276.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7707.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7084.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6092.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8672.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8981.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>

        <!--[I-D.richardson-homerouter-provisioning] IESG state Expired -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.richardson-homerouter-provisioning.xml"/>

      </references>
    </references>
    <section anchor="hna-channel-configurations"><name>HNA anchor="hna-channel-configurations">
      <name>HNA Channel Configurations</name>
      <section anchor="hna-provisioning"><name>Homenet Public anchor="hna-provisioning">
        <name>Public Homenet Zone</name>
        <t>This document does not deal with how the HNA is provisioned with a trusted relationship to the Distribution Manager for the forward zone.</t>
        <t>This section details what needs to be provisioned into the HNA and serves as a requirements statement for mechanisms.</t>
        <t>The HNA needs to be provisioned with:</t>

<t><list style="symbols">
  <t>the
        <ul spacing="normal">
          <li>the Registered Domain (e.g., myhome.example )</t>
  <t>the myhome.example);</li>
          <li>the contact info information for the Distribution Manager (DM), DM, including the DNS name (FQDN), (the fully qualified domain name (FQDN)), possibly including the IP literal, and a certificate (or anchor) to be used to authenticate the service</t>
  <t>the service;</li>
          <li>the DM transport protocol and port (the default is DNS over TLS, on port 853)</t>
  <t>the 853); and</li>
          <li>the HNA credentials used by the DM for its authentication.</t>
</list></t> authentication.</li>
        </ul>
        <t>The HNA will need to select an IP address for communication for the Synchronization Channel.
This is typically the WAN address of the CPE, but it could be an IPv6 LAN address in the case of a home with multiple ISPs (and multiple border routers).
This is detailed in <xref target="sec-ip-hna"/> when the NS and A or AAAA RRsets are communicated.</t>
        <t>The above parameters MUST be <bcp14>MUST</bcp14> be provisioned for ISP-specific reverse zones.
One example of how to do this can be found in  <xref target="I-D.ietf-homenet-naming-architecture-dhc-options"/>. target="RFC9527"/>.
ISP-specific forward zones MAY <bcp14>MAY</bcp14> also be provisioned using <xref target="I-D.ietf-homenet-naming-architecture-dhc-options"/>, target="RFC9527"/>, but zones which that are not related to a specific ISP zone (such as with a DNS provider) must be provisioned through other means.</t>
        <t>Similarly, if the HNA is provided by a registrar, the HNA may be handed pre-configured preconfigured to the end user.</t>
        <t>In the absence of specific pre-established relation, relations, these pieces of information may be entered manually by the end user. In order to ease the configuration from the end user user, the following scheme may be implemented.</t>
        <t>The HNA may present the end user with a web interface where it that provides the end user the ability to indicate the Registered Homenet Domain or the registrar with, for example example, a preselected list.
Once the registrar has been selected, the HNA redirects the end user to that registrar in order to receive a an access token. The access token will enable the HNA to retrieve the DM parameters associated with the Registered Domain.
These parameters will include the credentials used by the HNA to establish the Control and Synchronization Channels.</t>
        <t>Such architecture limits the necessary steps to configure the HNA from the end user.</t>
      </section>
    </section>
    <section anchor="info-model"><name>Information anchor="info-model">
      <name>Information Model for Outsourced information</name> Information</name>
      <t>This section specifies an optional format for the set of parameters required by the HNA to configure the naming architecture of this document.</t>
      <t>In cases where a home router has not been provisioned by the manufacturer (when forward zones are provided by the manufacturer), manufacturer) or by the ISP (when the ISP provides this service), then a home user/owner will need to configure these settings via an administrative interface.</t>
      <t>By defining a standard format (in JSON) for this configuration information, the user/owner may be able to just copy and paste a configuration blob from the service provider into the administrative interface of the HNA.</t>
      <t>This format may also provide the basis for a future OAUTH2 OAuth 2.0 <xref target="RFC6749"/> flow that could do the setup set up automatically.</t>

      <t>The HNA needs to be configured with the following parameters as described by this CDDL the Concise Data Definition Language (CDDL) <xref target="RFC8610"/>.  These are the parameters are necessary to establish a secure channel between the HNA and the DM as well as to specify the DNS zone that is in the scope of the communication.</t>

<figure><sourcecode

<sourcecode type="cddl"><![CDATA[
hna-configuration = {
  "registered_domain" : tstr,
  "dm"                : tstr,
  ? "dm_transport" : "DoT"
  ? "dm_port"        : uint,
  ? "dm_acl"         : hna-acl / [ +hna-acl ]
  ? "hna_auth_method": hna-auth-method
  ? "hna_certificate": tstr
}

hna-acl          = tstr
hna-auth-method  /= "certificate"
]]></sourcecode></figure>
]]></sourcecode>
      <t>For example:</t>

<!-- NOT actually json, as it is two examples merged -->

<figure><artwork><![CDATA[

<sourcecode><![CDATA[
{
  "registered_domain" : "n8d234f.r.example.net",
  "dm"                : "2001:db8:1234:111:222::2",
  "dm_transport"      : "DoT",
  "dm_port"           : 4433,
  "dm_acl"            : "2001:db8:1f15:62e:21c::/64" "2001:db8:1f15:62e::/64"
                   or [ "2001:db8:1f15:62e:21c::/64", "2001:db8:1f15:62e::/64", ... ]
  "hna_auth_method"   : "certificate",
  "hna_certificate"   : "-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy....", CERTIFICATE-----\nMIIDTjCCFGy..",
}
]]></artwork></figure>
]]></sourcecode>
      <dl>
        <dt>Registered Homenet Domain (registered_domain)</dt>
  <dd>
    <t>The (registered_domain):</dt>
        <dd>The Domain Name of the zone. Multiple Registered Homenet Domains may be provided.
This will generate the creation of multiple Public Homenet Zones. This parameter is mandatory.</t> mandatory.
        </dd>
        <dt>Distribution Manager notification address (dm)</dt>
  <dd>
    <t>The (dm):</dt>
        <dd>The associated FQDNs or IP addresses of the DM to which DNS notifies Notifies should be sent.
This parameter is mandatory. IP addresses are optional optional, and the FQDN is sufficient and preferred.
If there are concerns about the security of the name to IP translation, then DNSSEC should be employed.</t> employed.
        </dd>
      </dl>
      <t>As the session between the HNA and the DM is authenticated with TLS, the use of names is easier.</t>
      <t>As certificates are more commonly emitted for FQDN than for IP addresses, it is preferred to use names and authenticate the name of the DM during the TLS session establishment.</t>
      <dl>
        <dt>Supported Transport (dm_transport):</dt>
  <dd>
    <t>The
        <dd>The transport that carries the DNS exchanges between the HNA and the DM.
Typical
The typical value is "DoT" "DoT", but it may be extended in the future with "DoH", "DoQ" "DoH" or "DoQ", for example.
This parameter is optional optional, and by default the HNA uses DoT.</t> DoT by default.
        </dd>
        <dt>Distribution Manager Port (dm_port):</dt>
  <dd>
    <t>Indicates
        <dd>Indicates the port used by the DM.
This parameter is optional optional, and the default value is provided by the Supported Transport.
In the future, an additional transport may not have a default port, in which case either a default port needs to be defined or this parameter become mandatory.</t> becomes mandatory.
        </dd>
      </dl>
      <t>Note that HNA does not defines define ports for the Synchronization Channel.
In any case, this is not expected to be a part of the configuration, configuration but is instead negotiated through the Configuration Channel.
Currently Currently, the Configuration Channel does not provide this, this and limits its agility to a dedicated IP address. If such agility is needed in the future, additional exchanges will need to be defined.</t>
      <dl>
        <dt>Authentication Method ("hna_auth_method"):</dt>
  <dd>
    <t>How
        <dd>How the HNA authenticates itself to the DM within the TLS connection(s).
The authentication method can typically be "certificate", "psk" "psk", or "none".
This Parameter parameter is optional optional, and by default the Authentication Method is "certificate".</t> "certificate" by default.
        </dd>
        <dt>Authentication data ("hna_certificate", "hna_key"):</dt>
  <dd>
    <t>The
        <dd>The certificate chain used to authenticate the HNA.
This parameter is optional optional, and when not specified, a self-signed certificate is used.</t> used.
        </dd>
        <dt>Distribution Manager AXFR permission netmask (dm_acl):</dt>
  <dd>
    <t>The
        <dd>The subnet from which the CPE should accept SOA queries and AXFR requests.
A subnet is used in the case where the DOI consists of a number of different systems. An
array of addresses is permitted. This parameter is optional optional, and if unspecified, the CPE uses the IP addresses provided by the dm parameter either directly when the dm indicates an IP address or the IP addresses address(es) returned by the DNS(SEC) DNS or DNSSEC resolution when dm indicates a FQDN.</t> an FQDN.
        </dd>
      </dl>
      <t>For forward zones, the relationship between the HNA and the forward zone provider may be the result of a number of transactions:</t>

<t><list style="numbers">
  <t>The
      <ol spacing="normal" type="1">
	<li>The forward zone outsourcing may be provided by the maker of the Homenet router.
In this case, the identity and authorization could be built in the device at the manufacturer provisioning time. The device would need to be provisioned with a device-unique credential, and it is likely that the Registered Homenet Domain would be derived from a public attribute of the device, such as a serial number (see <xref target="sec-ex-manu"/> or <xref target="I-D.richardson-homerouter-provisioning"/> for more details ).</t>
  <t>The details).</li>
        <li>The forward zone outsourcing may be provided by the Internet Service Provider. ISP.
In this case, the use of <xref target="I-D.ietf-homenet-naming-architecture-dhc-options"/> target="RFC9527"/> to provide the credentials is appropriate.</t>
  <t>The appropriate.</li>
        <li>The forward zone may be outsourced to a third party, such as a domain registrar.
In this case, the use of the JSON-serialized YANG data model described in this section is appropriate, as it can easily be copy and pasted by the user, user or downloaded as part of a web transaction.</t>
</list></t> transaction.</li>
      </ol>
      <t>For reverse zones, the relationship is always with the upstream ISP (although there may be more than one), and so <xref target="I-D.ietf-homenet-naming-architecture-dhc-options"/> is target="RFC9527"/> always the appropriate interface.</t> applies.</t>
      <t>The following is an abbridged abridged example of a set of data that represents the needed configuration parameters for outsourcing.</t>
    </section>
    <section anchor="sec-ex-manu"><name>Example: anchor="sec-ex-manu">
      <name>Example: A manufacturer provisioned Manufacturer-Provisioned HNA product flow</name> Product Flow</name>
      <t>This scenario is one where a homenet Homenet router device manufacturer decides to offer DNS hosting as a value add.</t>
      <t><xref target="I-D.richardson-homerouter-provisioning"/> describes a process for a home router
credential provisioning system.
The outline of it is that near the end of the manufacturing process, as part of the firmware loading, the manufacturer provisions a private key and certificate into the device.</t>
      <t>In addition to having a assymmetric an asymmetric credential known to the manufacturer, the device also has
been provisioned with an agreed upon agreed-upon name.  In the example in the above document, the name "n8d234f.r.example.net" has already been allocated and confirmed with the manufacturer.</t>
      <t>The HNA can use the above domain for itself.
It is not very pretty or personal, but if the owner wishes would like to have a better name, they can arrange for it.</t>
      <t>The configuration would look like:</t>

<figure><artwork><![CDATA[ like the following:</t>
      <artwork><![CDATA[
{
  "dm" : "2001:db8:1234:111:222::2",
  "dm_acl"    : "2001:db8:1234:111:222::/64",
  "dm_ctrl"   : "manufacturer.example.net",
  "dm_port"   : "4433",
  "ns_list"   : [ "ns1.publicdns.example", "ns2.publicdns.example"],
  "zone"      : "n8d234f.r.example.net",
  "auth_method" : "certificate",
  "hna_certificate":"-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy....",
}
]]></artwork></figure>
]]></artwork>
      <t>The dm_ctrl and dm_port values would be built into the firmware.</t>
    </section>
   <section anchor="acknowledgment" numbered="false">
      <name>Acknowledgments</name>
      <t>The authors wish to thank <contact fullname="Philippe Lemordant"/> for his contributions to
the earlier draft versions of this document; <contact fullname="Ole Troan"/> for pointing out issues with
the IPv6-routed home concept and placing the scope of this document in a
wider picture; <contact fullname="Mark Townsley"/> for encouragement and injecting a healthy
debate on the merits of the idea; <contact fullname="Ulrik de Bie"/> for providing alternative
solutions; <contact fullname="Paul Mockapetris"/>, <contact fullname="Christian Jacquenet"/>, <contact fullname="Francis Dupont"/>, and <contact fullname="Ludovic Eschard"/> for their remarks on HNA and low power devices; <contact fullname="Olafur Gudmundsson"/> for clarifying DNSSEC capabilities of small devices; <contact fullname="Simon Kelley"/> for its feedback as dnsmasq implementer; <contact fullname="Andrew Sullivan"/>, <contact fullname="Mark Andrew"/>, <contact fullname="Ted Lemon"/>, <contact fullname="Mikael Abrahamson"/>, <contact fullname="Stephen Farrell"/>, and <contact fullname="Ray Bellis"/>
for their feedback on handling different views as well as clarifying the
impact of outsourcing the zone-signing operation outside the HNA; and <contact fullname="Mark Andrew"/> and <contact fullname="Peter Koch"/> for clarifying the renumbering.</t>
      <t>The authors would like to thank <contact fullname="Kiran Makhijani"/> for her in-depth review that contributed to shaping the final version of this document.</t>
      <t>The authors would also like to thank our Area Director <contact fullname="Éric Vyncke"/> for his constant support and pushing the document through the IESG process and the many reviewers from various directorates including <contact fullname="Anthony Somerset"/>, <contact fullname="Geoff Huston"/>, <contact fullname="Tim Chown"/>, <contact fullname="Tim Wicinski"/>, <contact fullname="Matt Brown"/>, <contact fullname="Darrel Miller"/>, and <contact fullname="Christer Holmberg"/>.</t>
    </section>
    <section anchor="contributors" numbered="false">
      <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 earlier draft versions of this document.</t>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA7V923rjRpLmPZ8CU76w5CHpOpdLPd07Kkl2aVxSqSVV2+3p
HX8gCYqwQIADgJLpw97vW/Sz9L7YxjEzMgGyZG+vuj+XRAJ5jIyM+OM0Go0G
bd4W2UFylS9XRZZc1NVd3uRVmZc3STVPLtaTIp8m5+kya5J5VSeXWZPPsrLN
0yI5z9r7qr5tBulkUmd3B8mKnh6V+PRgVk3xl4NkVqfzdpRn7Xy0qJZZmbWj
eV2V7SgrZ/gsdDWaZUV2k7bQ8ejpq8GgadNy9n1aVCW839brbDDIVzX92rRP
Hz9+/fjpIK2z9CA5LdushiYH9zcHyVtufnB7778YHWP3g2naHiTZj6vBYJUf
DJKknk+zWdNucO4bGG2StNXU/JqXOEv9oKnqts7mjft7swz+bOt86h6eVksY
Ruu+zcsiL103sCzLdLWCSfMng3TdLqoax4Q/I/kXX4MWjsfJWX6TrovWfc6L
epyWeVZ0vqxqaPYERtM0Vek+hfFlGYzvi6evXiTXdVo2yVFaprM0uazWbeae
m+btBkghzcs2eZeua5jFMPnzkf++mkHXz6+Sx29emg/XZVvDe9yk+zxbpnkB
u08DHS95oP+eydjGsEr9U74cJ99kk6yOJnyZFvPoC5rseQUEtF525gpU8ji5
ytIVbF3ypribJZ88f/w4muplNruvqllyBH9Fs3z9/PHLZ91JfriKJ1jDwMb3
OLB/L3ks2+d2Nk4u8+kirWd2e3iCZ/gFbGnPAzTRKzgSWbFMy+Sqmrf3QP7J
N3T6ovEsp/W/4mH790ZfGE/TzvI8f/UYaOgeekkO77JyHRPB+7ZN79Nh8v48
Wpevn3yXvPjLq49sf3dP367xQHY2dRN/QXP9qqgmORBpVTZANMiL3vylM4Vv
suymgbVKC/gkTdvkWTSHEzjEiwpmF03hxctnT4++6c7g/F28lncvq1Xz7zc0
mjFyFuBDJbDBJbCquwzP7FcXH86vTo6e8fmNzrLb9G9wK+rw43fj5Gq6uM/b
FraoDL87GidvKtq76ItrPBw573mb1je4Dou2XTUHn38+q/IxrN7nTx6Pnzx5
/Prz86PD8dPHT56Pn/JuCaeHEY/epE02S2jgydu0WSRvgJnewjrDg9+9Pz85
Of9wtmNG39GMbjrz+TZPq/DDS/Ok9H9YJtl8nk9z4C7J8fkVDCL5CRh9AlS4
zGq6BJK0uKnqvF0sB/Dq5cmb0/PjA9sIvJfU2QQ2ONfWo9XIyvF9fpuvslme
0rLgX5/De9/79waj0ShJJ0g+U9hbvD6Ski+1pLovs7pJlkChi/QuS2bZXT6F
SxDuwCar+fdF1bSwjjDedpHldbKwDbQLIEn4fJPc57DCbZWkU3gJrtG6WuIX
7opK9vJxNh7yF6kfwbrFuxavYXzaNr4/DgbbJMgN8nIKu9jAxIpNAmsJHAkG
t8YPktOLu5dJOpvVMICsGSb3C+Ay8EayquG1HK/+ZXoLU2oXcO5koA3JBPUw
maxbmeHWKdTZf6/zmhrI6HBDK+UM+vW9ykQav5b4hFtMWKAJjgJmnKR3cPzS
SYGTohZZssBtHw8G1zhGuEfXeM1CY820zie0HffQJEkBKLHgvA+JfIEbJHvn
bw/3kShBhpi2PE5c4WpdgyQAX8zrlL+Dew8HQ13ixtGQV3k25Sk4BgDb3h1d
AqP7yAKEZII718ACSlMicIkkk3yHB2Oyoa/0s+7U3p4f7ps9hRmUZqawJA+d
KB9EmNgkW+B92zdgOhhjPjvLfDYrQDj7BAmhrmbQKCzLP/kkDf7JJ2kQnSTc
sHVD35pjwjsmu0Jv8AEJzgx+B6xjDcKw28/o7MCuFJlMLKngPzA5IIwhv+tI
A8lguYb9w7sfnoFJ1tkyw0M85HOynvyQTVv+4mZdpDX8y6ccqAFmUdEA+QA3
OYyJKFTGQbJ7u1nlUxgqzUZ2pcXXyvQmowHVuC4gF8thBMoBhgLLDluHDfw/
nGshMiLA7ok+hPOcweBa/v7neX4zUppF9QAucWgtu/91mGw5XVvPFjEU4ieG
nfx/OGX4Lt5K7/2wgSyDs7Z3/P50/2EnDvoaf5TPnR8m09SPAQgeOrDtp70T
Rb4FA+YOiZ1mvpdczrFw8qtNOV2Aspb/xOR0BLRbgpCKi4/fg4QGzxfu8wms
fJaVOgf3XHKco5IEFwm2ckYUV8OCnPkV5Q5B7sIZwXGep1NiTw9dWJnJthHv
NVmW/Pxzk01HDT7y66/72OcaBSHopXGvZdsoBDr4X/DjZMTE/9b/47iSPD4e
9f2MzRt9T8CV8gt/yxeb0HaS/OJWH3+XH6QA+fkFXuxt8Be3KPBQ94kxvuga
pG2UBv/NPPWnX6JNhe/pxb4GfWv0lCMA/xG8CJ9Hq/5L58Xohz4a+MeIvuWb
eLDdV+nF5QZZxjj7MSUAhPpUGholv3zamc2n9GLf578kSnRmQ+xvg57XqEGz
H+7pvwQtDLozCBvftpUPe7Vv7fHVvvHCiOMtiNc++fjh4Oe6q/+Q9/oW/wHv
4Wv/Ff5/9OkD3qM+7f8//s4eXn9OoHGcYP+BvTGj+fkg+WTbTQh3G/GBUVrk
N+UfH00z7OIR60d/fPQ2v1kkRXaHrLqeLvI2Y07pXod7xjS7jeU9+nU3U0Vd
gW+wFlGlOQk8oLY5/j+tSpjBGhWRFJ8F0WmZ1puhuxh674X4LWDaVTmD98aD
K5JdVqgnViC+1NmchSUSe0CDneHM9H3RJbGJRwsQVbNSB/BIlRqULLN6iTMp
q5avAxIS7NULLeStPrKqs2neZKBjzbJ5XuIYy809yk7c5iJFWbfcJA3szKLF
5/I5jBIbWmYpIqsqdm3kzopvUXNXTdu6iK8q2Jz1atf1LKLD1O+SyD2oueAC
pclsg8gryV/Q2CxtQSKrKxRdh6TzI8Q7TVEeA7no+h0KaV+CBCgHdUhS3Tov
ZtsoZ+hIQARKlHZFliLwhARElED3kBTSpqmmOfVnRct9lYfcw/gHItQozPFe
5uYxvP1YHodlJwlUaJuIFKgnX4JeWReboXvcybu3JYhVdFg7QuUeE8++Ug/L
gkgW91lR4L+rqmVQvGApcoGgirz9NSguV3BIcSz4+97XV1/v644cXyWXl7ij
tLFTUslY4EFcxMPi/litUiIlnhCRT41oFQJM2qOX5hoc3Lwqiuq+gad//hmJ
PS+rorrZ/PqrUDDvjvlmPEDiK4BnwJhJ2oZnV6gUlSLp3sBG16BKAM3AThBN
idCJs+zXE6h/pGnkSCMUZ6nV6g5UM9JSDaeCppVN0fbBeg+T4zNqkzbZLz0r
jP6MIfy+LpF4cdnkDADlRIdsuO3wUD8BW5Iv9mGhmxUuyh2ffpbHWWMxh3UY
ipk0Zv5kBq3++ivvWviOeUhfm2WwCG7Xgdn7uRDb6gjJdJMObE9mdYlrwGoK
TkMGCuo0+xGnRCvQ4HW1kFMwsyvQbEA9XyaENYG8StylyaaMgSBbLEeloqLU
KjJKo7GSPQcUW1lqZpTAu5HEWJ9hjgnaKaE+yJV6BtAI50fCl4lOV9kI/11V
BUKKTbjeZUP/ZKui2uCU4dtoD1tQDIlN0eFDPU9bsjQmxxFIa1XkaQlrjhtj
wQFROR2NG90c9zJvpmvSlXGu5rukWVRr4KKTjFCBIpsho81LZCRKR8B07tLp
JiQSGW1nQtxRIu+IJi4zg2sRYZBaNvseifABQoBwmXS1ysoZqfTaSwMCBh5V
RhCI45irq8Zvmwxvr5U1K/Y+Mgwv7UafQrRttKyAEWI7OB2/m7alYI/9OmU/
jmBwa3qXlgm50OCT5Nozu+TnTyxT5MneIthU1XAzPDr7cHUN4gL9m5y/p98v
T/784fTy5Bh/v3p7+O6d+2UgT1y9ff/h3bH/zb959P7s7OT8mF+GT5Pgo8Gj
s8O/PmL56NH7i+vT9+eH7x71iCSM3U0y5gPAnFuSlgYBW3pzdPGPvz95Dovx
L5dfHj198uQ1rA7/8cWTV8/hDyQC7q0qgX74T8TaBrjfaY2tADEm03QFF3eB
0kGDRHsPnAL4La7m0bppgVzq5AL4So5EfgI8ZoXDPBgcAOO9ONlnSbFGa2Mt
XAlJAfa8JNpF8jRszBwnS4nYXO6hFhI8EZdC9M4cyEm1Rm6T9yOuB8mnxCnT
epV+qiREK/Ls1QsgFBGeqHER+fTgwKIKbIULBl/CfLCLZgp8iSE2u0kw+svs
BtgYvakTOa7wtjZTmdEHdGkKZ2+sPOSugGBhksPkBo58GQJeDmNdotkMNaqt
A4DB9Zx1HBbMFrhiaaH8Hk7HQ0Uy5BuEZVNF+qZAS8CYquKO+HmkBuHog7YQ
xgrH3TO2xlBDjM6RQCZrmibzdcl3E/JG3DscA24PMaqdrI72Pi+nxRqvzVW1
Whdpu+ONYdKIaOfAPOyIL4yhvUOCvoPLjYgUFjNA6X4b8vWQxwzJRUaAeJlA
w8nyux2zJvo3Ah9oR/EWD06JkJHUig3dnBXqL6R89Cp92KR0dRgoClcs+3uC
7f0aZ5eK9BwqGnSwVIHgQ7pl89HNhcl2LeTz3+usaf1bW0+TmHHKVvatcT2K
yoob5NXWe7r0jfKKL6AawaNSfTdHUx2uC/a/AG0yw71p8iLPSrjc1fo3pN6r
OaggCcH9yHz4AkCputxMYa+TOagkMClziHau4wPWMKAIw3/1cz3deQvKxHwM
YiNNE1cKnmhz5Cwg8RUZa5Ghhu7Xb7AVOzYUvcfy7b68ttcQ0M7QsmqiBuNt
tp9nXG/3XulPqrxTg150lxJS7u2Aclh3k69IzfgXgQQTBMrhM6AINMvAKUEV
tBSdJj4kSHZdnn3JApTj3awO8mfMjND61Heb9At62t7HThpqEXdpIQS/6+kE
xa58LjNk7sJ9+INmOu7b626HvRTxsI7cuT2/2gMWvY8ebXBNcS+pXFp4LJEj
w4HFTcY7xT1v+EPVcy3uZDC8Pe59oAfpIZsps1Guu/OQMsf/rePvGbozUfyz
hv0RDv4J/C64gjgV4nE7dKZEJaZmAWJ5BEEMBt+QLTUUhGdVJkJanSGKhXqk
10WXGSrNebNkfKUgfdSJNd5UNozFa4S/8lXKp57Nz5FtcQYSCJIhcvRkL00W
a/TNmmQwXjRq5UVB0hCjJnry0gR6I5kRdDKCKzxW4g2qWU524hko6lMEECtv
UIO+7vIUnmdTMltcQdUGdsVQKfDOdrUwalswTr544Jlb4XG9Jtu9yYbGtT80
eoaz4DI94GC4NWKT06pwi+tBnz3E5rrcJ2114N4HYCgyhd8f1Gyq3UQZ4XSd
RkmwhLHL6GAE6hlACjjBVkUKUz5IlnhAfv75f4Ai8PLVy6cI4xy/PbqQj754
/uQFfvThorwYJhfu85dffPEKP2fZEv0AAjUWTds9oxKVkCRedHWD1z4gYgWU
4Y/C3lcfDveTPXJJ4M6evcLOsCH48Pk+oyigLoKC1lTcGjQDxzF5V6Gdn141
DX54Bw1yU8+fvH6G48ZHRu/y8nbErzgalMeevn7y66/8+6vnj5/LK8/tK74D
GeXrpzjKvXfv0FxO0oviGYRKtBk1Ycid1a8nr598QeDYe3UnwC0tsKOCx4ZS
SbGsGpQskMWB2jdfFzHr8re4x1aqZd62hK1cE33CusBiOCPElnGhNjXJtBvL
LPIeZ4OsvMtBuCD2MQdWtK4Jd/vLxTlTPB+WFKFY/zJ5YbBPRyqSilN9ZU3M
gND3hCeJdzs7jQgSi1deXrBoilopnGCC1JCqVW5jwWJDrxmVlv3hkrRt0+kt
7gb729FenJbaAdB4qboeCyhAn8Ia+OzN0cHXHckO0zgUfgZPoPwEVzYev6wE
BRFvA97jELzNqRl6JAu/Ah6Jyi8sCJwadt3RmwwEtnq94tN3BZpc9o+/R6+S
0tq0qXqkEFdiPsxMkQF12LwbPpzs8T7P0byFc40gZuYxq7pqmcfsyX0Bi75J
igyPNXWBSM0NY4z8LLy9L/YVtnIg10NnG7Y2+RblApDhuKmOxLtvmtUtST5w
XY3/8fd//H1AINdJyaBbFoBmzRQWtM6rhm7YADlDbuU5Y+87xGVIcs1c63J5
KiCc5ihwtAMP86TJBHSZuUDmsjfX4naFG8h7grd4kS9zRaP5eMZQc+uvdznP
tFlqAJhmgRPKHQ573ZjJNEj7sGICcKyiiAe9aEcOi0HIljfE2CWBLp1T3VYt
WXX496fQnIECFGPveydvWIbwA0MbXAZMLpMvvDPfOEnwhE5AFuBlHArnjA2g
fGhJS2TEiqiNUKvIZDSODNGDICKEid+2DepQKtiPThVmEEFCoEuClswAJXu5
kcmsYcQBt1nMEvh5Aay6yIInCOJMp6EdLCvRuRWUIhrnd1ldRUPDc0mgJo5g
usgzNMivyU6G+mcyzWuYM5omVACCC+x0dDwOQlUkQMVa0UezxXRUERk31siC
20eSmLozcGeESDTNerliXRFvoKsL/5qs2zjxFg3gbbOqJiOQOn2pxIcEjeon
WZzp3aOLE+EW2N6MDNSeUN16YRdqgLsp4RbNqa+gE/Es0++pabkFTZPiKbdd
HB7jHT4FGgVSVD5NBxmJdNhDRbhVBRkTbozMzgI6anFlG2y5yFqwteT1QCwG
TpbRyFGM6LpcrmJa7juAziAMXB4uRkGUJnkhGPW0qMj6L+Yr2Ig0Gh16qQba
RUfbYqdQdtZmkjEk7uVrXHoH6HSea4T7f5NN4C4+JQFTVOBkWU1I8V+tCr32
kFkMvlFqwJ3dQiXedE9IsHNuZN9CtvqnSZvBwFBoEvGrD012bh6lX/rtAv37
cgcrRbYIPbd+cERrjQF1BIi0U9GFj029U/WTGHzyCS3FX+jAyY1oTiDeiG5R
+TPuwH1IDJDtaazg1YQR1mmNG+L+3AxwMxu6AKhHvV0sm5cWjEEARBhil4GR
gN+agPyyofuQNc85XLHlrBDfGuyNZDzWNonhqXsM0CiG78lN3wcOicrC9w3o
/TM6T5nnyCoQMPzm5B1aHzejxu2VTEzl7NtsI35CyGx8/0aOYW8XFe2Xa/Kx
RjnJOKfQWTkHGckNoaG2vTQR3UOuTbHnCnRPcm7TZuksbgOmjked3lP/YJiO
Disci7sDz3BUwIjUGYSa88pIiZEEDUKc7NftgmGI21XTzF+n8WQH3yyyHsyJ
tYhVsb5xphokMVgTfGyouCWPUqUjdc89PotvbPWZH1XzEbw6mlQ/8kk5tPcC
n5XgKsHTYmlb3aU8n0GyJG11LfodyrgVqOcDdabqWDpRyeX7OrgyYL9WjYNZ
kGmTfveEYGZZkT6f8Mka9zY4T4IJuINLJ2iAdk48e4wrsYPKlGLFmKukrX9j
MHg6llXWw+9mOsmMwZNuJGOnCQ0xA6Grjk2vFJpQjMuzn2BI0MDWtmFtPktO
vZuUsaNe+onn7L82IfcWOB10aKuK/NI5YmCRr7zM6NdQTkciYpNGiZwGFz9L
0Z7UZCiBJORPxyqtoeVWohTcukRU33qxL9MDOhZmJT5ZIQoovTH1+S7u9XhG
j8iNTvzrP67enycVe7U4E8GGpBeQpXHEQJUetsKjMHLYXOQvZB0bxoM363bI
kgTILzrlyEpnWS0eXjR1Ii/GeBjjsSfmFiOR92w9nsye7W+VvfRsug0Msdoz
CyF0QlnW0iMNKv/R2YkCaC9evABRM2cpWR/pIiMos+vZxfCTH3PGlgMjOe8Q
7U9emyHusVuRj0QTazjOMi3g7MzwCm7Xq3/ZRxmrZmMUjxrU7sbt1Wrdtqy4
4noxAoIUe/3tNRpHq3pGkN89SF4NaAUkKKFqSQZfoLXlSvQ2klDzFl0Rivw2
S76qqpsi+7RJruC1JRl12PAJTFT+1LVpUFr3+sisbKrViJcBpJOa70kMmAet
ZEGwXxMqDMk8u+dpmZNLzrXkB8duoLysAmGoljROCD84tJ7Dx153T5T3Oz++
wSBwCbNOfdbjmK402yhepLEHUsfwSOQlyKmL+MIDYCn8ECeMAg+aI8ppJpiE
aA+NPs9OVo70gerx9u0JJOuTiqz5RICCrpuUiE7wPrBPeJvje2rmI+4Kw3P7
k0AEa7b9Go6qmsNUvFgzio/b7oqRB3bUPuE6cZxY79Vh8ih0vn/kfIxlMKrF
4ibhUSxnNAckppkjnMBTu9+meIbQhTXODWNj1A7jU7JH5zQc6j5vmNssEefU
9tUQasPudHoxidNotWI3BCEdCbPiryfQ6Rwjo0QeAEVv3YmXvBcTlGPBsxwG
K/I7mekDrZhcm5mt4PlHWbJUpt2sV5ScAGHaokpnclsyIhZwebxJhuFB8XAL
rL0L12IMF1pmx9A++QfeTI6PqysarKyn1de1WcvuWbHGXWevcZJs00klxhrh
fthduE8sixnUj7QPVmiaSCXzd7RIJqt1jXvFkwi9qrzMH96j5JjWbBUheuSE
Acu1lie9V4ZlmJyLP+QQsK2xXBp24/CznY+Nxj40J4rt0piTzm9xUBl9C81s
62hs48R+2T6gMTdjOvJxX4kEvmh4wi/BgEzEmUTHcDN7oT/HPn39b0Gnf7LP
uSCP/aCZvh8aABz6DxfHGpPT6xHgmumPq/slWuJd3VEz3SiphD+Nm9kSdueb
oR8fMdVZGV2eDkek4CptJo6e0tG4+DUNWep50DXTG5LGr+nZ5Ga2xK5RM/1x
YhQp9osLbusscbhsUZzaf3U24fDbLy/7dmpnM9Gm7tjwu7iZnWfKPrslsNMt
cb8vR4dufom8J+Sx+DCwN0X/PLiZPXOW1A3HN/OvPeTQ20zfg7YZ50Ybrm+3
mR/Hm/FP43z10j1tm+l+29tM3482s4v8HtqMiZPUXywJhu1siYsM6e+Xzqtd
+guo3LzwW5qBwfxih6F/fBo0c/exZqLvzHngZrYch+g0bL3x5Iahh737mngr
dXYcf3dX3aUT7PzabNnyaMe3EUa0Nn0/vbdv33NbgmR9Rw9sZufX/mdnb6NP
w9BRY736WMRo5FltRCKMAv3556g5VOaLYk0ovEqfVozy9ilyW1Kbpcp2E7VL
qJC6237qpXRC/FgpysjAzroEOaHtamta0bxIttd8ILFwPPb4qrZIVl96c0vE
zzBWDbvmz0gV6RA/gUMYiMTY0Hxdt+zbhZ+hObio7tkXgwRhF4N5vd1W4jwW
XK/bXZcJU8FkLqHsLukn8vQGZGiGMlm8Tp1jJTnSLNOVGAo4iYvowY/G5NHx
yNq9H43dlfFIQwcw2KoVQ4ZxSulqk+LyQsZi71VHTm/h7BFd6xArERC7voia
OGOXE1RHETYirNolKbGuMuqZQkoO7gNRhYna8bqa2uoaFwAAo2GkMFDqKJYI
AYKtfsiMOnArsqL4IpNSQ+ZOdid3nhK32QY3Ae3sZN4RHGwWxCM0dKJqiWwx
VjlKk6LYewej0ejumh0T2IrjtG72AIj735YKBM0ju219zjk6svh5txt1WLQO
3bHpj3FJF3L+uZOJEAJkdC/KOrOFanj05EBBHpZtlhZoAWQxTAKI2Enw9WuM
NPMYwfEZpVm5y+TdWNXRKIk4AMOHh+wwVAt3jENm+r2wMUkMOzqQ3iwwcNSv
cNkz2oF2UWcdVyeJQD1ARBme6wSuh0HrfTq3pwN0eQjDbR6muHc31Nm2DK8h
QNr66Dv/CIMI0VqESAcNJbD2bc8ZNJZl2JpzJso387A8M9bdlwPzlJYcfacr
mM0KNYSMgmscCNdZG41o6iRqIGBWDKuI5gQx/xzw/1ki2OUSEby+kOhGp8jx
xvu8oD5kYusUHeAKs3pA8EQQy79jyXz0keD7S0zBQHnl9JQcn30qQTXuI/WP
BH5K3Ok6Sv7QrJccQo2p9WjIcvbxqFKCLbzDNi5PnmOvmI4PXZYWm4TcOzUh
Q0BxJmBHZtH4YBtBjv3HmMEymcBd4i4iaKCq25Ttx6VDxjpAZZRUo+xNxzA0
iS6sFAM0c5/VVtYy2dc+Y3HuswdGE/TgwUTTPhdaD/aOk/CRtLSjSK6VMxln
CY1tSkG7/XLgT+SSsi4L9E+F7nJ8Py1M6Lf3XPCsiK1NrTq3k/0fZ579iJNF
v2QGXb1nZJveZqVc2sJoSXyKuXxWNutaqfpYR++vP87L4TOmBYkfLrfEY0w2
UagKR14Ywbb/vW0y8VCNJWG0ibbdRIMXEhavdjK8Cb8nMfOBkUjJXgz4h45D
28JLQESuNH2eGnFdwFwWcZpYalRP4m8Oz8PAZO9RPAwE+O6ikFyHhjSB+GV5
O9ajME5uy2wCzxbNUGjfc7E+Wbngu13D/ptc5Ss22fTYjNjoCkyqqErESmHU
BeeADX3MnOdyzUfFZ/Uj86x8jhstC84GTf6+KkerFN6vJsxeSMDwsZHb/HQ6
R7vXt6ysavUvpZyLfK5iSx6ZBsnmwNZiKxKEWURg02s+ouSqIfY7T9oYaeGc
OUIRQc1J2wgDbpxsfDMeilD69twFkLx69cUXHNORYoPKpFl0pXTnsI7TBfqm
dY3BnN7iDhT6GbpdjmxyDxReyXcsdJvhoHV30o0PcGBiuXIEFHgJ76RYbJvc
t719rcNIor23+846fWxVxb2x+t42OR3NOFvjREFOtVKsE17E3Q++bGITtirf
IqOo4DtM1LcJv+iklMEPP5YysU+O2pIHSl/Z2qRIxC4VjBhwt6peCqSQU8LG
QhpsSfT3U2ArbzrRF+o9BNLSUfjNdrXPcUcf18BiWJ8Iqq7KqErYbCc+kwoM
nORSUOHUa9HlALI3OjtT8L5N1cnH59Kasm/U9SLUFrIfcctvdi3mGbZCmj4w
LJAVbjIbssH3MEvZ6Le4d1xd70uo06svXnzByiWL5kY0Y+CGLax0iNI29hzC
Fl4/eUzxW1dCrq/Hz+B/KhLCccOIlkrUR2iCQgQkf5Im5SIefYNKHrJC2uGq
jNhFmG4sttmqPGv5qPMQloBCvA+g0QVvTK9AeMh+GhinwUBQJulxNdHXRyU7
lhkILjBseV8DeVYVnBBiqa0S+6fNTlniUxPEOB58YJHRmuQjGz5+pc4kaMv3
oIURWiWjCiEBv2lq7L6hEutQ0+BkfFHJ7R5unE+INlRqJRnUqR6S9C0SLGFZ
zq+GeOlFWdko8vQQfpKbYp3pmMcghkoOAzmuC3RPQr9RvLrgvM5VfRSGqum7
nfwvFzHpWAQryGiJdhom3B5eS+PbxheJnkVb8/s41I/E62LmICL5nFRj+tK7
sH2WvNlobJvfVDr4PV3QdDtD7huq80B/W91ndxpYRtggiBko7M3I8w20jiDX
smpWv/WqGCWd/LdRzrERsr9tO9Z/bXFmQREBjUuKdXuJY7ZM3kQ6qTEtUJB4
PDu5qBFWGihGFT+j3ktGLDP3HgUSCk8PGH0UwNR7imwaPkn/LIhVlARiZ0pE
xUpWk8JFF+GZo+xXWxvS1GN4sGg8JBPu9R83zpAVtUXZBXeQxl6HBjCjzFWM
n5GTWV3nGkRtFlbWexjeVKT0gYagMpUHU5n3+LASn+VuEaZfLE0GD03IJCGn
ikg7D9QdF5TvmVRx8onMS2CmPrWPoQ0+wBysSoEzA6tCCAwvyUzhrGDSjiKb
3TghGR3qZyJh7WGw/rcvHr+2sQ37w3iiFPqOjEdiMtQrED92rrKVd7vlnKhr
yjnTNG5tkclPxfu1Myw3JhPkuNcZWqwT7cgf9WXIKJjUMgluJGoJnEqHyQpj
YTNhRIsyHdl4LBLiUYo/Dan3zc4jJZyhc6S8xYRO0nYzy4QqodCF4SKaVMSv
M8zxbhDjM0Ps48QkcBypAAj8E21alD7LLYRGtvEoyIvFebtFoAWfe3RC/EmM
lrBoCPL25VNlh9A9Jh7Sfzf92VN7JR1KdmSS02huHhWNJfdVFmNregMxDnVY
FMo31QfQHVaV9zlqwXLmIXw8TRXY1JNtonLIjBjIPNH0JV8rB99VlDfC+d2f
nR+enehIrt4fmvx2ynHw5SZ4u+V0dtdGVSGBSWEkyQLgjG6Y/NQbKdRxnH3J
53lWsEAHvSd7VyeXp4fvhskljgv+Ofny8uTqLf5yffnXYXLy7cXp5QmN8ez0
/PTsAybFX8RiQY6Aa0ZCJ+oUtWjwDYY4g0TWCCWvQYPzFkubiQKPq1qBhlo/
gPHxe0GPhQUGzeZzhIRRT7wVJSoNElhydCbyVbRJ4GGngKpDl2jMXiAeVXU5
pBg90bgnvbGj9/pgw+Mz8fHuU9s49VhJsMjG2E9bikUMs+J8YEnY7ayRZIZ8
VTmMVu8qWD0Wk4cJSxkkGatQLImusMgQ2yrZFwJP9fZE2t7DwWW08WUi8saf
QDYzkASatxZkDMw7zbiPmX5MrBA5K5Qq/OrRqbDBMUGa46uvKTVNu/BZjcXg
7NUuuhR8CzAvIjNd8gDiPlSV1CQi0IQBQTCMCWcywZfz3feXFVKHtDcukhMD
JYzTP8dvaoNmiJKZQvehX6MS6J0YhLNTUlhLY2JZXXCgKpbqf2KkLNO+yxrd
ZxpwiTbkBXQZIRGbQIXAsMFCUKHGyJAa6NhU6xsv9riYNrwXTH4iMzLhGioK
XTmS6GBledeNgqUe5qEmClyZ65GopUdAvF+f/FXBlGfPn4vawgocr4XKmDMG
UzGhK3RfEPNUkQ5FXJsYgkLtKGaRCTT1RmINNNT9CTejuw0f4U2a2RUGAvol
4ter1liCLi+d1o5nAKkTwZrZHUpqjeu279R0wt41WQ205TgL2apox9NVOpXA
9o80L9PCbXOMjeY4oVh4L4Tr0lR+Nr3M6ON57IUfec3EsyIpe2acKjRvYGjW
9PlvhqFfBjdAQVlBgYFDdnBqAn3fCR2W+Rn5XTELPsYk19iUPhxqcOrlbpCY
JY0OSpqtN/npzSoIGFbqYa6rslKs9UakaJWpMrsP6r4FHWl80keq5ijZ415Z
INS1vcdZ3u+e7wfKTKzIKQmOBzGcYp6K1XcNZe4q+sZRzMvm2q86lUUYkw4C
OrR9NCwY+gN5vbBIkEKce6zyk/+TV9T29d5p2LjJR6/MPgLDn22DccSOkYHM
7zLFOuyBdyoIi8kccKpKNmpvnLKtF+3Ija6Be5qa9sfhPa/By8rx8EGKPY6L
EphoZPLtYrUIucWI34mVoi1iV7V1u3E1oeEPKNuagleC0Mz6l8txUHa2a6vV
x7xIXATfVDJV+EljpyklWWel0hEd2tDT2uk9VPu3xquWoXWOYBc6UGiM2QFs
9JmaDU50r2yUpQe9vHo5GJyp1wqhGLTZ5jRUPoG/xnna7Xf2j655o4dK+7Fa
rRmR2rBqjoYfkVQq4mXkbsSDsFZtZseRpO+sq3yfYDs6VpGX/NBj5aJrSBYR
CSPsXDbUIdEPJ3uIbmgTAIkbCSuxy54l9pt7qrCxLl2fUnHPGt0l8Tnu0lDZ
BDUmQckLtpzQtUwePkR6Wv8hFR2bFqOE77GEzOdApvwbxg2iEsZYdslBv5w4
jduSV0M+MCQe5BVCjG0fIjazFMvQbCbww48oH1D5v0ogESohB302rQTkXfef
254dScnfYEQ1dxx2dTinOGhkZooNY3bgGlFrrtjC0gTyPZfD4/rogpJ09fYc
9coJ/kl/HJGZvaicuNLh9ePe6Yj1H4gcOBZV/eHITRwoy8OyDuKokZLVT6YI
T01vs7ZxjqLPX3rb3fPxy/ETjo030rCm7wxTjCib0UEJwuJQLJsJLjRGyAVJ
MokPez3zMr3klmDtm9SCCAzXO8vw/5/EdSZWjGberynIuSQlhoj7fQK6WVvn
2Z3kqnC0uSsa+OdPsH1F6n7t2m07Xp4WsxNQr+ZUYEYKUKWesDl3cUpeysfP
niM4yd+JxseaIZnLM/FQbVPhNO2GHSZIQyPzSeV6FeFJVbDfYj4wFiK60DDd
VNqJfsC+aaR9kMmuYgDXCsTtQD/7TCxNgJxaBBNzWZsqRdy4PklzcKsm2qxO
gDA79T11lQyCR8Sx7CdM+6Y4dPiEt1juiQaE71CdZEmjoHUf2G173DNKEn/F
2JNc40mHvXyHUsDe9fW7fdV2yZkPDxbqbXpBGONvy4VZJcl7s76By6ylbDg/
5sv1Uprx+VyRhRTVPWV7cx1Y5JEdS9GiSSa2pZqCO8BcQ26814yDwvCs7uaP
hVPclb8ECGqvpMSNRkArdqAs6SP0xu9zP0HX1Mzx4fWhitb8ba/3tgni/yx5
TxovvyrLtvdwxJUoo68Tv2FiC7pmSuLTTSaxjV2mftcob44nMsuDtFu0CA9c
NwuKG5ulreuTTjA3Cofna1ZWoNbYJWFAVDmVBM8Ee8AlhffW9Tu40OobTiIe
MHcEPQ3OrA6InzbJzRrV4gIlw4MeV7WywVo/7KgGg3TG59/s0oarL0sPa3rN
B90hsLSICm7AItPKAn8lVFp4wLESLTEYxxkct/7AM7MVMJTTRyxYRpmJbKvm
uhXewR4DI2Ym7MrzJO3ulNPc1DWe8Ol0XTcxn0fFReBxkvCQaPGLorpxr44H
RP33uR3jxyxfPhCm3X4UsfShsAx3LOiL+KzQpaMLFamSLAdyYrOFxQgfejzt
iJwk+FtGAHJuJm46shWhs2e0MSjT4BW2NfG4b/imrFwOIUdDdldFd+u/UqPN
dmYQBqG4zHeYLGU8OLHNNnrHoP9udXMjwrHGEKZwW2yanAlNSFm9kB0aCJcI
9spjsVlGvG5OLk8gIxsTjRs0JcTcimZ8kly47Gd9Ut4uQ8SM3DJD1M0WTIzg
6/6m3FjhYjVCk6BmLAI8e/wYc5bLmqrHi3/K7GFYyeYtqG+o2LEoD5c/ny3z
9wVoDMTEKFGU/wIGIgiIy5uMYyujwAQPzNiGVQTk2X1HR7cLBn/cBuKTHPtw
3WNv6vVmCT4/mBnq0GYyY3Xm6ZNnL9EZ8bvrv3IqWtke4h8wqe+O3h1eXZkv
WhG04N6YFmkjtq/elXL3Iohk7YYfjNaNYpscWbC/OpxdWhTT4W5LED5hrmQW
IzyPcOJSwCCPr3hAh37LjtM23TZ2a05Z9U+WlUxmKhGbcLYytATnP7JuKw6O
zr9SATmpt2houP9mMzQuWoSDzRCZaMIjJ5peuP5Ok5wuMswfz9TYs3SBmeLa
YHPCQ9sODUhtkL61bSgJv/iF++ZQePZwOEoyvGaSQDu05u4yojHWyKyxadDy
z+265ZGzIYBImpy/P7m8fO8vIObhbL1ZSnbPfguhKe2qNxoS1qFeINbcEppx
AiNUqHk4i0WKGfeneJ7RWXGD95wa2OAatUUSItXOFZf1t1B4oSl1u1vNaBRU
WzISbCi/FYKl+ZRaTJMv31+enaBSYq5GflNFKlkBQdicUU287+jZdenAnsvL
q0zynAMXRR5d8zMiMaYUEdg05KIAcvDJ5V++PDx953uJR+GcG90TiKmtS2Ij
2MT5++vv3p+fbGtBNoiYoGHfPvBFD+6QKOj68MP1221teR0cXwytXHqZ2k5w
eCBZfbg6Of5Ik2S9y9S+ZfPPRnnkhb6EU6AsMFWXzY/e87tNfPlqtCjTXxWA
Z6Vlh2noY62K7tg1QXVEFCNepCaCwLoNb5EgPlzAJXFihAZXXVqXT2JjG7wc
g0YIUN/EQ1R35K7g0SMBEEHjPfe7b//fd2EjtjIehHwaz8Xu6zkGb3bfm0EF
Sq/tRbCOxkbA9eG4Y+Ar3QeBuQre3v9o33E6itYNrbxN1CY7oN5mGRmul8B9
TNII0v9cuvqlgM+ab2K8JXNEl0gVqoQGqyUGeKO+IyMTf6uWnXA58QYmkpfi
v+jewAoEenFiIs/fe+uHS4kaE9/vXuL8HXd8SrWiiVj65T0vTWhMjBhYXbC/
28rOAJm5NX2XMSkLM82PK3I8FwXysWec3sG7AoQH2h5mdxk23mVSxPctd3bu
KsnaIOygN+ShbPYW8yamve23bQrXtDZWUpT0VWO6jF5U8kI+1oSM7JhfCJWg
B/CcHQyGaIWYjOEu9CFzGPg0YCvb1YDfzmI8oezQBEQDOKdU+4cR1mG1G2et
eTp+MX7qVpXSPXtrtHDMCFpBMRS6fszrcYQaD/59eP5X/uTy+N3J+Vdw8+ND
bolYBelRf7ZxTb9Ev/HMm4OtpgQ+TstKA7xjLwHiFA86bRH9OQcUXr3Z+J92
yKJO8LSFHaHF/YoCA2VJtkeZ+IhDOAXvrpyh4PlLjLHQPQmDCKlJMiZq6LQ1
HRv/FLEiD8zHDkuZZFvjIRWScOZwhqxdAL83mLuYwzDaMCgrMjGWOS9aYV2V
eUp5f2rKcC2GPPKUw1DykYRNkLVxUqX1zJj1hjanrBZ4SCZ1dd9gc1ooGX2+
KuJ9nNNZ48bdG+x9hY++R4EYTlt1y9efDb+26L8UyZBx0AS5EbL+Y172Rso7
pXoyXZpfl/7cO5CzTaQmZR0rU7ftKjm8OPVxtuNkT2M3kc6gEwqT3jcFGqR+
Ssl+XloZ4tPG+WVM1RESd0r9rJCkvCKnWQjI04Yf2EkdZ/xYkA1exoIdm+oa
BsRfpMQjWDHDkpcswfOe91lvE1veQZGG/CcT0OXjyFmuwp1wwk1vkzlfhlqz
3e1RFPraGzSiZE1zd5j8tvUOlwGEpopRdTwszhixbtNRPZ++fPL0xSTHoA44
VqPTY+aU6tnB9Vk0afN8jadmKMp14DLT+GosM0nwLiVQg9hhon5+3fskFOmG
0gekywoJGL9thv6UH/MxJ6eCx6+fSylK9/Xb6+uLBkOP3+4714MvnnO+AffQ
nz+cHsm3r5++eCyBOA/wyVz4YLwdephz2AhTSX3EOS4s60PQUG/F7iBHxu+J
n+ekC/4K9yqgxvxzCavWYXfM6je0qUFuHhsyfLWmTON90+PLLIg8jULBiswo
NjjCb78dD/6KP6ye4Y+gkVzdDkkFhZc7TmyXa0Swjczf7qYTbwW6xkp+NMyC
nrPjfeT6mPB49vA2XoGygzUixZGEvPaLjZ8CCbtYvxxVmhsOwMVsWPcIUXYu
gsCns+U+v3jxbCiQCl9z1XV/ia+PgAKxH6s4Au+YLS/2npZf83P92CQCLwk/
DXY99y7GEXExJa3SnCIYAhVHrm23y7+X4iUA0sUXK52T3IjB62pmtNneA+TU
Vxav3DJKtF/DzsX8SMDqYyrbe8t+2xeaH9wckb0rp+6xBX3fJ0vQbJre4Zxi
i4vI39Dkk6cFIyvft19efn4K/8FC6s5rM5fRinTsriReZ/HptfWE6Ok9/C10
PXcgzz6pVx7MAS5FcE8VqLJw1/kCOaDsrL2GpsenRac1/pCvXK4QH/ovu5uu
E2JBORgqGgImg5jnIjQ2FKl3l/X6IA9FnqVjmO7OEHfBEZ0u69jQT1f74tLc
OeW0YEcD2ixnWnT+kCq9YMAgXrMBsQkKjcUcveSCCqXk5iG/W3R3ScIRzCq8
iumwkDwBsqem9vTxh+wjpn9tidQnpQY6mUnSvRklOMIh/HmdcTQNe/WTD5hE
n8Bw2O4qpWbwK5XeWwvqmoZdBJefvbbW649rJDB+xTkgKtb1uUFP/LHQqsuv
UbuFvViov4fkdSqRiXmRrAtKitludy/oHct11/kWQLd8oISMbh2tfpPeVfms
SbAqhVQhHnMAIUyWrfprEKIqziWCfp+6Jw+kVImlMF7n0PAPaBwmvzFyc1VB
OhApbB5AV9SmrLx9TTxtTcbDVHJh8aIo03NebFJvPYozyeedJ7hKM3TjXEwo
v66eipB5Dlla9+UfTfCUs+/wdZzNJAlsVEKupFozBReKVbnEQu1hjyDh0MNI
gaY354jaTXFFxaqrauYn1YirAueLpvzLHR39AVJooKzveIVsHLuIJCjSRfiP
y7TjEkqSooJCt0gKnZKFgd9pT10up6o5X3nO62ja4ZwH92mYGMgqp1SSx3gG
9wMa7FBo5RrbS3DkNVWPeQC1AJtsCOSP20zSWnqfLNQkkAcj+52JtlOxH6xj
Ihh7tyaT4bxIb3jXw2BVVXmDvJuzaiWlR6kcC+dqJTjSkbTmOB4nAxGc0fcr
bwVjCIYPf99kajPV0pKmw08bn6QETWJSTJpRBxNioQ0oxD6gyGrC+d5d9axj
lDVmx47nEtbbTzgeRNgRPaS6sHqRciIG05NctmI+/Cm00QWbQppka9rzCS7j
wrHoOU12cjeidzl53mjgJN6M6IGfaTBiKKtJUDBaHm2+2p4w9qRaOaFBi6Rn
sGfrOtMbmPuRMyQChfGdRTbHERrjCK1xte0rvNzDEYbrhTqjWVPknZGBryUc
ZrVCRgOLc/SOQyYmFCdiYB2XTBX3HG9BWwkqtwWTHUToRSFGIyjFSBp5ie17
pVgUiD2TDwIlDkEt8gIvYRQqWgefUAoeeKY35Y94ZuUuMHzbgw9T/Q0uuju3
J3YV5CVnJz7bblAydsuwXBX0j6RAdCCcSG5L5mhSjVCXGVq7S/MCYwI0w2ON
dxLLwSi6oFPj1TX8/YZKRNLSkg+uZqi7qDBYMWtM7WHKaCIfm5BX0qGDUFdR
VTKJYUxd+kV10fBYMZIfsjifojedulyfBGmKbOl4a4ZG/KlTtHxKPR3wiIiW
qjZK9816IjaYIFGwmkHRHME3pHcvCaUKrW1jDFWMx7jofvYc6clc7DY+EGtm
lFvgAFE6mWfyJifV7GBw0CPW6AAYRy2WIHHRUU9znGGBZiMXqIh5Yl2zQ/ag
Cxw3d2fL5ASsYZPO3yQs7+f3aPBOdtjtrM4jigvtnxZbr20O8iCdBlUFddZQ
CZprOJSMa5s37lbgnM+JT7NK5KNYL8HuSo0CGMHIXP1oT5h7Tinfd95rWDrZ
vNUx9GI4pqbNTr2nHQfnCE9jAIdJ9YDUDqZsIlUxW+PMgEZJxeHUJrWXKfru
AeJD8BzumndDQiVQmyGXNZ2RfkqnPsIvL6WGhoQ14ZmXshpw5Hc9y4HrTexr
stVVmQycimpOfeaM06sL/iUov0tB3UH247zR0oWE7nXQkNCRmt7X+iC0drRh
M7iUycriZFWd08e5fr8TkhpY1TN8R9bVGCRDcYMCHAoC1ICbVEsS6QRbfHtE
dU0Ul3eUYQN9aZ4XICbmP5Lh/MaFn0mA23X/nvRls0kf4JsaFV9Gzxd+wJW7
TW1N+htZbBTuNFmbnuE4xRfFCmRijQlr0ZNWGYUgTjFIk+oqN2J441Lcckty
yh3Nsk6c5f0pWWRNieBllpZdObcNzHkeEUPgk1wIYwOjSm9IygEVx4sYTphL
IveLWAKyhtqh6HSrxaYhGKvIy1u2zPQVeOkP2bSGV2ezxUXGMB3j8x1gpv5d
TCPD2Styn6cE8VbF23eFTQ5jjLEbIQtE1GZxU3pG44TMuuZAlF0/uxr/WtHJ
6C/+6lPNxol81iug2ixddjeUjhs36gy/Mig5QqeH318cOyPXEyw2zboCJxmm
bNCeHrUYsT+Jlmcp0EbqJKgYBcoNZJUSpoMwInMNTdVL0kkRyrdxCspuEXAf
/qTZ60xaa5V0R7PFdMRzoRCooExspWEdfvRD36GhYtE8qQiXvqU5ciYbXuAe
Ja4ZP6w73DFOqgbHk5ICUXI1f2977VEcNdRqbeMkUYQiR22xUcCNcENx29tB
HZkCG/NLS4kmu3UQ2Mq8TtT48eDkR0q+w7ohT2ZbnmNXTURcB7ytkKOedWLW
E1qCTxHhooIkCvORaDVk+CQO2uRHc7pObnAu+4IyONYnajSuOuWi1GrTTx8/
fnIwm3xxMH/8eHZw8PnL5zoWlFadIJnsYXpquudoCBcXF59fHu6bAvAmK9Vv
24SIR0cDeormr9LLHgs6E7ps7uE0SzMY/YuXdiVRz+Uxjy6OZai/a5hMJo48
UoyAmpSUrUwyTYUDecLj/oZF5dxnCouYgIdF+skosIDFZaL9TblaZaUV8NJm
Z0i8ZykZPJ6jlB+V+g5A7bhGdaPSnlwFG0+isEtYuAADmwOGHGRS7OEI/Z63
fpv1cmB3WE4oxhKmT+kWODqRNqYpy4MLlPKRqMueSYOfqtbJqbX8HQ4T2VqB
JhRboynI5fNEBsO3r9NngnE11kAnlv4yTBeFKdkzzIQhXvfU9lNfsQGltxw5
gYv1gL8bFLB+IDgFBHn0vctyEqd4T8UZZ0IxHggjwclIiatEmSCZkk/p8Nt5
i0TZrPS62+lNnf7j73xs3KlhfoOCRsXydSJ5YcyyigiEI6qr0jWGNqF0khes
cDRr1JneSiKb4H1o/QZov+YNp2IW5DC0pY6FyAMvHmOCDUfAGKyMWU9cupzK
bU3fQBANk9BCshRhtkyn21tISrAxjmH2ieWofCZZQp69REsIrLF6kz4bvxo/
8wC6y4HK9MRNMJm7RB694IcPzeCIbOfSLhViCO362HJFeVLDjqzy0zg0wePi
EoLsGvNp+3jusAW4Bz6rDfpl5eUa3VfEruhCNrniSROWMDSJouaMd3L1wWDC
DiU1uWS3cs4IeLRaNjp/s1encStFZiXJjHmVNLOeCyRrJP6bbGn9gWXdZsVz
IijhpNxDwcz3pz6vGqwNOpqgPw15CayIcCrVQyTLMw5WQGvmm5omlLbFWZSv
NyvLAu1U1NCBTqEi5IpLpEmzmXsAjABZngvyEcTM9HhvSeZoEzhaNJ63unIQ
gy2ixXqJdu9y0niH81IMA1g+J7/DNDZwQ7cGIJTUEVHwMNzp2R2ebBP/2rd/
mK2ZCB3l4WZotVrXoiZHY+ODUrFCyiabpNPYRczJgSum7Iu2rr2rj16Vk2xT
KfyxheFp3Ttms2wVVrWviYry4h6Xmt4trdk3i9WcmEaN50vj6tzZJAVUlVcP
Gz3GXoSXRrhVlMt9AozxWGsdWSlYeuuWIcMOzT2ql4nkA4vOc1ROVRxshajj
5D+YNitI4hv5lRJhmQyZzhbH1pfz99enX/51Swq70DtX5RhxmuFciiq8MoTm
SNVbiph48jZsQzO8IrLvsGP4KJ2IsrZFFEb/A+o3tHJR24S0hFkk49TfyHS1
mHPamoVsFhJGyDFR7hbCw2k2ViMW3IUcW5CBv4hrOZ2/Hkikb49HNs9tCEsQ
OVpadHEIZKVutDBFqJ0Dc3r+5PVTyVZCuRR+sl++evzksXzJy0LJALrgyhyU
ehAb/KouNSAZX+Fp5i6Fo9O40eA+4gdHE3jyNjgkzTQr0f1z6LZJxEjkfUqo
M/1WLAmBSwFLniutIkVkECSW8Y2O/UEF3pxXlP4AU59x+9C6PIjqgVT/wben
FdnMhjpf4u7FzAzVp7gfcMAJcLtzojmlMaU+iQp0Xn9+xj4FhgvGs9leK4rT
FuhDW3ME7ocTJNPA72d1el+ObeLWtBQneaV9vxronlSkK8LL0Vd7D74CZa4R
G1RYkEESAuIyCdxc5PMMF7TZpxy7aEX2+b+jUaqdBAMqUIMpEW/hhFGUjq5F
hepOnNOJcpSMkKR6qQjj6V2G03mBeb17H1OE7fWrLzSq1eznBM8xViEr101G
N4vZ95BE2ZMR/VgcrZJTlGQKtcdMO6PbrDO2RjiWLPOKlmG6mRYhgCoGOlJq
0a4jeZ5ZWENnFrI23bNBRNbZY1YOYIEeWMxCJJ3BDI4WoSJbVUsuhhzxaHz6
Hpa9F/0dHhIzbX0kOGiVL3FOckRWK3gYpdkNjSlIOcmxUVgNJCXdh2jVZgau
5nNM40S4kAi4eyxN7/N1gU8qbcNukYBuEv4xBeqVgM/ijlDClHl8q9ICp2xO
g63ighaMyDg7tDnSKHfAUBmGww3cZJLLuqdGEhpDnbcdLZjLfqrFJ+TuohGT
dfKebM9C1qzOGG887RFk/5xEwSBat+EYMGlTCF0j0URE8QKqTRW98Gl8gVb4
YLjZuKgo2k40tl9fY9rww8I4jePRIt2tmPX6jDdtVWe7q2n2pGPHuThtELqg
gwIaEFFb0I3dJrpo7fW9w5jp765dFs+FQ3O0Jgln7q8qMu0oCOPjpnAZdppQ
RRiU0EAVBnucvAPzm35lGJ44bqGry9qLHVcXWLB2mllKoHgpLbZq2UmrBp5r
AXTFlh3SEwJiU1h7Xg09dk6KGHGLXmJSSwknhLWStBwGoQzn5cFxMMidChu3
yrm6OIklOygJCTBEYkvjAkWEhuNdaTlhOq48TJC8RuS2nNx5WN1a185IhwNn
26Hsg9EGqD0pDu36cxUpMCDYK4eEqDlaTssNOgJ700pX8vLSlridGeRvKekd
rQQF19+yIEvwO6A+l9kPl7TH/OtCl/tPpzQCbOpv35+ffKONOU7L2djdQoBM
V6TTrHeR8rD0MB9CpHJu/f274799/+H88uTw6O3hm3cnYT/SlkVAdyyiNRh1
FnToVigkKJsCOhVJCv7dMrpRcs0r8qdk72nyWXK9L1zZx2Y2QIDNPHe81zH0
Hoi6f60CXxw+NlOKhy395PHKoQHAkPa2D1Z3cL+7SmlXUBtum/YffUue6fHE
tg2QHWJpiOPB+znehcgO4YL3ZPWnP27p0NuF8DS2kgmNVteROXq4SPXpozAf
pZTo4i9B5X9vMszp0TzsgJo4F+e6IFWC8Cjn9YywyA0j4igDzUmw5L61nJ9C
5Ds8MVDqsIW0KO5Uylujq72/MEP2eVQtJx7amoDUdiui5qHx+eGrTWIxzkF6
eiZw14snL9A4vXfX0Mfy6XPKMryvCT7ISCXBEAhd+Vwfitfcp8Wtu6iGEoQw
5RgJyRdO0zIVJtEDD9ks0vHPP3918YGGxdGgP/+MeYxOzj+cwd8kUoGEcl9a
gYajViNmzjNLbzBdSwtDoCeoDAcHchhBzvhQg/jVirgjeUAp+PTVyxilzyij
qGRYZr1VulTZfdwtE+aWTZ054iVTi4JmqSdZ15eeQRWxLIG6GjISwLQXZY6+
jKRYZWkt9rWolHgPevDqFeYVtAmQdUgIZcItTpkEjfC8y2ToCpw4DyiXO+Sa
GckaUwPnza3DBUkzIjdPZKX3nlkIXQYO8qE6Cdu0nkqJl/HgBKMU8+iFKB00
rqY926cBmEkXJ86esUKsNU9vET5AjmlW8FKoWQO5NNRIaiFGdSZt2IAzmIE6
W2fsk4NGKFgW0oPwcLjwMBW/of96Q2bCrks9kBdbnAqsNRPEzJBQGME9qrST
4MyMZU5pyKSOJceQNNyOQ4h82Sd100NcqiafhLG4AwZILLZs5rpcWeup8s/c
V1zLA+FdvCXIUogLggzVBeh7l05FuShknH27LOYHV8ENRs+PaK7kbKlJU14+
JtgMZ+YdpLk2KbtSE3ruUvE4SGriqsMgQklOWy5s6QP6rnk/XvafnTIzRlyK
+6fytemthFdrUC6zfwoTo5UTwUveIdtJxanw2QUmb3nn/Vh5+Ni6v2okCXdH
SGDCuOesUEoQcsngUjHGLleNLuemU2OKxyKu7zwuTWbgEgqw4szmZUG4nBiI
KiexNnlZeA982dY50StKx0SKf7k4T+brkrk3CmLGdzSdoV2E3KdQSebpOBSO
Ct+opqLrrVyO+xX+QFEv9DzZMo17Di0e6a/GL999GOhAJn+t2Jo0Htg7TDyk
ZQcJiKiCtTOzVAN0VBqVsFBYHWs7wcWSziUzl0uwqApdN6eXLE1gcUvZH1M2
U643zK8kslyrRaTwM/EQcwIsGx5wLB7p7CDtWpOcTJcUKzBzZduAwk/wNAE9
N8YdhC5/4Xh4P2MYFhlXJLMF+pVmN3F0f7OCBRuRubEqR8eY4Y0dFhv2EJWX
GLrxhdBXLmcgRWLq0UI/lbwG2m7weS7PF3l881QbRFaKIitvNGhdbkpuxlOu
y4cZCyKY/LAQMaIziaGc2rTO7Hw5x6zaWwxqhVRBJ9ykfbPkCFSyqnApvDTp
qwO6RcqpmGaR8+0g+z5kKrTzoGPUicVK2IXQnhQXskFpneAoWOd4zZ4j5Tu9
k5uBFh3gTFGhMBDG4tTMy8zW6fFUc42cSLg4mP5BKUw0ZQXNhtFi9gDJ+HNX
c4aG9iVSAR4VGyErK9KYTBqOv4gPC7GZ0Yjru9F5T+tVip/krUOp0X0Pc5G2
YeiYs6QrO1eTl6ymgSbVZB+F87oByqMYMQCLSavqfAZztUOmdtDkIABinRrk
RVDrUKb3+yYGgWxA9IMOuuCcQCgdgPcR90FM4v0dOyB4zyrvZUG04ugJ6V2S
D4o2RrcJ0iQ8AQuwx3vrJUt3Ntm5Zl+Yl2dcCwyrZvp2Jz6uBrwj5mGI07hL
G639BzSXtxV7QWGgK8rd8lnAIPvggC0hFeixLG8h53bZQ0tNSGbENHfL40I5
/3vmxA1WxF5LSbTSp2R15oLGvz92eO+QYEDimOgWP5mvG3GejzSSvAyvUmdI
Z6HLetzp5bhBqC0UZTrNWvCHAEkOF3TxbL3KfxShzQmKmSSbewyGCuLFnNpv
g4twNdwTXMaFq3iRM5It2UGeJM5XnoKQ+FbHOtwF7gwpXnjXWvOQ4gysn7iA
BfcsCmSi0/YO0BtwJeu+yhL0EpoHSGztIbQmTtXDg0E7vofVzQSHNqDBloUJ
C4FwNP3W0JKBKzjsgFMf+NWHl9hilZz6q67UuXCWKdxNXksaF7C9kEkyuKgr
tJrOTWgLO6g5svWh4OVM4mbWyJ7otlwtULcjWxTiGjNJiBOUL/AKJa8Fjo3y
HbITBK+AS/MUu+1LqqYtGQOomJZTG2krTS4uyhQoLhsB1ujCKOOiLRgrzDC7
g/6Nt7itJZZyyT9xngsHFtyF7AnGCeaQWVDBFycTMd6Fdw3GgrZRRoGtkMYX
L1891XK7i20x79sj1PX4681ICaPIrrGjtTCxwjCoYtmJIMIE6QZQydr16iNB
YuPB3mFBwlxLfiBB0fW+WPejd8wCWEzY5m7unXfEg9l5qO/3p+L6WPKmmtxb
eIywwhh5+4+/2xyPAqYZiMZjaKaohYNRyGo5+SHjhLEgCWtGD2F0YRn6JnMM
EElQI+hIVJ2ymKhZVnIujIQSLCGSH44vxlKqzblo9yWAC7KjITFwKsuji6Gs
tYNHpZ52PGKbEa43srCR6FsBeG2hJ/QJ96vBfoq6DuzxxvEjsQ8tXpq9rvZ5
1w7SF1FluD3FHDXBruiSU56O7QbcHhhUQuu1yyAa/ozioepk7/L4bD9ICGqM
dGiMHP1zopbiODkdGxYgVH2DZq6YqJn5SOtx+gtSdarU61HI38+dssarqHlZ
A+97F2qP4vYIH2TxhKsJBlCiTFtFNC/BoSipVr+8tlLezOnnKiTkYbyFQeHE
W9CF5E82QvmsUdoELaEnGw2TV6rpok9u6ShcGxqcZkaNtVilVrbjlUdmtNr0
9Yf1nTHtsEYCQDPPYbQIBpKBrlAvtip5+tlnz56KdRQxFNLiXLyBdWtwUyex
6JRiSuc5A6ovoXm8OOPWxYr1X/B90EXCGXGSm/yOtOlJaOsWYxWaarGXypg1
JITBuM7hjQSn1Q4BB7u2YMW2cfSUX1cIge4wE6/R2TZRAivj1CyUJFVOwm3a
Qw+vSfXjUHzJhqhZlfQLHJOqSGGJf8hK0Lvwo/F4rAn2KF1kyxG8CHoZMtIO
yZgUW3LIn7dzxu4qDIUqHnLK9FE4Z30+KppNmbyguM40jmZIqDvCnLUHdI1R
K4xlUjeduOqs+lukbMzOS4QhWB1lx7UNOYaNE6tlEsW6ip/ZEqEbXA83cqIi
TovUolMn5XIkIMsti3qwffGEaohalKCaaD3qYDkYTFcjGOsgLulkYHKiCn8I
XDt0z0s9skxbyXHrQvmhw+8hGwhGj8XGPK/iZIK4tLKbvAppsRbXNAy5lzds
o8PAZZcqL1BeScNsPyWMrwYRNasx/coUKfHi+tKvUapp2CY5J4ewoVaVQP7i
VUsgNZXyM0kL4CFsECUXzeNAtoD5nC7hRWYHIwDGWNI+UYATFY6Im6D6dYd/
dYrqJEtC51upHURi5fm3x+/PDk/PtQK8xg5F+rTXnyOzk/O9l8AXn3pBZKVF
VRhwFA7Y11dff/7d1dc2sxlltiOlDpPj+RSDamTjEHfGxPEsrtJaWuK8tNga
l75zJli8KTHtlpgC2sqUXVwSFhGF/okZRE0HCHHK07HDXb0uOc+ILbGtSCVf
/RnjR8ne1ck+MpDrC9AeGsGD7GLcZhvn7xG9e69oH6H1WAkKFc50bZLh85JT
G5TlzoHniNZy+BamEQdBkakc5N5bTmWZi2yJR5GOTDUH1mwQDGsvJNOutYa4
Xp0MhT4ARSXq0jJFmI7yA6dUkpIv3Ul+g6IftZZ37E8N2xKpnCAmOTGhGLLE
8A4rjJRHBZFpWNkfuNReTU696/Zz8UHyoHSGvpXLakY21a84hI/4R3YfTMWF
15KWAyeL1bGNWlxcTJwHfnu8aln+5e3B9HMqu+slE2mNaWuTcklOVZe11DXA
4Lv3hJAMq6zKokdtwSs3QdqfiZQg/rREdlhXA4hRQqDS5MPVG2x9nw79e4Pk
xKceRf1zrGCBvggVcFLmUbdsQ0UIlrVhvs29k1M5M4ZGWpaBw6yShIWjJQsA
k7qi8IXtgJITTFx8lpYx0DYPtNpwaA7Vx5dIJM7kgrcyxekvMrqe9MZPvHV0
YPxiQTYsZhp5V5WxMR7ppppgB1nJfrF0oRl9wk5+9ziDGBvjR4Dnq8hvNC+g
y8Q2oPQSQo6N71S3QVzTWRnQ9mZ8AuHJVqBIguEH4YgTO+LjTAs9a55gs1cr
vCKpu57wKTc35gF1NsgbRqyDwUR9JuqGQaxSPB4HOZ62maRLR+OzT16Sy4sj
nUSzgbtvmfgUOlWFPJDTcRCINlD+L6a5JRyvJUcDDD45PQRW370BrZIm/uxa
c4PClg8pvdjgk8OpBl3go3x3clBkQ9Z5nm9a3iYXwG7zFejz7zJgwzOUDCmo
OheTu+jNKJ0RwWdkaEbFmj/lFZ/V6bz9Q/IeATs4TezIv6rykjMVofc6WT2I
KfLBoXRJyFdnvF/kt7aSWsJF6pzk+uP96P4b3HNZgZz07j+Abg/7fY0YbJGx
rwEVrUPm49HU8gcpQQDHCPhWu9gMZtmEsxky9AhCjPcJQeb2h+RDUeegqGAO
tUxcIVQjSj2ANnCGpT8kFyncl2fV9DZdZbCKQH1HC5LiYHH+I52CqESmzS/r
tJzCvI4xrzONcPBuPYO2p8lJMyWTkPCevCZbEcr6lYdq0S2evfflyOEmpPN1
PfhqPVuuy1nTSFjFFA5sPt9I8QWK6U5XqdMjEdeh7GOunat8CXv+dVboYuKq
zIE3IJMncKSEN5r/Ntaq+g/JYQni531yBXwOBAy4KHBTBvzpMLmG3UZCw8/z
2xSurMNJnS7SZYMfXbUo75fJl2kNN6Gk8b4EefQN/JU3A78SbhhUxqOckee2
T0qCaVMbayswk0dmCCPG6pAEYYUumSQ9qkO5Cbw24Dws/R/srGiUF2hETb6u
4H6LFpttqC5oZxwdRsmFd5v5I/l1DkQBPdwu8h/SMufzSFG2GFrfIvrn88K6
Q8oYVbNIV9rrPEfOJEf1Af0inHcITDE5Jj8JNtf/n/9dAy3+ZVPCxW45A2Zc
wAQIK0rvT4d27Z1j3DG1fPT05OqrOCMVuRnxfBCcJOhIDeUzPwwtfUm57EuY
Arx1BVyjJinsqwxEjeQtXIFIRdf5Es4acAH+9RuQBMvmNkdKbNvkTU3fHBOJ
ARECddd4NtHcjnVDqgI36gbrx33C8hUuLiyZ2Eyq0a4lpDOefFWjfb1dsBjy
DQuPR0WVYcBlYlPPzcJgtoDlqlS+heN63HU0GpHgpRk2VRo8sskvGgYxHHQq
SKok4euUl+kggupw59MYLCRLhSglnRRqKec0ICM6Z40hU5fKqH2grIpZ8C8V
l7ApqdTEOMvaNC8aDlizTiF2AEHOaJUFOTtKGmZxBjpu+XYg/zkXro/XqGqc
23rBaZLgF1n8JPnaHudFXW7IDUMSAyX7+gJFdU5bQjZ8iH4vVn18tm+jFEUJ
Yl+PvS//fHwOX4uUsomeO70AEm1RK2N2mgb2pT0SZTHnxL7Mb4ue4JAVHT2m
+Xa1epxdhfgAfrLHqBqXM82boDrXMCHPHK4K4paDykb5DHtxTnG9gEJTXRxW
p6Ir53OPEJFuPt4Hhxu26rpGj2NGqbi66sUJ67Mu1C4VGO2deTiPIx9I8uFE
ETb3EIdfuY8mbPNjLbQxFUH4LKh1wpST/dWnCISFp9ScrnqoKQnsV4OkTrog
JhXnPAHawt5csFJE+yRuXl2MjFuNyYOE+FumubBwqpJsZlYpnkIqLdU2xsH/
3oxwwQgs12gIgCJIOxo4a8+/05aDO8zNs0lHwUQNviDQzQ0IzUgcTae5P4Qx
ii2Sir/ts3IYjVLvTZM10pbldHnQLPOdqVeVS1LSye6IshLnoRqFiJzCfD48
J5006pzuJoTvZcAx1TNDGbtaSVd5JmqYhWtdwB1zR5dVRQ637/rUWLed4hkm
Qe3m9OT7Ak3CHK6NgLGrGBT4UV2btVDLQtBUCqLJxOSKY8fXPEoUG/Rs/GWD
wo/b85q6TBI2k4uelJQHJlVDME4HT9I0i15xIcv6qN9o6JHEpnislSK2Pn+N
X2zJUA3dO7TyNisD/2uuREhMNtOoaxeeVKOKA+dfmbVhH33uZZ2rUt2czHvU
k5rpGJTqvxtkCI4sA2AMOd/2TCDi/2kTWRmnKQ0g2Eia1yAUR3vu0CP5hJ0a
6j9D5I82WUNEiF/7B37+BP8aEUL4ayTsyMljN7pKkjVqiXi9vSSE0iyeSx8V
rlE4fPGWDabfk1bntJSQBT4NIegc1Bv9SFnNZI/upJBLEzQSWd/tS/uEsRqz
/N623Le0aiSiaDZHGSruyucamGBkhGA1GpdXWfzLyyB1851x4IA1eUPBGur+
62riyL7swdH6j6v35/u+1EbIxMzuO19XHWIUuUXoMubPZ9EqbchAGDY3KaqJ
J8S4uKiXhbdNKEi2y/QnMyFbEN6hpi44g/didpYSNlKtVCJgXj1/jX5SReVU
VBSJZloDrI1zyI77Je3Y/yhk9AGLCavX0IofHR+/c45bmKyGUF9y5RH6ty3U
9rgH3MRZVDQV6q76jVa5rYJi9xpw5/B4Nbl4dCvyhYRV+V/wk0xns2KA+lm4
6X9Mfh4kyaPasdLv2Yz+KDlIWtjjIX47Wz5Koh//7f/A7793Qjy++Oi4un7k
vuJP3XtrIBj/XjotHplGcYDwUfJ58p/Jv+of/5Ofhj+/R7H9e1jtRTV7JE/D
JyP+xD9mdJNHPNIBsERtz/38kb+KmkmSz/+YPLJN0AoGCWRBXfu3fwF9GZ0+
kcWQIPJDExRWwZw+8jgG3deI145Gf6L9GGxf9UflF7Onz57Px7XqemO49h9t
34hHLtnqE3jv4MmTJwdPnz49OHiq79jN0Xdwh/TrYIPo6+fPnz3Tb4Mdijuc
P3lx8PJpdvD0yZSSV+Kud35g2f5z50vkXkHb3Nlk7tBuxlAfsx/yYyP8eXPy
1el5cnRyeX365enR4fUJffq38uz09Pj6h6OjL7/aQG9jaOdX2gnKtrFFyNrr
7ND+4IDsHqbueeAmm5yptrW11SZ2FxNFjG4Vzc1J+CKaFtRI4LS4Ht819Why
rCih/BSSSh44QC8cwBUN1VdVVMu92VKnaEQuxAY0M7lxtHDFcFxSn6BSoo/z
aKSW8Y4xhqlSUYZQMUUZIw6CPS4xdCBXJH5FIZ+UQDMoFehyvLKbR6uGaRSz
bQwojB36piNitJDSJcD09VyWbDjlAqTcHjsU72DleRO5PaujcxCdwj4g6JFA
hkjuwdC3FAeQWntcHDYDCVPrcNHSkI9InHV26Ks88Sqp+4F4sSCUE0M0pSHq
0BnYelG7u00EPK7YW1MxOIfoADn9zbOf/QMhLQ/5SNRXLSVE4sTF21fWxQFy
hhWcIzE1l+NItEWtoab1mqRYHu4CPP8WeA/88+dHVn3qo9SAGn2QrRsY1R3j
orq9h+3CrYZbiFNR9BqxDtZtBFZ9dBwWHHOrEIvBPdsyjmtuGwuk3xotkkDx
jNoNfhP7oopTXho8FMhgJOWi6VnkWD8lybRhmZX3/6XyRR4xnlMqAy7V/FHI
7ZRr6Jm8N+LEGMSam5y8gVwkqbLE8ajMbioJN7OGiAAY9z0frWu0HgnI1/uQ
n5WXiHOJkBbVkUDKG4cKpCaYzJbJBpbHoNCNS/8iPjP51i3enhdc9glP82EY
y3DGotEe3rx/oxv6b3pFEzG/NSh+WDWhU3zPhHNSHUjnN7LHmGSnAIiIZQj2
eQAVRhuKBcmjVXP7CEnsERY5fCSn5+Khp7h/wshWbDc9S0OO57Iw0Yjos9ts
88hxPouawy7k5XakXHJa7eQApMVSLJFo+JgkF+Gc+UgcNm2H4r+zjUdR9pUV
BnEyhwfxYpk2t8y2QAx0kxCfXxPCIdi1i0qhpPG9dZ1cDBrmJ5CG1K/I4to+
WhxjCyRUv2G421e28rZadpTAVktKxbsRzwqRKPKGZ9a2Tt7avqr5PFmXZkV1
dq7+ZCCsxAx3tjRNC2/UkHHesNnSoXxNZFwQthZ0wG6OQZ6QPcomaGJqe9ol
qQDp9Ut2ifZwiWatN+a0bRetfc9jAXK5civozhrvC90i4lICutKTMdFN0Jg1
mW+Jn0D/LJc0TgVehoz6KjzmM0ndrVKNLzjpMxeu88IFloi7FCEUBmAK0uWi
Ty7r/Po4G2xtNYWuyZIfHa0p7Y3BHF0W4iiAdDfWe+8rENdUAVDKp0hWjrTV
2slq1BXH78b5yWFweOpKwu01WSaGnuzHEc5dcxiRNaPOyWMEtFmyafCCh3Zd
jl8jgVQNqZiS6+nv22fnLnUloNOFEFrfLrvMO7/d8CIO0g6Cslgw5wyoq1Wd
c+3eZz1zkfFXHoGNk2rZRXcFxgQr3zEb/BWxvhFvFKWc/+vh+Vd8uRCm25Oz
p/H+lmbsCkGY2HKCwSz455YeIUPCRmfVfYk1LzgbhQpGbMowp1nq6ARWuh52
QnEgVIHIYW5Bbaq91GTfrEOnd9JjoN198Q6tft9e+yEQaOnXJ4BgrwM0kH36
0smkzmcI1xjLY6r4OO2IGEHE/KNAP8ldIb5m0EGqweAPA3LmwSfJiQBKyeEW
JoTsABjyil0GGQ/lyBA9uwr2S4ZFus7KLADaPeP0ae5MZzO46mbs4VrhhUpa
mFZLJ1pm9QLupDHV4ngwm/AhYKnW9hPM1+D/A38QQ+bLlzoLhfAkuQGjVbB1
ftcl5kFRw4nLlahTk5p82OvQkjXdbHm9vKcwnIrCo4ZdS4MbC4/eebpzpQYr
WCk2zovbTbYAOhSD/GnTbJZLtHNNDfuRnLXSiB3DMLioEENfpM2gYyfRyNr0
ps7IcbqSbBhJIqqeknKuZlm0z/vCJU7v3wI/cpWsAtOtbySjc8GBRjMpJFzi
glqQ3U7DYPPIljRtmI6C+KS4ZlCJ91OXZJSy9sI5a1tKtgVCHOZUkdLsYr02
6aJwp0CWQULH6RjXd1ufIZdCD9FhFVesqrqly/nAQLWIvD4EalW0dPuzBHjK
09O2LgS7DFarB/h1KC08i/Asf14236N1lz//T/z7yZilglnZaDOoiZTN054v
/ic1gkzcI8M74OcAmH0ILHvwOyFZkrZA6cD14ZhQAU4kna6XiFSek6OjhxqZ
6/8Fmkcug50pAQA=

-->
</rfc>