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" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.21 (Ruby 3.
	0.2) -->
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?rfc rfcedstyle="yes"?>		<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.21 (Ruby 3.0.
	<?rfc tocindent="yes"?>		2) -->
	<?rfc strict="yes"?>
	<?rfc comments="yes"?>
	<?rfc inline="yes"?>
	<?rfc docmapping="yes"?>
	<rfc ipr="trust200902" docName="draft-ietf-homenet-front-end-naming-delegation-2		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	7" category="exp" tocInclude="true" sortRefs="true" symRefs="true">		-ietf-homenet-front-end-naming-delegation-27" number="9526" submissionType="IETF
	<front>		" category="exp" consensus="true" tocInclude="true" sortRefs="true" symRefs="tru
	<title abbrev="public-names">Simple Provisioning of Public Names for Residen		e" updates="" obsoletes="" xml:lang="en" version="3">
	tial Networks</title>
			<!-- xml2rfc v2v3 conversion 3.16.0 -->
			<front>
			<title abbrev="Public Names for Residential Networks">Simple Provisioning of
			Public Names for Residential Networks</title>
			<seriesInfo name="RFC" value="9526"/>
	<author initials="D." surname="Migault" fullname="Daniel Migault">		<author initials="D." surname="Migault" fullname="Daniel Migault">
	<organization>Ericsson</organization>		<organization>Ericsson</organization>
	<address>		<address>
	<postal>		<postal>
	<street>8275 Trans Canada Route</street>		<street>8275 Trans Canada Route</street>
	<city>Saint Laurent, QC</city>		<city>Saint Laurent</city>
			<region>QC</region>
	<code>4S 0B6</code>		<code>4S 0B6</code>
	<country>Canada</country>		<country>Canada</country>
	</postal>		</postal>
	<email>daniel.migault@ericsson.com</email>		<email>daniel.migault@ericsson.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="R." surname="Weber" fullname="Ralf Weber">		<author initials="R." surname="Weber" fullname="Ralf Weber">
	<organization>Nominum</organization>		<organization>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>Sandelman Software Works</organization>
	<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>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 year="2024" month="January"/>
	<date year="2023" month="February" day="08"/>
	<area>Internet</area>		<area>Internet</area>
	<workgroup>Homenet</workgroup>		<workgroup>Homenet</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>		<abstract>
			<t>Home network owners may have devices or services hosted on their home n
	<t>Home network owners may have devices or services hosted on their home network		etwork that they wish to access from the Internet (i.e., from a network outside
	that they wish to access from the Internet (i.e., from a network outside of the		of the home network). Home networks are increasingly numbered using IPv6 address
	home network).		es, which in principle makes this access simpler, but accessing home networks fr
	Home networks are increasingly numbered using IPv6 addresses, which in principle		om the Internet requires the names and IP addresses of these devices and service
	makes this access simpler, but their access from the Internet requires the name		s to be made available in the public DNS.</t>
	s and IP addresses of these devices and services to be made available in the pu		<t>This document describes how a Home Naming Authority (NHA) instructs the
	blic DNS.</t>		outsourced infrastructure to publish these pieces of information in the public
			DNS.
	<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>
	</front>		</front>
	<middle>		<middle>
			<section anchor="introduction">
	<section anchor="introduction"><name>Introduction</name>		<name>Introduction</name>
			<t>Home network owners may have devices or services hosted on their home n
	<t>Home network owners may have devices or services hosted on their home network		etwork
	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>As depicted in <xref target="fig-outsourcing-overview"/>, the names and
	<t>As depicted in {fig-outsourcing-overview}, he names and IP address of the hom		IP address of the home network are made available in the Public Homenet Zone by
	e network are made availble in the Public Homenet Zone by the Homenet Naming Aut		the Homenet Naming Authority (HNA), which in turn instructs the DNS Outsourcing
	hority (HNA), which in turn instructs the DNS Outsourcing Infrastructure (DOI) t		Infrastructure (DOI) to publish the zone on behalf of the HNA.
	o 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>This document introduces the Synchronization Channel and the Control Ch
	<t>The document introduces the Synchronization Channel and the Control Channel b		annel between the HNA and the Distribution Manager (DM), which is the main inte
	etween the HNA and the Distribution Manager (DM), which is the main interface t		rface to the DOI.</t>
	o the DNS Outsourcing Infrastructure (DOI).</t>		<t>The Synchronization Channel (see <xref target="sec-synch"/>) is used to
			synchronize the Public Homenet Zone.</t>
	<t>The Synchronization Channel (see <xref target="sec-synch"/>) is used to synch		<figure anchor="fig-outsourcing-overview">
	ronize the Public Homenet Zone.</t>		<name>High-Level Architecture Overview of Outsourcing the Public Homenet
			Zone</name>
	<figure title="High level architecture overview of outsourcing the Public Homene		<artwork align="center"><![CDATA[
	t Zone" anchor="fig-outsourcing-overview"><artwork align="center"><![CDATA[
	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>
			</figure>
			<t>The Synchronization Channel is a zone transfer, with the HNA configured
			as a primary server and the Distribution Manager configured as a secondary serv
			er.
			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
			t it has many slightly different meanings to many.</t>
			<t>The Control Channel (see <xref target="sec-ctrl"/>) is used to set up t
			he Synchronization Channel.
			This channel is in the form of a dynamic DNS update process, authenticated
			by TLS.</t>
	]]></artwork></figure>		<t>For example, to build the Public Homenet Zone, the HNA needs the author
			itative servers (and associated IP addresses) of the DOI's servers (the visible
	<t>The Synchronization Channel is a zone transfer, with the HNA configured as a		primaries) that are actually serving the zone.
	primary, and the Distribution Manager configured as a secondary.
	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
	t has many slightly different meanings to many.</t>
	<t>The Control Channel (see <xref target="sec-ctrl"/>) is used to set up the Syn
	chronization Channel.
	This channel is in the form of a dynamic DNS update process, authenticated by TL
	S.</t>
	<t>For example, to build the Public Homenet Zone, the HNA needs the authoritativ
	e servers (and associated IP addresses) of the servers (the visible primaries) o
	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>The remainder of the document is as follows.</t>		<t>The remainder of the document is as follows.</t>
			<t><xref target="terminology"/> defines the terminology.
	<t><xref target="terminology"/> defines the terminology.		<xref target="selectingnames"/> presents the general problem of publishing names
	<xref target="selectingnames"/> presents the general problem of publishing names		and IP addresses. <xref target="sec-deployment"/> briefly describes some potent
	and IP addresses.</t>		ial envisioned deployment scenarios.
			And <xref target="sec-arch-desc"/> provides an architectural view of the HNA,
	<t><xref target="sec-arch-desc"/> provides an architectural view of the HNA, DM		DM, and DOI as well as their different communication channels (Control Channel,
	and DOI as well as their different communication channels (Control Channel, Syn		Synchronization Channel, and DM Distribution Channel) described in Sections <xre
	chronization Channel, DM Distribution Channel) respectively described in <xref t		f target="sec-ctrl" format="counter"/>, <xref target="sec-synch" format="counter
	arget="sec-ctrl"/>, <xref target="sec-synch"/> and <xref target="sec-dist"/>.</t		"/>, and <xref target="sec-dist" format="counter"/>, respectively.</t>
	>		<t>Then, Sections <xref target="sec-ctrl" format="counter"/> and <xref tar
			get="sec-synch" format="counter"/> deal with the two channels that interface to
	<t>Then <xref target="sec-ctrl"/> and <xref target="sec-synch"/> deal with the t		the home.
	wo channels that interface to the home.		<xref target="sec-dist"/> provides a set of requirements and expectations on how
	<xref target="sec-dist"/> provides a set of requirements and expectations on how		the distribution system works. This section is non-normative and not subject t
	the distribution system works. This section is non-normative and not subject t		o standardization but reflects how many scalable DNS distribution systems operat
	o standardization, but reflects how many scalable DNS distribution systems opera		e.</t>
	te.</t>		<t>Sections <xref target="sec-cpe-sec-policies" format="counter"/> and <xr
			ef target="sec-dnssec-deployment" format="counter"/> respectively detail HNA sec
	<t><xref target="sec-cpe-sec-policies"/> and <xref target="sec-dnssec-deployment		urity policies as well as DNSSEC compliance within the home network.</t>
	"/> respectively detail HNA security policies as well as DNSSEC compliance withi		<t><xref target="sec-renumbering"/> discusses how renumbering should be ha
	n the home network.</t>		ndled.</t>
			<t>Finally, Sections <xref target="sec-privacy" format="counter"/> and <xr
	<t><xref target="sec-renumbering"/> discusses how renumbering should be handled.		ef target="sec-security" format="counter"/> respectively discuss privacy and sec
	</t>		urity considerations when outsourcing the Public Homenet Zone.</t>
			<t>The appendices discuss the following aspects: management (see <xref tar
	<t>Finally, <xref target="sec-privacy"/> and <xref target="sec-security"/> respe		get="sec-reverse"/>), provisioning (see <xref target="sec-reverse"/>), configura
	ctively discuss privacy and security considerations when outsourcing the Public		tions (see <xref target="info-model"/>), and deployment (see <xref target="sec-d
	Homenet Zone.</t>		eployment"/> and <xref target="sec-ex-manu"/>).</t>
			</section>
	<t>The appendices discuss several management (see <xref target="sec-reverse"/>)		<section anchor="terminology">
	provisioning (see <xref target="sec-reverse"/>), configurations (see <xref targe		<name>Terminology</name>
	t="info-model"/>) and deployment (see <xref target="sec-deployment"/> and <xref		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
	target="sec-ex-manu"/>) aspects.</t>		>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
			NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
	</section>		MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	<section anchor="terminology"><name>Terminology</name>		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
			nterpreted as
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		only when, they
	"MAY", and "OPTIONAL" in this document are to be interpreted as
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
	only when, they
	appear in all capitals, as shown here.</t>		appear in all capitals, as shown here.</t>
			<dl>
	<dl>		<dt>Customer Premises Equipment (CPE):</dt>
	<dt>Customer Premises Equipment:</dt>		<dd>
	<dd>		<t>A router providing connectivity to the home network.</t>
	<t>(CPE) is a router providing connectivity to the home network.</t>		</dd>
	</dd>		<dt>Homenet Zone:</dt>
	<dt>Homenet Zone:</dt>		<dd>
	<dd>		<t>The DNS zone for use within the boundaries of the home network: "ho
	<t>is the DNS zone for use within the boundaries of the home network: 'home.		me.arpa" (see <xref target="RFC8375"/>).
	arpa' (see <xref target="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>Registered Homenet Domain:</dt>
	<dd>		<dd>
	<t>is the domain name that is associated with the home network. A given home		<t>The domain name that is associated with the home network. A given h
	network may have multiple Registered Homenet Domain.</t>		ome network may have multiple Registered Homenet Domains.</t>
	</dd>		</dd>
	<dt>Public Homenet Zone:</dt>		<dt>Public Homenet Zone:</dt>
	<dd>		<dd>
	<t>contains the names in the home network that are expected to be publicly r		<t>Contains the names in the home network that are expected to be publ
	esolvable on the Internet. A home network can have multiple Public Homenet Zones		icly resolvable on the Internet. A home network can have multiple Public Homenet
	.</t>		Zones.</t>
	</dd>		</dd>
	<dt>Homenet Naming Authority(HNA):</dt>		<dt>Homenet Naming Authority (HNA):</dt>
	<dd>		<dd>
	<t>is a function responsible for managing the Public Homenet Zone.		<t>A function responsible for managing the Public Homenet Zone.
	This includes populating the Public Homenet Zone, signing the zone for DNSSEC, a		This includes populating the Public Homenet Zone, signing the zone for DNSSEC, a
	s well as managing the distribution of that Homenet Zone to the DNS Outsourcing		s well as managing the distribution of that Homenet Zone to the DOI.</t>
	Infrastructure (DOI).</t>		</dd>
	</dd>		<dt>DNS Outsourcing Infrastructure (DOI):</dt>
	<dt>DNS Outsourcing Infrastructure (DOI):</dt>		<dd>
	<dd>		<t>The infrastructure responsible for receiving the Public Homenet Zon
	<t>is the infrastructure responsible for receiving the Public Homenet Zone a		e and publishing it on the Internet.
	nd 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>Public Authoritative Servers:</dt>
	<dd>		<dd>
	<t>are the authoritative name servers for the Public Homenet Zone.		<t>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>Homenet Authoritative Servers:</dt>
	<dd>		<dd>
	<t>are authoritative name servers for the Homenet Zone within the Homenet ne		<t>The authoritative name servers for the Homenet Zone within the Home
	twork itself. These are sometimes called the hidden primary servers.</t>		net network itself. These are sometimes called "hidden primary servers".</t>
	</dd>		</dd>
	<dt>Distribution Manager (DM):</dt>		<dt>Distribution Manager (DM):</dt>
	<dd>		<dd>
	<t>is the (set of) server(s) to which the HNA synchronizes the Public Homene		<t>The server (or set of servers) that the HNA synchronizes the Public
	t Zone, and which then distributes the relevant information to the Public Author		Homenet Zone to and that then distributes the relevant information to the Publi
	itative Servers.		c Authoritative Servers. This server has been historically known as the Distribu
	This server has been historically known as the Distribution Master.</t>		tion Master.</t>
	</dd>		</dd>
	<dt>Public Homenet Reverse Zone:</dt>		<dt>Public Homenet Reverse Zone:</dt>
	<dd>		<dd>
	<t>The reverse zone file associated with the Public Homenet Zone.</t>		<t>The reverse zone file associated with the Public Homenet Zone.</t>
	</dd>		</dd>
	<dt>Reverse Public Authoritative Servers:</dt>		<dt>Reverse Public Authoritative Servers:</dt>
	<dd>		<dd>
	<t>equivalent to Public Authoritative Servers specifically for reverse resol		<t>These are equivalent to Public Authoritative Servers, specifically
	ution.</t>		for reverse resolution.</t>
	</dd>		</dd>
	<dt>Reverse Distribution Manager:</dt>		<dt>Reverse Distribution Manager:</dt>
	<dd>		<dd>
	<t>equivalent to Distribution Manager specifically for reverse resolution.</		<t>This is equivalent to the Distribution Manager, specifically for re
	t>		verse resolution.</t>
	</dd>		</dd>
	<dt>Homenet DNS(SEC) Resolver:</dt>		<dt>DNS Resolver:</dt>
	<dd>		<dd>
	<t>a resolver that performs a DNS(SEC) resolution on the home network for th		<t>A resolver that performs a DNS resolution on the Internet for the P
	e Public Homenet Zone.		ublic Homenet Zone.
	The resolution is performed requesting the Homenet Authoritative Servers.</t>		The resolution is performed by requesting the Public Authoritative Serv
	</dd>		ers. While the resolver does not necessarily perform DNSSEC resolutions, it is <
	<dt>DNS(SEC) Resolver:</dt>		bcp14>RECOMMENDED</bcp14> that DNSSEC is enabled. </t>
	<dd>		<t>Note that when "DNS Resolver" is used in this document, it refers
	<t>a resolver that performs a DNS resolution on the Internet for the Public		to "DNS or DNSSEC Resolver".</t>
	Homenet Zone.		</dd>
	The resolution is performed requesting the Public Authoritative Servers.</t>		<dt>Homenet DNS Resolver:</dt>
	</dd>		<dd>
	</dl>		<t>A resolver that performs a DNS or DNSSEC resolution on the home net
			work for the Public Homenet Zone. The resolution is performed by requesting the
	</section>		Homenet Authoritative Servers.</t>
	<section anchor="selectingnames"><name>Selecting Names and Addresses to Publish<		</dd>
	/name>		</dl>
			</section>
	<t>While this document does not create any normative mechanism to select the nam		<section anchor="selectingnames">
	es to publish, this document anticipates that the home network administrator (a		<name>Selecting Names and Addresses to Publish</name>
	human being), will be presented with a list of current names and addresses eithe		<t>While this document does not create any normative mechanism to select t
	r directly on the HNA or via another device such as a smartphone.</t>		he names to publish, it does anticipate that the home network administrator (a h
			uman being) will be presented with a list of current names and addresses either
	<t>The administrator would mark which devices and services (by name), are to be		directly on the HNA or via another device such as a smartphone.</t>
	published.		<t>The administrator will mark which devices and services (by name) are to
	The HNA would then collect the IP address(es) associated with that device or ser		be published. The HNA will then collect the IP address(es) associated with that
	vice, and put the name into the Public Homenet Zone.		device or service and put the name into the Public Homenet Zone. The address of
	The address of the device or service can be collected from a number of places: m		the device or service can be collected from a number of places: Multicast DNS (
	DNS <xref target="RFC6762"/>, DHCP <xref target="RFC8415"/>, UPnP, PCP <xref tar		mDNS) <xref target="RFC6762"/>, DHCP <xref target="RFC8415"/>, Universal Plug an
	get="RFC6887"/>, or manual configuration.</t>		d Play (UPnP), the Port Control Protocol (PCP) <xref target="RFC6887"/>, or manu
			al configuration.</t>
	<t>A device or service SHOULD have Global Unicast Addresses (GUA) (IPv6 <xref ta		<t>A device or service <bcp14>SHOULD</bcp14> have Global Unicast Addresses
	rget="RFC3787"/> or IPv4), but MAY also have Unique Local IPv6 Addresses (ULA) <		(GUAs) (IPv6 <xref target="RFC3587"/> or IPv4) but <bcp14>MAY</bcp14> also have
	xref target="RFC4193"/>, IPv6-Link-Local addresses<xref target="RFC4291"/><xref		IPv6 Unique Local Addresses (ULAs) <xref target="RFC4193"/>, IPv6 Link-Local Ad
	target="RFC7404"/>, IPv4-Link-Local Addresses <xref target="RFC3927"/> (LLA), an		dresses (LLAs) <xref target="RFC4291"/> <xref target="RFC7404"/>, IPv4 LLAs <xre
	d finally, private IPv4 addresses <xref target="RFC1918"/>.</t>		f target="RFC3927"/>, and private IPv4 addresses <xref target="RFC1918"/>.</t>
			<t>Of these, the LLAs are almost never useful for the Public Zone and shou
	<t>Of these the link-local are almost never useful for the Public Zone, and shou		ld be omitted.</t>
	ld be omitted.</t>		<t>The IPv6 ULA and private IPv4 addresses may be useful to publish, if th
			e home network environment features a VPN that would allow the home owner to rea
	<t>The IPv6 ULA and the private IPv4 addresses may be useful to publish, if the		ch the network. <xref target="RFC1918"/> addresses in public zones are generally
	home network environment features a VPN that would allow the home owner to reach		filtered out by many DNS servers as they are considered rebind attacks <xref ta
	the network.		rget="REBIND"/>.</t>
	RFC1918 addresses in public zones are generally filtered out by many DNS servers		<t>In general, one expects the GUA to be the default address to be publish
	as they are considered rebind attacks <xref target="REBIND"/>.</t>		ed.
			A direct advantage of enabling local communication is to enable communications e
	<t>In general, one expects the GUA to be the default address to be published.		ven in case of Internet disruption. Since communications are established with na
	A direct advantage of enabling local communication is to enable communications e		mes that remain a global identifier, the communication can be protected (at the
	ven in case of Internet disruption.		very least with integrity protection) by TLS the same way it is protected on the
	Since communications are established with names which remain a global identifier		global Internet -- by using certificates.</t>
	, the communication can be protected (at the very least with integrity protectio		</section>
	n) by TLS the same way it is protected on the global Internet - using certificat		<section anchor="sec-deployment">
	es.  </t>		<name>Envisioned Deployment Scenarios</name>
			<t>A number of deployment scenarios have been envisioned; this section aim
	</section>		s at
	<section anchor="sec-deployment"><name>Envisioned deployment scenarios</name>		providing a brief description. The use cases are not limitations, and this secti
			on is not normative.</t>
	<t>A number of deployment scenarios have been envisioned, this section aims at		<t>The main difference between the various deployments concerns the provis
	providing a brief description.		ioning of the HNA -- that is, how it is configured to outsource the Public Homen
	The use cases are not limitations and this section is not normative.</t>		et Zone to the DOI -- as well as how the Public Homenet Zone is being provisione
			d before being outsourced.
	<t>The main difference between the various deployments concerns the provisioning		In both cases, these configuration aspects are out of the scope of this document
	of the HNA - that is how it is configured to outsource the Public Homenet Zone		.</t>
	to the DOI - as well as how the Public Homenet Zone is being provisioned before		<t>Provisioning the configuration related to the DOI is expected to be aut
	being outsourced.<br />		omated as much as possible and require interaction with the end user as little a
	In both cases, these configuration aspects are out of the scope of the document.		s possible.
	</t>		Zero configuration can only be achieved under some circumstances, and <xref targ
			et="RFC9527"/> provides one such example under the assumption that the ISP provi
	<t>Provisioning the configuration related to the DOI is expected to be automated		des the DOI. <xref target="sec-cpe-vendor"/> describes another variant where the
	as much as possible and require as little as possible interaction with the end		Customer Premises Equipment (CPE) is provided preconfigured with the DOI.
	user. <br />
	Zero configuration can only be achieved under some circumstances and <xref targe
	t="I-D.ietf-homenet-naming-architecture-dhc-options"/> provides one such example
	under the assumption the ISP provides the DOI. <xref target="sec-cpe-vendor"/>
	describes another variant where the CPE is provided preconfigured with the DOI.
	<xref target="sec-agnostic-cpe"/> describes how an agnostic CPE may be configure d by the home network administrator.		<xref target="sec-agnostic-cpe"/> describes how an agnostic CPE may be configure d by the home network administrator.
	Of course even in this case, the configuration can leverage mechanisms to preven		Of course even in this case, the configuration can leverage mechanisms to
	t the end user manually entering all information.</t>		prevent the end user from manually entering all information.</t>
			<t>On the other hand, provisioning the Public Homenet Zone needs to combin
	<t>On the other hand, provisioning the Public Homenet Zone needs to combine the		e the ability to closely reflect what the end user wishes to publish on the Inte
	ability to closely reflect what the end user wishes to publish on the Internet w		rnet while easing such interaction.
	hile easing such interaction.		The HNA may implement such interactions using web-based GUIs or specific mobile
	The HNA may implement such interactions using Web GUI or specific mobile applica		applications.</t>
	tions.</t>		<t>With the CPE configured with the DOI, the HNA contacts the DOI to build
			a template for the
	<t>With the CPE configured with the DOI, the HNA contacts the DOI to build a tem		Public Homenet Zone and then provisions the Public Homenet Zone.
	plate for the		Once the Public Homenet Zone is built, the HNA starts synchronizing it with the
	Public Homenet Zone, and then provision the Public Homenet Zone.		DOI on the Synchronization Channel.</t>
	Once the Public Homenet Zone is built, the HNA strats synchronizing it with the		<section anchor="sec-cpe-vendor">
	DOI on the Synchronization channel.</t>		<name>CPE Vendor</name>
			<t>A specific vendor that has specific relations with a registrar or a r
	<section anchor="sec-cpe-vendor"><name>CPE Vendor</name>		egistry
	<t>A specific vendor with specific relations 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>One possible scenario is that the vendor provisions the HNA with a pr
	<t>One possible scenario is that the vendor provisions the HNA with a private ke		ivate key with an associated certificate used for the mutual TLS authentication.
	y, with an associated certificate used for 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>Instead, these keys are solely used by the HNA for the authentication to the
	<t>Instead these keys are solely used by the HNA for the authentication to the D		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>When the home network owner plugs in the CPE at home, the relation be
			tween the HNA and DM is expected to work out of the box.</t>
	<t>When the home network owner plugs in the CPE at home, the relation between HN		</section>
	A and DM is expected to work out-of-the-box.</t>		<section anchor="sec-agnostic-cpe">
			<name>Agnostic CPE</name>
	</section>		<t>A CPE that is not preconfigured may also use the protocol
	<section anchor="sec-agnostic-cpe"><name>Agnostic CPE</name>		defined in this document, but some configuration steps will be needed.</t>
			<ol spacing="normal" type="1">
	<t>A CPE that is not preconfigured may also use the protocol		<li>The owner of the home network buys a domain name from a registrar and,
	defined in this document but some configuration steps will be needed.</t>		as such, creates an account on that registrar.</li>
			<li>The registrar may provide the outsourcing infrastructure,
	<t><list style="numbers">
	<t>The owner of the home network buys a domain name from a registrar, and
	as such creates an account on that registrar</t>
	<t>the registrar may also be providing 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">
	<t><list style="symbols">		<li>If the DOI is the DNS Registrar, it has by design a proof of owner
	<t>If the DOI is the DNS Registrar, it has by design a proof of ownership of t		ship of the domain name by the Homenet owner.
	he domain name by the homenet owner.		In this case, it is expected that the DOI provides the necessary parameters to t
	In this case, it is expected the DOI provides the necessary parameters to the ho		he home network owner to configure the HNA. One potential mechanism to provide t
	me network owner to configure the HNA.		he parameters would be to provide the user with a JSON object that they can copy
	One potential mechanism to provide the parameters would be to provide the user w		and paste into the CPE, such as described in <xref target="info-model"/>.
	ith a JSON object which they can copy paste into the CPE - such as described in		But what matters to the infrastructure is that the HNA is able to authenticate i
	<xref target="info-model"/>.		tself to the DOI.</li>
	But, what matters to infrastructure is that the HNA is able to authenticate itse		<li>If the DOI is not the DNS Registrar, then the proof of ownership n
	lf to the DOI.</t>		eeds to be established using some other protocol.
	<t>If the DOI is not the DNS Registrar, then the proof of ownership needs to b		Automatic Certificate Management Environment (ACME) <xref target="RFC85
	e established using some other protocol.		55"/> is one protocol that would allow an owner of an existing domain name to pr
	ACME <xref target="RFC8555"/> is one protocol that would allow an owner of an ex		ove their ownership (but it requires that they have DNS already set up!). There
	isting domain name to prove their ownership (but requires they have DNS already		are other ways to establish proof such as providing a DOI-generated TXT record,
	setup!)		or web site contents, as championed by entities like Google's Sitemaster and Pos
	There are other ways such as putting a DOI generated TXT record, or web site con		tmaster protocols.
	tents, as championed by entities like Google's Sitemaster and Postmaster protoco		<xref target="I-D.ietf-dnsop-domain-verification-techniques"/> describes a few w
	ls.		ays ownership or control of a domain can be achieved.</li>
	<xref target="I-D.ietf-dnsop-domain-verification-techniques"/> describes a few w		</ul>
	ays ownership or control of a domain can be achieved.</t>		</section>
	</list></t>		</section>
			<section anchor="sec-arch-desc">
	</section>		<name>Architecture Description</name>
	</section>		<t>This section provides an overview of the architecture for outsourcing t
	<section anchor="sec-arch-desc"><name>Architecture Description</name>		he authoritative naming service from the HNA to the DOI.
			As a consequence, this prevents HNA from handling the DNS traffic from the Inter
	<t>This section provides an overview of the architecture for outsourcing the aut		net that is associated with the resolution of the Homenet Zone.</t>
	horitative naming service from the HNA to the DOI.		<t>The device-assigned zone or user-configurable zone that is used as the
	As a consequence, this prevents HNA to handle the DNS traffic from the Internet		domain to publicly serve hostnames in the home network is called the Public Home
	associated with the resolution of the Homenet Zone.</t>		net Zone.
			In this document, "myhome.example" is used as the example for an end-user-owned
	<t>The device assigned zone or user configurable zone to use as the domain to pu		domain configured as a Public Homenet Zone.</t>
	blicly serve hostnames in the home network is called the Public Homenet Zone.		<t>More specifically, DNS resolution for the Public Homenet Zone (here "my
	In this document, "myhome.example" is used as the example for an enduser owned d		home.example") from Internet DNSSEC resolvers is handled by the DOI as opposed t
	omain configured as Public Homenet Zone.</t>		o the HNA.
			The DOI benefits from a cloud infrastructure while the HNA is dimensioned for a
	<t>More specifically, DNS resolution for the Public Homenet Zone (here myhome.ex		home network and, as such, is likely unable to support any load.
	ample) from Internet DNSSEC resolvers is handled by the DOI as opposed to the HN		In the case where the HNA is a CPE, outsourcing to the DOI reduces the attack su
	A.		rface of the home network to DDoS, for example.
	The DOI benefits from a cloud infrastructure while the HNA is dimensioned for ho		Of course, the DOI needs to be informed dynamically about the content of m
	me network and as such likely unable to support any load.		yhome.example. The description of such a synchronization mechanism is the purpos
	In the case the HNA is a CPE, outsourcing to the DOI reduces the attack surface		e of this document.</t>
	of the home network to DDoS for example.
	Of course the DOI needs to be informed dynamically about the content of myhome.e
	xample. The description of such a synchronization mechanism is the purpose of th
	is document.</t>
	<t>Note that <xref target="info-model"/> shows necessary parameters to configure
	the HNA.</t>
	<section anchor="sec-arch-overview"><name>Architecture Overview</name>
	<figure title="Homenet Naming Architecture" anchor="fig-naming-arch"><artwork al		<t>Note that <xref target="info-model"/> shows the necessary parameters to
	ign="center"><![CDATA[		configure the HNA.</t>
			<section anchor="sec-arch-overview">
			<name>Architecture Overview</name>
			<figure anchor="fig-naming-arch">
			<name>Homenet Naming Architecture</name>
			<artwork align="center"><![CDATA[
	.----------------------------. .-----------------------------.		.----------------------------. .-----------------------------.
	| 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><xref target="fig-naming-arch"/> illustrates the architecture where t
	utsources the publication of the Public Homenet Zone to the DOI.		he HNA outsources the publication of the Public Homenet Zone to the DOI.
	The DOI will serve every DNS request of the Public Homenet Zone coming from outs		The DOI will serve every DNS request of the Public Homenet Zone coming from outs
	ide the home network.		ide the home network. When the request is coming from within the home network, t
	When the request is coming within the home network, the resolution is expected t		he resolution is expected to be handled by the Homenet DNS Resolver as further d
	o be handled by the Homenet Resolver as detailed in further details below.</t>		etailed below.</t>
			<t>In this example, the Public Homenet Zone is identified by the Registe
	<t>In this example, The Public Homenet Zone is identified by the Registered Home		red Homenet Domain name "myhome.example".
	net Domain name -- myhome.example.		This diagram also shows a reverse IPv6 map being hosted.</t>
	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
	Homenet zones and represented as a Homenet Zone in <xref target="fig-naming-arch
	"/>.
	They are resolved locally, but not published as they are local content.</t>
	<t>It is RECOMMENDED the HNA implements DNSSEC, in which case the HNA MUST signs
	the Public Homenet Zone with DNSSEC.</t>
	<t>The HNA handles all operations and keying material required for DNSSEC, so th
	ere is no provision made in this architecture for transferring private DNSSEC re
	lated keying material between the HNA and the DM.</t>
	<t>Once the Public Homenet Zone has been built, the HNA communicates and synchro
	nizes it with the DOI using a primary/secondary setting as depicted in <xref tar
	get="fig-naming-arch"/>.
	The HNA acts as a stealth server (see <xref target="RFC8499"/>) while the DM beh
	aves as a hidden secondary.
	It is responsible for distributing the Public Homenet Zone to the multiple Publi
	c Authoritative Servers instances that DOI is responsible for.
	The DM has three communication channels:</t>
	<t><list style="symbols">
	<t>DM Control Channel (<xref target="sec-ctrl"/>) to configure the HNA and the
	DOI. This includes necessary parameters to configure the primary/secondary rela
	tion as well as some information provided by the DOI that needs to be included b
	y the HNA in the Public Homenet Zone.</t>
	<t>DM Synchronization Channel (<xref target="sec-synch"/>) to synchronize the
	Public Homenet Zone on the HNA and on the DM with the appropriately configured p
	rimary/secondary.
	This is a zone transfer over mutually authenticated TLS.</t>
	<t>one or more Distribution Channels (<xref target="sec-dist"/>) that distribu
	te the Public Homenet Zone from the DM to the Public Authoritative Servers servi
	ng the Public Homenet Zone on the Internet.</t>
	</list></t>
	<t>There might be multiple DM's, and multiple servers per DM.		<t>".local" and ".home.arpa" are explicitly not considered Public Homene
			t Zones; therefore, they are represented as a Homenet Zone in <xref target="fig-
			naming-arch"/>.
			They are resolved locally but are not published because they are considered loca
			l content.</t>
			<t>It is <bcp14>RECOMMENDED</bcp14> that the HNA implements DNSSEC, in w
			hich case the HNA <bcp14>MUST</bcp14> sign the Public Homenet Zone with DNSSEC.<
			/t>
			<t>The HNA handles all operations and keying material required for DNSSE
			C, so there is no provision made in this architecture for transferring private D
			NSSEC-related keying material between the HNA and the DM.</t>
			<t>Once the Public Homenet Zone has been built, the HNA communicates and
			synchronizes it with the DOI using a primary/secondary setting as depicted in <
			xref target="fig-naming-arch"/>.
			The HNA acts as a stealth server (see <xref target="RFC8499"/>) while the DM beh
			aves as a hidden secondary. It is responsible for distributing the Public Homene
			t Zone to the multiple Public Authoritative Server instances that DOI is respons
			ible for. The DM has three communication channels:</t>
			<ul spacing="normal">
			<li>DM Control Channel (<xref target="sec-ctrl"/>) to configure the HN
			A and the DOI. This includes necessary parameters to configure the primary/secon
			dary relation as well as some information provided by the DOI that needs to be i
			ncluded by the HNA in the Public Homenet Zone.</li>
			<li>DM Synchronization Channel (<xref target="sec-synch"/>) to synchro
			nize the Public Homenet Zone on the HNA and on the DM with the appropriately con
			figured primary/secondary.
			This is a zone transfer over mutually authenticated TLS.</li>
			<li>One or more Distribution Channels (<xref target="sec-dist"/>) that
			distribute the Public Homenet Zone from the DM to the Public Authoritative Serv
			ers serving the Public Homenet Zone on the Internet.</li>
			</ul>
			<t>There might be multiple DMs and multiple servers per the DM.
	This document assumes a single DM server for simplicity, but there is no reason why each channel needs to be implemented on the same server or use the same code base.</t>		This document assumes a single DM server for simplicity, but there is no reason why each channel needs to be implemented on the same server or use the same code base.</t>
			<t>It is important to note that while the HNA is configured as an author
	<t>It is important to note that while the HNA is configured as an authoritative		itative server, it is not expected to answer DNS requests from the <em>public</e
	server, it is not expected to answer DNS requests from the <em>public</em> Inter		m> 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>The DOI is also responsible for ensuring the DS record has been updat
	<t>The DOI is also responsible for ensuring the DS record has been updated in th		ed in the parent zone.</t>
	e parent zone.</t>		<t>Resolution is performed by DNS Resolvers.
			When the resolution is performed outside the home network, the DNS Resolver reso
	<t>Resolution is performed by DNS(SEC) resolvers.		lves the DS record on the Global DNS and the name associated with the Public Hom
	When the resolution is performed outside the home network, the DNS(SEC) Resolver		enet Zone (myhome.example) on the Public Authoritative Servers.</t>
	resolves the DS record on the Global DNS and the name associated with the Publi		<t>In order to provide resilience to the Public Homenet Zone in case of
	c Homenet Zone (myhome.example) on the Public Authoritative Servers.</t>		WAN connectivity disruption, the Homenet DNS Resolver <bcp14>MUST</bcp14> be abl
			e to perform the resolution on the Homenet Authoritative Servers.
	<t>In order to provide resilience to the Public Homenet Zone in case of WAN conn		Note that the use of the Homenet DNS Resolver enhances privacy since the user on
	ectivity disruption, the Homenet DNS(SEC) Resolver MUST be able to perform the r		the home network would no longer be leaking interactions with internal services
	esolution on the Homenet Authoritative Servers.		to an external DNS provider and to an on-path observer.
	Note that the use of the Homenet resolver enhances privacy since the user on the		These servers are not expected to be mentioned in the Public Homenet Zone nor to
	home network would no longer be leaking interactions with internal services to		be accessible from the Internet.
	an external DNS provider and to an on-path observer.		As such, their information as well as the corresponding signed DS record <bcp14>
	These servers are not expected to be mentioned in the Public Homenet Zone, nor t		MAY</bcp14> be provided by the HNA to the Homenet DNS Resolvers, e.g., by using
	o be accessible from the Internet.		the Home Networking Control Protocol (HNCP) <xref target="RFC7788"/> or by confi
	As such their information as well as the corresponding signed DS record MAY be p		guring a trust anchor <xref target="I-D.ietf-dnsop-dnssec-validator-requirements
	rovided by the HNA to the Homenet DNS(SEC) Resolvers, e.g., using HNCP <xref tar		"/>.
	get="RFC7788"/> or a by configuring a trust anchor <xref target="I-D.ietf-dnsop-
	dnssec-validator-requirements"/>.
	Such configuration is outside the scope of this document.		Such configuration is outside the scope of this document.
	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 f target="fig-naming-arch"/>.</t>		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 f target="fig-naming-arch"/>.</t>
			</section>
			<section anchor="sec-comms">
			<name>Distribution Manager (DM) Communication Channels</name>
			<t>This section details the DM channels: the Control Channel, Synchroniz
			ation Channel, and Distribution Channel.</t>
			<t>The Control Channel and the Synchronization Channel are the interface
			s used between the HNA and the DOI. The entity within the DOI responsible for ha
			ndling these communications is the DM. Communications between the HNA and the DM
			<bcp14>MUST</bcp14> be protected and mutually authenticated.
			The different protocols that can be used for security are discussed in more dept
			h in <xref target="sec-ctrl-security"/>.</t>
			<t>The information exchanged between the HNA and the DM uses DNS message
			s protected by DNS over TLS (DoT) <xref target="RFC7858"/>.
			This is configured identically to that described in <xref target="RFC9103
			" sectionFormat="comma" section="9.3.3"/>.</t>
	</section>		<t>It is worth noting that both the DM and HNA need to agree on a common
	<section anchor="sec-comms"><name>Distribution Manager (DM) Communication Channe		configuration in order to set up the Synchronization Channel and build and serv
	ls</name>		e a coherent Public Homenet Zone.
			As previously noted, the visible NS records of the Public Homenet Zone (built by
	<t>This section details the DM channels, that is the Control Channel, the Synchr		the HNA) remain pointing at the IP address of the DOI's Public Authoritative Se
	onization Channel and the Distribution Channel.</t>		rvers.
			Unless the HNA is able to support the traffic load, the HNA <bcp14>SHOULD NOT</b
	<t>The Control Channel and the Synchronization Channel are the interfaces used b		cp14> appear as a visible NS record of the Public Homenet Zone.
	etween the HNA and the DOI.		In addition, and depending on the configuration of the DOI, the DM also needs to
	The entity within the DOI responsible to handle these communications is the DM.		update the parent zone's NS, DS, and associated A or AAAA glue records.
	Communications between the HNA and the DM MUST be protected and mutually authent
	icated.
	<xref target="sec-ctrl-security"/> discusses in more depth the different securit
	y protocols that could be used to secure.</t>
	<t>The information exchanged between the HNA and the DM uses DNS messages protec
	ted by DNS over TLS (DoT) <xref target="RFC7858"/>.
	This is configured identically to that described in <xref target="RFC9103"/>, Se
	ction 9.3.3.</t>
	<t>It is worth noting that both DM and HNA need to agree on a common configurati
	on to set up the synchronization channel as well as to build and server a cohere
	nt Public Homenet Zone.
	As previously noted, the visible NS records of the Public Homenet Zone (built by
	the HNA) remain pointing at the DOI's Public Authoritative Servers' IP address.
	Unless the HNA is able to support the traffic load, the HNA SHOULD NOT appear as
	a visible NS records of the Public Homenet Zone.
	In addition, and depending on the configuration of the DOI, the DM also needs to
	update the parent zone's NS, DS and associated A or AAAA glue records.
	Refer to <xref target="sec-chain-of-trust"/> for more details.</t>		Refer to <xref target="sec-chain-of-trust"/> for more details.</t>
			<t>This specification assumes:</t>
	<t>This specification assumes:</t>		<ul spacing="normal">
			<li>The DM serves both the Control Channel and Synchronization Channel
	<t><list style="symbols">		on a single IP address, on a single port, and by using a single transport proto
	<t>the DM serves both the Control Channel and Synchronization Channel on a sin		col.</li>
	gle IP address, single port and using a single transport protocol.</t>		<li>By default, the HNA uses a single IP address for both the Control
	<t>By default, the HNA uses a single IP address for both the Control and Synch		and Synchronization channels; however, the HNA <bcp14>MAY</bcp14> use distinct I
	ronization channel.		P addresses for the Control Channel and the Synchronization Channel -- see Secti
	However, the HNA MAY use distinct IP addresses for the Control Channel and the S		ons <xref target="sec-synch" format="counter"/> and <xref target="sec-sync-info"
	ynchronization Channel - see <xref target="sec-synch"/> and <xref target="sec-sy		format="counter"/> for more details.</li>
	nc-info"/> for more details.</t>		</ul>
	</list></t>		<t>The Distribution Channel is internal to the DOI and, as such, is not
			normatively defined by this specification.</t>
	<t>The Distribution Channel is internal to the DOI and as such is not normativel		</section>
	y defined by this specification.</t>		</section>
			<section anchor="sec-ctrl">
	</section>		<name>Control Channel</name>
	</section>		<t>The DM Control Channel is used by the HNA and the DOI to exchange infor
	<section anchor="sec-ctrl"><name>Control Channel</name>		mation related to the configuration of the delegation, which includes informatio
			n to build the Public Homenet Zone (<xref target="sec-pbl-homenet-zone"/>), to b
	<t>The DM Control Channel is used by the HNA and the DOI to exchange information		uild the DNSSEC chain of trust (<xref target="sec-chain-of-trust"/>), and to set
	related to the configuration of the delegation which includes information to bu		the Synchronization Channel (<xref target="sec-sync-info"/>).</t>
	ild the Public Homenet Zone (<xref target="sec-pbl-homenet-zone"/>), information		<t>Some information is carried from the DOI to the HNA, as described in th
	to build the DNSSEC chain of trust (<xref target="sec-chain-of-trust"/>) and in		e next section.
	formation to set the Synchronization Channel (<xref target="sec-sync-info"/>).</		The HNA updates the DOI with the IP address on which the zone is to be transferr
	t>		ed using the Synchronization Channel.
	<t>Some information is carried from the DOI to the HNA, described in the next se
	ction.
	The HNA updates the DOI with the the IP address on which the zone is to be trans
	ferred 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>As such, the HNA has a prior knowledge of the DM identity (via an X.509
	<t>As such the HNA has a prior knowledge of the DM identity (via X509 certificat		certificate), the IP address and port number to use, and the protocol to establ
	e), the IP address and port number to use and protocol to establish a secure ses		ish 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"/>.</t>
	For more detail to see how this can be achieved, please see <xref target="hna-pr		<section anchor="sec-pbl-homenet-zone">
	ovisioning"/>.</t>		<name>Building the Public Homenet Zone</name>
			<t>The HNA builds the Public Homenet Zone based on a template that is re
	<section anchor="sec-pbl-homenet-zone"><name>Information to Build the Public Hom		turned by the DM to the HNA. <xref target="sec-ctrl-messages"/> explains how th
	enet Zone</name>		is leverages the Authoritative Transfer (AXFR) mechanism.</t>
			<t>In order to build its zone completely, the HNA needs the names (and p
	<t>The HNA builds the Public Homenet Zone based on a template that is returned b		ossibly IP addresses) of the Public Authoritative Name Servers.
	y the DM to the HNA. <xref target="sec-ctrl-messages"/> explains how this lever
	ages the AXFR mechanism.</t>
	<t>In order to build its zone completely, the HNA needs the names (and possibly
	IP addresses) of the Public Authoritative Name Servers.
	These are used to populate the NS records for the zone.		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>In addition, the HNA needs to know what to put into the MNAME of the
	<t>In addition, the HNA needs to know what to put into the MNAME of the SOA, and		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>Because the information associated with the DM is necessary for the H
	<t>As the information is necessary for the HNA to proceed and the information is		NA to proceed, this information exchange is mandatory.</t>
	associated with the DM, this information exchange is mandatory.</t>		<t>The HNA then performs a DNS Update operation to the DOI, updating the
			DOI with an NS, a DS, and A and AAAA records. These indicate where its Synchron
	<t>The HNA then performs a DNS Update operation to the DOI, updating the DOI wit		ization Channel is.
	h an NS, DS, A and AAAA records. These indicates where its Synchronization Chann		The DOI does not publish this NS record but uses it to perform zone transfers.</
	el is.		t>
	The DOI does not publish this NS record, but uses it to perform zone transfers.<		</section>
	/t>		<section anchor="sec-chain-of-trust">
			<name>Building the DNSSEC Chain of Trust</name>
	</section>		<t>The HNA <bcp14>MUST</bcp14> provide the hash of the KSK via the DS RR
	<section anchor="sec-chain-of-trust"><name>Information to build the DNSSEC chain		set so that the DOI can provide this value to the parent zone.
	of trust</name>		A common deployment use case is that the DOI is the registrar of the Registered
			Homenet Domain; therefore, its relationship with the registry of the parent zone
	<t>The HNA MUST provide the hash of the KSK via the DS RRset, so that the DOI ca		enables it to update the parent zone. When such relation exists, the HNA should
	n provide this value to the parent zone.		be able to request the DOI to update the DS RRset in the parent zone.
	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
	e enables it to update the parent zone.
	When such relation exists, the HNA should be able to request the DOI to update t
	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>Though the HNA may also directly update the values of the DS via the
	<t>Though the HNA may also later directly update the values of the DS via the Co		Control Channel at a later time, it is <bcp14>RECOMMENDED</bcp14> to use other m
	ntrol Channel, it is RECOMMENDED to use other mechanisms such as CDS and CDNSKEY		echanisms such as CDS and CDNSKEY <xref target="RFC7344"/> for transparent updat
	<xref target="RFC7344"/> for transparent updates during key roll overs.</t>		es during key rollovers.</t>
			<t>As some deployments may not provide a DOI that will be able to update
	<t>As some deployments may not provide a DOI that will be able to update the DS		the DS in the parent zone, this information exchange is <bcp14>OPTIONAL</bcp14>
	in the parent zone, this information exchange is OPTIONAL.</t>		.</t>
			<t>By accepting the DS RR, the DM commits to advertise the DS to the par
	<t>By accepting the DS RR, the DM commits to advertise the DS to the parent zone		ent zone.
	.		On the other hand, if the DM does not have the capacity to advertise the DS to t
	On the other hand if the DM does not have the capacity to advertise the DS to th		he parent zone, it indicates this by refusing the update to the DS RR.</t>
	e parent zone, it indicates this by refusing the update to the DS RR.</t>		</section>
			<section anchor="sec-sync-info">
	</section>		<name>Setting Up the Synchronization Channel</name>
	<section anchor="sec-sync-info"><name>Information to set up the Synchronization		<t>The HNA works as a hidden primary authoritative DNS server while the
	Channel</name>		DM works like a secondary one.
			As a result, the HNA needs to provide the IP address that the DM should use to r
	<t>The HNA works as a hidden primary authoritative DNS server, while the DM work		each the HNA.</t>
	s like a secondary.		<t>If the HNA detects that it has been renumbered, then it <bcp14>MUST</
	As a result, the HNA needs to provide the IP address the DM should use to reach		bcp14> use the Control Channel to update the DOI with the new IPv6 address it ha
	the HNA.</t>		s been assigned.</t>
			<t>The Synchronization Channel will be set between the new IPv6 (and IPv
	<t>If the HNA detects that it has been renumbered, then it MUST use the Control		4) address and the IP address of the DM.
	Channel to update the DOI with the new IPv6 address it has been assigned.</t>		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
	<t>The Synchronization Channel will be set between the new IPv6 (and IPv4) addre		TIONAL</bcp14>.
	ss and the IP address of the DM.		The transport channel (including the port number) is the same as the one used be
	By default, the IP address used by the HNA in the Control Channel is considered		tween the HNA and the DM for the Control Channel.</t>
	by the DM and the explicit specification of the IP by the HNA is only OPTIONAL.		</section>
	The transport channel (including port number) is the same as the one used betwee		<section anchor="deleting-the-delegation">
	n the HNA and the DM for the Control Channel.</t>		<name>Deleting the Delegation</name>
			<t>The purpose of the previous sections is to exchange information in or
	</section>		der to set a delegation.
	<section anchor="deleting-the-delegation"><name>Deleting the delegation</name>		The HNA <bcp14>MUST</bcp14> also be able to delete a delegation with a specific
			DM.</t>
	<t>The purpose of the previous sections were to exchange information in order to		<t><xref target="sec-zone-delete"/> explains how a DNS Update operation
	set a delegation.		on the Control Channel is used.</t>
	The HNA MUST also be able to delete a delegation with a specific DM.</t>		<t>Upon receiving the instruction to delete the delegation, the DM <bcp1
			4>MUST</bcp14> stop serving the Public Homenet Zone.</t>
	<t><xref target="sec-zone-delete"/> explains how a DNS Update operation on the C		<t>The decision to delete an inactive HNA by the DM is part of the comme
	ontrol Channel is used.</t>		rcial agreement between the DOI and HNA.</t>
			</section>
	<t>Upon an instruction of deleting the delegation, the DM MUST stop serving the		<section anchor="sec-ctrl-messages">
	Public Homenet Zone.</t>		<name>Message Exchange Description</name>
			<t>Multiple ways were considered on how the control information could be
	<t>The decision to delete an inactive HNA by the DM is part of the commercial ag		exchanged between the HNA and the DM.</t>
	reement between DOI and HNA.</t>		<t>This specification defines a mechanism that reuses the DNS zone trans
			fer format.
	</section>		Note that while information is provided using DNS exchanges, the exchanged infor
	<section anchor="sec-ctrl-messages"><name>Messages Exchange Description</name>		mation is not expected to be set in any zone file; instead, this information is
			used as commands between the HNA and the DM.
	<t>Multiple ways were considered on how the control information could be exchang
	ed between the HNA and the DM.</t>
	<t>This specification defines a mechanism that re-uses the DNS zone transfer for
	mat.
	Note that while information is provided using DNS exchanges, the exchanged infor
	mation is not expected to be set in any zone file, instead this information is u
	sed 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>The Control Channel is not expected to be a long-term session.
	<t>The Control Channel is not expected to be a long-term session.		After a predefined timer (similar to those used for TCP), the Control Channel is
	After a predefined timer - similar to those used for TCP - the Control Channel i		expected to be terminated by closing the transport channel. The Control Channel
	s expected to be terminated - by closing the transport channel.		<bcp14>MAY</bcp14> be reopened at any later time.</t>
	The Control Channel MAY be re-opened at any time later.</t>		<t>The use of TLS session tickets (see <xref section="4.6.1" sectionForm
			at="comma" target="RFC8446"/>) is <bcp14>RECOMMENDED</bcp14>.</t>
	<t>The use of a TLS session tickets <xref section="4.6.1" sectionFormat="comma"		<t>The authentication of the channel <bcp14>MUST</bcp14> be based on cer
	target="RFC8446"/> is RECOMMENDED.</t>		tificates for both the DM and each HNA.
	<t>The authentication of the channel MUST 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">
	<section anchor="zonetemplate"><name>Retrieving information for the Public Homen		<name>Retrieving Information for the Public Homenet Zone</name>
	et Zone</name>		<t>The information provided by the DM to the HNA is retrieved by the H
			NA with an AXFR exchange <xref target="RFC1034"/>.
	<t>The information provided by the DM to the HNA is retrieved by the HNA with an
	AXFR exchange <xref target="RFC1034"/>.
	AXFR enables the response to contain any type of RRsets.</t>		AXFR enables the response to contain any type of RRsets.</t>
			<t>To retrieve the necessary information to build the Public Homenet Z
			one, the HNA <bcp14>MUST</bcp14> send a DNS request of type AXFR associated with
			the Registered Homenet Domain.</t>
			<t>The zone that is returned by the DM is used by the HNA as a templat
			e to build its own zone.</t>
			<t>The zone template <bcp14>MUST</bcp14> contain an RRset of type SOA,
			one or multiple RRsets of type NS, and zero or more RRsets of type A or AAAA (i
			f the NS is in-domain <xref target="RFC8499"/>). The zone template will include
			Time-To-Live (TTL) values for each RR, and the HNA <bcp14>SHOULD</bcp14> take th
			ese as suggested maximum values, but it <bcp14>MAY</bcp14> use lower values for
			operational reasons, such as for impending renumbering events.</t>
			<ul spacing="normal">
			<li>The SOA RR indicates the value of the MNAME of the Public Homene
			t Zone to the HNA.</li>
			<li>The NAME of the SOA RR <bcp14>MUST</bcp14> be the Registered Hom
			enet Domain.</li>
			<li>The MNAME value of the SOA RDATA is the value provided by the DO
			I to the HNA.</li>
			<li>Other RDATA values (RNAME, REFRESH, RETRY, EXPIRE, and MINIMUM)
			are provided by the DOI as suggestions.</li>
			</ul>
			<t>The NS RRsets carry the Public Authoritative Servers of the DOI.
			Their associated NAME <bcp14>MUST</bcp14> be the Registered Homenet Domain.</t>
			<t>In addition to the considerations above about default TTL, the HNA
			<bcp14>SHOULD</bcp14>
			take care to not pick a TTL larger than the parent NS, based upon the resolver's
			guidelines in <xref target="I-D.ietf-dnsop-ns-revalidation"/> and <xref target=
			"I-D.ietf-dnsop-dnssec-validator-requirements"/>.
			The RRsets of Type A and AAAA <bcp14>MUST</bcp14> have their NAME match
			ing the NSDNAME of one of the NS RRsets.</t>
	<t>To retrieve the necessary information to build the Public Homenet Zone, the H		<t>Upon receiving the response, the HNA <bcp14>MUST</bcp14> validate t
	NA MUST send a DNS request of type AXFR associated with the Registered Homenet D		he format and properties of the SOA, NS, and A or AAAA RRsets.
	omain.</t>		If an error occurs, the HNA <bcp14>MUST</bcp14> stop proceeding and <bcp14>MUST<
			/bcp14> log an error.
	<t>The zone that is returned by the DM is used by the HNA as a template to build		Otherwise, the HNA builds the Public Homenet Zone by setting the MNAME value of
	its own zone.</t>		the SOA as indicated by the SOA provided by the AXFR response. The HNA <bcp14>MU
			ST NOT</bcp14> exceed the values of NAME, REFRESH, RETRY, EXPIRE, and MINIMUM of
	<t>The zone template MUST contain a RRset of type SOA, one or multiple RRset of		the SOA provided by the AXFR response. The HNA <bcp14>MUST</bcp14> insert the N
	type NS and zero or more RRset of type A or AAAA (if the NS are in-domain <xref		S and corresponding A or AAAA RRsets in its Public Homenet Zone. The HNA <bcp14>
	target="RFC8499"/>).		MUST</bcp14> ignore other RRsets.</t>
	The zone template will include Time To Live (TTL) values for each RR, and the HN		<t>If an error message is returned by the DM, the HNA <bcp14>MUST</bcp
	A SHOULD take these as suggested maximum values, but MAY use lower values for op		14> proceed as a regular DNS resolution. Error messages <bcp14>SHOULD</bcp14> be
	erational reasons, such impending renumbering events.</t>		logged for further analysis.
			If the resolution does not succeed, the outsourcing operation is aborted and the
	<t><list style="symbols">		HNA <bcp14>MUST</bcp14> close the Control Channel.</t>
	<t>The SOA RR indicates to the HNA the value of the MNAME of the Public Homene		</section>
	t Zone.</t>		<section anchor="sec-ds">
	<t>The NAME of the SOA RR MUST be the Registered Homenet Domain.</t>		<name>Providing Information for the DNSSEC Chain of Trust</name>
	<t>The MNAME value of the SOA RDATA is the value provided by the DOI to the HN		<t>To provide the DS RRset to initialize the DNSSEC chain of trust, th
	A.</t>		e HNA <bcp14>MAY</bcp14> send a DNS update <xref target="RFC3007"/> message.</t>
	<t>Other RDATA values (RNAME, REFRESH, RETRY, EXPIRE and MINIMUM) are provided		<t>The DNS update message is composed of a Header section, a Zone sect
	by the DOI as suggestions.</t>		ion, a Prerequisite section, an Update section, and an additional section.
	</list></t>		The Zone section <bcp14>MUST</bcp14> set the ZNAME to the parent zone of the Reg
			istered Homenet Domain, which is where the DS records should be inserted. As des
	<t>The NS RRsets carry the Public Authoritative Servers of the DOI.		cribed in <xref target="RFC2136"/>, ZTYPE is set to SOA and ZCLASS is set to the
	Their associated NAME MUST be the Registered Homenet Domain.</t>		zone's class.
			The Prerequisite section <bcp14>MUST</bcp14> be empty.
	<t>In addition to the considerations above about default TTL, the HNA SHOULD		The Update section is a DS RRset with its NAME set to the Registered Homenet Dom
	take care to not pick a TTL larger than the parent NS, based upon resolver's gui		ain, and the associated RDATA corresponds to the value of the DS.
	de lines: <xref target="I-D.ietf-dnsop-ns-revalidation"/> and <xref target="I-D.		The Additional Data section <bcp14>MUST</bcp14> be empty.</t>
	ietf-dnsop-dnssec-validator-requirements"/>.		<t>Though the Prerequisite section <bcp14>MAY</bcp14> be ignored by th
	The RRsets of Type A and AAAA MUST have their NAME matching the NSDNAME of one o		e DM, this value is fixed to remain coherent with a standard DNS update.</t>
	f the NS RRsets.</t>		<t>Upon receiving the DNS update request, the DM reads the DS RRset in
			the Update section.
	<t>Upon receiving the response, the HNA MUST validate format and properties of t		The DM checks that ZNAME corresponds to the parent zone. The DM <bcp14>MUST</bcp
	he SOA, NS and A or AAAA RRsets.		14> ignore the Prerequisite and Additional Data sections, if present. The DM <bc
	If an error occurs, the HNA MUST stop proceeding and MUST log an error.		p14>MAY</bcp14> update the TTL value before updating the DS RRset in the parent
	Otherwise, the HNA builds the Public Homenet Zone by setting the MNAME value of		zone. Upon a successful update, the DM should return a NOERROR response as a com
	the SOA as indicated by the SOA provided by the AXFR response.		mitment to update the parent zone with the provided DS. An error indicates that
	The HNA MUST not exceed the values of NAME, REFRESH, RETRY, EXPIRE and MINIMUM o		the DM does not update the DS, and the HNA needs to act accordingly; otherwise,
	f the SOA to those provided by the AXFR response.		another method should be used by the HNA.</t>
	The HNA MUST insert the NS and corresponding A or AAAA RRset in its Public Homen		<t>The regular DNS error message <bcp14>MUST</bcp14> be returned to th
	et Zone.		e HNA when an error occurs. In particular, a FORMERR is returned when a format e
	The HNA MUST ignore other RRsets.</t>		rror is found, including when unexpected RRsets are added or when RRsets are mis
			sing. A SERVFAIL error is returned when an internal error is encountered.
	<t>If an error message is returned by the DM, the HNA MUST proceed as a regular		A NOTZONE error is returned when the Update and Zone sections are not coherent,
	DNS resolution.		and a NOTAUTH error is returned when the DM is not authoritative for the Zone se
	Error messages SHOULD be logged for further analysis.		ction. A REFUSED error is returned when the DM refuses the configuration or perf
	If the resolution does not succeed, the outsourcing operation is aborted and the		orming the requested action.</t>
	HNA MUST close the Control Channel.</t>		</section>
			<section anchor="sec-ip-hna">
	</section>		<name>Providing Information for the Synchronization Channel</name>
	<section anchor="sec-ds"><name>Providing information for the DNSSEC chain of tru		<t>The default IP address used by the HNA for the Synchronization Chan
	st</name>		nel is the IP address of the Control Channel. To provide a different IP address,
			the HNA <bcp14>MAY</bcp14> send a DNS UPDATE message.</t>
	<t>To provide the DS RRset to initialize the DNSSEC chain of trust the HNA MAY s		<t>Similar to what is described in <xref target="sec-ds"/>, the HNA <b
	end a DNS update <xref target="RFC3007"/> message.</t>		cp14>MAY</bcp14> specify the IP address using a DNS update message. The Zone sec
			tion sets its ZNAME to the parent zone of the Registered Homenet Domain, ZTYPE t
	<t>The DNS update message is composed of a Header section, a Zone section, a Pre		o SOA, and ZCLASS to the zone's type. Prerequisite is empty. The Update section
	-requisite section, and Update section and an additional section.		is an RRset of type NS. The Additional Data section contains the RRsets of type
	The Zone section MUST set the ZNAME to the parent zone of the Registered Homenet		A or AAAA that designate the IP addresses associated with the primary (or the HN
	Domain - that is where the DS records should be inserted. As described <xref ta		A).</t>
	rget="RFC2136"/>, ZTYPE is set to SOA and ZCLASS is set to the zone's class.		<t>The reason to provide these IP addresses is to keep them unpublishe
	The Pre-requisite section MUST be empty.		d and prevent them from being resolved. It is <bcp14>RECOMMENDED</bcp14> that th
	The Update section is a DS RRset with its NAME set to the Registered Homenet Dom		e IP address of the HNA be randomly chosen to prevent it from being easily disco
	ain and the associated RDATA corresponds to the value of the DS.		vered as well.</t>
	The Additional Data section MUST be empty.</t>		<t>Upon receiving the DNS update request, the DM reads the IP addresse
			s and checks that the ZNAME corresponds to the parent zone. The DM <bcp14>MUST</
	<t>Though the pre-requisite section MAY be ignored by the DM, this value is fixe		bcp14> ignore a non-empty Prerequisite section. The DM configures the secondary
	d to remain coherent with a standard DNS update.</t>		with the IP addresses and returns a NOERROR response to indicate it is committed
			to serve as a secondary.</t>
	<t>Upon receiving the DNS update request, the DM reads the DS RRset in the Updat		<t>Similar to what is described in <xref target="sec-ds"/>, DNS errors
	e section.		are used, and an error indicates the DM is not configured as a secondary.</t>
	The DM checks ZNAME corresponds to the parent zone.		</section>
	The DM MUST ignore the Pre-requisite and Additional Data sections, if present.		<section anchor="sec-zone-delete">
	The DM MAY update the TTL value before updating the DS RRset in the parent zone.		<name>Initiating Deletion of the Delegation</name>
	Upon a successful update, the DM should return a NOERROR response as a commitmen		<t>To initiate the deletion of the delegation, the HNA sends a DNS UPD
	t to update the parent zone with the provided DS.		ATE Delete message.</t>
	An error indicates the DM does not update the DS, and the HNA needs to act accor		<t>The Zone section sets its ZNAME to the Registered Homenet Domain, t
	dingly or other method should be used by the HNA.</t>		he ZTYPE to SOA, and the ZCLASS to the zone's type. The Prerequisite section is
			empty. The Update section is an RRset of type NS with the NAME set to the Regist
	<t>The regular DNS error message MUST be returned to the HNA when an error occur		ered Domain Name.
	s.		As indicated by <xref target="RFC2136" sectionFormat="comma" section="2
	In particular a FORMERR is returned when a format error is found, this includes		.5.2"/>, the delete instruction is initiated by setting TTL to 0, CLASS to ANY,
	when unexpected RRSets are added or when RRsets are missing.		and RDLENGTH to 0, and RDATA <bcp14>MUST</bcp14> be empty. The Additional Data s
	A SERVFAIL error is returned when a internal error is encountered.		ection is empty.</t>
	A NOTZONE error is returned when update and Zone sections are not coherent, a NO		<t>Upon receiving the DNS update request, the DM checks the request an
	TAUTH error is returned when the DM is not authoritative for the Zone section.		d removes the delegation. The DM returns a NOERROR response to indicate the dele
	A REFUSED error is returned when the DM refuses to proceed to the configuration		gation has been deleted. Similar to what is described in <xref target="sec-ds"/>
	and the requested action.</t>		, DNS errors are used, and an error indicates that the delegation has not been d
			eleted.</t>
	</section>		</section>
	<section anchor="sec-ip-hna"><name>Providing information for the Synchronization		</section>
	Channel</name>		<section anchor="sec-ctrl-security">
			<name>Securing the Control Channel</name>
	<t>The default IP address used by the HNA for the Synchronization Channel is the		<t>TLS <xref target="RFC8446"/> <bcp14>MUST</bcp14> be used to secure th
	IP address of the Control Channel.		e transactions between the DM and the HNA, and the DM and HNA <bcp14>MUST</bcp14
	To provide a different IP address, the HNA MAY send a DNS UPDATE message.</t>		> be mutually authenticated.
	<t>Similarly to the <xref target="sec-ds"/>, the HNA MAY specify the IP address
	using a DNS update message.
	The Zone section sets its ZNAME to the parent zone of the Registered Homenet Dom
	ain, ZTYPE is set to SOA and ZCLASS is set to the zone's type.
	Pre-requisite is empty.
	The Update section is a RRset of type NS.
	The Additional Data section contains the RRsets of type A or AAAA that designate
	s 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
	ent them to be resolved.
	It is RECOMMENDED the IP address of the HNA is randomly chosen to prevent it fro
	m being easily discovered as well.</t>
	<t>Upon receiving the DNS update request, the DM reads the IP addresses and chec
	ks the ZNAME corresponds to the parent zone.
	The DM MUST ignore a non-empty Pre-requisite section.
	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>
	<t>Similarly to <xref target="sec-ds"/>, DNS errors are used and an error indica
	tes the DM is not configured as a secondary.</t>
	</section>
	<section anchor="sec-zone-delete"><name>HNA instructing deleting the delegation<
	/name>
	<t>To instruct to delete the delegation the HNA sends a DNS UPDATE Delete messag
	e.</t>
	<t>The Zone section sets its ZNAME to the Registered Homenet Domain, the ZTYPE t
	o SOA and the ZCLASS to zone's type.
	The Pre-requisite section is empty.
	The Update section is a RRset of type NS with the NAME set to the Registered Dom
	ain Name.
	As indicated by <xref target="RFC2136"/> Section 2.5.2 the delete instruction is
	set by setting the TTL to 0, the Class to ANY, the RDLENGTH to 0 and the RDATA
	MUST be empty.
	The Additional Data section is empty.</t>
	<t>Upon receiving the DNS update request, the DM checks the request and removes
	the delegation.
	The DM returns a NOERROR response to indicate the delegation has been deleted.
	Similarly to <xref target="sec-ds"/>, DNS errors are used and an error indicates
	the delegation has not been deleted.</t>
	</section>
	</section>
	<section anchor="sec-ctrl-security"><name>Securing the Control Channel</name>
	<t>TLS <xref target="RFC8446"/>) MUST be used to secure the transactions between
	the DM and the HNA and
	the DM and HNA MUST be mutually authenticated.
	The DNS exchanges are performed using DNS over TLS <xref target="RFC7858"/>.</t>		The DNS exchanges are performed using DNS over TLS <xref target="RFC7858"/>.</t>
			<t>The HNA may be provisioned by the manufacturer or during some user-in
			itiated onboarding process, for example, with a browser, by signing up to a serv
			ice provider, and with a resulting OAuth 2.0 token to be provided to the HNA. Su
			ch 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 scope for this document.)</t>
			<t>When the HNA connects to the DM's Control Channel, TLS will be used,
			and the connection will be mutually authenticated.
			The DM will authenticate the HNA's certificate based upon having participated in
			some provisioning process that is not standardized by this document. The result
			s of the provisioning process is a series of settings described in <xref target=
			"hna-provisioning"/>.</t>
			<t>The HNA will validate the DM's Control Channel certificate by perform
			ing a DNS-ID check on the name as described in <xref target="RFC9525"/>.</t>
			<t>In the future, other specifications may consider protecting DNS messa
			ges with other transport layers such as DNS over DTLS <xref target="RFC8094"/>,
			DNS over HTTPS (DoH) <xref target="RFC8484"/>, or DNS over QUIC <xref target="RF
			C9250"/>.</t>
			</section>
			</section>
			<section anchor="sec-synch">
			<name>Synchronization Channel</name>
			<t>The DM Synchronization Channel is used for communication between the HN
			A and the DM for synchronizing the Public Homenet Zone. Note that the Control Ch
			annel and the Synchronization Channel are different channels by construction eve
			n though they may use the same IP address. Suppose the HNA and the DM are using
			a single IP address designated by XX, and YYYYY and ZZZZZ are the various ports
			involved in the communications.</t>
	<t>The HNA may be provisioned by the manufacturer, or during some user-initiated		<t>The Control Channel is between</t>
	onboarding process, for example, with a browser, signing up to a service provid		<ul>
	er, with a resulting OAUTH2 token to be provided to the HNA.		<li>the HNA working as a client using port number YYYYY (an ephemeral also com
	Such a process may result in a passing of a settings from a Registrar into the H		monly designated as a high range port) and</li>
	NA through an http API interface. (This is not in scope)</t>		<li>a service provided by the DM at port 853, when using DoT.</li>
			</ul>
	<t>When the HNA connects to the DM's control channel, TLS will be used, and the
	connection will be mutually authenticated.
	The DM will authenticate the HNA's certificate based upon having participating i
	n some provisioning process that is not standardized by this document.
	The results of the provisioning process is a series of settings described in <xr
	ef target="hna-provisioning"/>.</t>
	<t>The HNA will validate the DM's control channel certificate by doing an <xref
	target="I-D.ietf-uta-rfc6125bis"/> DNS-ID check on the name.</t>
	<t>In the future, other specifications may consider protecting DNS messages with
	other transport layers, among others, DNS over DTLS <xref target="RFC8094"/>, o
	r DNS over HTTPs (DoH) <xref target="RFC8484"/> or DNS over QUIC <xref target="R
	FC9250"/>.</t>
	</section>
	</section>
	<section anchor="sec-synch"><name>Synchronization Channel</name>
	<t>The DM Synchronization Channel is used for communication between the HNA and
	the DM for synchronizing the Public Homenet Zone.
	Note that the Control Channel and the Synchronization Channel are by constructio
	n different channels even though there they may use the same IP address.
	Suppose the HNA and the DM are using a single IP address and let designate by XX
	.
	YYYYY and ZZZZZ the various ports involved in the communications.</t>
	<t>The Control Channel is between the HNA working as a client using port number
	YYYYY (an ephemeral also commonly designated as high range port) toward a servic
	e provided by the DM at port 853, when using DoT.</t>
	<t>On the other hand, the Synchronization Channel is set between the DM working
	as a client using port ZZZZZ (another ephemeral port) toward a service provided
	by the HNA at port 853.</t>
	<t>As a result, even though the same pair of IP addresses may be involved the Co
	ntrol Channel and the Synchronization Channel are always distinct channels.</t>
	<t>Uploading and dynamically updating the zone file on the DM can be seen as zon
	e provisioning between the HNA (Hidden Primary) and the DM (Secondary Server).
	This is handled using the normal zone transfer mechanism involving AXFR/IXFR.</t
	>
	<t>Part of this zone update process involves the owner of the zone (the hidden p
	rimary, the HNA) sending a DNS Notify to the secondaries.
	In this situation the only destination that is known by the HNA is the DM's Cont
	rol Channel, and so DNS notifies are sent over the Control Channel, secured by a
	mutually authenticated TLS.</t>
	<t>Please note that, DNS Notifies are not critical to normal operation, as the D
	M will be checking the zone regularly based upon SOA record comments. DNS Notif
	ies do speed things up as they cause the DM to use the Synchronization channel t
	o immediately do an SOA Query to detect any updates. If there are any changes t
	hen the DM immediately transfers the zone updates.</t>
	<t>This specification standardizes the use of a primary / secondary mechanism <x
	ref target="RFC1996"/> rather than an extended series of DNS update messages.
	The primary / secondary mechanism was selected as it scales better and avoids Do
	S attacks.
	As this AXFR runs over a TCP channel secured by a mutually authenticated TLS, th
	en DNS Update is just more complicated.</t>
	<t>Note that this document provides no standard way to distribute a DNS primary
	between multiple devices.
	As a result, if multiple devices are candidate for hosting the Hidden Primary, s
	ome specific mechanisms should be designed so the home network only selects a si
	ngle HNA for the Hidden Primary.
	Selection mechanisms based on HNCP <xref target="RFC7788"/> are good candidates
	for future work.</t>
	<section anchor="sec-synch-security"><name>Securing the Synchronization Channel<
	/name>
	<t>The Synchronization Channel uses mutually authenticated TLS, as described by
	<xref target="RFC9103"/>.</t>
	<t>There is a TLS client certificate used by the DM to authenticate itself.
	The DM uses the same certificate which was configured into the HNA for authentic
	ating the Control Channel, but as a client certificate rather than a server cert
	ificate.</t>
	<t><xref target="RFC9103"/> makes no requirements or recommendations on any exte
	nded key usage flags for zone transfers, and this document adopts the view that
	none should be required.
	and leave it up to <xref target="RFC9103"/> to get updated for this document's
	normative reference to be considered updated as well.</t>
	<t>For the TLS server certificate, the HNA uses the same certificate which it us
	es to authenticate itself to the DM for the Control Channel.</t>
	<t>The HNA MAY use this certificate as the authorization for the zone transfer,
	or the HNA MAY have been configured with an Access Control List that will determ
	ine if the zone transfer can proceed.
	This is a local configuration option, as it is premature to determine which will
	be operationally simpler.</t>
	<t>When the HNA expects to do zone transfer authorization by certificate only, t
	he HNA MAY still apply an ACL on inbound connection requests to avoid load.
	In this case, the HNA MUST regularly check (via a DNS resolution) that the addre
	ss(es) of the DM in the filter is still valid.</t>
	</section>
	</section>
	<section anchor="sec-dist"><name>DM Distribution Channel</name>
	<t>The DM Distribution Channel is used for communication between the DM and the
	Public Authoritative Servers.
	The architecture and communication used for the DM Distribution Channels are out
	side the scope of this document, and there are many existing solutions available
	, e.g., rsync, DNS AXFR, REST, DB copy.</t>
	</section>
	<section anchor="sec-cpe-sec-policies"><name>HNA Security Policies</name>
	<t>The HNA as hidden primary processes only a limited message exchanges on it's
	Internet facing interface.
	This should be enforced using security policies - to allow only a subset of DNS
	requests to be received by HNA.</t>
	<t>The Hidden Primary Server on the HNA differs the regular authoritative server
	for the home network due to:</t>
	<dl>
	<dt>Interface Binding:</dt>
	<dd>
	<t>the Hidden Primary Server will almost certainly listen on the WAN Interfa
	ce, whereas a regular Homenet Authoritative Servers would listen on the internal
	home network interface.</t>
	</dd>
	<dt>Limited exchanges:</dt>
	<dd>
	<t>the purpose of the Hidden Primary Server is to synchronize with the DM, n
	ot to serve any zones to end users, or the public Internet.
	This results in a limited number of possible exchanges (AXFR/IXFR) with a small
	number of IP addresses and an implementation MUST enable filtering policies: it
	should only respond to queries that are required to do zone transfers.
	That list includes SOA queries and AXFR/IXFR queries.</t>
	</dd>
	</dl>
	</section>
	<section anchor="sec-reverse"><name>Public Homenet Reverse Zone</name>
	<t>Public Homenet Reverse Zone works similarly to the Public Homenet Zone.
	The main difference is that ISP that provides the IPv6 connectivity is likely al
	so the owner of the corresponding IPv6 reverse zone and administrating the Rever
	se Public Authoritative Servers.
	The configuration and the setting of the Synchronization Channel and Control Cha
	nnel can largely be automated using DHCPv6 messages that are part of the IPv6 Pr
	efix Delegation process.</t>
	<t>The Public Homenet Zone is associated with a Registered Homenet Domain and th
	e ownership of that domain requires a specific registration from the end user as
	well as the HNA being provisioned with some authentication credentials.
	Such steps are mandatory unless the DOI has some other means to authenticate the
	HNA.
	Such situation may occur, for example, when the ISP provides the Homenet Domain
	as well as the DOI.</t>
	<t>In this case, the HNA may be authenticated by the physical link layer, in whi		<t>On the other hand, the Synchronization Channel is between</t>
	ch case the authentication of the HNA may be performed without additional provis		<ul>
	ioning of the HNA.		<li>the DM working as a client using port ZZZZZ (another ephemeral port) and</
			li>
			<li>a service provided by the HNA at port 853.</li>
			</ul>
			<t>As a result, even though the same pair of IP addresses may be involved,
			the Control Channel and the Synchronization Channel are always distinct channel
			s.</t>
			<t>Uploading and dynamically updating the zone file on the DM can be seen
			as zone provisioning between the HNA (hidden primary server) and the DM (seconda
			ry server).
			This is handled using the normal zone transfer mechanism involving the AXFR and
			Incremental Zone Transfer (IXFR).</t>
			<t>Part of the process to update the zone involves the owner of the zone (
			the hidden primary server, the HNA) sending a DNS Notify to the secondaries. In
			this situation, the only destination that is known by the HNA is the DM's Contro
			l Channel, so DNS Notifies are sent over the Control Channel, secured by a mutua
			lly authenticated TLS.</t>
			<t>Please note that DNS Notifies are not critical to normal operation, as
			the DM will be checking the zone regularly based upon SOA record comments. DNS
			Notifies do speed things up as they cause the DM to use the Synchronization Chan
			nel to immediately do an SOA query to detect any updates. If there are any chan
			ges, then the DM immediately transfers the zone updates.</t>
			<t>This specification standardizes the use of a primary/secondary mechanis
			m <xref target="RFC1996"/> rather than an extended series of DNS update messages
			. The primary/secondary mechanism was selected as it scales better and avoids Do
			S attacks. Because this AXFR runs over a TCP channel secured by a mutually authe
			nticated TLS, the DNS update is more complicated.</t>
			<t>Note that this document provides no standard way to distribute a DNS pr
			imary between multiple devices. As a result, if multiple devices are candidates
			for hosting the hidden primary server, some specific mechanisms should be design
			ed so the home network only selects a single HNA for the hidden primary server.
			Selection mechanisms based on HNCP <xref target="RFC7788"/> are good candidates
			for future work.</t>
			<section anchor="sec-synch-security">
			<name>Securing the Synchronization Channel</name>
			<t>The Synchronization Channel uses mutually authenticated TLS, as descr
			ibed by <xref target="RFC9103"/>.</t>
			<t>There is a TLS client certificate used by the DM to authenticate itse
			lf.
			The DM uses the same certificate that was configured into the HNA for authentica
			ting the Control Channel, but as a client certificate rather than a server certi
			ficate.</t>
			<t><xref target="RFC9103"/> makes no requirements or recommendations on any exte
			nded key usage flags for zone transfers, and this document adopts the view that
			none should be required. Note that once an update to <xref target="RFC9103"/> is
			published, this document's normative reference to <xref target="RFC9103"/> will
			be considered updated as well.</t>
			<t>For the TLS server certificate, the HNA uses the same certificate tha
			t it uses to authenticate itself to the DM for the Control Channel.</t>
			<t>The HNA <bcp14>MAY</bcp14> use this certificate as the authorization
			for the zone transfer, or the HNA <bcp14>MAY</bcp14> have been configured with a
			n Access Control List (ACL) that will determine if the zone transfer can proceed
			. This is a local configuration option as it is premature to determine which wil
			l be operationally simpler.</t>
			<t>When the HNA expects to do zone transfer authorization by certificate
			only, the HNA <bcp14>MAY</bcp14> still apply an ACL on inbound connection reque
			sts to avoid load.
			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-dist">
			<name>DM Distribution Channel</name>
			<t>The DM Distribution Channel is used for communication between the DM an
			d the Public Authoritative Servers.
			The architecture and communication used for the DM Distribution Channels are out
			side the scope of this document, but there are many existing solutions available
			, e.g., rsync, DNS AXFR, REST, and DB copy.</t>
			</section>
			<section anchor="sec-cpe-sec-policies">
			<name>HNA Security Policies</name>
			<t>The HNA, as the hidden primary server, processes only limited message e
			xchanges on its Internet-facing interface.
			This should be enforced using security policies to allow only a subset of DNS re
			quests to be received by HNA.</t>
			<t>The hidden primary server on the HNA differs from the regular authorita
			tive server for the home network due to the following:</t>
			<dl>
			<dt>Interface Binding:</dt>
			<dd>The hidden primary server will almost certainly listen on the WAN In
			terface, whereas a regular Homenet Authoritative Server will listen on the inter
			nal home network interface.
			</dd>
			<dt>Limited Exchanges:</dt>
			<dd>The purpose of the hidden primary server is to synchronize with the
			DM, not to serve any zones to end users or the public Internet. This results in
			a limited number of possible exchanges (AXFR/IXFR) with a small number of IP add
			resses, and an implementation <bcp14>MUST</bcp14> enable filtering policies: it
			should only respond to queries that are required to do zone transfers.
			That list includes SOA queries and AXFR/IXFR queries.
			</dd>
			</dl>
			</section>
			<section anchor="sec-reverse">
			<name>Public Homenet Reverse Zone</name>
			<t>The Public Homenet Reverse Zone works similarly to the Public Homenet Z
			one.
			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
			the Reverse Public Authoritative Servers. The configuration and the setting of t
			he Synchronization Channel and Control Channel can largely be automated using DH
			CPv6 messages that are a part of the IPv6 prefix delegation process.</t>
			<t>The Public Homenet Zone is associated with a Registered Homenet Domain,
			and the ownership of that domain requires a specific registration from the end
			user as well as the HNA being provisioned with some authentication credentials.
			Such steps are mandatory unless the DOI has some other means to authenticate the
			HNA. Such situation may occur, for example, when the ISP provides the Homenet D
			omain as well as the DOI.</t>
			<t>In this case, the HNA may be authenticated by the physical link layer,
			in which case the authentication of the HNA may be performed without additional
			provisioning of the HNA.
	While this may not be so common for the Public Homenet Zone, this situation is 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>More specifically, a common case is that the upstream ISP provides the
			IPv6 prefix to the Homenet with an identity association for a prefix delegation
			(IA_PD) option <xref target="RFC8415"/> and manages the DOI of the associated re
			verse zone.</t>
			<t>This leaves a place for setting up the relation between the HNA and DOI
			automatically as described in <xref target="RFC9527"/>.</t>
			<t>In the case of the reverse zone, the DOI authenticates the source of th
			e updates by IPv6 ACLs, and the ISP knows exactly what addresses have been deleg
			ated. Therefore, the HNA <bcp14>SHOULD</bcp14> always originate Synchronization
			Channel updates from an IP address within the zone that is being updated. Except
			ionally, the Synchronization Channel might be from a different zone delegated to
			the HNA (if there were multiple zones or renumbering events were in progress).<
			/t>
			<t>For example, if the ISP has assigned 2001:db8:f00d:1234::/64 to the WAN inter
			face (by DHCPv6 or PPP with Router Advertisement (RA)), then the HNA should orig
			inate Synchronization Channel updates from, for example, 2001:db8:f00d:1234::2.<
			/t>
	<t>More specifically, a common case is that the upstream ISP provides the IPv6 p		<t>If an ISP has delegated 2001:db8:aeae::/56 to the HNA via DHCPv6-PD, th
	refix to the Homenet with a IA_PD <xref target="RFC8415"/> option and manages th		en the HNA should originate Synchronization Channel updates to an IP address wit
	e DOI of the associated reverse zone.</t>		hin that subnet, such as 2001:db8:aeae:1::2.</t>
			<t>With this relation automatically configured, the synchronization betwee
	<t>This leaves place for setting up automatically the relation between HNA and t		n the Home network and the DOI happens in a similar way to the synchronization o
	he DOI as described in <xref target="I-D.ietf-homenet-naming-architecture-dhc-op		f the Public Homenet Zone described earlier in this document.</t>
	tions"/>.</t>		<t>Note that for home networks connected to multiple ISPs, each ISP provides onl
			y the DOI of the reverse zones associated with the delegated prefix. It is also
	<t>In the case of the reverse zone, the DOI authenticates the source of the upda		likely that the DNS exchanges will need to be performed on dedicated interfaces
	tes by IPv6 Access Control Lists.		to be accepted by the ISP. More specifically, the reverse zone update associated
	In the case of the reverse zone, the ISP knows exactly what addresses have been		with prefix 1 cannot be performed by the HNA using an IP address that belongs t
	delegated.		o prefix 2. Such constraints do not raise major concerns for hot standby or loa
	The HNA SHOULD therefore always originate Synchronization Channel updates from a		d-sharing configuration.</t>
	n IP address within the zone that is being updated.		<t>With IPv6, the reverse domain space for IP addresses associated with a
	Exceptionally, the synchronization channel might be from a different zone delega		subnet such as ::/64 is so large that the reverse zone may be confronted with sc
	ted to the HNA (if there were multiple zones, or renumbering events were in prog		alability issues.
	ress).</t>
	<t>For example, if the ISP has assigned 2001:db8:f00d::/64 to the WAN interface
	(by DHCPv6, or PPP/RA), then the HNA should originate Synchronization Channel up
	dates from, for example, 2001:db8:f00d::2.</t>
	<t>An ISP that has delegated 2001:db8:aeae::/56 to the HNA via DHCPv6-PD, then H
	NA should originate Synchronization Channel updates an IP within that subnet, su
	ch as 2001:db8:aeae:1::2.</t>
	<t>With this relation automatically configured, the synchronization between the
	Home network and the DOI happens similarly as for the Public Homenet Zone descri
	bed earlier in this document.</t>
	<t>Note that for home networks connected to by multiple ISPs, each ISP provides
	only the DOI of the reverse zones associated with the delegated prefix.
	It is also likely that the DNS exchanges will need to be performed on dedicated
	interfaces as to be accepted by the ISP.
	More specifically, the reverse zone associated with prefix 1 will not be possibl
	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. </t>		<xref target="RFC8501"/> provides guidance on how to address scalability issues. </t>
			</section>
			<section anchor="sec-dnssec-deployment">
			<name>DNSSEC-Compliant Homenet Architecture</name>
			<t><xref target="RFC7368" sectionFormat="of" section="3.7.3"/> recommends
			that DNSSEC be deployed on both the authoritative server and the resolver.</t>
			<t>The resolver side is out of scope of this document, and only the author
			itative part of the server is considered.
			Other documents such as <xref target="RFC5011"/> deal with the continuous
			update of trust anchors required for operation of a DNSSEC Resolver.</t>
	</section>		<t>The Public Homenet Zone and the Public Reverse Zone <bcp14>MUST</bcp14> be DN
	<section anchor="sec-dnssec-deployment"><name>DNSSEC compliant Homenet Architect		SSEC signed by the HNA.</t>
	ure</name>		<t>Secure delegation is achieved only if the DS RRset is properly set in t
			he parent zone.
	<t><xref target="RFC7368"/> in Section 3.7.3 recommends DNSSEC to be deployed on		Secure delegation can be performed by the HNA or the DOIs, and the choice highly
	both the authoritative server and the resolver.</t>		depends on which entity is authorized to perform such updates.
			Typically, the DS RRset is updated manually through a registrar interface and ca
	<t>The resolver side is out of scope of this document, and only the authoritativ		n be maintained with mechanisms such as CDS <xref target="RFC7344"/>.</t>
	e part of the server is considered.		<t>When the operator of the DOI is also the registrar for the domain, then
	Other documents such as <xref target="RFC5011"/> deal with continuous update of		it is a trivial matter for the DOI to initialize the relevant DS records in the
	trust anchors required for operation of a DNSSEC resolver.</t>		parent zone.
	<t>The HNA MUST DNSSEC sign the Public Homenet Zone and the Public Reverse Zone.
	</t>
	<t>Secure delegation is achieved only if the DS RRset is properly set in the par
	ent zone.
	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.
	Typically, the DS RRset is updated manually through a registrar interface, and c
	an be maintained with mechanisms such as CDS <xref target="RFC7344"/>.</t>
	<t>When the operator of the DOI is also the Registrar for the domain, then it is
	a trivial matter for the DOI to initialize the relevant DS records in the paren
	t 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>There may be some situations where the HNA is unable to arrange for sec
	<t>There may be some situations where the HNA is unable to arrange for secure de		ure delegation of the zones, but the HNA <bcp14>MUST</bcp14> still sign the zone
	legation of the zones, but the HNA MUST still sign the zones.</t>		s.</t>
			</section>
	</section>		<section anchor="sec-renumbering">
	<section anchor="sec-renumbering"><name>Renumbering</name>		<name>Renumbering</name>
			<t>During a renumbering of the home network, the HNA IP address may be cha
	<t>During a renumbering of the home network, the HNA IP address may be changed a		nged and the Public Homenet Zone will be updated by the HNA with new AAAA record
	nd the Public Homenet Zone will be updated by the HNA with new AAAA records.</t>		s.</t>
			<t>The HNA will then advertise to the DM via a NOTIFY on the Control Chann
	<t>The HNA will then advertise to the DM via a NOTIFY on the Control Channel.		el.
	The DM will need to note the new originating IP for the connection, and it will		The DM will need to note the new originating IP for the connection, and it will
	need to update it's internal database of Synchronization Channels.		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>The remainder of the section provides recommendations regarding the pro
	<t>The remaining of the section provides recommendations regarding the provision		visioning of the Public Homenet Zone, especially the IP addresses.</t>
	ing of the Public Homenet Zone - especially the IP addresses.</t>		<t>Renumbering has been extensively described in <xref target="RFC4192"/>
			and analyzed in <xref target="RFC7010"/>, and the reader is expected to be famil
	<t>Renumbering has been extensively described in <xref target="RFC4192"/> and an		iar with them before reading this section.
	alyzed in <xref target="RFC7010"/> and the reader is expected to be familiar wit		In the make-before-break renumbering scenario, the new prefix is advertised, and
	h them before reading this section.		the network is configured to prepare the transition to the new prefix. During a
	In the make-before-break renumbering scenario, the new prefix is advertised, the		period of time, the two prefixes (old and new) coexist before the old prefix is
	network is configured to prepare the transition to the new prefix.		completely removed. New resource records containing the new prefix <bcp14>SHOUL
	During a period of time, the two prefixes old and new coexist, before the old pr		D</bcp14> be published, while the old resource records with the old prefixes <bc
	efix is completely		p14>SHOULD</bcp14> be withdrawn. If the HNA anticipates that the period of overl
	removed.		ap will be long (perhaps due to the knowledge of router and DHCPv6 lifetimes), i
	New resources records containing the new prefix SHOULD be published, while the o		t <bcp14>MAY</bcp14> publish the old prefixes with a significantly lower TTL.</t
	ld resource records with the old prefixes SHOULD be withdrawn.		>
	If the HNA anticipates that period of overlap is long (perhaps due to knowledge		<t>In break-before-make renumbering scenarios, including flash renumbering
	of router and DHCPv6 lifetimes), it MAY publish the old prefixes with a signific		scenarios <xref target="RFC8978"/>, the old prefix becomes unusable before the
	antly lower time to live.</t>		new prefix is known or advertised.
	<t>In break-before-make renumbering scenarios, including flash renumbering scena
	rios <xref target="RFC8978"/>, the old prefix becomes unuseable before the new p
	refix is known or advertised.
	As explained in <xref target="RFC8978"/>, some flash renumberings occur due to p ower cycling of the HNA, where ISPs do not properly remember what prefixes have been assigned to which user.</t>		As explained in <xref target="RFC8978"/>, some flash renumberings occur due to p ower cycling of the HNA, where ISPs do not properly remember what prefixes have been assigned to which user.</t>
			<t>An HNA that boots up <bcp14>MUST</bcp14> immediately use the Control Ch
	<t>An HNA that boots up MUST immediately use the Control Channel to update the l		annel to update the location for the Synchronization Channel. This is a reasonab
	ocation for the Synchronization Channel.		le thing to do on every boot, as the HNA has no idea how long it has been offlin
	This is a reasonable thing to do on every boot, as the HNA has no idea how long		e or if the (DNSSEC) zone has perhaps expired during the time the HNA was powere
	it has been offline, or if the (DNSSEC) zone has perhaps expired during the time		d off.</t>
	the HNA was powered off.</t>		<t>The HNA will have a list of names that should be published, but it migh
			t not yet have IP addresses for those devices. This could be because at the time
	<t>The HNA will have a list of names that should be published, but it might not		of power on, the other devices were not yet online.
	yet have IP addresses for those devices.
	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>Although the new and old IP addresses may be stored in the Public Homen
	<t>Although the new and old IP addresses may be stored in the Public Homenet Zon		et Zone, it is <bcp14>RECOMMENDED</bcp14> that only the newly reachable IP addre
	e, it is RECOMMENDED that only the newly reachable IP addresses be published.</t		sses be published.</t>
	>		<t>Regarding the Public Homenet Reverse Zone, the new Public Homenet Rever
			se Zone has to be populated as soon as possible, and the old Public Homenet Reve
	<t>Regarding the Public Homenet Reverse Zone, the new Public Homenet Reverse Zon		rse Zone will be deleted by the owner of the zone (and the owner of the old pref
	e has to be populated as soon as possible, and the old Public Homenet Reverse Zo		ix, which is usually the ISP) once the prefix is no longer assigned to the HNA.
	ne will be deleted by the owner of the zone (and the owner of the old prefix whi		The ISP <bcp14>MUST</bcp14> ensure that the DNS cache has expired before reassig
	ch is usually the ISP) once the prefix is no longer assigned to the HNA.		ning the prefix to a new home network.
	The ISP MUST ensure that the DNS cache has expired before re-assigning the prefi
	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>To avoid reachability disruption, IP connectivity information provided
	<t>To avoid reachability disruption, IP connectivity information provided by the		by the DNS <bcp14>MUST</bcp14> be coherent with the IP in use.
	DNS MUST be coherent with the IP in use.		In our case, this means the old IP address <bcp14>MUST NOT</bcp14> be provided v
	In our case, this means the old IP address MUST NOT be provided via the DNS when		ia the DNS when it is not reachable anymore.</t>
	it is not reachable anymore.</t>		<t>In the make-before-break scenario, it is possible to make the transitio
			n seamless.
	<t>In the make-before-break scenario, it is possible to make the transition seam		Let T be the TTL associated with an RRset of the Public Homenet Zone;
	less.		Time_NEW be the time the new IP address replaces the old IP address in the Homen
	Let T be the TTL associated with a RRset of the Public Homenet Zone.		et Zone; and Time_OLD_UNREACHABLE be the time the old IP will not be reachable a
	Let Time_NEW be the time the new IP address replaces the old IP address in the H		nymore.</t>
	omenet Zone, and Time_OLD_UNREACHABLE the time the old IP will not be reachable		<t>In the case of the make-before-break scenario, seamless reachability is
	anymore.</t>		provided as long as Time_OLD_UNREACHABLE - T_NEW &gt; (2 * T).
	<t>In the case of the make-before-break, seamless reachability is provided as lo
	ng as Time_OLD_UNREACHABLE - T_NEW &gt; (2 * T).
	If this is not satisfied, then devices associated with the old IP address in the home network may become unreachable for 2 * T - (Time_OLD_UNREACHABLE - Time_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>In the case of a break-before-make scenario, Time_OLD_UNREACHABLE = Tim
	<t>In the case of a break-before-make, Time_OLD_UNREACHABLE = Time_NEW, and the		e_NEW, and the device may become unreachable up to 2 * T.
	device may become unreachable up to 2 * T.		Of course, if Time_NEW &gt;= Time_OLD_UNREACHABLE, then the outage is not seamle
	Of course if Time_NEW &gt;= Time_OLD_UNREACHABLE, then then outage is not seamle		ss.</t>
	ss.</t>		</section>
			<section anchor="sec-privacy">
	</section>		<name>Privacy Considerations</name>
	<section anchor="sec-privacy"><name>Privacy Considerations</name>		<t>Outsourcing the DNS Authoritative service from the HNA to a third party
			raises a few privacy-related concerns.</t>
	<t>Outsourcing the DNS Authoritative service from the HNA to a third party raise		<t>The Public Homenet Zone lists the names of services hosted in the home
	s a few privacy related concerns.</t>		network.
			Combined with blocking of AXFR queries, the use of NSEC3 <xref target="RFC5155"/
	<t>The Public Homenet Zone lists the names of services hosted in the home networ		> (vs.&nbsp;NSEC <xref target="RFC4034"/>) prevents an attacker from being able
	k.		to walk the zone to discover all the names.
	Combined with blocking of AXFR queries, the use of NSEC3 <xref target="RFC5155"/		However, recent work <xref target="GPUNSEC3"/> <xref target="ZONEENUM"/> has sho
	> (vs NSEC <xref target="RFC4034"/>) prevents an attacker from being able to wa		wn that the protection provided by NSEC3 against dictionary attacks should be co
	lk the zone, to discover all the names.		nsidered cautiously, and <xref target="RFC9276"/> provides guidelines to configu
	However, recent work <xref target="GPUNSEC3"/> or <xref target="ZONEENUM"/> have		re NSEC3 properly. In addition, the attacker may be able to walk the reverse DNS
	shown that the protection provided by NSEC3 against dictionary attacks should b		zone or use other reconnaissance techniques to learn this information as descri
	e considered cautiously and <xref target="RFC9276"/> provides guidelines to conf		bed in <xref target="RFC7707"/>.</t>
	igure NSEC3 properly.		<t>The zone may be also exposed during the synchronization between the primary a
	In addition, the attacker may be able to walk the reverse DNS zone, or use other		nd the secondary. The casual risk of this occurring is low, and the use of <xref
	reconnaissance techniques to learn this information as described in <xref targe		target="RFC9103"/> significantly reduces this. Even if DNS zone transfer over T
	t="RFC7707"/>.</t>		LS <xref target="RFC9103"/> is used by the DOI, it may still leak the existence
			of the zone through Notifies. The protocol described in this document does not i
	<t>The zone may be also exposed during the synchronization between the primary a		ncrease that risk, as all Notifies use the encrypted Control Channel.</t>
	nd the secondary.		<t>In general, a home network owner is expected to publish only names for which
	The casual risk of this occuring is low, and the use of <xref target="RFC9103"/>		there is some need to reference them externally. Publication of the name does no
	significantly reduces this.		t imply that the service is necessarily reachable from any or all parts of the I
	Even if <xref target="RFC9103"/> is used by the DNS Outsourcing Infrastructure,		nternet. <xref target="RFC7084"/> mandates that the outgoing-only policy <xref t
	it may still leak the existence of the zone through Notifies.		arget="RFC6092"/> be available, and in many cases, it is configured by default.
	The protocol described in this document does not increase that risk, as all Noti		A well-designed user interface would combine a policy for making a service publi
	fies use the encrypted Control Channel.</t>		c by a name with a policy on who may access it.</t>
			<t>In many cases, and for privacy reasons, the home network owner has want
	<t>In general a home network owner is expected to publish only names for which t		ed to publish names only for services that they will be able to access. The acce
	here is some need to be able to reference externally.		ss control may consist of an IP source address range, or access may be restricte
	Publication of the name does not imply that the service is necessarily reachable		d via some VPN functionality. The main advantages of publishing the names are th
	from any or all parts of the Internet.		at the service may be accessed by the same name both within and outside the home
	<xref target="RFC7084"/> mandates that the outgoing-only policy <xref target="RF		, and the DNS resolution can be handled similarly both within and outside the ho
	C6092"/> be available, and in many cases it is configured by default.		me. This considerably eases the ability to use VPNs where the VPN can be chosen
	A well designed User Interface would combine a policy for making a service publi		according to the IP address of the service. Typically, a user may configure its
	c by a name with a policy on who may access it.</t>		device to reach its Homenet devices via a VPN while the remaining traffic is acc
			essed directly.</t>
	<t>In many cases, and for privacy reasons, the home network owner wished publish		<t>Enterprise networks have generally adopted another strategy designated
	names only for services that they will be able to access.		as split-horizon-DNS. While such strategy might appear as providing more privacy
	The access control may consist of an IP source address range, or access may be r		at first sight, its implementation remains challenging and the privacy advantag
	estricted via some VPN functionality.		es need to be considered carefully. In split-horizon-DNS, names are designated w
	The main advantages of publishing the name are that service may be access by the		ith internal names that can only be resolved within the corporate network. When
	same name both within the home and outside the home and that the DNS resolution		such strategy is applied to the homenet, VPNs need to be configured with naming
	can be handled similarly within the home and outside the home.		resolution policies and routing policies. Such an approach might be reasonable w
	This considerably eases the ability to use VPNs where the VPN can be chosen acco		ith a single VPN, but maintaining a coherent DNS space and IP space among variou
	rding to the IP address of the service.		s VPNs comes with serious complexities. Firstly, if multiple homenets are using
	Typically, a user may configure its device to reach its homenet devices via a VP		the same domain name -- like home.arpa -- it becomes difficult to determine on w
	N while the remaining of the traffic is accessed directly.</t>		hich network the resolution should be performed. As a result, homenets should at
			least be differentiated by a domain name. Secondly, the use of split-horizon-DN
	<t>Enterprise networks have generally adopted another strategy designated as spl		S requires each VPN to be associated with a resolver and specific resolutions to
	it-horizon-DNS.		be performed by the dedicated resolver. Such policies can easily raise some con
	While such strategy might appear as providing more privacy at first sight, its i		flicts (with significant privacy issues) while remaining hard to be implemented.
	mplementation remains challenging and the privacy advantages needs to be conside		</t>
	red carefully.		<t>In addition to the Public Homenet Zone, pervasive DNS monitoring can al
	In split-horizon-DNS, names are designated with internal names that can only be		so monitor the traffic associated with the Public Homenet Zone.
	resolved within the corporate network.		This traffic may provide an indication of the services an end user accesses, plu
	When such strategy is applied to homenet, VPNs needs to be both configured with		s how and when they use these services. Although, caching may obfuscate this inf
	a naming resolution policies and routing policies.		ormation inside the home network, it is likely that this information will not be
	Such approach might be reasonable with a single VPN, but maintaining a coherent		cached outside the home network.</t>
	DNS space and IP space among various VPNs comes with serious complexities.		</section>
	Firstly, if multiple homenets are using the same domain name -- like home.arpa -		<section anchor="sec-security">
	- it becomes difficult to determine on which network the resolution should be pe		<name>Security Considerations</name>
	rformed.		<t>The HNA never answers DNS requests from the Internet.
	As a result, homenets should at least be differentiated by a domain name.
	Secondly, the use of split-horizon-DNS requires each VPN being associated with a
	resolver and specific resolutions being performed by the dedicated resolver.
	Such policies can easily raises some conflicts (with significant privacy issues)
	while remaining hard to be implemented.</t>
	<t>In addition to the Public Homenet Zone, pervasive DNS monitoring can also mon
	itor the traffic associated with the Public Homenet Zone.
	This traffic may provide an indication of the services an end user accesses, plu
	s how and when they use these services.
	Although, caching may obfuscate this information inside the home network, it is
	likely that outside your home network this information will not be cached.</t>
	</section>
	<section anchor="sec-security"><name>Security Considerations</name>
	<t>The HNA never answers DNS requests from the Internet.
	These requests are instead served by the DOI.</t>		These requests are instead served by the DOI.</t>
			<t>While this limits the level of exposure of the HNA, the HNA still has s
	<t>While this limits the level of exposure of the HNA, the HNA still has some ex		ome 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">
	<section anchor="registered-homenet-domain"><name>Registered Homenet Domain</nam		<name>Registered Homenet Domain</name>
	e>		<t>The DOI <bcp14>MUST NOT</bcp14> serve any Public Homenet Zone when it
			is not confident that the HNA owns the Registered Homenet Domain.
	<t>The DOI MUST NOT serve any Public Homenet Zone that it has not strong confide		Proof of ownership is outside the scope of this document, and it is assumed that
	nce the HNA owns the Registered Homenet Domain.		such a phase has preceded the outsourcing of the zone.</t>
	Proof of ownership is outside the document and is assumed such phase has precede		</section>
	d the outsourcing of the zone.</t>		<section anchor="hna-dm-channels">
			<name>HNA DM Channels</name>
	</section>		<t>The channels between HNA and DM are mutually authenticated and encryp
	<section anchor="hna-dm-channels"><name>HNA DM channels</name>		ted with TLS <xref target="RFC8446"/>, and its associated security consideration
			s apply.</t>
	<t>The channels between HNA and DM are mutually authenticated and encrypted with		<t>To ensure that the multiple TLS sessions are continuously authenticat
	TLS <xref target="RFC8446"/> and its associated security considerations apply.<		ing the same entity, TLS may take advantage of second-factor authentication as d
	/t>		escribed in <xref target="RFC8672"/> for the TLS server certificate for the Cont
			rol Channel. The HNA should also cache the TLS server certificate used by the DM
	<t>To ensure the multiple TLS session are continuously authenticating the same e		, in order to authenticate the DM during the setup of the Synchronization Channe
	ntity, TLS may take advantage of second factor authentication as described in <x		l. (Alternatively, the HNA is configured with an ACL from which Synchronization
	ref target="RFC8672"/> for the TLS server certificate for the Control Channel.		Channel connections will originate.)</t>
	The HNA should also cache the TLS server certificate used by the DM, in order to		<t>The Control Channel and Synchronization Channel follow the guidelines
	authenticate the DM during the setup of the Synchronization Channel.		in <xref target="RFC7858"/> and <xref target="RFC9103"/>, respectively.</t>
	(Alternatively, the HNA is configured with an ACL from which Synchronization Cha		<t>The DNS protocol is subject to reflection attacks; however, these att
	nnel connections will originate)</t>		acks are largely applicable when DNS is carried over UDP. The interfaces between
			the HNA and DM are using TLS over TCP, which prevents such reflection attacks.
	<t>The Control Channel and the Synchronization Channel respectively follow <xref		Note that Public Authoritative servers hosted by the DOI are subject to such att
	target="RFC7858"/> and <xref target="RFC9103"/> guidelines.</t>		acks, but that is out of scope of this document.</t>
			<t>Note that in the case of the Reverse Homenet Zone, the data is less s
	<t>The DNS protocol is subject to reflection attacks, however, these attacks are		ubject to attacks than in the Public Homenet Zone. In addition, the DM and Rever
	largely applicable when DNS is carried over UDP.		se Distribution Manager (RDM) may be provided by the ISP -- as described in <xre
	The interfaces between the HNA and DM are using TLS over TCP, which prevents suc		f target="RFC9527"/>, in which case DM and RDM might be less exposed to attacks
	h reflection attacks.		-- as communications within a network.</t>
	Note that Public Authoritative servers hosted by the DOI are subject to such att		</section>
	acks, but that is out of scope of our document.</t>		<section anchor="sec-name-less-secure">
			<name>Names Are Less Secure than IP Addresses</name>
	<t>Note that in the case of the Reverse Homenet Zone, the data is less subject t		<t>This document describes how an end user can make their services and d
	o attacks than in the Public Homenet Zone.		evices from their home network reachable on the Internet by using names rather t
	In addition, the DM and Reverse Distribution Manager (RDM) may be provided by th		han IP addresses.
	e ISP - as described in <xref target="I-D.ietf-homenet-naming-architecture-dhc-o		This exposes the home network to attackers because names are expected to
	ptions"/>, in which case DM and RDM might be less exposed to attacks - as commun		include less entropy than IP addresses. IPv4 addresses are 4-bytes long leading
	ications within a network.</t>		to 2<sup>32</sup> possibilities.
			With IPv6 addresses, the Interface Identifier is 64-bits long leading to up to 2
	</section>		<sup>64</sup> possibilities for a given subnetwork. This is not to mention that
	<section anchor="sec-name-less-secure"><name>Names are less secure than IP addre		the subnet prefix is also 64-bits long, thus providing up to 2<sup>64</sup> pos
	sses</name>		sibilities. On the other hand, names used for either the home network domain or
			the devices present less entropy (livebox, router, printer, nicolas, jennifer, .
	<t>This document describes how an end user can make their services and devices f		..) and thus potentially expose the devices to dictionary attacks.</t>
	rom their home network reachable on the Internet by using names rather than IP a		</section>
	ddresses.		<section anchor="sec-name-less-volatile">
	This exposes the home network to attackers, since names are expected to include		<name>Names Are Less Volatile than IP Addresses</name>
	less entropy than IP addresses.		<t>IP addresses may be used to locate a device, a host, or a service.
	IPv4 Addresses are 4 bytes long leading to 2**32 possibilities.		However, home networks are not expected to be assigned a time-invariant prefix b
	With IPv6 addresses, the Interface Identifier is 64 bits long leading to up to 2		y ISPs. In addition, IPv6 enables temporary addresses that makes them even more
	^64 possibilities for a given subnetwork.		volatile <xref target="RFC8981"/>. As a result, observing IP addresses only prov
	This is not to mention that the subnet prefix is also of 64 bits long, thus prov		ides some ephemeral information about who is accessing the service. On the other
	iding up to 2^64 possibilities.		hand, names are not expected to be as volatile as IP addresses. As a result, lo
	On the other hand, names used either for the home network domain or for the devi		gging names over time may be more valuable than logging IP addresses, especially
	ces present less entropy (livebox, router, printer, nicolas, jennifer, ...) and		to profile an end user's characteristics.</t>
	thus potentially exposes the devices to dictionary attacks.</t>		<t>PTR provides a way to bind an IP address to a name.
	</section>
	<section anchor="sec-name-less-volatile"><name>Names are less volatile than IP a
	ddresses</name>
	<t>IP addresses may be used to locate a device, a host or a service.
	However, home networks are not expected to be assigned a time invariant prefix b
	y ISPs. In addition IPv6 enables temporary addresses that makes them even more v
	olatile <xref target="RFC8981"/>.
	As a result, observing IP addresses only provides some ephemeral information abo
	ut who is accessing the service.
	On the other hand, names are not expected to be as volatile as IP addresses.
	As a result, logging names over time may be more valuable than logging IP addres
	ses, especially to profile an end user's characteristics.</t>
	<t>PTR provides a way to bind an IP address to a name.
	In that sense, responding to PTR DNS queries may affect the end user's privacy.		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">
	<section anchor="deployment-considerations"><name>Deployment Considerations</nam		<name>Deployment Considerations</name>
	e>		<t>The HNA is expected to sign the DNSSEC zone and, as such, hold the pr
			ivate KSK and Zone Signing Key (ZSK).</t>
	<t>The HNA is expected to sign the DNSSEC zone and as such hold the private KSK/		<t>In this case, there is no strong justification to use a separate KSK
	ZSK.</t>		and ZSK.
			If an attacker can get access to one of them, it is likely that they will access
	<t>There is no strong justification in this case to use a separate KSK and ZSK.		both of them.
	If an attacker can get access to one of them, it likely that they will access bo		If the HNA is run in a home router with a secure element (SE) or trusted platfor
	th of them.		m module (TPM), storing the private keys in the secure element would be a useful
	If the HNA is run in a home router with a secure element (SE) or TPM, storing th		precaution. The DNSSEC keys are generally needed on an hourly to weekly basis,
	e private keys in the secure element would be a useful precaution.		but not more often.</t>
	The DNSSEC keys are generally needed on an hourly to weekly basis, but not more		<t>While there is some risk that the DNSSEC keys might be disclosed by m
	often.</t>		alicious parties, the bigger risk is that they will simply be lost if the home r
			outer is factory reset or just thrown out / replaced with a newer model.</t>
	<t>While there is some risk that the DNSSEC keys might be disclosed by malicious		<t>Generating new DNSSEC keys is relatively easy; they can be deployed u
	parties, the bigger risk is that they will simply be lost if the home router is		sing the Control Channel to the DM.
	factory reset, or just thrown out/replaced with a newer model.</t>		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
	<t>Generating new DNSSEC keys is relatively easy, they can be deployed using the		key).</t>
	Control Channel to the DM.		</section>
	The key that is used to authenticate that connection is the critical key that ne		<section anchor="operational-considerations">
	eds protection, and should ideally be backed up to offline storage. (Such as a U		<name>Operational Considerations</name>
	SB key)</t>		<t>Homenet technologies make it easier to expose devices and services to
			the
	</section>
	<section anchor="operational-considerations"><name>Operational Considerations</n
	ame>
	<t>HomeNet technologies makes it easier to 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">
	<t><list style="symbols">		<li>The home network operator must carefully assess whether a device o
	<t>The home network operator must carefully assess whether a device or service		r 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>The home network operator will need to increase the diligence to r
			egularly
	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>Depending on the operational practices of the home network operato
			rs, 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">
	<section anchor="iana-considerations"><name>IANA Considerations</name>		<name>IANA Considerations</name>
			<t>This document has no IANA actions.</t>
	<t>This document has no actions for IANA.</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>
	<references title='Normative References'>		<displayreference target="I-D.ietf-dnsop-domain-verification-techniques" to="DOM
			AIN-VALIDATION"/>
	<reference anchor='RFC2119'>		<displayreference target="I-D.ietf-dnsop-dnssec-validator-requirements" to="DRO-
	<front>		RECS"/>
	<title>Key words for use in RFCs to Indicate Requirement Levels</title>		<displayreference target="I-D.ietf-dnsop-ns-revalidation" to="NS-REVALIDATION"/>
	<author fullname='S. Bradner' initials='S.' surname='Bradner'><organization/></a		<displayreference target="I-D.richardson-homerouter-provisioning" to="HOMEROUTER
	uthor>		-PROVISION"/>
	<date month='March' year='1997'/>
	<abstract><t>In many standards track documents several words are used to signify
	the requirements in the specification. These words are often capitalized. This
	document defines these words as they should be interpreted in IETF documents.
	This document specifies an Internet Best Current Practices for the Internet Comm
	unity, and requests discussion and suggestions for improvements.</t></abstract>
	</front>
	<seriesInfo name='BCP' value='14'/>
	<seriesInfo name='RFC' value='2119'/>
	<seriesInfo name='DOI' value='10.17487/RFC2119'/>
	</reference>
	<reference anchor='RFC8174'>
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
	<author fullname='B. Leiba' initials='B.' surname='Leiba'><organization/></autho
	r>
	<date month='May' year='2017'/>
	<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
	pecifications. This document aims to reduce the ambiguity by clarifying that on
	ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
	tract>
	</front>
	<seriesInfo name='BCP' value='14'/>
	<seriesInfo name='RFC' value='8174'/>
	<seriesInfo name='DOI' value='10.17487/RFC8174'/>
	</reference>
	<reference anchor='RFC8375'>
	<front>
	<title>Special-Use Domain 'home.arpa.'</title>
	<author fullname='P. Pfister' initials='P.' surname='Pfister'><organization/></a
	uthor>
	<author fullname='T. Lemon' initials='T.' surname='Lemon'><organization/></autho
	r>
	<date month='May' year='2018'/>
	<abstract><t>This document specifies the behavior that is expected from the Doma
	in Name System with regard to DNS queries for names ending with '.home.arpa.' an
	d designates this domain as a special-use domain name. 'home.arpa.' is designate
	d for non-unique use in residential home networks. The Home Networking Control
	Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.</t
	></abstract>
	</front>
	<seriesInfo name='RFC' value='8375'/>
	<seriesInfo name='DOI' value='10.17487/RFC8375'/>
	</reference>
	<reference anchor='RFC1918'>
	<front>
	<title>Address Allocation for Private Internets</title>
	<author fullname='Y. Rekhter' initials='Y.' surname='Rekhter'><organization/></a
	uthor>
	<author fullname='B. Moskowitz' initials='B.' surname='Moskowitz'><organization/
	></author>
	<author fullname='D. Karrenberg' initials='D.' surname='Karrenberg'><organizatio
	n/></author>
	<author fullname='G. J. de Groot' initials='G. J.' surname='de Groot'><organizat
	ion/></author>
	<author fullname='E. Lear' initials='E.' surname='Lear'><organization/></author>
	<date month='February' year='1996'/>
	<abstract><t>This document describes address allocation for private internets.
	This document specifies an Internet Best Current Practices for the Internet Comm
	unity, and requests discussion and suggestions for improvements.</t></abstract>
	</front>
	<seriesInfo name='BCP' value='5'/>
	<seriesInfo name='RFC' value='1918'/>
	<seriesInfo name='DOI' value='10.17487/RFC1918'/>
	</reference>
	<reference anchor='RFC8499'>
	<front>
	<title>DNS Terminology</title>
	<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
	uthor>
	<author fullname='A. Sullivan' initials='A.' surname='Sullivan'><organization/><
	/author>
	<author fullname='K. Fujiwara' initials='K.' surname='Fujiwara'><organization/><
	/author>
	<date month='January' year='2019'/>
	<abstract><t>The Domain Name System (DNS) is defined in literally dozens of diff
	erent RFCs. The terminology used by implementers and developers of DNS protocol
	s, and by operators of DNS systems, has sometimes changed in the decades since t
	he DNS was first defined. This document gives current definitions for many of t
	he terms used in the DNS in a single document.</t><t>This document obsoletes RFC
	7719 and updates RFC 2308.</t></abstract>
	</front>
	<seriesInfo name='BCP' value='219'/>
	<seriesInfo name='RFC' value='8499'/>
	<seriesInfo name='DOI' value='10.17487/RFC8499'/>
	</reference>
	<reference anchor='RFC7858'>
	<front>
	<title>Specification for DNS over Transport Layer Security (TLS)</title>
	<author fullname='Z. Hu' initials='Z.' surname='Hu'><organization/></author>
	<author fullname='L. Zhu' initials='L.' surname='Zhu'><organization/></author>
	<author fullname='J. Heidemann' initials='J.' surname='Heidemann'><organization/
	></author>
	<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></aut
	hor>
	<author fullname='D. Wessels' initials='D.' surname='Wessels'><organization/></a
	uthor>
	<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
	uthor>
	<date month='May' year='2016'/>
	<abstract><t>This document describes the use of Transport Layer Security (TLS) t
	o provide privacy for DNS. Encryption provided by TLS eliminates opportunities
	for eavesdropping and on-path tampering with DNS queries in the network, such as
	discussed in RFC 7626. In addition, this document specifies two usage profiles
	for DNS over TLS and provides advice on performance considerations to minimize
	overhead from using TCP and TLS with DNS.</t><t>This document focuses on securin
	g stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It
	does not prevent future applications of the protocol to recursive-to-authoritat
	ive traffic.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7858'/>
	<seriesInfo name='DOI' value='10.17487/RFC7858'/>
	</reference>
	<reference anchor='RFC9103'>
	<front>
	<title>DNS Zone Transfer over TLS</title>
	<author fullname='W. Toorop' initials='W.' surname='Toorop'><organization/></aut
	hor>
	<author fullname='S. Dickinson' initials='S.' surname='Dickinson'><organization/
	></author>
	<author fullname='S. Sahib' initials='S.' surname='Sahib'><organization/></autho
	r>
	<author fullname='P. Aras' initials='P.' surname='Aras'><organization/></author>
	<author fullname='A. Mankin' initials='A.' surname='Mankin'><organization/></aut
	hor>
	<date month='August' year='2021'/>
	<abstract><t>DNS zone transfers are transmitted in cleartext, which gives attack
	ers the opportunity to collect the content of a zone by eavesdropping on network
	connections. The DNS Transaction Signature (TSIG) mechanism is specified to res
	trict direct zone transfer to authorized clients only, but it does not add confi
	dentiality. This document specifies the use of TLS, rather than cleartext, to pr
	event zone content collection via passive monitoring of zone transfers: XFR over
	TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with
	respect to efficient use of TCP connections and RFC 7766 with respect to the rec
	ommended number of connections between a client and server for each transport.</
	t></abstract>
	</front>
	<seriesInfo name='RFC' value='9103'/>
	<seriesInfo name='DOI' value='10.17487/RFC9103'/>
	</reference>
	<reference anchor='RFC7344'>
	<front>
	<title>Automating DNSSEC Delegation Trust Maintenance</title>
	<author fullname='W. Kumari' initials='W.' surname='Kumari'><organization/></aut
	hor>
	<author fullname='O. Gudmundsson' initials='O.' surname='Gudmundsson'><organizat
	ion/></author>
	<author fullname='G. Barwood' initials='G.' surname='Barwood'><organization/></a
	uthor>
	<date month='September' year='2014'/>
	<abstract><t>This document describes a method to allow DNS Operators to more eas
	ily update DNSSEC Key Signing Keys using the DNS as a communication channel. Th
	e technique described is aimed at delegations in which it is currently hard to m
	ove information from the Child to Parent.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='7344'/>
	<seriesInfo name='DOI' value='10.17487/RFC7344'/>
	</reference>
	<reference anchor='RFC8446'>
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
	<author fullname='E. Rescorla' initials='E.' surname='Rescorla'><organization/><
	/author>
	<date month='August' year='2018'/>
	<abstract><t>This document specifies version 1.3 of the Transport Layer Security
	(TLS) protocol. TLS allows client/server applications to communicate over the
	Internet in a way that is designed to prevent eavesdropping, tampering, and mess
	age forgery.</t><t>This document updates RFCs 5705 and 6066, and obsoletes RFCs
	5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2
	implementations.</t></abstract>
	</front>
	<seriesInfo name='RFC' value='8446'/>
	<seriesInfo name='DOI' value='10.17487/RFC8446'/>
	</reference>
	<reference anchor='RFC1034'>
	<front>
	<title>Domain names - concepts and facilities</title>
	<author fullname='P. Mockapetris' initials='P.' surname='Mockapetris'><organizat
	ion/></author>
	<date month='November' year='1987'/>
	<abstract><t>This RFC is the revised basic definition of The Domain Name System.
	It obsoletes RFC-882. This memo describes the domain style names and their us
	ed for host address look up and electronic mail forwarding. It discusses the cl
	ients and servers in the domain name system and the protocol used between them.<
	/t></abstract>
	</front>
	<seriesInfo name='STD' value='13'/>
	<seriesInfo name='RFC' value='1034'/>
	<seriesInfo name='DOI' value='10.17487/RFC1034'/>
	</reference>
	<reference anchor='RFC3007'>		<references>
	<front>		<name>References</name>
	<title>Secure Domain Name System (DNS) Dynamic Update</title>		<references>
	<author fullname='B. Wellington' initials='B.' surname='Wellington'><organizatio		<name>Normative References</name>
	n/></author>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<date month='November' year='2000'/>		119.xml"/>
	<abstract><t>This document proposes a method for performing secure Domain Name S		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ystem (DNS) dynamic updates. [STANDARDS-TRACK]</t></abstract>		174.xml"/>
	</front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<seriesInfo name='RFC' value='3007'/>		375.xml"/>
	<seriesInfo name='DOI' value='10.17487/RFC3007'/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
	</reference>		918.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			499.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			858.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			103.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			344.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			446.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
			034.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
			007.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
			996.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
			155.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
			034.xml"/>
	<reference anchor='I-D.ietf-uta-rfc6125bis'>		<!-- [I-D.ietf-uta-rfc6125bis] is now RFC 9525 -->
	<front>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<title>Service Identity in TLS</title>		525.xml"/>
	<author fullname='Peter Saint-Andre' initials='P.' surname='Saint-Andre'>
	<organization>independent</organization>
	</author>
	<author fullname='Rich Salz' initials='R.' surname='Salz'>
	<organization>Akamai Technologies</organization>
	</author>
	<date day='25' month='January' year='2023'/>
	<abstract>
	<t> Many application technologies enable secure communication between
	two
	entities by means of Transport Layer Security (TLS) with Internet
	Public Key Infrastructure Using X.509 (PKIX) certificates. This
	document specifies procedures for representing and verifying the
	identity of application services in such interactions.
	This document obsoletes RFC 6125.		</references>
			<references>
			<name>Informative References</name>
	</t>		<reference anchor="GPUNSEC3" target="https://doi.org/10.1109/NCA.2014.27
	</abstract>		">
	</front>		<front>
	<seriesInfo name='Internet-Draft' value='draft-ietf-uta-rfc6125bis-10'/>		<title>GPU-Based NSEC3 Hash Breaking</title>
			<author initials="M." surname="Wander">
			<organization/>
			</author>
			<author initials="L." surname="Schwittmann">
			<organization/>
			</author>
			<author initials="C." surname="Boelmann">
			<organization/>
			</author>
			<author initials="T." surname="Weis">
			<organization/>
			</author>
			<date month="August" year="2014"/>
			</front>
			<seriesInfo name="DOI" value="10.1109/NCA.2014.27" />
			</reference>
	</reference>		<reference anchor="ZONEENUM">
			<front>
			<title>An efficient DNSSEC zone enumeration algorithm</title>
			<author initials="Z." surname="Wang">
			<organization/>
			</author>
			<author initials="L." surname="Xiao">
			<organization/>
			</author>
			<author initials="R." surname="Wang">
			<organization/>
			</author>
			<date month="April" year="2014"/>
			</front>
			<seriesInfo name="DOI" value="10.2495/MIIT130591" />
			</reference>
	<reference anchor='RFC1996'>		<reference anchor="REBIND" target="https://en.wikipedia.org/w/index.php?
	<front>		title=DNS_rebinding&amp;oldid=1173433859">
	<title>A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)</title>		<front>
	<author fullname='P. Vixie' initials='P.' surname='Vixie'><organization/></autho		<title>DNS rebinding</title>
	r>		<author>
	<date month='August' year='1996'/>		<organization>Wikipedia</organization>
	<abstract><t>This memo describes the NOTIFY opcode for DNS, by which a master se		</author>
	rver advises a set of slave servers that the master's data has been changed and		<date month="September" year="2023"/>
	that a query should be initiated to discover the new data. [STANDARDS-TRACK]</t>		</front>
	</abstract>		</reference>
	</front>
	<seriesInfo name='RFC' value='1996'/>
	<seriesInfo name='DOI' value='10.17487/RFC1996'/>
	</reference>
	<reference anchor='RFC5155'>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<front>		762.xml"/>
	<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname='B. Laurie' initials='B.' surname='Laurie'><organization/></aut		415.xml"/>
	hor>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<author fullname='G. Sisson' initials='G.' surname='Sisson'><organization/></aut		887.xml"/>
	hor>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></aut		587.xml"/>
	hor>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<author fullname='D. Blacka' initials='D.' surname='Blacka'><organization/></aut		193.xml"/>
	hor>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	<date month='March' year='2008'/>		291.xml"/>
	<abstract><t>The Domain Name System Security (DNSSEC) Extensions introduced the		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	NSEC resource record (RR) for authenticated denial of existence. This document i		404.xml"/>
	ntroduces an alternative resource record, NSEC3, which similarly provides authen		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	ticated denial of existence. However, it also provides measures against zone en		927.xml"/>
	umeration and permits gradual expansion of delegation-centric zones. [STANDARDS
	-TRACK]</t></abstract>
	</front>
	<seriesInfo name='RFC' value='5155'/>
	<seriesInfo name='DOI' value='10.17487/RFC5155'/>
	</reference>
	<reference anchor='RFC4034'>		<!-- [I-D.ietf-homenet-naming-architecture-dhc-options] companion document RFC 9
			527 -->
			<reference anchor="RFC9527" target="https://www.rfc-editor.org/info/rfc9527">
	<front>		<front>
	<title>Resource Records for the DNS Security Extensions</title>		<title>DHCPv6 Options for the Homenet Naming Authority</title>
	<author fullname='R. Arends' initials='R.' surname='Arends'><organization/></aut		<author initials='D' surname='Migault' fullname='Daniel Migault'>
	hor>		<organization />
	<author fullname='R. Austein' initials='R.' surname='Austein'><organization/></a		</author>
	uthor>		<author initials='R' surname='Weber' fullname='Ralf Weber'>
	<author fullname='M. Larson' initials='M.' surname='Larson'><organization/></aut		<organization />
	hor>		</author>
	<author fullname='D. Massey' initials='D.' surname='Massey'><organization/></aut		<author initials='T' surname='Mrugalski' fullname='Tomek Mrugalski'>
	hor>		<organization />
	<author fullname='S. Rose' initials='S.' surname='Rose'><organization/></author>		</author>
	<date month='March' year='2005'/>		<date year='2024' month='January' />
	<abstract><t>This document is part of a family of documents that describe the DN
	S Security Extensions (DNSSEC). The DNS Security Extensions are a collection of
	resource records and protocol modifications that provide source authentication
	for the DNS. This document defines the public key (DNSKEY), delegation signer (
	DS), resource record digital signature (RRSIG), and authenticated denial of exis
	tence (NSEC) resource records. The purpose and format of each resource record i
	s described in detail, and an example of each resource record is given. </t><t>
	This document obsoletes RFC 2535 and incorporates changes from all updates to RF
	C 2535. [STANDARDS-TRACK]</t></abstract>
	</front>		</front>
	<seriesInfo name='RFC' value='4034'/>		<seriesInfo name="RFC" value="9527"/>
	<seriesInfo name='DOI' value='10.17487/RFC4034'/>		<seriesInfo name="DOI" value="10.17487/RFC9527"/>
	</reference>		</reference>
	</references>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			555.xml"/>
	<references title='Informative References'>
	<reference anchor="GPUNSEC3" target="https://doi.org/10.1109/NCA.2014.27">		<!-- [I-D.ietf-dnsop-domain-verification-techniques] IESG state I-D Exist
			s as of 1/22/24; entered the long way to get the correct author initials -->
			<reference anchor="I-D.ietf-dnsop-domain-verification-techniques" target=
			"https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-tech
			niques-03">
	<front>		<front>
	<title>GPU-Based NSEC3 Hash Breaking</title>		<title>Domain Control Validation using DNS</title>
	<author initials="M." surname="Wander">		<author fullname="Shivan Kaul Sahib" initials="S." surname="Sahib">
	<organization></organization>		<organization>Brave Software</organization>
	</author>		</author>
	<author initials="L." surname="Schwittmann">		<author fullname="Shumon Huque" initials="S." surname="Huque">
	<organization></organization>		<organization>Salesforce</organization>
	</author>		</author>
	<author initials="C." surname="Boelmann">		<author fullname="Paul Wouters" initials="P." surname="Wouters">
	<organization></organization>		<organization>Aiven</organization>
	</author>		</author>
	<author initials="T." surname="Weis">		<author fullname="Erik Nygren" initials="E." surname="Nygren">
	<organization></organization>		<organization>Akamai Technologies</organization>
	</author>		</author>
	<date year="n.d."/>		<date day="17" month="October" year="2023"/>
	</front>		</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-domain-verification- techniques-03"/>
	</reference>		</reference>
	<reference anchor="ZONEENUM" >
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			788.xml"/>
			<!-- [I-D.ietf-dnsop-dnssec-validator-requirements] IESG state I-D Exist
			s: Revised I-D Needed -->
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
			.ietf-dnsop-dnssec-validator-requirements.xml"/>
			<!-- [I-D.ietf-dnsop-ns-revalidation] IESG state Expired as of 1/22/24; entered
			the long way to get the right author intials -->
			<reference anchor="I-D.ietf-dnsop-ns-revalidation" target="https://datatracker.i
			etf.org/doc/html/draft-ietf-dnsop-ns-revalidation-04">
	<front>		<front>
	<title>An efficient DNSSEC zone enumeration algorithm</title>		<title>Delegation Revalidation by DNS Resolvers</title>
	<author initials="Z." surname="Wang">		<author fullname="Shumon Huque" initials="S." surname="Huque">
	<organization></organization>		<organization>Salesforce</organization>
	</author>
	<author initials="L." surname="Xiao">
	<organization></organization>
	</author>		</author>
	<author initials="R." surname="Wang">		<author fullname="Paul A. Vixie" initials="P." surname="Vixie">
	<organization></organization>		<organization>SIE Europe, U.G.</organization>
	</author>		</author>
	<date year="n.d."/>		<author fullname="Ralph Dolmans" initials="R." surname="Dolmans">
	</front>		<organization>NLnet Labs</organization>
	</reference>
	<reference anchor="REBIND" target="https://en.wikipedia.org/wiki/DNS_rebinding">
	<front>
	<title>DNS rebinding</title>
	<author >
	<organization></organization>
	</author>		</author>
	<date year="n.d."/>		<date day="13" month="March" year="2023"/>
	</front>		</front>
			<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-ns-revalidation-04"/ >
	</reference>		</reference>
	<reference anchor='RFC6762'>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	<front>		136.xml"/>
	<title>Multicast DNS</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname='S. Cheshire' initials='S.' surname='Cheshire'><organization/><		094.xml"/>
	/author>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname='M. Krochmal' initials='M.' surname='Krochmal'><organization/><		484.xml"/>
	/author>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	<date month='February' year='2013'/>		250.xml"/>
	<abstract><t>As networked devices become smaller, more portable, and more ubiqui		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	tous, the ability to operate with less configured infrastructure is increasingly		501.xml"/>
	important. In particular, the ability to look up DNS resource record data type		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	s (including, but not limited to, host names) in the absence of a conventional m		368.xml"/>
	anaged DNS server is useful.</t><t>Multicast DNS (mDNS) provides the ability to		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	perform DNS-like operations on the local link in the absence of any conventional		011.xml"/>
	Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	namespace to be free for local use, without the need to pay any annual fee, and		192.xml"/>
	without the need to set up delegations or otherwise configure a conventional DN		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	S server to answer for those names.</t><t>The primary benefits of Multicast DNS		010.xml"/>
	names are that (i) they require little or no administration or configuration to		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	set them up, (ii) they work when no infrastructure is present, and (iii) they wo		978.xml"/>
	rk during infrastructure failures.</t></abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	</front>		276.xml"/>
	<seriesInfo name='RFC' value='6762'/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	<seriesInfo name='DOI' value='10.17487/RFC6762'/>		707.xml"/>
	</reference>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			084.xml"/>
	<reference anchor='RFC8415'>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<front>		092.xml"/>
	<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname='T. Mrugalski' initials='T.' surname='Mrugalski'><organization/		672.xml"/>
	></author>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	<author fullname='M. Siodelski' initials='M.' surname='Siodelski'><organization/		981.xml"/>
	></author>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	<author fullname='B. Volz' initials='B.' surname='Volz'><organization/></author>		749.xml"/>
	<author fullname='A. Yourtchenko' initials='A.' surname='Yourtchenko'><organizat		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ion/></author>		610.xml"/>
	<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, &quot;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
	forged.
	This document clarifies the scope and responsibilities of DNSSEC
	Resolver Operators (DRO) as well as operational recommendations that
	DNSSEC validators operators SHOULD put in place in order to implement
	sufficient trust that makes DNSSEC validation output accurate. The
	recommendations described in this document include, provisioning
	mechanisms as well as monitoring and management mechanisms.
	</t>
	</abstract>
	</front>
	<seriesInfo name='Internet-Draft' value='draft-ietf-dnsop-dnssec-validator-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 &quot;trust anchors&quot;. 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 &quot;make-before-break&quot; 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 &quot;simple security&quot; 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'>
	<front>
	<title>Provisioning Initial Device Identifiers into Home Routers</title>
	<author fullname='Michael Richardson' initials='M.' surname='Richardson'>
	<organization>Sandelman Software Works</organization>
	</author>
	<date day='14' month='November' year='2021'/>
	<abstract>
	<t> This document describes a method to provisioning an 802.1AR-style
	certificate into a router intended for use in the home.
	The proceedure results in a certificate which can be validated with a
	public trust anchor (&quot;WebPKI&quot;), using a name rather than an IP
	address. This method is focused on home routers, but can in some
	cases be used by other classes of IoT devices.
	(RFCEDITOR please remove: this document can be found at
	https://github.com/mcr/homerouter-provisioning)
	</t>
	</abstract>
	</front>
	<seriesInfo name='Internet-Draft' value='draft-richardson-homerouter-provisio
	ning-02'/>
	</reference>		<!--[I-D.richardson-homerouter-provisioning] IESG state Expired -->
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
			.richardson-homerouter-provisioning.xml"/>
			</references>
	</references>		</references>
			<section anchor="hna-channel-configurations">
	<section anchor="hna-channel-configurations"><name>HNA Channel Configurations</n		<name>HNA Channel Configurations</name>
	ame>		<section anchor="hna-provisioning">
			<name>Public Homenet Zone</name>
	<section anchor="hna-provisioning"><name>Homenet Public Zone</name>		<t>This document does not deal with how the HNA is provisioned with a tr
			usted relationship to the Distribution Manager for the forward zone.</t>
	<t>This document does not deal with how the HNA is provisioned with a trusted re		<t>This section details what needs to be provisioned into the HNA and se
	lationship to the Distribution Manager for the forward zone.</t>		rves as a requirements statement for mechanisms.</t>
			<t>The HNA needs to be provisioned with:</t>
	<t>This section details what needs to be provisioned into the HNA and serves as		<ul spacing="normal">
	a requirements statement for mechanisms.</t>		<li>the Registered Domain (e.g., myhome.example);</li>
			<li>the contact information for the DM, including the DNS name (the fu
	<t>The HNA needs to be provisioned with:</t>		lly qualified domain name (FQDN)), possibly the IP literal, and a certificate (o
			r anchor) to be used to authenticate the service;</li>
	<t><list style="symbols">		<li>the DM transport protocol and port (the default is DNS over TLS, o
	<t>the Registered Domain (e.g., myhome.example )</t>		n port 853); and</li>
	<t>the contact info for the Distribution Manager (DM), including the DNS name		<li>the HNA credentials used by the DM for its authentication.</li>
	(FQDN), possibly including the IP literal, and a certificate (or anchor) to be u		</ul>
	sed to authenticate the service</t>		<t>The HNA will need to select an IP address for communication for the S
	<t>the DM transport protocol and port (the default is DNS over TLS, on port 85		ynchronization Channel.
	3)</t>		This is typically the WAN address of the CPE, but it could be an IPv6 LAN addres
	<t>the HNA credentials used by the DM for its authentication.</t>		s in the case of a home with multiple ISPs (and multiple border routers).
	</list></t>
	<t>The HNA will need to select an IP address for communication for the Synchroni
	zation Channel.
	This is typically the WAN address of the CPE, but could be an IPv6 LAN address i
	n the case of a home with multiple ISPs (and multiple border routers).
	This is detailed in <xref target="sec-ip-hna"/> when the NS and A or AAAA RRsets are communicated.</t>		This is detailed in <xref target="sec-ip-hna"/> when the NS and A or AAAA RRsets are communicated.</t>
			<t>The above parameters <bcp14>MUST</bcp14> be provisioned for ISP-speci
	<t>The above parameters MUST be be provisioned for ISP-specific reverse zones.		fic reverse zones.
	One example of how to do this can be found in <xref target="I-D.ietf-homenet-na		One example of how to do this can be found in <xref target="RFC9527"/>.
	ming-architecture-dhc-options"/>.		ISP-specific forward zones <bcp14>MAY</bcp14> also be provisioned using <xref ta
	ISP-specific forward zones MAY also be provisioned using <xref target="I-D.ietf-		rget="RFC9527"/>, but zones that are not related to a specific ISP zone (such as
	homenet-naming-architecture-dhc-options"/>, but zones which are not related to a		with a DNS provider) must be provisioned through other means.</t>
	specific ISP zone (such as with a DNS provider) must be provisioned through oth		<t>Similarly, if the HNA is provided by a registrar, the HNA may be hand
	er means.</t>		ed preconfigured to the end user.</t>
			<t>In the absence of specific pre-established relations, these pieces of
	<t>Similarly, if the HNA is provided by a registrar, the HNA may be handed pre-c		information may be entered manually by the end user. In order to ease the confi
	onfigured to end user.</t>		guration from the end user, the following scheme may be implemented.</t>
			<t>The HNA may present the end user with a web interface that provides t
	<t>In the absence of specific pre-established relation, these pieces of informat		he end user the ability to indicate the Registered Homenet Domain or the registr
	ion may be entered manually by the end user.		ar with, for example, a preselected list.
	In order to ease the configuration from the end user the following scheme may be		Once the registrar has been selected, the HNA redirects the end user to that reg
	implemented.</t>		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.
	<t>The HNA may present the end user a web interface where it provides the end us
	er the ability to indicate the Registered Homenet Domain or the registrar for ex
	ample a preselected list.
	Once the registrar has been selected, the HNA redirects the end user to that reg
	istrar in order to receive a access token.
	The access token will enable the HNA to retrieve the DM parameters associated wi
	th 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>Such architecture limits the necessary steps to configure the HNA fro
			m the end user.</t>
			</section>
			</section>
			<section anchor="info-model">
			<name>Information Model for Outsourced Information</name>
			<t>This section specifies an optional format for the set of parameters req
			uired by the HNA to configure the naming architecture of this document.</t>
			<t>In cases where a home router has not been provisioned by the manufactur
			er (when forward zones are provided by the manufacturer) or by the ISP (when the
			ISP provides this service), then a home user/owner will need to configure these
			settings via an administrative interface.</t>
			<t>By defining a standard format (in JSON) for this configuration informat
			ion, the user/owner may be able to copy and paste a configuration blob from the
			service provider into the administrative interface of the HNA.</t>
			<t>This format may also provide the basis for a future OAuth 2.0 <xref tar
			get="RFC6749"/> flow that could do the set up automatically.</t>
	<t>Such architecture limits the necessary steps to configure the HNA from the en		<t>The HNA needs to be configured with the following parameters as describ
	d user.</t>		ed by the Concise Data Definition Language (CDDL) <xref target="RFC8610"/>. The
			se parameters are necessary to establish a secure channel between the HNA and th
	</section>		e DM as well as to specify the DNS zone that is in the scope of the communicatio
	</section>		n.</t>
	<section anchor="info-model"><name>Information Model for Outsourced information<
	/name>
	<t>This section specifies an optional format for the set of parameters required
	by the HNA to configure the naming architecture of this document.</t>
	<t>In cases where a home router has not been provisioned by the manufacturer (wh
	en forward zones are provided by the manufacturer), or by the ISP (when the ISP
	provides this service), then a home user/owner will need to configure these sett
	ings via an administrative interface.</t>
	<t>By defining a standard format (in JSON) for this configuration information, t
	he user/owner may be able to just copy and paste a configuration blob from the s
	ervice provider into the administrative interface of the HNA.</t>
	<t>This format may also provide the basis for a future OAUTH2 <xref target="RFC6
	749"/> flow that could do the setup automatically.</t>
	<t>The HNA needs to be configured with the following parameters as described by
	this CDDL <xref target="RFC8610"/>. These are the parameters are necessary to e
	stablish a secure channel between the HNA and the DM as well as to specify the
	DNS zone that is in the scope of the communication.</t>
	<figure><sourcecode type="cddl"><![CDATA[		<sourcecode type="cddl"><![CDATA[
	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>For example:</t>
	<t>For example:</t>
	<!-- NOT actually json, as it is two examples merged -->
	<figure><artwork><![CDATA[		<sourcecode><![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>
	<dl>		<dt>Registered Homenet Domain (registered_domain):</dt>
	<dt>Registered Homenet Domain (registered_domain)</dt>		<dd>The Domain Name of the zone. Multiple Registered Homenet Domains may
	<dd>		be provided.
	<t>The Domain Name of the zone. Multiple Registered Homenet Domains may be p		This will generate the creation of multiple Public Homenet Zones. This parameter
	rovided.		is mandatory.
	This will generate the		</dd>
	creation of multiple Public Homenet Zones.		<dt>Distribution Manager notification address (dm):</dt>
	This parameter is mandatory.</t>		<dd>The associated FQDNs or IP addresses of the DM to which DNS Notifies
	</dd>		should be sent.
	<dt>Distribution Manager notification address (dm)</dt>		This parameter is mandatory. IP addresses are optional, and the FQDN is sufficie
	<dd>		nt and preferred.
	<t>The associated FQDNs or IP addresses of the DM to which DNS notifies shou		If there are concerns about the security of the name to IP translation, then DNS
	ld be sent.		SEC should be employed.
	This parameter is mandatory.		</dd>
	IP addresses are optional and the FQDN is sufficient and preferred.		</dl>
	If there are concerns about the security of the name to IP translation, then DNS		<t>As the session between the HNA and the DM is authenticated with TLS, th
	SEC should be employed.</t>		e use of names is easier.</t>
	</dd>		<t>As certificates are more commonly emitted for FQDN than for IP addresse
	</dl>		s, it is preferred to use names and authenticate the name of the DM during the T
			LS session establishment.</t>
	<t>As the session between the HNA and the DM is authenticated with TLS, the use		<dl>
	of names is easier.</t>		<dt>Supported Transport (dm_transport):</dt>
			<dd>The transport that carries the DNS exchanges between the HNA and the
	<t>As certificates are more commonly emitted for FQDN than for IP addresses, it		DM.
	is preferred to use names and authenticate the name of the DM during the TLS ses		The typical value is "DoT", but it may be extended in the future with "DoH" or "
	sion establishment.</t>		DoQ", for example.
			This parameter is optional, and the HNA uses DoT by default.
	<dl>		</dd>
	<dt>Supported Transport (dm_transport):</dt>		<dt>Distribution Manager Port (dm_port):</dt>
	<dd>		<dd>Indicates the port used by the DM.
	<t>The transport that carries the DNS exchanges between the HNA and the DM.		This parameter is optional, and the default value is provided by the Supported T
	Typical value is "DoT" but it may be extended in the future with "DoH", "DoQ" fo		ransport.
	r example.		In the future, an additional transport may not have a default port, in which cas
	This parameter is optional and by default the HNA uses DoT.</t>		e either a default port needs to be defined or this parameter becomes mandatory.
	</dd>		</dd>
	<dt>Distribution Manager Port (dm_port):</dt>		</dl>
	<dd>		<t>Note that HNA does not define ports for the Synchronization Channel.
	<t>Indicates the port used by the DM.		In any case, this is not expected to be a part of the configuration but is inste
	This parameter is optional and the default value is provided by the Supported Tr		ad negotiated through the Configuration Channel. Currently, the Configuration Ch
	ansport.		annel does not provide this and limits its agility to a dedicated IP address. If
	In the future, additional transport may not have default port, in which case eit		such agility is needed in the future, additional exchanges will need to be defi
	her a default port needs to be defined or this parameter become mandatory.</t>		ned.</t>
	</dd>		<dl>
	</dl>		<dt>Authentication Method ("hna_auth_method"):</dt>
			<dd>How the HNA authenticates itself to the DM within the TLS connection
	<t>Note that HNA does not defines ports for the Synchronization Channel.		(s).
	In any case, this is not expected to part of the configuration, but instead nego		The authentication method can typically be "certificate", "psk", or "none".
	tiated through the Configuration Channel.		This parameter is optional, and the Authentication Method is "certificate" by de
	Currently the Configuration Channel does not provide this, and limits its agilit		fault.
	y to a dedicated IP address.		</dd>
	If such agility is needed in the future, additional exchanges will need to be de		<dt>Authentication data ("hna_certificate", "hna_key"):</dt>
	fined.</t>		<dd>The certificate chain used to authenticate the HNA.
			This parameter is optional, and when not specified, a self-signed certificate is
	<dl>		used.
	<dt>Authentication Method ("hna_auth_method"):</dt>		</dd>
	<dd>		<dt>Distribution Manager AXFR permission netmask (dm_acl):</dt>
	<t>How the HNA authenticates itself to the DM within the TLS connection(s).		<dd>The subnet from which the CPE should accept SOA queries and AXFR req
	The authentication method can typically be "certificate", "psk" or "none".		uests.
	This Parameter is optional and by default the Authentication Method is "certific		A subnet is used in the case where the DOI consists of a number of different sys
	ate".</t>		tems. An
	</dd>		array of addresses is permitted. This parameter is optional, and if unspecified,
	<dt>Authentication data ("hna_certificate", "hna_key"):</dt>		the CPE uses the IP addresses provided by the dm parameter either directly when
	<dd>		the dm indicates the IP address(es) returned by the DNS or DNSSEC resolution wh
	<t>The certificate chain used to authenticate the HNA.		en dm indicates an FQDN.
	This parameter is optional and when not specified, a self-signed certificate is		</dd>
	used.</t>		</dl>
	</dd>		<t>For forward zones, the relationship between the HNA and the forward zon
	<dt>Distribution Manager AXFR permission netmask (dm_acl):</dt>		e provider may be the result of a number of transactions:</t>
	<dd>		<ol spacing="normal" type="1">
	<t>The subnet from which the CPE should accept SOA queries and AXFR requests		<li>The forward zone outsourcing may be provided by the maker of the Home
	.		net router.
	A subnet is used in the case where the DOI consists of a number of different sys		In this case, the identity and authorization could be built in the device at the
	tems.		manufacturer provisioning time. The device would need to be provisioned with a
	An array of addresses is permitted.		device-unique credential, and it is likely that the Registered Homenet Domain wo
	This parameter is optional and if unspecified, the CPE uses the IP addresses pro		uld be derived from a public attribute of the device, such as a serial number (s
	vided by the dm parameter either directly when dm indicates an IP address or the		ee <xref target="sec-ex-manu"/> or <xref target="I-D.richardson-homerouter-provi
	IP addresses returned by the DNS(SEC) resolution when dm indicates a FQDN.</t>		sioning"/> for more details).</li>
	</dd>		<li>The forward zone outsourcing may be provided by the ISP.
	</dl>		In this case, the use of <xref target="RFC9527"/> to provide the credentials is
			appropriate.</li>
	<t>For forward zones, the relationship between the HNA and the forward zone prov		<li>The forward zone may be outsourced to a third party, such as a domai
	ider may be the result of a number of transactions:</t>		n registrar.
			In this case, the use of the JSON-serialized YANG data model described in this s
	<t><list style="numbers">		ection is appropriate, as it can easily be copy and pasted by the user or downlo
	<t>The forward zone outsourcing may be provided by the maker of the Homenet ro		aded as part of a web transaction.</li>
	uter.		</ol>
	In this case, the identity and authorization could be built in the device at man		<t>For reverse zones, the relationship is always with the upstream ISP (al
	ufacturer provisioning time. The device would need to be provisioned with a dev		though there may be more than one), so <xref target="RFC9527"/> always applies.<
	ice-unique credential, and it is likely that the Registered Homenet Domain would		/t>
	be derived from a public attribute of the device, such as a serial number (see		<t>The following is an abridged example of a set of data that represents t
	<xref target="sec-ex-manu"/> or <xref target="I-D.richardson-homerouter-provisio		he needed configuration parameters for outsourcing.</t>
	ning"/> for more details ).</t>		</section>
	<t>The forward zone outsourcing may be provided by the Internet Service Provid		<section anchor="sec-ex-manu">
	er.		<name>Example: A Manufacturer-Provisioned HNA Product Flow</name>
	In this case, the use of <xref target="I-D.ietf-homenet-naming-architecture-dhc-		<t>This scenario is one where a Homenet router device manufacturer decides
	options"/> to provide the credentials is appropriate.</t>		to offer DNS hosting as a value add.</t>
	<t>The forward zone may be outsourced to a third party, such as a domain regis		<t><xref target="I-D.richardson-homerouter-provisioning"/> describes a pro
	trar.		cess for a home router
	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
	oaded as part of a web transaction.</t>
	</list></t>
	<t>For reverse zones, the relationship is always with the upstream ISP (although
	there may be more than one), and so <xref target="I-D.ietf-homenet-naming-archi
	tecture-dhc-options"/> is always the appropriate interface.</t>
	<t>The following is an abbridged example of a set of data that represents the ne
	eded configuration parameters for outsourcing.</t>
	</section>
	<section anchor="sec-ex-manu"><name>Example: A manufacturer provisioned HNA prod
	uct flow</name>
	<t>This scenario is one where a homenet router device manufacturer decides to of
	fer DNS hosting as a value add.</t>
	<t><xref target="I-D.richardson-homerouter-provisioning"/> describes a process f
	or 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>In addition to having an asymmetric credential known to the manufacture
	<t>In addition to having a assymmetric credential known to the manufacturer, the		r, 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>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
	<t>The HNA can use the above domain for itself.		name, they can arrange it.</t>
	It is not very pretty or personal, but if the owner wishes a better name, they c		<t>The configuration would look like the following:</t>
	an arrange for it.</t>		<artwork><![CDATA[
	<t>The configuration would look like:</t>
	<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>The dm_ctrl and dm_port values would be built into the firmware.</t>
	<t>The dm_ctrl and dm_port values would be built into the firmware.</t>		</section>
			<section anchor="acknowledgment" numbered="false">
	</section>		<name>Acknowledgments</name>
			<t>The authors wish to thank <contact fullname="Philippe Lemordant"/> for
			his contributions to
			the earlier draft versions of this document; <contact fullname="Ole Troan"/> for
			pointing out issues with
			the IPv6-routed home concept and placing the scope of this document in a
			wider picture; <contact fullname="Mark Townsley"/> for encouragement and 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>The authors would like to thank <contact fullname="Kiran Makhijani"/> f
			or her in-depth review that contributed to shaping the final version of this doc
			ument.</t>
			<t>The authors would also like to thank our Area Director <contact fullnam
			e="Éric Vyncke"/> for his constant support and pushing the document through the
			IESG process and the many reviewers from various directorates including <contact
			fullname="Anthony Somerset"/>, <contact fullname="Geoff Huston"/>, <contact ful
			lname="Tim Chown"/>, <contact fullname="Tim Wicinski"/>, <contact fullname="Matt
			Brown"/>, <contact fullname="Darrel Miller"/>, and <contact fullname="Christer
			Holmberg"/>.</t>
			</section>
			<section anchor="contributors" numbered="false">
			<name>Contributors</name>
			<t>The coauthors would like to thank <contact fullname="Chris Griffiths"/>
			and <contact fullname="Wouter Cloetens"/> for providing significant contributio
			ns to the earlier draft versions of this document.</t>
			</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. 114 change blocks.
	3202 lines changed or deleted		1539 lines changed or added
This html diff was produced by rfcdiff 1.48.