Diff: rfc9526xml2.original.xml

	rfc9526xml2.original.xml	rfc9526.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-rfc version 1.6.21 (Ruby 3.	cName="draft-ietf-homenet-front-end-naming-delegation-27" number="9526" submissi
	0.2) -->	onType="IETF" category="exp" consensus="true" tocInclude="true" sortRefs="true"
		symRefs="true" updates="" obsoletes="" xml:lang="en" prepTime="2024-01-28T20:37:
	<!DOCTYPE rfc [	15" indexInclude="true" scripts="Common,Latin" tocDepth="3">
	<!ENTITY nbsp " ">	<link href="https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-nami
	<!ENTITY zwsp "">	ng-delegation-27" rel="prev"/>
	<!ENTITY nbhy "‑">	<link href="https://dx.doi.org/10.17487/rfc9526" rel="alternate"/>
	<!ENTITY wj "⁠">	<link href="urn:issn:2070-1721" rel="alternate"/>

	]>

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

	<rfc ipr="trust200902" docName="draft-ietf-homenet-front-end-naming-delegation-2
	7" category="exp" tocInclude="true" sortRefs="true" symRefs="true">
	<front>	<front>

	<title abbrev="public-names">Simple Provisioning of Public Names for Residen	<title abbrev="Public Names for Residential Networks">Simple Provisioning of
	tial Networks</title>	Public Names for Residential Networks</title>
		<seriesInfo name="RFC" value="9526" 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>Nominum</organization>	<organization showOnFrontPage="true">Nominum</organization>
	<address>	<address>
	<postal>	<postal>

	<street>2000 Seaport Blvd</street>	<street>2000 Seaport Blvd.</street>
	<city>Redwood City</city>	<city>Redwood City</city>

		<region>CA</region>
	<code>94063</code>	<code>94063</code>

	<country>US</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>ralf.weber@nominum.com</email>	<email>ralf.weber@nominum.com</email>
	</address>	</address>
	</author>	</author>
	<author initials="M." surname="Richardson" fullname="Michael Richardson">	<author initials="M." surname="Richardson" fullname="Michael Richardson">

	<organization>Sandelman Software Works</organization>	<organization showOnFrontPage="true">Sandelman Software Works</organizatio n>
	<address>	<address>
	<postal>	<postal>
	<street>470 Dawson Avenue</street>	<street>470 Dawson Avenue</street>

	<city>Ottawa, ON</city>	<city>Ottawa</city>
		<region>ON</region>
	<code>K1Z 5V7</code>	<code>K1Z 5V7</code>
	<country>Canada</country>	<country>Canada</country>
	</postal>	</postal>
	<email>mcr+ietf@sandelman.ca</email>	<email>mcr+ietf@sandelman.ca</email>
	</address>	</address>
	</author>	</author>
	<author initials="R." surname="Hunter" fullname="Ray Hunter">	<author initials="R." surname="Hunter" fullname="Ray Hunter">

	<organization>Globis Consulting BV</organization>	<organization showOnFrontPage="true">Globis Consulting BV</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Weegschaalstraat 3</street>	<street>Weegschaalstraat 3</street>
	<city>Eindhoven</city>	<city>Eindhoven</city>
	<code>5632CW</code>	<code>5632CW</code>

	<country>NL</country>	<country>Netherlands</country>
	</postal>	</postal>
	<email>v6ops@globis.net</email>	<email>v6ops@globis.net</email>
	</address>	</address>
	</author>	</author>

		<date month="01" year="2024"/>
	<date year="2023" month="February" day="08"/>

	<area>Internet</area>	<area>Internet</area>
	<workgroup>Homenet</workgroup>	<workgroup>Homenet</workgroup>

	<keyword>Internet-Draft</keyword>	<abstract pn="section-abstract">
		<t indent="0" pn="section-abstract-1">Home network owners may have devices
	<abstract>	or services hosted on their home network that they wish to access from the Inte
		rnet (i.e., from a network outside of the home network). Home networks are incre
	<t>Home network owners may have devices or services hosted on their home network	asingly numbered using IPv6 addresses, which in principle makes this access simp
	that they wish to access from the Internet (i.e., from a network outside of the	ler, but accessing home networks from the Internet requires the names and IP add
	home network).	resses of these devices and services to be made available in the public DNS.</t>
	Home networks are increasingly numbered using IPv6 addresses, which in principle	<t indent="0" pn="section-abstract-2">This document describes how a Home N
	makes this access simpler, but their access from the Internet requires the name	aming Authority (NHA) instructs the outsourced infrastructure to publish these p
	s and IP addresses of these devices and services to be made available in the pu	ieces of information in the public DNS.
	blic DNS.</t>

	<t>This document describes how an Home Naming Authority (NHA) instructs the outs
	ourced infrastructure to publish these pieces of information in the public DNS.
	The names and IP addresses of the home network are set in the Public Homenet Zon e by the Homenet Naming Authority (HNA), which in turn instructs an outsourced i nfrastructure to publish the zone on behalf of the home network owner.</t>	The names and IP addresses of the home network are set in the Public Homenet Zon e by the Homenet Naming Authority (HNA), which in turn instructs an outsourced i nfrastructure to publish the zone on behalf of the home network owner.</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 document is not an Internet Standards Track specification; it i
		s
		published for examination, experimental implementation, and
		evaluation.
		</t>
		<t indent="0" pn="section-boilerplate.1-2">
		This document defines an Experimental Protocol for the Internet
		community. This document is a product of the Internet Engineering
		Task Force (IETF). It represents the consensus of the IETF communit
		y.
		It has received public review and has been approved for publication
		by the Internet Engineering Steering Group (IESG). Not all document
		s
		approved by the IESG are candidates for any level of Internet
		Standard; see 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/rfc9526" 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-selecting-name
		s-and-address">Selecting Names and Addresses to Publish</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-envisioned-deployment-scena">Envis
		ioned Deployment Scenarios</xref></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-cpe-vendor">CPE Vendor
		</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-agnostic-cpe">Agnostic
		CPE</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-architecture-description">Architec
		ture Description</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-architecture-overview"
		>Architecture Overview</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-distribution-manager-d
		m-com">Distribution Manager (DM) Communication Channels</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-control-channel">Control Channel</
		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-building-the-public-ho
		menet">Building the Public Homenet Zone</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-building-the-dnssec-ch
		ain-o">Building the DNSSEC Chain of Trust</xref></t>
		</li>
		<li pn="section-toc.1-1.6.2.3">
		<t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent=
		"6.3" format="counter" sectionFormat="of" target="section-6.3"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-setting-up-the-synchro
		nizat">Setting Up the Synchronization Channel</xref></t>
		</li>
		<li pn="section-toc.1-1.6.2.4">
		<t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent=
		"6.4" format="counter" sectionFormat="of" target="section-6.4"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-deleting-the-delegatio
		n">Deleting the Delegation</xref></t>
		</li>
		<li pn="section-toc.1-1.6.2.5">
		<t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent=
		"6.5" format="counter" sectionFormat="of" target="section-6.5"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-message-exchange-descr
		iptio">Message Exchange Description</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
		ction-toc.1-1.6.2.5.2">
		<li pn="section-toc.1-1.6.2.5.2.1">
		<t indent="0" pn="section-toc.1-1.6.2.5.2.1.1"><xref derived
		Content="6.5.1" format="counter" sectionFormat="of" target="section-6.5.1"/>. <
		xref derivedContent="" format="title" sectionFormat="of" target="name-retrieving
		-information-for-">Retrieving Information for the Public Homenet Zone</xref></t>
		</li>
		<li pn="section-toc.1-1.6.2.5.2.2">
		<t indent="0" pn="section-toc.1-1.6.2.5.2.2.1"><xref derived
		Content="6.5.2" format="counter" sectionFormat="of" target="section-6.5.2"/>. <
		xref derivedContent="" format="title" sectionFormat="of" target="name-providing-
		information-for-t">Providing Information for the DNSSEC Chain of Trust</xref></t
		>
		</li>
		<li pn="section-toc.1-1.6.2.5.2.3">
		<t indent="0" pn="section-toc.1-1.6.2.5.2.3.1"><xref derived
		Content="6.5.3" format="counter" sectionFormat="of" target="section-6.5.3"/>. <
		xref derivedContent="" format="title" sectionFormat="of" target="name-providing-
		information-for-th">Providing Information for the Synchronization Channel</xref>
		</t>
		</li>
		<li pn="section-toc.1-1.6.2.5.2.4">
		<t indent="0" pn="section-toc.1-1.6.2.5.2.4.1"><xref derived
		Content="6.5.4" format="counter" sectionFormat="of" target="section-6.5.4"/>. <
		xref derivedContent="" format="title" sectionFormat="of" target="name-initiating
		-deletion-of-the-">Initiating Deletion of the Delegation</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.6.2.6">
		<t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent=
		"6.6" format="counter" sectionFormat="of" target="section-6.6"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-securing-the-control-c
		hanne">Securing the Control Channel</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-synchronization-channel">Synchroni
		zation Channel</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.7.2">
		<li pn="section-toc.1-1.7.2.1">
		<t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent=
		"7.1" format="counter" sectionFormat="of" target="section-7.1"/>. <xref derived
		Content="" format="title" sectionFormat="of" target="name-securing-the-synchroni
		zatio">Securing the Synchronization Channel</xref></t>
		</li>
		</ul>
		</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-dm-distribution-channel">DM Distri
		bution Channel</xref></t>
		</li>
		<li pn="section-toc.1-1.9">
		<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
		at="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" f
		ormat="title" sectionFormat="of" target="name-hna-security-policies">HNA Securit
		y Policies</xref></t>
		</li>
		<li pn="section-toc.1-1.10">
		<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
		rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-public-homenet-reverse-zone">Pub
		lic Homenet Reverse Zone</xref></t>
		</li>
		<li pn="section-toc.1-1.11">
		<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
		rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-dnssec-compliant-homenet-ar">DNS
		SEC-Compliant Homenet Architecture</xref></t>
		</li>
		<li pn="section-toc.1-1.12">
		<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
		rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-renumbering">Renumbering</xref><
		/t>
		</li>
		<li pn="section-toc.1-1.13">
		<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
		rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-privacy-considerations">Privacy
		Considerations</xref></t>
		</li>
		<li pn="section-toc.1-1.14">
		<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
		rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-security-considerations">Securit
		y Considerations</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.14.2">
		<li pn="section-toc.1-1.14.2.1">
		<t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent
		="14.1" format="counter" sectionFormat="of" target="section-14.1"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-registered-homenet-
		domain">Registered Homenet Domain</xref></t>
		</li>
		<li pn="section-toc.1-1.14.2.2">
		<t indent="0" pn="section-toc.1-1.14.2.2.1"><xref derivedContent
		="14.2" format="counter" sectionFormat="of" target="section-14.2"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-hna-dm-channels">HN
		A DM Channels</xref></t>
		</li>
		<li pn="section-toc.1-1.14.2.3">
		<t indent="0" pn="section-toc.1-1.14.2.3.1"><xref derivedContent
		="14.3" format="counter" sectionFormat="of" target="section-14.3"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-names-are-less-secu
		re-than-">Names Are Less Secure than IP Addresses</xref></t>
		</li>
		<li pn="section-toc.1-1.14.2.4">
		<t indent="0" pn="section-toc.1-1.14.2.4.1"><xref derivedContent
		="14.4" format="counter" sectionFormat="of" target="section-14.4"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-names-are-less-vola
		tile-tha">Names Are Less Volatile than IP Addresses</xref></t>
		</li>
		<li pn="section-toc.1-1.14.2.5">
		<t indent="0" pn="section-toc.1-1.14.2.5.1"><xref derivedContent
		="14.5" format="counter" sectionFormat="of" target="section-14.5"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-deployment-consider
		ations">Deployment Considerations</xref></t>
		</li>
		<li pn="section-toc.1-1.14.2.6">
		<t indent="0" pn="section-toc.1-1.14.2.6.1"><xref derivedContent
		="14.6" format="counter" sectionFormat="of" target="section-14.6"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-operational-conside
		rations">Operational Considerations</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.15">
		<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" fo
		rmat="counter" sectionFormat="of" target="section-15"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-iana-considerations">IANA Consid
		erations</xref></t>
		</li>
		<li pn="section-toc.1-1.16">
		<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="16" fo
		rmat="counter" sectionFormat="of" target="section-16"/>. <xref derivedContent=""
		format="title" sectionFormat="of" target="name-references">References</xref></t
		>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.16.2">
		<li pn="section-toc.1-1.16.2.1">
		<t indent="0" pn="section-toc.1-1.16.2.1.1"><xref derivedContent
		="16.1" format="counter" sectionFormat="of" target="section-16.1"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-normative-reference
		s">Normative References</xref></t>
		</li>
		<li pn="section-toc.1-1.16.2.2">
		<t indent="0" pn="section-toc.1-1.16.2.2.1"><xref derivedContent
		="16.2" format="counter" sectionFormat="of" target="section-16.2"/>. <xref deri
		vedContent="" format="title" sectionFormat="of" target="name-informative-referen
		ces">Informative References</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.17">
		<t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="Append
		ix A" format="default" sectionFormat="of" target="section-appendix.a"/>. <xref
		derivedContent="" format="title" sectionFormat="of" target="name-hna-channel-con
		figurations">HNA Channel Configurations</xref></t>
		<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
		n-toc.1-1.17.2">
		<li pn="section-toc.1-1.17.2.1">
		<t indent="0" pn="section-toc.1-1.17.2.1.1"><xref derivedContent
		="A.1" format="counter" sectionFormat="of" target="section-appendix.a.1"/>. <xr
		ef derivedContent="" format="title" sectionFormat="of" target="name-public-homen
		et-zone">Public Homenet Zone</xref></t>
		</li>
		</ul>
		</li>
		<li pn="section-toc.1-1.18">
		<t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="Append
		ix B" format="default" sectionFormat="of" target="section-appendix.b"/>. <xref
		derivedContent="" format="title" sectionFormat="of" target="name-information-mod
		el-for-outso">Information Model for Outsourced Information</xref></t>
		</li>
		<li pn="section-toc.1-1.19">
		<t indent="0" pn="section-toc.1-1.19.1"><xref derivedContent="Append
		ix C" format="default" sectionFormat="of" target="section-appendix.c"/>. <xref
		derivedContent="" format="title" sectionFormat="of" target="name-example-a-manuf
		acturer-prov">Example: A Manufacturer-Provisioned HNA Product Flow</xref></t>
		</li>
		<li pn="section-toc.1-1.20">
		<t indent="0" pn="section-toc.1-1.20.1"><xref derivedContent="" form
		at="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="
		" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
		s</xref></t>
		</li>
		<li pn="section-toc.1-1.21">
		<t indent="0" pn="section-toc.1-1.21.1"><xref derivedContent="" form
		at="none" sectionFormat="of" target="section-appendix.e"/><xref derivedContent="
		" format="title" sectionFormat="of" target="name-contributors">Contributors</xre
		f></t>
		</li>
		<li pn="section-toc.1-1.22">
		<t indent="0" pn="section-toc.1-1.22.1"><xref derivedContent="" form
		at="none" sectionFormat="of" target="section-appendix.f"/><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" removeInRFC="false" toc="incl
	<section anchor="introduction"><name>Introduction</name>	ude" pn="section-1">
		<name slugifiedName="name-introduction">Introduction</name>
	<t>Home network owners may have devices or services hosted on their home network	<t indent="0" pn="section-1-1">Home network owners may have devices or ser
		vices hosted on their home network
	that they wish to access from the Internet (i.e., from a network outside of the	that they wish to access from the Internet (i.e., from a network outside of the
	home network).	home network).

	The use of IPv6 addresesses in the home makes in principle the actual network ac	The use of IPv6 addresses in the home makes, in principle, the actual network ac
	cess simpler, while on the other hand, the addresses are much harder to remember	cess simpler, while on the other hand, the addresses are much harder to remember
	, and subject to regular renumbering.	and are subject to regular renumbering.
	To make this situation simpler for typical home owners to manage, there needs to	To make this situation simpler for typical home owners to manage, there needs to
	be an easy way for names and IP addresses of these devices and services to be p	be an easy way for the names and IP addresses of these devices and services to
	ublished in the public DNS.</t>	be published in the public DNS.</t>
		<t indent="0" pn="section-1-2">As depicted in <xref target="fig-outsourcin
	<t>As depicted in {fig-outsourcing-overview}, he names and IP address of the hom	g-overview" format="default" sectionFormat="of" derivedContent="Figure 1"/>, the
	e network are made availble in the Public Homenet Zone by the Homenet Naming Aut	names and IP address of the home network are made available in the Public Homen
	hority (HNA), which in turn instructs the DNS Outsourcing Infrastructure (DOI) t	et Zone by the Homenet Naming Authority (HNA), which in turn instructs the DNS O
	o publish the zone on behalf of the HNA.	utsourcing Infrastructure (DOI) to publish the zone on behalf of the HNA.
	This document describes how an HNA can instruct a DOI to publish a Public Homene t Zone on its behalf.</t>	This document describes how an HNA can instruct a DOI to publish a Public Homene t Zone on its behalf.</t>

		<t indent="0" pn="section-1-3">This document introduces the Synchronizatio
	<t>The document introduces the Synchronization Channel and the Control Channel b	n Channel and the Control Channel between the HNA and the Distribution Manager
	etween the HNA and the Distribution Manager (DM), which is the main interface t	(DM), which is the main interface to the DOI.</t>
	o the DNS Outsourcing Infrastructure (DOI).</t>	<t indent="0" pn="section-1-4">The Synchronization Channel (see <xref targ
		et="sec-synch" format="default" sectionFormat="of" derivedContent="Section 7"/>)
	<t>The Synchronization Channel (see <xref target="sec-synch"/>) is used to synch	is used to synchronize the Public Homenet Zone.</t>
	ronize the Public Homenet Zone.</t>	<figure anchor="fig-outsourcing-overview" align="left" suppress-title="fal
		se" pn="figure-1">
	<figure title="High level architecture overview of outsourcing the Public Homene	<name slugifiedName="name-high-level-architecture-ove">High-Level Archit
	t Zone" anchor="fig-outsourcing-overview"><artwork align="center"><![CDATA[	ecture Overview of Outsourcing the Public Homenet Zone</name>
		<artwork align="center" pn="section-1-5.1">
	Internet	Internet
	.---------------------. .-------------------.	.---------------------. .-------------------.
	\| Home Network \| Control \| DOI \|	\| Home Network \| Control \| DOI \|
	\|.-------------------.\| Channel \|.-----------------.\|	\|.-------------------.\| Channel \|.-----------------.\|

	\|\| HNA \|<----------->\| Distribution \|\|	\|\| HNA \|<----------->\| Distribution \|\|
	\|\|.-----------------.\|\| \|\| Manager \|\|	\|\|.-----------------.\|\| \|\| Manager \|\|
	\|\|\| Public Homenet \|\|\| \|\| \|\|	\|\|\| Public Homenet \|\|\| \|\| \|\|

	\|\|\| Zone \|\|<----------->\| \|\|	\|\|\| Zone \|\|<----------->\| \|\|
	\|\|\| myhome.example \|\|\| Synchron- \|'-----------------'\|	\|\|\| myhome.example \|\|\| Synchron- \|'-----------------'\|
	\|\|'-----------------'\|\| ization \| \| \|	\|\|'-----------------'\|\| ization \| \| \|
	\|'-------------------'\| Channel \| V \|	\|'-------------------'\| Channel \| V \|
	\| \| \|.-----------------.\|	\| \| \|.-----------------.\|
	\| \| \|\| Public Homenet \|\|	\| \| \|\| Public Homenet \|\|
	'---------------------' \|\| Zone \|\|	'---------------------' \|\| Zone \|\|
	\|\| myhome.example \|\|	\|\| myhome.example \|\|
	\|'-----------------'\|	\|'-----------------'\|
	'---^--^--^--^--^---'	'---^--^--^--^--^---'
	\| \| \| \| \|	\| \| \| \| \|
	(served on the Internet)	(served on the Internet)

		</artwork>
	]]></artwork></figure>	</figure>
		<t indent="0" pn="section-1-6">The Synchronization Channel is a zone trans
	<t>The Synchronization Channel is a zone transfer, with the HNA configured as a	fer, with the HNA configured as a primary server and the Distribution Manager co
	primary, and the Distribution Manager configured as a secondary.	nfigured as a secondary server.
	Some operators refer to this kind of configuration as a "hidden primary", but th	Some operators refer to this kind of configuration as a "hidden primary", but th
	at term is not used in this document as it is not precisely defined anywhere, bu	at term is not used in this document as it is not precisely defined anywhere, bu
	t has many slightly different meanings to many.</t>	t it has many slightly different meanings to many.</t>
		<t indent="0" pn="section-1-7">The Control Channel (see <xref target="sec-
	<t>The Control Channel (see <xref target="sec-ctrl"/>) is used to set up the Syn	ctrl" format="default" sectionFormat="of" derivedContent="Section 6"/>) is used
	chronization Channel.	to set up the Synchronization Channel.
	This channel is in the form of a dynamic DNS update process, authenticated by TL	This channel is in the form of a dynamic DNS update process, authenticated
	S.</t>	by TLS.</t>
		<t indent="0" pn="section-1-8">For example, to build the Public Homenet Zo
	<t>For example, to build the Public Homenet Zone, the HNA needs the authoritativ	ne, the HNA needs the authoritative servers (and associated IP addresses) of the
	e servers (and associated IP addresses) of the servers (the visible primaries) o	DOI's servers (the visible primaries) that are actually serving the zone.
	f the DOI actually serving the zone.
	Similarly, the DOI needs to know the IP address of the (hidden) primary (HNA) as well as potentially the hash of the Key Signing Key (KSK) in the DS RRset to se cure the DNSSEC delegation with the parent zone.</t>	Similarly, the DOI needs to know the IP address of the (hidden) primary (HNA) as well as potentially the hash of the Key Signing Key (KSK) in the DS RRset to se cure the DNSSEC delegation with the parent zone.</t>

		<t indent="0" pn="section-1-9">The remainder of the document is as follows
	<t>The remainder of the document is as follows.</t>	.</t>
		<t indent="0" pn="section-1-10"><xref target="terminology" format="default
	<t><xref target="terminology"/> defines the terminology.	" sectionFormat="of" derivedContent="Section 2"/> defines the terminology.
	<xref target="selectingnames"/> presents the general problem of publishing names	<xref target="selectingnames" format="default" sectionFormat="of" derivedContent
	and IP addresses.</t>	="Section 3"/> presents the general problem of publishing names and IP addresses
		. <xref target="sec-deployment" format="default" sectionFormat="of" derivedConte
	<t><xref target="sec-arch-desc"/> provides an architectural view of the HNA, DM	nt="Section 4"/> briefly describes some potential envisioned deployment scenario
	and DOI as well as their different communication channels (Control Channel, Syn	s.
	chronization Channel, DM Distribution Channel) respectively described in <xref t	And <xref target="sec-arch-desc" format="default" sectionFormat="of" derivedCon
	arget="sec-ctrl"/>, <xref target="sec-synch"/> and <xref target="sec-dist"/>.</t	tent="Section 5"/> provides an architectural view of the HNA, DM, and DOI as we
	>	ll as their different communication channels (Control Channel, Synchronization C
		hannel, and DM Distribution Channel) described in Sections <xref target="sec-ctr
	<t>Then <xref target="sec-ctrl"/> and <xref target="sec-synch"/> deal with the t	l" format="counter" sectionFormat="of" derivedContent="6"/>, <xref target="sec-s
	wo channels that interface to the home.	ynch" format="counter" sectionFormat="of" derivedContent="7"/>, and <xref target
	<xref target="sec-dist"/> provides a set of requirements and expectations on how	="sec-dist" format="counter" sectionFormat="of" derivedContent="8"/>, respective
	the distribution system works. This section is non-normative and not subject t	ly.</t>
	o standardization, but reflects how many scalable DNS distribution systems opera	<t indent="0" pn="section-1-11">Then, Sections <xref target="sec-ctrl" for
	te.</t>	mat="counter" sectionFormat="of" derivedContent="6"/> and <xref target="sec-sync
		h" format="counter" sectionFormat="of" derivedContent="7"/> deal with the two ch
	<t><xref target="sec-cpe-sec-policies"/> and <xref target="sec-dnssec-deployment	annels that interface to the home.
	"/> respectively detail HNA security policies as well as DNSSEC compliance withi	<xref target="sec-dist" format="default" sectionFormat="of" derivedContent="Sect
	n the home network.</t>	ion 8"/> provides a set of requirements and expectations on how the distribution
		system works. This section is non-normative and not subject to standardization
	<t><xref target="sec-renumbering"/> discusses how renumbering should be handled.	but reflects how many scalable DNS distribution systems operate.</t>
	</t>	<t indent="0" pn="section-1-12">Sections <xref target="sec-cpe-sec-policie
		s" format="counter" sectionFormat="of" derivedContent="9"/> and <xref target="se
	<t>Finally, <xref target="sec-privacy"/> and <xref target="sec-security"/> respe	c-dnssec-deployment" format="counter" sectionFormat="of" derivedContent="11"/> r
	ctively discuss privacy and security considerations when outsourcing the Public	espectively detail HNA security policies as well as DNSSEC compliance within the
	Homenet Zone.</t>	home network.</t>
		<t indent="0" pn="section-1-13"><xref target="sec-renumbering" format="def
	<t>The appendices discuss several management (see <xref target="sec-reverse"/>)	ault" sectionFormat="of" derivedContent="Section 12"/> discusses how renumbering
	provisioning (see <xref target="sec-reverse"/>), configurations (see <xref targe	should be handled.</t>
	t="info-model"/>) and deployment (see <xref target="sec-deployment"/> and <xref	<t indent="0" pn="section-1-14">Finally, Sections <xref target="sec-privac
	target="sec-ex-manu"/>) aspects.</t>	y" format="counter" sectionFormat="of" derivedContent="13"/> and <xref target="s
		ec-security" format="counter" sectionFormat="of" derivedContent="14"/> respectiv
	</section>	ely discuss privacy and security considerations when outsourcing the Public Home
	<section anchor="terminology"><name>Terminology</name>	net Zone.</t>
		<t indent="0" pn="section-1-15">The appendices discuss the following aspec
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	ts: management (see <xref target="sec-reverse" format="default" sectionFormat="o
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	f" derivedContent="Section 10"/>), provisioning (see <xref target="sec-reverse"
	"MAY", and "OPTIONAL" in this document are to be interpreted as	format="default" sectionFormat="of" derivedContent="Section 10"/>), configuratio
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and	ns (see <xref target="info-model" format="default" sectionFormat="of" derivedCon
	only when, they	tent="Appendix B"/>), and deployment (see <xref target="sec-deployment" format="
		default" sectionFormat="of" derivedContent="Section 4"/> and <xref target="sec-e
		x-manu" format="default" sectionFormat="of" derivedContent="Appendix C"/>).</t>
		</section>
		<section anchor="terminology" numbered="true" removeInRFC="false" toc="inclu
		de" 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>

		<dl indent="3" newline="false" spacing="normal" pn="section-2-2">
	<dl>	<dt pn="section-2-2.1">Customer Premises Equipment (CPE):</dt>
	<dt>Customer Premises Equipment:</dt>	<dd pn="section-2-2.2">
	<dd>	<t indent="0" pn="section-2-2.2.1">A router providing connectivity to
	<t>(CPE) is a router providing connectivity to the home network.</t>	the home network.</t>
	</dd>	</dd>
	<dt>Homenet Zone:</dt>	<dt pn="section-2-2.3">Homenet Zone:</dt>
	<dd>	<dd pn="section-2-2.4">
	<t>is the DNS zone for use within the boundaries of the home network: 'home.	<t indent="0" pn="section-2-2.4.1">The DNS zone for use within the bou
	arpa' (see <xref target="RFC8375"/>).	ndaries of the home network: "home.arpa" (see <xref target="RFC8375" format="def
		ault" sectionFormat="of" derivedContent="RFC8375"/>).
	This zone is not considered public and is out of scope for this document.</t>	This zone is not considered public and is out of scope for this document.</t>

	</dd>	</dd>
	<dt>Registered Homenet Domain:</dt>	<dt pn="section-2-2.5">Registered Homenet Domain:</dt>
	<dd>	<dd pn="section-2-2.6">
	<t>is the domain name that is associated with the home network. A given home	<t indent="0" pn="section-2-2.6.1">The domain name that is associated
	network may have multiple Registered Homenet Domain.</t>	with the home network. A given home network may have multiple Registered Homenet
	</dd>	Domains.</t>
	<dt>Public Homenet Zone:</dt>	</dd>
	<dd>	<dt pn="section-2-2.7">Public Homenet Zone:</dt>
	<t>contains the names in the home network that are expected to be publicly r	<dd pn="section-2-2.8">
	esolvable on the Internet. A home network can have multiple Public Homenet Zones	<t indent="0" pn="section-2-2.8.1">Contains the names in the home netw
	.</t>	ork that are expected to be publicly resolvable on the Internet. A home network
	</dd>	can have multiple Public Homenet Zones.</t>
	<dt>Homenet Naming Authority(HNA):</dt>	</dd>
	<dd>	<dt pn="section-2-2.9">Homenet Naming Authority (HNA):</dt>
	<t>is a function responsible for managing the Public Homenet Zone.	<dd pn="section-2-2.10">
	This includes populating the Public Homenet Zone, signing the zone for DNSSEC, a	<t indent="0" pn="section-2-2.10.1">A function responsible for managin
	s well as managing the distribution of that Homenet Zone to the DNS Outsourcing	g the Public Homenet Zone.
	Infrastructure (DOI).</t>	This includes populating the Public Homenet Zone, signing the zone for DNSSEC, a
	</dd>	s well as managing the distribution of that Homenet Zone to the DOI.</t>
	<dt>DNS Outsourcing Infrastructure (DOI):</dt>	</dd>
	<dd>	<dt pn="section-2-2.11">DNS Outsourcing Infrastructure (DOI):</dt>
	<t>is the infrastructure responsible for receiving the Public Homenet Zone a	<dd pn="section-2-2.12">
	nd publishing it on the Internet.	<t indent="0" pn="section-2-2.12.1">The infrastructure responsible for
		receiving the Public Homenet Zone and publishing it on the Internet.
	It is mainly composed of a Distribution Manager and Public Authoritative Servers .</t>	It is mainly composed of a Distribution Manager and Public Authoritative Servers .</t>

	</dd>	</dd>
	<dt>Public Authoritative Servers:</dt>	<dt pn="section-2-2.13">Public Authoritative Servers:</dt>
	<dd>	<dd pn="section-2-2.14">
	<t>are the authoritative name servers for the Public Homenet Zone.	<t indent="0" pn="section-2-2.14.1">The authoritative name servers for
		the Public Homenet Zone.
	Name resolution requests for the Registered Homenet Domain are sent to these ser vers.	Name resolution requests for the Registered Homenet Domain are sent to these ser vers.

	Some DNS operators would refer to these as public secondaries, and for higher re	Some DNS operators refer to these as public secondaries, and higher resiliency n
	siliency networks, are often implemented in an anycast fashion.</t>	etworks are often implemented in an anycast fashion.</t>
	</dd>	</dd>
	<dt>Homenet Authoritative Servers:</dt>	<dt pn="section-2-2.15">Homenet Authoritative Servers:</dt>
	<dd>	<dd pn="section-2-2.16">
	<t>are authoritative name servers for the Homenet Zone within the Homenet ne	<t indent="0" pn="section-2-2.16.1">The authoritative name servers for
	twork itself. These are sometimes called the hidden primary servers.</t>	the Homenet Zone within the Homenet network itself. These are sometimes called
	</dd>	"hidden primary servers".</t>
	<dt>Distribution Manager (DM):</dt>	</dd>
	<dd>	<dt pn="section-2-2.17">Distribution Manager (DM):</dt>
	<t>is the (set of) server(s) to which the HNA synchronizes the Public Homene	<dd pn="section-2-2.18">
	t Zone, and which then distributes the relevant information to the Public Author	<t indent="0" pn="section-2-2.18.1">The server (or set of servers) tha
	itative Servers.	t the HNA synchronizes the Public Homenet Zone to and that then distributes the
	This server has been historically known as the Distribution Master.</t>	relevant information to the Public Authoritative Servers. This server has been h
	</dd>	istorically known as the Distribution Master.</t>
	<dt>Public Homenet Reverse Zone:</dt>	</dd>
	<dd>	<dt pn="section-2-2.19">Public Homenet Reverse Zone:</dt>
	<t>The reverse zone file associated with the Public Homenet Zone.</t>	<dd pn="section-2-2.20">
	</dd>	<t indent="0" pn="section-2-2.20.1">The reverse zone file associated w
	<dt>Reverse Public Authoritative Servers:</dt>	ith the Public Homenet Zone.</t>
	<dd>	</dd>
	<t>equivalent to Public Authoritative Servers specifically for reverse resol	<dt pn="section-2-2.21">Reverse Public Authoritative Servers:</dt>
	ution.</t>	<dd pn="section-2-2.22">
	</dd>	<t indent="0" pn="section-2-2.22.1">These are equivalent to Public Aut
	<dt>Reverse Distribution Manager:</dt>	horitative Servers, specifically for reverse resolution.</t>
	<dd>	</dd>
	<t>equivalent to Distribution Manager specifically for reverse resolution.</	<dt pn="section-2-2.23">Reverse Distribution Manager:</dt>
	t>	<dd pn="section-2-2.24">
	</dd>	<t indent="0" pn="section-2-2.24.1">This is equivalent to the Distribu
	<dt>Homenet DNS(SEC) Resolver:</dt>	tion Manager, specifically for reverse resolution.</t>
	<dd>	</dd>
	<t>a resolver that performs a DNS(SEC) resolution on the home network for th	<dt pn="section-2-2.25">DNS Resolver:</dt>
	e Public Homenet Zone.	<dd pn="section-2-2.26">
	The resolution is performed requesting the Homenet Authoritative Servers.</t>	<t indent="0" pn="section-2-2.26.1">A resolver that performs a DNS res
	</dd>	olution on the Internet for the Public Homenet Zone.
	<dt>DNS(SEC) Resolver:</dt>	The resolution is performed by requesting the Public Authoritative Serv
	<dd>	ers. While the resolver does not necessarily perform DNSSEC resolutions, it is <
	<t>a resolver that performs a DNS resolution on the Internet for the Public	bcp14>RECOMMENDED</bcp14> that DNSSEC is enabled. </t>
	Homenet Zone.	<t indent="0" pn="section-2-2.26.2">Note that when "DNS Resolver" is u
	The resolution is performed requesting the Public Authoritative Servers.</t>	sed in this document, it refers to "DNS or DNSSEC Resolver".</t>
	</dd>	</dd>
	</dl>	<dt pn="section-2-2.27">Homenet DNS Resolver:</dt>
		<dd pn="section-2-2.28">
	</section>	<t indent="0" pn="section-2-2.28.1">A resolver that performs a DNS or
	<section anchor="selectingnames"><name>Selecting Names and Addresses to Publish<	DNSSEC resolution on the home network for the Public Homenet Zone. The resolutio
	/name>	n is performed by requesting the Homenet Authoritative Servers.</t>
		</dd>
	<t>While this document does not create any normative mechanism to select the nam	</dl>
	es to publish, this document anticipates that the home network administrator (a	</section>
	human being), will be presented with a list of current names and addresses eithe	<section anchor="selectingnames" numbered="true" removeInRFC="false" toc="in
	r directly on the HNA or via another device such as a smartphone.</t>	clude" pn="section-3">
		<name slugifiedName="name-selecting-names-and-address">Selecting Names and
	<t>The administrator would mark which devices and services (by name), are to be	Addresses to Publish</name>
	published.	<t indent="0" pn="section-3-1">While this document does not create any nor
	The HNA would then collect the IP address(es) associated with that device or ser	mative mechanism to select the names to publish, it does anticipate that the hom
	vice, and put the name into the Public Homenet Zone.	e network administrator (a human being) will be presented with a list of current
	The address of the device or service can be collected from a number of places: m	names and addresses either directly on the HNA or via another device such as a
	DNS <xref target="RFC6762"/>, DHCP <xref target="RFC8415"/>, UPnP, PCP <xref tar	smartphone.</t>
	get="RFC6887"/>, or manual configuration.</t>	<t indent="0" pn="section-3-2">The administrator will mark which devices a
		nd services (by name) are to be published. The HNA will then collect the IP addr
	<t>A device or service SHOULD have Global Unicast Addresses (GUA) (IPv6 <xref ta	ess(es) associated with that device or service and put the name into the Public
	rget="RFC3787"/> or IPv4), but MAY also have Unique Local IPv6 Addresses (ULA) <	Homenet Zone. The address of the device or service can be collected from a numbe
	xref target="RFC4193"/>, IPv6-Link-Local addresses<xref target="RFC4291"/><xref	r of places: Multicast DNS (mDNS) <xref target="RFC6762" format="default" sectio
	target="RFC7404"/>, IPv4-Link-Local Addresses <xref target="RFC3927"/> (LLA), an	nFormat="of" derivedContent="RFC6762"/>, DHCP <xref target="RFC8415" format="def
	d finally, private IPv4 addresses <xref target="RFC1918"/>.</t>	ault" sectionFormat="of" derivedContent="RFC8415"/>, Universal Plug and Play (UP
		nP), the Port Control Protocol (PCP) <xref target="RFC6887" format="default" sec
	<t>Of these the link-local are almost never useful for the Public Zone, and shou	tionFormat="of" derivedContent="RFC6887"/>, or manual configuration.</t>
	ld be omitted.</t>	<t indent="0" pn="section-3-3">A device or service <bcp14>SHOULD</bcp14> h
		ave Global Unicast Addresses (GUAs) (IPv6 <xref target="RFC3587" format="default
	<t>The IPv6 ULA and the private IPv4 addresses may be useful to publish, if the	" sectionFormat="of" derivedContent="RFC3587"/> or IPv4) but <bcp14>MAY</bcp14>
	home network environment features a VPN that would allow the home owner to reach	also have IPv6 Unique Local Addresses (ULAs) <xref target="RFC4193" format="defa
	the network.	ult" sectionFormat="of" derivedContent="RFC4193"/>, IPv6 Link-Local Addresses (L
	RFC1918 addresses in public zones are generally filtered out by many DNS servers	LAs) <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="
	as they are considered rebind attacks <xref target="REBIND"/>.</t>	RFC4291"/> <xref target="RFC7404" format="default" sectionFormat="of" derivedCon
		tent="RFC7404"/>, IPv4 LLAs <xref target="RFC3927" format="default" sectionForma
	<t>In general, one expects the GUA to be the default address to be published.	t="of" derivedContent="RFC3927"/>, and private IPv4 addresses <xref target="RFC1
	A direct advantage of enabling local communication is to enable communications e	918" format="default" sectionFormat="of" derivedContent="RFC1918"/>.</t>
	ven in case of Internet disruption.	<t indent="0" pn="section-3-4">Of these, the LLAs are almost never useful
	Since communications are established with names which remain a global identifier	for the Public Zone and should be omitted.</t>
	, the communication can be protected (at the very least with integrity protectio	<t indent="0" pn="section-3-5">The IPv6 ULA and private IPv4 addresses may
	n) by TLS the same way it is protected on the global Internet - using certificat	be useful to publish, if the home network environment features a VPN that would
	es. </t>	allow the home owner to reach the network. <xref target="RFC1918" format="defau
		lt" sectionFormat="of" derivedContent="RFC1918"/> addresses in public zones are
	</section>	generally filtered out by many DNS servers as they are considered rebind attacks
	<section anchor="sec-deployment"><name>Envisioned deployment scenarios</name>	<xref target="REBIND" format="default" sectionFormat="of" derivedContent="REBIN
		D"/>.</t>
	<t>A number of deployment scenarios have been envisioned, this section aims at	<t indent="0" pn="section-3-6">In general, one expects the GUA to be the d
	providing a brief description.	efault address to be published.
	The use cases are not limitations and this section is not normative.</t>	A direct advantage of enabling local communication is to enable communications e
		ven in case of Internet disruption. Since communications are established with na
	<t>The main difference between the various deployments concerns the provisioning	mes that remain a global identifier, the communication can be protected (at the
	of the HNA - that is how it is configured to outsource the Public Homenet Zone	very least with integrity protection) by TLS the same way it is protected on the
	to the DOI - as well as how the Public Homenet Zone is being provisioned before	global Internet -- by using certificates.</t>
	being outsourced.<br />	</section>
	In both cases, these configuration aspects are out of the scope of the document.	<section anchor="sec-deployment" numbered="true" removeInRFC="false" toc="in
	</t>	clude" pn="section-4">
		<name slugifiedName="name-envisioned-deployment-scena">Envisioned Deployme
	<t>Provisioning the configuration related to the DOI is expected to be automated	nt Scenarios</name>
	as much as possible and require as little as possible interaction with the end	<t indent="0" pn="section-4-1">A number of deployment scenarios have been
	user. <br />	envisioned; this section aims at
	Zero configuration can only be achieved under some circumstances and <xref targe	providing a brief description. The use cases are not limitations, and this secti
	t="I-D.ietf-homenet-naming-architecture-dhc-options"/> provides one such example	on is not normative.</t>
	under the assumption the ISP provides the DOI. <xref target="sec-cpe-vendor"/>	<t indent="0" pn="section-4-2">The main difference between the various dep
	describes another variant where the CPE is provided preconfigured with the DOI.	loyments concerns the provisioning of the HNA -- that is, how it is configured t
	<xref target="sec-agnostic-cpe"/> describes how an agnostic CPE may be configure	o outsource the Public Homenet Zone to the DOI -- as well as how the Public Home
	d by the home network administrator.	net Zone is being provisioned before being outsourced.
	Of course even in this case, the configuration can leverage mechanisms to preven	In both cases, these configuration aspects are out of the scope of this document
	t the end user manually entering all information.</t>	.</t>
		<t indent="0" pn="section-4-3">Provisioning the configuration related to t
	<t>On the other hand, provisioning the Public Homenet Zone needs to combine the	he DOI is expected to be automated as much as possible and require interaction w
	ability to closely reflect what the end user wishes to publish on the Internet w	ith the end user as little as possible.
	hile easing such interaction.	Zero configuration can only be achieved under some circumstances, and <xref targ
	The HNA may implement such interactions using Web GUI or specific mobile applica	et="RFC9527" format="default" sectionFormat="of" derivedContent="RFC9527"/> prov
	tions.</t>	ides one such example under the assumption that the ISP provides the DOI. <xref
		target="sec-cpe-vendor" format="default" sectionFormat="of" derivedContent="Sect
	<t>With the CPE configured with the DOI, the HNA contacts the DOI to build a tem	ion 4.1"/> describes another variant where the Customer Premises Equipment (CPE)
	plate for the	is provided preconfigured with the DOI.
	Public Homenet Zone, and then provision the Public Homenet Zone.	<xref target="sec-agnostic-cpe" format="default" sectionFormat="of" derivedConte
	Once the Public Homenet Zone is built, the HNA strats synchronizing it with the	nt="Section 4.2"/> describes how an agnostic CPE may be configured by the home n
	DOI on the Synchronization channel.</t>	etwork administrator.
		Of course even in this case, the configuration can leverage mechanisms to
	<section anchor="sec-cpe-vendor"><name>CPE Vendor</name>	prevent the end user from manually entering all information.</t>
		<t indent="0" pn="section-4-4">On the other hand, provisioning the Public
	<t>A specific vendor with specific relations with a registrar or a registry	Homenet Zone needs to combine the ability to closely reflect what the end user w
		ishes to publish on the Internet while easing such interaction.
		The HNA may implement such interactions using web-based GUIs or specific mobile
		applications.</t>
		<t indent="0" pn="section-4-5">With the CPE configured with the DOI, the H
		NA contacts the DOI to build a template for the
		Public Homenet Zone and then provisions the Public Homenet Zone.
		Once the Public Homenet Zone is built, the HNA starts synchronizing it with the
		DOI on the Synchronization Channel.</t>
		<section anchor="sec-cpe-vendor" numbered="true" removeInRFC="false" toc="
		include" pn="section-4.1">
		<name slugifiedName="name-cpe-vendor">CPE Vendor</name>
		<t indent="0" pn="section-4.1-1">A specific vendor that has specific rel
		ations with a registrar or a registry
	may sell a CPE that is provisioned with a domain name.	may sell a CPE that is provisioned with a domain name.

	Such a domain name is probably not human friendly, and may consist of some kind	Such a domain name is probably not human friendly and may consist of some kind o
	of serial number associated with the device being sold.</t>	f serial number associated with the device being sold.</t>
		<t indent="0" pn="section-4.1-2">One possible scenario is that the vendo
	<t>One possible scenario is that the vendor provisions the HNA with a private ke	r provisions the HNA with a private key with an associated certificate used for
	y, with an associated certificate used for the mutual TLS authentication.	the mutual TLS authentication.
	Note that these keys are not expected to be used for DNSSEC signing.</t>	Note that these keys are not expected to be used for DNSSEC signing.</t>

		<t indent="0" pn="section-4.1-3">Instead, these keys are solely used by
	<t>Instead these keys are solely used by the HNA for the authentication to the D	the HNA for the authentication to the DM.
	M.	Normally, the keys are necessary and sufficient to proceed to the authentication
	Normally the keys should be necessary and sufficient to proceed to the authentic	.</t>
	ation.</t>	<t indent="0" pn="section-4.1-4">When the home network owner plugs in th
		e CPE at home, the relation between the HNA and DM is expected to work out of th
	<t>When the home network owner plugs in the CPE at home, the relation between HN	e box.</t>
	A and DM is expected to work out-of-the-box.</t>	</section>
		<section anchor="sec-agnostic-cpe" numbered="true" removeInRFC="false" toc
	</section>	="include" pn="section-4.2">
	<section anchor="sec-agnostic-cpe"><name>Agnostic CPE</name>	<name slugifiedName="name-agnostic-cpe">Agnostic CPE</name>
		<t indent="0" pn="section-4.2-1">A CPE that is not preconfigured may als
	<t>A CPE that is not preconfigured may also use the protocol	o use the protocol
	defined in this document but some configuration steps will be needed.</t>	defined in this document, but some configuration steps will be needed.</t>
		<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.
	<t><list style="numbers">	2-2">
	<t>The owner of the home network buys a domain name from a registrar, and	<li pn="section-4.2-2.1" derivedCounter="1.">The owner of the home network buy
	as such creates an account on that registrar</t>	s a domain name from a registrar and,
	<t>the registrar may also be providing the outsourcing infrastructure	as such, creates an account on that registrar.</li>
		<li pn="section-4.2-2.2" derivedCounter="2.">The registrar may provide
		the outsourcing infrastructure,
	or the home network may need to create a specific account on the	or the home network may need to create a specific account on the

	outsourcing infrastructure.</t>	outsourcing infrastructure.</li>
	</list></t>	</ol>
		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4
	<t><list style="symbols">	.2-3">
	<t>If the DOI is the DNS Registrar, it has by design a proof of ownership of t	<li pn="section-4.2-3.1">If the DOI is the DNS Registrar, it has by de
	he domain name by the homenet owner.	sign a proof of ownership of the domain name by the Homenet owner.
	In this case, it is expected the DOI provides the necessary parameters to the ho	In this case, it is expected that the DOI provides the necessary parameters to t
	me network owner to configure the HNA.	he home network owner to configure the HNA. One potential mechanism to provide t
	One potential mechanism to provide the parameters would be to provide the user w	he parameters would be to provide the user with a JSON object that they can copy
	ith a JSON object which they can copy paste into the CPE - such as described in	and paste into the CPE, such as described in <xref target="info-model" format="
	<xref target="info-model"/>.	default" sectionFormat="of" derivedContent="Appendix B"/>.
	But, what matters to infrastructure is that the HNA is able to authenticate itse	But what matters to the infrastructure is that the HNA is able to authenticate i
	lf to the DOI.</t>	tself to the DOI.</li>
	<t>If the DOI is not the DNS Registrar, then the proof of ownership needs to b	<li pn="section-4.2-3.2">If the DOI is not the DNS Registrar, then the
	e established using some other protocol.	proof of ownership needs to be established using some other protocol.
	ACME <xref target="RFC8555"/> is one protocol that would allow an owner of an ex	Automatic Certificate Management Environment (ACME) <xref target="RFC85
	isting domain name to prove their ownership (but requires they have DNS already	55" format="default" sectionFormat="of" derivedContent="RFC8555"/> is one protoc
	setup!)	ol that would allow an owner of an existing domain name to prove their ownership
	There are other ways such as putting a DOI generated TXT record, or web site con	(but it requires that they have DNS already set up!). There are other ways to e
	tents, as championed by entities like Google's Sitemaster and Postmaster protoco	stablish proof such as providing a DOI-generated TXT record, or web site content
	ls.	s, as championed by entities like Google's Sitemaster and Postmaster protocols.
	<xref target="I-D.ietf-dnsop-domain-verification-techniques"/> describes a few w	<xref target="I-D.ietf-dnsop-domain-verification-techniques" format="default" se
	ays ownership or control of a domain can be achieved.</t>	ctionFormat="of" derivedContent="DOMAIN-VALIDATION"/> describes a few ways owner
	</list></t>	ship or control of a domain can be achieved.</li>
		</ul>
	</section>	</section>
	</section>	</section>
	<section anchor="sec-arch-desc"><name>Architecture Description</name>	<section anchor="sec-arch-desc" numbered="true" removeInRFC="false" toc="inc
		lude" pn="section-5">
	<t>This section provides an overview of the architecture for outsourcing the aut	<name slugifiedName="name-architecture-description">Architecture Descripti
	horitative naming service from the HNA to the DOI.	on</name>
	As a consequence, this prevents HNA to handle the DNS traffic from the Internet	<t indent="0" pn="section-5-1">This section provides an overview of the ar
	associated with the resolution of the Homenet Zone.</t>	chitecture for outsourcing the authoritative naming service from the HNA to the
		DOI.
	<t>The device assigned zone or user configurable zone to use as the domain to pu	As a consequence, this prevents HNA from handling the DNS traffic from the Inter
	blicly serve hostnames in the home network is called the Public Homenet Zone.	net that is associated with the resolution of the Homenet Zone.</t>
	In this document, "myhome.example" is used as the example for an enduser owned d	<t indent="0" pn="section-5-2">The device-assigned zone or user-configurab
	omain configured as Public Homenet Zone.</t>	le zone that is used as the domain to publicly serve hostnames in the home netwo
		rk is called the Public Homenet Zone.
	<t>More specifically, DNS resolution for the Public Homenet Zone (here myhome.ex	In this document, "myhome.example" is used as the example for an end-user-owned
	ample) from Internet DNSSEC resolvers is handled by the DOI as opposed to the HN	domain configured as a Public Homenet Zone.</t>
	A.	<t indent="0" pn="section-5-3">More specifically, DNS resolution for the P
	The DOI benefits from a cloud infrastructure while the HNA is dimensioned for ho	ublic Homenet Zone (here "myhome.example") from Internet DNSSEC resolvers is han
	me network and as such likely unable to support any load.	dled by the DOI as opposed to the HNA.
	In the case the HNA is a CPE, outsourcing to the DOI reduces the attack surface	The DOI benefits from a cloud infrastructure while the HNA is dimensioned for a
	of the home network to DDoS for example.	home network and, as such, is likely unable to support any load.
	Of course the DOI needs to be informed dynamically about the content of myhome.e	In the case where the HNA is a CPE, outsourcing to the DOI reduces the attack su
	xample. The description of such a synchronization mechanism is the purpose of th	rface of the home network to DDoS, for example.
	is document.</t>	Of course, the DOI needs to be informed dynamically about the content of m
		yhome.example. The description of such a synchronization mechanism is the purpos
	<t>Note that <xref target="info-model"/> shows necessary parameters to configure	e of this document.</t>
	the HNA.</t>	<t indent="0" pn="section-5-4">Note that <xref target="info-model" format=
		"default" sectionFormat="of" derivedContent="Appendix B"/> shows the necessary p
	<section anchor="sec-arch-overview"><name>Architecture Overview</name>	arameters to configure the HNA.</t>
		<section anchor="sec-arch-overview" numbered="true" removeInRFC="false" to
	<figure title="Homenet Naming Architecture" anchor="fig-naming-arch"><artwork al	c="include" pn="section-5.1">
	ign="center"><![CDATA[	<name slugifiedName="name-architecture-overview">Architecture Overview</
		name>
		<figure anchor="fig-naming-arch" align="left" suppress-title="false" pn=
		"figure-2">
		<name slugifiedName="name-homenet-naming-architecture">Homenet Naming
		Architecture</name>
		<artwork align="center" pn="section-5.1-1.1">
	.----------------------------. .-----------------------------.	.----------------------------. .-----------------------------.
	\| Home Network \| \| Internet \|	\| Home Network \| \| Internet \|
	\| .-----------------------. \| Control \| .-----------------------. \|	\| .-----------------------. \| Control \| .-----------------------. \|
	\| \| HNA \| \| Channel \| \| DOI \| \|	\| \| HNA \| \| Channel \| \| DOI \| \|

	\| \| (hidden primary) \|<------------->\| (hidden secondary) \| \|	\| \| (hidden primary) \|<------------->\| (hidden secondary) \| \|
	\| \| \| \| DNSUPD \| \| Distribution Manager \| \|	\| \| \| \| DNSUPD \| \| Distribution Manager \| \|
	\| \| .-------------------. \| \| \| \| \| \|	\| \| .-------------------. \| \| \| \| \| \|
	\| \| \| Public Homenet \| \| \| \| \| .-------------------.\| \|	\| \| \| Public Homenet \| \| \| \| \| .-------------------.\| \|

	\| \| \| Zone \|<------------------>\| Public Homenet Zo \|\| \|	\| \| \| Zone \|<------------------>\|Public Homenet Zone\|\| \|
	\| \| \| myhome.example \| \| \|Synchron-\| \| \| myhome.example \|\| \|	\| \| \| myhome.example \| \| \|Synchron-\| \| \| myhome.example \|\| \|

	\| \| '-------------------' \| \| ization \| \| '-------------------'\| \|	\| \| '-------------------' \| \|ization \| \| '-------------------'\| \|
	\| '-----------------------' \|Channel \| \| \| \| \|	\| '-----------------------' \|Channel \| \| \| \| \|
	\| ^ \| AXFR \| \| \| \| \|	\| ^ \| AXFR \| \| \| \| \|
	\| \| \| \| \| v \| \|	\| \| \| \| \| v \| \|
	\| .-----------------------. \| \| \|.---------------------.\| \|	\| .-----------------------. \| \| \|.---------------------.\| \|

	\| \| Homenet Authoritative \| \| \| \|\| Public Authoriative \|\| \|	\| \| Homenet Authoritative \| \| \| \|\| Public Authoritative\|\| \|
	\| \| Server \| \| \| \|\| (secondary) Servers \|\| \|	\| \| Server \| \| \| \|\| (secondary) Servers \|\| \|
	\| \| + myhome.example \| \| \| \|\| + myhome.example \|\| \|	\| \| + myhome.example \| \| \| \|\| + myhome.example \|\| \|
	\| \| + home.arpa \| \| \| \|\| + x.y.z.ip6.arpa \|\| \|	\| \| + home.arpa \| \| \| \|\| + x.y.z.ip6.arpa \|\| \|
	\| \| + x.y.z.ip6.arpa \| \| \| \|\| \|\| \|	\| \| + x.y.z.ip6.arpa \| \| \| \|\| \|\| \|
	\| '-----------------------' \| \| \|\| \|\| \|	\| '-----------------------' \| \| \|\| \|\| \|
	\| \| ^ \| \| \|'---------------------'\| \|	\| \| ^ \| \| \|'---------------------'\| \|
	\| \| \| \| \| \| ^ \| \| \|	\| \| \| \| \| \| ^ \| \| \|
	\| \| \| \| \| '--\|------------\|-------' \|	\| \| \| \| \| '--\|------------\|-------' \|
	\| v \| \| \| \| v \|	\| v \| \| \| \| v \|
	\| .----------------------. \| \| .------------------------. \|	\| .----------------------. \| \| .------------------------. \|

	\| \| Homenet Resolver \| \| \| \| Internet Resolvers \| \|	\| \| Homenet DNS Resolver \| \| \| \| Internet Resolvers \| \|
	\| '----------------------' \| \| '------------------------' \|	\| '----------------------' \| \| '------------------------' \|
	\| \| \| \|	\| \| \| \|
	'----------------------------' \| \|	'----------------------------' \| \|
	'-----------------------------'	'-----------------------------'

	]]></artwork></figure>	</artwork>
		</figure>
	<t><xref target="fig-naming-arch"/> illustrates the architecture where the HNA o	<t indent="0" pn="section-5.1-2"><xref target="fig-naming-arch" format="
	utsources the publication of the Public Homenet Zone to the DOI.	default" sectionFormat="of" derivedContent="Figure 2"/> illustrates the architec
	The DOI will serve every DNS request of the Public Homenet Zone coming from outs	ture where the HNA outsources the publication of the Public Homenet Zone to the
	ide the home network.	DOI.
	When the request is coming within the home network, the resolution is expected t	The DOI will serve every DNS request of the Public Homenet Zone coming from outs
	o be handled by the Homenet Resolver as detailed in further details below.</t>	ide the home network. When the request is coming from within the home network, t
		he resolution is expected to be handled by the Homenet DNS Resolver as further d
	<t>In this example, The Public Homenet Zone is identified by the Registered Home	etailed below.</t>
	net Domain name -- myhome.example.	<t indent="0" pn="section-5.1-3">In this example, the Public Homenet Zon
	This diagram also shows a reverse IPv6 map being hosted.</t>	e is identified by the Registered Homenet Domain name "myhome.example".
		This diagram also shows a reverse IPv6 map being hosted.</t>
	<t>The ".local" as well as ".home.arpa" are explicitly not considered as Public	<t indent="0" pn="section-5.1-4">".local" and ".home.arpa" are explicitl
	Homenet zones and represented as a Homenet Zone in <xref target="fig-naming-arch	y not considered Public Homenet Zones; therefore, they are represented as a Home
	"/>.	net Zone in <xref target="fig-naming-arch" format="default" sectionFormat="of" d
	They are resolved locally, but not published as they are local content.</t>	erivedContent="Figure 2"/>.
		They are resolved locally but are not published because they are considered loca
	<t>It is RECOMMENDED the HNA implements DNSSEC, in which case the HNA MUST signs	l content.</t>
	the Public Homenet Zone with DNSSEC.</t>	<t indent="0" pn="section-5.1-5">It is <bcp14>RECOMMENDED</bcp14> that t
		he HNA implements DNSSEC, in which case the HNA <bcp14>MUST</bcp14> sign the Pub
	<t>The HNA handles all operations and keying material required for DNSSEC, so th	lic Homenet Zone with DNSSEC.</t>
	ere is no provision made in this architecture for transferring private DNSSEC re	<t indent="0" pn="section-5.1-6">The HNA handles all operations and keyi
	lated keying material between the HNA and the DM.</t>	ng material required for DNSSEC, so there is no provision made in this architect
		ure for transferring private DNSSEC-related keying material between the HNA and
	<t>Once the Public Homenet Zone has been built, the HNA communicates and synchro	the DM.</t>
	nizes it with the DOI using a primary/secondary setting as depicted in <xref tar	<t indent="0" pn="section-5.1-7">Once the Public Homenet Zone has been b
	get="fig-naming-arch"/>.	uilt, the HNA communicates and synchronizes it with the DOI using a primary/seco
	The HNA acts as a stealth server (see <xref target="RFC8499"/>) while the DM beh	ndary setting as depicted in <xref target="fig-naming-arch" format="default" sec
	aves as a hidden secondary.	tionFormat="of" derivedContent="Figure 2"/>.
	It is responsible for distributing the Public Homenet Zone to the multiple Publi	The HNA acts as a stealth server (see <xref target="RFC8499" format="default" se
	c Authoritative Servers instances that DOI is responsible for.	ctionFormat="of" derivedContent="RFC8499"/>) while the DM behaves as a hidden se
	The DM has three communication channels:</t>	condary. It is responsible for distributing the Public Homenet Zone to the multi
		ple Public Authoritative Server instances that DOI is responsible for. The DM ha
	<t><list style="symbols">	s three communication channels:</t>
	<t>DM Control Channel (<xref target="sec-ctrl"/>) to configure the HNA and the	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5
	DOI. This includes necessary parameters to configure the primary/secondary rela	.1-8">
	tion as well as some information provided by the DOI that needs to be included b	<li pn="section-5.1-8.1">DM Control Channel (<xref target="sec-ctrl" f
	y the HNA in the Public Homenet Zone.</t>	ormat="default" sectionFormat="of" derivedContent="Section 6"/>) to configure th
	<t>DM Synchronization Channel (<xref target="sec-synch"/>) to synchronize the	e HNA and the DOI. This includes necessary parameters to configure the primary/s
	Public Homenet Zone on the HNA and on the DM with the appropriately configured p	econdary relation as well as some information provided by the DOI that needs to
	rimary/secondary.	be included by the HNA in the Public Homenet Zone.</li>
	This is a zone transfer over mutually authenticated TLS.</t>	<li pn="section-5.1-8.2">DM Synchronization Channel (<xref target="sec
	<t>one or more Distribution Channels (<xref target="sec-dist"/>) that distribu	-synch" format="default" sectionFormat="of" derivedContent="Section 7"/>) to syn
	te the Public Homenet Zone from the DM to the Public Authoritative Servers servi	chronize the Public Homenet Zone on the HNA and on the DM with the appropriately
	ng the Public Homenet Zone on the Internet.</t>	configured primary/secondary.
	</list></t>	This is a zone transfer over mutually authenticated TLS.</li>
		<li pn="section-5.1-8.3">One or more Distribution Channels (<xref targ
	<t>There might be multiple DM's, and multiple servers per DM.	et="sec-dist" format="default" sectionFormat="of" derivedContent="Section 8"/>)
		that distribute the Public Homenet Zone from the DM to the Public Authoritative
		Servers serving the Public Homenet Zone on the Internet.</li>
		</ul>
		<t indent="0" pn="section-5.1-9">There might be multiple DMs and multipl
		e servers per the DM.
	This document assumes a single DM server for simplicity, but there is no reason why each channel needs to be implemented on the same server or use the same code base.</t>	This document assumes a single DM server for simplicity, but there is no reason why each channel needs to be implemented on the same server or use the same code base.</t>

		<t indent="0" pn="section-5.1-10">It is important to note that while the
	<t>It is important to note that while the HNA is configured as an authoritative	HNA is configured as an authoritative server, it is not expected to answer DNS
	server, it is not expected to answer DNS requests from the <em>public</em> Inter	requests from the <em>public</em> Internet for the Public Homenet Zone.
	net for the Public Homenet Zone.	More specifically, the addresses associated with the HNA <bcp14>SHOULD NOT</bcp1
	More specifically, the addresses associated with the HNA SHOULD NOT be mentioned	4> be mentioned in the NS records of the Public Homenet Zone, unless additional
	in the NS records of the Public Homenet zone, unless additional security provis	security provisions necessary to protect the HNA from external attack have been
	ions necessary to protect the HNA from external attack have been taken.</t>	taken.</t>
		<t indent="0" pn="section-5.1-11">The DOI is also responsible for ensuri
	<t>The DOI is also responsible for ensuring the DS record has been updated in th	ng the DS record has been updated in the parent zone.</t>
	e parent zone.</t>	<t indent="0" pn="section-5.1-12">Resolution is performed by DNS Resolve
		rs.
	<t>Resolution is performed by DNS(SEC) resolvers.	When the resolution is performed outside the home network, the DNS Resolver reso
	When the resolution is performed outside the home network, the DNS(SEC) Resolver	lves the DS record on the Global DNS and the name associated with the Public Hom
	resolves the DS record on the Global DNS and the name associated with the Publi	enet Zone (myhome.example) on the Public Authoritative Servers.</t>
	c Homenet Zone (myhome.example) on the Public Authoritative Servers.</t>	<t indent="0" pn="section-5.1-13">In order to provide resilience to the
		Public Homenet Zone in case of WAN connectivity disruption, the Homenet DNS Reso
	<t>In order to provide resilience to the Public Homenet Zone in case of WAN conn	lver <bcp14>MUST</bcp14> be able to perform the resolution on the Homenet Author
	ectivity disruption, the Homenet DNS(SEC) Resolver MUST be able to perform the r	itative Servers.
	esolution on the Homenet Authoritative Servers.	Note that the use of the Homenet DNS Resolver enhances privacy since the user on
	Note that the use of the Homenet resolver enhances privacy since the user on the	the home network would no longer be leaking interactions with internal services
	home network would no longer be leaking interactions with internal services to	to an external DNS provider and to an on-path observer.
	an external DNS provider and to an on-path observer.	These servers are not expected to be mentioned in the Public Homenet Zone nor to
	These servers are not expected to be mentioned in the Public Homenet Zone, nor t	be accessible from the Internet.
	o be accessible from the Internet.	As such, their information as well as the corresponding signed DS record <bcp14>
	As such their information as well as the corresponding signed DS record MAY be p	MAY</bcp14> be provided by the HNA to the Homenet DNS Resolvers, e.g., by using
	rovided by the HNA to the Homenet DNS(SEC) Resolvers, e.g., using HNCP <xref tar	the Home Networking Control Protocol (HNCP) <xref target="RFC7788" format="defau
	get="RFC7788"/> or a by configuring a trust anchor <xref target="I-D.ietf-dnsop-	lt" sectionFormat="of" derivedContent="RFC7788"/> or by configuring a trust anch
	dnssec-validator-requirements"/>.	or <xref target="I-D.ietf-dnsop-dnssec-validator-requirements" format="default"
		sectionFormat="of" derivedContent="DRO-RECS"/>.
	Such configuration is outside the scope of this document.	Such configuration is outside the scope of this document.

	Since the scope of the Homenet Authoritative Servers is limited to the home netw	Since the scope of the Homenet Authoritative Servers is limited to the home netw
	ork, these servers are expected to serve the Homenet Zone as represented in <xre	ork, these servers are expected to serve the Homenet Zone as represented in <xre
	f target="fig-naming-arch"/>.</t>	f target="fig-naming-arch" format="default" sectionFormat="of" derivedContent="F
		igure 2"/>.</t>
	</section>	</section>
	<section anchor="sec-comms"><name>Distribution Manager (DM) Communication Channe	<section anchor="sec-comms" numbered="true" removeInRFC="false" toc="inclu
	ls</name>	de" pn="section-5.2">
		<name slugifiedName="name-distribution-manager-dm-com">Distribution Mana
	<t>This section details the DM channels, that is the Control Channel, the Synchr	ger (DM) Communication Channels</name>
	onization Channel and the Distribution Channel.</t>	<t indent="0" pn="section-5.2-1">This section details the DM channels: t
		he Control Channel, Synchronization Channel, and Distribution Channel.</t>
	<t>The Control Channel and the Synchronization Channel are the interfaces used b	<t indent="0" pn="section-5.2-2">The Control Channel and the Synchroniza
	etween the HNA and the DOI.	tion Channel are the interfaces used between the HNA and the DOI. The entity wit
	The entity within the DOI responsible to handle these communications is the DM.	hin the DOI responsible for handling these communications is the DM. Communicati
	Communications between the HNA and the DM MUST be protected and mutually authent	ons between the HNA and the DM <bcp14>MUST</bcp14> be protected and mutually aut
	icated.	henticated.
	<xref target="sec-ctrl-security"/> discusses in more depth the different securit	The different protocols that can be used for security are discussed in more dept
	y protocols that could be used to secure.</t>	h in <xref target="sec-ctrl-security" format="default" sectionFormat="of" derive
		dContent="Section 6.6"/>.</t>
	<t>The information exchanged between the HNA and the DM uses DNS messages protec	<t indent="0" pn="section-5.2-3">The information exchanged between the H
	ted by DNS over TLS (DoT) <xref target="RFC7858"/>.	NA and the DM uses DNS messages protected by DNS over TLS (DoT) <xref target="RF
	This is configured identically to that described in <xref target="RFC9103"/>, Se	C7858" format="default" sectionFormat="of" derivedContent="RFC7858"/>.
	ction 9.3.3.</t>	This is configured identically to that described in <xref target="RFC9103
		" sectionFormat="comma" section="9.3.3" format="default" derivedLink="https://rf
	<t>It is worth noting that both DM and HNA need to agree on a common configurati	c-editor.org/rfc/rfc9103#section-9.3.3" derivedContent="RFC9103"/>.</t>
	on to set up the synchronization channel as well as to build and server a cohere	<t indent="0" pn="section-5.2-4">It is worth noting that both the DM and
	nt Public Homenet Zone.	HNA need to agree on a common configuration in order to set up the Synchronizat
	As previously noted, the visible NS records of the Public Homenet Zone (built by	ion Channel and build and serve a coherent Public Homenet Zone.
	the HNA) remain pointing at the DOI's Public Authoritative Servers' IP address.	As previously noted, the visible NS records of the Public Homenet Zone (built by
	Unless the HNA is able to support the traffic load, the HNA SHOULD NOT appear as	the HNA) remain pointing at the IP address of the DOI's Public Authoritative Se
	a visible NS records of the Public Homenet Zone.	rvers.
	In addition, and depending on the configuration of the DOI, the DM also needs to	Unless the HNA is able to support the traffic load, the HNA <bcp14>SHOULD NOT</b
	update the parent zone's NS, DS and associated A or AAAA glue records.	cp14> appear as a visible NS record of the Public Homenet Zone.
	Refer to <xref target="sec-chain-of-trust"/> for more details.</t>	In addition, and depending on the configuration of the DOI, the DM also needs to
		update the parent zone's NS, DS, and associated A or AAAA glue records.
	<t>This specification assumes:</t>	Refer to <xref target="sec-chain-of-trust" format="default" sectionFormat="of" d
		erivedContent="Section 6.2"/> for more details.</t>
	<t><list style="symbols">	<t indent="0" pn="section-5.2-5">This specification assumes:</t>
	<t>the DM serves both the Control Channel and Synchronization Channel on a sin	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5
	gle IP address, single port and using a single transport protocol.</t>	.2-6">
	<t>By default, the HNA uses a single IP address for both the Control and Synch	<li pn="section-5.2-6.1">The DM serves both the Control Channel and Sy
	ronization channel.	nchronization Channel on a single IP address, on a single port, and by using a s
	However, the HNA MAY use distinct IP addresses for the Control Channel and the S	ingle transport protocol.</li>
	ynchronization Channel - see <xref target="sec-synch"/> and <xref target="sec-sy	<li pn="section-5.2-6.2">By default, the HNA uses a single IP address
	nc-info"/> for more details.</t>	for both the Control and Synchronization channels; however, the HNA <bcp14>MAY</
	</list></t>	bcp14> use distinct IP addresses for the Control Channel and the Synchronization
		Channel -- see Sections <xref target="sec-synch" format="counter" sectionFormat
	<t>The Distribution Channel is internal to the DOI and as such is not normativel	="of" derivedContent="7"/> and <xref target="sec-sync-info" format="counter" sec
	y defined by this specification.</t>	tionFormat="of" derivedContent="6.3"/> for more details.</li>
		</ul>
	</section>	<t indent="0" pn="section-5.2-7">The Distribution Channel is internal to
	</section>	the DOI and, as such, is not normatively defined by this specification.</t>
	<section anchor="sec-ctrl"><name>Control Channel</name>	</section>
		</section>
	<t>The DM Control Channel is used by the HNA and the DOI to exchange information	<section anchor="sec-ctrl" numbered="true" removeInRFC="false" toc="include"
	related to the configuration of the delegation which includes information to bu	pn="section-6">
	ild the Public Homenet Zone (<xref target="sec-pbl-homenet-zone"/>), information	<name slugifiedName="name-control-channel">Control Channel</name>
	to build the DNSSEC chain of trust (<xref target="sec-chain-of-trust"/>) and in	<t indent="0" pn="section-6-1">The DM Control Channel is used by the HNA a
	formation to set the Synchronization Channel (<xref target="sec-sync-info"/>).</	nd the DOI to exchange information related to the configuration of the delegatio
	t>	n, which includes information to build the Public Homenet Zone (<xref target="se
		c-pbl-homenet-zone" format="default" sectionFormat="of" derivedContent="Section
	<t>Some information is carried from the DOI to the HNA, described in the next se	6.1"/>), to build the DNSSEC chain of trust (<xref target="sec-chain-of-trust" f
	ction.	ormat="default" sectionFormat="of" derivedContent="Section 6.2"/>), and to set t
	The HNA updates the DOI with the the IP address on which the zone is to be trans	he Synchronization Channel (<xref target="sec-sync-info" format="default" sectio
	ferred using the synchronization channel.	nFormat="of" derivedContent="Section 6.3"/>).</t>
		<t indent="0" pn="section-6-2">Some information is carried from the DOI to
		the HNA, as described in the next section.
		The HNA updates the DOI with the IP address on which the zone is to be transferr
		ed using the Synchronization Channel.
	The HNA is always initiating the exchange in both directions.</t>	The HNA is always initiating the exchange in both directions.</t>

		<t indent="0" pn="section-6-3">As such, the HNA has a prior knowledge of t
	<t>As such the HNA has a prior knowledge of the DM identity (via X509 certificat	he DM identity (via an X.509 certificate), the IP address and port number to use
	e), the IP address and port number to use and protocol to establish a secure ses	, and the protocol to establish a secure session.
	sion.	The DM acquires knowledge of the identity of the HNA (X.509 certificate) a
	The DM acquires knowledge of the identity of the HNA (X509 certificate) as well	s well as the Registered Homenet Domain. For more detail on how this can be achi
	as the Registered Homenet Domain.	eved, please see <xref target="hna-provisioning" format="default" sectionFormat=
	For more detail to see how this can be achieved, please see <xref target="hna-pr	"of" derivedContent="Appendix A.1"/>.</t>
	ovisioning"/>.</t>	<section anchor="sec-pbl-homenet-zone" numbered="true" removeInRFC="false"
		toc="include" pn="section-6.1">
	<section anchor="sec-pbl-homenet-zone"><name>Information to Build the Public Hom	<name slugifiedName="name-building-the-public-homenet">Building the Publ
	enet Zone</name>	ic Homenet Zone</name>
		<t indent="0" pn="section-6.1-1">The HNA builds the Public Homenet Zone
	<t>The HNA builds the Public Homenet Zone based on a template that is returned b	based on a template that is returned by the DM to the HNA. <xref target="sec-ct
	y the DM to the HNA. <xref target="sec-ctrl-messages"/> explains how this lever	rl-messages" format="default" sectionFormat="of" derivedContent="Section 6.5"/>
	ages the AXFR mechanism.</t>	explains how this leverages the Authoritative Transfer (AXFR) mechanism.</t>
		<t indent="0" pn="section-6.1-2">In order to build its zone completely,
	<t>In order to build its zone completely, the HNA needs the names (and possibly	the HNA needs the names (and possibly IP addresses) of the Public Authoritative
	IP addresses) of the Public Authoritative Name Servers.	Name Servers.
	These are used to populate the NS records for the zone.	These are used to populate the NS records for the zone.

	All the content of the zone MUST be created by the HNA, because the zone is DNSS	All the content of the zone <bcp14>MUST</bcp14> be created by the HNA because th
	EC signed.</t>	e zone is DNSSEC signed.</t>
		<t indent="0" pn="section-6.1-3">In addition, the HNA needs to know what
	<t>In addition, the HNA needs to know what to put into the MNAME of the SOA, and	to put into the MNAME of the SOA, and only the DOI knows what to put there.
	only the DOI knows what to put there.	The DM <bcp14>MUST</bcp14> also provide useful operational parameters such as ot
	The DM MUST also provide useful operational parameters such as other fields of S	her fields of the SOA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE, and MINIMUM); howe
	OA (SERIAL, RNAME, REFRESH, RETRY, EXPIRE and MINIMUM), however, the HNA is free	ver, the HNA is free to override these values based upon local configuration.
	to override these values based upon local configuration.
	For instance, an HNA might want to change these values if it thinks that a renum bering event is approaching.</t>	For instance, an HNA might want to change these values if it thinks that a renum bering event is approaching.</t>

		<t indent="0" pn="section-6.1-4">Because the information associated with
	<t>As the information is necessary for the HNA to proceed and the information is	the DM is necessary for the HNA to proceed, this information exchange is mandat
	associated with the DM, this information exchange is mandatory.</t>	ory.</t>
		<t indent="0" pn="section-6.1-5">The HNA then performs a DNS Update oper
	<t>The HNA then performs a DNS Update operation to the DOI, updating the DOI wit	ation to the DOI, updating the DOI with an NS, a DS, and A and AAAA records. The
	h an NS, DS, A and AAAA records. These indicates where its Synchronization Chann	se indicate where its Synchronization Channel is.
	el is.	The DOI does not publish this NS record but uses it to perform zone transfers.</
	The DOI does not publish this NS record, but uses it to perform zone transfers.<	t>
	/t>	</section>
		<section anchor="sec-chain-of-trust" numbered="true" removeInRFC="false" t
	</section>	oc="include" pn="section-6.2">
	<section anchor="sec-chain-of-trust"><name>Information to build the DNSSEC chain	<name slugifiedName="name-building-the-dnssec-chain-o">Building the DNSS
	of trust</name>	EC Chain of Trust</name>
		<t indent="0" pn="section-6.2-1">The HNA <bcp14>MUST</bcp14> provide the
	<t>The HNA MUST provide the hash of the KSK via the DS RRset, so that the DOI ca	hash of the KSK via the DS RRset so that the DOI can provide this value to the
	n provide this value to the parent zone.	parent zone.
	A common deployment use case is that the DOI is the registrar of the Registered	A common deployment use case is that the DOI is the registrar of the Registered
	Homenet Domain and as such, its relationship with the registry of the parent zon	Homenet Domain; therefore, its relationship with the registry of the parent zone
	e enables it to update the parent zone.	enables it to update the parent zone. When such relation exists, the HNA should
	When such relation exists, the HNA should be able to request the DOI to update t	be able to request the DOI to update the DS RRset in the parent zone.
	he DS RRset in the parent zone.
	A direct update is especially necessary to initialize the chain of trust.</t>	A direct update is especially necessary to initialize the chain of trust.</t>

		<t indent="0" pn="section-6.2-2">Though the HNA may also directly update
	<t>Though the HNA may also later directly update the values of the DS via the Co	the values of the DS via the Control Channel at a later time, it is <bcp14>RECO
	ntrol Channel, it is RECOMMENDED to use other mechanisms such as CDS and CDNSKEY	MMENDED</bcp14> to use other mechanisms such as CDS and CDNSKEY <xref target="RF
	<xref target="RFC7344"/> for transparent updates during key roll overs.</t>	C7344" format="default" sectionFormat="of" derivedContent="RFC7344"/> for transp
		arent updates during key rollovers.</t>
	<t>As some deployments may not provide a DOI that will be able to update the DS	<t indent="0" pn="section-6.2-3">As some deployments may not provide a D
	in the parent zone, this information exchange is OPTIONAL.</t>	OI that will be able to update the DS in the parent zone, this information excha
		nge is <bcp14>OPTIONAL</bcp14>.</t>
	<t>By accepting the DS RR, the DM commits to advertise the DS to the parent zone	<t indent="0" pn="section-6.2-4">By accepting the DS RR, the DM commits
	.	to advertise the DS to the parent zone.
	On the other hand if the DM does not have the capacity to advertise the DS to th	On the other hand, if the DM does not have the capacity to advertise the DS to t
	e parent zone, it indicates this by refusing the update to the DS RR.</t>	he parent zone, it indicates this by refusing the update to the DS RR.</t>
		</section>
	</section>	<section anchor="sec-sync-info" numbered="true" removeInRFC="false" toc="i
	<section anchor="sec-sync-info"><name>Information to set up the Synchronization	nclude" pn="section-6.3">
	Channel</name>	<name slugifiedName="name-setting-up-the-synchronizat">Setting Up the Sy
		nchronization Channel</name>
	<t>The HNA works as a hidden primary authoritative DNS server, while the DM work	<t indent="0" pn="section-6.3-1">The HNA works as a hidden primary autho
	s like a secondary.	ritative DNS server while the DM works like a secondary one.
	As a result, the HNA needs to provide the IP address the DM should use to reach	As a result, the HNA needs to provide the IP address that the DM should use to r
	the HNA.</t>	each the HNA.</t>
		<t indent="0" pn="section-6.3-2">If the HNA detects that it has been ren
	<t>If the HNA detects that it has been renumbered, then it MUST use the Control	umbered, then it <bcp14>MUST</bcp14> use the Control Channel to update the DOI w
	Channel to update the DOI with the new IPv6 address it has been assigned.</t>	ith the new IPv6 address it has been assigned.</t>
		<t indent="0" pn="section-6.3-3">The Synchronization Channel will be set
	<t>The Synchronization Channel will be set between the new IPv6 (and IPv4) addre	between the new IPv6 (and IPv4) address and the IP address of the DM.
	ss and the IP address of the DM.	By default, the IP address used by the HNA in the Control Channel is considered
	By default, the IP address used by the HNA in the Control Channel is considered	by the DM, and the explicit specification of the IP by the HNA is only <bcp14>OP
	by the DM and the explicit specification of the IP by the HNA is only OPTIONAL.	TIONAL</bcp14>.
	The transport channel (including port number) is the same as the one used betwee	The transport channel (including the port number) is the same as the one used be
	n the HNA and the DM for the Control Channel.</t>	tween the HNA and the DM for the Control Channel.</t>
		</section>
	</section>	<section anchor="deleting-the-delegation" numbered="true" removeInRFC="fal
	<section anchor="deleting-the-delegation"><name>Deleting the delegation</name>	se" toc="include" pn="section-6.4">
		<name slugifiedName="name-deleting-the-delegation">Deleting the Delegati
	<t>The purpose of the previous sections were to exchange information in order to	on</name>
	set a delegation.	<t indent="0" pn="section-6.4-1">The purpose of the previous sections is
	The HNA MUST also be able to delete a delegation with a specific DM.</t>	to exchange information in order to set a delegation.
		The HNA <bcp14>MUST</bcp14> also be able to delete a delegation with a specific
	<t><xref target="sec-zone-delete"/> explains how a DNS Update operation on the C	DM.</t>
	ontrol Channel is used.</t>	<t indent="0" pn="section-6.4-2"><xref target="sec-zone-delete" format="
		default" sectionFormat="of" derivedContent="Section 6.5.4"/> explains how a DNS
	<t>Upon an instruction of deleting the delegation, the DM MUST stop serving the	Update operation on the Control Channel is used.</t>
	Public Homenet Zone.</t>	<t indent="0" pn="section-6.4-3">Upon receiving the instruction to delet
		e the delegation, the DM <bcp14>MUST</bcp14> stop serving the Public Homenet Zon
	<t>The decision to delete an inactive HNA by the DM is part of the commercial ag	e.</t>
	reement between DOI and HNA.</t>	<t indent="0" pn="section-6.4-4">The decision to delete an inactive HNA
		by the DM is part of the commercial agreement between the DOI and HNA.</t>
	</section>	</section>
	<section anchor="sec-ctrl-messages"><name>Messages Exchange Description</name>	<section anchor="sec-ctrl-messages" numbered="true" removeInRFC="false" to
		c="include" pn="section-6.5">
	<t>Multiple ways were considered on how the control information could be exchang	<name slugifiedName="name-message-exchange-descriptio">Message Exchange
	ed between the HNA and the DM.</t>	Description</name>
		<t indent="0" pn="section-6.5-1">Multiple ways were considered on how th
	<t>This specification defines a mechanism that re-uses the DNS zone transfer for	e control information could be exchanged between the HNA and the DM.</t>
	mat.	<t indent="0" pn="section-6.5-2">This specification defines a mechanism
	Note that while information is provided using DNS exchanges, the exchanged infor	that reuses the DNS zone transfer format.
	mation is not expected to be set in any zone file, instead this information is u	Note that while information is provided using DNS exchanges, the exchanged infor
	sed as commands between the HNA and the DM.	mation is not expected to be set in any zone file; instead, this information is
		used as commands between the HNA and the DM.
	This was found to be simpler on the home router side, as the HNA already has to have code to deal with all the DNS encodings/decodings.	This was found to be simpler on the home router side, as the HNA already has to have code to deal with all the DNS encodings/decodings.

	Inventing a new way to encode the DNS information in, for instance, JSON, seemed	Inventing a new way to encode the DNS information in, for instance, JSON seemed
	to add complexity for no return on investment.</t>	to add complexity for no return on investment.</t>
		<t indent="0" pn="section-6.5-3">The Control Channel is not expected to
	<t>The Control Channel is not expected to be a long-term session.	be a long-term session.
	After a predefined timer - similar to those used for TCP - the Control Channel i	After a predefined timer (similar to those used for TCP), the Control Channel is
	s expected to be terminated - by closing the transport channel.	expected to be terminated by closing the transport channel. The Control Channel
	The Control Channel MAY be re-opened at any time later.</t>	<bcp14>MAY</bcp14> be reopened at any later time.</t>
		<t indent="0" pn="section-6.5-4">The use of TLS session tickets (see <xr
	<t>The use of a TLS session tickets <xref section="4.6.1" sectionFormat="comma"	ef section="4.6.1" sectionFormat="comma" target="RFC8446" format="default" deriv
	target="RFC8446"/> is RECOMMENDED.</t>	edLink="https://rfc-editor.org/rfc/rfc8446#section-4.6.1" derivedContent="RFC844
		6"/>) is <bcp14>RECOMMENDED</bcp14>.</t>
	<t>The authentication of the channel MUST be based on certificates for both the	<t indent="0" pn="section-6.5-5">The authentication of the channel <bcp1
	DM and each HNA.	4>MUST</bcp14> be based on certificates for both the DM and each HNA.
	The DM may also create the initial configuration for the delegation zone in the parent zone during the provisioning process.</t>	The DM may also create the initial configuration for the delegation zone in the parent zone during the provisioning process.</t>

		<section anchor="zonetemplate" numbered="true" removeInRFC="false" toc="
	<section anchor="zonetemplate"><name>Retrieving information for the Public Homen	include" pn="section-6.5.1">
	et Zone</name>	<name slugifiedName="name-retrieving-information-for-">Retrieving Info
		rmation for the Public Homenet Zone</name>
	<t>The information provided by the DM to the HNA is retrieved by the HNA with an	<t indent="0" pn="section-6.5.1-1">The information provided by the DM
	AXFR exchange <xref target="RFC1034"/>.	to the HNA is retrieved by the HNA with an AXFR exchange <xref target="RFC1034"
		format="default" sectionFormat="of" derivedContent="RFC1034"/>.
	AXFR enables the response to contain any type of RRsets.</t>	AXFR enables the response to contain any type of RRsets.</t>

		<t indent="0" pn="section-6.5.1-2">To retrieve the necessary informati
	<t>To retrieve the necessary information to build the Public Homenet Zone, the H	on to build the Public Homenet Zone, the HNA <bcp14>MUST</bcp14> send a DNS requ
	NA MUST send a DNS request of type AXFR associated with the Registered Homenet D	est of type AXFR associated with the Registered Homenet Domain.</t>
	omain.</t>	<t indent="0" pn="section-6.5.1-3">The zone that is returned by the DM
		is used by the HNA as a template to build its own zone.</t>
	<t>The zone that is returned by the DM is used by the HNA as a template to build	<t indent="0" pn="section-6.5.1-4">The zone template <bcp14>MUST</bcp1
	its own zone.</t>	4> contain an RRset of type SOA, one or multiple RRsets of type NS, and zero or
		more RRsets of type A or AAAA (if the NS is in-domain <xref target="RFC8499" for
	<t>The zone template MUST contain a RRset of type SOA, one or multiple RRset of	mat="default" sectionFormat="of" derivedContent="RFC8499"/>). The zone template
	type NS and zero or more RRset of type A or AAAA (if the NS are in-domain <xref	will include Time-To-Live (TTL) values for each RR, and the HNA <bcp14>SHOULD</b
	target="RFC8499"/>).	cp14> take these as suggested maximum values, but it <bcp14>MAY</bcp14> use lowe
	The zone template will include Time To Live (TTL) values for each RR, and the HN	r values for operational reasons, such as for impending renumbering events.</t>
	A SHOULD take these as suggested maximum values, but MAY use lower values for op	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section
	erational reasons, such impending renumbering events.</t>	-6.5.1-5">
		<li pn="section-6.5.1-5.1">The SOA RR indicates the value of the MNA
	<t><list style="symbols">	ME of the Public Homenet Zone to the HNA.</li>
	<t>The SOA RR indicates to the HNA the value of the MNAME of the Public Homene	<li pn="section-6.5.1-5.2">The NAME of the SOA RR <bcp14>MUST</bcp14
	t Zone.</t>	> be the Registered Homenet Domain.</li>
	<t>The NAME of the SOA RR MUST be the Registered Homenet Domain.</t>	<li pn="section-6.5.1-5.3">The MNAME value of the SOA RDATA is the v
	<t>The MNAME value of the SOA RDATA is the value provided by the DOI to the HN	alue provided by the DOI to the HNA.</li>
	A.</t>	<li pn="section-6.5.1-5.4">Other RDATA values (RNAME, REFRESH, RETRY
	<t>Other RDATA values (RNAME, REFRESH, RETRY, EXPIRE and MINIMUM) are provided	, EXPIRE, and MINIMUM) are provided by the DOI as suggestions.</li>
	by the DOI as suggestions.</t>	</ul>
	</list></t>	<t indent="0" pn="section-6.5.1-6">The NS RRsets carry the Public Auth
		oritative Servers of the DOI.
	<t>The NS RRsets carry the Public Authoritative Servers of the DOI.	Their associated NAME <bcp14>MUST</bcp14> be the Registered Homenet Domain.</t>
	Their associated NAME MUST be the Registered Homenet Domain.</t>	<t indent="0" pn="section-6.5.1-7">In addition to the considerations a
		bove about default TTL, the HNA <bcp14>SHOULD</bcp14>
	<t>In addition to the considerations above about default TTL, the HNA SHOULD	take care to not pick a TTL larger than the parent NS, based upon the resolver's
	take care to not pick a TTL larger than the parent NS, based upon resolver's gui	guidelines in <xref target="I-D.ietf-dnsop-ns-revalidation" format="default" se
	de lines: <xref target="I-D.ietf-dnsop-ns-revalidation"/> and <xref target="I-D.	ctionFormat="of" derivedContent="NS-REVALIDATION"/> and <xref target="I-D.ietf-d
	ietf-dnsop-dnssec-validator-requirements"/>.	nsop-dnssec-validator-requirements" format="default" sectionFormat="of" derivedC
	The RRsets of Type A and AAAA MUST have their NAME matching the NSDNAME of one o	ontent="DRO-RECS"/>.
	f the NS RRsets.</t>	The RRsets of Type A and AAAA <bcp14>MUST</bcp14> have their NAME match
		ing the NSDNAME of one of the NS RRsets.</t>
	<t>Upon receiving the response, the HNA MUST validate format and properties of t	<t indent="0" pn="section-6.5.1-8">Upon receiving the response, the HN
	he SOA, NS and A or AAAA RRsets.	A <bcp14>MUST</bcp14> validate the format and properties of the SOA, NS, and A o
	If an error occurs, the HNA MUST stop proceeding and MUST log an error.	r AAAA RRsets.
	Otherwise, the HNA builds the Public Homenet Zone by setting the MNAME value of	If an error occurs, the HNA <bcp14>MUST</bcp14> stop proceeding and <bcp14>MUST<
	the SOA as indicated by the SOA provided by the AXFR response.	/bcp14> log an error.
	The HNA MUST not exceed the values of NAME, REFRESH, RETRY, EXPIRE and MINIMUM o	Otherwise, the HNA builds the Public Homenet Zone by setting the MNAME value of
	f the SOA to those provided by the AXFR response.	the SOA as indicated by the SOA provided by the AXFR response. The HNA <bcp14>MU
	The HNA MUST insert the NS and corresponding A or AAAA RRset in its Public Homen	ST NOT</bcp14> exceed the values of NAME, REFRESH, RETRY, EXPIRE, and MINIMUM of
	et Zone.	the SOA provided by the AXFR response. The HNA <bcp14>MUST</bcp14> insert the N
	The HNA MUST ignore other RRsets.</t>	S and corresponding A or AAAA RRsets in its Public Homenet Zone. The HNA <bcp14>
		MUST</bcp14> ignore other RRsets.</t>
	<t>If an error message is returned by the DM, the HNA MUST proceed as a regular	<t indent="0" pn="section-6.5.1-9">If an error message is returned by
	DNS resolution.	the DM, the HNA <bcp14>MUST</bcp14> proceed as a regular DNS resolution. Error m
	Error messages SHOULD be logged for further analysis.	essages <bcp14>SHOULD</bcp14> be logged for further analysis.
	If the resolution does not succeed, the outsourcing operation is aborted and the	If the resolution does not succeed, the outsourcing operation is aborted and the
	HNA MUST close the Control Channel.</t>	HNA <bcp14>MUST</bcp14> close the Control Channel.</t>
		</section>
	</section>	<section anchor="sec-ds" numbered="true" removeInRFC="false" toc="includ
	<section anchor="sec-ds"><name>Providing information for the DNSSEC chain of tru	e" pn="section-6.5.2">
	st</name>	<name slugifiedName="name-providing-information-for-t">Providing Infor
		mation for the DNSSEC Chain of Trust</name>
	<t>To provide the DS RRset to initialize the DNSSEC chain of trust the HNA MAY s	<t indent="0" pn="section-6.5.2-1">To provide the DS RRset to initiali
	end a DNS update <xref target="RFC3007"/> message.</t>	ze the DNSSEC chain of trust, the HNA <bcp14>MAY</bcp14> send a DNS update <xref
		target="RFC3007" format="default" sectionFormat="of" derivedContent="RFC3007"/>
	<t>The DNS update message is composed of a Header section, a Zone section, a Pre	message.</t>
	-requisite section, and Update section and an additional section.	<t indent="0" pn="section-6.5.2-2">The DNS update message is composed
	The Zone section MUST set the ZNAME to the parent zone of the Registered Homenet	of a Header section, a Zone section, a Prerequisite section, an Update section,
	Domain - that is where the DS records should be inserted. As described <xref ta	and an additional section.
	rget="RFC2136"/>, ZTYPE is set to SOA and ZCLASS is set to the zone's class.	The Zone section <bcp14>MUST</bcp14> set the ZNAME to the parent zone of the Reg
	The Pre-requisite section MUST be empty.	istered Homenet Domain, which is where the DS records should be inserted. As des
	The Update section is a DS RRset with its NAME set to the Registered Homenet Dom	cribed in <xref target="RFC2136" format="default" sectionFormat="of" derivedCont
	ain and the associated RDATA corresponds to the value of the DS.	ent="RFC2136"/>, ZTYPE is set to SOA and ZCLASS is set to the zone's class.
	The Additional Data section MUST be empty.</t>	The Prerequisite section <bcp14>MUST</bcp14> be empty.
		The Update section is a DS RRset with its NAME set to the Registered Homenet Dom
	<t>Though the pre-requisite section MAY be ignored by the DM, this value is fixe	ain, and the associated RDATA corresponds to the value of the DS.
	d to remain coherent with a standard DNS update.</t>	The Additional Data section <bcp14>MUST</bcp14> be empty.</t>
		<t indent="0" pn="section-6.5.2-3">Though the Prerequisite section <bc
	<t>Upon receiving the DNS update request, the DM reads the DS RRset in the Updat	p14>MAY</bcp14> be ignored by the DM, this value is fixed to remain coherent wit
	e section.	h a standard DNS update.</t>
	The DM checks ZNAME corresponds to the parent zone.	<t indent="0" pn="section-6.5.2-4">Upon receiving the DNS update reque
	The DM MUST ignore the Pre-requisite and Additional Data sections, if present.	st, the DM reads the DS RRset in the Update section.
	The DM MAY update the TTL value before updating the DS RRset in the parent zone.	The DM checks that ZNAME corresponds to the parent zone. The DM <bcp14>MUST</bcp
	Upon a successful update, the DM should return a NOERROR response as a commitmen	14> ignore the Prerequisite and Additional Data sections, if present. The DM <bc
	t to update the parent zone with the provided DS.	p14>MAY</bcp14> update the TTL value before updating the DS RRset in the parent
	An error indicates the DM does not update the DS, and the HNA needs to act accor	zone. Upon a successful update, the DM should return a NOERROR response as a com
	dingly or other method should be used by the HNA.</t>	mitment to update the parent zone with the provided DS. An error indicates that
		the DM does not update the DS, and the HNA needs to act accordingly; otherwise,
	<t>The regular DNS error message MUST be returned to the HNA when an error occur	another method should be used by the HNA.</t>
	s.	<t indent="0" pn="section-6.5.2-5">The regular DNS error message <bcp1
	In particular a FORMERR is returned when a format error is found, this includes	4>MUST</bcp14> be returned to the HNA when an error occurs. In particular, a FOR
	when unexpected RRSets are added or when RRsets are missing.	MERR is returned when a format error is found, including when unexpected RRsets
	A SERVFAIL error is returned when a internal error is encountered.	are added or when RRsets are missing. A SERVFAIL error is returned when an inter
	A NOTZONE error is returned when update and Zone sections are not coherent, a NO	nal error is encountered.
	TAUTH error is returned when the DM is not authoritative for the Zone section.	A NOTZONE error is returned when the Update and Zone sections are not coherent,
	A REFUSED error is returned when the DM refuses to proceed to the configuration	and a NOTAUTH error is returned when the DM is not authoritative for the Zone se
	and the requested action.</t>	ction. A REFUSED error is returned when the DM refuses the configuration or perf
		orming the requested action.</t>
	</section>	</section>
	<section anchor="sec-ip-hna"><name>Providing information for the Synchronization	<section anchor="sec-ip-hna" numbered="true" removeInRFC="false" toc="in
	Channel</name>	clude" pn="section-6.5.3">
		<name slugifiedName="name-providing-information-for-th">Providing Info
	<t>The default IP address used by the HNA for the Synchronization Channel is the	rmation for the Synchronization Channel</name>
	IP address of the Control Channel.	<t indent="0" pn="section-6.5.3-1">The default IP address used by the
	To provide a different IP address, the HNA MAY send a DNS UPDATE message.</t>	HNA for the Synchronization Channel is the IP address of the Control Channel. To
		provide a different IP address, the HNA <bcp14>MAY</bcp14> send a DNS UPDATE me
	<t>Similarly to the <xref target="sec-ds"/>, the HNA MAY specify the IP address	ssage.</t>
	using a DNS update message.	<t indent="0" pn="section-6.5.3-2">Similar to what is described in <xr
	The Zone section sets its ZNAME to the parent zone of the Registered Homenet Dom	ef target="sec-ds" format="default" sectionFormat="of" derivedContent="Section 6
	ain, ZTYPE is set to SOA and ZCLASS is set to the zone's type.	.5.2"/>, the HNA <bcp14>MAY</bcp14> specify the IP address using a DNS update me
	Pre-requisite is empty.	ssage. The Zone section sets its ZNAME to the parent zone of the Registered Home
	The Update section is a RRset of type NS.	net Domain, ZTYPE to SOA, and ZCLASS to the zone's type. Prerequisite is empty.
	The Additional Data section contains the RRsets of type A or AAAA that designate	The Update section is an RRset of type NS. The Additional Data section contains
	s the IP addresses associated with the primary (or the HNA).</t>	the RRsets of type A or AAAA that designate the IP addresses associated with the
		primary (or the HNA).</t>
	<t>The reason to provide these IP addresses is to keep them unpublished and prev	<t indent="0" pn="section-6.5.3-3">The reason to provide these IP addr
	ent them to be resolved.	esses is to keep them unpublished and prevent them from being resolved. It is <b
	It is RECOMMENDED the IP address of the HNA is randomly chosen to prevent it fro	cp14>RECOMMENDED</bcp14> that the IP address of the HNA be randomly chosen to pr
	m being easily discovered as well.</t>	event it from being easily discovered as well.</t>
		<t indent="0" pn="section-6.5.3-4">Upon receiving the DNS update reque
	<t>Upon receiving the DNS update request, the DM reads the IP addresses and chec	st, the DM reads the IP addresses and checks that the ZNAME corresponds to the p
	ks the ZNAME corresponds to the parent zone.	arent zone. The DM <bcp14>MUST</bcp14> ignore a non-empty Prerequisite section.
	The DM MUST ignore a non-empty Pre-requisite section.	The DM configures the secondary with the IP addresses and returns a NOERROR resp
	The DM configures the secondary with the IP addresses and returns a NOERROR resp	onse to indicate it is committed to serve as a secondary.</t>
	onse to indicate it is committed to serve as a secondary.</t>	<t indent="0" pn="section-6.5.3-5">Similar to what is described in <xr
		ef target="sec-ds" format="default" sectionFormat="of" derivedContent="Section 6
	<t>Similarly to <xref target="sec-ds"/>, DNS errors are used and an error indica	.5.2"/>, DNS errors are used, and an error indicates the DM is not configured as
	tes the DM is not configured as a secondary.</t>	a secondary.</t>
		</section>
	</section>	<section anchor="sec-zone-delete" numbered="true" removeInRFC="false" to
	<section anchor="sec-zone-delete"><name>HNA instructing deleting the delegation<	c="include" pn="section-6.5.4">
	/name>	<name slugifiedName="name-initiating-deletion-of-the-">Initiating Dele
		tion of the Delegation</name>
	<t>To instruct to delete the delegation the HNA sends a DNS UPDATE Delete messag	<t indent="0" pn="section-6.5.4-1">To initiate the deletion of the del
	e.</t>	egation, the HNA sends a DNS UPDATE Delete message.</t>
		<t indent="0" pn="section-6.5.4-2">The Zone section sets its ZNAME to
	<t>The Zone section sets its ZNAME to the Registered Homenet Domain, the ZTYPE t	the Registered Homenet Domain, the ZTYPE to SOA, and the ZCLASS to the zone's ty
	o SOA and the ZCLASS to zone's type.	pe. The Prerequisite section is empty. The Update section is an RRset of type NS
	The Pre-requisite section is empty.	with the NAME set to the Registered Domain Name.
	The Update section is a RRset of type NS with the NAME set to the Registered Dom	As indicated by <xref target="RFC2136" sectionFormat="comma" section="2
	ain Name.	.5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2136#section-2
	As indicated by <xref target="RFC2136"/> Section 2.5.2 the delete instruction is	.5.2" derivedContent="RFC2136"/>, the delete instruction is initiated by setting
	set by setting the TTL to 0, the Class to ANY, the RDLENGTH to 0 and the RDATA	TTL to 0, CLASS to ANY, and RDLENGTH to 0, and RDATA <bcp14>MUST</bcp14> be emp
	MUST be empty.	ty. The Additional Data section is empty.</t>
	The Additional Data section is empty.</t>	<t indent="0" pn="section-6.5.4-3">Upon receiving the DNS update reque
		st, the DM checks the request and removes the delegation. The DM returns a NOERR
	<t>Upon receiving the DNS update request, the DM checks the request and removes	OR response to indicate the delegation has been deleted. Similar to what is desc
	the delegation.	ribed in <xref target="sec-ds" format="default" sectionFormat="of" derivedConten
	The DM returns a NOERROR response to indicate the delegation has been deleted.	t="Section 6.5.2"/>, DNS errors are used, and an error indicates that the delega
	Similarly to <xref target="sec-ds"/>, DNS errors are used and an error indicates	tion has not been deleted.</t>
	the delegation has not been deleted.</t>	</section>
		</section>
	</section>	<section anchor="sec-ctrl-security" numbered="true" removeInRFC="false" to
	</section>	c="include" pn="section-6.6">
	<section anchor="sec-ctrl-security"><name>Securing the Control Channel</name>	<name slugifiedName="name-securing-the-control-channe">Securing the Cont
		rol Channel</name>
	<t>TLS <xref target="RFC8446"/>) MUST be used to secure the transactions between	<t indent="0" pn="section-6.6-1">TLS <xref target="RFC8446" format="defa
	the DM and the HNA and	ult" sectionFormat="of" derivedContent="RFC8446"/> <bcp14>MUST</bcp14> be used t
	the DM and HNA MUST be mutually authenticated.	o secure the transactions between the DM and the HNA, and the DM and HNA <bcp14>
	The DNS exchanges are performed using DNS over TLS <xref target="RFC7858"/>.</t>	MUST</bcp14> be mutually authenticated.
		The DNS exchanges are performed using DNS over TLS <xref target="RFC7858" format
	<t>The HNA may be provisioned by the manufacturer, or during some user-initiated	="default" sectionFormat="of" derivedContent="RFC7858"/>.</t>
	onboarding process, for example, with a browser, signing up to a service provid	<t indent="0" pn="section-6.6-2">The HNA may be provisioned by the manuf
	er, with a resulting OAUTH2 token to be provided to the HNA.	acturer or during some user-initiated onboarding process, for example, with a br
	Such a process may result in a passing of a settings from a Registrar into the H	owser, by signing up to a service provider, and with a resulting OAuth 2.0 token
	NA through an http API interface. (This is not in scope)</t>	to be provided to the HNA. Such a process may result in a passing of a settings
		from a registrar into the HNA through an http API interface. (This is not in sc
	<t>When the HNA connects to the DM's control channel, TLS will be used, and the	ope for this document.)</t>
	connection will be mutually authenticated.	<t indent="0" pn="section-6.6-3">When the HNA connects to the DM's Contr
	The DM will authenticate the HNA's certificate based upon having participating i	ol Channel, TLS will be used, and the connection will be mutually authenticated.
	n some provisioning process that is not standardized by this document.	The DM will authenticate the HNA's certificate based upon having participated in
	The results of the provisioning process is a series of settings described in <xr	some provisioning process that is not standardized by this document. The result
	ef target="hna-provisioning"/>.</t>	s of the provisioning process is a series of settings described in <xref target=
		"hna-provisioning" format="default" sectionFormat="of" derivedContent="Appendix
	<t>The HNA will validate the DM's control channel certificate by doing an <xref	A.1"/>.</t>
	target="I-D.ietf-uta-rfc6125bis"/> DNS-ID check on the name.</t>	<t indent="0" pn="section-6.6-4">The HNA will validate the DM's Control
		Channel certificate by performing a DNS-ID check on the name as described in <xr
	<t>In the future, other specifications may consider protecting DNS messages with	ef target="RFC9525" format="default" sectionFormat="of" derivedContent="RFC9525"
	other transport layers, among others, DNS over DTLS <xref target="RFC8094"/>, o	/>.</t>
	r DNS over HTTPs (DoH) <xref target="RFC8484"/> or DNS over QUIC <xref target="R	<t indent="0" pn="section-6.6-5">In the future, other specifications may
	FC9250"/>.</t>	consider protecting DNS messages with other transport layers such as DNS over D
		TLS <xref target="RFC8094" format="default" sectionFormat="of" derivedContent="R
	</section>	FC8094"/>, DNS over HTTPS (DoH) <xref target="RFC8484" format="default" sectionF
	</section>	ormat="of" derivedContent="RFC8484"/>, or DNS over QUIC <xref target="RFC9250" f
	<section anchor="sec-synch"><name>Synchronization Channel</name>	ormat="default" sectionFormat="of" derivedContent="RFC9250"/>.</t>
		</section>
	<t>The DM Synchronization Channel is used for communication between the HNA and	</section>
	the DM for synchronizing the Public Homenet Zone.	<section anchor="sec-synch" numbered="true" removeInRFC="false" toc="include
	Note that the Control Channel and the Synchronization Channel are by constructio	" pn="section-7">
	n different channels even though there they may use the same IP address.	<name slugifiedName="name-synchronization-channel">Synchronization Channel
	Suppose the HNA and the DM are using a single IP address and let designate by XX	</name>
	.	<t indent="0" pn="section-7-1">The DM Synchronization Channel is used for
	YYYYY and ZZZZZ the various ports involved in the communications.</t>	communication between the HNA and the DM for synchronizing the Public Homenet Zo
		ne. Note that the Control Channel and the Synchronization Channel are different
	<t>The Control Channel is between the HNA working as a client using port number	channels by construction even though they may use the same IP address. Suppose t
	YYYYY (an ephemeral also commonly designated as high range port) toward a servic	he HNA and the DM are using a single IP address designated by XX, and YYYYY and
	e provided by the DM at port 853, when using DoT.</t>	ZZZZZ are the various ports involved in the communications.</t>
		<t indent="0" pn="section-7-2">The Control Channel is between</t>
	<t>On the other hand, the Synchronization Channel is set between the DM working	<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7-3
	as a client using port ZZZZZ (another ephemeral port) toward a service provided	">
	by the HNA at port 853.</t>	<li pn="section-7-3.1">the HNA working as a client using port number YYY
		YY (an ephemeral also commonly designated as a high range port) and</li>
	<t>As a result, even though the same pair of IP addresses may be involved the Co	<li pn="section-7-3.2">a service provided by the DM at port 853, when us
	ntrol Channel and the Synchronization Channel are always distinct channels.</t>	ing DoT.</li>
		</ul>
	<t>Uploading and dynamically updating the zone file on the DM can be seen as zon	<t indent="0" pn="section-7-4">On the other hand, the Synchronization Chan
	e provisioning between the HNA (Hidden Primary) and the DM (Secondary Server).	nel is between</t>
	This is handled using the normal zone transfer mechanism involving AXFR/IXFR.</t	<ul bare="false" empty="false" indent="3" spacing="normal" pn="section-7-5
	>	">
		<li pn="section-7-5.1">the DM working as a client using port ZZZZZ (anot
	<t>Part of this zone update process involves the owner of the zone (the hidden p	her ephemeral port) and</li>
	rimary, the HNA) sending a DNS Notify to the secondaries.	<li pn="section-7-5.2">a service provided by the HNA at port 853.</li>
	In this situation the only destination that is known by the HNA is the DM's Cont	</ul>
	rol Channel, and so DNS notifies are sent over the Control Channel, secured by a	<t indent="0" pn="section-7-6">As a result, even though the same pair of I
	mutually authenticated TLS.</t>	P addresses may be involved, the Control Channel and the Synchronization Channel
		are always distinct channels.</t>
	<t>Please note that, DNS Notifies are not critical to normal operation, as the D	<t indent="0" pn="section-7-7">Uploading and dynamically updating the zone
	M will be checking the zone regularly based upon SOA record comments. DNS Notif	file on the DM can be seen as zone provisioning between the HNA (hidden primary
	ies do speed things up as they cause the DM to use the Synchronization channel t	server) and the DM (secondary server).
	o immediately do an SOA Query to detect any updates. If there are any changes t	This is handled using the normal zone transfer mechanism involving the AXFR and
	hen the DM immediately transfers the zone updates.</t>	Incremental Zone Transfer (IXFR).</t>
		<t indent="0" pn="section-7-8">Part of the process to update the zone invo
	<t>This specification standardizes the use of a primary / secondary mechanism <x	lves the owner of the zone (the hidden primary server, the HNA) sending a DNS No
	ref target="RFC1996"/> rather than an extended series of DNS update messages.	tify to the secondaries. In this situation, the only destination that is known b
	The primary / secondary mechanism was selected as it scales better and avoids Do	y the HNA is the DM's Control Channel, so DNS Notifies are sent over the Control
	S attacks.	Channel, secured by a mutually authenticated TLS.</t>
	As this AXFR runs over a TCP channel secured by a mutually authenticated TLS, th	<t indent="0" pn="section-7-9">Please note that DNS Notifies are not criti
	en DNS Update is just more complicated.</t>	cal to normal operation, as the DM will be checking the zone regularly based upo
		n SOA record comments. DNS Notifies do speed things up as they cause the DM to
	<t>Note that this document provides no standard way to distribute a DNS primary	use the Synchronization Channel to immediately do an SOA query to detect any upd
	between multiple devices.	ates. If there are any changes, then the DM immediately transfers the zone upda
	As a result, if multiple devices are candidate for hosting the Hidden Primary, s	tes.</t>
	ome specific mechanisms should be designed so the home network only selects a si	<t indent="0" pn="section-7-10">This specification standardizes the use of
	ngle HNA for the Hidden Primary.	a primary/secondary mechanism <xref target="RFC1996" format="default" sectionFo
	Selection mechanisms based on HNCP <xref target="RFC7788"/> are good candidates	rmat="of" derivedContent="RFC1996"/> rather than an extended series of DNS updat
	for future work.</t>	e messages. The primary/secondary mechanism was selected as it scales better and
		avoids DoS attacks. Because this AXFR runs over a TCP channel secured by a mutu
	<section anchor="sec-synch-security"><name>Securing the Synchronization Channel<	ally authenticated TLS, the DNS update is more complicated.</t>
	/name>	<t indent="0" pn="section-7-11">Note that this document provides no standa
		rd way to distribute a DNS primary between multiple devices. As a result, if mul
	<t>The Synchronization Channel uses mutually authenticated TLS, as described by	tiple devices are candidates for hosting the hidden primary server, some specifi
	<xref target="RFC9103"/>.</t>	c mechanisms should be designed so the home network only selects a single HNA fo
		r the hidden primary server. Selection mechanisms based on HNCP <xref target="RF
	<t>There is a TLS client certificate used by the DM to authenticate itself.	C7788" format="default" sectionFormat="of" derivedContent="RFC7788"/> are good c
	The DM uses the same certificate which was configured into the HNA for authentic	andidates for future work.</t>
	ating the Control Channel, but as a client certificate rather than a server cert	<section anchor="sec-synch-security" numbered="true" removeInRFC="false" t
	ificate.</t>	oc="include" pn="section-7.1">
		<name slugifiedName="name-securing-the-synchronizatio">Securing the Sync
	<t><xref target="RFC9103"/> makes no requirements or recommendations on any exte	hronization Channel</name>
	nded key usage flags for zone transfers, and this document adopts the view that	<t indent="0" pn="section-7.1-1">The Synchronization Channel uses mutual
	none should be required.	ly authenticated TLS, as described by <xref target="RFC9103" format="default" se
	and leave it up to <xref target="RFC9103"/> to get updated for this document's	ctionFormat="of" derivedContent="RFC9103"/>.</t>
	normative reference to be considered updated as well.</t>	<t indent="0" pn="section-7.1-2">There is a TLS client certificate used
		by the DM to authenticate itself.
	<t>For the TLS server certificate, the HNA uses the same certificate which it us	The DM uses the same certificate that was configured into the HNA for authentica
	es to authenticate itself to the DM for the Control Channel.</t>	ting the Control Channel, but as a client certificate rather than a server certi
		ficate.</t>
	<t>The HNA MAY use this certificate as the authorization for the zone transfer,	<t indent="0" pn="section-7.1-3"><xref target="RFC9103" format="default"
	or the HNA MAY have been configured with an Access Control List that will determ	sectionFormat="of" derivedContent="RFC9103"/> makes no requirements or recommen
	ine if the zone transfer can proceed.	dations on any extended key usage flags for zone transfers, and this document ad
	This is a local configuration option, as it is premature to determine which will	opts the view that none should be required. Note that once an update to <xref ta
	be operationally simpler.</t>	rget="RFC9103" format="default" sectionFormat="of" derivedContent="RFC9103"/> is
		published, this document's normative reference to <xref target="RFC9103" format
	<t>When the HNA expects to do zone transfer authorization by certificate only, t	="default" sectionFormat="of" derivedContent="RFC9103"/> will be considered upda
	he HNA MAY still apply an ACL on inbound connection requests to avoid load.	ted as well.</t>
	In this case, the HNA MUST regularly check (via a DNS resolution) that the addre	<t indent="0" pn="section-7.1-4">For the TLS server certificate, the HNA
	ss(es) of the DM in the filter is still valid.</t>	uses the same certificate that it uses to authenticate itself to the DM for the
		Control Channel.</t>
	</section>	<t indent="0" pn="section-7.1-5">The HNA <bcp14>MAY</bcp14> use this cer
	</section>	tificate as the authorization for the zone transfer, or the HNA <bcp14>MAY</bcp1
	<section anchor="sec-dist"><name>DM Distribution Channel</name>	4> have been configured with an Access Control List (ACL) that will determine if
		the zone transfer can proceed. This is a local configuration option as it is pr
	<t>The DM Distribution Channel is used for communication between the DM and the	emature to determine which will be operationally simpler.</t>
	Public Authoritative Servers.	<t indent="0" pn="section-7.1-6">When the HNA expects to do zone transfe
	The architecture and communication used for the DM Distribution Channels are out	r authorization by certificate only, the HNA <bcp14>MAY</bcp14> still apply an A
	side the scope of this document, and there are many existing solutions available	CL on inbound connection requests to avoid load.
	, e.g., rsync, DNS AXFR, REST, DB copy.</t>	In this case, the HNA <bcp14>MUST</bcp14> regularly check (via a DNS resolution)
		the validity of the address(es) of the DM in the filter.</t>
	</section>	</section>
	<section anchor="sec-cpe-sec-policies"><name>HNA Security Policies</name>	</section>
		<section anchor="sec-dist" numbered="true" removeInRFC="false" toc="include"
	<t>The HNA as hidden primary processes only a limited message exchanges on it's	pn="section-8">
	Internet facing interface.	<name slugifiedName="name-dm-distribution-channel">DM Distribution Channel
	This should be enforced using security policies - to allow only a subset of DNS	</name>
	requests to be received by HNA.</t>	<t indent="0" pn="section-8-1">The DM Distribution Channel is used for com
		munication between the DM and the Public Authoritative Servers.
	<t>The Hidden Primary Server on the HNA differs the regular authoritative server	The architecture and communication used for the DM Distribution Channels are out
	for the home network due to:</t>	side the scope of this document, but there are many existing solutions available
		, e.g., rsync, DNS AXFR, REST, and DB copy.</t>
	<dl>	</section>
	<dt>Interface Binding:</dt>	<section anchor="sec-cpe-sec-policies" numbered="true" removeInRFC="false" t
	<dd>	oc="include" pn="section-9">
	<t>the Hidden Primary Server will almost certainly listen on the WAN Interfa	<name slugifiedName="name-hna-security-policies">HNA Security Policies</na
	ce, whereas a regular Homenet Authoritative Servers would listen on the internal	me>
	home network interface.</t>	<t indent="0" pn="section-9-1">The HNA, as the hidden primary server, proc
	</dd>	esses only limited message exchanges on its Internet-facing interface.
	<dt>Limited exchanges:</dt>	This should be enforced using security policies to allow only a subset of DNS re
	<dd>	quests to be received by HNA.</t>
	<t>the purpose of the Hidden Primary Server is to synchronize with the DM, n	<t indent="0" pn="section-9-2">The hidden primary server on the HNA differ
	ot to serve any zones to end users, or the public Internet.	s from the regular authoritative server for the home network due to the followin
	This results in a limited number of possible exchanges (AXFR/IXFR) with a small	g:</t>
	number of IP addresses and an implementation MUST enable filtering policies: it	<dl indent="3" newline="false" spacing="normal" pn="section-9-3">
	should only respond to queries that are required to do zone transfers.	<dt pn="section-9-3.1">Interface Binding:</dt>
	That list includes SOA queries and AXFR/IXFR queries.</t>	<dd pn="section-9-3.2">The hidden primary server will almost certainly l
	</dd>	isten on the WAN Interface, whereas a regular Homenet Authoritative Server will
	</dl>	listen on the internal home network interface.
		</dd>
	</section>	<dt pn="section-9-3.3">Limited Exchanges:</dt>
	<section anchor="sec-reverse"><name>Public Homenet Reverse Zone</name>	<dd pn="section-9-3.4">The purpose of the hidden primary server is to sy
		nchronize with the DM, not to serve any zones to end users or the public Interne
	<t>Public Homenet Reverse Zone works similarly to the Public Homenet Zone.	t. This results in a limited number of possible exchanges (AXFR/IXFR) with a sma
	The main difference is that ISP that provides the IPv6 connectivity is likely al	ll number of IP addresses, and an implementation <bcp14>MUST</bcp14> enable filt
	so the owner of the corresponding IPv6 reverse zone and administrating the Rever	ering policies: it should only respond to queries that are required to do zone t
	se Public Authoritative Servers.	ransfers.
	The configuration and the setting of the Synchronization Channel and Control Cha	That list includes SOA queries and AXFR/IXFR queries.
	nnel can largely be automated using DHCPv6 messages that are part of the IPv6 Pr	</dd>
	efix Delegation process.</t>	</dl>
		</section>
	<t>The Public Homenet Zone is associated with a Registered Homenet Domain and th	<section anchor="sec-reverse" numbered="true" removeInRFC="false" toc="inclu
	e ownership of that domain requires a specific registration from the end user as	de" pn="section-10">
	well as the HNA being provisioned with some authentication credentials.	<name slugifiedName="name-public-homenet-reverse-zone">Public Homenet Reve
	Such steps are mandatory unless the DOI has some other means to authenticate the	rse Zone</name>
	HNA.	<t indent="0" pn="section-10-1">The Public Homenet Reverse Zone works simi
	Such situation may occur, for example, when the ISP provides the Homenet Domain	larly to the Public Homenet Zone.
	as well as the DOI.</t>	The main difference is that the ISP that provides the IPv6 connectivity is likel
		y to also be the owner of the corresponding IPv6 reverse zone who administrates
	<t>In this case, the HNA may be authenticated by the physical link layer, in whi	the Reverse Public Authoritative Servers. The configuration and the setting of t
	ch case the authentication of the HNA may be performed without additional provis	he Synchronization Channel and Control Channel can largely be automated using DH
	ioning of the HNA.	CPv6 messages that are a part of the IPv6 prefix delegation process.</t>
		<t indent="0" pn="section-10-2">The Public Homenet Zone is associated with
		a Registered Homenet Domain, and the ownership of that domain requires a specif
		ic registration from the end user as well as the HNA being provisioned with some
		authentication credentials. Such steps are mandatory unless the DOI has some ot
		her means to authenticate the HNA. Such situation may occur, for example, when t
		he ISP provides the Homenet Domain as well as the DOI.</t>
		<t indent="0" pn="section-10-3">In this case, the HNA may be authenticated
		by the physical link layer, in which case the authentication of the HNA may be
		performed without additional provisioning of the HNA.
	While this may not be so common for the Public Homenet Zone, this situation is e xpected to be quite common for the Reverse Homenet Zone as the ISP owns the IP a ddress or IP prefix.</t>	While this may not be so common for the Public Homenet Zone, this situation is e xpected to be quite common for the Reverse Homenet Zone as the ISP owns the IP a ddress or IP prefix.</t>

		<t indent="0" pn="section-10-4">More specifically, a common case is that t
	<t>More specifically, a common case is that the upstream ISP provides the IPv6 p	he upstream ISP provides the IPv6 prefix to the Homenet with an identity associa
	refix to the Homenet with a IA_PD <xref target="RFC8415"/> option and manages th	tion for a prefix delegation (IA_PD) option <xref target="RFC8415" format="defau
	e DOI of the associated reverse zone.</t>	lt" sectionFormat="of" derivedContent="RFC8415"/> and manages the DOI of the ass
		ociated reverse zone.</t>
	<t>This leaves place for setting up automatically the relation between HNA and t	<t indent="0" pn="section-10-5">This leaves a place for setting up the rel
	he DOI as described in <xref target="I-D.ietf-homenet-naming-architecture-dhc-op	ation between the HNA and DOI automatically as described in <xref target="RFC952
	tions"/>.</t>	7" format="default" sectionFormat="of" derivedContent="RFC9527"/>.</t>
		<t indent="0" pn="section-10-6">In the case of the reverse zone, the DOI a
	<t>In the case of the reverse zone, the DOI authenticates the source of the upda	uthenticates the source of the updates by IPv6 ACLs, and the ISP knows exactly w
	tes by IPv6 Access Control Lists.	hat addresses have been delegated. Therefore, the HNA <bcp14>SHOULD</bcp14> alwa
	In the case of the reverse zone, the ISP knows exactly what addresses have been	ys originate Synchronization Channel updates from an IP address within the zone
	delegated.	that is being updated. Exceptionally, the Synchronization Channel might be from
	The HNA SHOULD therefore always originate Synchronization Channel updates from a	a different zone delegated to the HNA (if there were multiple zones or renumberi
	n IP address within the zone that is being updated.	ng events were in progress).</t>
	Exceptionally, the synchronization channel might be from a different zone delega	<t indent="0" pn="section-10-7">For example, if the ISP has assigned 2001:
	ted to the HNA (if there were multiple zones, or renumbering events were in prog	db8:f00d:1234::/64 to the WAN interface (by DHCPv6 or PPP with Router Advertisem
	ress).</t>	ent (RA)), then the HNA should originate Synchronization Channel updates from, f
		or example, 2001:db8:f00d:1234::2.</t>
	<t>For example, if the ISP has assigned 2001:db8:f00d::/64 to the WAN interface	<t indent="0" pn="section-10-8">If an ISP has delegated 2001:db8:aeae::/56
	(by DHCPv6, or PPP/RA), then the HNA should originate Synchronization Channel up	to the HNA via DHCPv6-PD, then the HNA should originate Synchronization Channel
	dates from, for example, 2001:db8:f00d::2.</t>	updates to an IP address within that subnet, such as 2001:db8:aeae:1::2.</t>
		<t indent="0" pn="section-10-9">With this relation automatically configure
	<t>An ISP that has delegated 2001:db8:aeae::/56 to the HNA via DHCPv6-PD, then H	d, the synchronization between the Home network and the DOI happens in a similar
	NA should originate Synchronization Channel updates an IP within that subnet, su	way to the synchronization of the Public Homenet Zone described earlier in this
	ch as 2001:db8:aeae:1::2.</t>	document.</t>
		<t indent="0" pn="section-10-10">Note that for home networks connected to
	<t>With this relation automatically configured, the synchronization between the	multiple ISPs, each ISP provides only the DOI of the reverse zones associated wi
	Home network and the DOI happens similarly as for the Public Homenet Zone descri	th the delegated prefix. It is also likely that the DNS exchanges will need to b
	bed earlier in this document.</t>	e performed on dedicated interfaces to be accepted by the ISP. More specifically
		, the reverse zone update associated with prefix 1 cannot be performed by the HN
	<t>Note that for home networks connected to by multiple ISPs, each ISP provides	A using an IP address that belongs to prefix 2. Such constraints do not raise m
	only the DOI of the reverse zones associated with the delegated prefix.	ajor concerns for hot standby or load-sharing configuration.</t>
	It is also likely that the DNS exchanges will need to be performed on dedicated	<t indent="0" pn="section-10-11">With IPv6, the reverse domain space for I
	interfaces as to be accepted by the ISP.	P addresses associated with a subnet such as ::/64 is so large that the reverse
	More specifically, the reverse zone associated with prefix 1 will not be possibl	zone may be confronted with scalability issues.
	e to be performs by the HNA using an IP address that belongs to prefix 2.
	Such constraints does not raise major concerns either for hot standby or load sh
	aring configuration.</t>

	<t>With IPv6, the reverse domain space for IP addresses associated with a subnet
	such as ::/64 is so large that reverse zone may be confronted with scalability
	issues.
	How the reverse zone is generated is out of scope of this document.	How the reverse zone is generated is out of scope of this document.

	<xref target="RFC8501"/> provides guidance on how to address scalability issues.	<xref target="RFC8501" format="default" sectionFormat="of" derivedContent="RFC85
	</t>	01"/> provides guidance on how to address scalability issues.</t>
		</section>
	</section>	<section anchor="sec-dnssec-deployment" numbered="true" removeInRFC="false"
	<section anchor="sec-dnssec-deployment"><name>DNSSEC compliant Homenet Architect	toc="include" pn="section-11">
	ure</name>	<name slugifiedName="name-dnssec-compliant-homenet-ar">DNSSEC-Compliant Ho
		menet Architecture</name>
	<t><xref target="RFC7368"/> in Section 3.7.3 recommends DNSSEC to be deployed on	<t indent="0" pn="section-11-1"><xref target="RFC7368" sectionFormat="of"
	both the authoritative server and the resolver.</t>	section="3.7.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7368
		#section-3.7.3" derivedContent="RFC7368"/> recommends that DNSSEC be deployed on
	<t>The resolver side is out of scope of this document, and only the authoritativ	both the authoritative server and the resolver.</t>
	e part of the server is considered.	<t indent="0" pn="section-11-2">The resolver side is out of scope of this
	Other documents such as <xref target="RFC5011"/> deal with continuous update of	document, and only the authoritative part of the server is considered.
	trust anchors required for operation of a DNSSEC resolver.</t>	Other documents such as <xref target="RFC5011" format="default" sectionFor
		mat="of" derivedContent="RFC5011"/> deal with the continuous update of trust anc
	<t>The HNA MUST DNSSEC sign the Public Homenet Zone and the Public Reverse Zone.	hors required for operation of a DNSSEC Resolver.</t>
	</t>	<t indent="0" pn="section-11-3">The Public Homenet Zone and the Public Rev
		erse Zone <bcp14>MUST</bcp14> be DNSSEC signed by the HNA.</t>
	<t>Secure delegation is achieved only if the DS RRset is properly set in the par	<t indent="0" pn="section-11-4">Secure delegation is achieved only if the
	ent zone.	DS RRset is properly set in the parent zone.
	Secure delegation can be performed by the HNA or the DOIs and the choice highly	Secure delegation can be performed by the HNA or the DOIs, and the choice highly
	depends on which entity is authorized to perform such updates.	depends on which entity is authorized to perform such updates.
	Typically, the DS RRset is updated manually through a registrar interface, and c	Typically, the DS RRset is updated manually through a registrar interface and ca
	an be maintained with mechanisms such as CDS <xref target="RFC7344"/>.</t>	n be maintained with mechanisms such as CDS <xref target="RFC7344" format="defau
		lt" sectionFormat="of" derivedContent="RFC7344"/>.</t>
	<t>When the operator of the DOI is also the Registrar for the domain, then it is	<t indent="0" pn="section-11-5">When the operator of the DOI is also the r
	a trivial matter for the DOI to initialize the relevant DS records in the paren	egistrar for the domain, then it is a trivial matter for the DOI to initialize t
	t zone.	he relevant DS records in the parent zone.
	In other cases, some other initialization will be required, and that will be spe cific to the infrastructure involved.	In other cases, some other initialization will be required, and that will be spe cific to the infrastructure involved.
	It is beyond the scope of this document.</t>	It is beyond the scope of this document.</t>

		<t indent="0" pn="section-11-6">There may be some situations where the HNA
	<t>There may be some situations where the HNA is unable to arrange for secure de	is unable to arrange for secure delegation of the zones, but the HNA <bcp14>MUS
	legation of the zones, but the HNA MUST still sign the zones.</t>	T</bcp14> still sign the zones.</t>
		</section>
	</section>	<section anchor="sec-renumbering" numbered="true" removeInRFC="false" toc="i
	<section anchor="sec-renumbering"><name>Renumbering</name>	nclude" pn="section-12">
		<name slugifiedName="name-renumbering">Renumbering</name>
	<t>During a renumbering of the home network, the HNA IP address may be changed a	<t indent="0" pn="section-12-1">During a renumbering of the home network,
	nd the Public Homenet Zone will be updated by the HNA with new AAAA records.</t>	the HNA IP address may be changed and the Public Homenet Zone will be updated by
		the HNA with new AAAA records.</t>
	<t>The HNA will then advertise to the DM via a NOTIFY on the Control Channel.	<t indent="0" pn="section-12-2">The HNA will then advertise to the DM via
	The DM will need to note the new originating IP for the connection, and it will	a NOTIFY on the Control Channel.
	need to update it's internal database of Synchronization Channels.	The DM will need to note the new originating IP for the connection, and it will
		need to update its internal database of Synchronization Channels.
	A new zone transfer will occur with the new records for the resources that the H NA wishes to publish.</t>	A new zone transfer will occur with the new records for the resources that the H NA wishes to publish.</t>

		<t indent="0" pn="section-12-3">The remainder of the section provides reco
	<t>The remaining of the section provides recommendations regarding the provision	mmendations regarding the provisioning of the Public Homenet Zone, especially th
	ing of the Public Homenet Zone - especially the IP addresses.</t>	e IP addresses.</t>
		<t indent="0" pn="section-12-4">Renumbering has been extensively described
	<t>Renumbering has been extensively described in <xref target="RFC4192"/> and an	in <xref target="RFC4192" format="default" sectionFormat="of" derivedContent="R
	alyzed in <xref target="RFC7010"/> and the reader is expected to be familiar wit	FC4192"/> and analyzed in <xref target="RFC7010" format="default" sectionFormat=
	h them before reading this section.	"of" derivedContent="RFC7010"/>, and the reader is expected to be familiar with
	In the make-before-break renumbering scenario, the new prefix is advertised, the	them before reading this section.
	network is configured to prepare the transition to the new prefix.	In the make-before-break renumbering scenario, the new prefix is advertised, and
	During a period of time, the two prefixes old and new coexist, before the old pr	the network is configured to prepare the transition to the new prefix. During a
	efix is completely	period of time, the two prefixes (old and new) coexist before the old prefix is
	removed.	completely removed. New resource records containing the new prefix <bcp14>SHOUL
	New resources records containing the new prefix SHOULD be published, while the o	D</bcp14> be published, while the old resource records with the old prefixes <bc
	ld resource records with the old prefixes SHOULD be withdrawn.	p14>SHOULD</bcp14> be withdrawn. If the HNA anticipates that the period of overl
	If the HNA anticipates that period of overlap is long (perhaps due to knowledge	ap will be long (perhaps due to the knowledge of router and DHCPv6 lifetimes), i
	of router and DHCPv6 lifetimes), it MAY publish the old prefixes with a signific	t <bcp14>MAY</bcp14> publish the old prefixes with a significantly lower TTL.</t
	antly lower time to live.</t>	>
		<t indent="0" pn="section-12-5">In break-before-make renumbering scenarios
	<t>In break-before-make renumbering scenarios, including flash renumbering scena	, including flash renumbering scenarios <xref target="RFC8978" format="default"
	rios <xref target="RFC8978"/>, the old prefix becomes unuseable before the new p	sectionFormat="of" derivedContent="RFC8978"/>, the old prefix becomes unusable b
	refix is known or advertised.	efore the new prefix is known or advertised.
	As explained in <xref target="RFC8978"/>, some flash renumberings occur due to p	As explained in <xref target="RFC8978" format="default" sectionFormat="of" deriv
	ower cycling of the HNA, where ISPs do not properly remember what prefixes have	edContent="RFC8978"/>, some flash renumberings occur due to power cycling of the
	been assigned to which user.</t>	HNA, where ISPs do not properly remember what prefixes have been assigned to wh
		ich user.</t>
	<t>An HNA that boots up MUST immediately use the Control Channel to update the l	<t indent="0" pn="section-12-6">An HNA that boots up <bcp14>MUST</bcp14> i
	ocation for the Synchronization Channel.	mmediately use the Control Channel to update the location for the Synchronizatio
	This is a reasonable thing to do on every boot, as the HNA has no idea how long	n Channel. This is a reasonable thing to do on every boot, as the HNA has no ide
	it has been offline, or if the (DNSSEC) zone has perhaps expired during the time	a how long it has been offline or if the (DNSSEC) zone has perhaps expired durin
	the HNA was powered off.</t>	g the time the HNA was powered off.</t>
		<t indent="0" pn="section-12-7">The HNA will have a list of names that sho
	<t>The HNA will have a list of names that should be published, but it might not	uld be published, but it might not yet have IP addresses for those devices. This
	yet have IP addresses for those devices.	could be because at the time of power on, the other devices were not yet online
	This could be because at the time of power on, the other devices are not yet onl	.
	ine.
	If the HNA is sure that the prefix has not changed, then it should use the previ ously known addresses, with a very low TTL.</t>	If the HNA is sure that the prefix has not changed, then it should use the previ ously known addresses, with a very low TTL.</t>

		<t indent="0" pn="section-12-8">Although the new and old IP addresses may
	<t>Although the new and old IP addresses may be stored in the Public Homenet Zon	be stored in the Public Homenet Zone, it is <bcp14>RECOMMENDED</bcp14> that only
	e, it is RECOMMENDED that only the newly reachable IP addresses be published.</t	the newly reachable IP addresses be published.</t>
	>	<t indent="0" pn="section-12-9">Regarding the Public Homenet Reverse Zone,
		the new Public Homenet Reverse Zone has to be populated as soon as possible, an
	<t>Regarding the Public Homenet Reverse Zone, the new Public Homenet Reverse Zon	d the old Public Homenet Reverse Zone will be deleted by the owner of the zone (
	e has to be populated as soon as possible, and the old Public Homenet Reverse Zo	and the owner of the old prefix, which is usually the ISP) once the prefix is no
	ne will be deleted by the owner of the zone (and the owner of the old prefix whi	longer assigned to the HNA.
	ch is usually the ISP) once the prefix is no longer assigned to the HNA.	The ISP <bcp14>MUST</bcp14> ensure that the DNS cache has expired before reassig
	The ISP MUST ensure that the DNS cache has expired before re-assigning the prefi	ning the prefix to a new home network.
	x to a new home network.
	This may be enforced by controlling the TTL values.</t>	This may be enforced by controlling the TTL values.</t>

		<t indent="0" pn="section-12-10">To avoid reachability disruption, IP conn
	<t>To avoid reachability disruption, IP connectivity information provided by the	ectivity information provided by the DNS <bcp14>MUST</bcp14> be coherent with th
	DNS MUST be coherent with the IP in use.	e IP in use.
	In our case, this means the old IP address MUST NOT be provided via the DNS when	In our case, this means the old IP address <bcp14>MUST NOT</bcp14> be provided v
	it is not reachable anymore.</t>	ia the DNS when it is not reachable anymore.</t>
		<t indent="0" pn="section-12-11">In the make-before-break scenario, it is
	<t>In the make-before-break scenario, it is possible to make the transition seam	possible to make the transition seamless.
	less.	Let T be the TTL associated with an RRset of the Public Homenet Zone;
	Let T be the TTL associated with a RRset of the Public Homenet Zone.	Time_NEW be the time the new IP address replaces the old IP address in the Homen
	Let Time_NEW be the time the new IP address replaces the old IP address in the H	et Zone; and Time_OLD_UNREACHABLE be the time the old IP will not be reachable a
	omenet Zone, and Time_OLD_UNREACHABLE the time the old IP will not be reachable	nymore.</t>
	anymore.</t>	<t indent="0" pn="section-12-12">In the case of the make-before-break scen
		ario, seamless reachability is provided as long as Time_OLD_UNREACHABLE - T_NEW
	<t>In the case of the make-before-break, seamless reachability is provided as lo	> (2 * T).
	ng as Time_OLD_UNREACHABLE - T_NEW > (2 * T).
	If this is not satisfied, then devices associated with the old IP address in the home network may become unreachable for 2 * T - (Time_OLD_UNREACHABLE - Time_NE W).</t>	If this is not satisfied, then devices associated with the old IP address in the home network may become unreachable for 2 * T - (Time_OLD_UNREACHABLE - Time_NE W).</t>

		<t indent="0" pn="section-12-13">In the case of a break-before-make scenar
	<t>In the case of a break-before-make, Time_OLD_UNREACHABLE = Time_NEW, and the	io, Time_OLD_UNREACHABLE = Time_NEW, and the device may become unreachable up to
	device may become unreachable up to 2 * T.	2 * T.
	Of course if Time_NEW >= Time_OLD_UNREACHABLE, then then outage is not seamle	Of course, if Time_NEW >= Time_OLD_UNREACHABLE, then the outage is not seamle
	ss.</t>	ss.</t>
		</section>
	</section>	<section anchor="sec-privacy" numbered="true" removeInRFC="false" toc="inclu
	<section anchor="sec-privacy"><name>Privacy Considerations</name>	de" pn="section-13">
		<name slugifiedName="name-privacy-considerations">Privacy Considerations</
	<t>Outsourcing the DNS Authoritative service from the HNA to a third party raise	name>
	s a few privacy related concerns.</t>	<t indent="0" pn="section-13-1">Outsourcing the DNS Authoritative service
		from the HNA to a third party raises a few privacy-related concerns.</t>
	<t>The Public Homenet Zone lists the names of services hosted in the home networ	<t indent="0" pn="section-13-2">The Public Homenet Zone lists the names of
	k.	services hosted in the home network.
	Combined with blocking of AXFR queries, the use of NSEC3 <xref target="RFC5155"/	Combined with blocking of AXFR queries, the use of NSEC3 <xref target="RFC5155"
	> (vs NSEC <xref target="RFC4034"/>) prevents an attacker from being able to wa	format="default" sectionFormat="of" derivedContent="RFC5155"/> (vs. NSEC <xref t
	lk the zone, to discover all the names.	arget="RFC4034" format="default" sectionFormat="of" derivedContent="RFC4034"/>)
	However, recent work <xref target="GPUNSEC3"/> or <xref target="ZONEENUM"/> have	prevents an attacker from being able to walk the zone to discover all the names
	shown that the protection provided by NSEC3 against dictionary attacks should b	.
	e considered cautiously and <xref target="RFC9276"/> provides guidelines to conf	However, recent work <xref target="GPUNSEC3" format="default" sectionFormat="of"
	igure NSEC3 properly.	derivedContent="GPUNSEC3"/> <xref target="ZONEENUM" format="default" sectionFor
	In addition, the attacker may be able to walk the reverse DNS zone, or use other	mat="of" derivedContent="ZONEENUM"/> has shown that the protection provided by N
	reconnaissance techniques to learn this information as described in <xref targe	SEC3 against dictionary attacks should be considered cautiously, and <xref targe
	t="RFC7707"/>.</t>	t="RFC9276" format="default" sectionFormat="of" derivedContent="RFC9276"/> provi
		des guidelines to configure NSEC3 properly. In addition, the attacker may be abl
	<t>The zone may be also exposed during the synchronization between the primary a	e to walk the reverse DNS zone or use other reconnaissance techniques to learn t
	nd the secondary.	his information as described in <xref target="RFC7707" format="default" sectionF
	The casual risk of this occuring is low, and the use of <xref target="RFC9103"/>	ormat="of" derivedContent="RFC7707"/>.</t>
	significantly reduces this.	<t indent="0" pn="section-13-3">The zone may be also exposed during the sy
	Even if <xref target="RFC9103"/> is used by the DNS Outsourcing Infrastructure,	nchronization between the primary and the secondary. The casual risk of this occ
	it may still leak the existence of the zone through Notifies.	urring is low, and the use of <xref target="RFC9103" format="default" sectionFor
	The protocol described in this document does not increase that risk, as all Noti	mat="of" derivedContent="RFC9103"/> significantly reduces this. Even if DNS zone
	fies use the encrypted Control Channel.</t>	transfer over TLS <xref target="RFC9103" format="default" sectionFormat="of" de
		rivedContent="RFC9103"/> is used by the DOI, it may still leak the existence of
	<t>In general a home network owner is expected to publish only names for which t	the zone through Notifies. The protocol described in this document does not incr
	here is some need to be able to reference externally.	ease that risk, as all Notifies use the encrypted Control Channel.</t>
	Publication of the name does not imply that the service is necessarily reachable	<t indent="0" pn="section-13-4">In general, a home network owner is expect
	from any or all parts of the Internet.	ed to publish only names for which there is some need to reference them external
	<xref target="RFC7084"/> mandates that the outgoing-only policy <xref target="RF	ly. Publication of the name does not imply that the service is necessarily reach
	C6092"/> be available, and in many cases it is configured by default.	able from any or all parts of the Internet. <xref target="RFC7084" format="defau
	A well designed User Interface would combine a policy for making a service publi	lt" sectionFormat="of" derivedContent="RFC7084"/> mandates that the outgoing-onl
	c by a name with a policy on who may access it.</t>	y policy <xref target="RFC6092" format="default" sectionFormat="of" derivedConte
		nt="RFC6092"/> be available, and in many cases, it is configured by default.
	<t>In many cases, and for privacy reasons, the home network owner wished publish	A well-designed user interface would combine a policy for making a service publi
	names only for services that they will be able to access.	c by a name with a policy on who may access it.</t>
	The access control may consist of an IP source address range, or access may be r	<t indent="0" pn="section-13-5">In many cases, and for privacy reasons, th
	estricted via some VPN functionality.	e home network owner has wanted to publish names only for services that they wil
	The main advantages of publishing the name are that service may be access by the	l be able to access. The access control may consist of an IP source address rang
	same name both within the home and outside the home and that the DNS resolution	e, or access may be restricted via some VPN functionality. The main advantages o
	can be handled similarly within the home and outside the home.	f publishing the names are that the service may be accessed by the same name bot
	This considerably eases the ability to use VPNs where the VPN can be chosen acco	h within and outside the home, and the DNS resolution can be handled similarly b
	rding to the IP address of the service.	oth within and outside the home. This considerably eases the ability to use VPNs
	Typically, a user may configure its device to reach its homenet devices via a VP	where the VPN can be chosen according to the IP address of the service. Typical
	N while the remaining of the traffic is accessed directly.</t>	ly, a user may configure its device to reach its Homenet devices via a VPN while
		the remaining traffic is accessed directly.</t>
	<t>Enterprise networks have generally adopted another strategy designated as spl	<t indent="0" pn="section-13-6">Enterprise networks have generally adopted
	it-horizon-DNS.	another strategy designated as split-horizon-DNS. While such strategy might app
	While such strategy might appear as providing more privacy at first sight, its i	ear as providing more privacy at first sight, its implementation remains challen
	mplementation remains challenging and the privacy advantages needs to be conside	ging and the privacy advantages need to be considered carefully. In split-horizo
	red carefully.	n-DNS, names are designated with internal names that can only be resolved within
	In split-horizon-DNS, names are designated with internal names that can only be	the corporate network. When such strategy is applied to the homenet, VPNs need
	resolved within the corporate network.	to be configured with naming resolution policies and routing policies. Such an a
	When such strategy is applied to homenet, VPNs needs to be both configured with	pproach might be reasonable with a single VPN, but maintaining a coherent DNS sp
	a naming resolution policies and routing policies.	ace and IP space among various VPNs comes with serious complexities. Firstly, if
	Such approach might be reasonable with a single VPN, but maintaining a coherent	multiple homenets are using the same domain name -- like home.arpa -- it become
	DNS space and IP space among various VPNs comes with serious complexities.	s difficult to determine on which network the resolution should be performed. As
	Firstly, if multiple homenets are using the same domain name -- like home.arpa -	a result, homenets should at least be differentiated by a domain name. Secondly
	- it becomes difficult to determine on which network the resolution should be pe	, the use of split-horizon-DNS requires each VPN to be associated with a resolve
	rformed.	r and specific resolutions to be performed by the dedicated resolver. Such polic
	As a result, homenets should at least be differentiated by a domain name.	ies can easily raise some conflicts (with significant privacy issues) while rema
	Secondly, the use of split-horizon-DNS requires each VPN being associated with a	ining hard to be implemented.</t>
	resolver and specific resolutions being performed by the dedicated resolver.	<t indent="0" pn="section-13-7">In addition to the Public Homenet Zone, pe
	Such policies can easily raises some conflicts (with significant privacy issues)	rvasive DNS monitoring can also monitor the traffic associated with the Public H
	while remaining hard to be implemented.</t>	omenet Zone.
		This traffic may provide an indication of the services an end user accesses, plu
	<t>In addition to the Public Homenet Zone, pervasive DNS monitoring can also mon	s how and when they use these services. Although, caching may obfuscate this inf
	itor the traffic associated with the Public Homenet Zone.	ormation inside the home network, it is likely that this information will not be
	This traffic may provide an indication of the services an end user accesses, plu	cached outside the home network.</t>
	s how and when they use these services.	</section>
	Although, caching may obfuscate this information inside the home network, it is	<section anchor="sec-security" numbered="true" removeInRFC="false" toc="incl
	likely that outside your home network this information will not be cached.</t>	ude" pn="section-14">
		<name slugifiedName="name-security-considerations">Security Considerations
	</section>	</name>
	<section anchor="sec-security"><name>Security Considerations</name>	<t indent="0" pn="section-14-1">The HNA never answers DNS requests from th
		e Internet.
	<t>The HNA never answers DNS requests from the Internet.
	These requests are instead served by the DOI.</t>	These requests are instead served by the DOI.</t>

		<t indent="0" pn="section-14-2">While this limits the level of exposure of
	<t>While this limits the level of exposure of the HNA, the HNA still has some ex	the HNA, the HNA still has some exposure to attacks from the Internet.
	posure to attacks from the Internet.
	This section analyses the attack surface associated with these communications, t he data published by the DOI, as well as operational considerations.</t>	This section analyses the attack surface associated with these communications, t he data published by the DOI, as well as operational considerations.</t>

		<section anchor="registered-homenet-domain" numbered="true" removeInRFC="f
	<section anchor="registered-homenet-domain"><name>Registered Homenet Domain</nam	alse" toc="include" pn="section-14.1">
	e>	<name slugifiedName="name-registered-homenet-domain">Registered Homenet
		Domain</name>
	<t>The DOI MUST NOT serve any Public Homenet Zone that it has not strong confide	<t indent="0" pn="section-14.1-1">The DOI <bcp14>MUST NOT</bcp14> serve
	nce the HNA owns the Registered Homenet Domain.	any Public Homenet Zone when it is not confident that the HNA owns the Registere
	Proof of ownership is outside the document and is assumed such phase has precede	d Homenet Domain.
	d the outsourcing of the zone.</t>	Proof of ownership is outside the scope of this document, and it is assumed that
		such a phase has preceded the outsourcing of the zone.</t>
	</section>	</section>
	<section anchor="hna-dm-channels"><name>HNA DM channels</name>	<section anchor="hna-dm-channels" numbered="true" removeInRFC="false" toc=
		"include" pn="section-14.2">
	<t>The channels between HNA and DM are mutually authenticated and encrypted with	<name slugifiedName="name-hna-dm-channels">HNA DM Channels</name>
	TLS <xref target="RFC8446"/> and its associated security considerations apply.<	<t indent="0" pn="section-14.2-1">The channels between HNA and DM are mu
	/t>	tually authenticated and encrypted with TLS <xref target="RFC8446" format="defau
		lt" sectionFormat="of" derivedContent="RFC8446"/>, and its associated security c
	<t>To ensure the multiple TLS session are continuously authenticating the same e	onsiderations apply.</t>
	ntity, TLS may take advantage of second factor authentication as described in <x	<t indent="0" pn="section-14.2-2">To ensure that the multiple TLS sessio
	ref target="RFC8672"/> for the TLS server certificate for the Control Channel.	ns are continuously authenticating the same entity, TLS may take advantage of se
	The HNA should also cache the TLS server certificate used by the DM, in order to	cond-factor authentication as described in <xref target="RFC8672" format="defaul
	authenticate the DM during the setup of the Synchronization Channel.	t" sectionFormat="of" derivedContent="RFC8672"/> for the TLS server certificate
	(Alternatively, the HNA is configured with an ACL from which Synchronization Cha	for the Control Channel. The HNA should also cache the TLS server certificate us
	nnel connections will originate)</t>	ed by the DM, in order to authenticate the DM during the setup of the Synchroniz
		ation Channel. (Alternatively, the HNA is configured with an ACL from which Sync
	<t>The Control Channel and the Synchronization Channel respectively follow <xref	hronization Channel connections will originate.)</t>
	target="RFC7858"/> and <xref target="RFC9103"/> guidelines.</t>	<t indent="0" pn="section-14.2-3">The Control Channel and Synchronizatio
		n Channel follow the guidelines in <xref target="RFC7858" format="default" secti
	<t>The DNS protocol is subject to reflection attacks, however, these attacks are	onFormat="of" derivedContent="RFC7858"/> and <xref target="RFC9103" format="defa
	largely applicable when DNS is carried over UDP.	ult" sectionFormat="of" derivedContent="RFC9103"/>, respectively.</t>
	The interfaces between the HNA and DM are using TLS over TCP, which prevents suc	<t indent="0" pn="section-14.2-4">The DNS protocol is subject to reflect
	h reflection attacks.	ion attacks; however, these attacks are largely applicable when DNS is carried o
	Note that Public Authoritative servers hosted by the DOI are subject to such att	ver UDP. The interfaces between the HNA and DM are using TLS over TCP, which pre
	acks, but that is out of scope of our document.</t>	vents such reflection attacks.
		Note that Public Authoritative servers hosted by the DOI are subject to such att
	<t>Note that in the case of the Reverse Homenet Zone, the data is less subject t	acks, but that is out of scope of this document.</t>
	o attacks than in the Public Homenet Zone.	<t indent="0" pn="section-14.2-5">Note that in the case of the Reverse H
	In addition, the DM and Reverse Distribution Manager (RDM) may be provided by th	omenet Zone, the data is less subject to attacks than in the Public Homenet Zone
	e ISP - as described in <xref target="I-D.ietf-homenet-naming-architecture-dhc-o	. In addition, the DM and Reverse Distribution Manager (RDM) may be provided by
	ptions"/>, in which case DM and RDM might be less exposed to attacks - as commun	the ISP -- as described in <xref target="RFC9527" format="default" sectionFormat
	ications within a network.</t>	="of" derivedContent="RFC9527"/>, in which case DM and RDM might be less exposed
		to attacks -- as communications within a network.</t>
	</section>	</section>
	<section anchor="sec-name-less-secure"><name>Names are less secure than IP addre	<section anchor="sec-name-less-secure" numbered="true" removeInRFC="false"
	sses</name>	toc="include" pn="section-14.3">
		<name slugifiedName="name-names-are-less-secure-than-">Names Are Less Se
	<t>This document describes how an end user can make their services and devices f	cure than IP Addresses</name>
	rom their home network reachable on the Internet by using names rather than IP a	<t indent="0" pn="section-14.3-1">This document describes how an end use
	ddresses.	r can make their services and devices from their home network reachable on the I
	This exposes the home network to attackers, since names are expected to include	nternet by using names rather than IP addresses.
	less entropy than IP addresses.	This exposes the home network to attackers because names are expected to
	IPv4 Addresses are 4 bytes long leading to 2**32 possibilities.	include less entropy than IP addresses. IPv4 addresses are 4-bytes long leading
	With IPv6 addresses, the Interface Identifier is 64 bits long leading to up to 2	to 2<sup>32</sup> possibilities.
	^64 possibilities for a given subnetwork.	With IPv6 addresses, the Interface Identifier is 64-bits long leading to up to 2
	This is not to mention that the subnet prefix is also of 64 bits long, thus prov	<sup>64</sup> possibilities for a given subnetwork. This is not to mention that
	iding up to 2^64 possibilities.	the subnet prefix is also 64-bits long, thus providing up to 2<sup>64</sup> pos
	On the other hand, names used either for the home network domain or for the devi	sibilities. On the other hand, names used for either the home network domain or
	ces present less entropy (livebox, router, printer, nicolas, jennifer, ...) and	the devices present less entropy (livebox, router, printer, nicolas, jennifer, .
	thus potentially exposes the devices to dictionary attacks.</t>	..) and thus potentially expose the devices to dictionary attacks.</t>
		</section>
	</section>	<section anchor="sec-name-less-volatile" numbered="true" removeInRFC="fals
	<section anchor="sec-name-less-volatile"><name>Names are less volatile than IP a	e" toc="include" pn="section-14.4">
	ddresses</name>	<name slugifiedName="name-names-are-less-volatile-tha">Names Are Less Vo
		latile than IP Addresses</name>
	<t>IP addresses may be used to locate a device, a host or a service.	<t indent="0" pn="section-14.4-1">IP addresses may be used to locate a d
	However, home networks are not expected to be assigned a time invariant prefix b	evice, a host, or a service.
	y ISPs. In addition IPv6 enables temporary addresses that makes them even more v	However, home networks are not expected to be assigned a time-invariant prefix b
	olatile <xref target="RFC8981"/>.	y ISPs. In addition, IPv6 enables temporary addresses that makes them even more
	As a result, observing IP addresses only provides some ephemeral information abo	volatile <xref target="RFC8981" format="default" sectionFormat="of" derivedConte
	ut who is accessing the service.	nt="RFC8981"/>. As a result, observing IP addresses only provides some ephemeral
	On the other hand, names are not expected to be as volatile as IP addresses.	information about who is accessing the service. On the other hand, names are no
	As a result, logging names over time may be more valuable than logging IP addres	t expected to be as volatile as IP addresses. As a result, logging names over ti
	ses, especially to profile an end user's characteristics.</t>	me may be more valuable than logging IP addresses, especially to profile an end
		user's characteristics.</t>
	<t>PTR provides a way to bind an IP address to a name.	<t indent="0" pn="section-14.4-2">PTR provides a way to bind an IP addre
		ss to a name.
	In that sense, responding to PTR DNS queries may affect the end user's privacy.	In that sense, responding to PTR DNS queries may affect the end user's privacy.

	For that reason PTR DNS queries and MAY instead be configured to return with NXD	For that reason, PTR DNS queries <bcp14>MAY</bcp14> be configured to return with
	OMAIN.</t>	NXDOMAIN instead.</t>
		</section>
	</section>	<section anchor="deployment-considerations" numbered="true" removeInRFC="f
	<section anchor="deployment-considerations"><name>Deployment Considerations</nam	alse" toc="include" pn="section-14.5">
	e>	<name slugifiedName="name-deployment-considerations">Deployment Consider
		ations</name>
	<t>The HNA is expected to sign the DNSSEC zone and as such hold the private KSK/	<t indent="0" pn="section-14.5-1">The HNA is expected to sign the DNSSEC
	ZSK.</t>	zone and, as such, hold the private KSK and Zone Signing Key (ZSK).</t>
		<t indent="0" pn="section-14.5-2">In this case, there is no strong justi
	<t>There is no strong justification in this case to use a separate KSK and ZSK.	fication to use a separate KSK and ZSK.
	If an attacker can get access to one of them, it likely that they will access bo	If an attacker can get access to one of them, it is likely that they will access
	th of them.	both of them.
	If the HNA is run in a home router with a secure element (SE) or TPM, storing th	If the HNA is run in a home router with a secure element (SE) or trusted platfor
	e private keys in the secure element would be a useful precaution.	m module (TPM), storing the private keys in the secure element would be a useful
	The DNSSEC keys are generally needed on an hourly to weekly basis, but not more	precaution. The DNSSEC keys are generally needed on an hourly to weekly basis,
	often.</t>	but not more often.</t>
		<t indent="0" pn="section-14.5-3">While there is some risk that the DNSS
	<t>While there is some risk that the DNSSEC keys might be disclosed by malicious	EC keys might be disclosed by malicious parties, the bigger risk is that they wi
	parties, the bigger risk is that they will simply be lost if the home router is	ll simply be lost if the home router is factory reset or just thrown out / repla
	factory reset, or just thrown out/replaced with a newer model.</t>	ced with a newer model.</t>
		<t indent="0" pn="section-14.5-4">Generating new DNSSEC keys is relative
	<t>Generating new DNSSEC keys is relatively easy, they can be deployed using the	ly easy; they can be deployed using the Control Channel to the DM.
	Control Channel to the DM.	The key that is used to authenticate that connection is the critical key that ne
	The key that is used to authenticate that connection is the critical key that ne	eds protection and should ideally be backed up to offline storage (such as a USB
	eds protection, and should ideally be backed up to offline storage. (Such as a U	key).</t>
	SB key)</t>	</section>
		<section anchor="operational-considerations" numbered="true" removeInRFC="
	</section>	false" toc="include" pn="section-14.6">
	<section anchor="operational-considerations"><name>Operational Considerations</n	<name slugifiedName="name-operational-considerations">Operational Consid
	ame>	erations</name>
		<t indent="0" pn="section-14.6-1">Homenet technologies make it easier to
	<t>HomeNet technologies makes it easier to expose devices and services to the	expose devices and services to the
	Internet. This imposes broader operational considerations for the operator and	Internet. This imposes broader operational considerations for the operator and

	the Internet:</t>	the Internet as follows:</t>
		<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1
	<t><list style="symbols">	4.6-2">
	<t>The home network operator must carefully assess whether a device or service	<li pn="section-14.6-2.1">The home network operator must carefully ass
		ess whether a device or service
	previously fielded only on a home network is robust enough to be exposed to the	previously fielded only on a home network is robust enough to be exposed to the

	Internet</t>	Internet.</li>
	<t>The home network operator will need to increase the diligence to regularly	<li pn="section-14.6-2.2">The home network operator will need to incre
		ase the diligence to regularly
	managing these exposed devices due to their increased risk posture of being	managing these exposed devices due to their increased risk posture of being

	exposed to the Internet</t>	exposed to the Internet.</li>
	<t>Depending on the operational practices of the home network operators, there	<li pn="section-14.6-2.3">Depending on the operational practices of th
		e home network operators, there
	is an increased risk to the Internet through the possible	is an increased risk to the Internet through the possible

	introduction of additional internet-exposed system that are poorly managed and	introduction of additional Internet-exposed systems that are poorly managed and
	likely to be compromised.</t>	likely to be compromised.</li>
	</list></t>	</ul>
		</section>
	</section>	</section>
	</section>	<section anchor="iana-considerations" numbered="true" removeInRFC="false" to
	<section anchor="iana-considerations"><name>IANA Considerations</name>	c="include" pn="section-15">
		<name slugifiedName="name-iana-considerations">IANA Considerations</name>
	<t>This document has no actions for IANA.</t>	<t indent="0" pn="section-15-1">This document has no IANA actions.</t>
		</section>
	</section>
	<section anchor="acknowledgment"><name>Acknowledgment</name>

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

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

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

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

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

	</section>

	</middle>	</middle>


	<back>	<back>

		<displayreference target="I-D.ietf-dnsop-domain-verification-techniques" to=
	<references title='Normative References'>	"DOMAIN-VALIDATION"/>
		<displayreference target="I-D.ietf-dnsop-dnssec-validator-requirements" to="
	<reference anchor='RFC2119'>	DRO-RECS"/>
	<front>	<displayreference target="I-D.ietf-dnsop-ns-revalidation" to="NS-REVALIDATIO
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>	N"/>
	<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a	<displayreference target="I-D.richardson-homerouter-provisioning" to="HOMERO
	uthor>	UTER-PROVISION"/>
	<date month='March' year='1997'/>	<references pn="section-16">
	<abstract><t>In many standards track documents several words are used to signify	<name slugifiedName="name-references">References</name>
	the requirements in the specification. These words are often capitalized. This	<references pn="section-16.1">
	document defines these words as they should be interpreted in IETF documents.	<name slugifiedName="name-normative-references">Normative References</na
	This document specifies an Internet Best Current Practices for the Internet Comm	me>
	unity, and requests discussion and suggestions for improvements.</t></abstract>	<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1
	</front>	034" quoteTitle="true" derivedAnchor="RFC1034">
	<seriesInfo name='BCP' value='14'/>	<front>
	<seriesInfo name='RFC' value='2119'/>	<title>Domain names - concepts and facilities</title>
	<seriesInfo name='DOI' value='10.17487/RFC2119'/>	<author fullname="P. Mockapetris" initials="P." surname="Mockapetris
	</reference>	"/>
		<date month="November" year="1987"/>
	<reference anchor='RFC8174'>	<abstract>
	<front>	<t indent="0">This RFC is the revised basic definition of The Doma
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>	in Name System. It obsoletes RFC-882. This memo describes the domain style names
	<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho	and their used for host address look up and electronic mail forwarding. It disc
	r>	usses the clients and servers in the domain name system and the protocol used be
	<date month='May' year='2017'/>	tween them.</t>
	<abstract><t>RFC 2119 specifies common key words that may be used in protocol s	</abstract>
	pecifications. This document aims to reduce the ambiguity by clarifying that on	</front>
	ly UPPERCASE usage of the key words have the defined special meanings.</t></abs	<seriesInfo name="STD" value="13"/>
	tract>	<seriesInfo name="RFC" value="1034"/>
	</front>	<seriesInfo name="DOI" value="10.17487/RFC1034"/>
	<seriesInfo name='BCP' value='14'/>	</reference>
	<seriesInfo name='RFC' value='8174'/>	<reference anchor="RFC1918" target="https://www.rfc-editor.org/info/rfc1
	<seriesInfo name='DOI' value='10.17487/RFC8174'/>	918" quoteTitle="true" derivedAnchor="RFC1918">
	</reference>	<front>
		<title>Address Allocation for Private Internets</title>
	<reference anchor='RFC8375'>	<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
	<front>	<author fullname="B. Moskowitz" initials="B." surname="Moskowitz"/>
	<title>Special-Use Domain 'home.arpa.'</title>	<author fullname="D. Karrenberg" initials="D." surname="Karrenberg"/
	<author fullname='P. Pfister' initials='P.' surname='Pfister'><organization/></a	>
	uthor>	<author fullname="G. J. de Groot" initials="G. J." surname="de Groot
	<author fullname='T. Lemon' initials='T.' surname='Lemon'><organization/></autho	"/>
	r>	<author fullname="E. Lear" initials="E." surname="Lear"/>
	<date month='May' year='2018'/>	<date month="February" year="1996"/>
	<abstract><t>This document specifies the behavior that is expected from the Doma	<abstract>
	in Name System with regard to DNS queries for names ending with '.home.arpa.' an	<t indent="0">This document describes address allocation for priva
	d designates this domain as a special-use domain name. 'home.arpa.' is designate	te internets. This document specifies an Internet Best Current Practices for the
	d for non-unique use in residential home networks. The Home Networking Control	Internet Community, and requests discussion and suggestions for improvements.</
	Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.</t	t>
	></abstract>	</abstract>
	</front>	</front>
	<seriesInfo name='RFC' value='8375'/>	<seriesInfo name="BCP" value="5"/>
	<seriesInfo name='DOI' value='10.17487/RFC8375'/>	<seriesInfo name="RFC" value="1918"/>
	</reference>	<seriesInfo name="DOI" value="10.17487/RFC1918"/>
		</reference>
	<reference anchor='RFC1918'>	<reference anchor="RFC1996" target="https://www.rfc-editor.org/info/rfc1
	<front>	996" quoteTitle="true" derivedAnchor="RFC1996">
	<title>Address Allocation for Private Internets</title>	<front>
	<author fullname='Y. Rekhter' initials='Y.' surname='Rekhter'><organization/></a	<title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTI
	uthor>	FY)</title>
	<author fullname='B. Moskowitz' initials='B.' surname='Moskowitz'><organization/	<author fullname="P. Vixie" initials="P." surname="Vixie"/>
	></author>	<date month="August" year="1996"/>
	<author fullname='D. Karrenberg' initials='D.' surname='Karrenberg'><organizatio	<abstract>
	n/></author>	<t indent="0">This memo describes the NOTIFY opcode for DNS, by wh
	<author fullname='G. J. de Groot' initials='G. J.' surname='de Groot'><organizat	ich a master server advises a set of slave servers that the master's data has be
	ion/></author>	en changed and that a query should be initiated to discover the new data. [STAND
	<author fullname='E. Lear' initials='E.' surname='Lear'><organization/></author>	ARDS-TRACK]</t>
	<date month='February' year='1996'/>	</abstract>
	<abstract><t>This document describes address allocation for private internets.	</front>
	This document specifies an Internet Best Current Practices for the Internet Comm	<seriesInfo name="RFC" value="1996"/>
	unity, and requests discussion and suggestions for improvements.</t></abstract>	<seriesInfo name="DOI" value="10.17487/RFC1996"/>
	</front>	</reference>
	<seriesInfo name='BCP' value='5'/>	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	<seriesInfo name='RFC' value='1918'/>	119" quoteTitle="true" derivedAnchor="RFC2119">
	<seriesInfo name='DOI' value='10.17487/RFC1918'/>	<front>
	</reference>	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
		le>
	<reference anchor='RFC8499'>	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	<front>	<date month="March" year="1997"/>
	<title>DNS Terminology</title>	<abstract>
	<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a	<t indent="0">In many standards track documents several words are
	uthor>	used to signify the requirements in the specification. These words are often cap
	<author fullname='A. Sullivan' initials='A.' surname='Sullivan'><organization/><	italized. This document defines these words as they should be interpreted in IET
	/author>	F documents. This document specifies an Internet Best Current Practices for the
	<author fullname='K. Fujiwara' initials='K.' surname='Fujiwara'><organization/><	Internet Community, and requests discussion and suggestions for improvements.</t
	/author>	>
	<date month='January' year='2019'/>	</abstract>
	<abstract><t>The Domain Name System (DNS) is defined in literally dozens of diff	</front>
	erent RFCs. The terminology used by implementers and developers of DNS protocol	<seriesInfo name="BCP" value="14"/>
	s, and by operators of DNS systems, has sometimes changed in the decades since t	<seriesInfo name="RFC" value="2119"/>
	he DNS was first defined. This document gives current definitions for many of t	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	he terms used in the DNS in a single document.</t><t>This document obsoletes RFC	</reference>
	7719 and updates RFC 2308.</t></abstract>	<reference anchor="RFC3007" target="https://www.rfc-editor.org/info/rfc3
	</front>	007" quoteTitle="true" derivedAnchor="RFC3007">
	<seriesInfo name='BCP' value='219'/>	<front>
	<seriesInfo name='RFC' value='8499'/>	<title>Secure Domain Name System (DNS) Dynamic Update</title>
	<seriesInfo name='DOI' value='10.17487/RFC8499'/>	<author fullname="B. Wellington" initials="B." surname="Wellington"/
	</reference>	>
		<date month="November" year="2000"/>
	<reference anchor='RFC7858'>	<abstract>
	<front>	<t indent="0">This document proposes a method for performing secur
	<title>Specification for DNS over Transport Layer Security (TLS)</title>	e Domain Name System (DNS) dynamic updates. [STANDARDS-TRACK]</t>
	<author fullname='Z. Hu' initials='Z.' surname='Hu'><organization/></author>	</abstract>
	<author fullname='L. Zhu' initials='L.' surname='Zhu'><organization/></author>	</front>
	<author fullname='J. Heidemann' initials='J.' surname='Heidemann'><organization/	<seriesInfo name="RFC" value="3007"/>
	></author>	<seriesInfo name="DOI" value="10.17487/RFC3007"/>
	<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></aut	</reference>
	hor>	<reference anchor="RFC4034" target="https://www.rfc-editor.org/info/rfc4
	<author fullname='D. Wessels' initials='D.' surname='Wessels'><organization/></a	034" quoteTitle="true" derivedAnchor="RFC4034">
	uthor>	<front>
	<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a	<title>Resource Records for the DNS Security Extensions</title>
	uthor>	<author fullname="R. Arends" initials="R." surname="Arends"/>
	<date month='May' year='2016'/>	<author fullname="R. Austein" initials="R." surname="Austein"/>
	<abstract><t>This document describes the use of Transport Layer Security (TLS) t	<author fullname="M. Larson" initials="M." surname="Larson"/>
	o provide privacy for DNS. Encryption provided by TLS eliminates opportunities	<author fullname="D. Massey" initials="D." surname="Massey"/>
	for eavesdropping and on-path tampering with DNS queries in the network, such as	<author fullname="S. Rose" initials="S." surname="Rose"/>
	discussed in RFC 7626. In addition, this document specifies two usage profiles	<date month="March" year="2005"/>
	for DNS over TLS and provides advice on performance considerations to minimize	<abstract>
	overhead from using TCP and TLS with DNS.</t><t>This document focuses on securin	<t indent="0">This document is part of a family of documents that
	g stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It	describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a
	does not prevent future applications of the protocol to recursive-to-authoritat	collection of resource records and protocol modifications that provide source a
	ive traffic.</t></abstract>	uthentication for the DNS. This document defines the public key (DNSKEY), delega
	</front>	tion signer (DS), resource record digital signature (RRSIG), and authenticated d
	<seriesInfo name='RFC' value='7858'/>	enial of existence (NSEC) resource records. The purpose and format of each resou
	<seriesInfo name='DOI' value='10.17487/RFC7858'/>	rce record is described in detail, and an example of each resource record is giv
	</reference>	en.</t>
		<t indent="0">This document obsoletes RFC 2535 and incorporates ch
	<reference anchor='RFC9103'>	anges from all updates to RFC 2535. [STANDARDS-TRACK]</t>
	<front>	</abstract>
	<title>DNS Zone Transfer over TLS</title>	</front>
	<author fullname='W. Toorop' initials='W.' surname='Toorop'><organization/></aut	<seriesInfo name="RFC" value="4034"/>
	hor>	<seriesInfo name="DOI" value="10.17487/RFC4034"/>
	<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/	</reference>
	></author>	<reference anchor="RFC5155" target="https://www.rfc-editor.org/info/rfc5
	<author fullname='S. Sahib' initials='S.' surname='Sahib'><organization/></autho	155" quoteTitle="true" derivedAnchor="RFC5155">
	r>	<front>
	<author fullname='P. Aras' initials='P.' surname='Aras'><organization/></author>	<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existenc
	<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></aut	e</title>
	hor>	<author fullname="B. Laurie" initials="B." surname="Laurie"/>
	<date month='August' year='2021'/>	<author fullname="G. Sisson" initials="G." surname="Sisson"/>
	<abstract><t>DNS zone transfers are transmitted in cleartext, which gives attack	<author fullname="R. Arends" initials="R." surname="Arends"/>
	ers the opportunity to collect the content of a zone by eavesdropping on network	<author fullname="D. Blacka" initials="D." surname="Blacka"/>
	connections. The DNS Transaction Signature (TSIG) mechanism is specified to res	<date month="March" year="2008"/>
	trict direct zone transfer to authorized clients only, but it does not add confi	<abstract>
	dentiality. This document specifies the use of TLS, rather than cleartext, to pr	<t indent="0">The Domain Name System Security (DNSSEC) Extensions
	event zone content collection via passive monitoring of zone transfers: XFR over	introduced the NSEC resource record (RR) for authenticated denial of existence.
	TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with	This document introduces an alternative resource record, NSEC3, which similarly
	respect to efficient use of TCP connections and RFC 7766 with respect to the rec	provides authenticated denial of existence. However, it also provides measures a
	ommended number of connections between a client and server for each transport.</	gainst zone enumeration and permits gradual expansion of delegation-centric zone
	t></abstract>	s. [STANDARDS-TRACK]</t>
	</front>	</abstract>
	<seriesInfo name='RFC' value='9103'/>	</front>
	<seriesInfo name='DOI' value='10.17487/RFC9103'/>	<seriesInfo name="RFC" value="5155"/>
	</reference>	<seriesInfo name="DOI" value="10.17487/RFC5155"/>
		</reference>
	<reference anchor='RFC7344'>	<reference anchor="RFC7344" target="https://www.rfc-editor.org/info/rfc7
	<front>	344" quoteTitle="true" derivedAnchor="RFC7344">
	<title>Automating DNSSEC Delegation Trust Maintenance</title>	<front>
	<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></aut	<title>Automating DNSSEC Delegation Trust Maintenance</title>
	hor>	<author fullname="W. Kumari" initials="W." surname="Kumari"/>
	<author fullname='O. Gudmundsson' initials='O.' surname='Gudmundsson'><organizat	<author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson
	ion/></author>	"/>
	<author fullname='G. Barwood' initials='G.' surname='Barwood'><organization/></a	<author fullname="G. Barwood" initials="G." surname="Barwood"/>
	uthor>	<date month="September" year="2014"/>
	<date month='September' year='2014'/>	<abstract>
	<abstract><t>This document describes a method to allow DNS Operators to more eas	<t indent="0">This document describes a method to allow DNS Operat
	ily update DNSSEC Key Signing Keys using the DNS as a communication channel. Th	ors to more easily update DNSSEC Key Signing Keys using the DNS as a communicati
	e technique described is aimed at delegations in which it is currently hard to m	on channel. The technique described is aimed at delegations in which it is curre
	ove information from the Child to Parent.</t></abstract>	ntly hard to move information from the Child to Parent.</t>
	</front>	</abstract>
	<seriesInfo name='RFC' value='7344'/>	</front>
	<seriesInfo name='DOI' value='10.17487/RFC7344'/>	<seriesInfo name="RFC" value="7344"/>
	</reference>	<seriesInfo name="DOI" value="10.17487/RFC7344"/>
		</reference>
	<reference anchor='RFC8446'>	<reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7
	<front>	858" quoteTitle="true" derivedAnchor="RFC7858">
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>	<front>
	<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/><	<title>Specification for DNS over Transport Layer Security (TLS)</ti
	/author>	tle>
	<date month='August' year='2018'/>	<author fullname="Z. Hu" initials="Z." surname="Hu"/>
	<abstract><t>This document specifies version 1.3 of the Transport Layer Security	<author fullname="L. Zhu" initials="L." surname="Zhu"/>
	(TLS) protocol. TLS allows client/server applications to communicate over the	<author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
	Internet in a way that is designed to prevent eavesdropping, tampering, and mess	<author fullname="A. Mankin" initials="A." surname="Mankin"/>
	age forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs	<author fullname="D. Wessels" initials="D." surname="Wessels"/>
	5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	implementations.</t></abstract>	<date month="May" year="2016"/>
	</front>	<abstract>
	<seriesInfo name='RFC' value='8446'/>	<t indent="0">This document describes the use of Transport Layer S
	<seriesInfo name='DOI' value='10.17487/RFC8446'/>	ecurity (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates
	</reference>	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
	<reference anchor='RFC1034'>	sage profiles for DNS over TLS and provides advice on performance considerations
	<front>	to minimize overhead from using TCP and TLS with DNS.</t>
	<title>Domain names - concepts and facilities</title>	<t indent="0">This document focuses on securing stub-to-recursive
	<author fullname='P. Mockapetris' initials='P.' surname='Mockapetris'><organizat	traffic, as per the charter of the DPRIVE Working Group. It does not prevent fut
	ion/></author>	ure applications of the protocol to recursive-to-authoritative traffic.</t>
	<date month='November' year='1987'/>	</abstract>
	<abstract><t>This RFC is the revised basic definition of The Domain Name System.	</front>
	It obsoletes RFC-882. This memo describes the domain style names and their us	<seriesInfo name="RFC" value="7858"/>
	ed for host address look up and electronic mail forwarding. It discusses the cl	<seriesInfo name="DOI" value="10.17487/RFC7858"/>
	ients and servers in the domain name system and the protocol used between them.<	</reference>
	/t></abstract>	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	</front>	174" quoteTitle="true" derivedAnchor="RFC8174">
	<seriesInfo name='STD' value='13'/>	<front>
	<seriesInfo name='RFC' value='1034'/>	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	<seriesInfo name='DOI' value='10.17487/RFC1034'/>	tle>
	</reference>	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
		<date month="May" year="2017"/>
	<reference anchor='RFC3007'>	<abstract>
	<front>	<t indent="0">RFC 2119 specifies common key words that may be used
	<title>Secure Domain Name System (DNS) Dynamic Update</title>	in protocol specifications. This document aims to reduce the ambiguity by clari
	<author fullname='B. Wellington' initials='B.' surname='Wellington'><organizatio	fying that only UPPERCASE usage of the key words have the defined special meanin
	n/></author>	gs.</t>
	<date month='November' year='2000'/>	</abstract>
	<abstract><t>This document proposes a method for performing secure Domain Name S	</front>
	ystem (DNS) dynamic updates. [STANDARDS-TRACK]</t></abstract>	<seriesInfo name="BCP" value="14"/>
	</front>	<seriesInfo name="RFC" value="8174"/>
	<seriesInfo name='RFC' value='3007'/>	<seriesInfo name="DOI" value="10.17487/RFC8174"/>
	<seriesInfo name='DOI' value='10.17487/RFC3007'/>	</reference>
	</reference>	<reference anchor="RFC8375" target="https://www.rfc-editor.org/info/rfc8
		375" quoteTitle="true" derivedAnchor="RFC8375">
	<reference anchor='I-D.ietf-uta-rfc6125bis'>	<front>
	<front>	<title>Special-Use Domain 'home.arpa.'</title>
	<title>Service Identity in TLS</title>	<author fullname="P. Pfister" initials="P." surname="Pfister"/>
	<author fullname='Peter Saint-Andre' initials='P.' surname='Saint-Andre'>	<author fullname="T. Lemon" initials="T." surname="Lemon"/>
	<organization>independent</organization>	<date month="May" year="2018"/>
	</author>	<abstract>
	<author fullname='Rich Salz' initials='R.' surname='Salz'>	<t indent="0">This document specifies the behavior that is expecte
	<organization>Akamai Technologies</organization>	d from the Domain Name System with regard to DNS queries for names ending with '
	</author>	.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa
	<date day='25' month='January' year='2023'/>	.' is designated for non-unique use in residential home networks. The Home Netwo
	<abstract>	rking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead
	<t> Many application technologies enable secure communication between	of '.home'.</t>
	two	</abstract>
	entities by means of Transport Layer Security (TLS) with Internet	</front>
	Public Key Infrastructure Using X.509 (PKIX) certificates. This	<seriesInfo name="RFC" value="8375"/>
	document specifies procedures for representing and verifying the	<seriesInfo name="DOI" value="10.17487/RFC8375"/>
	identity of application services in such interactions.	</reference>
		<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
	This document obsoletes RFC 6125.	446" quoteTitle="true" derivedAnchor="RFC8446">
		<front>
	</t>	<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
	</abstract>	e>
	</front>	<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
	<seriesInfo name='Internet-Draft' value='draft-ietf-uta-rfc6125bis-10'/>	<date month="August" year="2018"/>
		<abstract>
	</reference>	<t indent="0">This document specifies version 1.3 of the Transport
		Layer Security (TLS) protocol. TLS allows client/server applications to communi
	<reference anchor='RFC1996'>	cate over the Internet in a way that is designed to prevent eavesdropping, tampe
	<front>	ring, and message forgery.</t>
	<title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>	<t indent="0">This document updates RFCs 5705 and 6066, and obsole
	<author fullname='P. Vixie' initials='P.' surname='Vixie'><organization/></autho	tes RFCs 5077, 5246, and 6961. This document also specifies new requirements for
	r>	TLS 1.2 implementations.</t>
	<date month='August' year='1996'/>	</abstract>
	<abstract><t>This memo describes the NOTIFY opcode for DNS, by which a master se	</front>
	rver advises a set of slave servers that the master's data has been changed and	<seriesInfo name="RFC" value="8446"/>
	that a query should be initiated to discover the new data. [STANDARDS-TRACK]</t>	<seriesInfo name="DOI" value="10.17487/RFC8446"/>
	</abstract>	</reference>
	</front>	<reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8
	<seriesInfo name='RFC' value='1996'/>	499" quoteTitle="true" derivedAnchor="RFC8499">
	<seriesInfo name='DOI' value='10.17487/RFC1996'/>	<front>
	</reference>	<title>DNS Terminology</title>
		<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<reference anchor='RFC5155'>	<author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
	<front>	<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
	<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>	<date month="January" year="2019"/>
	<author fullname='B. Laurie' initials='B.' surname='Laurie'><organization/></aut	<abstract>
	hor>	<t indent="0">The Domain Name System (DNS) is defined in literally
	<author fullname='G. Sisson' initials='G.' surname='Sisson'><organization/></aut	dozens of different RFCs. The terminology used by implementers and developers o
	hor>	f DNS protocols, and by operators of DNS systems, has sometimes changed in the d
	<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></aut	ecades since the DNS was first defined. This document gives current definitions
	hor>	for many of the terms used in the DNS in a single document.</t>
	<author fullname='D. Blacka' initials='D.' surname='Blacka'><organization/></aut	<t indent="0">This document obsoletes RFC 7719 and updates RFC 230
	hor>	8.</t>
	<date month='March' year='2008'/>	</abstract>
	<abstract><t>The Domain Name System Security (DNSSEC) Extensions introduced the	</front>
	NSEC resource record (RR) for authenticated denial of existence. This document i	<seriesInfo name="BCP" value="219"/>
	ntroduces an alternative resource record, NSEC3, which similarly provides authen	<seriesInfo name="RFC" value="8499"/>
	ticated denial of existence. However, it also provides measures against zone en	<seriesInfo name="DOI" value="10.17487/RFC8499"/>
	umeration and permits gradual expansion of delegation-centric zones. [STANDARDS	</reference>
	-TRACK]</t></abstract>	<reference anchor="RFC9103" target="https://www.rfc-editor.org/info/rfc9
	</front>	103" quoteTitle="true" derivedAnchor="RFC9103">
	<seriesInfo name='RFC' value='5155'/>	<front>
	<seriesInfo name='DOI' value='10.17487/RFC5155'/>	<title>DNS Zone Transfer over TLS</title>
	</reference>	<author fullname="W. Toorop" initials="W." surname="Toorop"/>
		<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
	<reference anchor='RFC4034'>	<author fullname="S. Sahib" initials="S." surname="Sahib"/>
	<front>	<author fullname="P. Aras" initials="P." surname="Aras"/>
	<title>Resource Records for the DNS Security Extensions</title>	<author fullname="A. Mankin" initials="A." surname="Mankin"/>
	<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></aut	<date month="August" year="2021"/>
	hor>	<abstract>
	<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></a	<t indent="0">DNS zone transfers are transmitted in cleartext, whi
	uthor>	ch gives attackers the opportunity to collect the content of a zone by eavesdrop
	<author fullname='M. Larson' initials='M.' surname='Larson'><organization/></aut	ping on network connections. The DNS Transaction Signature (TSIG) mechanism is s
	hor>	pecified to restrict direct zone transfer to authorized clients only, but it doe
	<author fullname='D. Massey' initials='D.' surname='Massey'><organization/></aut	s not add confidentiality. This document specifies the use of TLS, rather than c
	hor>	leartext, to prevent zone content collection via passive monitoring of zone tran
	<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>	sfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and
	<date month='March' year='2005'/>	RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with res
	<abstract><t>This document is part of a family of documents that describe the DN	pect to the recommended number of connections between a client and server for ea
	S Security Extensions (DNSSEC). The DNS Security Extensions are a collection of	ch transport.</t>
	resource records and protocol modifications that provide source authentication	</abstract>
	for the DNS. This document defines the public key (DNSKEY), delegation signer (	</front>
	DS), resource record digital signature (RRSIG), and authenticated denial of exis	<seriesInfo name="RFC" value="9103"/>
	tence (NSEC) resource records. The purpose and format of each resource record i	<seriesInfo name="DOI" value="10.17487/RFC9103"/>
	s described in detail, and an example of each resource record is given. </t><t>	</reference>
	This document obsoletes RFC 2535 and incorporates changes from all updates to RF	<reference anchor="RFC9525" target="https://www.rfc-editor.org/info/rfc9
	C 2535. [STANDARDS-TRACK]</t></abstract>	525" quoteTitle="true" derivedAnchor="RFC9525">
	</front>	<front>
	<seriesInfo name='RFC' value='4034'/>	<title>Service Identity in TLS</title>
	<seriesInfo name='DOI' value='10.17487/RFC4034'/>	<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
	</reference>	"/>
		<author fullname="R. Salz" initials="R." surname="Salz"/>
	</references>	<date month="November" year="2023"/>
		<abstract>
	<references title='Informative References'>	<t indent="0">Many application technologies enable secure communic
		ation between two entities by means of Transport Layer Security (TLS) with Inter
	<reference anchor="GPUNSEC3" target="https://doi.org/10.1109/NCA.2014.27">	net Public Key Infrastructure using X.509 (PKIX) certificates. This document spe
	<front>	cifies procedures for representing and verifying the identity of application ser
	<title>GPU-Based NSEC3 Hash Breaking</title>	vices in such interactions.</t>
	<author initials="M." surname="Wander">	<t indent="0">This document obsoletes RFC 6125.</t>
	<organization></organization>	</abstract>
	</author>	</front>
	<author initials="L." surname="Schwittmann">	<seriesInfo name="RFC" value="9525"/>
	<organization></organization>	<seriesInfo name="DOI" value="10.17487/RFC9525"/>
	</author>	</reference>
	<author initials="C." surname="Boelmann">	</references>
	<organization></organization>	<references pn="section-16.2">
	</author>	<name slugifiedName="name-informative-references">Informative References
	<author initials="T." surname="Weis">	</name>
	<organization></organization>	<reference anchor="I-D.ietf-dnsop-domain-verification-techniques" target
	</author>	="https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-tec
	<date year="n.d."/>	hniques-03" quoteTitle="true" derivedAnchor="DOMAIN-VALIDATION">
	</front>	<front>
	</reference>	<title>Domain Control Validation using DNS</title>
	<reference anchor="ZONEENUM" >	<author fullname="Shivan Kaul Sahib" initials="S." surname="Sahib">
	<front>	<organization showOnFrontPage="true">Brave Software</organization>
	<title>An efficient DNSSEC zone enumeration algorithm</title>	</author>
	<author initials="Z." surname="Wang">	<author fullname="Shumon Huque" initials="S." surname="Huque">
	<organization></organization>	<organization showOnFrontPage="true">Salesforce</organization>
	</author>	</author>
	<author initials="L." surname="Xiao">	<author fullname="Paul Wouters" initials="P." surname="Wouters">
	<organization></organization>	<organization showOnFrontPage="true">Aiven</organization>
	</author>	</author>
	<author initials="R." surname="Wang">	<author fullname="Erik Nygren" initials="E." surname="Nygren">
	<organization></organization>	<organization showOnFrontPage="true">Akamai Technologies</organiza
	</author>	tion>
	<date year="n.d."/>	</author>
	</front>	<date day="17" month="October" year="2023"/>
	</reference>	</front>
	<reference anchor="REBIND" target="https://en.wikipedia.org/wiki/DNS_rebinding">	<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-domain-verif
	<front>	ication-techniques-03"/>
	<title>DNS rebinding</title>	<refcontent>Work in Progress</refcontent>
	<author >	</reference>
	<organization></organization>	<reference anchor="I-D.ietf-dnsop-dnssec-validator-requirements" target=
	</author>	"https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-validator-require
	<date year="n.d."/>	ments-07" quoteTitle="true" derivedAnchor="DRO-RECS">
	</front>	<front>
	</reference>	<title>Recommendations for DNSSEC Resolvers Operators</title>
		<author initials="D." surname="Migault" fullname="Daniel Migault">
	<reference anchor='RFC6762'>	<organization showOnFrontPage="true">Ericsson</organization>
	<front>	</author>
	<title>Multicast DNS</title>	<author initials="E." surname="Lewis" fullname="Edward Lewis">
	<author fullname='S. Cheshire' initials='S.' surname='Cheshire'><organization/><	<organization showOnFrontPage="true">ICANN</organization>
	/author>	</author>
	<author fullname='M. Krochmal' initials='M.' surname='Krochmal'><organization/><	<author initials="D." surname="York" fullname="Dan York">
	/author>	<organization showOnFrontPage="true">Internet Society</organizatio
	<date month='February' year='2013'/>	n>
	<abstract><t>As networked devices become smaller, more portable, and more ubiqui	</author>
	tous, the ability to operate with less configured infrastructure is increasingly	<date month="November" day="13" year="2023"/>
	important. In particular, the ability to look up DNS resource record data type	<abstract>
	s (including, but not limited to, host names) in the absence of a conventional m	<t indent="0"> The DNS Security Extensions (DNSSEC) defines a pr
	anaged DNS server is useful.</t><t>Multicast DNS (mDNS) provides the ability to	ocess for validating
	perform DNS-like operations on the local link in the absence of any conventional
	Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS
	namespace to be free for local use, without the need to pay any annual fee, and
	without the need to set up delegations or otherwise configure a conventional DN
	S server to answer for those names.</t><t>The primary benefits of Multicast DNS
	names are that (i) they require little or no administration or configuration to
	set them up, (ii) they work when no infrastructure is present, and (iii) they wo
	rk during infrastructure failures.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='6762'/>
	<seriesInfo name='DOI' value='10.17487/RFC6762'/>
	</reference>

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

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

	<reference anchor='RFC3787'>
	<front>
	<title>Recommendations for Interoperable IP Networks using Intermediate System t
	o Intermediate System (IS-IS)</title>
	<author fullname='J. Parker' initials='J.' role='editor' surname='Parker'><organ
	ization/></author>
	<date month='May' year='2004'/>
	<abstract><t>This document discusses a number of differences between the Interme
	diate System to Intermediate System (IS-IS) protocol used to route IP traffic as
	described in RFC 1195 and the protocol as it is deployed today. These differen
	ces are discussed as a service to those implementing, testing, and deploying the
	IS-IS Protocol to route IP traffic. A companion document describes the differe
	nces between the protocol described in ISO 10589 and current practice. This mem
	o provides information for the Internet community.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='3787'/>
	<seriesInfo name='DOI' value='10.17487/RFC3787'/>
	</reference>

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

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

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

	<reference anchor='RFC3927'>
	<front>
	<title>Dynamic Configuration of IPv4 Link-Local Addresses</title>
	<author fullname='S. Cheshire' initials='S.' surname='Cheshire'><organization/><
	/author>
	<author fullname='B. Aboba' initials='B.' surname='Aboba'><organization/></autho
	r>
	<author fullname='E. Guttman' initials='E.' surname='Guttman'><organization/></a
	uthor>
	<date month='May' year='2005'/>
	<abstract><t>To participate in wide-area IP networking, a host needs to be confi
	gured with IP addresses for its interfaces, either manually by the user or autom
	atically from a source on the network such as a Dynamic Host Configuration Proto
	col (DHCP) server. Unfortunately, such address configuration information may no
	t always be available. It is therefore beneficial for a host to be able to depen
	d on a useful subset of IP networking functions even when no address configurati
	on is available. This document describes how a host may automatically configure
	an interface with an IPv4 address within the 169.254/16 prefix that is valid fo
	r communication with other devices connected to the same physical (or logical) l
	ink.</t><t>IPv4 Link-Local addresses are not suitable for communication with dev
	ices not directly connected to the same physical (or logical) link, and are only
	used where stable, routable addresses are not available (such as on ad hoc or i
	solated networks). This document does not recommend that IPv4 Link-Local addres
	ses and routable addresses be configured simultaneously on the same interface.
	[STANDARDS-TRACK]</t></abstract>
	</front>
	<seriesInfo name='RFC' value='3927'/>
	<seriesInfo name='DOI' value='10.17487/RFC3927'/>
	</reference>

	<reference anchor='I-D.ietf-homenet-naming-architecture-dhc-options'>
	<front>
	<title>DHCPv6 Options for Home Network Naming Authority</title>
	<author fullname='Daniel Migault' initials='D.' surname='Migault'>
	<organization>Ericsson</organization>
	</author>
	<author fullname='Ralf Weber' initials='R.' surname='Weber'>
	<organization>Akamai</organization>
	</author>
	<author fullname='Tomek Mrugalski' initials='T.' surname='Mrugalski'>
	<organization>Internet Systems Consortium, Inc.</organization>
	</author>
	<date day='31' month='October' year='2022'/>
	<abstract>
	<t> This document defines DHCPv6 options so a Homenet Naming Authority
	(HNA) can automatically proceed to the appropriate configuration and
	outsource the authoritative naming service for the home network. In
	most cases, the outsourcing mechanism is transparent for the end
	user.

	</t>
	</abstract>
	</front>
	<seriesInfo name='Internet-Draft' value='draft-ietf-homenet-naming-architectu
	re-dhc-options-24'/>

	</reference>

	<reference anchor='RFC8555'>
	<front>
	<title>Automatic Certificate Management Environment (ACME)</title>
	<author fullname='R. Barnes' initials='R.' surname='Barnes'><organization/></aut
	hor>
	<author fullname='J. Hoffman-Andrews' initials='J.' surname='Hoffman-Andrews'><o
	rganization/></author>
	<author fullname='D. McCarney' initials='D.' surname='McCarney'><organization/><
	/author>
	<author fullname='J. Kasten' initials='J.' surname='Kasten'><organization/></aut
	hor>
	<date month='March' year='2019'/>
	<abstract><t>Public Key Infrastructure using X.509 (PKIX) certificates are used
	for a number of purposes, the most significant of which is the authentication of
	domain names. Thus, certification authorities (CAs) in the Web PKI are trusted
	to verify that an applicant for a certificate legitimately represents the domai
	n name(s) in the certificate. As of this writing, this verification is done thr
	ough a collection of ad hoc mechanisms. This document describes a protocol that
	a CA and an applicant can use to automate the process of verification and certi
	ficate issuance. The protocol also provides facilities for other certificate ma
	nagement functions, such as certificate revocation.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='8555'/>
	<seriesInfo name='DOI' value='10.17487/RFC8555'/>
	</reference>

	<reference anchor='I-D.ietf-dnsop-domain-verification-techniques'>
	<front>
	<title>Survey of Domain Verification Techniques using DNS</title>
	<author fullname='Shivan Kaul Sahib' initials='S. K.' surname='Sahib'>
	<organization>Brave Software</organization>
	</author>
	<author fullname='Shumon Huque' initials='S.' surname='Huque'>
	<organization>Salesforce</organization>
	</author>
	<author fullname='Paul Wouters' initials='P.' surname='Wouters'>
	<organization>Aiven</organization>
	</author>
	<date day='28' month='July' year='2022'/>
	<abstract>
	<t> Many services on the Internet need to verify ownership or control
	of
	a domain in the Domain Name System (DNS) [RFC1034] [RFC1035]. This
	verification is often done by requesting a specific DNS record to be
	visible in the domain. This document surveys various techniques in
	wide use today, the pros and cons of each, and proposes some
	practices to avoid known problems.

	</t>
	</abstract>
	</front>
	<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-domain-verification
	-techniques-00'/>

	</reference>

	<reference anchor='RFC7788'>
	<front>
	<title>Home Networking Control Protocol</title>
	<author fullname='M. Stenberg' initials='M.' surname='Stenberg'><organization/><
	/author>
	<author fullname='S. Barth' initials='S.' surname='Barth'><organization/></autho
	r>
	<author fullname='P. Pfister' initials='P.' surname='Pfister'><organization/></a
	uthor>
	<date month='April' year='2016'/>
	<abstract><t>This document describes the Home Networking Control Protocol (HNCP)
	, an extensible configuration protocol, and a set of requirements for home netwo
	rk devices. HNCP is described as a profile of and extension to the Distributed
	Node Consensus Protocol (DNCP). HNCP enables discovery of network borders, auto
	mated configuration of addresses, name resolution, service discovery, and the us
	e of any routing protocol that supports routing based on both the source and des
	tination address.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7788'/>
	<seriesInfo name='DOI' value='10.17487/RFC7788'/>
	</reference>

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


	This document clarifies the scope and responsibilities of DNSSEC	While DNSSEC comes with some complexity, at least for non expert,
	Resolver Operators (DRO) as well as operational recommendations that	that complexity is mostly abstracted by the resolver. As result,
	DNSSEC validators operators SHOULD put in place in order to implement	running a resolver with DNSSEC enabled only requires the operator to
	sufficient trust that makes DNSSEC validation output accurate. The	only follow a very limited set of recommendations. This document
	recommendations described in this document include, provisioning	provides such recommendations.
	mechanisms as well as monitoring and management mechanisms.

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

	</reference>

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

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

	</reference>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


	<reference anchor='I-D.richardson-homerouter-provisioning'>	</t>
	<front>	</abstract>
	<title>Provisioning Initial Device Identifiers into Home Routers</title>	</front>
	<author fullname='Michael Richardson' initials='M.' surname='Richardson'>	<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-dnssec-valid
	<organization>Sandelman Software Works</organization>	ator-requirements-07"/>
	</author>	<refcontent>Work in Progress</refcontent>
	<date day='14' month='November' year='2021'/>	</reference>
	<abstract>	<reference anchor="GPUNSEC3" target="https://doi.org/10.1109/NCA.2014.27
	<t> This document describes a method to provisioning an 802.1AR-style	" quoteTitle="true" derivedAnchor="GPUNSEC3">
		<front>
		<title>GPU-Based NSEC3 Hash Breaking</title>
		<author initials="M." surname="Wander">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="L." surname="Schwittmann">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="C." surname="Boelmann">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="T." surname="Weis">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="August" year="2014"/>
		</front>
		<seriesInfo name="DOI" value="10.1109/NCA.2014.27"/>
		</reference>
		<reference anchor="I-D.richardson-homerouter-provisioning" target="https
		://datatracker.ietf.org/doc/html/draft-richardson-homerouter-provisioning-02" qu
		oteTitle="true" derivedAnchor="HOMEROUTER-PROVISION">
		<front>
		<title>Provisioning Initial Device Identifiers into Home Routers</ti
		tle>
		<author initials="M." surname="Richardson" fullname="Michael Richard
		son">
		<organization showOnFrontPage="true">Sandelman Software Works</org
		anization>
		</author>
		<date month="November" day="14" year="2021"/>
		<abstract>
		<t indent="0"> This document describes a method to provisioning
		an 802.1AR-style
	certificate into a router intended for use in the home.	certificate into a router intended for use in the home.

	The proceedure results in a certificate which can be validated with a	The proceedure results in a certificate which can be validated with a

	public trust anchor ("WebPKI"), using a name rather than an IP	public trust anchor ("WebPKI"), using a name rather than an IP
	address. This method is focused on home routers, but can in some	address. This method is focused on home routers, but can in some
	cases be used by other classes of IoT devices.	cases be used by other classes of IoT devices.

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


	</t>	</t>
	</abstract>	</abstract>
	</front>	</front>
	<seriesInfo name='Internet-Draft' value='draft-richardson-homerouter-provisio	<seriesInfo name="Internet-Draft" value="draft-richardson-homerouter-p
	ning-02'/>	rovisioning-02"/>
		<refcontent>Work in Progress</refcontent>
	</reference>	</reference>
		<reference anchor="I-D.ietf-dnsop-ns-revalidation" target="https://datat
		racker.ietf.org/doc/html/draft-ietf-dnsop-ns-revalidation-04" quoteTitle="true"
		derivedAnchor="NS-REVALIDATION">
		<front>
		<title>Delegation Revalidation by DNS Resolvers</title>
		<author fullname="Shumon Huque" initials="S." surname="Huque">
		<organization showOnFrontPage="true">Salesforce</organization>
		</author>
		<author fullname="Paul A. Vixie" initials="P." surname="Vixie">
		<organization showOnFrontPage="true">SIE Europe, U.G.</organizatio
		n>
		</author>
		<author fullname="Ralph Dolmans" initials="R." surname="Dolmans">
		<organization showOnFrontPage="true">NLnet Labs</organization>
		</author>
		<date day="13" month="March" year="2023"/>
		</front>
		<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-ns-revalidat
		ion-04"/>
		<refcontent>Work in Progress</refcontent>
		</reference>
		<reference anchor="REBIND" target="https://en.wikipedia.org/w/index.php?
		title=DNS_rebinding&oldid=1173433859" quoteTitle="true" derivedAnchor="REBIN
		D">
		<front>
		<title>DNS rebinding</title>
		<author>
		<organization showOnFrontPage="true">Wikipedia</organization>
		</author>
		<date month="September" year="2023"/>
		</front>
		</reference>
		<reference anchor="RFC2136" target="https://www.rfc-editor.org/info/rfc2
		136" quoteTitle="true" derivedAnchor="RFC2136">
		<front>
		<title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title
		>
		<author fullname="P. Vixie" initials="P." role="editor" surname="Vix
		ie"/>
		<author fullname="S. Thomson" initials="S." surname="Thomson"/>
		<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
		<author fullname="J. Bound" initials="J." surname="Bound"/>
		<date month="April" year="1997"/>
		<abstract>
		<t indent="0">Using this specification of the UPDATE opcode, it is
		possible to add or delete RRs or RRsets from a specified zone. Prerequisites ar
		e specified separately from update operations, and can specify a dependency upon
		either the previous existence or nonexistence of an RRset, or the existence of
		a single RR. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="2136"/>
		<seriesInfo name="DOI" value="10.17487/RFC2136"/>
		</reference>
		<reference anchor="RFC3587" target="https://www.rfc-editor.org/info/rfc3
		587" quoteTitle="true" derivedAnchor="RFC3587">
		<front>
		<title>IPv6 Global Unicast Address Format</title>
		<author fullname="R. Hinden" initials="R." surname="Hinden"/>
		<author fullname="S. Deering" initials="S." surname="Deering"/>
		<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
		<date month="August" year="2003"/>
		<abstract>
		<t indent="0">This document obsoletes RFC 2374, "An IPv6 Aggregata
		ble Global Unicast Address Format". It defined an IPv6 address allocation struct
		ure that includes Top Level Aggregator (TLA) and Next Level Aggregator (NLA). Th
		is document makes RFC 2374 and the TLA/NLA structure historic. This memo provide
		s information for the Internet community.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="3587"/>
		<seriesInfo name="DOI" value="10.17487/RFC3587"/>
		</reference>
		<reference anchor="RFC3927" target="https://www.rfc-editor.org/info/rfc3
		927" quoteTitle="true" derivedAnchor="RFC3927">
		<front>
		<title>Dynamic Configuration of IPv4 Link-Local Addresses</title>
		<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
		<author fullname="B. Aboba" initials="B." surname="Aboba"/>
		<author fullname="E. Guttman" initials="E." surname="Guttman"/>
		<date month="May" year="2005"/>
		<abstract>
		<t indent="0">To participate in wide-area IP networking, a host ne
		eds to be configured with IP addresses for its interfaces, either manually by th
		e user or automatically from a source on the network such as a Dynamic Host Conf
		iguration Protocol (DHCP) server. Unfortunately, such address configuration info
		rmation may not always be available. It is therefore beneficial for a host to be
		able to depend on a useful subset of IP networking functions even when no addre
		ss configuration is available. This document describes how a host may automatica
		lly configure an interface with an IPv4 address within the 169.254/16 prefix tha
		t is valid for communication with other devices connected to the same physical (
		or logical) link.</t>
		<t indent="0">IPv4 Link-Local addresses are not suitable for commu
		nication with devices not directly connected to the same physical (or logical) l
		ink, and are only used where stable, routable addresses are not available (such
		as on ad hoc or isolated networks). This document does not recommend that IPv4 L
		ink-Local addresses and routable addresses be configured simultaneously on the s
		ame interface. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="3927"/>
		<seriesInfo name="DOI" value="10.17487/RFC3927"/>
		</reference>
		<reference anchor="RFC4192" target="https://www.rfc-editor.org/info/rfc4
		192" quoteTitle="true" derivedAnchor="RFC4192">
		<front>
		<title>Procedures for Renumbering an IPv6 Network without a Flag Day
		</title>
		<author fullname="F. Baker" initials="F." surname="Baker"/>
		<author fullname="E. Lear" initials="E." surname="Lear"/>
		<author fullname="R. Droms" initials="R." surname="Droms"/>
		<date month="September" year="2005"/>
		<abstract>
		<t indent="0">This document describes a procedure that can be used
		to renumber a network from one prefix to another. It uses IPv6's intrinsic abil
		ity to assign multiple addresses to a network interface to provide continuity of
		network service through a "make-before-break" transition, as well as addresses
		naming and configuration management issues. It also uses other IPv6 features to
		minimize the effort and time required to complete the transition from the old pr
		efix to the new prefix. This memo provides information for the Internet communit
		y.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="4192"/>
		<seriesInfo name="DOI" value="10.17487/RFC4192"/>
		</reference>
		<reference anchor="RFC4193" target="https://www.rfc-editor.org/info/rfc4
		193" quoteTitle="true" derivedAnchor="RFC4193">
		<front>
		<title>Unique Local IPv6 Unicast Addresses</title>
		<author fullname="R. Hinden" initials="R." surname="Hinden"/>
		<author fullname="B. Haberman" initials="B." surname="Haberman"/>
		<date month="October" year="2005"/>
		<abstract>
		<t indent="0">This document defines an IPv6 unicast address format
		that is globally unique and is intended for local communications, usually insid
		e of a site. These addresses are not expected to be routable on the global Inter
		net. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="4193"/>
		<seriesInfo name="DOI" value="10.17487/RFC4193"/>
		</reference>
		<reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4
		291" quoteTitle="true" derivedAnchor="RFC4291">
		<front>
		<title>IP Version 6 Addressing Architecture</title>
		<author fullname="R. Hinden" initials="R." surname="Hinden"/>
		<author fullname="S. Deering" initials="S." surname="Deering"/>
		<date month="February" year="2006"/>
		<abstract>
		<t indent="0">This specification defines the addressing architectu
		re of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressin
		g model, text representations of IPv6 addresses, definition of IPv6 unicast addr
		esses, anycast addresses, and multicast addresses, and an IPv6 node's required a
		ddresses.</t>
		<t indent="0">This document obsoletes RFC 3513, "IP Version 6 Addr
		essing Architecture". [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="4291"/>
		<seriesInfo name="DOI" value="10.17487/RFC4291"/>
		</reference>
		<reference anchor="RFC5011" target="https://www.rfc-editor.org/info/rfc5
		011" quoteTitle="true" derivedAnchor="RFC5011">
		<front>
		<title>Automated Updates of DNS Security (DNSSEC) Trust Anchors</tit
		le>
		<author fullname="M. StJohns" initials="M." surname="StJohns"/>
		<date month="September" year="2007"/>
		<abstract>
		<t indent="0">This document describes a means for automated, authe
		nticated, and authorized updating of DNSSEC "trust anchors". The method provides
		protection against N-1 key compromises of N keys in the trust point key set. Ba
		sed on the trust established by the presence of a current anchor, other anchors
		may be added at the same place in the hierarchy, and, ultimately, supplant the e
		xisting anchor(s).</t>
		<t indent="0">This mechanism will require changes to resolver mana
		gement behavior (but not resolver resolution behavior), and the addition of a si
		ngle flag bit to the DNSKEY record. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="STD" value="74"/>
		<seriesInfo name="RFC" value="5011"/>
		<seriesInfo name="DOI" value="10.17487/RFC5011"/>
		</reference>
		<reference anchor="RFC6092" target="https://www.rfc-editor.org/info/rfc6
		092" quoteTitle="true" derivedAnchor="RFC6092">
		<front>
		<title>Recommended Simple Security Capabilities in Customer Premises
		Equipment (CPE) for Providing Residential IPv6 Internet Service</title>
		<author fullname="J. Woodyatt" initials="J." role="editor" surname="
		Woodyatt"/>
		<date month="January" year="2011"/>
		<abstract>
		<t indent="0">This document identifies a set of recommendations fo
		r the makers of devices and describes how to provide for "simple security" capab
		ilities at the perimeter of local-area IPv6 networks in Internet-enabled homes a
		nd small offices. This document is not an Internet Standards Track specification
		; it is published for informational purposes.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6092"/>
		<seriesInfo name="DOI" value="10.17487/RFC6092"/>
		</reference>
		<reference anchor="RFC6749" target="https://www.rfc-editor.org/info/rfc6
		749" quoteTitle="true" derivedAnchor="RFC6749">
		<front>
		<title>The OAuth 2.0 Authorization Framework</title>
		<author fullname="D. Hardt" initials="D." role="editor" surname="Har
		dt"/>
		<date month="October" year="2012"/>
		<abstract>
		<t indent="0">The OAuth 2.0 authorization framework enables a thir
		d-party application to obtain limited access to an HTTP service, either on behal
		f of a resource owner by orchestrating an approval interaction between the resou
		rce owner and the HTTP service, or by allowing the third-party application to ob
		tain access on its own behalf. This specification replaces and obsoletes the OAu
		th 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6749"/>
		<seriesInfo name="DOI" value="10.17487/RFC6749"/>
		</reference>
		<reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6
		762" quoteTitle="true" derivedAnchor="RFC6762">
		<front>
		<title>Multicast DNS</title>
		<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
		<author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
		<date month="February" year="2013"/>
		<abstract>
		<t indent="0">As networked devices become smaller, more portable,
		and more ubiquitous, the ability to operate with less configured infrastructure
		is increasingly important. In particular, the ability to look up DNS resource re
		cord data types (including, but not limited to, host names) in the absence of a
		conventional managed DNS server is useful.</t>
		<t indent="0">Multicast DNS (mDNS) provides the ability to perform
		DNS-like operations on the local link in the absence of any conventional Unicas
		t DNS server. In addition, Multicast DNS designates a portion of the DNS namespa
		ce to be free for local use, without the need to pay any annual fee, and without
		the need to set up delegations or otherwise configure a conventional DNS server
		to answer for those names.</t>
		<t indent="0">The primary benefits of Multicast DNS names are that
		(i) they require little or no administration or configuration to set them up, (
		ii) they work when no infrastructure is present, and (iii) they work during infr
		astructure failures.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6762"/>
		<seriesInfo name="DOI" value="10.17487/RFC6762"/>
		</reference>
		<reference anchor="RFC6887" target="https://www.rfc-editor.org/info/rfc6
		887" quoteTitle="true" derivedAnchor="RFC6887">
		<front>
		<title>Port Control Protocol (PCP)</title>
		<author fullname="D. Wing" initials="D." role="editor" surname="Wing
		"/>
		<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
		<author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
		<author fullname="R. Penno" initials="R." surname="Penno"/>
		<author fullname="P. Selkirk" initials="P." surname="Selkirk"/>
		<date month="April" year="2013"/>
		<abstract>
		<t indent="0">The Port Control Protocol allows an IPv6 or IPv4 hos
		t to control how incoming IPv6 or IPv4 packets are translated and forwarded by a
		Network Address Translator (NAT) or simple firewall, and also allows a host to
		optimize its outgoing NAT keepalive messages.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="6887"/>
		<seriesInfo name="DOI" value="10.17487/RFC6887"/>
		</reference>
		<reference anchor="RFC7010" target="https://www.rfc-editor.org/info/rfc7
		010" quoteTitle="true" derivedAnchor="RFC7010">
		<front>
		<title>IPv6 Site Renumbering Gap Analysis</title>
		<author fullname="B. Liu" initials="B." surname="Liu"/>
		<author fullname="S. Jiang" initials="S." surname="Jiang"/>
		<author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
		<author fullname="S. Venaas" initials="S." surname="Venaas"/>
		<author fullname="W. George" initials="W." surname="George"/>
		<date month="September" year="2013"/>
		<abstract>
		<t indent="0">This document briefly introduces the existing mechan
		isms that could be utilized for IPv6 site renumbering and tries to cover most of
		the explicit issues and requirements associated with IPv6 renumbering. The cont
		ent is mainly a gap analysis that provides a basis for future works to identify
		and develop solutions or to stimulate such development as appropriate. The gap a
		nalysis is organized by the main steps of a renumbering process.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7010"/>
		<seriesInfo name="DOI" value="10.17487/RFC7010"/>
		</reference>
		<reference anchor="RFC7084" target="https://www.rfc-editor.org/info/rfc7
		084" quoteTitle="true" derivedAnchor="RFC7084">
		<front>
		<title>Basic Requirements for IPv6 Customer Edge Routers</title>
		<author fullname="H. Singh" initials="H." surname="Singh"/>
		<author fullname="W. Beebee" initials="W." surname="Beebee"/>
		<author fullname="C. Donley" initials="C." surname="Donley"/>
		<author fullname="B. Stark" initials="B." surname="Stark"/>
		<date month="November" year="2013"/>
		<abstract>
		<t indent="0">This document specifies requirements for an IPv6 Cus
		tomer Edge (CE) router. Specifically, the current version of this document focus
		es on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 h
		osts attached to it. The document also covers IP transition technologies. Two tr
		ansition technologies in RFC 5969's IPv6 Rapid Deployment on IPv4 Infrastructure
		s (6rd) and RFC 6333's Dual-Stack Lite (DS-Lite) are covered in the document. Th
		e document obsoletes RFC 6204.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7084"/>
		<seriesInfo name="DOI" value="10.17487/RFC7084"/>
		</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>
		<reference anchor="RFC7404" target="https://www.rfc-editor.org/info/rfc7
		404" quoteTitle="true" derivedAnchor="RFC7404">
		<front>
		<title>Using Only Link-Local Addressing inside an IPv6 Network</titl
		e>
		<author fullname="M. Behringer" initials="M." surname="Behringer"/>
		<author fullname="E. Vyncke" initials="E." surname="Vyncke"/>
		<date month="November" year="2014"/>
		<abstract>
		<t indent="0">In an IPv6 network, it is possible to use only link-
		local addresses on infrastructure links between routers. This document discusses
		the advantages and disadvantages of this approach to facilitate the decision pr
		ocess for a given network.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7404"/>
		<seriesInfo name="DOI" value="10.17487/RFC7404"/>
		</reference>
		<reference anchor="RFC7707" target="https://www.rfc-editor.org/info/rfc7
		707" quoteTitle="true" derivedAnchor="RFC7707">
		<front>
		<title>Network Reconnaissance in IPv6 Networks</title>
		<author fullname="F. Gont" initials="F." surname="Gont"/>
		<author fullname="T. Chown" initials="T." surname="Chown"/>
		<date month="March" year="2016"/>
		<abstract>
		<t indent="0">IPv6 offers a much larger address space than that of
		its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate ap
		proximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#h
		osts/#addresses) than is typical in IPv4 networks, where a site typically has 65
		,000 or fewer unique addresses. As a result, it is widely assumed that it would
		take a tremendous effort to perform address-scanning attacks against IPv6 networ
		ks; therefore, IPv6 address-scanning attacks have been considered unfeasible. Th
		is document formally obsoletes RFC 5157, which first discussed this assumption,
		by providing further analysis on how traditional address-scanning techniques app
		ly to IPv6 networks and exploring some additional techniques that can be employe
		d for IPv6 network reconnaissance.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7707"/>
		<seriesInfo name="DOI" value="10.17487/RFC7707"/>
		</reference>
		<reference anchor="RFC7788" target="https://www.rfc-editor.org/info/rfc7
		788" quoteTitle="true" derivedAnchor="RFC7788">
		<front>
		<title>Home Networking Control Protocol</title>
		<author fullname="M. Stenberg" initials="M." surname="Stenberg"/>
		<author fullname="S. Barth" initials="S." surname="Barth"/>
		<author fullname="P. Pfister" initials="P." surname="Pfister"/>
		<date month="April" year="2016"/>
		<abstract>
		<t indent="0">This document describes the Home Networking Control
		Protocol (HNCP), an extensible configuration protocol, and a set of requirements
		for home network devices. HNCP is described as a profile of and extension to th
		e Distributed Node Consensus Protocol (DNCP). HNCP enables discovery of network
		borders, automated configuration of addresses, name resolution, service discover
		y, and the use of any routing protocol that supports routing based on both the s
		ource and destination address.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="7788"/>
		<seriesInfo name="DOI" value="10.17487/RFC7788"/>
		</reference>
		<reference anchor="RFC8094" target="https://www.rfc-editor.org/info/rfc8
		094" quoteTitle="true" derivedAnchor="RFC8094">
		<front>
		<title>DNS over Datagram Transport Layer Security (DTLS)</title>
		<author fullname="T. Reddy" initials="T." surname="Reddy"/>
		<author fullname="D. Wing" initials="D." surname="Wing"/>
		<author fullname="P. Patil" initials="P." surname="Patil"/>
		<date month="February" year="2017"/>
		<abstract>
		<t indent="0">DNS queries and responses are visible to network ele
		ments on the path between the DNS client and its server. These queries and respo
		nses can contain privacy-sensitive information, which is valuable to protect.</t
		>
		<t indent="0">This document proposes the use of Datagram Transport
		Layer Security (DTLS) for DNS, to protect against passive listeners and certain
		active attacks. As latency is critical for DNS, this proposal also discusses me
		chanisms to reduce DTLS round trips and reduce the DTLS handshake size. The prop
		osed mechanism runs over port 853.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8094"/>
		<seriesInfo name="DOI" value="10.17487/RFC8094"/>
		</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="RFC8484" target="https://www.rfc-editor.org/info/rfc8
		484" quoteTitle="true" derivedAnchor="RFC8484">
		<front>
		<title>DNS Queries over HTTPS (DoH)</title>
		<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
		<author fullname="P. McManus" initials="P." surname="McManus"/>
		<date month="October" year="2018"/>
		<abstract>
		<t indent="0">This document defines a protocol for sending DNS que
		ries and getting DNS responses over HTTPS. Each DNS query-response pair is mappe
		d into an HTTP exchange.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8484"/>
		<seriesInfo name="DOI" value="10.17487/RFC8484"/>
		</reference>
		<reference anchor="RFC8501" target="https://www.rfc-editor.org/info/rfc8
		501" quoteTitle="true" derivedAnchor="RFC8501">
		<front>
		<title>Reverse DNS in IPv6 for Internet Service Providers</title>
		<author fullname="L. Howard" initials="L." surname="Howard"/>
		<date month="November" year="2018"/>
		<abstract>
		<t indent="0">In IPv4, Internet Service Providers (ISPs) commonly
		provide IN-ADDR.ARPA information for their customers by prepopulating the zone w
		ith one PTR record for every available address. This practice does not scale in
		IPv6. This document analyzes different approaches and considerations for ISPs in
		managing the IP6.ARPA zone.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8501"/>
		<seriesInfo name="DOI" value="10.17487/RFC8501"/>
		</reference>
		<reference anchor="RFC8555" target="https://www.rfc-editor.org/info/rfc8
		555" quoteTitle="true" derivedAnchor="RFC8555">
		<front>
		<title>Automatic Certificate Management Environment (ACME)</title>
		<author fullname="R. Barnes" initials="R." surname="Barnes"/>
		<author fullname="J. Hoffman-Andrews" initials="J." surname="Hoffman
		-Andrews"/>
		<author fullname="D. McCarney" initials="D." surname="McCarney"/>
		<author fullname="J. Kasten" initials="J." surname="Kasten"/>
		<date month="March" year="2019"/>
		<abstract>
		<t indent="0">Public Key Infrastructure using X.509 (PKIX) certifi
		cates are used for a number of purposes, the most significant of which is the au
		thentication of domain names. Thus, certification authorities (CAs) in the Web P
		KI are trusted to verify that an applicant for a certificate legitimately repres
		ents the domain name(s) in the certificate. As of this writing, this verificatio
		n is done through a collection of ad hoc mechanisms. This document describes a p
		rotocol that a CA and an applicant can use to automate the process of verificati
		on and certificate issuance. The protocol also provides facilities for other cer
		tificate management functions, such as certificate revocation.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8555"/>
		<seriesInfo name="DOI" value="10.17487/RFC8555"/>
		</reference>
		<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8
		610" quoteTitle="true" derivedAnchor="RFC8610">
		<front>
		<title>Concise Data Definition Language (CDDL): A Notational Convent
		ion to Express Concise Binary Object Representation (CBOR) and JSON Data Structu
		res</title>
		<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
		<author fullname="C. Vigano" initials="C." surname="Vigano"/>
		<author fullname="C. Bormann" initials="C." surname="Bormann"/>
		<date month="June" year="2019"/>
		<abstract>
		<t indent="0">This document proposes a notational convention to ex
		press Concise Binary Object Representation (CBOR) data structures (RFC 7049). It
		s main goal is to provide an easy and unambiguous way to express structures for
		protocol messages and data formats that use CBOR or JSON.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8610"/>
		<seriesInfo name="DOI" value="10.17487/RFC8610"/>
		</reference>
		<reference anchor="RFC8672" target="https://www.rfc-editor.org/info/rfc8
		672" quoteTitle="true" derivedAnchor="RFC8672">
		<front>
		<title>TLS Server Identity Pinning with Tickets</title>
		<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
		<author fullname="D. Migault" initials="D." surname="Migault"/>
		<date month="October" year="2019"/>
		<abstract>
		<t indent="0">Misissued public-key certificates can prevent TLS cl
		ients from appropriately authenticating the TLS server. Several alternatives hav
		e been proposed to detect this situation and prevent a client from establishing
		a TLS session with a TLS end point authenticated with an illegitimate public-key
		certificate. These mechanisms are either not widely deployed or limited to publ
		ic web browsing.</t>
		<t indent="0">This document proposes experimental extensions to TL
		S with opaque pinning tickets as a way to pin the server's identity. During an i
		nitial TLS session, the server provides an original encrypted pinning ticket. In
		subsequent TLS session establishment, upon receipt of the pinning ticket, the s
		erver proves its ability to decrypt the pinning ticket and thus the ownership of
		the pinning protection key. The client can now safely conclude that the TLS ses
		sion is established with the same TLS server as the original TLS session. One of
		the important properties of this proposal is that no manual management actions
		are required.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8672"/>
		<seriesInfo name="DOI" value="10.17487/RFC8672"/>
		</reference>
		<reference anchor="RFC8978" target="https://www.rfc-editor.org/info/rfc8
		978" quoteTitle="true" derivedAnchor="RFC8978">
		<front>
		<title>Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC)
		to Flash-Renumbering Events</title>
		<author fullname="F. Gont" initials="F." surname="Gont"/>
		<author fullname="J. Žorž" initials="J." surname="Žorž"/>
		<author fullname="R. Patterson" initials="R." surname="Patterson"/>
		<date month="March" year="2021"/>
		<abstract>
		<t indent="0">In scenarios where network configuration information
		related to IPv6 prefixes becomes invalid without any explicit and reliable sign
		aling of that condition (such as when a Customer Edge router crashes and reboots
		without knowledge of the previously employed prefixes), hosts on the local netw
		ork may continue using stale prefixes for an unacceptably long time (on the orde
		r of several days), thus resulting in connectivity problems. This document descr
		ibes this issue and discusses operational workarounds that may help to improve n
		etwork robustness. Additionally, it highlights areas where further work may be n
		eeded.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8978"/>
		<seriesInfo name="DOI" value="10.17487/RFC8978"/>
		</reference>
		<reference anchor="RFC8981" target="https://www.rfc-editor.org/info/rfc8
		981" quoteTitle="true" derivedAnchor="RFC8981">
		<front>
		<title>Temporary Address Extensions for Stateless Address Autoconfig
		uration in IPv6</title>
		<author fullname="F. Gont" initials="F." surname="Gont"/>
		<author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
		<author fullname="T. Narten" initials="T." surname="Narten"/>
		<author fullname="R. Draves" initials="R." surname="Draves"/>
		<date month="February" year="2021"/>
		<abstract>
		<t indent="0">This document describes an extension to IPv6 Statele
		ss Address Autoconfiguration that causes hosts to generate temporary addresses w
		ith randomized interface identifiers for each prefix advertised with autoconfigu
		ration enabled. Changing addresses over time limits the window of time during wh
		ich eavesdroppers and other information collectors may trivially perform address
		-based network-activity correlation when the same address is employed for multip
		le transactions by the same host. Additionally, it reduces the window of exposur
		e of a host as being accessible via an address that becomes revealed as a result
		of active communication. This document obsoletes RFC 4941.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="8981"/>
		<seriesInfo name="DOI" value="10.17487/RFC8981"/>
		</reference>
		<reference anchor="RFC9250" target="https://www.rfc-editor.org/info/rfc9
		250" quoteTitle="true" derivedAnchor="RFC9250">
		<front>
		<title>DNS over Dedicated QUIC Connections</title>
		<author fullname="C. Huitema" initials="C." surname="Huitema"/>
		<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
		<author fullname="A. Mankin" initials="A." surname="Mankin"/>
		<date month="May" year="2022"/>
		<abstract>
		<t indent="0">This document describes the use of QUIC to provide t
		ransport confidentiality for DNS. The encryption provided by QUIC has similar pr
		operties to those provided by TLS, while QUIC transport eliminates the head-of-l
		ine blocking issues inherent with TCP and provides more efficient packet-loss re
		covery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over
		TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic
		DNS over UDP. This specification describes the use of DoQ as a general-purpose t
		ransport for DNS and includes the use of DoQ for stub to recursive, recursive to
		authoritative, and zone transfer scenarios.</t>
		</abstract>
		</front>
		<seriesInfo name="RFC" value="9250"/>
		<seriesInfo name="DOI" value="10.17487/RFC9250"/>
		</reference>
		<reference anchor="RFC9276" target="https://www.rfc-editor.org/info/rfc9
		276" quoteTitle="true" derivedAnchor="RFC9276">
		<front>
		<title>Guidance for NSEC3 Parameter Settings</title>
		<author fullname="W. Hardaker" initials="W." surname="Hardaker"/>
		<author fullname="V. Dukhovni" initials="V." surname="Dukhovni"/>
		<date month="August" year="2022"/>
		<abstract>
		<t indent="0">NSEC3 is a DNSSEC mechanism providing proof of nonex
		istence by asserting that there are no names that exist between two domain names
		within a zone. Unlike its counterpart NSEC, NSEC3 avoids directly disclosing th
		e bounding domain name pairs. This document provides guidance on setting NSEC3 p
		arameters based on recent operational deployment experience. This document updat
		es RFC 5155 with guidance about selecting NSEC3 iteration and salt parameters.</
		t>
		</abstract>
		</front>
		<seriesInfo name="BCP" value="236"/>
		<seriesInfo name="RFC" value="9276"/>
		<seriesInfo name="DOI" value="10.17487/RFC9276"/>
		</reference>
		<reference anchor="RFC9527" target="https://www.rfc-editor.org/info/rfc9
		527" quoteTitle="true" derivedAnchor="RFC9527">
		<front>
		<title>DHCPv6 Options for the Homenet Naming Authority</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="T" surname="Mrugalski" fullname="Tomek Mrugalski">
		<organization showOnFrontPage="true"/>
		</author>
		<date year="2024" month="January"/>
		</front>
		<seriesInfo name="RFC" value="9527"/>
		<seriesInfo name="DOI" value="10.17487/RFC9527"/>
		</reference>
		<reference anchor="ZONEENUM" quoteTitle="true" target="https://doi.org/1
		0.2495/MIIT130591" derivedAnchor="ZONEENUM">
		<front>
		<title>An efficient DNSSEC zone enumeration algorithm</title>
		<author initials="Z." surname="Wang">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="L." surname="Xiao">
		<organization showOnFrontPage="true"/>
		</author>
		<author initials="R." surname="Wang">
		<organization showOnFrontPage="true"/>
		</author>
		<date month="April" year="2014"/>
		</front>
		<seriesInfo name="DOI" value="10.2495/MIIT130591"/>
		</reference>
		</references>
	</references>	</references>

		<section anchor="hna-channel-configurations" numbered="true" removeInRFC="fa
	<section anchor="hna-channel-configurations"><name>HNA Channel Configurations</n	lse" toc="include" pn="section-appendix.a">
	ame>	<name slugifiedName="name-hna-channel-configurations">HNA Channel Configur
		ations</name>
	<section anchor="hna-provisioning"><name>Homenet Public Zone</name>	<section anchor="hna-provisioning" numbered="true" removeInRFC="false" toc
		="include" pn="section-appendix.a.1">
	<t>This document does not deal with how the HNA is provisioned with a trusted re	<name slugifiedName="name-public-homenet-zone">Public Homenet Zone</name
	lationship to the Distribution Manager for the forward zone.</t>	>
		<t indent="0" pn="section-appendix.a.1-1">This document does not deal wi
	<t>This section details what needs to be provisioned into the HNA and serves as	th how the HNA is provisioned with a trusted relationship to the Distribution Ma
	a requirements statement for mechanisms.</t>	nager for the forward zone.</t>
		<t indent="0" pn="section-appendix.a.1-2">This section details what need
	<t>The HNA needs to be provisioned with:</t>	s to be provisioned into the HNA and serves as a requirements statement for mech
		anisms.</t>
	<t><list style="symbols">	<t indent="0" pn="section-appendix.a.1-3">The HNA needs to be provisione
	<t>the Registered Domain (e.g., myhome.example )</t>	d with:</t>
	<t>the contact info for the Distribution Manager (DM), including the DNS name	<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-a
	(FQDN), possibly including the IP literal, and a certificate (or anchor) to be u	ppendix.a.1-4">
	sed to authenticate the service</t>	<li pn="section-appendix.a.1-4.1">the Registered Domain (e.g., myhome.
	<t>the DM transport protocol and port (the default is DNS over TLS, on port 85	example);</li>
	3)</t>	<li pn="section-appendix.a.1-4.2">the contact information for the DM,
	<t>the HNA credentials used by the DM for its authentication.</t>	including the DNS name (the fully qualified domain name (FQDN)), possibly the IP
	</list></t>	literal, and a certificate (or anchor) to be used to authenticate the service;<
		/li>
	<t>The HNA will need to select an IP address for communication for the Synchroni	<li pn="section-appendix.a.1-4.3">the DM transport protocol and port (
	zation Channel.	the default is DNS over TLS, on port 853); and</li>
	This is typically the WAN address of the CPE, but could be an IPv6 LAN address i	<li pn="section-appendix.a.1-4.4">the HNA credentials used by the DM f
	n the case of a home with multiple ISPs (and multiple border routers).	or its authentication.</li>
	This is detailed in <xref target="sec-ip-hna"/> when the NS and A or AAAA RRsets	</ul>
	are communicated.</t>	<t indent="0" pn="section-appendix.a.1-5">The HNA will need to select an
		IP address for communication for the Synchronization Channel.
	<t>The above parameters MUST be be provisioned for ISP-specific reverse zones.	This is typically the WAN address of the CPE, but it could be an IPv6 LAN addres
	One example of how to do this can be found in <xref target="I-D.ietf-homenet-na	s in the case of a home with multiple ISPs (and multiple border routers).
	ming-architecture-dhc-options"/>.	This is detailed in <xref target="sec-ip-hna" format="default" sectionFormat="of
	ISP-specific forward zones MAY also be provisioned using <xref target="I-D.ietf-	" derivedContent="Section 6.5.3"/> when the NS and A or AAAA RRsets are communic
	homenet-naming-architecture-dhc-options"/>, but zones which are not related to a	ated.</t>
	specific ISP zone (such as with a DNS provider) must be provisioned through oth	<t indent="0" pn="section-appendix.a.1-6">The above parameters <bcp14>MU
	er means.</t>	ST</bcp14> be provisioned for ISP-specific reverse zones.
		One example of how to do this can be found in <xref target="RFC9527" format="de
	<t>Similarly, if the HNA is provided by a registrar, the HNA may be handed pre-c	fault" sectionFormat="of" derivedContent="RFC9527"/>.
	onfigured to end user.</t>	ISP-specific forward zones <bcp14>MAY</bcp14> also be provisioned using <xref ta
		rget="RFC9527" format="default" sectionFormat="of" derivedContent="RFC9527"/>, b
	<t>In the absence of specific pre-established relation, these pieces of informat	ut zones that are not related to a specific ISP zone (such as with a DNS provide
	ion may be entered manually by the end user.	r) must be provisioned through other means.</t>
	In order to ease the configuration from the end user the following scheme may be	<t indent="0" pn="section-appendix.a.1-7">Similarly, if the HNA is provi
	implemented.</t>	ded by a registrar, the HNA may be handed preconfigured to the end user.</t>
		<t indent="0" pn="section-appendix.a.1-8">In the absence of specific pre
	<t>The HNA may present the end user a web interface where it provides the end us	-established relations, these pieces of information may be entered manually by t
	er the ability to indicate the Registered Homenet Domain or the registrar for ex	he end user. In order to ease the configuration from the end user, the following
	ample a preselected list.	scheme may be implemented.</t>
	Once the registrar has been selected, the HNA redirects the end user to that reg	<t indent="0" pn="section-appendix.a.1-9">The HNA may present the end us
	istrar in order to receive a access token.	er with a web interface that provides the end user the ability to indicate the R
	The access token will enable the HNA to retrieve the DM parameters associated wi	egistered Homenet Domain or the registrar with, for example, a preselected list.
	th the Registered Domain.	Once the registrar has been selected, the HNA redirects the end user to that reg
		istrar in order to receive an access token. The access token will enable the HNA
		to retrieve the DM parameters associated with the Registered Domain.
	These parameters will include the credentials used by the HNA to establish the C ontrol and Synchronization Channels.</t>	These parameters will include the credentials used by the HNA to establish the C ontrol and Synchronization Channels.</t>

		<t indent="0" pn="section-appendix.a.1-10">Such architecture limits the
	<t>Such architecture limits the necessary steps to configure the HNA from the en	necessary steps to configure the HNA from the end user.</t>
	d user.</t>	</section>
		</section>
	</section>	<section anchor="info-model" numbered="true" removeInRFC="false" toc="includ
	</section>	e" pn="section-appendix.b">
	<section anchor="info-model"><name>Information Model for Outsourced information<	<name slugifiedName="name-information-model-for-outso">Information Model f
	/name>	or Outsourced Information</name>
		<t indent="0" pn="section-appendix.b-1">This section specifies an optional
	<t>This section specifies an optional format for the set of parameters required	format for the set of parameters required by the HNA to configure the naming ar
	by the HNA to configure the naming architecture of this document.</t>	chitecture of this document.</t>
		<t indent="0" pn="section-appendix.b-2">In cases where a home router has n
	<t>In cases where a home router has not been provisioned by the manufacturer (wh	ot been provisioned by the manufacturer (when forward zones are provided by the
	en forward zones are provided by the manufacturer), or by the ISP (when the ISP	manufacturer) or by the ISP (when the ISP provides this service), then a home us
	provides this service), then a home user/owner will need to configure these sett	er/owner will need to configure these settings via an administrative interface.<
	ings via an administrative interface.</t>	/t>
		<t indent="0" pn="section-appendix.b-3">By defining a standard format (in
	<t>By defining a standard format (in JSON) for this configuration information, t	JSON) for this configuration information, the user/owner may be able to copy and
	he user/owner may be able to just copy and paste a configuration blob from the s	paste a configuration blob from the service provider into the administrative in
	ervice provider into the administrative interface of the HNA.</t>	terface of the HNA.</t>
		<t indent="0" pn="section-appendix.b-4">This format may also provide the b
	<t>This format may also provide the basis for a future OAUTH2 <xref target="RFC6	asis for a future OAuth 2.0 <xref target="RFC6749" format="default" sectionForma
	749"/> flow that could do the setup automatically.</t>	t="of" derivedContent="RFC6749"/> flow that could do the set up automatically.</
		t>
	<t>The HNA needs to be configured with the following parameters as described by	<t indent="0" pn="section-appendix.b-5">The HNA needs to be configured wit
	this CDDL <xref target="RFC8610"/>. These are the parameters are necessary to e	h the following parameters as described by the Concise Data Definition Language
	stablish a secure channel between the HNA and the DM as well as to specify the	(CDDL) <xref target="RFC8610" format="default" sectionFormat="of" derivedContent
	DNS zone that is in the scope of the communication.</t>	="RFC8610"/>. These parameters are necessary to establish a secure channel betw
		een the HNA and the DM as well as to specify the DNS zone that is in the scope o
	<figure><sourcecode type="cddl"><![CDATA[	f the communication.</t>
		<sourcecode type="cddl" markers="false" pn="section-appendix.b-6">
	hna-configuration = {	hna-configuration = {
	"registered_domain" : tstr,	"registered_domain" : tstr,
	"dm" : tstr,	"dm" : tstr,
	? "dm_transport" : "DoT"	? "dm_transport" : "DoT"
	? "dm_port" : uint,	? "dm_port" : uint,
	? "dm_acl" : hna-acl / [ +hna-acl ]	? "dm_acl" : hna-acl / [ +hna-acl ]
	? "hna_auth_method": hna-auth-method	? "hna_auth_method": hna-auth-method
	? "hna_certificate": tstr	? "hna_certificate": tstr
	}	}

	hna-acl = tstr	hna-acl = tstr
	hna-auth-method /= "certificate"	hna-auth-method /= "certificate"

	]]></sourcecode></figure>	</sourcecode>
		<t indent="0" pn="section-appendix.b-7">For example:</t>
	<t>For example:</t>	<sourcecode markers="false" pn="section-appendix.b-8">

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

	<figure><artwork><![CDATA[
	{	{
	"registered_domain" : "n8d234f.r.example.net",	"registered_domain" : "n8d234f.r.example.net",
	"dm" : "2001:db8:1234:111:222::2",	"dm" : "2001:db8:1234:111:222::2",
	"dm_transport" : "DoT",	"dm_transport" : "DoT",
	"dm_port" : 4433,	"dm_port" : 4433,

	"dm_acl" : "2001:db8:1f15:62e:21c::/64"	"dm_acl" : "2001:db8:1f15:62e::/64"
	or [ "2001:db8:1f15:62e:21c::/64", ... ]	or [ "2001:db8:1f15:62e::/64", ... ]
	"hna_auth_method" : "certificate",	"hna_auth_method" : "certificate",

	"hna_certificate" : "-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy....",	"hna_certificate" : "-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy..",
	}	}

	]]></artwork></figure>	</sourcecode>
		<dl indent="3" newline="false" spacing="normal" pn="section-appendix.b-9">
	<dl>	<dt pn="section-appendix.b-9.1">Registered Homenet Domain (registered_do
	<dt>Registered Homenet Domain (registered_domain)</dt>	main):</dt>
	<dd>	<dd pn="section-appendix.b-9.2">The Domain Name of the zone. Multiple Re
	<t>The Domain Name of the zone. Multiple Registered Homenet Domains may be p	gistered Homenet Domains may be provided.
	rovided.	This will generate the creation of multiple Public Homenet Zones. This parameter
	This will generate the	is mandatory.
	creation of multiple Public Homenet Zones.	</dd>
	This parameter is mandatory.</t>	<dt pn="section-appendix.b-9.3">Distribution Manager notification addres
	</dd>	s (dm):</dt>
	<dt>Distribution Manager notification address (dm)</dt>	<dd pn="section-appendix.b-9.4">The associated FQDNs or IP addresses of
	<dd>	the DM to which DNS Notifies should be sent.
	<t>The associated FQDNs or IP addresses of the DM to which DNS notifies shou	This parameter is mandatory. IP addresses are optional, and the FQDN is sufficie
	ld be sent.	nt and preferred.
	This parameter is mandatory.	If there are concerns about the security of the name to IP translation, then DNS
	IP addresses are optional and the FQDN is sufficient and preferred.	SEC should be employed.
	If there are concerns about the security of the name to IP translation, then DNS	</dd>
	SEC should be employed.</t>	</dl>
	</dd>	<t indent="0" pn="section-appendix.b-10">As the session between the HNA an
	</dl>	d the DM is authenticated with TLS, the use of names is easier.</t>
		<t indent="0" pn="section-appendix.b-11">As certificates are more commonly
	<t>As the session between the HNA and the DM is authenticated with TLS, the use	emitted for FQDN than for IP addresses, it is preferred to use names and authen
	of names is easier.</t>	ticate the name of the DM during the TLS session establishment.</t>
		<dl indent="3" newline="false" spacing="normal" pn="section-appendix.b-12"
	<t>As certificates are more commonly emitted for FQDN than for IP addresses, it	>
	is preferred to use names and authenticate the name of the DM during the TLS ses	<dt pn="section-appendix.b-12.1">Supported Transport (dm_transport):</dt
	sion establishment.</t>	>
		<dd pn="section-appendix.b-12.2">The transport that carries the DNS exch
	<dl>	anges between the HNA and the DM.
	<dt>Supported Transport (dm_transport):</dt>	The typical value is "DoT", but it may be extended in the future with "DoH" or "
	<dd>	DoQ", for example.
	<t>The transport that carries the DNS exchanges between the HNA and the DM.	This parameter is optional, and the HNA uses DoT by default.
	Typical value is "DoT" but it may be extended in the future with "DoH", "DoQ" fo	</dd>
	r example.	<dt pn="section-appendix.b-12.3">Distribution Manager Port (dm_port):</d
	This parameter is optional and by default the HNA uses DoT.</t>	t>
	</dd>	<dd pn="section-appendix.b-12.4">Indicates the port used by the DM.
	<dt>Distribution Manager Port (dm_port):</dt>	This parameter is optional, and the default value is provided by the Supported T
	<dd>	ransport.
	<t>Indicates the port used by the DM.	In the future, an additional transport may not have a default port, in which cas
	This parameter is optional and the default value is provided by the Supported Tr	e either a default port needs to be defined or this parameter becomes mandatory.
	ansport.	</dd>
	In the future, additional transport may not have default port, in which case eit	</dl>
	her a default port needs to be defined or this parameter become mandatory.</t>	<t indent="0" pn="section-appendix.b-13">Note that HNA does not define por
	</dd>	ts for the Synchronization Channel.
	</dl>	In any case, this is not expected to be a part of the configuration but is inste
		ad negotiated through the Configuration Channel. Currently, the Configuration Ch
	<t>Note that HNA does not defines ports for the Synchronization Channel.	annel does not provide this and limits its agility to a dedicated IP address. If
	In any case, this is not expected to part of the configuration, but instead nego	such agility is needed in the future, additional exchanges will need to be defi
	tiated through the Configuration Channel.	ned.</t>
	Currently the Configuration Channel does not provide this, and limits its agilit	<dl indent="3" newline="false" spacing="normal" pn="section-appendix.b-14"
	y to a dedicated IP address.	>
	If such agility is needed in the future, additional exchanges will need to be de	<dt pn="section-appendix.b-14.1">Authentication Method ("hna_auth_method
	fined.</t>	"):</dt>
		<dd pn="section-appendix.b-14.2">How the HNA authenticates itself to the
	<dl>	DM within the TLS connection(s).
	<dt>Authentication Method ("hna_auth_method"):</dt>	The authentication method can typically be "certificate", "psk", or "none".
	<dd>	This parameter is optional, and the Authentication Method is "certificate" by de
	<t>How the HNA authenticates itself to the DM within the TLS connection(s).	fault.
	The authentication method can typically be "certificate", "psk" or "none".	</dd>
	This Parameter is optional and by default the Authentication Method is "certific	<dt pn="section-appendix.b-14.3">Authentication data ("hna_certificate",
	ate".</t>	"hna_key"):</dt>
	</dd>	<dd pn="section-appendix.b-14.4">The certificate chain used to authentic
	<dt>Authentication data ("hna_certificate", "hna_key"):</dt>	ate the HNA.
	<dd>	This parameter is optional, and when not specified, a self-signed certificate is
	<t>The certificate chain used to authenticate the HNA.	used.
	This parameter is optional and when not specified, a self-signed certificate is	</dd>
	used.</t>	<dt pn="section-appendix.b-14.5">Distribution Manager AXFR permission ne
	</dd>	tmask (dm_acl):</dt>
	<dt>Distribution Manager AXFR permission netmask (dm_acl):</dt>	<dd pn="section-appendix.b-14.6">The subnet from which the CPE should ac
	<dd>	cept SOA queries and AXFR requests.
	<t>The subnet from which the CPE should accept SOA queries and AXFR requests	A subnet is used in the case where the DOI consists of a number of different sys
	.	tems. An
	A subnet is used in the case where the DOI consists of a number of different sys	array of addresses is permitted. This parameter is optional, and if unspecified,
	tems.	the CPE uses the IP addresses provided by the dm parameter either directly when
	An array of addresses is permitted.	the dm indicates the IP address(es) returned by the DNS or DNSSEC resolution wh
	This parameter is optional and if unspecified, the CPE uses the IP addresses pro	en dm indicates an FQDN.
	vided by the dm parameter either directly when dm indicates an IP address or the	</dd>
	IP addresses returned by the DNS(SEC) resolution when dm indicates a FQDN.</t>	</dl>
	</dd>	<t indent="0" pn="section-appendix.b-15">For forward zones, the relationsh
	</dl>	ip between the HNA and the forward zone provider may be the result of a number o
		f transactions:</t>
	<t>For forward zones, the relationship between the HNA and the forward zone prov	<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-appe
	ider may be the result of a number of transactions:</t>	ndix.b-16">
		<li pn="section-appendix.b-16.1" derivedCounter="1.">The forward zone out
	<t><list style="numbers">	sourcing may be provided by the maker of the Homenet router.
	<t>The forward zone outsourcing may be provided by the maker of the Homenet ro	In this case, the identity and authorization could be built in the device at the
	uter.	manufacturer provisioning time. The device would need to be provisioned with a
	In this case, the identity and authorization could be built in the device at man	device-unique credential, and it is likely that the Registered Homenet Domain wo
	ufacturer provisioning time. The device would need to be provisioned with a dev	uld be derived from a public attribute of the device, such as a serial number (s
	ice-unique credential, and it is likely that the Registered Homenet Domain would	ee <xref target="sec-ex-manu" format="default" sectionFormat="of" derivedContent
	be derived from a public attribute of the device, such as a serial number (see	="Appendix C"/> or <xref target="I-D.richardson-homerouter-provisioning" format=
	<xref target="sec-ex-manu"/> or <xref target="I-D.richardson-homerouter-provisio	"default" sectionFormat="of" derivedContent="HOMEROUTER-PROVISION"/> for more de
	ning"/> for more details ).</t>	tails).</li>
	<t>The forward zone outsourcing may be provided by the Internet Service Provid	<li pn="section-appendix.b-16.2" derivedCounter="2.">The forward zone ou
	er.	tsourcing may be provided by the ISP.
	In this case, the use of <xref target="I-D.ietf-homenet-naming-architecture-dhc-	In this case, the use of <xref target="RFC9527" format="default" sectionFormat="
	options"/> to provide the credentials is appropriate.</t>	of" derivedContent="RFC9527"/> to provide the credentials is appropriate.</li>
	<t>The forward zone may be outsourced to a third party, such as a domain regis	<li pn="section-appendix.b-16.3" derivedCounter="3.">The forward zone ma
	trar.	y be outsourced to a third party, such as a domain registrar.
	In this case, the use of the JSON-serialized YANG data model described in this s	In this case, the use of the JSON-serialized YANG data model described in this s
	ection is appropriate, as it can easily be copy and pasted by the user, or downl	ection is appropriate, as it can easily be copy and pasted by the user or downlo
	oaded as part of a web transaction.</t>	aded as part of a web transaction.</li>
	</list></t>	</ol>
		<t indent="0" pn="section-appendix.b-17">For reverse zones, the relationsh
	<t>For reverse zones, the relationship is always with the upstream ISP (although	ip is always with the upstream ISP (although there may be more than one), so <xr
	there may be more than one), and so <xref target="I-D.ietf-homenet-naming-archi	ef target="RFC9527" format="default" sectionFormat="of" derivedContent="RFC9527"
	tecture-dhc-options"/> is always the appropriate interface.</t>	/> always applies.</t>
		<t indent="0" pn="section-appendix.b-18">The following is an abridged exam
	<t>The following is an abbridged example of a set of data that represents the ne	ple of a set of data that represents the needed configuration parameters for out
	eded configuration parameters for outsourcing.</t>	sourcing.</t>
		</section>
	</section>	<section anchor="sec-ex-manu" numbered="true" removeInRFC="false" toc="inclu
	<section anchor="sec-ex-manu"><name>Example: A manufacturer provisioned HNA prod	de" pn="section-appendix.c">
	uct flow</name>	<name slugifiedName="name-example-a-manufacturer-prov">Example: A Manufact
		urer-Provisioned HNA Product Flow</name>
	<t>This scenario is one where a homenet router device manufacturer decides to of	<t indent="0" pn="section-appendix.c-1">This scenario is one where a Homen
	fer DNS hosting as a value add.</t>	et router device manufacturer decides to offer DNS hosting as a value add.</t>
		<t indent="0" pn="section-appendix.c-2"><xref target="I-D.richardson-homer
	<t><xref target="I-D.richardson-homerouter-provisioning"/> describes a process f	outer-provisioning" format="default" sectionFormat="of" derivedContent="HOMEROUT
	or a home router	ER-PROVISION"/> describes a process for a home router
	credential provisioning system.	credential provisioning system.
	The outline of it is that near the end of the manufacturing process, as part of the firmware loading, the manufacturer provisions a private key and certificate into the device.</t>	The outline of it is that near the end of the manufacturing process, as part of the firmware loading, the manufacturer provisions a private key and certificate into the device.</t>

		<t indent="0" pn="section-appendix.c-3">In addition to having an asymmetri
	<t>In addition to having a assymmetric credential known to the manufacturer, the	c credential known to the manufacturer, the device also has
	device also has	been provisioned with an agreed-upon name. In the example in the above document
	been provisioned with an agreed upon name. In the example in the above document	, the name "n8d234f.r.example.net" has already been allocated and confirmed with
	, the name "n8d234f.r.example.net" has already been allocated and confirmed with	the manufacturer.</t>
	the manufacturer.</t>	<t indent="0" pn="section-appendix.c-4">The HNA can use the above domain f
		or itself.
	<t>The HNA can use the above domain for itself.	It is not very pretty or personal, but if the owner would like to have a better
	It is not very pretty or personal, but if the owner wishes a better name, they c	name, they can arrange it.</t>
	an arrange for it.</t>	<t indent="0" pn="section-appendix.c-5">The configuration would look like
		the following:</t>
	<t>The configuration would look like:</t>	<artwork align="left" pn="section-appendix.c-6">

	<figure><artwork><![CDATA[
	{	{
	"dm" : "2001:db8:1234:111:222::2",	"dm" : "2001:db8:1234:111:222::2",
	"dm_acl" : "2001:db8:1234:111:222::/64",	"dm_acl" : "2001:db8:1234:111:222::/64",
	"dm_ctrl" : "manufacturer.example.net",	"dm_ctrl" : "manufacturer.example.net",
	"dm_port" : "4433",	"dm_port" : "4433",
	"ns_list" : [ "ns1.publicdns.example", "ns2.publicdns.example"],	"ns_list" : [ "ns1.publicdns.example", "ns2.publicdns.example"],
	"zone" : "n8d234f.r.example.net",	"zone" : "n8d234f.r.example.net",
	"auth_method" : "certificate",	"auth_method" : "certificate",
	"hna_certificate":"-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy....",	"hna_certificate":"-----BEGIN CERTIFICATE-----\nMIIDTjCCFGy....",
	}	}

	]]></artwork></figure>	</artwork>
		<t indent="0" pn="section-appendix.c-7">The dm_ctrl and dm_port values wou
	<t>The dm_ctrl and dm_port values would be built into the firmware.</t>	ld be built into the firmware.</t>
		</section>
	</section>	<section anchor="acknowledgment" numbered="false" removeInRFC="false" toc="i
		nclude" pn="section-appendix.d">
		<name slugifiedName="name-acknowledgments">Acknowledgments</name>
		<t indent="0" pn="section-appendix.d-1">The authors wish to thank <contact
		fullname="Philippe Lemordant"/> for his contributions to
		the earlier draft versions of this document; <contact fullname="Ole Troan"/> for
		pointing out issues with
		the IPv6-routed home concept and placing the scope of this document in a
		wider picture; <contact fullname="Mark Townsley"/> for encouragement and injecti
		ng a healthy
		debate on the merits of the idea; <contact fullname="Ulrik de Bie"/> for providi
		ng alternative
		solutions; <contact fullname="Paul Mockapetris"/>, <contact fullname="Christian
		Jacquenet"/>, <contact fullname="Francis Dupont"/>, and <contact fullname="Ludov
		ic Eschard"/> for their remarks on HNA and low power devices; <contact fullname=
		"Olafur Gudmundsson"/> for clarifying DNSSEC capabilities of small devices; <con
		tact fullname="Simon Kelley"/> for its feedback as dnsmasq implementer; <contact
		fullname="Andrew Sullivan"/>, <contact fullname="Mark Andrew"/>, <contact fulln
		ame="Ted Lemon"/>, <contact fullname="Mikael Abrahamson"/>, <contact fullname="S
		tephen Farrell"/>, and <contact fullname="Ray Bellis"/>
		for their feedback on handling different views as well as clarifying the
		impact of outsourcing the zone-signing operation outside the HNA; and <contact f
		ullname="Mark Andrew"/> and <contact fullname="Peter Koch"/> for clarifying the
		renumbering.</t>
		<t indent="0" pn="section-appendix.d-2">The authors would like to thank <c
		ontact fullname="Kiran Makhijani"/> for her in-depth review that contributed to
		shaping the final version of this document.</t>
		<t indent="0" pn="section-appendix.d-3">The authors would also like to tha
		nk our Area Director <contact fullname="Éric Vyncke"/> for his constant support
		and pushing the document through the IESG process and the many reviewers from va
		rious directorates including <contact fullname="Anthony Somerset"/>, <contact fu
		llname="Geoff Huston"/>, <contact fullname="Tim Chown"/>, <contact fullname="Tim
		Wicinski"/>, <contact fullname="Matt Brown"/>, <contact fullname="Darrel Miller
		"/>, and <contact fullname="Christer Holmberg"/>.</t>
		</section>
		<section anchor="contributors" numbered="false" removeInRFC="false" toc="inc
		lude" pn="section-appendix.e">
		<name slugifiedName="name-contributors">Contributors</name>
		<t indent="0" pn="section-appendix.e-1">The coauthors would like to thank
		<contact fullname="Chris Griffiths"/> and <contact fullname="Wouter Cloetens"/>
		for providing significant contributions to the earlier draft versions of this do
		cument.</t>
		</section>
		<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
		="include" pn="section-appendix.f">
		<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">Nominum</organization>
		<address>
		<postal>
		<street>2000 Seaport Blvd.</street>
		<city>Redwood City</city>
		<region>CA</region>
		<code>94063</code>
		<country>United States of America</country>
		</postal>
		<email>ralf.weber@nominum.com</email>
		</address>
		</author>
		<author initials="M." surname="Richardson" fullname="Michael Richardson">
		<organization showOnFrontPage="true">Sandelman Software Works</organizat
		ion>
		<address>
		<postal>
		<street>470 Dawson Avenue</street>
		<city>Ottawa</city>
		<region>ON</region>
		<code>K1Z 5V7</code>
		<country>Canada</country>
		</postal>
		<email>mcr+ietf@sandelman.ca</email>
		</address>
		</author>
		<author initials="R." surname="Hunter" fullname="Ray Hunter">
		<organization showOnFrontPage="true">Globis Consulting BV</organization>
		<address>
		<postal>
		<street>Weegschaalstraat 3</street>
		<city>Eindhoven</city>
		<code>5632CW</code>
		<country>Netherlands</country>
		</postal>
		<email>v6ops@globis.net</email>
		</address>
		</author>
		</section>
	</back>	</back>


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


	</rfc>	</rfc>

End of changes. 75 change blocks.
	3265 lines changed or deleted	3193 lines changed or added
This html diff was produced by rfcdiff 1.48.