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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY I-D.ietf-homenet-front-end-naming-delegation SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-homenet-front-end-naming-delegation.xml">
<!ENTITY RFC8415 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml">
<!ENTITY RFC7858 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC7368 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7368.xml">
<!ENTITY I-D.ietf-dhc-sedhcpv6 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-sedhcpv6.xml">
<!ENTITY I-D.andrews-dnsop-pd-reverse SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.andrews-dnsop-pd-reverse.xml">
<!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC6672 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6672.xml">
<!ENTITY I-D.sury-dnsext-cname-dname SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.sury-dnsext-cname-dname.xml">
]>

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

<rfc ipr="trust200902" docName="draft-ietf-homenet-naming-architecture-dhc-options-14" category="std">

  <front>
    <title abbrev="DHCPv6 Options for HNA">DHCPv6 Options for Home Network Naming Authority</title>

    <author initials="D." surname="Migault" fullname="Daniel Migault">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8275 Trans Canada Route</street>
          <city>Saint Laurent, QC</city>
          <code>4S 0B6</code>
          <country>Canada</country>
        </postal>
        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>
    <author initials="R." surname="Weber" fullname="Ralf Weber">
      <organization>Akamai</organization>
      <address>
        <email>ralf.weber@akamai.com</email>
      </address>
    </author>
    <author initials="T." surname="Mrugalski" fullname="Tomek Mrugalski">
      <organization>Internet Systems Consortium, Inc.</organization>
      <address>
        <postal>
          <street>950 Charter Street</street>
          <city>Redwood City</city>
          <code>94063</code>
          <country>US</country>
        </postal>
        <email>tomasz.mrugalski@gmail.com</email>
      </address>
    </author>

    <date year="2021" month="May" day="13"/>

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

    <abstract>


<t>This document defines DHCPv6 options so an agnostic 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>


  </front>

  <middle>


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

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

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

</section>
<section anchor="introduction" title="Introduction">

<t><xref target="I-D.ietf-homenet-front-end-naming-delegation"/> specifies how an entity designated as the Homenet Naming Authority (HNA) outsources a Public Homenet Zone to an Outsourcing DNS Infrastructure (DOI).</t>

<t>This document describes how a network can provision the HNA with a specific DOI.
This could be particularly useful for a DOI partly managed by an ISP, or to make home networks resilient to HNA replacement. 
The ISP delegates an IP prefix to the home network as well as the associated reverse zone.
The ISP is thus aware of the owner of that IP prefix, and as such becomes a natural candidate for hosting the Homenet Reverse Zone - that is the Reverse Distribution Manager (RDM) and potentially the Reverse Public Authoritative Servers.</t>

<t>In addition, ISPs often identify the line of the home network with a name. 
Such name is used for their internal network management operations and is not a name the home network owner has registered to.
ISPs may leverage such infrastructure and provide the homenet with a specific domain name designated as per <xref target="I-D.ietf-homenet-front-end-naming-delegation"/> a Homenet Registered Domain.
Similarly to the reverse zone, ISPs are aware of who owns that domain name and may become a natural candidate for hosting the Homenet Zone - that is the Distribution Manager (DM) and the Public Authoritative Servers.</t>

<t>This document describes DHCPv6 options that enable an ISP to provide the necessary parameters to the HNA, to proceed.
More specifically, the ISP provides the Registered Homenet Domain, necessary information on the DM and the RDM so the HNA can manage and upload the Public Homenet Zone and the Reverse Public Homenet Zone as described in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>.</t>

<t>The use of DHCPv6 options may make the configuration completely transparent to the end user and provides a similar level of trust as the one used to provide the IP prefix - when provisioned via DHCP.</t>

</section>
<section anchor="sec-overview" title="Procedure Overview">

<t>This section illustrates how a HNA receives the necessary information via DHCPv6 options to outsource its authoritative naming service to the DOI.
For the sake of simplicity, and similarly to <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>, this section assumes that the HNA and the home network DHCPv6 client are collocated on the  Customer Edge (CE) router <xref target="RFC7368"/>.
Note also that this is not mandatory and the DHCPv6 client may instruct remotely the  HNA and the DHCPv6 either with a proprietary protocol or a protocol that will be defined in the future.
In addition, this section assumes the responsible entity for the DHCPv6 server is configured with the DM and RDM.
This means a Registered Homenet Domain can be associated to the DHCPv6 client.</t>

<t>This scenario is believed to be the most popular scenario. 
This document does not ignore scenarios where the DHCPv6 server does not have privileged relations with the DM or RDM.
These cases are discussed in <xref target="sec-scenario"/>.
Such scenarios do not necessarily require configuration for the end user and can also be zero-config.</t>

<t>The scenario considered in this section is as follows:</t>

<t><list style="numbers">
  <t>The HNA is willing to outsource the Public Homenet Zone or Homenet Reverse Zone. 
The DHCPv6 client is configured to include in its Option Request Option (ORO) the Registered Homenet Domain Option (OPTION_REGISTERED_DOMAIN), the Distribution Manager Option (OPTION_DIST_MANAGER) and the Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) option codes.</t>
  <t>The DHCPv6 server responds to the HNA with the requested DHCPv6 options based on the identified homenet.
The DHCPv6 client passes the information to the HNA.</t>
  <t>The HNA is authenticated (eventually by a self signed certificate) by the DM and the RDM. 
The HNA builds the Homenet Zone (or the Homenet Reverse Zone) and proceed as described in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>.
The DHCPv6 options provide the necessary non optional parameters described in Section 14 of <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>.
The HNA may complement the configurations with additional parameters via means not yet defined.
Section 14 of <xref target="I-D.ietf-homenet-front-end-naming-delegation"/> describes such parameters that MAY take some specific non default value.</t>
</list></t>

</section>
<section anchor="sec-format" title="DHCPv6 Option">

<t>This section details the payload of the DHCPv6 options.</t>

<section anchor="o_rd" title="Registered Homenet Domain Option">

<t>The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the FQDN associated to the home network.</t>

<figure title="Registered Domain Option" anchor="fig-rhd"><artwork><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   OPTION_REGISTERED_DOMAIN    |         option-len            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                   Registered Homenet Domain                   /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style="symbols">
  <t>option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code for the Registered Homenet Domain  (TBD1).</t>
  <t>option-len (16 bits): length in octets of the Registered Homenet Domain field as described in <xref target="RFC8415"/>.</t>
  <t>Registered Homenet Domain (variable): the FQDN registered for the homenet encoded as described in Section 10 of <xref target="RFC8415"/>.</t>
</list></t>

</section>
<section anchor="o_dm" title="Distribution Manager Option">

<t>The Distributed Manager Option (OPTION_DIST_MANAGER) provides the HNA with the FQDN of the DM as well as the transport protocols for the communication between the HNA and the DM.</t>

<figure title="Distribution Manager Option" anchor="fig-dm"><artwork><![CDATA[
 0                   1                        2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      OPTION_DIST_MANAGER      |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Supported Transport       |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                                                               |
/                  Distribution Manager  FQDN                   /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t><list style="symbols">
  <t>option-code (16 bits): OPTION_DIST_MANAGER, the option code for the Distribution Manager Option (TBD2).</t>
  <t>option-len (16 bits): length in octets of the enclosed data as described in <xref target="RFC8415"/>.</t>
  <t>Supported Transport (16 bits): defines the supported transport by the DM (see <xref target="sec-st"/>).
Each bit represents a supported transport, and a DM MAY indicate the support of multiple modes.
The bit for DNS over TLS <xref target="RFC7858"/> MUST be set.</t>
  <t>Distribution Manager FQDN (variable): the FQDN of the DM encoded as described in Section 10 of <xref target="RFC8415"/>.</t>
</list></t>

<section anchor="sec-st" title="Supported Transport">

<t>The Supported Transport field of the DHCPv6 option indicates the supported transport protocols.
Each bit represents a specific transport mechanism. 
A bit sets to 1 indicates the associated transport protocol is supported.
The corresponding bits are assigned as described in <xref target="tab-st"/> and <xref target="sec-iana"/>.</t>

<figure title="Supported Transport" anchor="tab-st"><artwork><![CDATA[
Bit Position | Transport Protocol | Reference
-------------+--------------------+-----------
      0      | DNS over TLS       | This-RFC
     1-15    | unallocated        |
]]></artwork></figure>

<t>DNS over TLS: indicates the support of DNS over TLS as described in <xref target="RFC7858"/>.</t>

</section>
</section>
<section anchor="reverse-distribution-manager-server-option" title="Reverse Distribution Manager Server Option">

<t>The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) provides the HNA with the FQDN of the DM as well as the transport protocols for the communication between the HNA and the DM.</t>

<figure title="Reverse Distribution Manager Option" anchor="fig-rdm"><artwork><![CDATA[
 0                   1                        2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_REVERSE_DIST_MANAGER   |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Supported Transport       |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
|                                                               |
/              Reverse Distribution Manager FQDN                /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t><list style="symbols">
  <t>option-code (16 bits): OPTION_REVERSE_DIST_MANAGER, the option code for the Reverse Distribution Manager Option (TBD3).</t>
  <t>option-len (16 bits): length in octets of the option-data field as described in <xref target="RFC8415"/>.</t>
  <t>Supported Transport (16 bits): defines the supported transport by the RDM (see <xref target="sec-st"/>).
Each bit represents a supported transport, and a RDM MAY indicate the support of multiple modes.
The bit for DNS over TLS <xref target="RFC7858"/> MUST be set.</t>
  <t>Reverse Distribution Manager FQDN (variable): the FQDN of the RDM encoded as described in section 10 of <xref target="RFC8415"/>.</t>
</list></t>

</section>
</section>
<section anchor="sec-dhcp-behavior" title="DHCPv6 Behavior">

<section anchor="dhcpv6-server-behavior" title="DHCPv6 Server Behavior">

<t>Sections 17.2.2 and 18.2 of <xref target="RFC8415"/> govern server operation in regards to option assignment.
As a convenience to the reader, we mention here that the server will send option foo only if configured with specific values for foo and if the client requested it.
In particular, when configured the DHCPv6 server sends the Registered Homenet Domain Option, Distribution Manager Option, the Reverse Distribution Manager Option when requested by the DHCPv6 client by including necessary option codes in its ORO.</t>

</section>
<section anchor="dhcpv6-client-behavior" title="DHCPv6 Client Behavior">

<t>The DHCPv6 client includes Registered Homenet Domain Option, Distribution Manager Option, the Reverse Distribution Manager Option in an ORO as specified in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of <xref target="RFC8415"/>.</t>

<t>Upon receiving a DHCPv6 option described in this document in the Reply
message, the HNA SHOULD proceed as described in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>.</t>

</section>
<section anchor="sec-dhcp-relay" title="DHCPv6 Relay Agent Behavior">

<t>There are no additional requirements for the DHCPv6 Relay agents.</t>

</section>
</section>
<section anchor="sec-iana" title="IANA Considerations">

<t>IANA is requested to assign the following new DHCPv6 Option Codes in the registry maintained in: https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2.</t>

<figure><artwork><![CDATA[
Value Description                   Client ORO     Singleton Option
TBD1  OPTION_REGISTERED_DOMAIN       Yes            No
TBD2  OPTION_DIST_MANAGER            Yes            Yes
TBD3  OPTION_REVERSE_DIST_MANAGER    Yes            Yes
]]></artwork></figure>

<t>IANA is requested to maintain a new number space of Supported Transport parameter in the Distributed Manager Option (OPTION_DIST_MANAGER) or the Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The different parameters are defined in <xref target="tab-st"/> in <xref target="sec-st"/>.
Future code points are assigned under Specification Required as per <xref target="RFC8126"/>.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>The security considerations in <xref target="RFC8415"/> are to be considered.
The use of DHCPv6 options provides a similar level of trust as the one used to provide the IP prefix.
The link between the HNA and the DHCPv6 server may benefit from additional security for example by using <xref target="I-D.ietf-dhc-sedhcpv6"/>.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>We would like to thank Marcin Siodelski, Bernie Volz and Ted Lemon for their comments on the design of the DHCPv6 options.
We would also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their remarks on the architecture design. The designed solution has been largely been inspired by Mark Andrews’s document <xref target="I-D.andrews-dnsop-pd-reverse"/> as well as discussions with Mark.
We also thank Ray Hunter for its reviews, its comments and for suggesting an appropriated terminology.</t>

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

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

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC8174;
&I-D.ietf-homenet-front-end-naming-delegation;
&RFC8415;
&RFC7858;
&RFC8126;


    </references>

    <references title='Informative References'>

&RFC7368;
&I-D.ietf-dhc-sedhcpv6;
&I-D.andrews-dnsop-pd-reverse;
&RFC2181;
&RFC1034;
&RFC6672;
&I-D.sury-dnsext-cname-dname;


    </references>


<section anchor="sec-scenario" title="Scenarios and impact on the End User">

<t>This section details various scenarios and discuss their impact on the end user.
This section is not normative and limits the description of a limited scope of scenarios that are assumed to be representative. Many other scenarios may be derived from these.</t>

</section>
<section anchor="sec-scenario-1" title="Base Scenario">

<t>The base scenario is the one described in <xref target="sec-overview"/> in which an ISP manages the DHCPv6 server, the DM and RDM.</t>

<t>The end user subscribes to the ISP (foo), and at subscription time registers for example.foo as its Registered Homenet Domain example.foo.</t>

<t>In this scenario, the DHCPv6 server, DM and RDM are managed by the ISP so the DHCPv6 server and as such can provide authentication credentials of the HNA to enable secure authenticated transaction with the DM and the Reverse DM.</t>

<t>The main advantage of this scenario is that the naming architecture is configured automatically and transparently for the end user.
The drawbacks are that the end user uses a Registered Homenet Domain managed by the ISP and that it relies on the ISP naming infrastructure.</t>

<section anchor="scenario-2" title="Third Party Registered Homenet Domain">

<t>This section considers the case when the end user wants its home network to use example.com not managed by her ISP (foo) as a Registered Homenet Domain.
This section still consider the ISP manages the home network and still provides example.foo as a Registered Homenet Domain.</t>

<t>When the end user buys the domain name example.com, it may request to redirect the name example.com to example.foo using static redirection with CNAME <xref target="RFC2181"/>, <xref target="RFC1034"/>, DNAME <xref target="RFC6672"/> or CNAME+DNAME <xref target="I-D.sury-dnsext-cname-dname"/>.</t>

<t>This configuration is performed once when the domain name example.com is registered.
The only information the end user needs to know is the domain name assigned by the ISP.
Once this configuration is done no additional configuration is needed anymore.
More specifically, the HNA may be changed, the zone can be updated as in <xref target="sec-scenario-1"/> without any additional configuration from the end user.</t>

<t>The main advantage of this scenario is that the end user benefits from the Zero Configuration of the Base Scenario <xref target="sec-scenario-1"/>.
Then, the end user is able to register for its home network an unlimited number of domain names provided by an unlimited number of different third party providers.
The drawback of this scenario may be that the end user still rely on the ISP naming infrastructure.
Note that the only case this may be inconvenient is when the DNS servers provided by the ISPs results in high latency.</t>

</section>
<section anchor="scenario-3" title="Third Party DNS Infrastructure">

<t>This scenario considers that the end user uses example.com as a Registered Homenet Domain, and does not want to rely on the authoritative servers provided by the ISP.</t>

<t>In this section we limit the outsourcing to the DM and Public Authoritative Server(s) to a third party.
The Reverse Public Authoritative Server(s) and the RDM remain managed by the ISP as the IP prefix is managed by the ISP.</t>

<t>Outsourcing to a third party DM can be performed in the following ways:</t>

<t><list style="numbers">
  <t>Updating the DHCPv6 server Information. One can imagine a GUI interface that enables the end user to modify its profile parameters. Again, this configuration update is done once-for-ever.</t>
  <t>Upload the configuration of the DM to the HNA. In some cases, the provider of the CE router hosting the HNA may be the registrar and provide the CE router already configured. In other cases, the CE router may request the end user to log into the registrar to validate the ownership of the Registered Homenet Domain and agree on the necessary credentials to secure the communication between the HNA and the DM. As described in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>, such settings could be performed in an almost automatic way as to limit the necessary interactions with the end user.</t>
</list></t>

</section>
<section anchor="scenario-4" title="Multiple ISPs">

<t>This scenario considers a HNA connected to multiple ISPs.</t>

<t>Suppose the HNA has been configured each of its interfaces independently with each ISPS as described in <xref target="sec-scenario-1"/>.
Each ISP provides a different Registered Homenet Domain.</t>

<t>The protocol and DHCPv6 options described in this document are fully compatible with a HNA connected to multiple ISPs with multiple Registered Homenet Domains.
However, the HNA should be able to handle different Registered Homenet Domains.
This is an implementation issue which is outside the scope of the current document.</t>

<t>If a HNA is not able to handle multiple Registered Homenet Domains, the HNA may remain connected to multiple ISP with a single Registered Homenet Domain.
In this case, one entity is chosen to host the Registered Homenet Domain.
This entity may be one of the ISP or a third party.
Note that having multiple ISPs can be motivated for bandwidth aggregation, or connectivity fail-over.
In the case of connectivity fail-over, the fail-over concerns the access network and a failure of the access network may not impact the core network where the DM and Public Authoritative Primaries are hosted.
In that sense, choosing one of the ISP even in a scenario of multiple ISPs may make sense.
However, for sake of simplicity, this scenario assumes that a third party has been chosen to host the Registered Homenet Domain.
Configuration is performed as described in <xref target="scenario-2"/> and <xref target="scenario-3"/>.</t>

<t>With the configuration described in <xref target="scenario-2"/>,  the HNA is expect to be able to handle multiple Homenet Registered Domain, as the third party redirect to one of the ISPs servers.
With the configuration described in <xref target="scenario-3"/>, DNS zone are hosted and maintained by the third party.
A single DNS(SEC) Homenet Zone is built and maintained by the HNA.
This latter configuration is likely to match most HNA implementations.</t>

<t>The protocol and DHCPv6 options described in this document are fully compatible with a HNA connected to multiple ISPs.
To configure or not and how to configure the HNA depends on the HNA facilities.
<xref target="sec-scenario-1"/> and  <xref target="scenario-2"/> require the HNA to handle multiple Registered Homenet Domain, whereas <xref target="scenario-3"/> does not have such requirement.</t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAFJnnWAAA+1cW3MbN7J+n1+BYz8cKSFpU5ZlR1WnNrKkxKqyLhHlpLIv
KXAGJFEaDrjAjBjGVn7L/pbzy0534zKY4ZCybJ9UHpZbG4szuDT68nU30GC/
30+SUpa5OGQnb4+v7g7Y5aKUqjBsojR7q+aCXYhyqfQtu+BzWUzZUVXOlJbl
KuHjsRZ33R0vjpJMpQWfw8CZ5pOyL0U56c9gwEKU/YLG6nOdzmQp0rLSop/N
0r6yY/SH+4lc6ENW6sqUe8+ff/d8L+Fa8EN2VpRCwxDJcnpI9OHft8v6Rf8E
p0tSXh4yU2ZJqjKY6pBVMP3rJFnIw4QxPUlFZsoVrnslDDwpVRr9KYtMFKV/
YJQutZiY8H01b3wttUxD41TNgagyvJVFLoswDTBlzhcLogifJJzYiTThp+/+
xW4wwsmAncspr/IyPLcsPeGFFPnaS6Vh2FOgxhhVhKdAnxBA3+u9Vy/ZjeYg
o2Ne8Iyza1WVIrRLQaiHbMRlUbJ3HERSlD3203H9XmUw9f6IPX9zED2silJD
PztkeC7mXOYgeyJ0MLeEfi8cbQPgUveSrwfsFzEWurXga55PWi9osUe3HCZq
L7W5pOYC1ihvk6xhqsESp/qe0+ibib0B+ehqynNzK1sE34Bq3na8Jaq9rrLR
ypRiDvIApQclk9W8By/TwZrsvnv5nB3PuIZ+bETPWmK7FtlSqYwdo2U2Jfbd
/vODF+sCez9qr7xUc27+GMw90d9P8TktP0n6/T7jY6CHp2WS3MykQWWuUNdZ
Jiag48YjgbNisBvGC8anhTKlTL21rgEJ2wG42GUptq2QBmjM83zFFlqlQmRA
FytngoHdaLXQkpcCVlFM5LTSHGeCWTIGqmxUpVNh27rB4f2dYBZumBH6TkID
RChshGjECgtvg+SsYHMgFOgwwvSogR8TO89FOgNlNnMGKy/RihYcTSSMJoCI
CqYYWF7NZZblAhj3lN0IDfOrXE1XyDnBbsWKwaSZYU/O349unvTsv+zikv6+
Pv3p/dn16Qn+PXp79O5d+CNxLUZvL9+/O6n/qnseX56fn16c2M7wlDUeJU/O
j36FN8iwJ5dXN2eXF0fvnoAywwpigcLKkOtjAa9A5RZalCAHbpJMmFTLMXyB
Pm+Or/7338N99uHDf13/cLw3HH53f+++vB6+2ocvy5ko7GyqAIHar8AscB6L
heAaRwFRA88XIKsc2M5BbWZqWbCZ0AJYSfwC5M9A8eFFlWdI1QQEmkvov5Tl
DKc8658MGh5molVR9kEm3tdkIhdTUpf7+wFKBYxQq6xK8VGSPHoMZhYilRMJ
ag/0oqID41CbgUVyWnDLMNKMBxQ/aK5hnF1V4zyylX+qgiQBw19GynhyMQL6
J5qDPVbkPtnOyeXZ7mDdMq28HJFe28nYwJrupEH7ISIvjiw3uV9ZymDIgR0w
9ZwHpQfzrHKuQZ6g7pMqJwvg2JjewvM5+IIprH+8QsLPRlc9hkai4MVt0+wM
yNaAKJFWeI9EaLHIeSqQ/AEj8cMAzLEeeQQjXgHxgDm/e2iIh0SuLwUoleM+
B4eTSpIHhCtCG8H+AK4OwtBoz7MKBl6i2quJNf1lARpHX3hZT2iVGZW0SmfA
D8BGEhvIG8AIFbnIZIYIhUyZIfCBuGIluHY0kGT7dnhpKfWvTiSGFOOKsO2c
eKnZzvXJ+S7NvlAlqhpBZNzNqc5RA/pGgHnwFhQD8I1nmcRBe7huA6uDgZjE
UEdO7FgYq3gWNJjqVAOdG0hlhKvHv5F00ILMo6DUFjEK4IXvarWB1FEthIVs
QyuBzoUq3bDrc1oZzDgqyRR4AoiAzgCgGqmf8xXLcekwuBWHbFoE8Qp1PKvH
Rgm0tTwDlwM4RDQ0jReofTy4wNC1rAPZJzTJIBlJQC4yHqe6sU46uaAaBmVc
zhQywlhNiWnF9SETrBY+Sgk7lK9b6bzOYYsH9GsT8LSCAppTFHycCwcOyIlY
ToUAKDRcrxBOYKHAQOO5BQDRc+0xNBgk5wrY5EWJJmE9Nw7rxvS2FUThmWBF
0ovmAwVSem5jCgeLJ+dh/WCAGNJ4sEQItapNLapFrniDUQ1mh0GaxtpsY1jD
v36OX0NQA4NEzWkxHlWF8BfJaMZPoD+LHPiMWhlFNo7nPrCJDQoxz1hVJiPM
CTQwW/OwiwsiZGhJt8buPsUDtRuCtneSE9kDipuuUMgZmvLlHYZuYsk+PDUC
0kT39d5pHTyjdcg8rzBCLYO/sw4lFaCqpqVcsbD9vLGeqiiklKXZHlI6VpHD
/MEFhAaZDWwBPi1A1uDwrfcwMQQ8WsY9G6r5JYN3q+bCmZVXTa9sDTR160ut
s0V0SVWeq5TAzmk7Owb+QSfNTjPQ653j012mMUlEHPwHxHWvXhy8Rj27AB8E
kRuZA00MJDk0B5sA7FF6Fchozox6CNkTwTTIZq6s3uHsMe2ukwCwFtpjtk0A
REngoBVk6ipnFH2Eb0TPEjQBoxWbmGQ2wAU4rNAxDJqucAM7EZnNAjRBIlK5
2M7H+o44Q+DHKD6y9gRzEakRdABsuCBqLjD35puxiDBl3AhZvGLFLPRga1LA
US0VEjAW8OrOdhhbS6NsZqEWGKyFthRSNYBaCSs38HuEpa6hQevUomO5oceM
gyGAPO4kqCeFV7lz7jEPgGWOBQJwibIr0r5MmrQyxkMd2rWfGzWMQoyamEzR
lN58JaiMFv+qpG5jWTsdIxlQbonaCqz5Q2jVt30cXgY+pijujATjU6IALQaB
bYIWszSHSTIcsBtnbdKQvpGPVa08tAvm3cZaOxh0wW7TWJqqBcPLIs2rDPMy
AiW76Qbj/KsSIG33defy+nJ3u9urm1IW+Nv16Y9no5tTyDp/O7k8Pzq72O1t
DgtafU+g52/nRxdHP55e7655uk8Z4fr059Pr0WlrJAvFtIuBAcaeZXlTGa2R
ZnGAUGuftmzB8KsJ7mNuatBzAbCEJw6BBx2SWIBROmCIPUc9LVD4oqEU6DBw
ZIuwO8COoqwoase8CBaQo2+YIj6lQpcUwJRiF9+uRx5OO3DocSXzrJlZkl7t
OM3vUq5d77xpQ+UrBBoRgzxTu2O4AmMpagGRaRTQNQgYOSsb7qPD/ExykDfo
XGw0Q+C2Fuo4aPLo3yQJowCL0Qg1K+E3tiDM/EICo3CYMpU4sEV/dX70Kysx
XDDosUNmgrwDEnDrlN3xvBK0cdHYb3cRkVXIdjyUgaeUuVWVBV9RgOqSu6bs
cNynD4PFh6fqN53dW9RcS24ehhQQdUZKbkn64aeTiw5f19yWS5I///wzYc/Z
+mfY8Wyv49kL7D6EVy/YPnvJDtgr9pp995hnybf9L/xf8hEI2cQYJPJjINfK
pJ9DbBx9Pn4lGr7k8zF51vF0s9qsf559BRq+nA+oUR8OnwIs9PUM9A4PwP7n
ySaFfgIK/42XCjojtjM8YGNwv7uHG0XqNpBrDxYCky3s2rl5czLETbxvYiWI
ZoOv0xI3OphKS1Eab82bxwS3lncCPm7S7g9fUtL4zZYBdu4gNMJsHaYPRhvt
x8Sb6dhNFLja9SkDgj53CBoTgOizLU5A4MnmDnhCQxj4kyKSxkZAI0CgxXhE
PG/vHNpcWOkyZBcmLBeP+aoCwQznHQNaCVFvpIYkBuLex+EXff7WIMYCjsVc
dsZZ09uJYl8PxEbVAiUDKnATpLRGw+cCyIMj/L8AaacBWBVd//ztgDSbexzd
YsgIpQ9iaaxWm2F0a1oBOLr3OTgK4JUrTA0yXvKHUbNLCaNZ/LEobQaFpjWq
1IH+jhHC58Dl/T2QfsrxfEHiDskCchysKMCcYX0UdyKBo2AU6SOseFJc3Rxi
SAlhMZvbbAqBFIdHduJpEm6psZt3I7fIV69fvoawlU4lIWc2mBPBgjuZThra
6SZqZP0sr/AUvEIXi23Ia0rnD7qaWLfXFeu2YtAuuQS03ygGH6DXfcLxMCRq
R9TDoF5BSDtszRgHvGtTYt4YSLJSSpV2SS7uMIxpK1LTMDZ3XNfSko9JjUgz
rFZJkBXxFC32DVB3pQxlQACXNdeuPBUfISCYgHsvUoGH2fXn237HJ37oagqc
u/vY1C3/EJOUPkjaNh72hy/t8woSMr8jGVDKYYxdlMeYDpk/YaAP8XSH3aKm
rfGYqm4ztxbgE6MtWxn2BMRBj0+NvnTr4z8hy9cLWbYwmv0nZPnUz1rIslXJ
u6KWv0fI4vCE2eyvjlo+wWYpevmEVHBdz7Zlg58AFRDOvPiccMa1pmDmExPB
rxPSXH+dmOb6LwlqHlbkbcHN9ZboxmyNbnxc8kbM+J0Ekm1ck83SRX/snt3b
1Ng2dJ7Gt0/8rqRhw1eDvcEecW34Gv5ozcamyInC75mHKgykEVJ5ru3+udNP
G1lQ/U1yhBJKVXEnConRQF21gBVZPfA9DBtiN3da5I4h3VR0EGfwLMYNPlHK
1oLJydqhWQiraK/TOi5sT6UilttuM77e2JclHefVZUk9e6ocn5qsHRogQQ+U
BTjb620zzN4nWzCRVBPtA//GAcN45Q53MMyr98/jQ5Bw6nN96TdN7BDHdoha
MzpOkuzBkfmrloyVfQVSStVSrlYujvkNqepg2LP/7rl/992/L92/BxYM9oaD
Vx1G9B7iYnfAj2xrneI3rbFZ4uiOhK/FIl8lc2T2VPRCNOTKKjcfmDy6MCOS
1rXI+YodTWORxcaP56grm9xgoA//L1R8ZOEOPqnMvH0kbcfmOLaxZY7ggai+
GA823RmInYtygiShBtJE6on1hoQB9tCczjytUi5bhw/HXistJqBiaawykUXJ
3cH7IZuV5cIcPnu2XC4HOOdA6emzGmTMM1z03UG/PhRZfzL4fVbO86drz/t7
Llr9GSGDnZCQLG3rH2clqJP4GcGaclEqr/gJ7r5u36SHz6+w4OhzobDb3pY9
sc5u8BX7vWAPRKdd/XC53VLzjKdCzyUrqvkY0W7BUypE6fLtgZVeio/eXX1M
ILMt57Fnp5mcUOJZxmdkVC5Ql3JEGW5dOlCilf1ABR42wlooWbRz5arAOuKR
LxcLZ+dSNwr+qIB578C5acCrisp1u6yI3vTTxhu3L+HfsubbdtgVFVvX9QeD
LYVcX68Ey86Sy+J2czrYcJy23LCAvhBkaTWPUSksFxFJ/M7xEBadWmUQOz58
+EeATLzpA2SRLTseH6W3hVrmIpsSJCTJL4ItqeY4l7cu6uBA5jnHAmgwXZAw
XlHoAYBqCE3Yzyr/g4i+gfW+E/O6EkTqcCfHn/jbKs9NR6FhaqoYWZv/lh0V
mRZL03N/gF3lubzj9h7COwXa+4cCZYGHpYyoAMTmWPHsiIgvPzmKnAkIp61G
5daMsAR2jNIBWU+xWoq+SDBhUlxgckzXf0dezrGd2zf9rDBq0V9kfVd1itpX
byC4ipz6mBxHJX74Si/gwDWowNsKa3xpaRiOwGCS+IFfAq+RGdjCVNOpsCWo
yKL6EgcoWH0xgrQADMxih9ImcZtffVt3ZzrV4XimAQN/1AAaQK+d8xdbr3ac
KwAPX3Dq1D8jm5kWZP3AntRP6CIW2gOm0jxkDzHCKYnn6MBdhRnz9JbAIVQo
UZQ6B6wtvYRP4cl7LEFyG5a+umnDKT0mGaoyUdETDumE4nSoOUF95eSmVatE
tVK2SOXOFp/mABWl8eofvCQsj9t3qHAppAZUshhIIO45DAUG+PqykMHRBAME
eghVqVSv7mvRAqbTEivTCDBKrAIjYb/hgG6efS0W9YcOQ7FQp1Hn5nGtFY41
qkLJLSxnErJNV2Fs63TNOqL11ir1aNpQPGaqsS/ccJkPDrcDWcmuS1JL38by
s5RzEY5HTYyFA0plDBnJ5hg8amxr9su40q/XtYKaehJUdPnC02tUB5bHFxnC
dZBMxGVLlHgAkfa6QbAF9A/ADVfETbgvWtVOlMpzq47tgshGtOA5TovnGaBo
iRXVNFOrxDHklq72tgGgzUK55j0ymrSua85XHXe2CHg1X6Jd26AhTBeUoaLS
xS3C62C9XTCW2WPWmuN1IWe8+NatpHlxwe45g0XrjF1BXrvaMiOYjTeZvTau
+GjCqj0WXto8tLGmJUesRp1sFAuDeDH48NoIoO5re/0C0dSDLaAibWFMC5/A
GeCdL0deYEZspM0LPVg0TX1C6NOyqa1zJ7+srXpcrRwURvcposWiKyP4cuE1
8gOGBm+bBhVscgftIaLJBj0G4TENPYMxHF8cnZ+6iuq94eshVnXbb8PnL/bx
20nU4uDg1R5gGqgs9fs2vEPPbiq9Qrcufi/7dN8avsB/3V2AyCq4dw0Q42K1
GNU/ppFKbGCFTTI8c62h2A2cuAoyZm4BGTPBJYZ0HrMbF1d8OF7bySC5pN2l
ToozBPxmCrzWBidFwy9Wc4UmtOFeiK8RxGAbIgjQZfscb9/46utqkfkLQGuV
yeCY7kmGEGTgZJtp8t4uvhf6WKCr9dXG3KYe9Z9CY4wZz+jQueVX18gnEbqN
nDABlqsimJOeW2GH8K5li5BE+XjBJZgwcSReUwdb9v5fZ/uQ5pWEcwvCOddR
myYerzPJiXCdURYmNMbID8MsXWIIY5BSE0rSXG4KWYTdT6rGDuaC+8vWkzYX
7Oaki41VXpIOzeR0BrE7hKPpym0FxfDecZszwvUX9+1y/xjYO31UbL7b0dEG
MaGiH72B1YGagc17L1uWHMcrHu2EjS0tg6MLrP5ag40Ittws2zG7tB8V68mg
ccj6QOf49hZmYBvctGlmxow0oN0MVnjZXESDLlyOw5AaZGV7F23JV+4CwXsE
Gn81rxmcndXgOmCXDpvknE/xfiZnP74/s/csJzx1KmyjMdPUBtwTUhle7kRD
BplNZC6inZUBO5qSFnQAr4XBgL/oLLDMuI9st9X47+srb2kXEgE7ovJ4WJMt
b44u2HuD9z2OT/11o8atxRq0o31G3riQ1urOczyhWEUxIc1vM5SIgLpHw9u3
eAgJKrJbtaaHB3c8tzctScHxvqqZycXDZZkUfE+1EN7K6g3/OOCGGVx4/agD
fHb0pQX+PZsXGFGiFOL737Fi060aumYUAm5Ub7ImFVl+fOkO2MHT1i2hyEUC
NJ77Uz2C0QgJ97cgob3qB99hLr8bGo8DQ9P2pxGBYWFXJUocBB5RgvQkAbcz
MPwzEwtBPwqDP2OAdFNLGLmrfmTd5Z661vHmXe0DtwWvN9ZMbF0Oyri1G7jl
iAOzmEmFGRBeiQDpoId3N+m2c8u2Co820gdsfauWIiTSOGr9Kw0+ooBAK8vF
p6zXuExB0jV/6e9x+CjPVMLl9dAA3Yk3/LBxQWZSaW1vtoUtm7OJW7K/cd6k
7BMW2gwfnSPZyMBwx5yOGLbJ13tMxKQe7Wy4q4b4DEBQ0BUjRMPtiOIY5zo7
tFT1ZX4kii5KNvxoHQHhKRT+yklDC5wzmyvwqRQSY0g4Bp4tZYbrm061Qwz6
gQfHDnlHu8Bc5rQl49boMlA12dDMMjh8xVap0IWrmUsRQBoJIae2Vf2LDa02
yAK61mh3zCx+6ugHDerbjVuCkCsNTldLd2URxYA5EC0Id35EgVIDOSnK91r8
xhtfBJM1YMVFC+FXDOhWNo0VmRNtnXbcIG4Gwo3rv81gpIa3R6nR8eZ8sQPo
6s2HUG1Yx62Yg/7iMb4ZIWwZp8eCqaFC/76gnFt1AErg5MbfW+iFuriIMXUi
r1oSMz68HTyW7hc2aR/ZRLLWFfcjDeE81MWSDSM88jAB/XdGp8e7zWt9eLm3
knm5YSi6eUi2DwlGaQ2nKUDcMreXzcFDA3aSwyb2NvDV+F/b+cu9DdCvaieM
SEIYXWR0ib+M33nNsO447KXhI/DUEk9csBCoI2nH4doa628QR5uan+wRehZB
QL+aatC6Hk1hVHRgj0z+P7AgM0x2TwAA

-->

</rfc>

