<?xml version="1.0"encoding="US-ASCII"?> <!-- This template is for creating an Internet Draft using xml2rfc, which is available here: http://xml.resource.org. --> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- used by XSLT processors --> <!-- For a complete list and description of processing instructions (PIs), please see http://xml.resource.org/authoring/README.html. --> <!-- 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 strict="yes" ?> <!-- give errors regarding ID-nits and DTD validation --> <!-- control the table of contents (ToC) --> <?rfc toc="yes"?> <!-- generate a ToC --> <?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 -->encoding="UTF-8"?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-add-dnr-16" number="9463" submissionType="IETF" category="std" consensus="true"docName="draft-ietf-add-dnr-16"ipr="trust200902"submissionType="IETF">tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" updates="" obsoletes="" xml:lang="en" version="3"> <!-- xml2rfc v2v3 conversion 3.17.1 --> <front> <titleabbrev="Discovery of Network-designated Resolvers">DHCPabbrev="DNR">DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)</title> <seriesInfo name="RFC" value="9463"/> <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Boucadair"> <organization>Orange</organization> <address> <postal><street /><street/> <city>Rennes</city> <code>35000</code> <country>France</country> </postal> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="TirumaleswarReddy"Reddy.K" initials="T." role="editor"surname="Reddy">surname="Reddy.K"> <organization>Nokia</organization> <address> <postal><street /><street/> <country>India</country> </postal> <email>kondtir@gmail.com</email> </address> </author> <author fullname="Dan Wing" initials="D." surname="Wing"> <organizationabbrev="Citrix">Citrix Systems,abbrev="Cloud Software Group">Cloud Software Group Holdings, Inc.</organization> <address> <postal><street /> <country>USA</country><street/> <country>United States of America</country> </postal> <email>dwing-ietf@fuggles.com</email> </address> </author> <author fullname="Neil Cook" initials="N." surname="Cook"> <organization>Open-Xchange</organization> <address> <postal><street /> <country>UK</country><street/> <country>United Kingdom</country> </postal> <email>neil.cook@noware.co.uk</email> </address> </author> <author fullname="Tommy Jensen" initials="T." surname="Jensen"> <organization>Microsoft</organization> <address> <postal><street /> <country>USA</country><street/> <country>United States of America</country> </postal> <email>tojens@microsoft.com</email> </address> </author> <dateday="" month="" year=""year="2023" month="November" /><workgroup>ADD</workgroup><area>int</area> <workgroup>add</workgroup> <keyword>DNS</keyword> <keyword>service resolution</keyword> <keyword>encryption</keyword> <keyword>service discovery</keyword> <keyword>service provider</keyword> <keyword>network provider</keyword> <keyword>automation</keyword> <keyword>DoH</keyword> <keyword>DoT</keyword> <keyword>DoQ</keyword> <abstract><t>The<t>This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g.,DNS-over-HTTPS, DNS-over-TLS, DNS-over-QUIC).DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn anauthentication domain nameAuthentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers.</t> </abstract> </front> <middle> <sectionanchor="intro" title="Introduction">anchor="intro"> <name>Introduction</name> <t>This document focuses on the discovery of encrypted DNS resolvers that are using protocols such asDNS-over-HTTPSDNS over HTTPS (DoH) <xreftarget="RFC8484" />, DNS-over-TLStarget="RFC8484"/>, DNS over TLS (DoT) <xreftarget="RFC7858" />,target="RFC7858"/>, orDNS-over-QUICDNS over QUIC (DoQ) <xreftarget="RFC9250" />target="RFC9250"/> in local networks.</t> <t>In particular,thethis document specifies how a local encrypted DNS resolver can be discovered by connected hosts by means of DHCPv4 <xreftarget="RFC2132" />,target="RFC2132"/>, DHCPv6 <xreftarget="RFC8415" />,target="RFC8415"/>, and IPv6 Router Advertisement (RA) options <xreftarget="RFC4861" /> options.target="RFC4861"/>. These options are designed to convey the following information: the DNS Authentication Domain Name (ADN), a list of IP addresses, and a set of service parameters. This procedure is called Discovery of Network-designated Resolvers (DNR).</t> <t>The options defined in this document can be deployed in a variety of deployments (e.g., local networks with Customer Premises Equipment (CPEs) that may or may not be managed by an Internet Service Provider (ISP), or local networks with or without DNS forwarders).It is outProviding an inventory of such deployments is beyond the scope of thisdocument to provide an inventory of such deployments.</t>document.</t> <t>Resolver selection considerations are out of scope. Likewise, policies (including any interactions with users) are out of scope.</t> </section> <sectionanchor="notation" title="Terminology">anchor="notation"> <name>Terminology</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" />target="RFC2119"/> <xreftarget="RFC8174" />target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <t>This document makes use of the terms defined in <xreftarget="RFC8499" />.target="RFC8499"/>. The following additional terms are used:<list style="hanging"> <t hangText="Authentication</t> <dl newline="false" spacing="normal"> <dt>Authentication Domain Name(ADN):">refers(ADN):</dt> <dd>Refers to a domain name that is used by a DNS client to authenticate a DNSresolver.</t> <t hangText="ADN-only mode:">refersresolver.</dd> <dt>ADN-only mode:</dt> <dd>Refers to a DNS discovery mode where only the ADN of the DNS resolver is retrieved. See <xreftarget="adn-only" />.</t> <t hangText="Do53:">referstarget="adn-only"/>.</dd> <dt>Do53:</dt> <dd>Refers to unencryptedDNS.</t> <t hangText="DNR:">refersDNS.</dd> <dt>DNR:</dt> <dd>Refers to the procedure called Discovery of Network-designatedResolvers procedure.</t> <t hangText="Encrypted DNS:">refersResolvers.</dd> <dt>Encrypted DNS:</dt> <dd>Refers to a scheme where DNS exchanges are transported over an encrypted channel. Examplesof encrypted DNS areinclude DoT, DoH,or DoQ.</t> <t hangText="Encryptedand DoQ.</dd> <dt>Encrypted DNSresolver:">refersresolver:</dt> <dd>Refers to a DNS resolver that supports any encrypted DNSscheme.</t> <t hangText="Encryptedscheme.</dd> <dt>Encrypted DNSoptions:">refersoptions:</dt> <dd>Refers to the options defined inSections <xrefSections <xref format="counter"target="DHCPv6" />,target="DHCPv6"/>, <xref format="counter"target="DHCP" />,target="DHCP"/>, and <xref format="counter"target="RA" />.</t> <t hangText="DHCP:">referstarget="RA"/>.</dd> <dt>DHCP:</dt> <dd>Refers to both DHCPv4 andDHCPv6.</t> </list></t>DHCPv6.</dd> </dl> </section> <sectionanchor="RI" title="Overview">anchor="RI"> <name>Overview</name> <t>This document describes how a DNS client can discover local encrypted DNS resolvers using DHCP(Sections <xref(Sections <xref format="counter"target="DHCPv6" />target="DHCPv6"/> and <xref format="counter"target="DHCP" />)target="DHCP"/>) and Neighbor Discovery protocol (<xreftarget="RA" />):target="RA"/>) Encrypted DNS options.</t> <t>These options configure anauthentication domain name,ADN, a list of IP addresses, and a set of service parameters of the encrypted DNS resolver. More information about the design of these options is provided in the following subsections.</t> <sectionanchor="rationale" title="Configurationanchor="rationale"> <name>Configuration Data for EncryptedDNS"> <t /> <section title="ADNDNS</name> <section> <name>ADN astheReference Identifier for DNSAuthentication">Authentication</name> <t>In order to allow for a PKIX-based authentication of the encrypted DNS resolver to the DNS client, the Encrypted DNS options are designed to always include anauthentication domain name.ADN. This ADN is presented as a reference identifier for DNS authentication purposes. This design accommodates the current best practices for issuing certificates as per <xref section="1.7.2"target="RFC6125" />:</t> <aside pn="aside-cert-authorities"> <t indent="0">Sometarget="RFC6125"/>:</t> <aside> <t>Some certification authorities issue server certificates based on IP addresses, but preliminary evidence indicates that such certificates are a very small percentage (less than 1%) of issued certificates.</t> </aside> </section><section title="Avoiding<section> <name>Avoiding Dependency on ExternalResolvers">Resolvers</name> <t>To avoid adding a dependency on another server to resolve the ADN, the Encrypted DNS options return the IP address(es) to locate an encrypted DNS resolver. These encrypted DNS resolvers may be hosted on the same IP address or distinct IP addresses. Such a decision is deployment specific.</t> <t>In order to optimize the size of discovery messages when all DNS resolvers terminate on the same IP address, early draft versions of this document considered relying upon the discovery mechanisms specified in <xreftarget="RFC2132" /><xref target="RFC3646" /><xref target="RFC8106" />target="RFC2132"/>, <xref target="RFC3646"/>, and <xref target="RFC8106"/> to retrieve a list of IP addresses to reach their DNS resolvers. Nevertheless, this approach requires a client that supports more than one encrypted DNS protocol (e.g., DoH and DoT) to probe that list of IP addresses. To avoid suchaprobing, the options defined inSections <xrefSections <xref format="counter"target="DHCPv6" />,target="DHCPv6"/>, <xref format="counter"target="DHCP" />,target="DHCP"/>, and <xref format="counter"target="RA" />target="RA"/> associate an encrypted DNS protocol with an IP address. No probing is required in such a design.</t> </section><section title="Single<section> <name>Single vs. Multiple IPAddresses">Addresses</name> <t>A list of IP addresses to reach an encrypted DNS resolver may be returned in an Encrypted DNS option to accommodate current deployments relying upon primary and backup resolvers. Also, DNR can be used in contexts where other DNS redundancy schemes (e.g., anycast as discussed inBCP 126<xreftarget="RFC4786" />)target="RFC4786">BCP 126</xref>) are used.</t> <t>Whether one or more IP addresses are returned in an Encrypted DNS option is deployment specific. For example, a router embedding a recursive server or a forwarder has to include one single IP address pointing to one of its LAN-facing interfaces. Typically, this IP address can be a private IPv4 address, alink-localLink-Local address,aan IPv6 Unique LocalIPv6 unicastAddress (ULA), or a Global Unicast Address (GUA).</t> <t>If multiple IP addresses are to be returned in an Encrypted DNS option, these addresses are returned, orderedin the preferenceby preference, for use by the client.</t> </section><section title="Why<section> <name>Why Not Separate Options for the ADN and IPAddresses?">Addresses?</name> <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 with an ADN conveyed in another option will be required if, for example, more than one ADN is supported by the network.</t> </section><section title="Service Parameters"><section> <name>Service Parameters</name> <t>Because distinct encrypted DNS protocols (e.g., DoT, DoH, and DoQ) may be provisioned by a network andthatsome of these protocols may make use of customized port numbers instead of defaultones,port numbers, the Encrypted DNS options are designed to return a set of service parameters. These parameters are encoded following the same rules for encoding SvcParams using the wire format specified in <xrefsection="2.1" target="I-D.ietf-dnsop-svcb-https" />.section="2.2" target="RFC9460"/>. This encoding approach may increase the size of theoptionsoptions, but it has the merit of relying upon an existing IANA registry and, thus, accommodating new encrypted DNS protocols and service parameters that may be defined in the future.</t> <t>The following service parametersMUST<bcp14>MUST</bcp14> be supported by a DNR implementation:</t><t> <list style="hanging"> <t hangText="alpn:">Used<dl newline="false" spacing="normal"> <dt>alpn:</dt> <dd>Used to indicate the set of supported protocols (<xref section="7.1"target="I-D.ietf-dnsop-svcb-https" />).</t> <t hangText="port:">Usedtarget="RFC9460"/>).</dd> <dt>port:</dt> <dd>Used to indicate the target port number for the encrypted DNS connection (<xref section="7.2"target="I-D.ietf-dnsop-svcb-https" />).</t> </list> </t>target="RFC9460"/>).</dd> </dl> <t>In addition, the following service parameter isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to be supported by a DNRimplementation:<list style="hanging"> <t hangText="dohpath:">Usedimplementation:</t> <dl newline="false" spacing="normal"> <dt>dohpath:</dt> <dd>Used to supply a relative DoH URI Template (<xref section="5.1"target="I-D.ietf-add-svcb-dns" />).</t> </list></t> <t />target="RFC9461"/>).</dd> </dl> </section> <sectionanchor="adn-only" title="ADN Only Mode">anchor="adn-only"> <name>ADN-Only Mode</name> <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 supplied to a hostSHOULD<bcp14>SHOULD</bcp14> be used because the Encrypted DNS options are self-contained and do not require any additional DNS queries. The reader may refer to <xreftarget="RFC7969" />target="RFC7969"/> for an overview of advanced capabilities that are supported by DHCP servers to populate configuration data (e.g., issue DNS queries).</t> <t>In contexts where putting additional complexity on requesting hosts is acceptable, returning an ADN only can be considered. The supplied ADN will be passed to a local resolution library (a DNS client,typically)typically), which will then issue Service Binding (SVCB) queries <xreftarget="I-D.ietf-add-svcb-dns" />.target="RFC9461"/>. These SVCB queries can be sent to the discovered encrypted DNS resolver itself or to the network-designated Do53 resolver. Note that this mode may be subject to active attacks, which can be mitigated by DNSSEC.</t><aside pn="aside-adn-passed"> <t indent="0">How<aside> <t>How an ADN is passed to a local resolution library is implementation specific.</t> </aside> </section><section title="Encrypted<section> <name>Ordering of Encrypted DNSOptions Ordering">Options</name> <t>The DHCP options defined inSections <xrefSections <xref format="counter"target="DHCPv6" />target="DHCPv6"/> and <xref format="counter"target="DHCP" />target="DHCP"/> follow the option ordering guidelines in <xref section="17"target="RFC7227" />.</t>target="RFC7227"/>.</t> <t>Likewise, the RA option (<xref format="default"target="RA" />)target="RA"/>) adheres to the recommendations in <xref section="9"target="RFC4861" />.</t>target="RFC4861"/>.</t> </section> <sectionanchor="VC" title="DNRanchor="VC"> <name>DNR ValidationChecks">Checks</name> <t>On receipt of an Encrypted DNS option, the DHCP client (or IPv6 host) makes the following validationchecks:<list style="symbols"> <t>Thechecks:</t> <ul spacing="normal"> <li>The ADN is present and encoded as per <xref section="10"target="RFC8415" />.</t>target="RFC8415"/>.</li> <li> <t>If additional data is supplied:<list style="symbols"> <t>the</t> <ul spacing="normal"> <li>The service parameters are encoded following the rules specified in <xrefsection="2.1" target="I-D.ietf-dnsop-svcb-https" />.</t> <t>thesection="2.2" target="RFC9460"/>.</li> <li>The option includes at least one valid IPaddress.</t> <t>theaddress.</li> <li>The service parameters do not include "ipv4hint" or "ipv6hint"service parameters.</t> </list></t> </list></t>parameters.</li> </ul> </li> </ul> <t>If any of the checks fail, the receiver discards the received Encrypted DNS option.</t> </section><section title="DNR<section> <name>DNR Information Using Other ProvisioningMechanisms">Mechanisms</name> <t>The provisioning mechanisms specified in this document may not be available in specific networks (e.g., some cellular networks exclusively use Protocol Configuration Options (PCOs) <xreftarget="TS.24008" />)target="TS.24008"/>) or may not be suitable in some contexts (e.g.,need for awhere securediscovery).discovery is needed). Other mechanisms may be considered in these contexts for the provisioning of encrypted DNS resolvers. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that at least the following DNR informationisbe made available to a requesting host:</t><t> <list style="symbols"> <t>A<ul spacing="normal"> <li>A service priority whenever the discovery mechanism does not rely on implicit ordering if multiple instances of the encrypted DNS areused.</t> <t>An authentication domain name.used.</li> <li>An ADN. This parameter ismandatory.</t> <t>Amandatory.</li> <li>A list of IP addresses to locate the encrypted DNSresolver.</t> <t>Aresolver.</li> <li>A set of serviceparameters.</t> </list> </t>parameters.</li> </ul> </section> </section><section title="Handling<section> <name>Handling Configuration DataConflicts">Conflicts</name> <t>Iftheencrypted DNSisresolvers are discovered by a host using both RA and DHCP, the rules discussed in <xref section=" 5.3.1"target="RFC8106" /> MUSTtarget="RFC8106"/> <bcp14>MUST</bcp14> be followed.</t> <t>DHCP/RA options to discover encrypted DNS resolvers(including,(including DoH URI Templates) takes precedence over Discovery of Designated Resolvers (DDR) <xreftarget="I-D.ietf-add-ddr" />target="RFC9462"/>, since DDR uses Do53 to an external DNS resolver, which is susceptible to both internal and external attacks whereas DHCP/RA is typically protected using the mechanisms discussed in <xreftarget="spoof" />.</t>target="spoof"/>.</t> <t>If a client learns both Do53 and encrypted DNS resolvers from the same network, and absent explicit configuration otherwise, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that the clientusesuse the encrypted DNS resolvers for that network. If the client cannot establish an authenticated and encrypted connection with the encrypted DNS resolver, it may fall back to using the Do53 resolver.</t> </section><section title="Validating<section> <name>Validating DiscoveredResolvers">Resolvers</name> <t>This section describes a set of validation checks to confirm that an encrypted DNS resolver matches what is provided using DNR (e.g., DHCP or RA). Such validation checks do not intend to validate the security of the DNR provisioning mechanisms or the user's trust relationship to the network.</t> <t>If the local DNS client supports one of the discovered encrypted DNS protocols identified byApplication LayerApplication-Layer Protocol Negotiation (ALPN) protocol identifiers (orotheranother service parameter that indicates some other protocol disambiguation mechanism), the DNS client establishes an encrypted DNS session following the service priority of the discovered encrypted resolvers.</t> <t>The DNS client verifies the connection based on PKIX validation <xreftarget="RFC5280" />target="RFC5280"/> of the DNS resolver certificate and uses the validation techniques as described in <xreftarget="RFC6125" />target="RFC6125"/> to compare theauthentication domain nameADN conveyed in the Encrypted DNS options to the certificate provided (see <xref section="8.1"target="RFC8310" />target="RFC8310"/> for more details). The DNS client uses the default system or application PKI trust anchors unless configured otherwise to use explicit trust anchors. ALPN-related considerations can be found in <xrefsection="6.1" target="I-D.ietf-dnsop-svcb-https" />. Operationsection="7.1" target="RFC9460"/>. Operational considerations related tocheckchecking the revocation status of the certificate of an encrypted DNS resolver are discussed inSection 10 of<xref target="RFC8484"/>.</t>sectionFormat="of" section="10"/>.</t> </section><section title="Multihoming Considerations"><section> <name>Multihoming Considerations</name> <t>Devices may be connected to multiplenetworks;networks, each providing their own DNS configuration using the discovery mechanisms specified in this document. Nevertheless,it is outdiscussing DNS selection of multi-interfaced devices is beyond the scope of thisspecification to discuss DNS selection of multi-interface devices.specification. Such considerations fall under the generic issue of handling multiple provisioning sources andwhichshould not bedealt withinprocessed in each optionseparatelyseparately, as per the recommendation in <xref section="12"target="RFC7227" />.</t>target="RFC7227"/>.</t> <t>The reader may refer to <xreftarget="RFC6731" />target="RFC6731"/> for a discussion of DNS selection issues and an example of DNS resolver selection for multi-interfaced devices. Also, the reader may refer to <xreftarget="I-D.ietf-add-split-horizon-authority" />target="Local-DNS-Authority"/> for a discussion on how DNR and ProvisioningDomains (PvDs) KeyDomain (PvD) key "dnsZones" (<xref section="4.3"target="RFC8801" />)target="RFC8801"/>) can be used inSplit DNS"split DNS" environments (<xref section="6"target="RFC8499" />).</t>target="RFC8499"/>).</t> </section> </section> <sectionanchor="DHCPv6" title="DHCPv6anchor="DHCPv6"> <name>DHCPv6 Encrypted DNSOption"> <t />Option</name> <sectionanchor="DHCPv6-ADN" title="Option Format">anchor="DHCPv6-ADN"> <name>Option Format</name> <t>The format of the DHCPv6 Encrypted DNS option is shown in <xreftarget="dhcpv6-format" />.</t> <t><figure align="center" anchor="dhcpv6-format" title="DHCPv6target="dhcpv6-format"/>.</t> <figure anchor="dhcpv6-format"> <name>DHCPv6 Encrypted DNSOption"> <artwork><![CDATA[Option</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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_V6_DNR | Option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Priority | ADN Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ authentication-domain-name ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ipv6-address(es) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Service Parameters (SvcParams) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure>The</figure> <t>The fields of the option shown in <xreftarget="dhcpv6-format" />target="dhcpv6-format"/> are asfollows:<list style="hanging"> <t hangText="Option-code:">OPTION_V6_DNR (TBA1,follows:</t> <dl newline="false" spacing="normal"> <dt>Option-code:</dt> <dd>OPTION_V6_DNR (144; see <xreftarget="iana6" />)</t> <t hangText="Option-length:">Lengthtarget="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 is included in theoption.</t> <t hangText="Service Priority:">Theoption.</dd> <dt>Service Priority:</dt> <dd>The priority of this OPTION_V6_DNR instance compared to other instances. This 16-bit unsigned integer is interpreted following the rules specified in <xref section="2.4.1"target="I-D.ietf-dnsop-svcb-https" />.</t> <t hangText="ADN Length:">Lengthtarget="RFC9460"/>.</dd> <dt>ADN Length:</dt> <dd>Length of the authentication-domain-name field inoctets.</t> <t hangText="authentication-domain-nameoctets.</dd> <dt>authentication-domain-name (variablelength):">A fully qualified domain namelength):</dt> <dd> <t>A Fully Qualified Domain Name (FQDN) of the encrypted DNS resolver. This field is formatted as specified in <xref section="10"target="RFC8415" />.<vspace blankLines="1" />Antarget="RFC8415"/>.</t> <t>An example of the authentication-domain-name encoding is shown in <xreftarget="fqdn" />.target="fqdn"/>. This example conveys the FQDN "doh1.example.com.", and the resultingOption-lengthADN Length field is18.<figure anchor="fqdn" title="An18.</t> <figure anchor="fqdn"> <name>An Example of the DNS authentication-domain-nameEncoding">Encoding</name> <artworkalign="center"><![CDATA[+------+------+------+------+------+------+------+------+------+align="center"><![CDATA[ +------+------+------+------+------+------+------+------+------+ | 0x04 | d | o | h | 1 | 0x07 | e | x | a | +------+------+------+------+------+------+------+------+------+ | m | p | l | e | 0x03 | c | o | m | 0x00 | +------+------+------+------+------+------+------+------+------+ ]]></artwork></figure></t> <t hangText="Addr Length:">Length</figure> </dd> <dt>Addr Length:</dt> <dd>Length of enclosed IPv6 addresses in octets. When present, itMUST<bcp14>MUST</bcp14> be a multiple of16.</t> <t hangText="ipv6-address(es)16.</dd> <dt>ipv6-address(es) (variablelength):">Indicateslength):</dt> <dd> <t>Indicates one or more IPv6 addresses to reach the encrypted DNS resolver. An address can belink-local,a Link-Local address, a ULA, or a GUA. The format of this field is shown in <xreftarget="v6add" />.<figure align="center" anchor="v6add" title="Formattarget="v6add"/>.</t> <figure anchor="v6add"> <name>Format of theIPv6 Addresses Field"> <artwork><![CDATA[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 | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> </figure></t> <t hangText="Service+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure> </dd> <dt>Service Parameters (SvcParams) (variablelength):">Specifieslength):</dt> <dd> <t>Specifies a set of service parameters that are encoded following the rules in <xrefsection="2.1" target="I-D.ietf-dnsop-svcb-https" />.section="2.2" target="RFC9460"/>. Service parameters may include, for example, a list of ALPN protocol identifiers or alternate port numbers. This fieldSHOULD<bcp14>SHOULD</bcp14> include at least the "alpn" SvcParam. The "alpn" SvcParam may not be required in contexts such as a variant of DNS overCoAPthe Constrained Application Protocol (CoAP) where messages are encrypted using Object Security for Constrained RESTful Environments (OSCORE) <xreftarget="RFC8613" />.target="RFC8613"/>. The service parametersMUST NOT<bcp14>MUST NOT</bcp14> include "ipv4hint" or "ipv6hint"SvcParamsSvcParams, as they are superseded by the included IP addresses.<vspace blankLines="1" />If</t> <t>If no port service parameter is included, this indicates that default port numbers should be used. As a reminder, the default port number is 853 for DoT, 443 for DoH, and 853 forDoQ.<vspace blankLines="1" />TheDoQ.</t> <t>The length of this field is ('Option-length' - 6 - 'ADN Length' - 'Addr Length').</t></list></t></dd> </dl> <t>Note that the "Addr Length", "ipv6-address(es)", and "Service Parameters (SvcParams)" fields are not present if the ADN-only mode is used (<xreftarget="adn-only" />).</t>target="adn-only"/>).</t> </section><section title="DHCPv6<section> <name>DHCPv6 ClientBehavior">Behavior</name> <t>To discover an encrypted DNS resolver, the DHCPv6 clientMUST<bcp14>MUST</bcp14> include OPTION_V6_DNR in an Option Request Option (ORO),as in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6,per Sections <xref target="RFC8415" section="18.2.1" sectionFormat="bare"/>, <xref target="RFC8415" section="18.2.2" sectionFormat="bare"/>, <xref target="RFC8415" section="18.2.4" sectionFormat="bare"/>, <xref target="RFC8415" section="18.2.5" sectionFormat="bare"/>, <xref target="RFC8415" section="18.2.6" sectionFormat="bare"/>, and21.7 of<xref target="RFC8415"/>.</t>section="21.7" sectionFormat="bare"/> of <xref target="RFC8415"/>.</t> <t>The DHCPv6 clientMUST<bcp14>MUST</bcp14> be prepared to receive multiple instances of the OPTION_V6_DNR option; each option is to be treated as a separate encrypted DNS resolver. These instancesMUST<bcp14>MUST</bcp14> be processed following their service priority (i.e., a smaller service priority value indicates a higher preference).</t> <t>The DHCPv6 clientMUST<bcp14>MUST</bcp14> silently discard any OPTION_V6_DNR that fails to pass the validation steps defined in <xreftarget="VC" />.</t>target="VC"/>.</t> <t>The DHCPv6 clientMUST<bcp14>MUST</bcp14> silently discard multicast and host loopback addresses conveyed in OPTION_V6_DNR.</t> </section> </section> <sectionanchor="DHCP" title="DHCPv4anchor="DHCP"> <name>DHCPv4 Encrypted DNSOption"> <section title="Option Format">Option</name> <section> <name>Option Format</name> <t>The format of the DHCPv4 Encrypted DNS option is illustrated in <xreftarget="dhcpri_dns" />.</t> <t>target="dhcpri_dns"/>.</t> <figureanchor="dhcpri_dns" title="DHCPv4anchor="dhcpri_dns"> <name>DHCPv4 Encrypted DNSOption">Option</name> <artwork align="center"><![CDATA[ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_V4_DNR | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ DNR Instance Data #1 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- . ... . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ optional ~ DNR Instance Data #n ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- ]]></artwork> </figure></t><t>The fields of the option shown in <xreftarget="dhcpri_dns" />target="dhcpri_dns"/> are asfollows:<list style="hanging"> <t hangText="Code:">OPTION_V4_DNR (TBA2,follows:</t> <dl newline="false" spacing="normal"> <dt>Code:</dt> <dd>OPTION_V4_DNR (162; see <xreftarget="iana4" />).</t> <t hangText="Length:">Indicatestarget="iana4"/>).</dd> <dt>Length:</dt> <dd>Indicates the length of the enclosed data inoctets.</t> <t hangText="DNRoctets.</dd> <dt>DNR InstanceData:">IncludesData:</dt> <dd> <t>Includes the configuration data of an encrypted DNS resolver. The format of this field is shown in <xreftarget="dhcpri_dns2" />.target="dhcpri_dns2"/>. </t> <figureanchor="dhcpri_dns2" title="DNRanchor="dhcpri_dns2"> <name>DNR Instance DataFormat">Format</name> <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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADN Length | | +-+-+-+-+-+-+-+-+ | ~ authentication-domain-name ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Length | | +-+-+-+-+-+-+-+-+ | ~ IPv4 Address(es) ~ | +-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+ | ~Service Parameters (SvcParams) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork></figure><vspace blankLines="1" />When</figure> <t>When several encrypted DNS resolvers are to be included, the "DNR Instance Data" field is repeated.</t></list>The</dd> </dl> <t>The fields shown in <xreftarget="dhcpri_dns2" />target="dhcpri_dns2"/> are asfollows:<list style="hanging"> <t hangText="DNRfollows:</t> <dl newline="false" spacing="normal"> <dt>DNR Instance DataLength:">LengthLength:</dt> <dd>Length of all following data in octets. This field is set to ('ADN Length' + 3) when only an ADN is provided for a DNRinstance.</t> <t hangText="Service Priority:">Theinstance.</dd> <dt>Service Priority:</dt> <dd>The priority of this instance compared to other DNR instances. This 16-bit unsigned integer is interpreted following the rules specified in <xref section="2.4.1"target="I-D.ietf-dnsop-svcb-https" />.</t> <t hangText="ADN Length:">Lengthtarget="RFC9460"/>.</dd> <dt>ADN Length:</dt> <dd>Length of the authentication-domain-name field inoctets.</t> <t hangText="authentication-domain-nameoctets.</dd> <dt>authentication-domain-name (variablelength):">The authentication domain namelength):</dt> <dd>The ADN of the encrypted DNS resolver. This field is formatted as specified in <xref section="10"target="RFC8415" />.target="RFC8415"/>. An example is provided in <xreftarget="fqdn" />.</t> <t hangText="Addr Length:">Lengthtarget="fqdn"/>.</dd> <dt>Addr Length:</dt> <dd>Length of included IPv4 addresses in octets. When present, itMUST<bcp14>MUST</bcp14> be a multiple of4.</t> <t hangText="IPv44.</dd> <dt>IPv4 Address(es) (variablelength):">Indicateslength):</dt> <dd> <t>Indicates one or more IPv4 addresses to reach the encrypted DNS resolver. Both private and public IPv4 addresses can be included in this field. The format of this field is shown in <xreftarget="v4" />.target="v4"/>. This format assumes that an IPv4 address is encoded asa1.a2.a3.a4.<figure align="center" anchor="v4" title="Formata1.a2.a3.a4.</t> <figure anchor="v4"> <name>Format of the IPv4Addresses Field">Address(es) Field</name> <artworkalign="center"><![CDATA[0align="center"><![CDATA[ 0 8 16 24 32 40 48 +-----+-----+-----+-----+-----+-----+-- | a1 | a2 | a3 | a4 | a1 | a2 | ... +-----+-----+-----+-----+-----+-----+-- IPv4 Address 1 IPv4 Address 2 ... ]]></artwork></figure></t> <t hangText="Service</figure> </dd> <dt>Service Parameters (SvcParams) (variablelength):">Specifieslength):</dt> <dd> <t>Specifies a set of service parameters that are encoded following the rules in <xrefsection="2.1" target="I-D.ietf-dnsop-svcb-https" />.section="2.2" target="RFC9460"/>. Service parameters may include, for example, a list of ALPN protocol identifiers or alternate port numbers. This fieldSHOULD<bcp14>SHOULD</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 messages are encrypted using OSCORE. The service parametersMUST NOT<bcp14>MUST NOT</bcp14> include "ipv4hint" or "ipv6hint"SvcParamsSvcParams, as they are superseded by the included IPaddresses.<vspace blankLines="1" />Ifaddresses.</t> <t>If no port service parameter is included, this indicates that default port numbers should be used.<vspace blankLines="1" />The</t> <t>The length of this field is ('DNR Instance Data Length' - 4 - 'ADN Length' - 'Addr Length').</t></list></t></dd> </dl> <t>Note that the "Addr Length", "IPv4 Address(es)", and "Service Parameters (SvcParams)" fields are not present if the ADN-only mode is used (<xreftarget="adn-only" />).</t>target="adn-only"/>).</t> <t>OPTION_V4_DNR is a concatenation-requiring option. As such, the mechanism specified in <xreftarget="RFC3396" /> MUSTtarget="RFC3396"/> <bcp14>MUST</bcp14> be used if OPTION_V4_DNR exceeds the maximum DHCPv4 option size of 255 octets.</t> </section><section title="DHCPv4<section> <name>DHCPv4 ClientBehavior">Behavior</name> <t>To discover an encrypted DNS resolver, the DHCPv4 client requests the encrypted DNS resolver by including OPTION_V4_DNR in a Parameter Request List option <xreftarget="RFC2132" />.</t>target="RFC2132"/>.</t> <t>The DHCPv4 clientMUST<bcp14>MUST</bcp14> be prepared to receive multipleDNR instance data"DNR Instance Data" field entries in the OPTION_V4_DNR option; each instance is to be treated as a separate encrypted DNS resolver. These instancesMUST<bcp14>MUST</bcp14> be processed following their service priority (i.e., a smaller service priority value indicates a higher preference).</t> <t>The DHCPv4 clientMUST<bcp14>MUST</bcp14> silently discard any OPTION_V4_DNR that fails to pass the validation steps defined in <xreftarget="VC" />.</t>target="VC"/>.</t> <t>The DHCPv4 clientMUST<bcp14>MUST</bcp14> silently discard multicast and host loopback addresses conveyed in OPTION_V4_DNR.</t> </section> </section> <sectionanchor="RA" title="IPv6anchor="RA"> <name>IPv6 RA Encrypted DNSOption"> <t />Option</name> <sectionanchor="RA-ADN" title="Option Format">anchor="RA-ADN"> <name>Option Format</name> <t>This section defines a new Neighbor Discovery option <xreftarget="RFC4861" />:target="RFC4861"/>: the IPv6 RA Encrypted DNS option. This option is useful in contexts similar to those discussed in <xref section="1.1"target="RFC8106" />.</t>target="RFC8106"/>.</t> <t>The format of the IPv6 RA Encrypted DNS option is illustrated in <xreftarget="ra_dns" />.</t> <t>target="ra_dns"/>.</t> <figureanchor="ra_dns" title="RAanchor="ra_dns"> <name>RA Encrypted DNSOption">Option</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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TBA3Type | Length | Service Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ADN Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ authentication-domain-name ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ipv6-address(es) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | SvcParams Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Service Parameters (SvcParams) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure></t><t>The fields of the option shown in <xreftarget="ra_dns" />target="ra_dns"/> are asfollows:<list style="hanging"> <t hangText="Type:">8-bitfollows:</t> <dl newline="false" spacing="normal"> <dt>Type:</dt> <dd>8-bit identifier of the Encrypted DNS option as assigned by IANA(TBA3,(144; see <xreftarget="iana7" />).</t> <t hangText="Length:">8-bittarget="iana7"/>).</dd> <dt>Length:</dt> <dd>8-bit unsigned integer. The length of the option (including the Type and Length fields) is in units of 8octets.</t> <t hangText="Service Priority:">16-bitoctets.</dd> <dt>Service Priority:</dt> <dd>16-bit unsigned integer. The priority of this Encrypted DNS option instance compared to other instances. This field is interpreted following the rules specified in <xref section="2.4.1"target="I-D.ietf-dnsop-svcb-https" />.</t> <t hangText="Lifetime:">32-bittarget="RFC9460"/>.</dd> <dt>Lifetime:</dt> <dd> <t>32-bit unsigned integer.TheThis represents the maximum time in seconds (relative to the time the packet is received) over which the discoveredAuthentication Domain NameADN is valid.<vspace blankLines="1" />The</t> <t>The value of LifetimeSHOULD<bcp14>SHOULD</bcp14> by default be at least 3 * MaxRtrAdvInterval, where MaxRtrAdvInterval is the maximum RA interval as defined in <xreftarget="RFC4861" />. <vspace blankLines="1" />Atarget="RFC4861"/>. </t> <t>A value of all one bits (0xffffffff) represents infinity.<vspace blankLines="1" />A</t> <t>A value of zero means that thisAuthentication Domain Name MUSTADN <bcp14>MUST</bcp14> no longer be used.</t><t hangText="ADN Length:">16-bit</dd> <dt>ADN Length:</dt> <dd>16-bit unsigned integer. This field indicates the length of the authentication-domain-name field inoctets.</t> <t hangText="authentication-domain-nameoctets.</dd> <dt>authentication-domain-name (variablelength):">The authentication domain namelength):</dt> <dd>The ADN of the encrypted DNS resolver. This field is formatted as specified in <xref section="10"target="RFC8415" />.</t> <t hangText="Addr Length:">16-bittarget="RFC8415"/>.</dd> <dt>Addr Length:</dt> <dd>16-bit unsigned integer. This field indicates the length of enclosed IPv6 addresses in octets. When present, itMUST<bcp14>MUST</bcp14> be a multiple of16.</t> <t hangText="ipv6-address(es)16.</dd> <dt>ipv6-address(es) (variablelength):">Onelength):</dt> <dd> <t>One or more IPv6 addresses of the encrypted DNS resolver. An address can belink-local,a Link-Local address, a ULA, or a GUA.<vspace blankLines="1" />All</t> <t>All of the addresses share the same Lifetime value.Similar toAs also discussed in <xreftarget="RFC8106" />,target="RFC8106"/>, if it is desirable to have different Lifetime values per IP address, multiple Encrypted DNS options may beused.<vspace blankLines="1" />Theused.</t> <t>The format of this field is shown in <xreftarget="v6add" />.</t> <t hangText="SvcParams Length:">16-bittarget="v6add"/>.</t> </dd> <dt>SvcParams Length:</dt> <dd>16-bit unsigned integer. This field indicates the length of theService"Service Parameters (SvcParams)" field inoctets.</t> <t hangText="Serviceoctets.</dd> <dt>Service Parameters (SvcParams) (variablelength):">Specifieslength):</dt> <dd> <t>Specifies a set of service parameters that are encoded following the rules in <xrefsection="2.1" target="I-D.ietf-dnsop-svcb-https" />.section="2.2" target="RFC9460"/>. Service parameters may include, for example, a list of ALPN protocol identifiers or alternate port numbers. This fieldSHOULD<bcp14>SHOULD</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 messages are encrypted using OSCORE. The service parametersMUST NOT<bcp14>MUST NOT</bcp14> include "ipv4hint" or "ipv6hint"SvcParamsSvcParams, as they are superseded by the included IPaddresses.<vspace blankLines="1" />Ifaddresses.</t> <t>If no port service parameter is included, this indicates that default port numbers should be used.</t></list></t></dd> </dl> <t>Note that the "Addr Length", "ipv6-address(es)", and "Service Parameters (SvcParams)" fields are not present if the ADN-only mode is used (<xreftarget="adn-only" />).</t>target="adn-only"/>).</t> <t>The optionMUST<bcp14>MUST</bcp14> be padded with zeros so that the full enclosed data is a multiple of 8 octets (<xref section="4.6"target="RFC4861" />).</t>target="RFC4861"/>).</t> </section><section title="IPv6<section> <name>IPv6 HostBehavior">Behavior</name> <t>The procedure for DNS configuration is the same as it is with any other Neighbor Discovery option <xreftarget="RFC4861" />.target="RFC4861"/>. In addition, the host follows the same procedure as theoneprocedure described in <xref section="5.3.1"target="RFC8106" />target="RFC8106"/> for processing received Encrypted DNSoptionsoptions, with the formatting requirements listed in <xreftarget="RA-ADN" />target="RA-ADN"/> and the validation checks listed in <xreftarget="VC" />target="VC"/> substituted forthelength andfields validation.</t>field validations.</t> <t>The hostMUST<bcp14>MUST</bcp14> be prepared to receive multiple Encrypted DNS options in RAs. These instancesMUST<bcp14>MUST</bcp14> be processed following their service priority (i.e., a smaller service priority value indicates a higher preference).</t> <t>The hostMUST<bcp14>MUST</bcp14> silently discard multicast and host loopback addresses conveyed in the Encrypted DNS options.</t> </section> </section> <sectionanchor="Security" title="Security Considerations"> <t />anchor="Security"> <name>Security Considerations</name> <sectionanchor="spoof" title="Spoofing Attacks">anchor="spoof"> <name>Spoofing Attacks</name> <t>DHCP/RA messages are not encrypted or protected against modification within the LAN. Unless spoofing attacks are mitigated(described below),as described below, the content of DHCP and RA messages can be spoofed or modified by active attackers, such as compromised devices within the local network. An active attacker (<xref section="3.3"target="RFC3552" />)target="RFC3552"/>) can spoof the DHCP/RA response to provide the attacker's encrypted DNS resolver. Note that such an attacker can launch other attacks as discussed in <xref section="22"target="RFC8415" />.target="RFC8415"/>. The attacker can get a domain name with a domain-validated public certificate from aCACertificate Authority (CA) and host an encrypted DNS resolver.</t> <t>Attacks of spoofed or modified DHCP responses and RA messages by attackers within the local network may be mitigated by making use of the following mechanisms:</t><t> <list style="symbols"> <t>DHCPv6-Shield<dl newline="false" spacing="normal"> <dt>DHCPv6-Shield <xreftarget="RFC7610" />: thetarget="RFC7610"/>:</dt><dd>The network access node (e.g., a border router, a CPE, an Access Point (AP)) discards DHCP response messages received from any localendpoint.</t> <t>RA-Guardendpoint.</dd> <dt>RA-Guard <xreftarget="RFC7113" />: thetarget="RFC7113"/>:</dt><dd>The network access node discardsRAsRA messages received from any localendpoint.</t> <t>Sourceendpoint.</dd> <dt>Source Address Validation Improvement (SAVI) solution for DHCP <xreftarget="RFC7513" />: thetarget="RFC7513"/>:</dt><dd>The network access node filters packets with forged source IPaddresses.</t> </list> </t>addresses.</dd> </dl> <t>The above mechanisms would ensure that the endpoint receives the correct configuration information of the encrypted DNS resolvers 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 server (or RA sender).</t> <t>Encrypted DNS sessions with rogue resolvers that spoof the IP address of a DNS resolver will fail because the DNS client will fail to authenticate that rogue resolver based upon PKIX authentication <xreftarget="RFC6125" />,target="RFC6125"/>, particularly theauthentication domain nameADN in the Encrypted DNSOption.option. DNS clients that ignore authentication failures and accept spoofed certificates will be subject to attacks (e.g., attacks that redirect to maliciousresolvers,resolvers or intercept sensitive data).</t> </section><section title="Deletion Attacks"><section> <name>Deletion Attacks</name> <t>If the DHCP responses or RAs are dropped by the attacker, the client can fall back touseusing a preconfigured encrypted DNS resolver. However, the use of policies to select resolvers isout ofbeyond the scope of this document.</t> <t>Note that deletionattack isattacks are not specific to DHCP/RA.</t> </section><section title="Passive Attacks"><section> <name>Passive Attacks</name> <t>A passive attacker (<xref section="3.2"target="RFC3552" />)target="RFC3552"/>) canidentifydetermine that a host is using DHCP/RA to discover an encrypted DNS resolver and can infer that the host is capable of using DoH/DoT/DoQ to encrypt DNS messages. However, a passive attacker cannot spoof or modify DHCP/RA messages.</t> </section><section title="Wireless<section> <name>Wireless Security - AuthenticationAttacks">Attacks</name> <t>WirelessLAN (WLAN) asLANs (WLANs), frequently deployed in local networks (e.g., homenetworks) isnetworks), are vulnerable to various attacks (e.g., <xreftarget="Evil-Twin" />,target="Evil-Twin"/>, <xreftarget="Krack" />,target="Krack"/>, <xreftarget="Dragonblood" />).target="Dragonblood"/>). Because of these attacks, only cryptographically authenticated communications are trusted on WLANs. This means that any information (e.g., regarding NTPserver,servers, DNSresolver,resolvers, or domain searchlist)lists) provided by such networks via DHCP, DHCPv6, or RA 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 connect to the same WLAN (e.g.,WPA-PSK),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 to mount an active on-path attack. On-path attacks are possible within local networks becausesuch athis form of WLAN authentication lacks peer entity authentication.</t> <t>This leads to the need for provisioning unique credentials for different clients. Endpoints can be provisioned with unique credentials (username and password, typically) provided by the local network administrator to mutually authenticate to the local WLAN AP (e.g., 802.1x Wireless User Authentication onOpenWRTOpenWrt <xreftarget="dot1x" />,target="dot1x"/>, EAP-pwd <xreftarget="RFC8146" />).target="RFC8146"/> ("EAP" stands for "Extensible Authentication Protocol")). Not all endpoint devices (e.g.,IoTInternet of Things (IoT) devices) support 802.1xsupplicantsupplicants and need an alternate mechanism to connect to the local network. To address this limitation, uniquepre-shared keysPSKs can be created for each suchdevicesdevice and WPA-PSK is used (e.g., <xreftarget="IPSK" />).</t>target="IPSK"/>).</t> </section> </section><section title="Privacy Considerations"><section> <name>Privacy Considerations</name> <t>Privacy considerations that are also specific to DNR provisioning mechanisms are discussed in <xref section="23"target="RFC8415" /> ortarget="RFC8415"/> and in <xreftarget="RFC7824" />.target="RFC7824"/>. Anonymity profiles for DHCP clients are discussed in <xreftarget="RFC7844" />.target="RFC7844"/>. Themechanismmechanisms defined in this document can be used to infer that a DHCP client or IPv6 hostsupport encryptedsupports Encrypted DNS options, butdoesthese mechanisms do not explicitly reveal whether local DNS clients are able to consume these options or infer their encryption capabilities. Other than that, this document does not expose more privacy information compared to Do53 discovery options.</t> <t>As discussed in <xreftarget="RFC9076" />,target="RFC9076"/>, the use of encrypted DNS does not reduce the data available in the DNS resolver. For example, the reader may refer to <xref section="8"target="RFC8484" />target="RFC8484"/> or <xref section="7"target="RFC9250" />target="RFC9250"/> for a discussion on specific privacy considerationstofor encrypted DNS.</t> </section> <sectionanchor="IANA" title="IANA Considerations"> <t />anchor="IANA"> <name>IANA Considerations</name> <sectionanchor="iana6" title="DHCPv6 Option">anchor="iana6"> <name>DHCPv6 Option</name> <t>IANAis requested to assignhas assigned the following new DHCPv6 Option Code in the "Option Codes" registry maintainedinat <xreftarget="DHCPV6" />.</t> <texttable anchor="dhcpv6t" title="DHCPv6target="DHCPV6"/>.</t> <table anchor="dhcpv6t"> <name>DHCPv6 Encrypted DNSOption"> <ttcol>Value</ttcol> <ttcol>Description</ttcol> <ttcol>Client ORO</ttcol> <ttcol>Singleton Option</ttcol> <ttcol>Reference</ttcol> <c>TBA1</c> <c>OPTION_V6_DNR</c> <c>Yes</c> <c>No</c> <c>[ThisDocument]</c> </texttable> <t />Option</name> <thead> <tr> <th>Value</th> <th>Description</th> <th>Client ORO</th> <th>Singleton Option</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>144</td> <td>OPTION_V6_DNR</td> <td>Yes</td> <td>No</td> <td>RFC 9463</td> </tr> </tbody> </table> </section> <sectionanchor="iana4" title="DHCPv4 Option">anchor="iana4"> <name>DHCPv4 Option</name> <t>IANAis requested to assignhas assigned the following new DHCP Option Code in the "BOOTP Vendor Extensions and DHCP Options" registry maintainedinat <xreftarget="BOOTP" />.</t> <texttable anchor="dhcpv4t" title="DHCPv4target="BOOTP"/>.</t> <table anchor="dhcpv4t"> <name>DHCPv4 Encrypted DNSOption"> <ttcol>Tag</ttcol> <ttcol>Name</ttcol> <ttcol>Data Length</ttcol> <ttcol>Meaning</ttcol> <ttcol>Reference</ttcol> <c>TBA2</c> <c>OPTION_V4_DNR</c> <c>N</c> <c>Encrypted DNS Server</c> <c>[ThisDocument]</c> </texttable>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> <sectionanchor="iana7" title="Neighboranchor="iana7"> <name>Neighbor DiscoveryOption">Option</name> <t>IANAis requested to assignhas assigned the following new IPv6 Neighbor Discovery Option type in the "IPv6 Neighbor Discovery Option Formats"sub-registrysubregistry under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry maintainedinat <xreftarget="ND" />.</t> <texttable anchor="ndt" title="Neighbortarget="ND"/>.</t> <table anchor="ndt"> <name>Neighbor Discovery Encrypted DNSOption"> <ttcol>Type</ttcol> <ttcol>Description</ttcol> <ttcol>Reference</ttcol> <c>TBA3</c> <c>Encrypted DNS Option</c> <c>[ThisDocument]</c> </texttable> <t />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> <back> <displayreference target="I-D.pusateri-dhc-dns-driu" to="DNS-TLS-DHCPv6-Options"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2132.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8106.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3396.xml"/> <!-- 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> <!-- 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> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8310.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6125.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3646.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7610.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7113.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6731.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7513.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8146.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7227.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7969.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4786.xml"/> <!-- 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> <!-- draft-pusateri-dhc-dns-driu (Expired) --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.pusateri-dhc-dns-driu.xml"/> <!-- draft-ietf-add-split-horizon-authority (I-D Exists) ("Long way" to fix author initials) --> <reference anchor="Local-DNS-Authority"> <front> <title>Establishing Local DNS Authority in Validated Split-Horizon Environments</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-authority-04"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8801.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9076.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7824.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7844.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/> <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> <reference anchor="Krack" target="https://dl.acm.org/doi/10.1145/3133956.3134027"> <front> <title>Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2</title> <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 Computer and Communications Security, pp. 1313-1328</refcontent> </reference> <reference anchor="Dragonblood" target="https://ieeexplore.ieee.org/document/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 Francisco, pp. 517-533</refcontent> </reference> <reference anchor="IPSK" target="https://www.cisco.com/c/en/us/td/docs/wireless/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> <reference anchor="dot1x" target="https://openwrt.org/docs/guide-user/network/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/dhcpv6-parameters/"> <front> <title>Option Codes</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="ND" target="https://www.iana.org/assignments/icmpv6-parameters/"> <front> <title>IPv6 Neighbor Discovery Option Formats</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="BOOTP" target="https://www.iana.org/assignments/bootp-dhcp-parameters/"> <front> <title>BOOTP Vendor Extensions and DHCP Options</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="TS.24008" target="https://www.3gpp.org/DynaReport/24008.htm"> <front> <title>Technical Specification Group Core Network and Terminals; Mobile 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> <sectiontitle="Acknowledgements">numbered="false"> <name>Acknowledgments</name> <t>Many thanks toChristian Jacquenet<contact fullname="Christian Jacquenet"/> andMichael Richardson<contact fullname="Michael Richardson"/> forthe review.</t>their reviews.</t> <t>Thanks toStephen Farrell, Martin Thomson, Vittorio Bertola, Stephane Bortzmeyer, Ben Schwartz, Iain Sharp,<contact fullname="Stephen Farrell"/>, <contact fullname="Martin Thomson"/>, <contact fullname="Vittorio Bertola"/>, <contact fullname="Stéphane Bortzmeyer"/>, <contact fullname="Ben Schwartz"/>, <contact fullname="Iain Sharp"/>, andChris Box<contact fullname="Chris Box"/> forthetheir comments.</t> <t>Thanks toMark Nottingham<contact fullname="Mark Nottingham"/> for the feedback on HTTP redirection that was discussed in previous draft versions of this specification.</t> <t>The use of DHCP as a candidate protocol to retrieve anauthentication domain nameADN wasdiscussedmentioned in <xref section="7.3.1"target="RFC8310" />target="RFC8310"/> and in an Internet-Draft authored byTom Pusateri<contact fullname="Tom Pusateri"/> andWillem Toorop<contact fullname="Willem Toorop"/> <xreftarget="I-D.pusateri-dhc-dns-driu" />.</t>target="I-D.pusateri-dhc-dns-driu"/>.</t> <t>Thanks toBernie Volz<contact fullname="Bernie Volz"/> for the review of the DHCP part.</t><t>Christian Amsuess<t><contact fullname="Christian Amsüss"/> reported a case where the ALPN service parameter cannot be used.</t> <t>Thanks toAndrew Campling<contact fullname="Andrew Campling"/> for the Shepherd review andEric Vyncke<contact fullname="Éric Vyncke"/> for the AD review.</t> <t>Thanks toRich Salz<contact fullname="Rich Salz"/> for the secdir reviews,Joe Clarke<contact fullname="Joe Clarke"/> for theops-diropsdir review,Robert Sparks<contact fullname="Robert Sparks"/> for the artart review, andDavid Blacka<contact fullname="David Blacka"/> for the dnsdir review.</t> <t>Thanks toLars Eggert, Roman Danyliw, Erik Kline, Martin Duke, Robert Wilton, Paul Wouters,<contact fullname="Lars Eggert"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Erik Kline"/>, <contact fullname="Martin Duke"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Paul Wouters"/>, andZaheduzzaman Sarker<contact fullname="Zaheduzzaman Sarker"/> for the IESG review.</t> </section> <sectiontitle="Contributing Authors"> <t />numbered="false"> <name>Contributors</name> <contact fullname="Nicolai Leymann"> <organization>Deutsche Telekom</organization> <address> <postal><street /> <city /> <region /> <code /><country>Germany</country> </postal> <email>n.leymann@telekom.de</email> </address> </contact> <contact fullname="Zhiwei Yan"> <organization>CNNIC</organization> <address> <postal> <street>No.4 South 4th Street, Zhongguancun</street> <city>Beijing</city><region /><region/> <code>100190</code> <country>China</country> </postal> <email>yan@cnnic.cn</email> </address> </contact> </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_networks)"> <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/controller/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/wireless.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/dhcpv6-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> </rfc>