rfc9527xml2.original.xml   rfc9527.xml 
<?xml version="1.0" encoding="utf-8"?> <?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" [ <!DOCTYPE rfc [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <!ENTITY nbsp "&#160;">
nce.RFC.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere <!ENTITY nbhy "&#8209;">
nce.RFC.8174.xml"> <!ENTITY wj "&#8288;">
<!ENTITY I-D.ietf-homenet-front-end-naming-delegation SYSTEM "https://xml2rfc.to
ols.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-homenet-front-end-naming-dele
gation.xml">
<!ENTITY RFC8415 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8415.xml">
<!ENTITY RFC7858 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7858.xml">
<!ENTITY RFC9103 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.9103.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.8126.xml">
<!ENTITY RFC7368 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7368.xml">
<!ENTITY RFC7227 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.7227.xml">
<!ENTITY I-D.andrews-dnsop-pd-reverse SYSTEM "https://xml2rfc.tools.ietf.org/pub
lic/rfc/bibxml3/reference.I-D.andrews-dnsop-pd-reverse.xml">
<!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.2181.xml">
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.1034.xml">
<!ENTITY RFC6672 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6672.xml">
<!ENTITY I-D.sury-dnsext-cname-dname SYSTEM "https://xml2rfc.tools.ietf.org/publ
ic/rfc/bibxml3/reference.I-D.sury-dnsext-cname-dname.xml">
]> ]>
<?rfc rfcedstyle="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<?rfc toc="yes"?> -ietf-homenet-naming-architecture-dhc-options-24" number="9527" submissionType="
<?rfc tocindent="yes"?> IETF" category="std" consensus="true" obsoletes="" updates="" xml:lang="en" tocI
<?rfc sortrefs="yes"?> nclude="true" sortRefs="true" symRefs="true" version="3">
<?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-optio
ns-24" category="std">
<!-- xml2rfc v2v3 conversion 3.16.0 -->
<front> <front>
<title abbrev="DHCPv6 Options for HNA">DHCPv6 Options for Home Network Namin <title abbrev="DHCPv6 Options for the HNA">DHCPv6 Options for the Homenet Na
g Authority</title> ming Authority</title>
<seriesInfo name="RFC" value="9527"/>
<author initials="D." surname="Migault" fullname="Daniel Migault"> <author initials="D." surname="Migault" fullname="Daniel Migault">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street>8275 Trans Canada Route</street> <street>8275 Trans Canada Route</street>
<city>Saint Laurent, QC</city> <city>Saint Laurent</city>
<region>QC</region>
<code>4S 0B6</code> <code>4S 0B6</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>daniel.migault@ericsson.com</email> <email>daniel.migault@ericsson.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Weber" fullname="Ralf Weber"> <author initials="R." surname="Weber" fullname="Ralf Weber">
<organization>Akamai</organization> <organization>Akamai</organization>
<address> <address>
<email>ralf.weber@akamai.com</email> <email>ralf.weber@akamai.com</email>
</address> </address>
</author> </author>
<author initials="T." surname="Mrugalski" fullname="Tomek Mrugalski"> <author initials="T." surname="Mrugalski" fullname="Tomek Mrugalski">
<organization>Internet Systems Consortium, Inc.</organization> <organization abbrev="ISC">Internet Systems Consortium, Inc.</organization >
<address> <address>
<postal> <postal>
<street>950 Charter Street</street> <street>PO Box 360</street>
<city>Redwood City</city> <city>Newmarket</city>
<code>94063</code> <region>NH</region>
<country>US</country> <code>03857</code>
<country>United States of America</country>
</postal> </postal>
<email>tomasz.mrugalski@gmail.com</email> <email>tomasz.mrugalski@gmail.com</email>
</address> </address>
</author> </author>
<date year="2024" month="January"/>
<area>int</area>
<workgroup>homenet</workgroup>
<date year="2022" month="October" day="31"/> <abstract>
<t>This document defines DHCPv6 options so that a Homenet Naming Authority
<area>Internet</area> (HNA) can automatically set the appropriate configuration and outsource the aut
<workgroup>Homenet</workgroup> horitative naming service for the home network.
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document defines DHCPv6 options so a Homenet Naming Authority (HNA) can
automatically proceed to the appropriate configuration and outsource the authori
tative naming service for the home network.
In most cases, the outsourcing mechanism is transparent for the end user.</t> In most cases, the outsourcing mechanism is transparent for the end user.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="terminology" title="Terminology"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t><xref target="RFC9526" format="default"/> specifies how an entity desig
nated as the Homenet Naming Authority (HNA) outsources a Public Homenet Zone to
a DNS Outsourcing Infrastructure (DOI).</t>
<t>This document describes how a network can provision the HNA with a spec
ific 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 and t
he associated reverse zone to the home network.
The ISP is thus aware of the owner of that IP prefix and, as such, becomes a nat
ural candidate for hosting the Homenet Reverse Zone -- that is, the Reverse Dist
ribution Manager (RDM) and potentially the Reverse Public Authoritative Servers.
</t>
<t>In addition, ISPs often identify the line of the home network with a na
me.
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 infrastruc
ture and provide the home network with a specific domain name designated per a R
egistered Homenet Domain <xref target="RFC9526" format="default"/>.
Similarly to the reverse zone, ISPs are aware of who owns that domain name and m
ay become a natural candidate for hosting the Homenet Zone -- that is, the Distr
ibution Manager (DM) and the Public Authoritative Servers.</t>
<t>This document describes DHCPv6 options that enable an ISP to provide the nece
ssary parameters to the HNA to proceed. More specifically, the ISP provides the
Registered Homenet Domain and the necessary information on the DM and the RDM so
the HNA can manage and upload the Public Homenet Zone and the Reverse Public Ho
menet Zone as described in <xref target="RFC9526" format="default"/>.</t>
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL <t>The use of DHCPv6 options may make the configuration completely transpa
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, rent to the end user and provides a similar level of trust as the one used to pr
“MAY”, and “OPTIONAL” in this document are to be interpreted as ovide the IP prefix, when provisioned via DHCP.</t>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and </section>
only when, they <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8
174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<t>The reader should be familiar with <xref target="RFC9526" format="defau
<t>The reader should be familiar with <xref target="I-D.ietf-homenet-front-end-n lt"/>.</t>
aming-delegation"/>.</t> </section>
<section anchor="sec-overview" numbered="true" toc="default">
</section> <name>Procedure Overview</name>
<section anchor="introduction" title="Introduction"> <t>This section illustrates how an HNA receives the necessary information
via DHCPv6 options to outsource its authoritative naming service to the DOI. For
<t><xref target="I-D.ietf-homenet-front-end-naming-delegation"/> specifies how a the sake of simplicity, and similarly to <xref target="RFC9526" format="default
n entity designated as the Homenet Naming Authority (HNA) outsources a Public Ho "/>, this section assumes that the HNA and the home network DHCPv6 client are co
menet Zone to an DNS Outsourcing Infrastructure (DOI).</t> located on the Customer Premises Equipment (CPE) router <xref target="RFC7368"
format="default"/>. Also, note that this is not mandatory, and the DHCPv6 client
<t>This document describes how a network can provision the HNA with a specific D may remotely instruct the HNA with a protocol that will be standardized in the
OI. future.
This could be particularly useful for a DOI partly managed by an ISP, or to make In addition, this section assumes that the responsible entity for the DHCPv6 ser
home networks resilient to HNA replacement. ver is provisioned with the DM and RDM information, which is associated with the
The ISP delegates an IP prefix to the home network as well as the associated rev requested Registered Homenet Domain.
erse zone.
The ISP is thus aware of the owner of that IP prefix, and as such becomes a natu
ral candidate for hosting the Homenet Reverse Zone - that is the Reverse Distrib
ution Manager (RDM) and potentially the Reverse Public Authoritative Servers.</t
>
<t>In addition, ISPs often identify the line of the home network with a name.
Such name is used for their internal network management operations and is not a
name the home network owner has registered to.
ISPs may leverage such infrastructure and provide the home network with a specif
ic 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 m
ay become a natural candidate for hosting the Homenet Zone - that is the Distrib
ution Manager (DM) and the Public Authoritative Servers.</t>
<t>This document describes DHCPv6 options that enable an ISP to provide the nece
ssary parameters to the HNA, to proceed.
More specifically, the ISP provides the Registered Homenet Domain, necessary inf
ormation on the DM and the RDM so the HNA can manage and upload the Public Homen
et Zone and the Reverse Public Homenet Zone as described in <xref target="I-D.ie
tf-homenet-front-end-naming-delegation"/>.</t>
<t>The use of DHCPv6 options may make the configuration completely transparent t
o 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 DHC
Pv6 options to outsource its authoritative naming service to the DOI.
For the sake of simplicity, and similarly to <xref target="I-D.ietf-homenet-fron
t-end-naming-delegation"/>, this section assumes that the HNA and the home netwo
rk DHCPv6 client are colocated on the Customer Edge (CPE) router <xref target="
RFC7368"/>.
Note also that this is not mandatory and the DHCPv6 client may instruct remotely
the HNA with a protocol that will be standardized in the future.
In addition, this section assumes the responsible entity for the DHCPv6 server i
s provisioned with the DM and RDM information - associated with the requested Re
gistered Homenet Domain .
This means a Registered Homenet Domain can be associated with the DHCPv6 client. </t> This means a Registered Homenet Domain can be associated with the DHCPv6 client. </t>
<t>This scenario is believed to be the most popular scenario.
<t>This scenario is believed to be the most popular scenario.
This document does not ignore scenarios where the DHCPv6 server does not have pr ivileged relations with the DM or RDM. This document does not ignore scenarios where the DHCPv6 server does not have pr ivileged relations with the DM or RDM.
These cases are discussed in <xref target="sec-scenario"/>. These cases are discussed in <xref target="sec-scenario" format="default"/>.
Such scenarios do not necessarily require configuration for the end user and can Such scenarios do not necessarily require configuration for the end user and can
also be zero-config.</t> also be zero configuration.</t>
<t>The scenario considered in this section is as follows:</t>
<t>The scenario considered in this section is as follows:</t> <ol spacing="normal" type="1">
<li>The HNA is willing to outsource the Public Homenet Zone or Homenet Re
<t><list style="numbers"> verse Zone.
<t>The HNA is willing to outsource the Public Homenet Zone or Homenet Reverse The DHCPv6 client is configured to include in its Option Request Option (ORO) th
Zone. e Registered Homenet Domain Option (OPTION_REGISTERED_DOMAIN), the Forward Distr
The DHCPv6 client is configured to include in its Option Request Option (ORO) th ibution Manager Option (OPTION_FORWARD_DIST_MANAGER), and the Reverse Distributi
e Registered Homenet Domain Option (OPTION_REGISTERED_DOMAIN), the Forward Distr on Manager Option (OPTION_REVERSE_DIST_MANAGER) option codes.</li>
ibution Manager Option (OPTION_FORWARD_DIST_MANAGER) and the Reverse Distributio <li>The DHCPv6 server responds to the DHCPv6 client with the requested D
n Manager Option (OPTION_REVERSE_DIST_MANAGER) option codes.</t> HCPv6 options based on the identified homenet. The DHCPv6 client passes the info
<t>The DHCPv6 server responds to the DHCPv6 client with the requested DHCPv6 o rmation to the HNA.</li>
ptions based on the identified homenet. <li>The HNA is authenticated (see "Securing the Control Channel" (Sectio
The DHCPv6 client passes the information to the HNA.</t> n <xref target="RFC9526" sectionFormat="bare" section="6.6"/>) of <xref target="
<t>The HNA is authenticated (see Section “Securing the Control Channel” of <xr RFC9526" sectionFormat="bare" format="default"/>) by the DM and the RDM. The HNA
ef target="I-D.ietf-homenet-front-end-naming-delegation"/>) by the DM and the RD builds the Homenet Zone (or the Homenet Reverse Zone) and proceeds as described
M. in <xref target="RFC9526" format="default"/>. The DHCPv6 options provide the ne
The HNA builds the Homenet Zone (or the Homenet Reverse Zone) and proceed as des cessary non-optional parameters described in Appendix B of <xref target="RFC9526
cribed in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>. " format="default"/>.
The DHCPv6 options provide the necessary non optional parameters described in Ap
pendix B of <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>.
The HNA may complement the configurations with additional parameters via means n ot yet defined. The HNA may complement the configurations with additional parameters via means n ot yet defined.
Appendix B of <xref target="I-D.ietf-homenet-front-end-naming-delegation"/> desc Appendix B of <xref target="RFC9526" format="default"/> describes such parameter
ribes such parameters that may take some specific non default value.</t> s that may take some specific non-default value.</li>
</list></t> </ol>
</section>
</section> <section anchor="sec-format" numbered="true" toc="default">
<section anchor="sec-format" title="DHCPv6 Option"> <name>DHCPv6 Options</name>
<t>This section details the payload of the DHCPv6 options following the gu
<t>This section details the payload of the DHCPv6 options following the guidelin idelines of <xref target="RFC7227" format="default"/>.</t>
es of <xref target="RFC7227"/>.</t> <section anchor="o_rd" numbered="true" toc="default">
<name>Registered Homenet Domain Option</name>
<section anchor="o_rd" title="Registered Homenet Domain Option"> <t>The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the
fully qualified domain name (FQDN) associated with the home network.</t>
<t>The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the FQDN as <figure anchor="fig-rhd">
sociated with the home network.</t> <name>Registered Domain Option</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="Registered Domain Option" anchor="fig-rhd"><artwork><![CDATA[
0 1 2 3 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 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 | | OPTION_REGISTERED_DOMAIN | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Registered Homenet Domain / / Registered Homenet Domain /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t><list style="symbols"> <dl spacing="normal">
<t>option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code for the Re <dt>option-code (16 bits):</dt><dd>OPTION_REGISTERED_DOMAIN; the optio
gistered Homenet Domain (TBD1).</t> n code for the Registered Homenet Domain (145).</dd>
<t>option-len (16 bits): length in octets of the Registered Homenet Domain fie <dt>option-len (16 bits):</dt><dd>Length in octets of the Registered H
ld as described in <xref target="RFC8415"/>.</t> omenet Domain field as described in <xref target="RFC8415" format="default"/>.</
<t>Registered Homenet Domain (variable): the FQDN registered for the homenet e dd>
ncoded as described in Section 10 of <xref target="RFC8415"/>.</t> <dt>Registered Homenet Domain (variable):</dt><dd>The FQDN registered
</list></t> for the homenet encoded as described in <xref target="RFC8415" sectionFormat="of
" section ="10"/>.</dd>
</section> </dl>
<section anchor="o_dm" title="Forward Distribution Manager Option"> </section>
<section anchor="o_dm" numbered="true" toc="default">
<t>The Forward Distributed Manager Option (OPTION_FORWARD_DIST_MANAGER) provides <name>Forward Distribution Manager Option</name>
the HNA with the FQDN of the DM as well as the transport protocols for the comm <t>The Forward Distribution Manager Option (OPTION_FORWARD_DIST_MANAGER)
unication between the HNA and the DM. provides the HNA with the FQDN of the DM as well as the transport protocols for
As opposed to IP addresses, the FQDN requires a DNS resolution before establishi the communication between the HNA and the DM.
ng the communication between the HNA and the DM. As opposed to IP addresses, the FQDN requires a DNS resolution before establishi
However, the use of a FQDN provides multiple advantages over IP addresses. ng the communication between the HNA and the DM. However, the use of an FQDN pro
Firstly, it makes the DHCPv6 Option easier to parse and smaller - especially whe vides multiple advantages over IP addresses. Firstly, it makes the DHCPv6 option
n IPv4 and IPv6 addresses are expected to be provided. easier to parse and smaller, especially when IPv4 and IPv6 addresses are expect
Then the FQDN can reasonably be seen as a more stable identifier than IP address ed to be provided. Then, the FQDN can reasonably be seen as a more stable identi
es, as well as a pointer to additional information that may be useful, in the fu fier than IP addresses as well as a pointer to additional information that may b
ture, to establish the communication between the HNA and the DM.</t> e useful, in the future, to establish the communication between the HNA and the
DM.</t>
<figure title="Forward Distribution Manager Option" anchor="fig-dm"><artwork><![ <figure anchor="fig-dm">
CDATA[ <name>Forward Distribution Manager Option</name>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_FORWARD_DIST_MANAGER | option-len | | OPTION_FORWARD_DIST_MANAGER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Transport | | | Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Distribution Manager FQDN / / Distribution Manager FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure> ]]></artwork>
</figure>
<t><list style="symbols"> <dl spacing="normal">
<t>option-code (16 bits): OPTION_FORWARD_DIST_MANAGER, the option code for the <dt>option-code (16 bits):</dt><dd>OPTION_FORWARD_DIST_MANAGER; the op
Forward Distribution Manager Option (TBD2).</t> tion code for the Forward Distribution Manager Option (146).</dd>
<t>option-len (16 bits): length in octets of the enclosed data as described in <dt>option-len (16 bits):</dt><dd>Length in octets of the enclosed dat
<xref target="RFC8415"/>.</t> a as described in <xref target="RFC8415" format="default"/>.</dd>
<t>Supported Transport (16 bits): defines the supported transport by the DM (s <dt>Supported Transport (16 bits):</dt><dd>Defines the Supported Trans
ee <xref target="sec-st"/>). port by the DM (see <xref target="sec-st" format="default"/>).
Each bit represents a supported transport, and a DM MAY indicate the support of Each bit represents a supported transport, and a DM <bcp14>MAY</bcp14> indicate
multiple modes. the support of multiple modes.
The bit for DNS over mutually authenticated TLS (DomTLS) MUST be set.</t> The bit for DNS over mutually authenticated TLS (DomTLS) <bcp14>MUST</bcp14> be
<t>Distribution Manager FQDN (variable): the FQDN of the DM encoded as describ set.</dd>
ed in Section 10 of <xref target="RFC8415"/>.</t> <dt>Distribution Manager FQDN (variable):</dt><dd>The FQDN of the DM e
</list></t> ncoded as described in <xref target="RFC8415" sectionFormat="of" section="10"/>.
</dd>
<t>It is worth noticing that the DHCP Option specifies the Supported Transport </dl>
without specifying any explicit port. Unless the HNA and the DM have agreed on u <t>It is worth noting that the DHCPv6 option specifies the Supported Tra
sing a specific port - for example by configuration, or any out of band mechanis nsport without specifying any explicit port. Unless the HNA and the DM have agre
m -, the default port is used and must be specified. The specification of such d ed on using a specific port -- for example, by configuration, or any out-of-band
efault port may be defined in the specification of the designated Supported Tran mechanism -- the default port is used and must be specified. The specification
sport or in any other document. of such default port may be defined in the specification of the designated Suppo
In the case of DNS over mutually authenticated TLS (DomTLS), the default port va rted Transport or in any other document. In the case of DomTLS, the default port
lue is 853 as per DNS over TLS <xref target="RFC7858"/> and DNS Zone Transfer o value is 853 per DNS over TLS <xref target="RFC7858" format="default"/> and DNS
ver TLS <xref target="RFC9103"/>.</t> Zone Transfer over TLS <xref target="RFC9103" format="default"/>.</t>
<t>The need to associate the port value to each Supported Transport in t
<t>The need to associate in the DHCP Option the port value to each Supported Tra he DHCPv6 option has been balanced with the difficulty of handling a list of tup
nsport has been balanced with the difficulty of handling a list of tuples ( tran les (transport, port) and the possibility of using a dedicated IP address for th
sport, port ) as well as the possibility to use a dedicated IP address for the D e DM in case the default port is already in use.</t>
M in case the default port was already in use.</t> </section>
<section anchor="reverse-distribution-manager-server-option" numbered="tru
</section> e" toc="default">
<section anchor="reverse-distribution-manager-server-option" title="Reverse Dist <name>Reverse Distribution Manager Server Option</name>
ribution 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
<t>The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) provide the communication between the HNA and the DM.</t>
s the HNA with the FQDN of the DM as well as the transport protocols for the com <figure anchor="fig-rdm">
munication between the HNA and the DM.</t> <name>Reverse Distribution Manager Option</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="Reverse Distribution Manager Option" anchor="fig-rdm"><artwork><! 0 1 2 3
[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 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 | | OPTION_REVERSE_DIST_MANAGER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Transport | | | Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Reverse Distribution Manager FQDN / / Reverse Distribution Manager FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<dl spacing="normal">
<dt>option-code (16 bits):</dt><dd>OPTION_REVERSE_DIST_MANAGER; the op
tion code for the Reverse Distribution Manager Option (147).</dd>
<dt>option-len (16 bits):</dt><dd>Length in octets of the option-data
field as described in <xref target="RFC8415" format="default"/>.</dd>
<dt>Supported Transport (16 bits):</dt><dd>Defines the Supported Trans
port by the RDM (see <xref target="sec-st" format="default"/>). Each bit represe
nts a supported transport, and an RDM <bcp14>MAY</bcp14> indicate the support of
multiple modes.
The bit for DomTLS <xref target="RFC7858" format="default"/> <bcp14>MUS
T</bcp14> be set.</dd>
<dt>Reverse Distribution Manager FQDN (variable):</dt><dd>The FQDN of
the RDM encoded as described in <xref target="RFC8415" sectionFormat="of" sectio
n="10"/>.</dd>
</dl>
<t>For the port number associated to the Supported Transport, the same c
onsiderations as described in <xref target="o_dm" format="default"/> apply.</t>
</section>
<section anchor="sec-st" numbered="true" toc="default">
<name>Supported Transport</name>
<t>The Supported Transport field of the DHCPv6 option indicates the Supp
orted Transport protocols. Each bit represents a specific transport mechanism. A
bit set to 1 indicates the associated transport protocol is supported. The corr
esponding bits are assigned as described in <xref target="tab-iana" format="defa
ult"/>.</t>
<dl spacing="normal">
<dt> DNS over mutually authenticated TLS (DomTLS):</dt><dd> Indicates the s
upport of DNS over TLS <xref target="RFC7858" format="default"/> and DNS Zone Tr
ansfer over TLS <xref target="RFC9103" format="default"/> as described in <xref
target="RFC9526" format="default"/>.</dd>
</dl>
]]></artwork></figure> <t>As an example, the Supported Transport field expressing support for
DomTLS looks as follows and has a numeric value of 0x0001:</t>
<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 describe
d 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 mutually authenticated TLS <xref target="RFC7858"/> MUST be
set.</t>
<t>Reverse Distribution Manager FQDN (variable): the FQDN of the RDM encoded a
s described in section 10 of <xref target="RFC8415"/>.</t>
</list></t>
<t>For the port number associated to the Supported Transport, the same considera
tions as described in <xref target="o_dm"/> holds.</t>
</section>
<section anchor="sec-st" title="Supported Transport">
<t>The Supported Transport field of the DHCPv6 option indicates the supported tr
ansport 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 | Mnemonic | Reference
left to right| Description | |
0 | DNS over mutually | DomTLS | This-RFC
| authenticated TLS | |
1-15 | unallocated | - | -
]]></artwork></figure>
<t>DNS over mutually authenticated TLS (DomTLS): indicates the support of DNS o
ver TLS <xref target="RFC7858"/>, DNS Zone Transfer over TLS <xref target="RFC9
103"/> as described in <xref target="I-D.ietf-homenet-front-end-naming-delegatio
n"/>.</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
regarding option assignment.
As a convenience to the reader, we mention here that the server will send option
foo only if configured with specific values for foo and if the client requested
it.
In particular, when configured the DHCPv6 server sends the Registered Homenet Do
main Option, Distribution Manager Option, the Reverse Distribution Manager Optio
n 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 Man
ager Option, the Reverse Distribution Manager Option in an ORO as specified in S
ections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of <xref target="RFC841
5"/>.</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-f
ront-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">
<section anchor="dhcpv6-option-codes" title="DHCPv6 Option Codes">
<t>IANA is requested to assign the following new DHCPv6 Option Codes in the regi
stry maintained in: https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-pa
rameters.xhtml#dhcpv6-parameters-2.</t>
<figure><artwork><![CDATA[
Value Description Client ORO Singleton Option Reference
TBD1 OPTION_REGISTERED_DOMAIN Yes No [This-RFC]
Section 4.1
TBD2 OPTION_FORWARD_DIST_MANAGER Yes Yes [This-RFC]
Section 4.2
TBD3 OPTION_REVERSE_DIST_MANAGER Yes Yes [This-RFC]
Section 4.3
]]></artwork></figure>
</section>
<section anchor="supported-transport-parameter" title="Supported Transport param
eter">
<t>IANA is requested to maintain a new registry of Supported Transport parameter
in the Distributed Manager Option (OPTION_FORWARD_DIST_MANAGER) or the Reverse
Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The different paramet
ers are defined in <xref target="tab-st"/> in <xref target="sec-st"/>.</t>
<t>The Name of the registry is: Supported Transport parameter</t>
<t>The registry description is: The Supported Transport field of the DHCPv6 opt
ion is a two octet field that indicates the supported transport protocols.
Each bit represents a specific transport mechanism.</t>
<t>The parent grouping is Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
at https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dh
cpv6-parameters-2.</t>
<t>New entry MUST specify the bit position, the Transport Protocol Description a
Mnemonic and a Reference as defined in <xref target="tab-iana"/>.</t>
<t>The initial registry is as specified in <xref target="tab-iana"/>.</t>
<t>Changes of the format or policies of the registry is left to the IETF via th
e IESG.</t>
<t>Future code points are assigned under RFC Required as per <xref target="RFC81
26"/>.</t>
<figure title="Supported Transport" anchor="tab-iana"><artwork><![CDATA[
Bit Position | Transport Protocol | Mnemonic | Reference
left to right| Description | |
0 | DNS over mutually | DomTLS | This-RFC
| authenticated TLS | |
1-15 | unallocated | - | -
]]></artwork></figure>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>The security considerations in <xref target="RFC8415"/> are to be considered.
The trust associated with the information carried by the DHCPv6 Options describe
d in this document is similar to the one associated with the IP prefix - when co
nfigured via DHCPv6.</t>
<t>In some cases, the ISP MAY identify the HNA by its wire line, that is to say
physically which may not require to rely on TLS to authenticate the HNA.
As TLS is mandatory to be used, it is expected the HNA is provisioned with a cer
tificate.
In some cases, the HNA may use a self signed certificate.</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 fo
r their remarks on the architecture design. The designed solution has been large
ly been inspired by Mark Andrews’s document <xref target="I-D.andrews-dnsop-pd-r
everse"/> as well as discussions with Mark.
We also thank Ray Hunter and Michael Richardson for its reviews, its comments an
d 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 p
rovided a significant contribution in the early versions of the document.</t>
</section> <artwork name="" type="" align="left" alt=""><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| must be zero |1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</section>
</section>
<section anchor="sec-dhcp-behavior" numbered="true" toc="default">
<name>DHCPv6 Behavior</name>
<section anchor="dhcpv6-server-behavior" numbered="true" toc="default">
<name>DHCPv6 Server Behavior</name>
<t><xref target="RFC8415" sectionFormat="of" section="18.3"/> governs se
rver operation regarding option assignment. As a convenience to the reader, we m
ention here that the server will send option foo only if configured with specifi
c values for foo and if the client requested it.
In particular, when configured, the DHCPv6 server sends the Registered Homenet D
omain Option, Distribution Manager Option, and Reverse Distribution Manager Opti
on when requested by the DHCPv6 client by including necessary option codes in it
s ORO.</t>
</section>
<section anchor="dhcpv6-client-behavior" numbered="true" toc="default">
<name>DHCPv6 Client Behavior</name>
<t>The DHCPv6 client includes the Registered Homenet Domain Option, Dist
ribution Manager Option, and Reverse Distribution Manager Option in an ORO as sp
ecified in Sections <xref target="RFC8415" sectionFormat="bare" section="18.2"/>
and <xref target="RFC8415" sectionFormat="bare" section="21.7"/> of <xref targe
t="RFC8415" format="default"/>.</t>
<t>Upon receiving a DHCPv6 option, as described in this document, in the
Reply
message, the HNA <bcp14>SHOULD</bcp14> proceed as described in <xref target="RFC
9526" format="default"/>.</t>
</section>
<section anchor="sec-dhcp-relay" numbered="true" toc="default">
<name>DHCPv6 Relay Agent Behavior</name>
<t>There are no additional requirements for the DHCPv6 Relay agents.</t>
</section>
</section>
<section anchor="sec-iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="dhcpv6-option-codes" numbered="true" toc="default">
<name>DHCPv6 Option Codes</name>
<t>IANA has assigned the following new DHCPv6 Option Codes in the "Optio
n Codes" registry maintained at <eref target="https://www.iana.org/assignments/d
hcpv6-parameters" brackets="angle"/>.</t>
<table anchor="tab-2">
<name>Option Codes Registry</name>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Client ORO</th>
<th>Singleton Option</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>145</td>
<td>OPTION_REGISTERED_DOMAIN</td>
<td>Yes</td>
<td>No</td>
<td>RFC 9527, Section 4.1</td>
</tr>
<tr>
<td>146</td>
<td>OPTION_FORWARD_DIST_MANAGER</td>
<td>Yes</td>
<td>Yes</td>
<td>RFC 9527, Section 4.2</td>
</tr>
<tr>
<td>147</td>
<td>OPTION_REVERSE_DIST_MANAGER</td>
<td>Yes</td>
<td>Yes</td>
<td>RFC 9527, Section 4.3</td>
</tr>
</tbody>
</table>
</section>
<section anchor="supported-transport-parameter" numbered="true" toc="defau
lt">
<name>Supported Transport parameter</name>
<t>IANA has created and maintains a new registry called "Supported Trans
port" under the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry
at <eref target="https://www.iana.org/assignments/dhcpv6-parameters" brackets="
angle"/>. This registry contains Supported Transport parameters in the Distribut
ed Manager Option (OPTION_FORWARD_DIST_MANAGER) or the Reverse Distribution Mana
ger Option (OPTION_REVERSE_DIST_MANAGER). The different parameters are defined i
n <xref target="tab-iana" format="default"/> (<xref target="supported-transport-
parameter" format="default"/>).</t>
<t>The Supported Transport field of the DHCPv6 option is a two-octet fie
ld that indicates the Supported Transport protocols. Each bit represents a speci
fic transport mechanism.</t>
<t>New entries <bcp14>MUST</bcp14> specify the bit position, the transpo
rt protocol description, a mnemonic, and a reference as shown in <xref target="t
ab-iana" format="default"/>.</t>
<t>Changes to the format or policies of the registry are managed by the
IETF via the IESG.</t>
<t>Future code points are assigned under RFC Required per <xref target="
RFC8126" format="default"/>. The initial registry is as specified in <xref targe
t="tab-iana" format="default"/> below.</t>
<table anchor="tab-iana">
<name>Supported Transport Registry</name>
<thead>
<tr>
<th>Bit Position (least to most significant)</th>
<th>Transport Protocol Description</th>
<th>Mnemonic</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>DNS over mutually authenticated TLS</td>
<td>DomTLS</td>
<td>RFC 9527</td>
</tr>
<tr>
<td>1-15</td>
<td>Unassigned</td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name>
<t>The security considerations in <xref target="RFC8415" format="default"/
> are to be considered.
The trust associated with the information carried by the DHCPv6 options describe
d in this document is similar to the one associated with the IP prefix, when con
figured via DHCPv6.</t>
<t>In some cases, the ISP <bcp14>MAY</bcp14> identify the HNA by its wire
line (i.e., physically), which may not require relying on TLS to authenticate th
e HNA. As the use of TLS is mandatory, it is expected that the HNA will be provi
sioned with a certificate.
In some cases, the HNA may use a self-signed certificate.</t>
</section>
</middle> </middle>
<back> <back>
<references title='Normative References'> <displayreference target="I-D.andrews-dnsop-pd-reverse" to="PD-REVERSE"/>
<displayreference target="I-D.sury-dnsop-cname-plus-dname" to="CNAME-PLUS-DNAME"
/>
&RFC2119; <references>
&RFC8174; <name>References</name>
&I-D.ietf-homenet-front-end-naming-delegation; <references>
&RFC8415; <name>Normative References</name>
&RFC7858; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC9103; 119.xml"/>
&RFC8126; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references> <!-- draft-ietf-homenet-front-end-naming-delegation-27
companion document in AUTH48 as 9526 - checked title (no changes)-->
<reference anchor="RFC9526" target="https://www.rfc-editor.org/info/rfc9526">
<front>
<title>Simple Provisioning of Public Names for Residential Networks</title>
<author initials='D' surname='Migault' fullname='Daniel Migault'>
<organization />
</author>
<author initials='R' surname='Weber' fullname='Ralf Weber'>
<organization />
</author>
<author initials='M' surname='Richardson' fullname='Michael Richardson'>
<organization />
</author>
<author initials='R' surname='Hunter' fullname='Ray Hunter'>
<organization />
</author>
<date year='2024' month='January' />
</front>
<seriesInfo name="RFC" value="9526"/>
<seriesInfo name="DOI" value="10.17487/RFC9526"/>
</reference>
<references title='Informative References'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
415.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
858.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
103.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
368.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
227.xml"/>
&RFC7368; <!-- [I-D.andrews-dnsop-pd-reverse] IESG state Expired as of 01/22/24. En
&RFC7227; tered the long way to get the right intials and date -->
&I-D.andrews-dnsop-pd-reverse; <reference anchor="I-D.andrews-dnsop-pd-reverse" target="https://datatracker.iet
&RFC2181; f.org/doc/html/draft-andrews-dnsop-pd-reverse-02">
&RFC1034; <front>
&RFC6672; <title>Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation
&I-D.sury-dnsext-cname-dname; </title>
<author fullname="Mark P. Andrews" initials="M." surname="Andrews">
<organization>ISC</organization>
</author>
<date day="5" month="November" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-andrews-dnsop-pd-reverse-02"/>
</reference>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
181.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
034.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
672.xml"/>
<section anchor="sec-scenario" title="Scenarios and impact on the End User"> <!-- [I-D.sury-dnsext-cname-dname] Replaced by [I-D.sury-dnsop-cname-plus-dname]
IESG state Expired, as of 01/22/24-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.sury-dnsop-cname-plus-dname.xml"/>
<t>This appendix details various scenarios and discuss their impact on the end u </references>
ser. </references>
<section anchor="sec-scenario" numbered="true" toc="default">
<name>Scenarios and Impact on the End User</name>
<t>This appendix details various scenarios and discusses their impact on t
he end user.
This appendix is not normative and limits the description of a limited scope of scenarios that are assumed to be representative. Many other scenarios may be der ived from these.</t> This appendix is not normative and limits the description of a limited scope of scenarios that are assumed to be representative. Many other scenarios may be der ived from these.</t>
<section anchor="sec-scenario-1" numbered="true" toc="default">
<section anchor="sec-scenario-1" title="Base Scenario"> <name>Base Scenario</name>
<t>The base scenario, as described in <xref target="sec-overview" format
<t>The base scenario is the one described in <xref target="sec-overview"/> in wh ="default"/>, is one in which an ISP manages the DHCPv6 server, DM, and RDM.</t>
ich an ISP manages the DHCPv6 server, the DM and RDM.</t> <t>The end user subscribes to the ISP (foo), and at subscription time, i
t registers foo.example as its Registered Homenet Domain.</t>
<t>The end user subscribes to the ISP (foo), and at subscription time registers <t>In this scenario, the DHCPv6 server, DM, and RDM are managed by the I
for foo.example as its Registered Homenet Domain foo.example.</t> SP, so the DHCPv6 server and such can provide authentication credentials of the
HNA to enable secure authenticated transaction with the DM and the Reverse DM.</
<t>In this scenario, the DHCPv6 server, DM and RDM are managed by the ISP so the t>
DHCPv6 server and as such can provide authentication credentials of the HNA to <t>The main advantage of this scenario is that the naming architecture i
enable secure authenticated transaction with the DM and the Reverse DM.</t> s 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
<t>The main advantage of this scenario is that the naming architecture is config it relies on the ISP naming infrastructure.</t>
ured automatically and transparently for the end user. </section>
The drawbacks are that the end user uses a Registered Homenet Domain managed by <section anchor="scenario-2" numbered="true" toc="default">
the ISP and that it relies on the ISP naming infrastructure.</t> <name>Third-Party Registered Homenet Domain</name>
<t>This appendix considers the case where the end user wants its home ne
</section> twork to use example.com but does not want it to be managed by the ISP (foo) as
<section anchor="scenario-2" title="Third Party Registered Homenet Domain"> a Registered Homenet Domain, and the ISP manages the home network and still prov
ides foo.example as a Registered Homenet Domain.</t>
<t>This appendix considers the case when the end user wants its home network to <t>When the end user buys the domain name example.com, it may request to
use example.com not managed by her ISP (foo) as a Registered Homenet Domain. redirect example.com to foo.example using static redirection with CNAME <xref t
This appendix still considers the ISP manages the home network and still provide arget="RFC1034" format="default"/> <xref target="RFC2181" format="default"/>, DN
s foo.example as a Registered Homenet Domain.</t> AME <xref target="RFC6672" format="default"/>, or CNAME+DNAME <xref target="I-D.
sury-dnsop-cname-plus-dname" format="default"/>.
<t>When the end user buys the domain name example.com, it may request to redirec The only information the end user needs to know is the domain name assigned by t
t the name example.com to foo.example using static redirection with CNAME <xref he ISP. Once the redirection has been configured, the HNA may be changed, and th
target="RFC2181"/>, <xref target="RFC1034"/>, DNAME <xref target="RFC6672"/> or e zone can be updated as described in <xref target="sec-scenario-1" format="defa
CNAME+DNAME <xref target="I-D.sury-dnsext-cname-dname"/>. ult"/> without any additional configuration from the end user.</t>
The only information the end user needs to know is the domain name assigned by t <t>The main advantage of this scenario is that the end user benefits fro
he ISP. m the zero configuration of the base scenario in <xref target="sec-scenario-1" f
Once the redirection has been configured, the HNA may be changed, the zone can b ormat="default"/>. Then, the end user is able to register an unlimited number of
e updated as in <xref target="sec-scenario-1"/> without any additional configura domain names provided by an unlimited number of different third-party providers
tion from the end user.</t> for its home network. The drawback of this scenario may be that the end user st
ill needs to rely on the ISP naming infrastructure. Note that this may be inconv
<t>The main advantage of this scenario is that the end user benefits from the Ze enient in the case where the DNS servers provided by the ISPs result in high lat
ro Configuration of the Base Scenario <xref target="sec-scenario-1"/>. ency.</t>
Then, the end user is able to register for its home network an unlimited number </section>
of domain names provided by an unlimited number of different third party provide <section anchor="scenario-3" numbered="true" toc="default">
rs. <name>Third-Party DNS Infrastructure</name>
The drawback of this scenario may be that the end user still rely on the ISP nam <t>This scenario involves the end user using example.com as a Registered
ing infrastructure. Homenet Domain and not relying on the authoritative servers provided by the ISP
Note that the only case this may be inconvenient is when the DNS servers provide .</t>
d by the ISPs results in high latency.</t> <t>In this appendix, we limit the outsourcing of the DM and Public Autho
ritative Server(s) to a third party. The Reverse Public Authoritative Server(s)
</section> and the RDM remain managed by the ISP as the IP prefix is managed by the ISP.</t
<section anchor="scenario-3" title="Third Party DNS Infrastructure"> >
<t>Outsourcing to a third-party DM can be performed in the following way
<t>This scenario considers that the end user uses example.com as a Registered Ho s:</t>
menet Domain, and does not want to rely on the authoritative servers provided by <ol spacing="normal" type="1">
the ISP.</t> <li>Updating the DHCPv6 server information. One can imagine a GUI inter
face that enables the end user to modify its profile parameters. Again, this con
<t>In this appendix we limit the outsourcing to the DM and Public Authoritative figuration update only needs to be performed one time.</li>
Server(s) to a third party. <li>Uploading the configuration of the DM to the HNA. In some cases, t
The Reverse Public Authoritative Server(s) and the RDM remain managed by the ISP he provider of the CPE router hosting the HNA may be the registrar, and the regi
as the IP prefix is managed by the ISP.</t> strar may provide the CPE router already configured. In other cases, the CPE rou
ter may request the end user to log into the registrar to validate the ownership
<t>Outsourcing to a third party DM can be performed in the following ways:</t> of the Registered Homenet Domain and agree on the necessary credentials to secu
re the communication between the HNA and the DM. As described in <xref target="R
<t><list style="numbers"> FC9526" format="default"/>, such settings could be performed in an almost automa
<t>Updating the DHCPv6 server Information. One can imagine a GUI interface tha tic way as to limit the necessary interactions with the end user.</li>
t enables the end user to modify its profile parameters. Again, this configurati </ol>
on update is done once-for-ever.</t> </section>
<t>Upload the configuration of the DM to the HNA. In some cases, the provider <section anchor="scenario-4" numbered="true" toc="default">
of the CPE router hosting the HNA may be the registrar and provide the CPE route <name>Multiple ISPs</name>
r already configured. In other cases, the CPE router may request the end user to <t>This scenario involves an HNA connected to multiple ISPs.</t>
log into the registrar to validate the ownership of the Registered Homenet Doma <t>Suppose the HNA has configured each of its interfaces independently w
in and agree on the necessary credentials to secure the communication between th ith each ISP as described in <xref target="sec-scenario-1" format="default"/>.
e HNA and the DM. As described in <xref target="I-D.ietf-homenet-front-end-namin
g-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> Each ISP provides a different Registered Homenet Domain.</t>
<t>The protocol and DHCPv6 options described in this document are fully
<t>The protocol and DHCPv6 options described in this document are fully compatib compatible with an HNA connected to multiple ISPs with multiple Registered Homen
le with a HNA connected to multiple ISPs with multiple Registered Homenet Domain et Domains.
s.
However, the HNA should be able to handle different 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 docume This is an implementation issue, which is outside the scope of this document.</t
nt.</t> >
<t>If an HNA is not able to handle multiple Registered Homenet Domains,
<t>If a HNA is not able to handle multiple Registered Homenet Domains, the HNA m the HNA may remain connected to multiple ISPs with a single Registered Homenet D
ay remain connected to multiple ISP with a single Registered Homenet Domain. omain. In this case, one entity is chosen to host the Registered Homenet Domain.
In this case, one entity is chosen to host the Registered Homenet Domain. This entity may be an ISP or a third party.
This entity may be one of the ISP or a third party. Note that having multiple ISPs can be motivation for bandwidth aggregation or co
Note that having multiple ISPs can be motivated for bandwidth aggregation, or co nnectivity failover.
nnectivity fail-over. In the case of connectivity failover, the failover concerns the access network,
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 a failure of the access network may not impact the core network where the D and Public Authoritative Primaries are hosted. In that sense, choosing one of t
M and Public Authoritative Primaries are hosted. he ISPs even in a scenario of multiple ISPs may make sense.
In that sense, choosing one of the ISP even in a scenario of multiple ISPs may m However, for the sake of simplicity, this scenario assumes that a third party ha
ake sense. s been chosen to host the Registered Homenet Domain. Configuration is performed
However, for sake of simplicity, this scenario assumes that a third party has be as described in Appendices <xref target="scenario-2" format="counter"/> and <xre
en chosen to host the Registered Homenet Domain. f target="scenario-3" format="counter"/>.</t>
Configuration is performed as described in <xref target="scenario-2"/> and <xref <t>With the configuration described in <xref target="scenario-2" format=
target="scenario-3"/>.</t> "default"/>, the HNA is expected to be able to handle multiple Registered Homene
t Domains as the third-party redirect to one of the ISP's servers. With the conf
<t>With the configuration described in <xref target="scenario-2"/>, the HNA is iguration described in <xref target="scenario-3" format="default"/>, DNS zones a
expected to be able to handle multiple Homenet Registered Domain, as the third p re hosted and maintained by the third party. A single DNS(SEC) Homenet Zone is b
arty redirect to one of the ISPs servers. uilt and maintained by the HNA. This latter configuration is likely to match mos
With the configuration described in <xref target="scenario-3"/>, DNS zone are ho t HNA implementations.</t>
sted and maintained by the third party. <t>The protocol and DHCPv6 options described in this document are fully
A single DNS(SEC) Homenet Zone is built and maintained by the HNA. compatible with an HNA connected to multiple ISPs. Whether to configure the HNA
This latter configuration is likely to match most HNA implementations.</t> or not, and how to configure the HNA, depends on the HNA facilities. Appendices
<xref target="sec-scenario-1" format="counter"/> and <xref target="scenario-2" f
<t>The protocol and DHCPv6 options described in this document are fully compatib ormat="counter"/> require the HNA to handle multiple Registered Homenet Domains,
le with a HNA connected to multiple ISPs. whereas <xref target="scenario-3" format="default"/> does not have such a requi
To configure or not and how to configure the HNA depends on the HNA facilities. rement.</t>
<xref target="sec-scenario-1"/> and <xref target="scenario-2"/> require the HNA </section>
to handle multiple Registered Homenet Domain, whereas <xref target="scenario-3" <section anchor="acknowledgments" numbered="false" toc="default">
/> does not have such requirement.</t> <name>Acknowledgments</name>
<t>We would like to thank <contact fullname="Marcin Siodelski"/>, <contact
</section> fullname="Bernie Volz"/>, and <contact fullname="Ted Lemon"/> for their comment
</section> s on the design of the DHCPv6 options. We would also like to thank <contact full
name="Mark Andrews"/>, <contact fullname="Andrew Sullivan"/>, and <contact fulln
ame="Lorenzo Colliti"/> for their remarks on the architecture design. The design
ed solution has been largely inspired by <contact fullname="Mark Andrews's"/> do
cument <xref target="I-D.andrews-dnsop-pd-reverse" format="default"/> as well as
discussions with <contact fullname="Mark"/>. We also thank <contact fullname="R
ay Hunter"/> and <contact fullname="Michael Richardson"/> for their reviews and
comments and for suggesting appropriate terminology.</t>
</section>
<section anchor="contributors" numbered="false" toc="default">
<name>Contributors</name>
<t>The coauthors would like to thank <contact fullname="Chris Griffiths"/>
and <contact fullname="Wouter Cloetens"/> for providing significant contributio
ns to the early draft versions of this document.</t>
</section>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAILrX2MAA+0823Ibt5Lv/Aqs/bBSQtKW5KuqtnJkSYlVZV1CyXHlbG2l
wBmQRHk4wzOYEUNf8i37Lftl2xcAAwxHlGQ7Z1Nbh6lY5FyARt+70Y3BYNDr
VbrK1L44en14cf1MnC8qXeRGTIpSvC7mSpypalmU78WZnOt8Kg7qalaUulr1
5HhcquvuF88OemmR5HIOA6elnFQDrarJYAYD5qoa5DTWQJbJTFcqqepSDdJZ
Mih4jMHuk55elPuiKmtT7T5+/PLxbk+WSu6Lk7xSJQzRW073CT78/n7Z3Bgc
4XS9RFb7wlRpLylSmGpf1DD9i15vofd7QpSTRKWmWuG6V8rAlapIgq86T1Ve
uQumKKtSTYz/vZpHP6tSJ/7hpJgDUJW/q/NM534aQMpcLhYEEV7pSUInwoSf
gf2Lr8EIR0Nxqqeyzip/nVF6JHOtsrWbRQnDHgM0xhS5vwrwKQXwvdh9/lRc
lRJodChzmUoxKupK+ecSIOq+uJQ6r8QbCSTJq774+bC5X6Qw9ZNL8fjVs+Bi
nVclvMdD+utqLnUGtCdAh3MG9G/KwjYELHUveTQU79RYla0Fj2Q2ad2gxR68
lzBRe6nxkuIFrEHeBrmEqYZLnOpvkka/GdgroE9ZT2Vm3usWwFfAmu877hLU
jlfF5cpUag70AKYHJtP1vA83k+Ea7V4+fSwOZ7KE98QlXWuRbaTSZVGk4hAl
M6bYyyePn+2tE+ztZXvlVTGX5sNw7oD+2xSv0/J7vcFgIOQY4JFJ1etdzbRB
Zq6R10WqJsDjxmkCK8UgN0I6GV1TH2ILlMS2SGQuQAZg5konMstWYlEWiVIp
QCOqmRIgLWWxKLWsFMCeT/S0LiWOL2SeCmBgU9RlovhZOzjcv1aClYwwqrzW
8ADqJXwIdZDIWakNeye5mBemAjiMMn16wI2JL89VMgMWNnMB661QdhYSBcOP
pgCIGqYYMobmOk0zBeh6KK5UCfMXWTFdIb6UeK9WAiZNjXhw+vby6kGf/4qz
c/o+Ov757cno+Ai/X74+ePPGf+nZJy5fn799c9R8a948PD89PT474pfhqogu
9R6cHvwKdxBhD84vrk7Ozw7ePAAWhhWEZISVIdbHCm4Boy1KVQEdpOmlyiSl
HsMPeOfV4cX//PfOE/Hx47+Nfjzc3dl5+fmz/fFi5/kT+LGcqZxnK3IgKP8E
ZIHJWCyULHEUIDXgfAG0ygDtEphlVixzMVOlAlQSvkDfp8DucKPOUoRqAgTN
NLy/1NUMpzwZHA0juzIpi7waAE2chUlVpqbELp8/D5EqIHplkdYJXur17j2G
MAuV6IkGZgd4YY3AABVyM6BIT3PJCCPOuIXxPecaEJKLepzpxL/y9yInSsDw
R2eX4jxgyJN8UkqQwpqMptg6Oj/ZHq7LI9PLAum4nYQNpOlaG5QfAvLsgLEp
3coSAUMOecDEYR6YHsSzzmQJ9AR2n9QZSYDEh+kuXJ+DBZjC+scrBPzk8qIv
UEgKuPE+FjsDtDVASoQV7iMQpVpkMlEI/lAQ+WEAYVGPOIIRLwB40DS/O9UQ
DolYXypgKot9CWYm0UQPcFJUaZT4AFgd+qFRnmc1DLxEti8mLPrLHDiOfsiq
mZCZGZm0TmaAD9CIRDagNygjZOQ81SlqKETKDPQJkipkgpGFgSg74OE1Q+pu
HWl0JMY16bZTwmUptkZHp9s0+6KokNVIRYavWdY5iFTfJeg8uAuMAfpNpqnG
Qfu4bgOrg4GERgdHT3gs9FAcCiKkWtZAkwZUucTV43cEHbggdVpQl6wxcsCF
e5W5gdixWChW2YZWAi/nRWWHXZ+TaTCTyCRTwAloBDQGoKoR+rlciQyXDoMz
OXQsEYQr5PG0Y+w2q6dgd0AZESCxBAPI99cwgbkbNbAf0STD3qUG9UUSZPk3
ZExLHORFz5HLWYHYMMwuIay4SMQEs+K9OLGDA7s5zzEePnELk92kfVr+AM2p
cjnOlNUQiImQWLkCfWhkuUKdAgsFBBqHLdASffs8+gfD3mkBaHKkRLlg843D
2jGdgHlSOCQwSfrBfMBFRTlnx8LqxqNTv36QQvRmnMZEPcr8TU/Ui6yQEaIi
ZPtBYomNnzEiMrJfYtxQs4FUIue0EI+sQkoYwYidKOCfRQZ4Rq4M3BuLc+fd
hFKFis8wK5MkZqQ5MFBzuhcXROqhRd1GgQ/IKWhsETx7rSWBPSTn6QKJnKI8
n1+j/6aW4uNDoyBCtD8/W66Da7QOnWU1OqeVN3psVRIFrGpazBUS280b8mkR
+JW6Mpv9Sosqspo/Wq/QILIBLYCnBdAarD6bEBOqgHvTuM/+mlsymLh6rqxY
OdZ0zBapPbu+hC0uapcE/NKEdJ1ldnEI6IN3SnGcAltvHV4cb4sS40PUgz+A
c/d879kL5LMzMETgvpE40MQAklXpIBOge4py5cGIZ0Y+hMCJdDXQZl4w3+H0
gSMCXAEheJHx+EugLLogpsLBy1R/YAnBtyY1qvxhbORuwBGqW7MA8mpUP9Zr
c168BdOQRsPVhJxJYAUKAZVByEGD0NnwD5fqH7UyeOlG/SOsmzVXGJPLDQ+i
whmrznkiDDtdbBJQs6UucCljBbeuWRrHLIgU8SyKBTp0/llyuyI9XigmK5hF
UrX2QYPCW6oOxPk3ZhLkBIK2aw3cSy5YZh2AEJmAfMAluWSgtigCI+ZMtUlq
Y5wmRLF3cyMDkhvSAJMWNKWTbg0chbjXZVvVtUM2IibFn8jMgJoPqiwG/I5V
px6PCTJOSqRxYZPXPAb13qTIsmJp9nu9naG4ssKoDbEvmeCiFat2WQGbcms7
jNYhjmWJ3HNeHtNW50lWpxi7kc7idByMQ2zofm6dj863N1vF5lGKFH8bHf90
cnl1DJHpb0fnpwcnZ9tsZ0HXgaOSdnsPrTF+PB+9OxjBADDSb6cHZwc/HY+2
1wzjXUYaHf9yPLo8bo3EmpvyHeiP7DIJYuZk8U+9PxGjs0NuW1ZhLE2jLq37
rOGKVd3DDhotQGCt8gkVRuPQAKx7EbugpcGRWTdvGYVuFvPZA/hSl86dOyww
kM0wKZTnKnuA1ubeBmUbY7V1V8fyG4I0rnWWxvEsceqWlaUudt123gKlcb6B
ZxMg1hGj22nM0XmjJ8AVDjzICICDxQJmAifk1RfhbOhxg9aM3SdSl2u+lVV2
zjLFIKHbwXoflddKuSQa+LVfCWDgf1N8FHrSaFAR7Ar9E4Mugg+FEHcAAqZp
xbXMakXpkii3b10wZuS2A5aqSuqMWWUhV+QR25CyRTtWlY6RpzXQMaP0Ia2W
XI3d3eecr3l4u576+LD4rUw/s8JeC7tu12bAEynJG8P+489HZ52GNs4b9np/
/PFHTzwW65+djmu7Hdf28PUduLUnnoin4pl4Ll6Il/e51vt+8JX/9T4BIDeh
BoH85MFl8g0y8NuDz6dvBMPXfD71HnVcvZlx1j+PvgEMX48H5KiP+w9BgwzK
GWhj3Jf7jwc3sfQDYPnvHFXQ8omtnWdiDLZ/e/9GktoMd2MuvVe0AV1bV6+O
djDL+F3IBMFs8HNaYSZGFEmlKuME/+YxwXJmnbYBs8hPdp6S9H+3YYCta/DL
MJMA03uxDRJGYbYfX1M5rnZ9Smdddx5bZRsCgPrnLm4OqqB0blXQ2gsw0b3c
oih54eMiv0inVE/bKU+O34uy8hGU8WjAXck6RzWH849BiynVZIB9tAbO+AFQ
b7EobPgOITvYL3Cd/O6IRTQ52Bi0YIIavhVZbYeeYKwAHhQQR5uZU/N3BkD0
XhdL9CZ4OpvQkDyvR80czJReYB4pvZZ5BcgFsNHLCwGGeFyXpsLEkK4oAWJC
e2SJoaTRivLUYCkNp2vMXGYZXBzAQtBAUtaVUhYnF9dP6JETHKKZiwIX9Ts8
XPlQy0Kbsj+VN+jDoKOEeQvMha0oukVsSMTnnEKtipJk3stEInIGPKBGQH4I
mgvKwNKuQeNwRF6nM/5jZVP4/TiOpuyaJ9w92eZ+5pA+f2WbuEFAQ5vYbRS/
nU28rBco0MBRV1647Rxfb49uHeFPscudepTFYv3zl7PL6dyZ5TvYBbTQt5ro
Lha72UrfKegGc737JeYabGRGij+VlbzdOHcxZzCLKwqgfKh/tDFSTehJYa7N
81QQlQ57xxL32TQmCReg7rCeBrPO66PYnTkc5fTgV+/Kh5Pi6ry5mHOGAO00
Do9oRQNGpmMOWpAUfRyEX725FFvgdcDfbUEb9qSvK8JBJx2ImTsdlMZ2f5E/
ckJpHwhAgHoQNuqEratN/6JZczzQbFNTdrWLVOhVFHVlH13hUDJfoQ2jjLXA
h4bibZ6BuelQ+Zzjk9NScVakNjRCE1DSJANCsfpdYpiMJI8iZNogxkkRDlju
mPa1fMnFgOXARaU0oNt5pCdxz2HsY1g0tJS0c1tCvJkz4TA4GsWaQRtyOzO4
9iLP7rcFu7BYcDUDrgGeLn32lJLSZEKl3ZK5B5t1rJtCcly9ePF0z21Q+jHx
ZeaV5y+evsCNSEAP3qVkDUE7wY3t+NmXO4/3/M5RbmtufOjrsBKyFQX3DTjo
L6CkdiEGN3DH6C2MZSbzJIykUz2ZYDVBtULEALHTjHkH/A7ig6oGbjFiK5Rz
GnS77fOCo2r0WGeYzAdo0FuUgLjUIrVxmJpUPybvmSprSF6iK5Vh3QnuU+Bo
4LpxEmJDhpL3QS2KXBriazOa/7dBwP8vb24DosW/vLm7fta8uY1M3uXQ/TW8
OevOCc6zNA7dHWSWHLo7JF3W+WxT3uUOqgI8ur0v8ejs0+TP3THl8m28utG3
cetGf7JfF9nMtm93O39v8vFGG5w8s8nJczUEtMa8no9xp7LJR9vNow4y9W3p
wVz57UpXdbVGdMpXfRazIksN59m76M75flPZzFbXI8xVXYn+Vl69i1m8ibqR
NZwz2bzj3UMwzQf0hkGGB7TstGYMkbY2JbpSHiRmnKQo7R4heiNjKvwoaRhw
ADt3sio5JtYmbmVO18AfREbUMq8AuovCUDYGdHyDtQsHBSjE01zNC7DK8H2k
wEsDplG9TE2oCKfU01n1SRzRvIxWpwojtTgIP98POj7f3/DdFoE/dqOuiw1e
JL+UH8BdnwEwbE+En08d0hXDKAS/sTPYecoX6hzGt2UozVOD8LuLvRnTTlV3
MOIDAUx6m8hHTvZ+N4NGvjrriB+8juhvcqrtk+xVf5OKrmYD7pWCcEuDZmCR
TGfJYjC21z6T/NoHrTPqnu/1bEBpxM7z4e5wl1h15wV8aWkeMcWF5G633Nds
YlIdy25AJKxcs0BwkHOAUgra5lrlGhm3KW3E2u0+uKYCH8TXbM2IDVbtNFTd
Y7Aiww4+KQquGteTsL6BvF+vDSj6YL8Wn6eiUtZAduO92cTXHIk1Bcx9zuOG
tRNrpQII0C21g9Y09zfZ7f6dDTyB1ADtUiNRMcF4ZUs8kBTNnndY+uBrP0bn
dvfCDnHIQzRc0VFPwuUj5p+1ZIqaEVKqq3YRfJACMcSmw50+/921f5/Yv0/t
32fsK+zuDJ93GNO3C+JgrALkEDM2UZGExs0QNvodqUW26s0R2VPV98GSbcC4
ucjhC2TdU2ukMrkSB9OQZKHgYzXVim0y2if4P4+y/nZ3htrQ2iVuPLbEsQ03
RICDSv1Hgb/Ac5EpiwCzpDskXuv16FVtAsbl/AFoB95W8Bv9uVp2jmGRzPt2
JRap6rySNiezL2ZVtTD7jx4tl8shQjMsyumjRv2YR4iO62eDpsRh/crw91k1
zx6uXR/sWiP9C6UyOixs8LHyg9yKn0tYU6aqwlcXBJYb90o3b6nD51dYe/A5
K1rz/aczsv/lE4JPhjs49u4texNrY7d+3jD2Lo69J24Jlb9s7D1C800+pqfI
TQzleIL6WJYNr4Cwbx7P5a++dB/2PgHaplwOZyUx6aVKrgrzBTlU7dgkIQOP
sql8rHyK7gxde+tqezRos78ZD66Zyj6fBoyO74ov8ezR6lfLgqNN+yR3FNzD
5xdf4vTzamyV+rQsauylRYCOVqhXsaAS/MTDqPDTe9uoC2nfdovXsy0A5D9d
yZwB1yrsueQI0+bbCUFjyrMb3ZjOjhghVE2yCRdshOwUD9ugFiv5aOSKShA1
9g+FrLNme1uvYXXhVPl0guDdZJSMRYG7BM2tcFAXvOD1k+OrH6nYjX9c/oQR
Lm03cxqE9q1bgVadY98faBGqXtVl1JFDbYa7z/4VY327GCsMspD0t4VZDwWX
olarTseB7gziFITNILi77QRFKxEVdKI2hdccpLtGk/X6vLDWIZFlqdccaXdC
wSavz/jeFsvA3J2zPt1aM0sQUTQ9JdyBR5WWQYcxtihRWitswqNy2xX570ss
XseayL7wfVqFMOC4LWYrY/uklzMN2hN3srCC1JW8Iz9jUwUgAdkDHbKAZ3zd
scDIDR/A9gPftcEox/01qpiBe01Fy8zXKK/1RkAEqMqKd85wx6Rjxa5eljdo
jMqwN4aEPXyVIt6D5H1eLDOVTkn99nrvlFhSI2qm39sAU+bvwQRjRyz4YqBG
sFu9D75yCVGo+KXIPpB2vILh36DgB32K7ngGV8jN23vdlarDZmpqEVib/704
yNNSLWGR/AUMaZbpa8nN6W8KUDQfChASuFjpAApwziW2wVogwnMwLETWaVAW
S76+ym+rAYtOFRUPYTcnSCfpSWCgEK5/D1j748cfMCiRfGeQ5qZYDBbpwHYh
csrCbSXZFoymihlHJXy4zh/AwAgI+rqmsiNc7inwo1SZGOHfMjUW78jQMIcm
NOEPTwJ8CZ8w9RSMTMU70GHDP7Bd00RP0QqVvaMTVpSmZ7N2A27PMp1ccjgr
gWV/KnHLsZrxnO+4rekwK8BIu75EV6xF3W3TnFgSsJa4CW3MSnUS1MGFWCP8
uI1iv/PLRwGMZfKedKXvVKE8xXwhk8oR/hiuvMVWFJtpdV0utrZaukpwV1yN
+eaiNkH3C45piWV5K56hOZ8gHtF2bOWsMq+57C0D1VcZJxfeGlL9Hd1DTkyK
Bfe2eRgIf9aCAwpc+Zt36miCIfrMbpe8edfvxJcae5QgSp7j/EZxVvoV7tM6
DLawNNixVgU7M6KWJ6e3WzF51D9ILjbrUNuLyh2dUYkg54P6fq+Vu7+sP+X7
iEw9dhX3zuuB4bYmRbFtNzIq94zdRtdz5YtVfR5r6MokQP6QDBuqZ5uH2cBU
YdNXv2sFQe8aUiro1XfwmmL9vajv3Z8ekKrQqJC9BSC5O92LA2p8rA/gdl8y
/Krlv5B/LzlMbDfZRZGXwzgt3ld88kytbjefYLRdmpFqjXum4mNHaNKmAzZb
rfWLsQOSlnKJos0+q5/OM0NNxaAbiNeBel4wGno05Bm51bm/a1cS97mzeIBM
l6m4kCW4VDfPCGLjRGZ3TbU4B8s01SpLV6zqF7WUqK+RKaO+Ultx4VgRFLtr
A3UrRGH3wsCVqjfC2VZRYBHwkJAIvracxkdAYOUuveSrJ1pitXH23ru1dY/r
lVWHQfN9sFxbWLxyGQt2v1IwxYnnwhg/8EAIE1dNGVSRiX/Ty8Ph2cHpsd1W
2N15sYMbEPxr5/HeE96OaJ549uz5Lqg14Fp673t/D82+qcsV2nz1ezWgc7ng
B/zr+pk45R5VCwdowNog0m3omTkFG51H4EK3hqmHvfPctjqG6/L+SyOIsYeI
Pj9FnfY6Ho7g+l/rRerOZ1jrDAVr8NnXtKGlCRKirT5Qa2PCs3vuq10aDgEW
mqBg+FH/rsqilYCwKrFlzNbAJ1LYPICfACUCNShxFvOud6ta3A/BnrPSdt8Y
Jg7IZBonh89o6Xze56kqUi4LUi72xdLESnAdSZaE64hiwXSxyS26jXrM/RjE
nLZiS3uXQed+34nLIp30YnTN5itesJ2TDp+ps4p4aAaxP7jS4AYmK5uED3Uq
DtU6cSdQpnuf2+3WobLqNAyhKtisj9hz8B3VqIHD4I7ChuhYgg1LDpwEr12X
il06xnBwwpBrj2U7vOHkjy2zTfFlyCjDqPztlpfD0zUwIrrBOJpWvM0ha+sx
WOJ5vIgILlyOVSILVaKaa8o+m22KpVzZDu63qGlc70rsEp00WnIozq1y0nM5
xUN0pPjp7QkfhjORieVh9oFMzA6Y2S5SDP5RkoFoE52pIDc8FAdTYoNqFrgt
rE9YDwpKXGDbOCha7MocINq5/fltcyRJ0qWKAB1BF7LoiNidxLs3Di+O3XkQ
0bEyjdoO0oAyOjGk/b4rsWxMAEHAoUEAQvBKZGNbaITgEDFetACAC9cy48Nw
iMfxXCEz04vbu9PI68XKZidpzXZr6OliTob9WsbzXTucDr62NKDPDrlRFdIh
PKcr5G062YCOevCeLnI4CVQRCH94LgqgQyZB83LLTIJ6PHUlV6RKA234ZIM2
5NNY4Hfu+6Pm4TgwNCUbjc9QdTkKXGwM1NOkvK2M4ddUoVZjt53gpidh5MuO
rdl1s3tsnw6PuGns4CaX8YolhRPNVHQd9zpvSDVi+DCpMfTAJnKgDlp5m0/b
jC1+yl+6ET5Aa9RLh6M2p+k5r4Lqr9Vd1mush67pODbtOt+l3RMytbIBNTyA
FsWJvk8ZkJjUZcmni/h0ycnELtmdDBZDdoeFxi6ktSU3ItAfA0bbuJvo66wm
KqU+pRTswTF4DdSgosMcUB9u1igWcfZlqy+L5tA1BIqO04tMaeMFYQ0AnkYZ
cYG1Z/MCzCq5xegWYgvFUqe4vum0tBqD+iwsOvQ1HXwjdUa5kLU+he7HGMH+
Jz6VqDK3hXYJKpAoDJP0bN2crNd6xqWtbbKK9WcZHNTWnDCzwQ+5KMHultp2
XyIZcJvgxPY6AnWQakCngqKsFr5BLrgKpVFYYUWpP22ODs6isQJxorRlxyFP
sTMcndAU+yONersXG8VxhTaBxu9QdE3U70sUG98VN9DeOR0fOwkbxukLL2rR
9kDRoVI8Lm88FK/v2xYC1DQBdNGimXFO7vC+kO+52j0KJxtusSfp+aoT61BG
YnjgFAW8v3V5fLgdH4WCRyzVOqtuGIpOeSHphzCjYtGJSYgJaz4RDGw0bukg
HxCCIw1r3Lmo/3R7A/AXjRlGXUJaOk/ppLUqvOd4gw2yT2PhJbDV2KejsU67
I3TH4do86ze1mnzinW1Cn3UI8FfMBq1DqsiRCgqmEMn/C3XUdH0WXQAA
</rfc> </rfc>
 End of changes. 39 change blocks. 
713 lines changed or deleted 575 lines changed or added

This html diff was produced by rfcdiff 1.48.