rfc9463xml2.original.xml   rfc9463.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. --> <!DOCTYPE rfc [
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!ENTITY nbsp "&#160;">
<!-- used by XSLT processors --> <!ENTITY zwsp "&#8203;">
<!-- For a complete list and description of processing instructions (PIs), <!ENTITY nbhy "&#8209;">
please see http://xml.resource.org/authoring/README.html. --> <!ENTITY wj "&#8288;">
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds ]>
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-add-dnr-16"
<?rfc strict="yes" ?> number="9463" submissionType="IETF" category="std" consensus="true" ipr="trust20
<!-- give errors regarding ID-nits and DTD validation --> 0902" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" updates="" o
<!-- control the table of contents (ToC) --> bsoletes="" xml:lang="en" version="3">
<?rfc toc="yes"?>
<!-- generate a ToC --> <!-- xml2rfc v2v3 conversion 3.17.1 -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" consensus="true" docName="draft-ietf-add-dnr-16"
ipr="trust200902" submissionType="IETF">
<front> <front>
<title abbrev="Discovery of Network-designated Resolvers">DHCP and Router <title abbrev="DNR">DHCP and Router
Advertisement Options for the Discovery of Network-designated Resolvers Advertisement Options for the Discovery of Network-designated Resolvers
(DNR)</title> (DNR)</title>
<seriesInfo name="RFC" value="9463"/>
<author fullname="Mohamed Boucadair" initials="M." role="editor" <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Bo
surname="Boucadair"> ucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street /> <street/>
<city>Rennes</city> <city>Rennes</city>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Tirumaleswar Reddy.K" initials="T." role="editor" surname=
<author fullname="Tirumaleswar Reddy" initials="T." role="editor" "Reddy.K">
surname="Reddy">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street /> <street/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Dan Wing" initials="D." surname="Wing"> <author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Citrix">Citrix Systems, Inc.</organization> <organization abbrev="Cloud Software Group">Cloud Software Group Holdings,
Inc.</organization>
<address> <address>
<postal> <postal>
<street /> <street/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>dwing-ietf@fuggles.com</email> <email>dwing-ietf@fuggles.com</email>
</address> </address>
</author> </author>
<author fullname="Neil Cook" initials="N." surname="Cook"> <author fullname="Neil Cook" initials="N." surname="Cook">
<organization>Open-Xchange</organization> <organization>Open-Xchange</organization>
<address> <address>
<postal> <postal>
<street /> <street/>
<country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>neil.cook@noware.co.uk</email> <email>neil.cook@noware.co.uk</email>
</address> </address>
</author> </author>
<author fullname="Tommy Jensen" initials="T." surname="Jensen"> <author fullname="Tommy Jensen" initials="T." surname="Jensen">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<postal> <postal>
<street /> <street/>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>tojens@microsoft.com</email> <email>tojens@microsoft.com</email>
</address> </address>
</author> </author>
<date year="2023" month="November" />
<date day="" month="" year="" /> <area>int</area>
<workgroup>add</workgroup>
<workgroup>ADD</workgroup>
<keyword>DNS</keyword> <keyword>DNS</keyword>
<keyword>service resolution</keyword> <keyword>service resolution</keyword>
<keyword>encryption</keyword> <keyword>encryption</keyword>
<keyword>service discovery</keyword> <keyword>service discovery</keyword>
<keyword>service provider</keyword> <keyword>service provider</keyword>
<keyword>network provider</keyword> <keyword>network provider</keyword>
<keyword>automation</keyword> <keyword>automation</keyword>
<keyword>DoH</keyword>
<keyword>DoT</keyword>
<keyword>DoQ</keyword>
<abstract> <abstract>
<t>The document specifies new DHCP and IPv6 Router Advertisement options <t>This document specifies new DHCP and IPv6 Router Advertisement options
to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over-TLS, to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS,
DNS-over-QUIC). Particularly, it allows a host to learn an and DNS over QUIC). Particularly, it allows a host to learn an
authentication domain name together with a list of IP addresses and a Authentication Domain Name together with a list of IP addresses and a
set of service parameters to reach such encrypted DNS resolvers.</t> set of service parameters to reach such encrypted DNS resolvers.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro">
<t>This document focuses on the discovery of encrypted DNS such as <name>Introduction</name>
DNS-over-HTTPS (DoH) <xref target="RFC8484" />, DNS-over-TLS (DoT) <xref <t>This document focuses on the discovery of encrypted DNS resolvers that
target="RFC7858" />, or DNS-over-QUIC (DoQ) <xref target="RFC9250" /> in are using protocols such as
DNS over HTTPS (DoH) <xref target="RFC8484"/>, DNS over TLS (DoT) <xref ta
rget="RFC7858"/>, or DNS over QUIC (DoQ) <xref target="RFC9250"/> in
local networks.</t> local networks.</t>
<t>In particular, this document specifies how a local encrypted DNS
<t>In particular, the document specifies how a local encrypted DNS resolver can be discovered by connected hosts by means of DHCPv4 <xref tar
resolver can be discovered by connected hosts by means of DHCPv4 <xref get="RFC2132"/>, DHCPv6 <xref target="RFC8415"/>, and IPv6 Router
target="RFC2132" />, DHCPv6 <xref target="RFC8415" />, and IPv6 Router Advertisement (RA) options <xref target="RFC4861"/>. These options are
Advertisement (RA) <xref target="RFC4861" /> options. These options are
designed to convey the following information: the DNS Authentication designed to convey the following information: the DNS Authentication
Domain Name (ADN), a list of IP addresses, and a set of service Domain Name (ADN), a list of IP addresses, and a set of service
parameters. This procedure is called Discovery of Network-designated parameters. This procedure is called Discovery of Network-designated
Resolvers (DNR).</t> Resolvers (DNR).</t>
<t>The options defined in this document can be deployed in a variety of <t>The options defined in this document can be deployed in a variety of
deployments (e.g., local networks with Customer Premises Equipment deployments (e.g., local networks with Customer Premises Equipment
(CPEs) that may or may not be managed by an Internet Service Provider (CPEs) that may or may not be managed by an Internet Service Provider
(ISP), or local networks with or without DNS forwarders). It is out of (ISP), or local networks with or without DNS forwarders). Providing an inv
the scope of this document to provide an inventory of such entory of such deployments is beyond the scope of this document.</t>
deployments.</t>
<t>Resolver selection considerations are out of scope. Likewise, <t>Resolver selection considerations are out of scope. Likewise,
policies (including any interactions with users) are out of scope.</t> policies (including any interactions with users) are out of scope.</t>
</section> </section>
<section anchor="notation">
<section anchor="notation" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 14 "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
<xref target="RFC2119" /> <xref target="RFC8174" /> when, and only when, "<bcp14>SHOULD NOT</bcp14>",
they appear in all capitals, as shown here.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
<t>This document makes use of the terms defined in <xref are to be interpreted as described in BCP&nbsp;14
target="RFC8499" />. The following additional terms are used: <list <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
style="hanging"> when, they appear in all capitals, as shown here.</t>
<t hangText="Authentication Domain Name (ADN):">refers to a domain <t>This document makes use of the terms defined in <xref target="RFC8499"/
>. The following additional terms are used: </t>
<dl newline="false" spacing="normal">
<dt>Authentication Domain Name (ADN):</dt>
<dd>Refers to a domain
name that is used by a DNS client to authenticate a DNS name that is used by a DNS client to authenticate a DNS
resolver.</t> resolver.</dd>
<dt>ADN-only mode:</dt>
<t hangText="ADN-only mode:">refers to a DNS discovery mode where <dd>Refers to a DNS discovery mode where
only the ADN of the DNS resolver is retrieved. See <xref only the ADN of the DNS resolver is retrieved. See <xref target="adn-o
target="adn-only" />.</t> nly"/>.</dd>
<dt>Do53:</dt>
<t hangText="Do53:">refers to unencrypted DNS.</t> <dd>Refers to unencrypted DNS.</dd>
<dt>DNR:</dt>
<t hangText="DNR:">refers to the Discovery of Network-designated <dd>Refers to the procedure called Discovery of Network-designated
Resolvers procedure.</t> Resolvers.</dd>
<dt>Encrypted DNS:</dt>
<t hangText="Encrypted DNS:">refers to a scheme where DNS exchanges <dd>Refers to a scheme where DNS exchanges
are transported over an encrypted channel. Examples of encrypted DNS are transported over an encrypted channel. Examples include
are DoT, DoH, or DoQ.</t> DoT, DoH, and DoQ.</dd>
<dt>Encrypted DNS resolver:</dt>
<t hangText="Encrypted DNS resolver:">refers to a DNS resolver that <dd>Refers to a DNS resolver that
supports any encrypted DNS scheme.</t> supports any encrypted DNS scheme.</dd>
<dt>Encrypted DNS options:</dt>
<t hangText="Encrypted DNS options:">refers to the options defined <dd>Refers to the options defined
in Sections <xref format="counter" target="DHCPv6" />, <xref in Sections&nbsp;<xref format="counter" target="DHCPv6"/>, <xref forma
format="counter" target="DHCP" />, and <xref format="counter" t="counter" target="DHCP"/>, and <xref format="counter" target="RA"/>.</dd>
target="RA" />.</t> <dt>DHCP:</dt>
<dd>Refers to both DHCPv4 and DHCPv6.</dd>
<t hangText="DHCP:">refers to both DHCPv4 and DHCPv6.</t> </dl>
</list></t>
</section> </section>
<section anchor="RI">
<section anchor="RI" title="Overview"> <name>Overview</name>
<t>This document describes how a DNS client can discover local encrypted <t>This document describes how a DNS client can discover local encrypted
DNS resolvers using DHCP (Sections <xref format="counter" DNS resolvers using DHCP (Sections&nbsp;<xref format="counter" target="DHC
target="DHCPv6" /> and <xref format="counter" target="DHCP" />) and Pv6"/> and <xref format="counter" target="DHCP"/>) and
Neighbor Discovery protocol (<xref target="RA" />): Encrypted DNS Neighbor Discovery protocol (<xref target="RA"/>) Encrypted DNS
options.</t> options.</t>
<t>These options configure an ADN, a list of IP
<t>These options configure an authentication domain name, a list of IP
addresses, and a set of service parameters of the encrypted DNS addresses, and a set of service parameters of the encrypted DNS
resolver. More information about the design of these options is provided resolver. More information about the design of these options is provided
in the following subsections.</t> in the following subsections.</t>
<section anchor="rationale">
<section anchor="rationale" title="Configuration Data for Encrypted DNS"> <name>Configuration Data for Encrypted DNS</name>
<t /> <section>
<name>ADN as Reference Identifier for DNS Authentication</name>
<section title="ADN as the Reference Identifier for DNS Authentication">
<t>In order to allow for a PKIX-based authentication of the <t>In order to allow for a PKIX-based authentication of the
encrypted DNS resolver to the DNS client, the Encrypted DNS options encrypted DNS resolver to the DNS client, the Encrypted DNS options
are designed to always include an authentication domain name. This are designed to always include an ADN. This
ADN is presented as a reference identifier for DNS authentication ADN is presented as a reference identifier for DNS authentication
purposes. This design accommodates the current best practices for purposes. This design accommodates the current best practices for
issuing certificates as per <xref section="1.7.2" issuing certificates as per <xref section="1.7.2" target="RFC6125"/>:<
target="RFC6125" />:</t> /t>
<aside>
<aside pn="aside-cert-authorities"> <t>Some certification authorities issue server
<t indent="0">Some certification authorities issue server
certificates based on IP addresses, but preliminary evidence certificates based on IP addresses, but preliminary evidence
indicates that such certificates are a very small percentage (less indicates that such certificates are a very small percentage (less
than 1%) of issued certificates.</t> than 1%) of issued certificates.</t>
</aside> </aside>
</section> </section>
<section>
<section title="Avoiding Dependency on External Resolvers"> <name>Avoiding Dependency on External Resolvers</name>
<t>To avoid adding a dependency on another server to resolve the <t>To avoid adding a dependency on another server to resolve the
ADN, the Encrypted DNS options return the IP address(es) to locate ADN, the Encrypted DNS options return the IP address(es) to locate
an encrypted DNS resolver. These encrypted DNS resolvers may be an encrypted DNS resolver. These encrypted DNS resolvers may be
hosted on the same or distinct IP addresses. Such a decision is hosted on the same IP address or distinct IP addresses. Such a decisio n is
deployment specific.</t> deployment specific.</t>
<t>In order to optimize the size of discovery messages when all DNS <t>In order to optimize the size of discovery messages when all DNS
resolvers terminate on the same IP address, early versions of this resolvers terminate on the same IP address, early draft versions of th is
document considered relying upon the discovery mechanisms specified document considered relying upon the discovery mechanisms specified
in <xref target="RFC2132" /><xref target="RFC3646" /><xref in <xref target="RFC2132"/>, <xref target="RFC3646"/>, and <xref targe
target="RFC8106" /> to retrieve a list of IP addresses to reach t="RFC8106"/> to retrieve a list of IP addresses to reach
their DNS resolvers. Nevertheless, this approach requires a client their DNS resolvers. Nevertheless, this approach requires a client
that supports more than one encrypted DNS protocol (e.g., DoH and that supports more than one encrypted DNS protocol (e.g., DoH and
DoT) to probe that list of IP addresses. To avoid such a probing, DoT) to probe that list of IP addresses. To avoid such probing,
the options defined in Sections <xref format="counter" the options defined in Sections&nbsp;<xref format="counter" target="DH
target="DHCPv6" />, <xref format="counter" target="DHCP" />, and CPv6"/>, <xref format="counter" target="DHCP"/>, and
<xref format="counter" target="RA" /> associate an encrypted DNS <xref format="counter" target="RA"/> associate an encrypted DNS
protocol with an IP address. No probing is required in such a protocol with an IP address. No probing is required in such a
design.</t> design.</t>
</section> </section>
<section>
<section title="Single vs. Multiple IP Addresses"> <name>Single vs. Multiple IP Addresses</name>
<t>A list of IP addresses to reach an encrypted DNS resolver may be <t>A list of IP addresses to reach an encrypted DNS resolver may be
returned in an Encrypted DNS option to accommodate current returned in an Encrypted DNS option to accommodate current
deployments relying upon primary and backup resolvers. Also, DNR can deployments relying upon primary and backup resolvers. Also, DNR can
be used in contexts where other DNS redundancy schemes (e.g., be used in contexts where other DNS redundancy schemes (e.g.,
anycast as in BCP 126 <xref target="RFC4786" />) are used.</t> anycast as discussed in <xref target="RFC4786">BCP&nbsp;126</xref>) ar
e used.</t>
<t>Whether one or more IP addresses are returned in an Encrypted DNS <t>Whether one or more IP addresses are returned in an Encrypted DNS
option is deployment specific. For example, a router embedding a option is deployment specific. For example, a router embedding a
recursive server or a forwarder has to include one single IP address recursive server or a forwarder has to include one single IP address
pointing to one of its LAN-facing interfaces. Typically, this IP pointing to one of its LAN-facing interfaces. Typically, this IP
address can be a private IPv4 address, a link-local address, a address can be a private IPv4 address, a Link-Local address, an IPv6
Unique Local IPv6 unicast Address (ULA), or a Global Unicast Address Unique Local Address (ULA), or a Global Unicast Address
(GUA).</t> (GUA).</t>
<t>If multiple IP addresses are to be returned in an Encrypted DNS <t>If multiple IP addresses are to be returned in an Encrypted DNS
option, these addresses are ordered in the preference for use by the option, these addresses are returned, ordered by preference, for use b y the
client.</t> client.</t>
</section> </section>
<section>
<section title="Why Not Separate Options for ADN and IP Addresses?"> <name>Why Not Separate Options for the ADN and IP Addresses?</name>
<t>A single option is used to convey both the ADN and IP addresses. <t>A single option is used to convey both the ADN and IP addresses.
Otherwise, a means to correlate an IP address conveyed in an option Otherwise, a means to correlate an IP address conveyed in an option
with an ADN conveyed in another option will be required if, for with an ADN conveyed in another option will be required if, for
example, more than one ADN is supported by the network.</t> example, more than one ADN is supported by the network.</t>
</section> </section>
<section>
<section title="Service Parameters"> <name>Service Parameters</name>
<t>Because distinct encrypted DNS protocols (e.g., DoT, DoH, and <t>Because distinct encrypted DNS protocols (e.g., DoT, DoH, and
DoQ) may be provisioned by a network and that some of these DoQ) may be provisioned by a network and some of these
protocols may make use of customized port numbers instead of default protocols may make use of customized port numbers instead of default
ones, the Encrypted DNS options are designed to return a set of port numbers, the Encrypted DNS options are designed to return a set o f
service parameters. These parameters are encoded following the same service parameters. These parameters are encoded following the same
rules for encoding SvcParams in <xref section="2.1" rules for encoding SvcParams using the wire format specified in <xref
target="I-D.ietf-dnsop-svcb-https" />. This encoding approach may section="2.2" target="RFC9460"/>. This encoding approach may
increase the size of the options but it has the merit of relying increase the size of the options, but it has the merit of relying
upon an existing IANA registry and, thus, accommodating new upon an existing IANA registry and, thus, accommodating new
encrypted DNS protocols and service parameters that may be defined encrypted DNS protocols and service parameters that may be defined
in the future.</t> in the future.</t>
<t>The following service parameters <bcp14>MUST</bcp14> be supported b
<t>The following service parameters MUST be supported by a DNR y a DNR
implementation:</t> implementation:</t>
<dl newline="false" spacing="normal">
<t> <dt>alpn:</dt>
<list style="hanging"> <dd>Used to indicate the set of supported
<t hangText="alpn:">Used to indicate the set of supported protocols (<xref section="7.1" target="RFC9460"/>).</dd>
protocols (<xref section="7.1" <dt>port:</dt>
target="I-D.ietf-dnsop-svcb-https" />).</t> <dd>Used to indicate the target port number for
the encrypted DNS connection (<xref section="7.2" target="RFC9460"
<t hangText="port:">Used to indicate the target port number for />).</dd>
the encrypted DNS connection (<xref section="7.2" </dl>
target="I-D.ietf-dnsop-svcb-https" />).</t> <t>In addition, the following service parameter is <bcp14>RECOMMENDED<
</list> /bcp14> to be
</t> supported by a DNR implementation:</t>
<dl newline="false" spacing="normal">
<t>In addition, the following service parameter is RECOMMENDED to be <dt>dohpath:</dt>
supported by a DNR implementation:<list style="hanging"> <dd>Used to supply a relative DoH URI
<t hangText="dohpath:">Used to supply a relative DoH URI Template (<xref section="5.1" target="RFC9461"/>).</dd>
Template (<xref section="5.1" </dl>
target="I-D.ietf-add-svcb-dns" />).</t>
</list></t>
<t />
</section> </section>
<section anchor="adn-only">
<section anchor="adn-only" title="ADN Only Mode"> <name>ADN-Only Mode</name>
<t>The provisioning mode in which an ADN, a list of IP addresses, <t>The provisioning mode in which an ADN, a list of IP addresses,
and a set of service parameters of the encrypted DNS resolver are and a set of service parameters of the encrypted DNS resolver are
supplied to a host SHOULD be used because the Encrypted DNS options supplied to a host <bcp14>SHOULD</bcp14> be used because the Encrypted DNS options
are self-contained and do not require any additional DNS queries. are self-contained and do not require any additional DNS queries.
The reader may refer to <xref target="RFC7969" /> for an overview of The reader may refer to <xref target="RFC7969"/> for an overview of
advanced capabilities that are supported by DHCP servers to populate advanced capabilities that are supported by DHCP servers to populate
configuration data (e.g., issue DNS queries).</t> configuration data (e.g., issue DNS queries).</t>
<t>In contexts where putting additional complexity on requesting <t>In contexts where putting additional complexity on requesting
hosts is acceptable, returning an ADN only can be considered. The hosts is acceptable, returning an ADN only can be considered. The
supplied ADN will be passed to a local resolution library (a DNS supplied ADN will be passed to a local resolution library (a DNS
client, typically) which will then issue Service Binding (SVCB) client, typically), which will then issue Service Binding (SVCB)
queries <xref target="I-D.ietf-add-svcb-dns" />. These SVCB queries queries <xref target="RFC9461"/>. These SVCB queries
can be sent to the discovered encrypted DNS resolver itself or to can be sent to the discovered encrypted DNS resolver itself or to
the network-designated Do53 resolver. Note that this mode may be the network-designated Do53 resolver. Note that this mode may be
subject to active attacks, which can be mitigated by DNSSEC.</t> subject to active attacks, which can be mitigated by DNSSEC.</t>
<aside>
<aside pn="aside-adn-passed"> <t>How an ADN is passed to a local resolution library
<t indent="0">How an ADN is passed to a local resolution library
is implementation specific.</t> is implementation specific.</t>
</aside> </aside>
</section> </section>
<section>
<section title="Encrypted DNS Options Ordering"> <name>Ordering of Encrypted DNS Options</name>
<t>The DHCP options defined in Sections <xref format="counter" <t>The DHCP options defined in Sections&nbsp;<xref format="counter" ta
target="DHCPv6" /> and <xref format="counter" target="DHCP" /> rget="DHCPv6"/> and <xref format="counter" target="DHCP"/>
follow the option ordering guidelines in <xref section="17" follow the option ordering guidelines in <xref section="17" target="RF
target="RFC7227" />.</t> C7227"/>.</t>
<t>Likewise, the RA option (<xref format="default" target="RA"/>)
<t>Likewise, the RA option (<xref format="default" target="RA" />) adheres to the recommendations in <xref section="9" target="RFC4861"/>
adheres to the recommendations in <xref section="9" .</t>
target="RFC4861" />.</t>
</section> </section>
<section anchor="VC">
<section anchor="VC" title="DNR Validation Checks"> <name>DNR Validation Checks</name>
<t>On receipt of an Encrypted DNS option, the DHCP client (or IPv6 <t>On receipt of an Encrypted DNS option, the DHCP client (or IPv6
host) makes the following validation checks:<list style="symbols"> host) makes the following validation checks:</t>
<t>The ADN is present and encoded as per <xref section="10" <ul spacing="normal">
target="RFC8415" />.</t> <li>The ADN is present and encoded as per <xref section="10" target=
"RFC8415"/>.</li>
<t>If additional data is supplied: <list style="symbols"> <li>
<t>the service parameters are encoded following the rules <t>If additional data is supplied: </t>
specified in <xref section="2.1" <ul spacing="normal">
target="I-D.ietf-dnsop-svcb-https" />.</t> <li>The service parameters are encoded following the rules
specified in <xref section="2.2" target="RFC9460"/>.</li>
<t>the option includes at least one valid IP address.</t> <li>The option includes at least one valid IP address.</li>
<li>The service parameters do not include "ipv4hint" or
<t>the service parameters do not include "ipv4hint" or "ipv6hint" parameters.</li>
"ipv6hint" service parameters.</t> </ul>
</list></t> </li>
</list></t> </ul>
<t>If any of the checks fail, the receiver discards the received <t>If any of the checks fail, the receiver discards the received
Encrypted DNS option.</t> Encrypted DNS option.</t>
</section> </section>
<section>
<section title="DNR Information Using Other Provisioning Mechanisms"> <name>DNR Information Using Other Provisioning Mechanisms</name>
<t>The provisioning mechanisms specified in this document may not be <t>The provisioning mechanisms specified in this document may not be
available in specific networks (e.g., some cellular networks available in specific networks (e.g., some cellular networks
exclusively use Protocol Configuration Options (PCOs) <xref exclusively use Protocol Configuration Options (PCOs) <xref target="TS
target="TS.24008" />) or may not be suitable in some contexts (e.g., .24008"/>) or may not be suitable in some contexts (e.g., where
need for a secure discovery). Other mechanisms may be considered in secure discovery is needed). Other mechanisms may be considered in
these contexts for the provisioning of encrypted DNS resolvers. It these contexts for the provisioning of encrypted DNS resolvers. It
is RECOMMENDED that at least the following DNR information is made is <bcp14>RECOMMENDED</bcp14> that at least the following DNR informat ion be made
available to a requesting host:</t> available to a requesting host:</t>
<ul spacing="normal">
<t> <li>A service priority whenever the discovery mechanism does not
<list style="symbols">
<t>A service priority whenever the discovery mechanism does not
rely on implicit ordering if multiple instances of the encrypted rely on implicit ordering if multiple instances of the encrypted
DNS are used.</t> DNS are used.</li>
<li>An ADN. This parameter is
<t>An authentication domain name. This parameter is mandatory.</li>
mandatory.</t> <li>A list of IP addresses to locate the encrypted DNS
resolver.</li>
<t>A list of IP addresses to locate the encrypted DNS <li>A set of service parameters.</li>
resolver.</t> </ul>
<t>A set of service parameters.</t>
</list>
</t>
</section> </section>
</section> </section>
<section>
<section title="Handling Configuration Data Conflicts"> <name>Handling Configuration Data Conflicts</name>
<t>If the encrypted DNS is discovered by a host using both RA and <t>If encrypted DNS resolvers are discovered by a host using both RA and
DHCP, the rules discussed in <xref section=" 5.3.1" DHCP, the rules discussed in <xref section=" 5.3.1" target="RFC8106"/> <
target="RFC8106" /> MUST be followed.</t> bcp14>MUST</bcp14> be followed.</t>
<t>DHCP/RA options to discover encrypted DNS resolvers (including DoH
<t>DHCP/RA options to discover encrypted DNS resolvers (including, DoH
URI Templates) takes precedence over Discovery of Designated Resolvers URI Templates) takes precedence over Discovery of Designated Resolvers
(DDR) <xref target="I-D.ietf-add-ddr" /> since DDR uses Do53 to an (DDR) <xref target="RFC9462"/>, since DDR uses Do53 to an
external DNS resolver, which is susceptible to both internal and external DNS resolver, which is susceptible to both internal and
external attacks whereas DHCP/RA is typically protected using the external attacks whereas DHCP/RA is typically protected using the
mechanisms discussed in <xref target="spoof" />.</t> mechanisms discussed in <xref target="spoof"/>.</t>
<t>If a client learns both Do53 and encrypted DNS resolvers from the <t>If a client learns both Do53 and encrypted DNS resolvers from the
same network, and absent explicit configuration otherwise, it is same network, and absent explicit configuration otherwise, it is
RECOMMENDED that the client uses the encrypted DNS resolvers for that <bcp14>RECOMMENDED</bcp14> that the client use the encrypted DNS resolve rs for that
network. If the client cannot establish an authenticated and encrypted network. If the client cannot establish an authenticated and encrypted
connection with the encrypted DNS resolver, it may fall back to using connection with the encrypted DNS resolver, it may fall back to using
the Do53 resolver.</t> the Do53 resolver.</t>
</section> </section>
<section>
<section title="Validating Discovered Resolvers"> <name>Validating Discovered Resolvers</name>
<t>This section describes a set of validation checks to confirm that <t>This section describes a set of validation checks to confirm that
an encrypted DNS resolver matches what is provided using DNR (e.g., an encrypted DNS resolver matches what is provided using DNR (e.g.,
DHCP or RA). Such validation checks do not intend to validate the DHCP or RA). Such validation checks do not intend to validate the
security of the DNR provisioning mechanisms or the user's trust security of the DNR provisioning mechanisms or the user's trust
relationship to the network.</t> relationship to the network.</t>
<t>If the local DNS client supports one of the discovered encrypted <t>If the local DNS client supports one of the discovered encrypted
DNS protocols identified by Application Layer Protocol Negotiation DNS protocols identified by Application-Layer Protocol Negotiation
(ALPN) protocol identifiers (or other service parameter that indicates (ALPN) protocol identifiers (or another service parameter that indicates
some other protocol disambiguation mechanism), the DNS client some other protocol disambiguation mechanism), the DNS client
establishes an encrypted DNS session following the service priority of establishes an encrypted DNS session following the service priority of
the discovered encrypted resolvers.</t> the discovered encrypted resolvers.</t>
<t>The DNS client verifies the connection based on PKIX validation <t>The DNS client verifies the connection based on PKIX validation
<xref target="RFC5280" /> of the DNS resolver certificate and uses the <xref target="RFC5280"/> of the DNS resolver certificate and uses the
validation techniques as described in <xref target="RFC6125" /> to validation techniques as described in <xref target="RFC6125"/> to
compare the authentication domain name conveyed in the Encrypted DNS compare the ADN conveyed in the Encrypted DNS
options to the certificate provided (see <xref section="8.1" options to the certificate provided (see <xref section="8.1" target="RFC
target="RFC8310" /> for more details). The DNS client uses the default 8310"/> for more details). The DNS client uses the default
system or application PKI trust anchors unless configured otherwise to system or application PKI trust anchors unless configured otherwise to
use explicit trust anchors. ALPN-related considerations can be found use explicit trust anchors. ALPN-related considerations can be found
in <xref section="6.1" target="I-D.ietf-dnsop-svcb-https" />. in <xref section="7.1" target="RFC9460"/>.
Operation considerations to check the revocation status of the Operational considerations related to checking the revocation status of
certificate of an encrypted DNS resolver are discussed in Section 10 the
of <xref target="RFC8484" />.</t> certificate of an encrypted DNS resolver are discussed in
<xref target="RFC8484" sectionFormat="of" section="10"/>.</t>
</section> </section>
<section>
<section title="Multihoming Considerations"> <name>Multihoming Considerations</name>
<t>Devices may be connected to multiple networks; each providing their <t>Devices may be connected to multiple networks, each providing their
own DNS configuration using the discovery mechanisms specified in this own DNS configuration using the discovery mechanisms specified in this
document. Nevertheless, it is out of the scope of this specification document. Nevertheless, discussing DNS selection of multi-interfaced dev
to discuss DNS selection of multi-interface devices. Such ices is beyond the scope of this specification. Such
considerations fall under the generic issue of handling multiple considerations fall under the generic issue of handling multiple
provisioning sources and which should not be dealt within each option provisioning sources and should not be processed in each option
separately as per the recommendation in <xref section="12" separately, as per the recommendation in <xref section="12" target="RFC7
target="RFC7227" />.</t> 227"/>.</t>
<t>The reader may refer to <xref target="RFC6731"/> for a discussion
<t>The reader may refer to <xref target="RFC6731" /> for a discussion
of DNS selection issues and an example of DNS resolver selection for of DNS selection issues and an example of DNS resolver selection for
multi-interfaced devices. Also, the reader may refer to <xref multi-interfaced devices. Also, the reader may refer to <xref target="Lo
target="I-D.ietf-add-split-horizon-authority" /> for a discussion on cal-DNS-Authority"/> for a discussion on
how DNR and Provisioning Domains (PvDs) Key "dnsZones" (<xref how DNR and Provisioning Domain (PvD) key "dnsZones" (<xref section="4.3
section="4.3" target="RFC8801" />) can be used in Split DNS " target="RFC8801"/>) can be used in "split DNS"
environments (<xref section="6" target="RFC8499" />).</t> environments (<xref section="6" target="RFC8499"/>).</t>
</section> </section>
</section> </section>
<section anchor="DHCPv6">
<section anchor="DHCPv6" title="DHCPv6 Encrypted DNS Option"> <name>DHCPv6 Encrypted DNS Option</name>
<t /> <section anchor="DHCPv6-ADN">
<name>Option Format</name>
<section anchor="DHCPv6-ADN" title="Option Format"> <t>The format of the DHCPv6 Encrypted DNS option is shown in <xref targe
<t>The format of the DHCPv6 Encrypted DNS option is shown in <xref t="dhcpv6-format"/>.</t>
target="dhcpv6-format" />.</t> <figure anchor="dhcpv6-format">
<name>DHCPv6 Encrypted DNS Option</name>
<t><figure align="center" anchor="dhcpv6-format" <artwork align="center"><![CDATA[
title="DHCPv6 Encrypted DNS Option"> 0 1 2 3
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_DNR | Option-length | | OPTION_V6_DNR | Option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Priority | ADN Length | | Service Priority | ADN Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ authentication-domain-name ~ ~ authentication-domain-name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Length | | | Addr Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ipv6-address(es) ~ ~ ipv6-address(es) ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ Service Parameters (SvcParams) ~ ~ Service Parameters (SvcParams) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure>The fields of the option shown in <xref ]]></artwork>
target="dhcpv6-format" /> are as follows:<list style="hanging"> </figure>
<t hangText="Option-code:">OPTION_V6_DNR (TBA1, see <xref
target="iana6" />)</t>
<t hangText="Option-length:">Length of the enclosed data in <t>The fields of the option shown in <xref target="dhcpv6-format"/> are
as follows:</t>
<dl newline="false" spacing="normal">
<dt>Option-code:</dt>
<dd>OPTION_V6_DNR (144; see <xref target="iana6"/>).</dd>
<dt>Option-length:</dt>
<dd>Length of the enclosed data in
octets. The option length is ('ADN Length' + 4) when only an ADN octets. The option length is ('ADN Length' + 4) when only an ADN
is included in the option.</t> is included in the option.</dd>
<dt>Service Priority:</dt>
<t hangText="Service Priority:">The priority of this OPTION_V6_DNR <dd>The priority of this OPTION_V6_DNR
instance compared to other instances. This 16-bit unsigned integer instance compared to other instances. This 16-bit unsigned integer
is interpreted following the rules specified in <xref is interpreted following the rules specified in <xref section="2.4.1
section="2.4.1" target="I-D.ietf-dnsop-svcb-https" />.</t> " target="RFC9460"/>.</dd>
<dt>ADN Length:</dt>
<t hangText="ADN Length:">Length of the authentication-domain-name <dd>Length of the authentication-domain-name
field in octets.</t> field in octets.</dd>
<dt>authentication-domain-name (variable length):</dt>
<t hangText="authentication-domain-name (variable length):">A <dd>
fully qualified domain name of the encrypted DNS resolver. This <t>A
field is formatted as specified in <xref section="10" Fully Qualified Domain Name (FQDN) of the encrypted DNS resolver. Th
target="RFC8415" />.<vspace blankLines="1" />An example of the is
authentication-domain-name encoding is shown in <xref field is formatted as specified in <xref section="10" target="RFC841
target="fqdn" />. This example conveys the FQDN 5"/>.</t>
"doh1.example.com.", and the resulting Option-length field is <t>An example of the
18.<figure anchor="fqdn" authentication-domain-name encoding is shown in <xref target="fqdn"/
title="An Example of the DNS authentication-domain-name Encoding >. This example conveys the FQDN
"> "doh1.example.com.", and the resulting ADN Length field is
<artwork align="center"><![CDATA[+------+------+------+------+-- 18.</t>
----+------+------+------+------+ <figure anchor="fqdn">
<name>An Example of the DNS authentication-domain-name Encoding</n
ame>
<artwork align="center"><![CDATA[
+------+------+------+------+------+------+------+------+------+
| 0x04 | d | o | h | 1 | 0x07 | e | x | a | | 0x04 | d | o | h | 1 | 0x07 | e | x | a |
+------+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+------+
| m | p | l | e | 0x03 | c | o | m | 0x00 | | m | p | l | e | 0x03 | c | o | m | 0x00 |
+------+------+------+------+------+------+------+------+------+ +------+------+------+------+------+------+------+------+------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
</dd>
<t hangText="Addr Length:">Length of enclosed IPv6 addresses in <dt>Addr Length:</dt>
octets. When present, it MUST be a multiple of 16.</t> <dd>Length of enclosed IPv6 addresses in
octets. When present, it <bcp14>MUST</bcp14> be a multiple of 16.</d
<t hangText="ipv6-address(es) (variable length):">Indicates one or d>
<dt>ipv6-address(es) (variable length):</dt>
<dd>
<t>Indicates one or
more IPv6 addresses to reach the encrypted DNS resolver. An more IPv6 addresses to reach the encrypted DNS resolver. An
address can be link-local, ULA, or GUA. The format of this field address can be a Link-Local address, a ULA, or a GUA. The format of
is shown in <xref target="v6add" />.<figure align="center" this field
anchor="v6add" title="Format of the IPv6 Addresses Field"> is shown in <xref target="v6add"/>.</t>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 <figure anchor="v6add">
3 4 5 6 7 8 9 0 1 <name>Format of the ipv6-address(es) Field</name>
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| ipv6-address | | ipv6-address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure></t> ]]></artwork>
</figure>
<t </dd>
hangText="Service Parameters (SvcParams) (variable length):">Specifi <dt>Service Parameters (SvcParams) (variable length):</dt>
es <dd>
<t>Specifies
a set of service parameters that are encoded following the rules a set of service parameters that are encoded following the rules
in <xref section="2.1" target="I-D.ietf-dnsop-svcb-https" />. in <xref section="2.2" target="RFC9460"/>.
Service parameters may include, for example, a list of ALPN Service parameters may include, for example, a list of ALPN
protocol identifiers or alternate port numbers. This field SHOULD protocol identifiers or alternate port numbers. This field <bcp14>SH
include at least "alpn" SvcParam. The "alpn" SvcParam may not be OULD</bcp14>
required in contexts such as a variant of DNS over CoAP where include at least the "alpn" SvcParam. The "alpn" SvcParam may not be
required in contexts such as a variant of DNS over the Constrained A
pplication Protocol (CoAP) where
messages are encrypted using Object Security for Constrained messages are encrypted using Object Security for Constrained
RESTful Environments (OSCORE) <xref target="RFC8613" />. The RESTful Environments (OSCORE) <xref target="RFC8613"/>. The
service parameters MUST NOT include "ipv4hint" or "ipv6hint" service parameters <bcp14>MUST NOT</bcp14> include "ipv4hint" or "ip
SvcParams as they are superseded by the included IP addresses. v6hint"
<vspace blankLines="1" />If no port service parameter is included, SvcParams, as they are superseded by the included IP addresses.
</t>
<t>If no port service parameter is included,
this indicates that default port numbers should be used. As a this indicates that default port numbers should be used. As a
reminder, the default port number is 853 for DoT, 443 for DoH, and reminder, the default port number is 853 for DoT, 443 for DoH, and
853 for DoQ.<vspace blankLines="1" />The length of this field is 853 for DoQ.</t>
<t>The length of this field is
('Option-length' - 6 - 'ADN Length' - 'Addr Length').</t> ('Option-length' - 6 - 'ADN Length' - 'Addr Length').</t>
</list></t> </dd>
</dl>
<t>Note that "Addr Length", "ipv6-address(es)", and "Service <t>Note that the "Addr Length", "ipv6-address(es)", and "Service
Parameters (SvcParams)" fields are not present if the ADN-only mode is Parameters (SvcParams)" fields are not present if the ADN-only mode is
used (<xref target="adn-only" />).</t> used (<xref target="adn-only"/>).</t>
</section> </section>
<section>
<section title="DHCPv6 Client Behavior"> <name>DHCPv6 Client Behavior</name>
<t>To discover an encrypted DNS resolver, the DHCPv6 client MUST <t>To discover an encrypted DNS resolver, the DHCPv6 client <bcp14>MUST<
include OPTION_V6_DNR in an Option Request Option (ORO), as in /bcp14>
Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of <xref include OPTION_V6_DNR in an Option Request Option (ORO), per
target="RFC8415" />.</t> Sections&nbsp;<xref target="RFC8415" section="18.2.1" sectionFormat="bar
e"/>, <xref target="RFC8415" section="18.2.2" sectionFormat="bare"/>, <xref targ
<t>The DHCPv6 client MUST be prepared to receive multiple instances of et="RFC8415" section="18.2.4" sectionFormat="bare"/>, <xref target="RFC8415" sec
tion="18.2.5" sectionFormat="bare"/>, <xref target="RFC8415" section="18.2.6" se
ctionFormat="bare"/>, and <xref target="RFC8415" section="21.7" sectionFormat="b
are"/> of <xref target="RFC8415"/>.</t>
<t>The DHCPv6 client <bcp14>MUST</bcp14> be prepared to receive multiple
instances of
the OPTION_V6_DNR option; each option is to be treated as a separate the OPTION_V6_DNR option; each option is to be treated as a separate
encrypted DNS resolver. These instances MUST be processed following encrypted DNS resolver. These instances <bcp14>MUST</bcp14> be processed
their service priority (i.e., smaller service priority indicates a following
their service priority (i.e., a smaller service priority value indicates
a
higher preference).</t> higher preference).</t>
<t>The DHCPv6 client <bcp14>MUST</bcp14> silently discard any OPTION_V6_
<t>The DHCPv6 client MUST silently discard any OPTION_V6_DNR that DNR that
fails to pass the validation steps defined in <xref fails to pass the validation steps defined in <xref target="VC"/>.</t>
target="VC" />.</t> <t>The DHCPv6 client <bcp14>MUST</bcp14> silently discard multicast and
host loopback
<t>The DHCPv6 client MUST silently discard multicast and host loopback
addresses conveyed in OPTION_V6_DNR.</t> addresses conveyed in OPTION_V6_DNR.</t>
</section> </section>
</section> </section>
<section anchor="DHCP">
<section anchor="DHCP" title="DHCPv4 Encrypted DNS Option"> <name>DHCPv4 Encrypted DNS Option</name>
<section title="Option Format"> <section>
<name>Option Format</name>
<t>The format of the DHCPv4 Encrypted DNS option is illustrated in <t>The format of the DHCPv4 Encrypted DNS option is illustrated in
<xref target="dhcpri_dns" />.</t> <xref target="dhcpri_dns"/>.</t>
<figure anchor="dhcpri_dns">
<t> <name>DHCPv4 Encrypted DNS Option</name>
<figure anchor="dhcpri_dns" title="DHCPv4 Encrypted DNS Option"> <artwork align="center"><![CDATA[
<artwork align="center"><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V4_DNR | Length | | OPTION_V4_DNR | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ DNR Instance Data #1 ~ ~ DNR Instance Data #1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
. ... . | . ... . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional
~ DNR Instance Data #n ~ | ~ DNR Instance Data #n ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
]]></artwork> ]]></artwork>
</figure> </figure>
</t> <t>The fields of the option shown in <xref target="dhcpri_dns"/> are
as follows:</t>
<t>The fields of the option shown in <xref target="dhcpri_dns" /> are <dl newline="false" spacing="normal">
as follows:<list style="hanging"> <dt>Code:</dt>
<t hangText="Code:">OPTION_V4_DNR (TBA2, see <xref <dd>OPTION_V4_DNR (162; see <xref target="iana4"/>).</dd>
target="iana4" />).</t> <dt>Length:</dt>
<dd>Indicates the length of the enclosed data in
<t hangText="Length:">Indicates the length of the enclosed data in octets.</dd>
octets.</t> <dt>DNR Instance Data:</dt>
<dd>
<t hangText="DNR Instance Data:">Includes the configuration data <t>Includes the configuration data
of an encrypted DNS resolver. The format of this field is shown in of an encrypted DNS resolver. The format of this field is shown in
<xref target="dhcpri_dns2" />. <figure anchor="dhcpri_dns2" <xref target="dhcpri_dns2"/>. </t>
title="DNR Instance Data Format"> <figure anchor="dhcpri_dns2">
<artwork align="center"><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 <name>DNR Instance Data Format</name>
5 <artwork align="center"><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNR Instance Data Length | | DNR Instance Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Priority | | Service Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADN Length | | | ADN Length | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ authentication-domain-name ~ ~ authentication-domain-name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Length | | | Addr Length | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~ IPv4 Address(es) ~ ~ IPv4 Address(es) ~
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+
| | | | | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
~Service Parameters (SvcParams) ~ ~Service Parameters (SvcParams) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure><vspace blankLines="1" />When several encrypted DNS </figure>
<t>When several encrypted DNS
resolvers are to be included, the "DNR Instance Data" field is resolvers are to be included, the "DNR Instance Data" field is
repeated.</t> repeated.</t>
</list>The fields shown in <xref target="dhcpri_dns2" /> are as </dd>
follows:<list style="hanging"> </dl>
<t hangText="DNR Instance Data Length:">Length of all following <t>The fields shown in <xref target="dhcpri_dns2"/> are as
follows:</t>
<dl newline="false" spacing="normal">
<dt>DNR Instance Data Length:</dt>
<dd>Length of all following
data in octets. This field is set to ('ADN Length' + 3) when only data in octets. This field is set to ('ADN Length' + 3) when only
an ADN is provided for a DNR instance.</t> an ADN is provided for a DNR instance.</dd>
<dt>Service Priority:</dt>
<t hangText="Service Priority:">The priority of this instance <dd>The priority of this instance
compared to other DNR instances. This 16-bit unsigned integer is compared to other DNR instances. This 16-bit unsigned integer is
interpreted following the rules specified in <xref section="2.4.1" interpreted following the rules specified in <xref section="2.4.1" t
target="I-D.ietf-dnsop-svcb-https" />.</t> arget="RFC9460"/>.</dd>
<dt>ADN Length:</dt>
<t hangText="ADN Length:">Length of the authentication-domain-name <dd>Length of the authentication-domain-name field
in octets.</t> in octets.</dd>
<dt>authentication-domain-name (variable length):</dt>
<t hangText="authentication-domain-name (variable length):">The <dd>The
authentication domain name of the encrypted DNS resolver. This ADN of the encrypted DNS resolver. This
field is formatted as specified in <xref section="10" field is formatted as specified in <xref section="10" target="RFC841
target="RFC8415" />. An example is provided in <xref 5"/>. An example is provided in <xref target="fqdn"/>.</dd>
target="fqdn" />.</t> <dt>Addr Length:</dt>
<dd>Length of included IPv4 addresses in
<t hangText="Addr Length:">Length of included IPv4 addresses in octets. When present, it <bcp14>MUST</bcp14> be a multiple of 4.</dd
octets. When present, it MUST be a multiple of 4.</t> >
<dt>IPv4 Address(es) (variable length):</dt>
<t hangText="IPv4 Address(es) (variable length):">Indicates one or <dd>
<t>Indicates one or
more IPv4 addresses to reach the encrypted DNS resolver. Both more IPv4 addresses to reach the encrypted DNS resolver. Both
private and public IPv4 addresses can be included in this field. private and public IPv4 addresses can be included in this field.
The format of this field is shown in <xref target="v4" />. This The format of this field is shown in <xref target="v4"/>. This
format assumes that an IPv4 address is encoded as format assumes that an IPv4 address is encoded as
a1.a2.a3.a4.<figure align="center" anchor="v4" a1.a2.a3.a4.</t>
title="Format of the IPv4 Addresses Field"> <figure anchor="v4">
<artwork align="center"><![CDATA[0 8 16 24 32 4 <name>Format of the IPv4 Address(es) Field</name>
0 48 <artwork align="center"><![CDATA[
0 8 16 24 32 40 48
+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+--
| a1 | a2 | a3 | a4 | a1 | a2 | ... | a1 | a2 | a3 | a4 | a1 | a2 | ...
+-----+-----+-----+-----+-----+-----+-- +-----+-----+-----+-----+-----+-----+--
IPv4 Address 1 IPv4 Address 2 ... ]]></artwork> IPv4 Address 1 IPv4 Address 2 ...
</figure></t> ]]></artwork>
</figure>
<t </dd>
hangText="Service Parameters (SvcParams) (variable length):">Specifi <dt>Service Parameters (SvcParams) (variable length):</dt>
es <dd>
<t>Specifies
a set of service parameters that are encoded following the rules a set of service parameters that are encoded following the rules
in <xref section="2.1" target="I-D.ietf-dnsop-svcb-https" />. in <xref section="2.2" target="RFC9460"/>.
Service parameters may include, for example, a list of ALPN Service parameters may include, for example, a list of ALPN
protocol identifiers or alternate port numbers. This field SHOULD protocol identifiers or alternate port numbers. This field <bcp14>SH
include at least "alpn" SvcParam. The "alpn" SvcParam may not be OULD</bcp14>
include at least the "alpn" SvcParam. The "alpn" SvcParam may not be
required in contexts such as a variant of DNS over CoAP where required in contexts such as a variant of DNS over CoAP where
messages are encrypted using OSCORE. The service parameters MUST messages are encrypted using OSCORE. The service parameters
NOT include "ipv4hint" or "ipv6hint" SvcParams as they are <bcp14>MUST NOT</bcp14> include "ipv4hint" or "ipv6hint" SvcParams,
superseded by the included IP addresses.<vspace as they are
blankLines="1" />If no port service parameter is included, this superseded by the included IP addresses.</t>
indicates that default port numbers should be used. <vspace <t>If no port service parameter is included, this
blankLines="1" />The length of this field is ('DNR Instance Data indicates that default port numbers should be used. </t>
<t>The length of this field is ('DNR Instance Data
Length' - 4 - 'ADN Length' - 'Addr Length').</t> Length' - 4 - 'ADN Length' - 'Addr Length').</t>
</list></t> </dd>
</dl>
<t>Note that "Addr Length", "IPv4 Address(es)", and "Service <t>Note that the "Addr Length", "IPv4 Address(es)", and "Service
Parameters (SvcParams)" fields are not present if the ADN-only mode is Parameters (SvcParams)" fields are not present if the ADN-only mode is
used (<xref target="adn-only" />).</t> used (<xref target="adn-only"/>).</t>
<t>OPTION_V4_DNR is a concatenation-requiring option. As such, the <t>OPTION_V4_DNR is a concatenation-requiring option. As such, the
mechanism specified in <xref target="RFC3396" /> MUST be used if mechanism specified in <xref target="RFC3396"/> <bcp14>MUST</bcp14> be u sed if
OPTION_V4_DNR exceeds the maximum DHCPv4 option size of 255 OPTION_V4_DNR exceeds the maximum DHCPv4 option size of 255
octets.</t> octets.</t>
</section> </section>
<section>
<section title="DHCPv4 Client Behavior"> <name>DHCPv4 Client Behavior</name>
<t>To discover an encrypted DNS resolver, the DHCPv4 client requests <t>To discover an encrypted DNS resolver, the DHCPv4 client requests
the encrypted DNS resolver by including OPTION_V4_DNR in a Parameter the encrypted DNS resolver by including OPTION_V4_DNR in a Parameter
Request List option <xref target="RFC2132" />.</t> Request List option <xref target="RFC2132"/>.</t>
<t>The DHCPv4 client <bcp14>MUST</bcp14> be prepared to receive multiple
<t>The DHCPv4 client MUST be prepared to receive multiple DNR instance "DNR Instance
data in the OPTION_V4_DNR option; each instance is to be treated as a Data" field entries in the OPTION_V4_DNR option; each instance is to be
separate encrypted DNS resolver. These instances MUST be processed treated as a
following their service priority (i.e., smaller service priority separate encrypted DNS resolver. These instances <bcp14>MUST</bcp14> be
processed
following their service priority (i.e., a smaller service priority value
indicates a higher preference).</t> indicates a higher preference).</t>
<t>The DHCPv4 client <bcp14>MUST</bcp14> silently discard any OPTION_V4_
<t>The DHCPv4 client MUST silently discard any OPTION_V4_DNR that DNR that
fails to pass the validation steps defined in <xref fails to pass the validation steps defined in <xref target="VC"/>.</t>
target="VC" />.</t> <t>The DHCPv4 client <bcp14>MUST</bcp14> silently discard multicast and
host loopback
<t>The DHCPv4 client MUST silently discard multicast and host loopback
addresses conveyed in OPTION_V4_DNR.</t> addresses conveyed in OPTION_V4_DNR.</t>
</section> </section>
</section> </section>
<section anchor="RA">
<section anchor="RA" title="IPv6 RA Encrypted DNS Option"> <name>IPv6 RA Encrypted DNS Option</name>
<t /> <section anchor="RA-ADN">
<name>Option Format</name>
<section anchor="RA-ADN" title="Option Format"> <t>This section defines a new Neighbor Discovery option <xref target="RF
<t>This section defines a new Neighbor Discovery option <xref C4861"/>: the IPv6 RA Encrypted DNS option. This option is
target="RFC4861" />: IPv6 RA Encrypted DNS option. This option is useful in contexts similar to those discussed in <xref section="1.1" tar
useful in contexts similar to those discussed in <xref section="1.1" get="RFC8106"/>.</t>
target="RFC8106" />.</t>
<t>The format of the IPv6 RA Encrypted DNS option is illustrated in <t>The format of the IPv6 RA Encrypted DNS option is illustrated in
<xref target="ra_dns" />.</t> <xref target="ra_dns"/>.</t>
<figure anchor="ra_dns">
<t> <name>RA Encrypted DNS Option</name>
<figure anchor="ra_dns" title="RA Encrypted DNS Option"> <artwork align="center"><![CDATA[
<artwork align="center"><![CDATA[ 0 1 0 1 2 3
2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBA3 | Length | Service Priority | | Type | Length | Service Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ADN Length | | | ADN Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ authentication-domain-name ~ ~ authentication-domain-name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Length | | | Addr Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ipv6-address(es) ~ ~ ipv6-address(es) ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | SvcParams Length | | | SvcParams Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Service Parameters (SvcParams) ~ ~ Service Parameters (SvcParams) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
</t> <t>The fields of the option shown in <xref target="ra_dns"/> are as
follows:</t>
<t>The fields of the option shown in <xref target="ra_dns" /> are as <dl newline="false" spacing="normal">
follows:<list style="hanging"> <dt>Type:</dt>
<t hangText="Type:">8-bit identifier of the Encrypted DNS option <dd>8-bit identifier of the Encrypted DNS option
as assigned by IANA (TBA3, see <xref target="iana7" />).</t> as assigned by IANA (144; see <xref target="iana7"/>).</dd>
<dt>Length:</dt>
<t hangText="Length:">8-bit unsigned integer. The length of the <dd>8-bit unsigned integer. The length of the
option (including the Type and Length fields) is in units of 8 option (including the Type and Length fields) is in units of 8
octets.</t> octets.</dd>
<dt>Service Priority:</dt>
<t hangText="Service Priority:">16-bit unsigned integer. The <dd>16-bit unsigned integer. The priority of this Encrypted DNS optio
priority of this Encrypted DNS option instance compared to other n instance compared to other instances. This field is interpreted following the
instances. This field is interpreted following the rules specified rules specified
in <xref section="2.4.1" in <xref section="2.4.1" target="RFC9460"/>.</dd>
target="I-D.ietf-dnsop-svcb-https" />.</t> <dt>Lifetime:</dt>
<dd>
<t hangText="Lifetime:">32-bit unsigned integer. The maximum time <t>32-bit unsigned integer. This represents the maximum time
in seconds (relative to the time the packet is received) over in seconds (relative to the time the packet is received) over
which the discovered Authentication Domain Name is valid. <vspace which the discovered ADN is valid. </t>
blankLines="1" />The value of Lifetime SHOULD by default be at <t>The value of Lifetime <bcp14>SHOULD</bcp14> by default be at
least 3 * MaxRtrAdvInterval, where MaxRtrAdvInterval is the least 3 * MaxRtrAdvInterval, where MaxRtrAdvInterval is the
maximum RA interval as defined in <xref target="RFC4861" />. maximum RA interval as defined in <xref target="RFC4861"/>.
<vspace blankLines="1" />A value of all one bits (0xffffffff) </t>
represents infinity. <vspace blankLines="1" />A value of zero <t>A value of all one bits (0xffffffff)
means that this Authentication Domain Name MUST no longer be represents infinity. </t>
<t>A value of zero
means that this ADN <bcp14>MUST</bcp14> no longer be
used.</t> used.</t>
</dd>
<t hangText="ADN Length:">16-bit unsigned integer. This field <dt>ADN Length:</dt>
<dd>16-bit unsigned integer. This field
indicates the length of the authentication-domain-name field in indicates the length of the authentication-domain-name field in
octets.</t> octets.</dd>
<dt>authentication-domain-name (variable length):</dt>
<t hangText="authentication-domain-name (variable length):">The <dd>The
authentication domain name of the encrypted DNS resolver. This ADN of the encrypted DNS resolver. This
field is formatted as specified in <xref section="10" field is formatted as specified in <xref section="10" target="RFC841
target="RFC8415" />.</t> 5"/>.</dd>
<dt>Addr Length:</dt>
<t hangText="Addr Length:">16-bit unsigned integer. This field <dd>16-bit unsigned integer. This field
indicates the length of enclosed IPv6 addresses in octets. When indicates the length of enclosed IPv6 addresses in octets. When
present, it MUST be a multiple of 16.</t> present, it <bcp14>MUST</bcp14> be a multiple of 16.</dd>
<dt>ipv6-address(es) (variable length):</dt>
<t hangText="ipv6-address(es) (variable length):">One or more IPv6 <dd>
addresses of the encrypted DNS resolver. An address can be <t>One or more IPv6
link-local, ULA, or GUA. <vspace blankLines="1" />All of the addresses of the encrypted DNS resolver. An address can be a
addresses share the same Lifetime value. Similar to <xref Link-Local address, a ULA, or a GUA. </t>
target="RFC8106" />, if it is desirable to have different Lifetime <t>All of the
addresses share the same Lifetime value. As also discussed in <xref
target="RFC8106"/>, if it is desirable to have different Lifetime
values per IP address, multiple Encrypted DNS options may be values per IP address, multiple Encrypted DNS options may be
used.<vspace blankLines="1" />The format of this field is shown in used.</t>
<xref target="v6add" />.</t> <t>The format of this field is shown in
<xref target="v6add"/>.</t>
<t hangText="SvcParams Length:">16-bit unsigned integer. This </dd>
field indicates the length of the Service Parameters field in <dt>SvcParams Length:</dt>
octets.</t> <dd>16-bit unsigned integer. This
field indicates the length of the "Service Parameters (SvcParams)" f
<t ield in
hangText="Service Parameters (SvcParams) (variable length):">Specifi octets.</dd>
es <dt>Service Parameters (SvcParams) (variable length):</dt>
<dd>
<t>Specifies
a set of service parameters that are encoded following the rules a set of service parameters that are encoded following the rules
in <xref section="2.1" target="I-D.ietf-dnsop-svcb-https" />. in <xref section="2.2" target="RFC9460"/>.
Service parameters may include, for example, a list of ALPN Service parameters may include, for example, a list of ALPN
protocol identifiers or alternate port numbers. This field SHOULD protocol identifiers or alternate port numbers. This field <bcp14>SH
include at least "alpn" SvcParam. The "alpn" SvcParam may not be OULD</bcp14>
include at least the "alpn" SvcParam. The "alpn" SvcParam may not be
required in contexts such as a variant of DNS over CoAP where required in contexts such as a variant of DNS over CoAP where
messages are encrypted using OSCORE. The service parameters MUST messages are encrypted using OSCORE. The service parameters
NOT include "ipv4hint" or "ipv6hint" SvcParams as they are <bcp14>MUST NOT</bcp14> include "ipv4hint" or "ipv6hint" SvcParams,
superseded by the included IP addresses.<vspace as they are
blankLines="1" />If no port service parameter is included, this superseded by the included IP addresses.</t>
<t>If no port service parameter is included, this
indicates that default port numbers should be used.</t> indicates that default port numbers should be used.</t>
</list></t> </dd>
</dl>
<t>Note that "Addr Length", "ipv6-address(es)", and "Service <t>Note that the "Addr Length", "ipv6-address(es)", and "Service
Parameters (SvcParams)" fields are not present if the ADN-only mode is Parameters (SvcParams)" fields are not present if the ADN-only mode is
used (<xref target="adn-only" />).</t> used (<xref target="adn-only"/>).</t>
<t>The option <bcp14>MUST</bcp14> be padded with zeros so that the full
<t>The option MUST be padded with zeros so that the full enclosed data enclosed data
is a multiple of 8 octets (<xref section="4.6" is a multiple of 8 octets (<xref section="4.6" target="RFC4861"/>).</t>
target="RFC4861" />).</t>
</section> </section>
<section>
<section title="IPv6 Host Behavior"> <name>IPv6 Host Behavior</name>
<t>The procedure for DNS configuration is the same as it is with any <t>The procedure for DNS configuration is the same as it is with any
other Neighbor Discovery option <xref target="RFC4861" />. In other Neighbor Discovery option <xref target="RFC4861"/>. In
addition, the host follows the same procedure as the one described in addition, the host follows the same procedure as the procedure described
<xref section="5.3.1" target="RFC8106" /> for processing received in
Encrypted DNS options with the formatting requirements in <xref <xref section="5.3.1" target="RFC8106"/> for processing received
target="RA-ADN" /> and validation checks in <xref target="VC" /> Encrypted DNS options, with the formatting requirements listed in <xref
substituted for the length and fields validation.</t> target="RA-ADN"/> and the validation checks listed in <xref target="VC"/>
substituted for length and field validations.</t>
<t>The host MUST be prepared to receive multiple Encrypted DNS options <t>The host <bcp14>MUST</bcp14> be prepared to receive multiple Encrypte
in RAs. These instances MUST be processed following their service d DNS options
priority (i.e., smaller service priority indicates a higher in RAs. These instances <bcp14>MUST</bcp14> be processed following their
service
priority (i.e., a smaller service priority value indicates a higher
preference).</t> preference).</t>
<t>The host <bcp14>MUST</bcp14> silently discard multicast and host loop
<t>The host MUST silently discard multicast and host loopback back
addresses conveyed in the Encrypted DNS options.</t> addresses conveyed in the Encrypted DNS options.</t>
</section> </section>
</section> </section>
<section anchor="Security">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t /> <section anchor="spoof">
<name>Spoofing Attacks</name>
<section anchor="spoof" title="Spoofing Attacks">
<t>DHCP/RA messages are not encrypted or protected against <t>DHCP/RA messages are not encrypted or protected against
modification within the LAN. Unless mitigated (described below), the modification within the LAN. Unless spoofing attacks are mitigated as de scribed below, the
content of DHCP and RA messages can be spoofed or modified by active content of DHCP and RA messages can be spoofed or modified by active
attackers, such as compromised devices within the local network. An attackers, such as compromised devices within the local network. An
active attacker (<xref section="3.3" target="RFC3552" />) can spoof active attacker (<xref section="3.3" target="RFC3552"/>) can spoof
the DHCP/RA response to provide the attacker's encrypted DNS resolver. the DHCP/RA response to provide the attacker's encrypted DNS resolver.
Note that such an attacker can launch other attacks as discussed in Note that such an attacker can launch other attacks as discussed in
<xref section="22" target="RFC8415" />. The attacker can get a domain <xref section="22" target="RFC8415"/>. The attacker can get a domain
name with a domain-validated public certificate from a CA and host an name with a domain-validated public certificate from a Certificate Autho
rity (CA) and host an
encrypted DNS resolver.</t> encrypted DNS resolver.</t>
<t>Attacks of spoofed or modified DHCP responses and RA messages by <t>Attacks of spoofed or modified DHCP responses and RA messages by
attackers within the local network may be mitigated by making use of attackers within the local network may be mitigated by making use of
the following mechanisms:</t> the following mechanisms:</t>
<dl newline="false" spacing="normal">
<t> <dt>DHCPv6-Shield <xref target="RFC7610"/>:</dt><dd>The network access
<list style="symbols">
<t>DHCPv6-Shield <xref target="RFC7610" />: the network access
node (e.g., a border router, a CPE, an Access Point (AP)) discards node (e.g., a border router, a CPE, an Access Point (AP)) discards
DHCP response messages received from any local endpoint.</t> DHCP response messages received from any local endpoint.</dd>
<dt>RA-Guard <xref target="RFC7113"/>:</dt><dd>The network access node
<t>RA-Guard <xref target="RFC7113" />: the network access node discards RA messages received from any local endpoint.</dd>
discards RAs messages received from any local endpoint.</t> <dt>Source Address Validation Improvement (SAVI) solution for DHCP
<xref target="RFC7513"/>:</dt><dd>The network access node filters pa
<t>Source Address Validation Improvement (SAVI) solution for DHCP ckets
<xref target="RFC7513" />: the network access node filters packets with forged source IP addresses.</dd>
with forged source IP addresses.</t> </dl>
</list>
</t>
<t>The above mechanisms would ensure that the endpoint receives the <t>The above mechanisms would ensure that the endpoint receives the
correct configuration information of the encrypted DNS resolvers correct configuration information of the encrypted DNS resolvers
selected by the DHCP server (or RA sender), but cannot provide any selected by the DHCP server (or RA sender), but these mechanisms cannot provide any
information about the DHCP server or the entity hosting the DHCP information about the DHCP server or the entity hosting the DHCP
server (or RA sender).</t> server (or RA sender).</t>
<t>Encrypted DNS sessions with rogue resolvers that spoof the IP <t>Encrypted DNS sessions with rogue resolvers that spoof the IP
address of a DNS resolver will fail because the DNS client will fail address of a DNS resolver will fail because the DNS client will fail
to authenticate that rogue resolver based upon PKIX authentication to authenticate that rogue resolver based upon PKIX authentication
<xref target="RFC6125" />, particularly the authentication domain name <xref target="RFC6125"/>, particularly the ADN
in the Encrypted DNS Option. DNS clients that ignore authentication in the Encrypted DNS option. DNS clients that ignore authentication
failures and accept spoofed certificates will be subject to attacks failures and accept spoofed certificates will be subject to attacks
(e.g., redirect to malicious resolvers, intercept sensitive data).</t> (e.g., attacks that redirect to malicious resolvers or intercept sensiti ve data).</t>
</section> </section>
<section>
<section title="Deletion Attacks"> <name>Deletion Attacks</name>
<t>If the DHCP responses or RAs are dropped by the attacker, the <t>If the DHCP responses or RAs are dropped by the attacker, the
client can fall back to use a preconfigured encrypted DNS resolver. client can fall back to using a preconfigured encrypted DNS resolver.
However, the use of policies to select resolvers is out of the scope However, the use of policies to select resolvers is beyond the scope
of this document.</t> of this document.</t>
<t>Note that deletion attacks are not specific to DHCP/RA.</t>
<t>Note that deletion attack is not specific to DHCP/RA.</t>
</section> </section>
<section>
<section title="Passive Attacks"> <name>Passive Attacks</name>
<t>A passive attacker (<xref section="3.2" target="RFC3552" />) can <t>A passive attacker (<xref section="3.2" target="RFC3552"/>) can
identify a host is using DHCP/RA to discover an encrypted DNS resolver determine that a host is using DHCP/RA to discover an encrypted DNS reso
and can infer that host is capable of using DoH/DoT/DoQ to encrypt DNS lver
and can infer that the host is capable of using DoH/DoT/DoQ to encrypt D
NS
messages. However, a passive attacker cannot spoof or modify DHCP/RA messages. However, a passive attacker cannot spoof or modify DHCP/RA
messages.</t> messages.</t>
</section> </section>
<section>
<section title="Wireless Security - Authentication Attacks"> <name>Wireless Security - Authentication Attacks</name>
<t>Wireless LAN (WLAN) as frequently deployed in local networks (e.g., <t>Wireless LANs (WLANs), frequently deployed in local networks (e.g.,
home networks) is vulnerable to various attacks (e.g., <xref home networks), are vulnerable to various attacks (e.g., <xref target="E
target="Evil-Twin" />, <xref target="Krack" />, <xref vil-Twin"/>, <xref target="Krack"/>, <xref target="Dragonblood"/>). Because of t
target="Dragonblood" />). Because of these attacks, only hese attacks, only
cryptographically authenticated communications are trusted on WLANs. cryptographically authenticated communications are trusted on WLANs.
This means that any information (e.g., NTP server, DNS resolver, This means that any information (e.g., regarding NTP servers, DNS resolv
domain search list) provided by such networks via DHCP, DHCPv6, or RA ers, or
domain search lists) provided by such networks via DHCP, DHCPv6, or RA
is untrusted because DHCP and RA messages are not authenticated.</t> is untrusted because DHCP and RA messages are not authenticated.</t>
<t>If the pre-shared key (PSK) is the same for all clients that <t>If the pre-shared key (PSK) is the same for all clients that
connect to the same WLAN (e.g., WPA-PSK), the shared key will be connect to the same WLAN (e.g., Wi-Fi Protected Access Pre-Shared
Key (WPA-PSK)), the shared key will be
available to all nodes, including attackers. As such, it is possible available to all nodes, including attackers. As such, it is possible
to mount an active on-path attack. On-path attacks are possible within to mount an active on-path attack. On-path attacks are possible within
local networks because such a WLAN authentication lacks peer entity local networks because this form of WLAN authentication lacks peer entit y
authentication.</t> authentication.</t>
<t>This leads to the need for provisioning unique credentials for <t>This leads to the need for provisioning unique credentials for
different clients. Endpoints can be provisioned with unique different clients. Endpoints can be provisioned with unique
credentials (username and password, typically) provided by the local credentials (username and password, typically) provided by the local
network administrator to mutually authenticate to the local WLAN AP network administrator to mutually authenticate to the local WLAN AP
(e.g., 802.1x Wireless User Authentication on OpenWRT <xref (e.g., 802.1x Wireless User Authentication on OpenWrt <xref target="dot1
target="dot1x" />, EAP-pwd <xref target="RFC8146" />). Not all x"/>, EAP-pwd <xref target="RFC8146"/> ("EAP" stands for "Extensible Authenticat
endpoint devices (e.g., IoT devices) support 802.1x supplicant and ion Protocol")). Not all
endpoint devices (e.g., Internet of Things (IoT) devices) support 802.1x
supplicants and
need an alternate mechanism to connect to the local network. To need an alternate mechanism to connect to the local network. To
address this limitation, unique pre-shared keys can be created for address this limitation, unique PSKs can be created for
each such devices and WPA-PSK is used (e.g., <xref each such device and WPA-PSK is used (e.g., <xref target="IPSK"/>).</t>
target="IPSK" />).</t>
</section> </section>
</section> </section>
<section>
<section title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>Privacy considerations that are specific to DNR provisioning <t>Privacy considerations that are also specific to DNR provisioning
mechanisms are discussed in <xref section="23" target="RFC8415" /> or mechanisms are discussed in <xref section="23" target="RFC8415"/> and in
<xref target="RFC7824" />. Anonymity profiles for DHCP clients are <xref target="RFC7824"/>. Anonymity profiles for DHCP clients are
discussed in <xref target="RFC7844" />. The mechanism defined in this discussed in <xref target="RFC7844"/>. The mechanisms defined in this
document can be used to infer that a DHCP client or IPv6 host support document can be used to infer that a DHCP client or IPv6 host supports
encrypted DNS options, but does not explicitly reveal whether local DNS Encrypted DNS options, but these mechanisms do not explicitly reveal wheth
er local DNS
clients are able to consume these options or infer their encryption clients are able to consume these options or infer their encryption
capabilities. Other than that, this document does not expose more capabilities. Other than that, this document does not expose more
privacy information compared to Do53 discovery options.</t> privacy information compared to Do53 discovery options.</t>
<t>As discussed in <xref target="RFC9076"/>, the use of encrypted DNS
<t>As discussed in <xref target="RFC9076" />, the use of encrypted DNS
does not reduce the data available in the DNS resolver. For example, the does not reduce the data available in the DNS resolver. For example, the
reader may refer to <xref section="8" target="RFC8484" /> or <xref reader may refer to <xref section="8" target="RFC8484"/> or <xref section=
section="7" target="RFC9250" /> for a discussion on specific privacy "7" target="RFC9250"/> for a discussion on specific privacy
considerations to encrypted DNS.</t> considerations for encrypted DNS.</t>
</section> </section>
<section anchor="IANA">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t /> <section anchor="iana6">
<name>DHCPv6 Option</name>
<section anchor="iana6" title="DHCPv6 Option"> <t>IANA has assigned the following new DHCPv6 Option Code in
<t>IANA is requested to assign the following new DHCPv6 Option Code in the "Option Codes" registry maintained at <xref target="DHCPV6"/>.</t>
the registry maintained in <xref target="DHCPV6" />.</t> <table anchor="dhcpv6t">
<name>DHCPv6 Encrypted DNS Option</name>
<texttable anchor="dhcpv6t" title="DHCPv6 Encrypted DNS Option"> <thead>
<ttcol>Value</ttcol> <tr>
<th>Value</th>
<ttcol>Description</ttcol> <th>Description</th>
<th>Client ORO</th>
<ttcol>Client ORO</ttcol> <th>Singleton Option</th>
<th>Reference</th>
<ttcol>Singleton Option</ttcol> </tr>
</thead>
<ttcol>Reference</ttcol> <tbody>
<tr>
<c>TBA1</c> <td>144</td>
<td>OPTION_V6_DNR</td>
<c>OPTION_V6_DNR</c> <td>Yes</td>
<td>No</td>
<c>Yes</c> <td>RFC 9463</td>
</tr>
<c>No</c> </tbody>
</table>
<c>[ThisDocument]</c>
</texttable>
<t />
</section> </section>
<section anchor="iana4">
<name>DHCPv4 Option</name>
<t>IANA has assigned the following new DHCP Option Code in
the "BOOTP Vendor Extensions and DHCP Options" registry maintained at <x
ref target="BOOTP"/>.</t>
<table anchor="dhcpv4t">
<name>DHCPv4 Encrypted DNS Option</name>
<thead>
<tr>
<th>Tag</th>
<th>Name</th>
<th>Data Length</th>
<th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>162</td>
<td>OPTION_V4_DNR</td>
<td>N</td>
<td>Encrypted DNS Server</td>
<td>RFC 9463</td>
</tr>
</tbody>
</table>
</section>
<section anchor="iana7">
<name>Neighbor Discovery Option</name>
<t>IANA has assigned the following new IPv6 Neighbor
Discovery Option type in the "IPv6 Neighbor Discovery Option Formats"
subregistry under the "Internet Control Message Protocol version 6
(ICMPv6) Parameters" registry maintained at <xref target="ND"/>.</t>
<table anchor="ndt">
<name>Neighbor Discovery Encrypted DNS Option</name>
<thead>
<tr>
<th>Type</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>144</td>
<td>Encrypted DNS Option</td>
<td>RFC 9463</td>
</tr>
</tbody>
</table>
</section>
</section>
</middle>
<section anchor="iana4" title="DHCPv4 Option"> <back>
<t>IANA is requested to assign the following new DHCP Option Code in
the registry maintained in <xref target="BOOTP" />.</t>
<texttable anchor="dhcpv4t" title="DHCPv4 Encrypted DNS Option">
<ttcol>Tag</ttcol>
<ttcol>Name</ttcol>
<ttcol>Data Length</ttcol>
<ttcol>Meaning</ttcol> <displayreference target="I-D.pusateri-dhc-dns-driu" to="DNS-TLS-DHCPv6-Options" />
<ttcol>Reference</ttcol> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
861.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
415.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
132.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
106.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
396.xml"/>
<c>TBA2</c> <!-- draft-ietf-dnsop-svcb-https (RFC 9460) -->
<reference anchor='RFC9460' target='https://www.rfc-editor.org/info/rfc9460'>
<front>
<title>Service Binding and Parameter Specification via the DNS (DNS SVCB and
HTTPS Resource Records)</title>
<author initials='B' surname='Schwartz' fullname='Benjamin Schwartz'>
<organization />
</author>
<author initials='M' surname='Bishop' fullname='Mike Bishop'>
<organization />
</author>
<author initials='E' surname='Nygren' fullname='Erik Nygren'>
<organization />
</author>
<date year='2023' month='November' />
</front>
<seriesInfo name="RFC" value="9460"/>
<seriesInfo name="DOI" value="10.17487/RFC9460"/>
</reference>
<c>OPTION_V4_DNR</c> <!-- draft-ietf-add-svcb-dns (RFC 9461) -->
<reference anchor='RFC9461' target='https://www.rfc-editor.org/info/rfc9461'>
<front>
<title>Service Binding Mapping for DNS Servers</title>
<author initials="B." surname="Schwartz" fullname="Benjamin Schwartz">
<organization>Google LLC</organization>
</author>
<date month="November" year="2023"/>
</front>
<seriesInfo name="RFC" value="9461"/>
<seriesInfo name="DOI" value="10.17487/RFC9461"/>
</reference>
<c>N</c> </references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
310.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.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.6
125.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
646.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
610.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
113.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.8
484.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
250.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
731.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
552.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
513.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
146.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
227.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
969.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
786.xml"/>
<c>Encrypted DNS Server</c> <!-- draft-ietf-add-ddr (RFC 9462) -->
<reference anchor='RFC9462' target='https://www.rfc-editor.org/info/rfc9462'>
<front>
<title>Discovery of Designated Resolvers</title>
<author initials="T." surname="Pauly" fullname="Tommy Pauly">
<organization>Apple Inc.</organization>
</author>
<author initials="E." surname="Kinnear" fullname="Eric Kinnear">
<organization>Apple Inc.</organization>
</author>
<author initials="C. A." surname="Wood" fullname="Christopher A. Wood">
<organization>Cloudflare</organization>
</author>
<author initials="P." surname="McManus" fullname="Patrick McManus">
<organization>Fastly</organization>
</author>
<author initials="T." surname="Jensen" fullname="Tommy Jensen">
<organization>Microsoft</organization>
</author>
<date month="November" year="2023"/>
</front>
<seriesInfo name="RFC" value="9462"/>
<seriesInfo name="DOI" value="10.17487/RFC9462"/>
</reference>
<c>[ThisDocument]</c> <!-- draft-pusateri-dhc-dns-driu (Expired) -->
</texttable> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
</section> pusateri-dhc-dns-driu.xml"/>
<section anchor="iana7" title="Neighbor Discovery Option"> <!-- draft-ietf-add-split-horizon-authority (I-D Exists)
<t>IANA is requested to assign the following new IPv6 Neighbor ("Long way" to fix author initials) -->
Discovery Option type in the "IPv6 Neighbor Discovery Option Formats" <reference anchor="Local-DNS-Authority">
sub-registry under the "Internet Control Message Protocol version 6 <front>
(ICMPv6) Parameters" registry maintained in <xref target="ND" />.</t> <title>Establishing Local DNS Authority in Validated Split-Horizon Environme
nts</title>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
</author>
<author fullname="Kevin Smith" initials="K." surname="Smith">
</author>
<author fullname="Benjamin Schwartz" initials="B." surname="Schwartz">
</author>
<date day="8" month="March" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-add-split-horizon-authorit
y-04"/>
</reference>
<texttable anchor="ndt" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
title="Neighbor Discovery Encrypted DNS Option"> 801.xml"/>
<ttcol>Type</ttcol> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
076.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
824.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
844.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
613.xml"/>
<ttcol>Description</ttcol> <reference anchor="Evil-Twin" target="https://en.wikipedia.org/wiki/Evil
_twin_(wireless_networks)">
<front>
<title>Evil twin (wireless networks)</title>
<author>
<organization>Wikipedia</organization>
</author>
<date month="November" year="2022"/>
</front>
</reference>
<ttcol>Reference</ttcol> <reference anchor="Krack" target="https://dl.acm.org/doi/10.1145/3133956
.3134027">
<front>
<title>Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2</titl
e>
<author fullname="Mathy Vanhoef" initials="M." surname="Vanhoef">
<organization/>
</author>
<author fullname="Frank Piessens" initials="F." surname="Piessens">
<organization/>
</author>
<date month="October" year="2017"/>
</front>
<seriesInfo name="DOI" value="10.1145/3133956.3134027"/>
<refcontent>CCS '17: Proceedings of the 2017 ACM SIGSAC Conference on Co
mputer and Communications Security, pp. 1313-1328</refcontent>
</reference>
<c>TBA3</c> <reference anchor="Dragonblood" target="https://ieeexplore.ieee.org/docu
ment/9152782">
<front>
<title>Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and
EAP-pwd</title>
<author fullname="Mathy Vanhoef" initials="M" surname="Vanhoef">
<organization/>
</author>
<author fullname="Eyal Ronen" initials="E" surname="Ronen">
<organization/>
</author>
<date month="May" year="2020"/>
</front>
<seriesInfo name="DOI" value="10.1109/SP40000.2020.00031"/>
<refcontent>2020 IEEE Symposium on Security and Privacy (SP), San Franci
sco, pp. 517-533</refcontent>
</reference>
<c>Encrypted DNS Option</c> <reference anchor="IPSK" target="https://www.cisco.com/c/en/us/td/docs/w
ireless/controller/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.html">
<front>
<title>8.5 Identity PSK Feature Deployment Guide</title>
<author>
<organization>Cisco</organization>
</author>
<date month="December" year="2021"/>
</front>
</reference>
<c>[ThisDocument]</c> <reference anchor="dot1x" target="https://openwrt.org/docs/guide-user/ne
</texttable> twork/wifi/wireless.security.8021x">
<front>
<title>Introduction to 802.1X</title>
<author>
<organization>OpenWrt</organization>
</author>
<date month="December" year="2021"/>
</front>
</reference>
<reference anchor="DHCPV6" target="https://www.iana.org/assignments/dhcp
v6-parameters/">
<front>
<title>Option Codes</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<t /> <reference anchor="ND" target="https://www.iana.org/assignments/icmpv6-p
</section> arameters/">
</section> <front>
<title>IPv6 Neighbor Discovery Option Formats</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<section title="Acknowledgements"> <reference anchor="BOOTP" target="https://www.iana.org/assignments/bootp
<t>Many thanks to Christian Jacquenet and Michael Richardson for the -dhcp-parameters/">
review.</t> <front>
<title>BOOTP Vendor Extensions and DHCP Options</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<t>Thanks to Stephen Farrell, Martin Thomson, Vittorio Bertola, Stephane <reference anchor="TS.24008" target="https://www.3gpp.org/DynaReport/240
Bortzmeyer, Ben Schwartz, Iain Sharp, and Chris Box for the 08.htm">
<front>
<title>Technical Specification Group Core Network and Terminals; Mob
ile radio interface Layer 3 specification; Core network
protocols; Stage 3 (Release 18)</title>
<author>
<organization>3GPP</organization>
</author>
<date month="September" year="2023"/>
</front>
<refcontent>version 18.4.0</refcontent>
</reference>
</references>
</references>
<section numbered="false">
<name>Acknowledgments</name>
<t>Many thanks to <contact fullname="Christian Jacquenet"/> and <contact f
ullname="Michael Richardson"/> for their
reviews.</t>
<t>Thanks to <contact fullname="Stephen Farrell"/>, <contact fullname="Mar
tin Thomson"/>, <contact fullname="Vittorio Bertola"/>, <contact fullname="Stéph
ane Bortzmeyer"/>, <contact fullname="Ben Schwartz"/>, <contact fullname="Iain S
harp"/>, and <contact fullname="Chris Box"/> for their
comments.</t> comments.</t>
<t>Thanks to <contact fullname="Mark Nottingham"/> for the feedback on HTT
<t>Thanks to Mark Nottingham for the feedback on HTTP redirection that P redirection that
was discussed in previous versions of this specification.</t> was discussed in previous draft versions of this specification.</t>
<t>The use of DHCP as a candidate protocol to retrieve an ADN was
<t>The use of DHCP to retrieve an authentication domain name was mentioned in <xref section="7.3.1" target="RFC8310"/> and in an
discussed in <xref section="7.3.1" target="RFC8310" /> and in an Internet-Draft authored by <contact fullname="Tom Pusateri"/> and <contact
Internet-Draft authored by Tom Pusateri and Willem Toorop <xref fullname="Willem Toorop"/> <xref target="I-D.pusateri-dhc-dns-driu"/>.</t>
target="I-D.pusateri-dhc-dns-driu" />.</t> <t>Thanks to <contact fullname="Bernie Volz"/> for the review of the DHCP
part.</t>
<t>Thanks to Bernie Volz for the review of the DHCP part.</t> <t><contact fullname="Christian Amsüss"/> reported a case where the ALPN s
ervice parameter cannot
<t>Christian Amsuess reported a case where ALPN service parameter cannot
be used.</t> be used.</t>
<t>Thanks to <contact fullname="Andrew Campling"/> for the Shepherd review
<t>Thanks to Andrew Campling for the Shepherd review and Eric Vyncke for and <contact fullname="Éric Vyncke"/> for
the AD review.</t> the AD review.</t>
<t>Thanks to <contact fullname="Rich Salz"/> for the secdir reviews, <cont
<t>Thanks to Rich Salz for the secdir reviews, Joe Clarke for the act fullname="Joe Clarke"/> for the
ops-dir review, Robert Sparks for the artart review, and David Blacka opsdir review, <contact fullname="Robert Sparks"/> for the artart review,
and <contact fullname="David Blacka"/>
for the dnsdir review.</t> for the dnsdir review.</t>
<t>Thanks to <contact fullname="Lars Eggert"/>, <contact fullname="Roman D
<t>Thanks to Lars Eggert, Roman Danyliw, Erik Kline, Martin Duke, Robert anyliw"/>, <contact fullname="Erik Kline"/>, <contact fullname="Martin Duke"/>,
Wilton, Paul Wouters, and Zaheduzzaman Sarker for the IESG review.</t> <contact fullname="Robert Wilton"/>, <contact fullname="Paul Wouters"/>, and <co
ntact fullname="Zaheduzzaman Sarker"/> for the IESG review.</t>
</section> </section>
<section numbered="false">
<section title="Contributing Authors"> <name>Contributors</name>
<t />
<contact fullname="Nicolai Leymann"> <contact fullname="Nicolai Leymann">
<organization>Deutsche Telekom</organization> <organization>Deutsche Telekom</organization>
<address> <address>
<postal> <postal>
<street />
<city />
<region />
<code />
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>n.leymann@telekom.de</email> <email>n.leymann@telekom.de</email>
</address> </address>
</contact> </contact>
<contact fullname="Zhiwei Yan"> <contact fullname="Zhiwei Yan">
<organization>CNNIC</organization> <organization>CNNIC</organization>
<address> <address>
<postal> <postal>
<street>No.4 South 4th Street, Zhongguancun</street> <street>No.4 South 4th Street, Zhongguancun</street>
<city>Beijing</city> <city>Beijing</city>
<region/>
<region />
<code>100190</code> <code>100190</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>yan@cnnic.cn</email> <email>yan@cnnic.cn</email>
</address> </address>
</contact> </contact>
</section> </section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119.xml'?>
<?rfc include='reference.RFC.8174.xml'?>
<?rfc include='reference.RFC.4861.xml'?>
<?rfc include='reference.RFC.8415.xml'?>
<?rfc include='reference.RFC.2132.xml'?>
<?rfc include='reference.RFC.8106.xml'?>
<?rfc include='reference.RFC.3396.xml'?>
<?rfc include='reference.I-D.ietf-dnsop-svcb-https.xml'?>
<?rfc include='reference.I-D.ietf-add-svcb-dns.xml'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.8310.xml'?>
<?rfc include='reference.RFC.5280.xml'?>
<?rfc include='reference.RFC.8499.xml'?>
<?rfc include='reference.RFC.6125.xml'?>
<?rfc include='reference.RFC.3646.xml'?>
<?rfc include='reference.RFC.7610.xml'?>
<?rfc include='reference.RFC.7113.xml'?>
<?rfc include='reference.RFC.7858.xml'?>
<?rfc include='reference.RFC.8484.xml'?>
<?rfc include='reference.RFC.9250.xml'?>
<?rfc include='reference.RFC.6731.xml'?>
<?rfc include='reference.RFC.3552.xml'?>
<?rfc include='reference.RFC.7513.xml'?>
<?rfc include='reference.RFC.8146.xml'?>
<?rfc include='reference.RFC.7227.xml'?>
<?rfc include='reference.RFC.7969.xml'?>
<?rfc include='reference.RFC.4786.xml'?>
<?rfc include='reference.I-D.ietf-add-ddr.xml'?>
<?rfc include='reference.I-D.pusateri-dhc-dns-driu.xml'?>
<?rfc include='reference.I-D.ietf-add-split-horizon-authority.xml'?>
<?rfc include='reference.RFC.8801.xml'?>
<?rfc include='reference.RFC.9076.xml'?>
<?rfc include='reference.RFC.7824.xml'?>
<?rfc include='reference.RFC.7844.xml'?>
<?rfc include='reference.RFC.8613'?>
<reference anchor="Evil-Twin"
target="https://en.wikipedia.org/wiki/Evil_twin_(wireless_netwo
rks)">
<front>
<title>Evil twin (wireless networks)</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="Krack" target="https://www.krackattacks.com/">
<front>
<title>Key Reinstallation Attacks</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="2017" />
</front>
</reference>
<reference anchor="Dragonblood"
target="https://papers.mathyvanhoef.com/dragonblood.pdf">
<front>
<title>Dragonblood: Analyzing the Dragonfly Handshake of WPA3 and
EAP-pwd</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="IPSK"
target="https://www.cisco.com/c/en/us/td/docs/wireless/controll
er/technotes/8-5/b_Identity_PSK_Feature_Deployment_Guide.html">
<front>
<title>Identity PSK Feature Deployment Guide</title>
<author>
<organization>Cisco</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="dot1x"
target="https://openwrt.org/docs/guide-user/network/wifi/wirele
ss.security.8021x">
<front>
<title>Basic 802.1x Wireless User Authentication</title>
<author>
<organization>Cisco</organization>
</author>
<date day="" month="" year="" />
</front>
</reference>
<reference anchor="DHCPV6"
target="https://www.iana.org/assignments/dhcpv6-parameters/dhcp
v6-parameters.xhtml#dhcpv6-parameters-2">
<front>
<title>DHCPv6 Option Codes</title>
<author>
<organization />
</author>
<date />
</front>
</reference>
<reference anchor="ND"
target="https://www.iana.org/assignments/icmpv6-parameters/
icmpv6-parameters.xhtml#icmpv6-parameters-5">
<front>
<title>IPv6 Neighbor Discovery Option Formats</title>
<author>
<organization />
</author>
<date />
</front>
</reference>
<reference anchor="BOOTP"
target="https://www.iana.org/assignments/bootp-dhcp-parameters/
bootp-dhcp-parameters.xhtml#options">
<front>
<title>BOOTP Vendor Extensions and DHCP Options</title>
<author>
<organization />
</author>
<date />
</front>
</reference>
<reference anchor="TS.24008"
target="https://www.3gpp.org/DynaReport/24008.htm">
<front>
<title>Mobile radio interface Layer 3 specification; Core network
protocols; Stage 3 (Release 16)</title>
<author fullname="" surname="">
<organization>3GPP</organization>
</author>
<date day="0" month="December" year="2019" />
</front>
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 209 change blocks. 
958 lines changed or deleted 987 lines changed or added

This html diff was produced by rfcdiff 1.48.