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" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" do
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.1 --> cName="draft-ietf-homenet-naming-architecture-dhc-options-24" number="9527" subm
issionType="IETF" category="std" consensus="true" obsoletes="" updates="" xml:la
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ ng="en" tocInclude="true" sortRefs="true" symRefs="true" prepTime="2024-01-28T21
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere :04:42" indexInclude="true" scripts="Common,Latin" tocDepth="3">
nce.RFC.2119.xml"> <link href="https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-archite
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere cture-dhc-options-24" rel="prev"/>
nce.RFC.8174.xml"> <link href="https://dx.doi.org/10.17487/rfc9527" rel="alternate"/>
<!ENTITY I-D.ietf-homenet-front-end-naming-delegation SYSTEM "https://xml2rfc.to <link href="urn:issn:2070-1721" rel="alternate"/>
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 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-optio
ns-24" category="std">
<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" stream="IETF"/>
<author initials="D." surname="Migault" fullname="Daniel Migault"> <author initials="D." surname="Migault" fullname="Daniel Migault">
<organization>Ericsson</organization> <organization showOnFrontPage="true">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 showOnFrontPage="true">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" showOnFrontPage="true">Internet Systems Consort ium, 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 month="01" year="2024"/>
<date year="2022" month="October" day="31"/> <area>int</area>
<workgroup>homenet</workgroup>
<area>Internet</area> <abstract pn="section-abstract">
<workgroup>Homenet</workgroup> <t indent="0" pn="section-abstract-1">This document defines DHCPv6 options
<keyword>Internet-Draft</keyword> so that a Homenet Naming Authority (HNA) can automatically set the appropriate
configuration and outsource the authoritative naming service for the home networ
<abstract> k.
<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>
<boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9527" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
erminology</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-procedure-over
view">Procedure Overview</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-dhcpv6-options">DHCPv6 Options</xr
ef></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-registered-homenet-dom
ain-o">Registered Homenet Domain Option</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-forward-distribution-m
anage">Forward Distribution Manager Option</xref></t>
</li>
<li pn="section-toc.1-1.4.2.3">
<t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent=
"4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-reverse-distribution-m
anage">Reverse Distribution Manager Server Option</xref></t>
</li>
<li pn="section-toc.1-1.4.2.4">
<t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent=
"4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-supported-transport">S
upported Transport</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-dhcpv6-behavior">DHCPv6 Behavior</
xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dhcpv6-server-behavior
">DHCPv6 Server Behavior</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dhcpv6-client-behavior
">DHCPv6 Client Behavior</xref></t>
</li>
<li pn="section-toc.1-1.5.2.3">
<t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent=
"5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dhcpv6-relay-agent-beh
avior">DHCPv6 Relay Agent Behavior</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-dhcpv6-option-codes">D
HCPv6 Option Codes</xref></t>
</li>
<li pn="section-toc.1-1.6.2.2">
<t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent=
"6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-supported-transport-pa
ramet">Supported Transport parameter</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.8.2">
<li pn="section-toc.1-1.8.2.1">
<t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent=
"8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.8.2.2">
<t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent=
"8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="Appendi
x A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref d
erivedContent="" format="title" sectionFormat="of" target="name-scenarios-and-im
pact-on-the">Scenarios and Impact on the End User</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-base-scenario
">Base Scenario</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"A.2" format="counter" sectionFormat="of" target="section-appendix.a.2"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-third-party-r
egistered-home">Third-Party Registered Homenet Domain</xref></t>
</li>
<li pn="section-toc.1-1.9.2.3">
<t indent="0" pn="section-toc.1-1.9.2.3.1"><xref derivedContent=
"A.3" format="counter" sectionFormat="of" target="section-appendix.a.3"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-third-party-d
ns-infrastruct">Third-Party DNS Infrastructure</xref></t>
</li>
<li pn="section-toc.1-1.9.2.4">
<t indent="0" pn="section-toc.1-1.9.2.4.1"><xref derivedContent=
"A.4" format="counter" sectionFormat="of" target="section-appendix.a.4"/>.  <xre
f derivedContent="" format="title" sectionFormat="of" target="name-multiple-isps
">Multiple ISPs</xref></t>
</li>
<li pn="section-toc.1-1.9.2.5">
<t indent="0" pn="section-toc.1-1.9.2.5.1"><xref derivedContent=
"" format="none" sectionFormat="of" target="section-appendix.a.5"/><xref derived
Content="" format="title" sectionFormat="of" target="name-acknowledgments">Ackno
wledgments</xref></t>
</li>
<li pn="section-toc.1-1.9.2.6">
<t indent="0" pn="section-toc.1-1.9.2.6.1"><xref derivedContent=
"" format="none" sectionFormat="of" target="section-appendix.a.6"/><xref derived
Content="" format="title" sectionFormat="of" target="name-contributors">Contribu
tors</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="include" removeInRFC="fa
<section anchor="terminology" title="Terminology"> lse" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL <t indent="0" pn="section-1-1"><xref target="RFC9526" format="default" sec
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, tionFormat="of" derivedContent="RFC9526"/> specifies how an entity designated as
“MAY”, and “OPTIONAL” in this document are to be interpreted as the Homenet Naming Authority (HNA) outsources a Public Homenet Zone to a DNS Ou
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and tsourcing Infrastructure (DOI).</t>
only when, they <t indent="0" pn="section-1-2">This document describes how a network can p
rovision 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 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 indent="0" pn="section-1-3">In addition, ISPs often identify the line o
f 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 infrastruc
ture and provide the home network with a specific domain name designated per a R
egistered Homenet Domain <xref target="RFC9526" format="default" sectionFormat="
of" derivedContent="RFC9526"/>.
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 indent="0" pn="section-1-4">This document describes DHCPv6 options that
enable an ISP to provide the necessary parameters to the HNA to proceed. More s
pecifically, the ISP provides the Registered Homenet Domain and the necessary in
formation on the DM and the RDM so the HNA can manage and upload the Public Home
net Zone and the Reverse Public Homenet Zone as described in <xref target="RFC95
26" format="default" sectionFormat="of" derivedContent="RFC9526"/>.</t>
<t indent="0" pn="section-1-5">The use of DHCPv6 options may make the conf
iguration 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="terminology" numbered="true" toc="include" removeInRFC="fal
se" pn="section-2">
<name slugifiedName="name-terminology">Terminology</name>
<t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp1
4>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>
SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp1
4>RECOMMENDED</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" sectionFormat="of" d
erivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat=
"of" derivedContent="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<t indent="0" pn="section-2-2">The reader should be familiar with <xref ta
<t>The reader should be familiar with <xref target="I-D.ietf-homenet-front-end-n rget="RFC9526" format="default" sectionFormat="of" derivedContent="RFC9526"/>.</
aming-delegation"/>.</t> t>
</section>
</section> <section anchor="sec-overview" numbered="true" toc="include" removeInRFC="fa
<section anchor="introduction" title="Introduction"> lse" pn="section-3">
<name slugifiedName="name-procedure-overview">Procedure Overview</name>
<t><xref target="I-D.ietf-homenet-front-end-naming-delegation"/> specifies how a <t indent="0" pn="section-3-1">This section illustrates how an HNA receive
n entity designated as the Homenet Naming Authority (HNA) outsources a Public Ho s the necessary information via DHCPv6 options to outsource its authoritative na
menet Zone to an DNS Outsourcing Infrastructure (DOI).</t> ming service to the DOI. For the sake of simplicity, and similarly to <xref targ
et="RFC9526" format="default" sectionFormat="of" derivedContent="RFC9526"/>, thi
<t>This document describes how a network can provision the HNA with a specific D s section assumes that the HNA and the home network DHCPv6 client are colocated
OI. on the Customer Premises Equipment (CPE) router <xref target="RFC7368" format="
This could be particularly useful for a DOI partly managed by an ISP, or to make default" sectionFormat="of" derivedContent="RFC7368"/>. Also, note that this is
home networks resilient to HNA replacement. not mandatory, and the DHCPv6 client may remotely instruct the HNA with a protoc
The ISP delegates an IP prefix to the home network as well as the associated rev ol that will be standardized in the future.
erse zone. In addition, this section assumes that the responsible entity for the DHCPv6 ser
The ISP is thus aware of the owner of that IP prefix, and as such becomes a natu ver is provisioned with the DM and RDM information, which is associated with the
ral candidate for hosting the Homenet Reverse Zone - that is the Reverse Distrib requested Registered Homenet Domain.
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 indent="0" pn="section-3-2">This scenario is believed to be the most po
<t>This scenario is believed to be the most popular scenario. pular 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" sectio
Such scenarios do not necessarily require configuration for the end user and can nFormat="of" derivedContent="Appendix A"/>.
also be zero-config.</t> Such scenarios do not necessarily require configuration for the end user and can
also be zero configuration.</t>
<t>The scenario considered in this section is as follows:</t> <t indent="0" pn="section-3-3">The scenario considered in this section is
as follows:</t>
<t><list style="numbers"> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-3-4"
<t>The HNA is willing to outsource the Public Homenet Zone or Homenet Reverse >
Zone. <li pn="section-3-4.1" derivedCounter="1.">The HNA is willing to outsourc
The DHCPv6 client is configured to include in its Option Request Option (ORO) th e the Public Homenet Zone or Homenet Reverse 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 Distributio e Registered Homenet Domain Option (OPTION_REGISTERED_DOMAIN), the Forward Distr
n Manager Option (OPTION_REVERSE_DIST_MANAGER) option codes.</t> ibution Manager Option (OPTION_FORWARD_DIST_MANAGER), and the Reverse Distributi
<t>The DHCPv6 server responds to the DHCPv6 client with the requested DHCPv6 o on Manager Option (OPTION_REVERSE_DIST_MANAGER) option codes.</li>
ptions based on the identified homenet. <li pn="section-3-4.2" derivedCounter="2.">The DHCPv6 server responds to
The DHCPv6 client passes the information to the HNA.</t> the DHCPv6 client with the requested DHCPv6 options based on the identified hom
<t>The HNA is authenticated (see Section “Securing the Control Channel” of <xr enet. The DHCPv6 client passes the information to the HNA.</li>
ef target="I-D.ietf-homenet-front-end-naming-delegation"/>) by the DM and the RD <li pn="section-3-4.3" derivedCounter="3.">The HNA is authenticated (see
M. "Securing the Control Channel" (Section <xref target="RFC9526" sectionFormat="b
The HNA builds the Homenet Zone (or the Homenet Reverse Zone) and proceed as des are" section="6.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9
cribed in <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>. 526#section-6.6" derivedContent="RFC9526"/>) of <xref target="RFC9526" sectionFo
The DHCPv6 options provide the necessary non optional parameters described in Ap rmat="bare" format="default" derivedContent="RFC9526"/>) by the DM and the RDM.
pendix B of <xref target="I-D.ietf-homenet-front-end-naming-delegation"/>. The HNA builds the Homenet Zone (or the Homenet Reverse Zone) and proceeds as de
scribed in <xref target="RFC9526" format="default" sectionFormat="of" derivedCon
tent="RFC9526"/>. The DHCPv6 options provide the necessary non-optional paramete
rs described in Appendix B of <xref target="RFC9526" format="default" sectionFor
mat="of" derivedContent="RFC9526"/>.
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" sectionFormat="of" derived
ribes such parameters that may take some specific non default value.</t> Content="RFC9526"/> describes such parameters that may take some specific non-de
</list></t> fault value.</li>
</ol>
</section> </section>
<section anchor="sec-format" title="DHCPv6 Option"> <section anchor="sec-format" numbered="true" toc="include" removeInRFC="fals
e" pn="section-4">
<t>This section details the payload of the DHCPv6 options following the guidelin <name slugifiedName="name-dhcpv6-options">DHCPv6 Options</name>
es of <xref target="RFC7227"/>.</t> <t indent="0" pn="section-4-1">This section details the payload of the DHC
Pv6 options following the guidelines of <xref target="RFC7227" format="default"
<section anchor="o_rd" title="Registered Homenet Domain Option"> sectionFormat="of" derivedContent="RFC7227"/>.</t>
<section anchor="o_rd" numbered="true" toc="include" removeInRFC="false" p
<t>The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the FQDN as n="section-4.1">
sociated with the home network.</t> <name slugifiedName="name-registered-homenet-domain-o">Registered Homene
t Domain Option</name>
<figure title="Registered Domain Option" anchor="fig-rhd"><artwork><![CDATA[ <t indent="0" pn="section-4.1-1">The Registered Domain Option (OPTION_RE
GISTERED_DOMAIN) indicates the fully qualified domain name (FQDN) associated wit
h the home network.</t>
<figure anchor="fig-rhd" align="left" suppress-title="false" pn="figure-
1">
<name slugifiedName="name-registered-domain-option">Registered Domain
Option</name>
<artwork name="" type="" align="left" alt="" pn="section-4.1-2.1">
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" indent="3" newline="false" pn="section-4.1-3">
<t>option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code for the Re <dt pn="section-4.1-3.1">option-code (16 bits):</dt>
gistered Homenet Domain (TBD1).</t> <dd pn="section-4.1-3.2">OPTION_REGISTERED_DOMAIN; the option code for
<t>option-len (16 bits): length in octets of the Registered Homenet Domain fie the Registered Homenet Domain (145).</dd>
ld as described in <xref target="RFC8415"/>.</t> <dt pn="section-4.1-3.3">option-len (16 bits):</dt>
<t>Registered Homenet Domain (variable): the FQDN registered for the homenet e <dd pn="section-4.1-3.4">Length in octets of the Registered Homenet Do
ncoded as described in Section 10 of <xref target="RFC8415"/>.</t> main field as described in <xref target="RFC8415" format="default" sectionFormat
</list></t> ="of" derivedContent="RFC8415"/>.</dd>
<dt pn="section-4.1-3.5">Registered Homenet Domain (variable):</dt>
</section> <dd pn="section-4.1-3.6">The FQDN registered for the homenet encoded a
<section anchor="o_dm" title="Forward Distribution Manager Option"> s described in <xref target="RFC8415" sectionFormat="of" section="10" format="de
fault" derivedLink="https://rfc-editor.org/rfc/rfc8415#section-10" derivedConten
<t>The Forward Distributed Manager Option (OPTION_FORWARD_DIST_MANAGER) provides t="RFC8415"/>.</dd>
the HNA with the FQDN of the DM as well as the transport protocols for the comm </dl>
unication between the HNA and the DM. </section>
As opposed to IP addresses, the FQDN requires a DNS resolution before establishi <section anchor="o_dm" numbered="true" toc="include" removeInRFC="false" p
ng the communication between the HNA and the DM. n="section-4.2">
However, the use of a FQDN provides multiple advantages over IP addresses. <name slugifiedName="name-forward-distribution-manage">Forward Distribut
Firstly, it makes the DHCPv6 Option easier to parse and smaller - especially whe ion Manager Option</name>
n IPv4 and IPv6 addresses are expected to be provided. <t indent="0" pn="section-4.2-1">The Forward Distribution Manager Option
Then the FQDN can reasonably be seen as a more stable identifier than IP address (OPTION_FORWARD_DIST_MANAGER) provides the HNA with the FQDN of the DM as well
es, as well as a pointer to additional information that may be useful, in the fu as the transport protocols for the communication between the HNA and the DM.
ture, to establish the communication between the HNA and the DM.</t> As opposed to IP addresses, the FQDN requires a DNS resolution before establishi
ng the communication between the HNA and the DM. However, the use of an FQDN pro
<figure title="Forward Distribution Manager Option" anchor="fig-dm"><artwork><![ vides multiple advantages over IP addresses. Firstly, it makes the DHCPv6 option
CDATA[ easier to parse and smaller, especially when IPv4 and IPv6 addresses are expect
0 1 2 3 ed to be provided. Then, the FQDN can reasonably be seen as a more stable identi
fier than IP addresses as well as a pointer to additional information that may b
e useful, in the future, to establish the communication between the HNA and the
DM.</t>
<figure anchor="fig-dm" align="left" suppress-title="false" pn="figure-2
">
<name slugifiedName="name-forward-distribution-manager">Forward Distri
bution Manager Option</name>
<artwork name="" type="" align="left" alt="" pn="section-4.2-2.1">
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" indent="3" newline="false" pn="section-4.2-3">
<t>option-code (16 bits): OPTION_FORWARD_DIST_MANAGER, the option code for the <dt pn="section-4.2-3.1">option-code (16 bits):</dt>
Forward Distribution Manager Option (TBD2).</t> <dd pn="section-4.2-3.2">OPTION_FORWARD_DIST_MANAGER; the option code
<t>option-len (16 bits): length in octets of the enclosed data as described in for the Forward Distribution Manager Option (146).</dd>
<xref target="RFC8415"/>.</t> <dt pn="section-4.2-3.3">option-len (16 bits):</dt>
<t>Supported Transport (16 bits): defines the supported transport by the DM (s <dd pn="section-4.2-3.4">Length in octets of the enclosed data as desc
ee <xref target="sec-st"/>). ribed in <xref target="RFC8415" format="default" sectionFormat="of" derivedConte
Each bit represents a supported transport, and a DM MAY indicate the support of nt="RFC8415"/>.</dd>
multiple modes. <dt pn="section-4.2-3.5">Supported Transport (16 bits):</dt>
The bit for DNS over mutually authenticated TLS (DomTLS) MUST be set.</t> <dd pn="section-4.2-3.6">Defines the Supported Transport by the DM (se
<t>Distribution Manager FQDN (variable): the FQDN of the DM encoded as describ e <xref target="sec-st" format="default" sectionFormat="of" derivedContent="Sect
ed in Section 10 of <xref target="RFC8415"/>.</t> ion 4.4"/>).
</list></t> Each bit represents a supported transport, and a DM <bcp14>MAY</bcp14> indicate
the support of multiple modes.
<t>It is worth noticing that the DHCP Option specifies the Supported Transport The bit for DNS over mutually authenticated TLS (DomTLS) <bcp14>MUST</bcp14> be
without specifying any explicit port. Unless the HNA and the DM have agreed on u set.</dd>
sing a specific port - for example by configuration, or any out of band mechanis <dt pn="section-4.2-3.7">Distribution Manager FQDN (variable):</dt>
m -, the default port is used and must be specified. The specification of such d <dd pn="section-4.2-3.8">The FQDN of the DM encoded as described in <x
efault port may be defined in the specification of the designated Supported Tran ref target="RFC8415" sectionFormat="of" section="10" format="default" derivedLin
sport or in any other document. k="https://rfc-editor.org/rfc/rfc8415#section-10" derivedContent="RFC8415"/>.</d
In the case of DNS over mutually authenticated TLS (DomTLS), the default port va d>
lue is 853 as per DNS over TLS <xref target="RFC7858"/> and DNS Zone Transfer o </dl>
ver TLS <xref target="RFC9103"/>.</t> <t indent="0" pn="section-4.2-4">It is worth noting that the DHCPv6 opti
on specifies the Supported Transport without specifying any explicit port. Unles
<t>The need to associate in the DHCP Option the port value to each Supported Tra s the HNA and the DM have agreed on using a specific port -- for example, by con
nsport has been balanced with the difficulty of handling a list of tuples ( tran figuration, or any out-of-band mechanism -- the default port is used and must be
sport, port ) as well as the possibility to use a dedicated IP address for the D specified. The specification of such default port may be defined in the specifi
M in case the default port was already in use.</t> cation of the designated Supported Transport or in any other document. In the ca
se of DomTLS, the default port value is 853 per DNS over TLS <xref target="RFC78
</section> 58" format="default" sectionFormat="of" derivedContent="RFC7858"/> and DNS Zone
<section anchor="reverse-distribution-manager-server-option" title="Reverse Dist Transfer over TLS <xref target="RFC9103" format="default" sectionFormat="of" der
ribution Manager Server Option"> ivedContent="RFC9103"/>.</t>
<t indent="0" pn="section-4.2-5">The need to associate the port value to
<t>The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) provide each Supported Transport in the DHCPv6 option has been balanced with the diffic
s the HNA with the FQDN of the DM as well as the transport protocols for the com ulty of handling a list of tuples (transport, port) and the possibility of using
munication between the HNA and the DM.</t> a dedicated IP address for the DM in case the default port is already in use.</
t>
<figure title="Reverse Distribution Manager Option" anchor="fig-rdm"><artwork><! </section>
[CDATA[ <section anchor="reverse-distribution-manager-server-option" numbered="tru
0 1 2 3 e" toc="include" removeInRFC="false" pn="section-4.3">
<name slugifiedName="name-reverse-distribution-manage">Reverse Distribut
ion Manager Server Option</name>
<t indent="0" pn="section-4.3-1">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 anchor="fig-rdm" align="left" suppress-title="false" pn="figure-
3">
<name slugifiedName="name-reverse-distribution-manager">Reverse Distri
bution Manager Option</name>
<artwork name="" type="" align="left" alt="" pn="section-4.3-2.1">
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>
]]></artwork></figure> </figure>
<dl spacing="normal" indent="3" newline="false" pn="section-4.3-3">
<t><list style="symbols"> <dt pn="section-4.3-3.1">option-code (16 bits):</dt>
<t>option-code (16 bits): OPTION_REVERSE_DIST_MANAGER, the option code for the <dd pn="section-4.3-3.2">OPTION_REVERSE_DIST_MANAGER; the option code
Reverse Distribution Manager Option (TBD3).</t> for the Reverse Distribution Manager Option (147).</dd>
<t>option-len (16 bits): length in octets of the option-data field as describe <dt pn="section-4.3-3.3">option-len (16 bits):</dt>
d in <xref target="RFC8415"/>.</t> <dd pn="section-4.3-3.4">Length in octets of the option-data field as
<t>Supported Transport (16 bits): defines the supported transport by the RDM ( described in <xref target="RFC8415" format="default" sectionFormat="of" derivedC
see <xref target="sec-st"/>). ontent="RFC8415"/>.</dd>
Each bit represents a supported transport, and a RDM MAY indicate the support of <dt pn="section-4.3-3.5">Supported Transport (16 bits):</dt>
multiple modes. <dd pn="section-4.3-3.6">Defines the Supported Transport by the RDM (s
The bit for DNS over mutually authenticated TLS <xref target="RFC7858"/> MUST be ee <xref target="sec-st" format="default" sectionFormat="of" derivedContent="Sec
set.</t> tion 4.4"/>). Each bit represents a supported transport, and an RDM <bcp14>MAY</
<t>Reverse Distribution Manager FQDN (variable): the FQDN of the RDM encoded a bcp14> indicate the support of multiple modes.
s described in section 10 of <xref target="RFC8415"/>.</t> The bit for DomTLS <xref target="RFC7858" format="default" sectionForma
</list></t> t="of" derivedContent="RFC7858"/> <bcp14>MUST</bcp14> be set.</dd>
<dt pn="section-4.3-3.7">Reverse Distribution Manager FQDN (variable):
<t>For the port number associated to the Supported Transport, the same considera </dt>
tions as described in <xref target="o_dm"/> holds.</t> <dd pn="section-4.3-3.8">The FQDN of the RDM encoded as described in <
xref target="RFC8415" sectionFormat="of" section="10" format="default" derivedLi
</section> nk="https://rfc-editor.org/rfc/rfc8415#section-10" derivedContent="RFC8415"/>.</
<section anchor="sec-st" title="Supported Transport"> dd>
</dl>
<t>The Supported Transport field of the DHCPv6 option indicates the supported tr <t indent="0" pn="section-4.3-4">For the port number associated to the S
ansport protocols. upported Transport, the same considerations as described in <xref target="o_dm"
Each bit represents a specific transport mechanism. format="default" sectionFormat="of" derivedContent="Section 4.2"/> apply.</t>
A bit sets to 1 indicates the associated transport protocol is supported. </section>
The corresponding bits are assigned as described in <xref target="tab-st"/> and <section anchor="sec-st" numbered="true" toc="include" removeInRFC="false"
<xref target="sec-iana"/>.</t> pn="section-4.4">
<name slugifiedName="name-supported-transport">Supported Transport</name
<figure title="Supported Transport" anchor="tab-st"><artwork><![CDATA[ >
Bit Position | Transport Protocol | Mnemonic | Reference <t indent="0" pn="section-4.4-1">The Supported Transport field of the DH
left to right| Description | | CPv6 option indicates the Supported Transport protocols. Each bit represents a s
0 | DNS over mutually | DomTLS | This-RFC pecific transport mechanism. A bit set to 1 indicates the associated transport p
| authenticated TLS | | rotocol is supported. The corresponding bits are assigned as described in <xref
1-15 | unallocated | - | - target="tab-iana" format="default" sectionFormat="of" derivedContent="Table 2"/>
]]></artwork></figure> .</t>
<dl spacing="normal" indent="3" newline="false" pn="section-4.4-2">
<t>DNS over mutually authenticated TLS (DomTLS): indicates the support of DNS o <dt pn="section-4.4-2.1"> DNS over mutually authenticated TLS (DomTLS)
ver TLS <xref target="RFC7858"/>, DNS Zone Transfer over TLS <xref target="RFC9 :</dt>
103"/> as described in <xref target="I-D.ietf-homenet-front-end-naming-delegatio <dd pn="section-4.4-2.2"> Indicates the support of DNS over TLS <xref
n"/>.</t> target="RFC7858" format="default" sectionFormat="of" derivedContent="RFC7858"/>
and DNS Zone Transfer over TLS <xref target="RFC9103" format="default" sectionFo
</section> rmat="of" derivedContent="RFC9103"/> as described in <xref target="RFC9526" form
</section> at="default" sectionFormat="of" derivedContent="RFC9526"/>.</dd>
<section anchor="sec-dhcp-behavior" title="DHCPv6 Behavior"> </dl>
<t indent="0" pn="section-4.4-3">As an example, the Supported Transport
<section anchor="dhcpv6-server-behavior" title="DHCPv6 Server Behavior"> field expressing support for
DomTLS looks as follows and has a numeric value of 0x0001:</t>
<t>Sections 17.2.2 and 18.2 of <xref target="RFC8415"/> govern server operation <artwork name="" type="" align="left" alt="" pn="section-4.4-4">
regarding option assignment. 0 1
As a convenience to the reader, we mention here that the server will send option 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
foo only if configured with specific values for foo and if the client requested +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
it. | must be zero |1|
In particular, when configured the DHCPv6 server sends the Registered Homenet Do +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
main Option, Distribution Manager Option, the Reverse Distribution Manager Optio </artwork>
n when requested by the DHCPv6 client by including necessary option codes in its </section>
ORO.</t> </section>
<section anchor="sec-dhcp-behavior" numbered="true" toc="include" removeInRF
</section> C="false" pn="section-5">
<section anchor="dhcpv6-client-behavior" title="DHCPv6 Client Behavior"> <name slugifiedName="name-dhcpv6-behavior">DHCPv6 Behavior</name>
<section anchor="dhcpv6-server-behavior" numbered="true" toc="include" rem
<t>The DHCPv6 client includes Registered Homenet Domain Option, Distribution Man oveInRFC="false" pn="section-5.1">
ager Option, the Reverse Distribution Manager Option in an ORO as specified in S <name slugifiedName="name-dhcpv6-server-behavior">DHCPv6 Server Behavior
ections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of <xref target="RFC841 </name>
5"/>.</t> <t indent="0" pn="section-5.1-1"><xref target="RFC8415" sectionFormat="o
f" section="18.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc84
<t>Upon receiving a DHCPv6 option described in this document in the Reply 15#section-18.3" derivedContent="RFC8415"/> governs server operation regarding o
message, the HNA SHOULD proceed as described in <xref target="I-D.ietf-homenet-f ption assignment. As a convenience to the reader, we mention here that the serve
ront-end-naming-delegation"/>.</t> r will send option foo only if configured with specific values for foo and if th
e client requested it.
</section> In particular, when configured, the DHCPv6 server sends the Registered Homenet D
<section anchor="sec-dhcp-relay" title="DHCPv6 Relay Agent Behavior"> omain Option, Distribution Manager Option, and Reverse Distribution Manager Opti
on when requested by the DHCPv6 client by including necessary option codes in it
<t>There are no additional requirements for the DHCPv6 Relay agents.</t> s ORO.</t>
</section>
</section> <section anchor="dhcpv6-client-behavior" numbered="true" toc="include" rem
</section> oveInRFC="false" pn="section-5.2">
<section anchor="sec-iana" title="IANA Considerations"> <name slugifiedName="name-dhcpv6-client-behavior">DHCPv6 Client Behavior
</name>
<section anchor="dhcpv6-option-codes" title="DHCPv6 Option Codes"> <t indent="0" pn="section-5.2-1">The DHCPv6 client includes the Register
ed Homenet Domain Option, Distribution Manager Option, and Reverse Distribution
<t>IANA is requested to assign the following new DHCPv6 Option Codes in the regi Manager Option in an ORO as specified in Sections <xref target="RFC8415" section
stry maintained in: https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-pa Format="bare" section="18.2" format="default" derivedLink="https://rfc-editor.or
rameters.xhtml#dhcpv6-parameters-2.</t> g/rfc/rfc8415#section-18.2" derivedContent="RFC8415"/> and <xref target="RFC8415
" sectionFormat="bare" section="21.7" format="default" derivedLink="https://rfc-
<figure><artwork><![CDATA[ editor.org/rfc/rfc8415#section-21.7" derivedContent="RFC8415"/> of <xref target=
Value Description Client ORO Singleton Option Reference "RFC8415" format="default" sectionFormat="of" derivedContent="RFC8415"/>.</t>
TBD1 OPTION_REGISTERED_DOMAIN Yes No [This-RFC] <t indent="0" pn="section-5.2-2">Upon receiving a DHCPv6 option, as desc
Section 4.1 ribed in this document, in the Reply
TBD2 OPTION_FORWARD_DIST_MANAGER Yes Yes [This-RFC] message, the HNA <bcp14>SHOULD</bcp14> proceed as described in <xref target="RFC
Section 4.2 9526" format="default" sectionFormat="of" derivedContent="RFC9526"/>.</t>
TBD3 OPTION_REVERSE_DIST_MANAGER Yes Yes [This-RFC] </section>
Section 4.3 <section anchor="sec-dhcp-relay" numbered="true" toc="include" removeInRFC
]]></artwork></figure> ="false" pn="section-5.3">
<name slugifiedName="name-dhcpv6-relay-agent-behavior">DHCPv6 Relay Agen
</section> t Behavior</name>
<section anchor="supported-transport-parameter" title="Supported Transport param <t indent="0" pn="section-5.3-1">There are no additional requirements fo
eter"> r the DHCPv6 Relay agents.</t>
</section>
<t>IANA is requested to maintain a new registry of Supported Transport parameter </section>
in the Distributed Manager Option (OPTION_FORWARD_DIST_MANAGER) or the Reverse <section anchor="sec-iana" numbered="true" toc="include" removeInRFC="false"
Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The different paramet pn="section-6">
ers are defined in <xref target="tab-st"/> in <xref target="sec-st"/>.</t> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<section anchor="dhcpv6-option-codes" numbered="true" toc="include" remove
<t>The Name of the registry is: Supported Transport parameter</t> InRFC="false" pn="section-6.1">
<name slugifiedName="name-dhcpv6-option-codes">DHCPv6 Option Codes</name
<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. <t indent="0" pn="section-6.1-1">IANA has assigned the following new DHC
Each bit represents a specific transport mechanism.</t> Pv6 Option Codes in the "Option Codes" registry maintained at <eref target="http
s://www.iana.org/assignments/dhcpv6-parameters" brackets="angle"/>.</t>
<t>The parent grouping is Dynamic Host Configuration Protocol for IPv6 (DHCPv6) <table anchor="tab-2" align="center" pn="table-1">
at https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dh <name slugifiedName="name-option-codes-registry">Option Codes Registry
cpv6-parameters-2.</t> </name>
<thead>
<t>New entry MUST specify the bit position, the Transport Protocol Description a <tr>
Mnemonic and a Reference as defined in <xref target="tab-iana"/>.</t> <th align="left" colspan="1" rowspan="1">Value</th>
<th align="left" colspan="1" rowspan="1">Description</th>
<t>The initial registry is as specified in <xref target="tab-iana"/>.</t> <th align="left" colspan="1" rowspan="1">Client ORO</th>
<th align="left" colspan="1" rowspan="1">Singleton Option</th>
<t>Changes of the format or policies of the registry is left to the IETF via th <th align="left" colspan="1" rowspan="1">Reference</th>
e IESG.</t> </tr>
</thead>
<t>Future code points are assigned under RFC Required as per <xref target="RFC81 <tbody>
26"/>.</t> <tr>
<td align="left" colspan="1" rowspan="1">145</td>
<figure title="Supported Transport" anchor="tab-iana"><artwork><![CDATA[ <td align="left" colspan="1" rowspan="1">OPTION_REGISTERED_DOMAIN<
Bit Position | Transport Protocol | Mnemonic | Reference /td>
left to right| Description | | <td align="left" colspan="1" rowspan="1">Yes</td>
0 | DNS over mutually | DomTLS | This-RFC <td align="left" colspan="1" rowspan="1">No</td>
| authenticated TLS | | <td align="left" colspan="1" rowspan="1">RFC 9527, Section 4.1</td
1-15 | unallocated | - | - >
</tr>
]]></artwork></figure> <tr>
<td align="left" colspan="1" rowspan="1">146</td>
</section> <td align="left" colspan="1" rowspan="1">OPTION_FORWARD_DIST_MANAG
</section> ER</td>
<section anchor="security-considerations" title="Security Considerations"> <td align="left" colspan="1" rowspan="1">Yes</td>
<td align="left" colspan="1" rowspan="1">Yes</td>
<t>The security considerations in <xref target="RFC8415"/> are to be considered. <td align="left" colspan="1" rowspan="1">RFC 9527, Section 4.2</td
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 </tr>
nfigured via DHCPv6.</t> <tr>
<td align="left" colspan="1" rowspan="1">147</td>
<t>In some cases, the ISP MAY identify the HNA by its wire line, that is to say <td align="left" colspan="1" rowspan="1">OPTION_REVERSE_DIST_MANAG
physically which may not require to rely on TLS to authenticate the HNA. ER</td>
As TLS is mandatory to be used, it is expected the HNA is provisioned with a cer <td align="left" colspan="1" rowspan="1">Yes</td>
tificate. <td align="left" colspan="1" rowspan="1">Yes</td>
In some cases, the HNA may use a self signed certificate.</t> <td align="left" colspan="1" rowspan="1">RFC 9527, Section 4.3</td
>
</section> </tr>
<section anchor="acknowledgments" title="Acknowledgments"> </tbody>
</table>
<t>We would like to thank Marcin Siodelski, Bernie Volz and Ted Lemon for their </section>
comments on the design of the DHCPv6 options. <section anchor="supported-transport-parameter" numbered="true" toc="inclu
We would also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti fo de" removeInRFC="false" pn="section-6.2">
r their remarks on the architecture design. The designed solution has been large <name slugifiedName="name-supported-transport-paramet">Supported Transpo
ly been inspired by Mark Andrews’s document <xref target="I-D.andrews-dnsop-pd-r rt parameter</name>
everse"/> as well as discussions with Mark. <t indent="0" pn="section-6.2-1">IANA has created and maintains a new re
We also thank Ray Hunter and Michael Richardson for its reviews, its comments an gistry called "Supported Transport" under the "Dynamic Host Configuration Protoc
d for suggesting an appropriated terminology.</t> ol for IPv6 (DHCPv6)" registry at <eref target="https://www.iana.org/assignments
/dhcpv6-parameters" brackets="angle"/>. This registry contains Supported Transpo
</section> rt parameters in the Distributed Manager Option (OPTION_FORWARD_DIST_MANAGER) or
<section anchor="contributors" title="Contributors"> the Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER). The diff
erent parameters are defined in <xref target="tab-iana" format="default" section
<t>The co-authors would like to thank Chris Griffiths and Wouter Cloetens that p Format="of" derivedContent="Table 2"/> (<xref target="supported-transport-parame
rovided a significant contribution in the early versions of the document.</t> ter" format="default" sectionFormat="of" derivedContent="Section 6.2"/>).</t>
<t indent="0" pn="section-6.2-2">The Supported Transport field of the DH
</section> CPv6 option is a two-octet field that indicates the Supported Transport protocol
s. Each bit represents a specific transport mechanism.</t>
<t indent="0" pn="section-6.2-3">New entries <bcp14>MUST</bcp14> specify
the bit position, the transport protocol description, a mnemonic, and a referen
ce as shown in <xref target="tab-iana" format="default" sectionFormat="of" deriv
edContent="Table 2"/>.</t>
<t indent="0" pn="section-6.2-4">Changes to the format or policies of th
e registry are managed by the IETF via the IESG.</t>
<t indent="0" pn="section-6.2-5">Future code points are assigned under R
FC Required per <xref target="RFC8126" format="default" sectionFormat="of" deriv
edContent="RFC8126"/>. The initial registry is as specified in <xref target="tab
-iana" format="default" sectionFormat="of" derivedContent="Table 2"/> below.</t>
<table anchor="tab-iana" align="center" pn="table-2">
<name slugifiedName="name-supported-transport-registr">Supported Trans
port Registry</name>
<thead>
<tr>
<th align="left" colspan="1" rowspan="1">Bit Position (least to mo
st significant)</th>
<th align="left" colspan="1" rowspan="1">Transport Protocol Descri
ption</th>
<th align="left" colspan="1" rowspan="1">Mnemonic</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left" colspan="1" rowspan="1">0</td>
<td align="left" colspan="1" rowspan="1">DNS over mutually authent
icated TLS</td>
<td align="left" colspan="1" rowspan="1">DomTLS</td>
<td align="left" colspan="1" rowspan="1">RFC 9527</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">1-15</td>
<td align="left" colspan="1" rowspan="1">Unassigned</td>
<td align="left" colspan="1" rowspan="1"/>
<td align="left" colspan="1" rowspan="1"/>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="security-considerations" numbered="true" toc="include" remo
veInRFC="false" pn="section-7">
<name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-7-1">The security considerations in <xref target
="RFC8415" format="default" sectionFormat="of" derivedContent="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 con
figured via DHCPv6.</t>
<t indent="0" pn="section-7-2">In some cases, the ISP <bcp14>MAY</bcp14> i
dentify the HNA by its wire line (i.e., physically), which may not require relyi
ng on TLS to authenticate the HNA. As the use of TLS is mandatory, it is expecte
d that the HNA will be provisioned with a certificate.
In some cases, the HNA may use a self-signed certificate.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.andrews-dnsop-pd-reverse" to="PD-REVERSE"/>
<displayreference target="I-D.sury-dnsop-cname-plus-dname" to="CNAME-PLUS-DN
AME"/>
<references pn="section-8">
<name slugifiedName="name-references">References</name>
<references pn="section-8.1">
<name slugifiedName="name-normative-references">Normative References</na
me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often cap
italized. This document defines these words as they should be interpreted in IET
F documents. This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for improvements.</t
>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7
858" quoteTitle="true" derivedAnchor="RFC7858">
<front>
<title>Specification for DNS over Transport Layer Security (TLS)</ti
tle>
<author fullname="Z. Hu" initials="Z." surname="Hu"/>
<author fullname="L. Zhu" initials="L." surname="Zhu"/>
<author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
<author fullname="A. Mankin" initials="A." surname="Mankin"/>
<author fullname="D. Wessels" initials="D." surname="Wessels"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="May" year="2016"/>
<abstract>
<t indent="0">This document describes the use of Transport Layer S
ecurity (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates
opportunities for eavesdropping and on-path tampering with DNS queries in the ne
twork, such as discussed in RFC 7626. In addition, this document specifies two u
sage profiles for DNS over TLS and provides advice on performance considerations
to minimize overhead from using TCP and TLS with DNS.</t>
<t indent="0">This document focuses on securing stub-to-recursive
traffic, as per the charter of the DPRIVE Working Group. It does not prevent fut
ure applications of the protocol to recursive-to-authoritative traffic.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7858"/>
<seriesInfo name="DOI" value="10.17487/RFC7858"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" quoteTitle="true" derivedAnchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t indent="0">Many protocols make use of points of extensibility t
hat use constants to identify various protocol parameters. To ensure that the va
lues in these fields do not have conflicting uses and to promote interoperabilit
y, their allocations are often coordinated by a central record keeper. For IETF
protocols, that role is filled by the Internet Assigned Numbers Authority (IANA)
.</t>
<t indent="0">To make assignments in a given registry prudently, g
uidance describing the conditions under which new values should be assigned, as
well as when and how modifications to existing values can be made, is needed. Th
is document defines a framework for the documentation of these guidelines by spe
cification authors, in order to assure that the provided guidance for the IANA C
onsiderations is clear and addresses the various issues that are likely in the o
peration of a registry.</t>
<t indent="0">This is the third edition of this document; it obsol
etes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by clari
fying that only UPPERCASE usage of the key words have the defined special meanin
gs.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8415" target="https://www.rfc-editor.org/info/rfc8
415" quoteTitle="true" derivedAnchor="RFC8415">
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
<author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
<author fullname="B. Volz" initials="B." surname="Volz"/>
<author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko
"/>
<author fullname="M. Richardson" initials="M." surname="Richardson"/
>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<author fullname="T. Lemon" initials="T." surname="Lemon"/>
<author fullname="T. Winters" initials="T." surname="Winters"/>
<date month="November" year="2018"/>
<abstract>
<t indent="0">This document describes the Dynamic Host Configurati
on Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes wit
h network configuration parameters, IP addresses, and prefixes. Parameters can b
e provided statelessly, or in combination with stateful assignment of one or mor
e IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or
in addition to stateless address autoconfiguration (SLAAC).</t>
<t indent="0">This document updates the text from RFC 3315 (the or
iginal DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stat
eless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a clie
nt should wait before refreshing information (RFC 4242), a mechanism for throttl
ing DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay ag
ent handling of unknown messages (RFC 7283). In addition, this document clarifie
s the interactions between models of operation (RFC 7550). As such, this documen
t obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC
7550.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8415"/>
<seriesInfo name="DOI" value="10.17487/RFC8415"/>
</reference>
<reference anchor="RFC9103" target="https://www.rfc-editor.org/info/rfc9
103" quoteTitle="true" derivedAnchor="RFC9103">
<front>
<title>DNS Zone Transfer over TLS</title>
<author fullname="W. Toorop" initials="W." surname="Toorop"/>
<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
<author fullname="S. Sahib" initials="S." surname="Sahib"/>
<author fullname="P. Aras" initials="P." surname="Aras"/>
<author fullname="A. Mankin" initials="A." surname="Mankin"/>
<date month="August" year="2021"/>
<abstract>
<t indent="0">DNS zone transfers are transmitted in cleartext, whi
ch gives attackers the opportunity to collect the content of a zone by eavesdrop
ping on network connections. The DNS Transaction Signature (TSIG) mechanism is s
pecified to restrict direct zone transfer to authorized clients only, but it doe
s not add confidentiality. This document specifies the use of TLS, rather than c
leartext, to prevent zone content collection via passive monitoring of zone tran
sfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and
RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with res
pect to the recommended number of connections between a client and server for ea
ch transport.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9103"/>
<seriesInfo name="DOI" value="10.17487/RFC9103"/>
</reference>
<reference anchor="RFC9526" target="https://www.rfc-editor.org/info/rfc9
526" quoteTitle="true" derivedAnchor="RFC9526">
<front>
<title>Simple Provisioning of Public Names for Residential Networks<
/title>
<author initials="D" surname="Migault" fullname="Daniel Migault">
<organization showOnFrontPage="true"/>
</author>
<author initials="R" surname="Weber" fullname="Ralf Weber">
<organization showOnFrontPage="true"/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richards
on">
<organization showOnFrontPage="true"/>
</author>
<author initials="R" surname="Hunter" fullname="Ray Hunter">
<organization showOnFrontPage="true"/>
</author>
<date year="2024" month="January"/>
</front>
<seriesInfo name="RFC" value="9526"/>
<seriesInfo name="DOI" value="10.17487/RFC9526"/>
</reference>
</references>
<references pn="section-8.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="I-D.sury-dnsop-cname-plus-dname" target="https://data
tracker.ietf.org/doc/html/draft-sury-dnsop-cname-plus-dname-01" quoteTitle="true
" derivedAnchor="CNAME-PLUS-DNAME">
<front>
<title>CNAME+DNAME Name Redirection</title>
<author initials="O." surname="Surý" fullname="Ondřej Surý">
<organization showOnFrontPage="true">Internet Systems Consortium</
organization>
</author>
<date month="July" day="15" year="2018"/>
<abstract>
<t indent="0"> This document updates RFC1034 to allow coexistenc
e of the CNAME
Resource Record with DNAME Resource Record at the same owner node,
which provides redirection for a sub-tree of the domain name tree in
the DNS system, in a parent zone. By allowing this cooexistence, DNS
system will have a way how to create a sub-tree redirection together
that includes the Resource Records owner name. This would allow
parent zones to create full domain aliases.
<references title='Normative References'> </t>
</abstract>
&RFC2119; </front>
&RFC8174; <seriesInfo name="Internet-Draft" value="draft-sury-dnsop-cname-plus-d
&I-D.ietf-homenet-front-end-naming-delegation; name-01"/>
&RFC8415; <refcontent>Work in Progress</refcontent>
&RFC7858; </reference>
&RFC9103; <reference anchor="I-D.andrews-dnsop-pd-reverse" target="https://datatra
&RFC8126; cker.ietf.org/doc/html/draft-andrews-dnsop-pd-reverse-02" quoteTitle="true" deri
vedAnchor="PD-REVERSE">
</references> <front>
<title>Automated Delegation of IP6.ARPA reverse zones with Prefix De
<references title='Informative References'> legation</title>
<author fullname="Mark P. Andrews" initials="M." surname="Andrews">
&RFC7368; <organization showOnFrontPage="true">ISC</organization>
&RFC7227; </author>
&I-D.andrews-dnsop-pd-reverse; <date day="5" month="November" year="2013"/>
&RFC2181; </front>
&RFC1034; <seriesInfo name="Internet-Draft" value="draft-andrews-dnsop-pd-revers
&RFC6672; e-02"/>
&I-D.sury-dnsext-cname-dname; <refcontent>Work in Progress</refcontent>
</reference>
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1
034" quoteTitle="true" derivedAnchor="RFC1034">
<front>
<title>Domain names - concepts and facilities</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris
"/>
<date month="November" year="1987"/>
<abstract>
<t indent="0">This RFC is the revised basic definition of The Doma
in Name System. It obsoletes RFC-882. This memo describes the domain style names
and their used for host address look up and electronic mail forwarding. It disc
usses the clients and servers in the domain name system and the protocol used be
tween them.</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1034"/>
<seriesInfo name="DOI" value="10.17487/RFC1034"/>
</reference>
<reference anchor="RFC2181" target="https://www.rfc-editor.org/info/rfc2
181" quoteTitle="true" derivedAnchor="RFC2181">
<front>
<title>Clarifications to the DNS Specification</title>
<author fullname="R. Elz" initials="R." surname="Elz"/>
<author fullname="R. Bush" initials="R." surname="Bush"/>
<date month="July" year="1997"/>
<abstract>
<t indent="0">This document considers some areas that have been id
entified as problems with the specification of the Domain Name System, and propo
ses remedies for the defects identified. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2181"/>
<seriesInfo name="DOI" value="10.17487/RFC2181"/>
</reference>
<reference anchor="RFC6672" target="https://www.rfc-editor.org/info/rfc6
672" quoteTitle="true" derivedAnchor="RFC6672">
<front>
<title>DNAME Redirection in the DNS</title>
<author fullname="S. Rose" initials="S." surname="Rose"/>
<author fullname="W. Wijngaards" initials="W." surname="Wijngaards"/
>
<date month="June" year="2012"/>
<abstract>
<t indent="0">The DNAME record provides redirection for a subtree
of the domain name tree in the DNS. That is, all names that end with a particula
r suffix are redirected to another part of the DNS. This document obsoletes the
original specification in RFC 2672 as well as updates the document on representi
ng IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6672"/>
<seriesInfo name="DOI" value="10.17487/RFC6672"/>
</reference>
<reference anchor="RFC7227" target="https://www.rfc-editor.org/info/rfc7
227" quoteTitle="true" derivedAnchor="RFC7227">
<front>
<title>Guidelines for Creating New DHCPv6 Options</title>
<author fullname="D. Hankins" initials="D." surname="Hankins"/>
<author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
<author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
<date month="May" year="2014"/>
<abstract>
<t indent="0">This document provides guidance to prospective DHCPv
6 option developers to help them create option formats that are easily adoptable
by existing DHCPv6 software. It also provides guidelines for expert reviewers t
o evaluate new registrations. This document updates RFC 3315.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="187"/>
<seriesInfo name="RFC" value="7227"/>
<seriesInfo name="DOI" value="10.17487/RFC7227"/>
</reference>
<reference anchor="RFC7368" target="https://www.rfc-editor.org/info/rfc7
368" quoteTitle="true" derivedAnchor="RFC7368">
<front>
<title>IPv6 Home Networking Architecture Principles</title>
<author fullname="T. Chown" initials="T." role="editor" surname="Cho
wn"/>
<author fullname="J. Arkko" initials="J." surname="Arkko"/>
<author fullname="A. Brandt" initials="A." surname="Brandt"/>
<author fullname="O. Troan" initials="O." surname="Troan"/>
<author fullname="J. Weil" initials="J." surname="Weil"/>
<date month="October" year="2014"/>
<abstract>
<t indent="0">This text describes evolving networking technology w
ithin residential home networks with increasing numbers of devices and a trend t
owards increased internal routing. The goal of this document is to define a gene
ral architecture for IPv6-based home networking, describing the associated princ
iples, considerations, and requirements. The text briefly highlights specific im
plications of the introduction of IPv6 for home networking, discusses the elemen
ts of the architecture, and suggests how standard IPv6 mechanisms and addressing
can be employed in home networking. The architecture describes the need for spe
cific protocol extensions for certain additional functionality. It is assumed th
at the IPv6 home network is not actively managed and runs as an IPv6-only or dua
l-stack network. There are no recommendations in this text for the IPv4 part of
the network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7368"/>
<seriesInfo name="DOI" value="10.17487/RFC7368"/>
</reference>
</references>
</references> </references>
<section anchor="sec-scenario" numbered="true" toc="include" removeInRFC="fa
<section anchor="sec-scenario" title="Scenarios and impact on the End User"> lse" pn="section-appendix.a">
<name slugifiedName="name-scenarios-and-impact-on-the">Scenarios and Impac
<t>This appendix details various scenarios and discuss their impact on the end u t on the End User</name>
ser. <t indent="0" pn="section-appendix.a-1">This appendix details various scen
arios and discusses their impact on the end user.
This appendix is not normative and limits the description of a limited scope of scenarios that are assumed to be representative. Many other scenarios may be 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="include" removeInRFC
<section anchor="sec-scenario-1" title="Base Scenario"> ="false" pn="section-appendix.a.1">
<name slugifiedName="name-base-scenario">Base Scenario</name>
<t>The base scenario is the one described in <xref target="sec-overview"/> in wh <t indent="0" pn="section-appendix.a.1-1">The base scenario, as describe
ich an ISP manages the DHCPv6 server, the DM and RDM.</t> d in <xref target="sec-overview" format="default" sectionFormat="of" derivedCont
ent="Section 3"/>, is one in which an ISP manages the DHCPv6 server, DM, and RDM
<t>The end user subscribes to the ISP (foo), and at subscription time registers .</t>
for foo.example as its Registered Homenet Domain foo.example.</t> <t indent="0" pn="section-appendix.a.1-2">The end user subscribes to the
ISP (foo), and at subscription time, it registers foo.example as its Registered
<t>In this scenario, the DHCPv6 server, DM and RDM are managed by the ISP so the Homenet Domain.</t>
DHCPv6 server and as such can provide authentication credentials of the HNA to <t indent="0" pn="section-appendix.a.1-3">In this scenario, the DHCPv6 s
enable secure authenticated transaction with the DM and the Reverse DM.</t> erver, DM, and RDM are managed by the ISP, so the DHCPv6 server and such can pro
vide authentication credentials of the HNA to enable secure authenticated transa
<t>The main advantage of this scenario is that the naming architecture is config ction with the DM and the Reverse DM.</t>
ured automatically and transparently for the end user. <t indent="0" pn="section-appendix.a.1-4">The main advantage of this sce
The drawbacks are that the end user uses a Registered Homenet Domain managed by nario is that the naming architecture is configured automatically and transparen
the ISP and that it relies on the ISP naming infrastructure.</t> tly for the end user. The drawbacks are that the end user uses a Registered Home
net Domain managed by the ISP and that it relies on the ISP naming infrastructur
</section> e.</t>
<section anchor="scenario-2" title="Third Party Registered Homenet Domain"> </section>
<section anchor="scenario-2" numbered="true" toc="include" removeInRFC="fa
<t>This appendix considers the case when the end user wants its home network to lse" pn="section-appendix.a.2">
use example.com not managed by her ISP (foo) as a Registered Homenet Domain. <name slugifiedName="name-third-party-registered-home">Third-Party Regis
This appendix still considers the ISP manages the home network and still provide tered Homenet Domain</name>
s foo.example as a Registered Homenet Domain.</t> <t indent="0" pn="section-appendix.a.2-1">This appendix considers the ca
se where the end user wants its home network to use example.com but does not wan
<t>When the end user buys the domain name example.com, it may request to redirec t it to be managed by the ISP (foo) as a Registered Homenet Domain, and the ISP
t the name example.com to foo.example using static redirection with CNAME <xref manages the home network and still provides foo.example as a Registered Homenet
target="RFC2181"/>, <xref target="RFC1034"/>, DNAME <xref target="RFC6672"/> or Domain.</t>
CNAME+DNAME <xref target="I-D.sury-dnsext-cname-dname"/>. <t indent="0" pn="section-appendix.a.2-2">When the end user buys the dom
The only information the end user needs to know is the domain name assigned by t ain name example.com, it may request to redirect example.com to foo.example usin
he ISP. g static redirection with CNAME <xref target="RFC1034" format="default" sectionF
Once the redirection has been configured, the HNA may be changed, the zone can b ormat="of" derivedContent="RFC1034"/> <xref target="RFC2181" format="default" se
e updated as in <xref target="sec-scenario-1"/> without any additional configura ctionFormat="of" derivedContent="RFC2181"/>, DNAME <xref target="RFC6672" format
tion from the end user.</t> ="default" sectionFormat="of" derivedContent="RFC6672"/>, or CNAME+DNAME <xref t
arget="I-D.sury-dnsop-cname-plus-dname" format="default" sectionFormat="of" deri
<t>The main advantage of this scenario is that the end user benefits from the Ze vedContent="CNAME-PLUS-DNAME"/>.
ro Configuration of the Base Scenario <xref target="sec-scenario-1"/>. The only information the end user needs to know is the domain name assigned by t
Then, the end user is able to register for its home network an unlimited number he ISP. Once the redirection has been configured, the HNA may be changed, and th
of domain names provided by an unlimited number of different third party provide e zone can be updated as described in <xref target="sec-scenario-1" format="defa
rs. ult" sectionFormat="of" derivedContent="Appendix A.1"/> without any additional c
The drawback of this scenario may be that the end user still rely on the ISP nam onfiguration from the end user.</t>
ing infrastructure. <t indent="0" pn="section-appendix.a.2-3">The main advantage of this sce
Note that the only case this may be inconvenient is when the DNS servers provide nario is that the end user benefits from the zero configuration of the base scen
d by the ISPs results in high latency.</t> ario in <xref target="sec-scenario-1" format="default" sectionFormat="of" derive
dContent="Appendix A.1"/>. Then, the end user is able to register an unlimited n
</section> umber of domain names provided by an unlimited number of different third-party p
<section anchor="scenario-3" title="Third Party DNS Infrastructure"> roviders for its home network. The drawback of this scenario may be that the end
user still needs to rely on the ISP naming infrastructure. Note that this may b
<t>This scenario considers that the end user uses example.com as a Registered Ho e inconvenient in the case where the DNS servers provided by the ISPs result in
menet Domain, and does not want to rely on the authoritative servers provided by high latency.</t>
the ISP.</t> </section>
<section anchor="scenario-3" numbered="true" toc="include" removeInRFC="fa
<t>In this appendix we limit the outsourcing to the DM and Public Authoritative lse" pn="section-appendix.a.3">
Server(s) to a third party. <name slugifiedName="name-third-party-dns-infrastruct">Third-Party DNS I
The Reverse Public Authoritative Server(s) and the RDM remain managed by the ISP nfrastructure</name>
as the IP prefix is managed by the ISP.</t> <t indent="0" pn="section-appendix.a.3-1">This scenario involves the end
user using example.com as a Registered Homenet Domain and not relying on the au
<t>Outsourcing to a third party DM can be performed in the following ways:</t> thoritative servers provided by the ISP.</t>
<t indent="0" pn="section-appendix.a.3-2">In this appendix, we limit the
<t><list style="numbers"> outsourcing of the DM and Public Authoritative Server(s) to a third party. The
<t>Updating the DHCPv6 server Information. One can imagine a GUI interface tha Reverse Public Authoritative Server(s) and the RDM remain managed by the ISP as
t enables the end user to modify its profile parameters. Again, this configurati the IP prefix is managed by the ISP.</t>
on update is done once-for-ever.</t> <t indent="0" pn="section-appendix.a.3-3">Outsourcing to a third-party D
<t>Upload the configuration of the DM to the HNA. In some cases, the provider M can be performed in the following ways:</t>
of the CPE router hosting the HNA may be the registrar and provide the CPE route <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-ap
r already configured. In other cases, the CPE router may request the end user to pendix.a.3-4">
log into the registrar to validate the ownership of the Registered Homenet Doma <li pn="section-appendix.a.3-4.1" derivedCounter="1.">Updating the DHCP
in and agree on the necessary credentials to secure the communication between th v6 server information. One can imagine a GUI interface that enables the end user
e HNA and the DM. As described in <xref target="I-D.ietf-homenet-front-end-namin to modify its profile parameters. Again, this configuration update only needs t
g-delegation"/>, such settings could be performed in an almost automatic way as o be performed one time.</li>
to limit the necessary interactions with the end user.</t> <li pn="section-appendix.a.3-4.2" derivedCounter="2.">Uploading the co
</list></t> nfiguration of the DM to the HNA. In some cases, the provider of the CPE router
hosting the HNA may be the registrar, and the registrar may provide the CPE rout
</section> er already configured. In other cases, the CPE router may request the end user t
<section anchor="scenario-4" title="Multiple ISPs"> o log into the registrar to validate the ownership of the Registered Homenet Dom
ain and agree on the necessary credentials to secure the communication between t
<t>This scenario considers a HNA connected to multiple ISPs.</t> he HNA and the DM. As described in <xref target="RFC9526" format="default" secti
onFormat="of" derivedContent="RFC9526"/>, such settings could be performed in an
<t>Suppose the HNA has been configured each of its interfaces independently with almost automatic way as to limit the necessary interactions with the end user.<
each ISPS as described in <xref target="sec-scenario-1"/>. /li>
</ol>
</section>
<section anchor="scenario-4" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-appendix.a.4">
<name slugifiedName="name-multiple-isps">Multiple ISPs</name>
<t indent="0" pn="section-appendix.a.4-1">This scenario involves an HNA
connected to multiple ISPs.</t>
<t indent="0" pn="section-appendix.a.4-2">Suppose the HNA has configured
each of its interfaces independently with each ISP as described in <xref target
="sec-scenario-1" format="default" sectionFormat="of" derivedContent="Appendix A
.1"/>.
Each ISP provides a different Registered Homenet Domain.</t> Each ISP provides a different Registered Homenet Domain.</t>
<t indent="0" pn="section-appendix.a.4-3">The protocol and DHCPv6 option
<t>The protocol and DHCPv6 options described in this document are fully compatib s described in this document are fully compatible with an HNA connected to multi
le with a HNA connected to multiple ISPs with multiple Registered Homenet Domain ple ISPs with multiple Registered Homenet 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 indent="0" pn="section-appendix.a.4-4">If an HNA is not able to handl
<t>If a HNA is not able to handle multiple Registered Homenet Domains, the HNA m e multiple Registered Homenet Domains, the HNA may remain connected to multiple
ay remain connected to multiple ISP with a single Registered Homenet Domain. ISPs with a single Registered Homenet Domain. In this case, one entity is chosen
In this case, one entity is chosen to host the Registered Homenet Domain. to host the Registered Homenet Domain. This entity may be an ISP or a third par
This entity may be one of the ISP or a third party. ty.
Note that having multiple ISPs can be motivated for bandwidth aggregation, or co Note that having multiple ISPs can be motivation for bandwidth aggregation or co
nnectivity fail-over. nnectivity failover.
In the case of connectivity fail-over, the fail-over concerns the access network In the case of connectivity failover, the failover concerns the access network,
and a failure of the access network may not impact the core network where the D and a failure of the access network may not impact the core network where the DM
M and Public Authoritative Primaries are hosted. and Public Authoritative Primaries are hosted. In that sense, choosing one of t
In that sense, choosing one of the ISP even in a scenario of multiple ISPs may m he ISPs even in a scenario of multiple ISPs may make sense.
ake sense. However, for the sake of simplicity, this scenario assumes that a third party ha
However, for sake of simplicity, this scenario assumes that a third party has be s been chosen to host the Registered Homenet Domain. Configuration is performed
en chosen to host the Registered Homenet Domain. as described in Appendices <xref target="scenario-2" format="counter" sectionFor
Configuration is performed as described in <xref target="scenario-2"/> and <xref mat="of" derivedContent="A.2"/> and <xref target="scenario-3" format="counter" s
target="scenario-3"/>.</t> ectionFormat="of" derivedContent="A.3"/>.</t>
<t indent="0" pn="section-appendix.a.4-5">With the configuration describ
<t>With the configuration described in <xref target="scenario-2"/>, the HNA is ed in <xref target="scenario-2" format="default" sectionFormat="of" derivedConte
expected to be able to handle multiple Homenet Registered Domain, as the third p nt="Appendix A.2"/>, the HNA is expected to be able to handle multiple Registere
arty redirect to one of the ISPs servers. d Homenet Domains as the third-party redirect to one of the ISP's servers. With
With the configuration described in <xref target="scenario-3"/>, DNS zone are ho the configuration described in <xref target="scenario-3" format="default" sectio
sted and maintained by the third party. nFormat="of" derivedContent="Appendix A.3"/>, DNS zones are hosted and maintaine
A single DNS(SEC) Homenet Zone is built and maintained by the HNA. d by the third party. A single DNS(SEC) Homenet Zone is built and maintained by
This latter configuration is likely to match most HNA implementations.</t> 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 compatib <t indent="0" pn="section-appendix.a.4-6">The protocol and DHCPv6 option
le with a HNA connected to multiple ISPs. s described in this document are fully compatible with an HNA connected to multi
To configure or not and how to configure the HNA depends on the HNA facilities. ple ISPs. Whether to configure the HNA or not, and how to configure the HNA, dep
<xref target="sec-scenario-1"/> and <xref target="scenario-2"/> require the HNA ends on the HNA facilities. Appendices <xref target="sec-scenario-1" format="cou
to handle multiple Registered Homenet Domain, whereas <xref target="scenario-3" nter" sectionFormat="of" derivedContent="A.1"/> and <xref target="scenario-2" fo
/> does not have such requirement.</t> rmat="counter" sectionFormat="of" derivedContent="A.2"/> require the HNA to hand
le multiple Registered Homenet Domains, whereas <xref target="scenario-3" format
</section> ="default" sectionFormat="of" derivedContent="Appendix A.3"/> does not have such
</section> a requirement.</t>
</section>
<section anchor="acknowledgments" numbered="false" toc="include" removeInR
FC="false" pn="section-appendix.a.5">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.a.5-1">We would like to thank <contac
t fullname="Marcin Siodelski"/>, <contact fullname="Bernie Volz"/>, and <contact
fullname="Ted Lemon"/> for their comments on the design of the DHCPv6 options.
We would also like to thank <contact fullname="Mark Andrews"/>, <contact fullnam
e="Andrew Sullivan"/>, and <contact fullname="Lorenzo Colliti"/> for their remar
ks on the architecture design. The designed solution has been largely inspired b
y <contact fullname="Mark Andrews's"/> document <xref target="I-D.andrews-dnsop-
pd-reverse" format="default" sectionFormat="of" derivedContent="PD-REVERSE"/> as
well as discussions with <contact fullname="Mark"/>. We also thank <contact ful
lname="Ray Hunter"/> and <contact fullname="Michael Richardson"/> for their revi
ews and comments and for suggesting appropriate terminology.</t>
</section>
<section anchor="contributors" numbered="false" toc="include" removeInRFC=
"false" pn="section-appendix.a.6">
<name slugifiedName="name-contributors">Contributors</name>
<t indent="0" pn="section-appendix.a.6-1">The coauthors would like to th
ank <contact fullname="Chris Griffiths"/> and <contact fullname="Wouter Cloetens
"/> for providing significant contributions to the early draft versions of this
document.</t>
</section>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-addresses">Authors' Addresses</name>
<author initials="D." surname="Migault" fullname="Daniel Migault">
<organization showOnFrontPage="true">Ericsson</organization>
<address>
<postal>
<street>8275 Trans Canada Route</street>
<city>Saint Laurent</city>
<region>QC</region>
<code>4S 0B6</code>
<country>Canada</country>
</postal>
<email>daniel.migault@ericsson.com</email>
</address>
</author>
<author initials="R." surname="Weber" fullname="Ralf Weber">
<organization showOnFrontPage="true">Akamai</organization>
<address>
<email>ralf.weber@akamai.com</email>
</address>
</author>
<author initials="T." surname="Mrugalski" fullname="Tomek Mrugalski">
<organization abbrev="ISC" showOnFrontPage="true">Internet Systems Conso
rtium, Inc.</organization>
<address>
<postal>
<street>PO Box 360</street>
<city>Newmarket</city>
<region>NH</region>
<code>03857</code>
<country>United States of America</country>
</postal>
<email>tomasz.mrugalski@gmail.com</email>
</address>
</author>
</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. 28 change blocks. 
731 lines changed or deleted 1237 lines changed or added

This html diff was produced by rfcdiff 1.48.