rfc9464xml2.original.xml   rfc9464.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, <!DOCTYPE rfc [
which is available here: http://xml.resource.org. --> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY zwsp "&#8203;">
<!-- One method to get references from the online citation libraries. <!ENTITY nbhy "&#8209;">
There has to be one entity for each item to be referenced. <!ENTITY wj "&#8288;">
An alternate method (rfc include) is described in the references. -->
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<!-- For a complete list and description of processing instructions (PIs), std" consensus="true" docName="draft-ietf-ipsecme-add-ike-14" number="9464" ipr=
please see http://xml.resource.org/authoring/README.html. --> "trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds 4" symRefs="true" sortRefs="true" version="3">
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) --> <!-- xml2rfc v2v3 conversion 3.17.1 -->
<?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 -->
<rfc category="std" docName="draft-ietf-ipsecme-add-ike-14" ipr="trust200902">
<front> <front>
<title abbrev="IKEv2 for Encrypted DNS">Internet Key Exchange Protocol <title abbrev="IKEv2 for Encrypted DNS">Internet Key Exchange Protocol
Version 2 (IKEv2) Configuration for Encrypted DNS</title> Version 2 (IKEv2) Configuration for Encrypted DNS</title>
<seriesInfo name="RFC" value="9464"/>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></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." surname="Reddy.K">
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <region/>
<code/>
<region></region>
<code></code>
<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> <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="Valery Smyslov" initials="V." surname="Smyslov"> <author fullname="Valery Smyslov" initials="V." surname="Smyslov">
<organization>ELVIS-PLUS</organization> <organization>ELVIS-PLUS</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <region/>
<code/>
<region></region> <country>Russian Federation</country>
<code></code>
<country>RU</country>
</postal> </postal>
<email>svan@elvis.ru</email> <email>svan@elvis.ru</email>
</address> </address>
</author> </author>
<date year="2023" month="November" />
<date /> <area>sec</area>
<workgroup>ipsecme</workgroup> <workgroup>ipsecme</workgroup>
<keyword>security</keyword> <keyword>security</keyword>
<keyword>name resolution</keyword> <keyword>name resolution</keyword>
<keyword>encryption</keyword> <keyword>encryption</keyword>
<keyword>service discovery</keyword> <keyword>service discovery</keyword>
<keyword>naming</keyword> <keyword>naming</keyword>
<keyword>resolver</keyword> <keyword>resolver</keyword>
<keyword>stub-resolver</keyword> <keyword>stub-resolver</keyword>
<keyword>CPE</keyword> <keyword>CPE</keyword>
<keyword>Customer premise equipment</keyword> <keyword>Customer premise equipment</keyword>
<keyword>VPN</keyword> <keyword>VPN</keyword>
<keyword>Secure discovery</keyword> <keyword>Secure discovery</keyword>
<keyword>DoT</keyword> <keyword>DoT</keyword>
<keyword>DoH</keyword> <keyword>DoH</keyword>
<keyword>DoQ</keyword> <keyword>DoQ</keyword>
<keyword>Tunnel</keyword> <keyword>Tunnel</keyword>
<keyword>connectivity</keyword> <keyword>connectivity</keyword>
<abstract> <abstract>
<t>This document specifies new Internet Key Exchange Protocol Version 2 <t>This document specifies new Internet Key Exchange Protocol Version 2
(IKEv2) Configuration Payload Attribute Types to assign DNS resolvers (IKEv2) Configuration Payload Attribute Types to assign DNS resolvers
that support encrypted DNS protocols, such as DNS-over-HTTPS (DoH), that support encrypted DNS protocols, such as DNS over HTTPS (DoH),
DNS-over-TLS (DoT), and DNS-over-QUIC (DoQ).</t> DNS over TLS (DoT), and DNS over QUIC (DoQ).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>This document specifies a mechanism to assign encrypted DNS <name>Introduction</name>
<t>This document specifies a mechanism for assigning encrypted DNS
configurations to an Internet Key Exchange Protocol Version 2 (IKEv2) configurations to an Internet Key Exchange Protocol Version 2 (IKEv2)
<xref target="RFC7296"></xref> initiator. Specifically, it assigns one initiator <xref target="RFC7296" format="default"/>. Specifically, it assi gns one
or more Authentication Domain Names (ADNs) of DNS resolvers that support or more Authentication Domain Names (ADNs) of DNS resolvers that support
encrypted DNS protocols. The specific protocols supported are described encrypted DNS protocols. The specific protocols supported are described
using the Service Parameters format defined in <xref using the Service Parameters format defined in <xref target="RFC9460" form
target="I-D.ietf-dnsop-svcb-https"></xref>; supported protocols include at="default"/>; supported protocols include
DNS-over-HTTPS (DoH) <xref target="RFC8484"></xref>, DNS-over-TLS (DoT) DNS over HTTPS (DoH) <xref target="RFC8484" format="default"/>, DNS over T
<xref target="RFC7858"></xref>, and DNS-over-QUIC (DoQ) <xref LS (DoT)
target="RFC9250"></xref>.</t> <xref target="RFC7858" format="default"/>, and DNS over QUIC (DoQ) <xref t
arget="RFC9250" format="default"/>.</t>
<t>This document introduces three new IKEv2 Configuration Payload <t>This document introduces three new IKEv2 Configuration Payload
Attribute Types (<xref target="RI"></xref>) to add support for encrypted Attribute Types (<xref target="RI" format="default"/>) to add support for
DNS resolvers. The ENCDNS_IP4 and ENCDNS_IP6 attribute types (<xref encrypted
target="RIIP"></xref>) are used to provision ADNs, a list of IP DNS resolvers. The ENCDNS_IP4 and ENCDNS_IP6 attribute types (<xref target
="RIIP" format="default"/>) are used to provision ADNs, a list of IP
addresses, and a set of service parameters. The ENCDNS_DIGEST_INFO addresses, and a set of service parameters. The ENCDNS_DIGEST_INFO
attribute (<xref target="digest"></xref>) additionally allows a specific attribute (<xref target="digest" format="default"/>) additionally allows a specific
resolver certificate to be indicated by the IKEv2 responder.</t> resolver certificate to be indicated by the IKEv2 responder.</t>
<t>The encrypted DNS resolver hosted by a Virtual Private Network (VPN) <t>The encrypted DNS resolver hosted by a Virtual Private Network (VPN)
provider can get a domain-validate certificate from a public Certificate provider can get a domain-validated certificate from a public Certificate
Authority (CA). The VPN client does not need to be provisioned with the Authority (CA). The VPN client does not need to be provisioned with the
root certificate of a private CA to authenticate the certificate of the root certificate of a private CA to authenticate the certificate of the
encrypted DNS resolvers. The encrypted DNS resolver can run on private encrypted DNS resolvers. The encrypted DNS resolver can run on private
IP addresses and its access can be restricted to clients connected to IP addresses, and its access can be restricted to clients connected to
the VPN.</t> the VPN.</t>
<t>For many years, typical designs have often assumed that the DNS
<t>For many years, typical designs have often considered that the DNS resolver was usually located inside the protected domain, but they don't
resolver was usually located inside the protected domain, but could be consider implementations where the DNS resolver could be located outside o
located outside of it. With encrypted DNS, the latter option becomes f it. With encrypted DNS, implementing the latter scenario becomes
plausible. Note that existing VPN client implementations might not plausible. Note that existing VPN client implementations might not
expect that the discovered DNS resolver IP addresses to be outside of expect the discovered DNS resolver IP addresses to be outside of
the covered IP address ranges of the VPN tunnel.</t> the covered IP address ranges of the VPN tunnel.</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<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> <xref target="RFC8174"></xref> when, and "<bcp14>SHOULD NOT</bcp14>",
only when, 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 uses the terms defined in <xref are to be interpreted as described in BCP&nbsp;14
target="RFC8499"></xref>.</t> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
<t>Also, this document uses the terms defined in <xref <t>This document uses the terms defined in <xref target="RFC8499" format="
target="RFC7296"></xref>. In particular, readers should be familiar with default"/>.</t>
"initiator" and "responder" terms used in that document.</t> <t>Also, this document uses the terms defined in <xref target="RFC7296" fo
rmat="default"/>. In particular, readers should be familiar with the terms
<t>This document makes use of the following terms: <list style="hanging"> "initiator" and "responder" as used in that document.</t>
<t hangText="Do53:">refers to unencrypted DNS.</t> <t>This document makes use of the following terms: </t>
<dl newline="false" spacing="normal">
<t hangText="Encrypted DNS:">refers to a scheme where DNS messages <dt>Do53:</dt>
<dd>Refers to unencrypted DNS.</dd>
<dt>Encrypted DNS:</dt>
<dd>Refers to a scheme where DNS messages
are sent over an encrypted channel. Examples of encrypted DNS are are sent over an encrypted channel. Examples of encrypted DNS are
DoT, DoH, and DoQ.</t> DoT, DoH, and DoQ.</dd>
<dt>ENCDNS_IP*:</dt>
<t hangText="ENCDNS_IP*:">refers to any IKEv2 Configuration Payload <dd>Refers to any of the IKEv2 Configuration Payload
Attribute Types defined in <xref target="RIIP"></xref>.</t> Attribute Types defined in <xref target="RIIP" format="default"/>.</dd
</list></t> >
</dl>
<t></t>
</section> </section>
<section anchor="RI" numbered="true" toc="default">
<section anchor="RI" <name>IKEv2 Configuration Payload Attribute Types for Encrypted DNS</name>
title="IKEv2 Configuration Payload Attribute Types for Encrypted DN <section anchor="RIIP" numbered="true" toc="default">
S"> <name>ENCDNS_IP* Configuration Payload Attributes</name>
<section anchor="RIIP"
title="ENCDNS_IP* Configuration Payload Attributes">
<t>The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types, <t>The ENCDNS_IP* IKEv2 Configuration Payload Attribute Types,
ENCDNS_IP4 and ENCDNS_IP6, are used to configure encrypted DNS ENCDNS_IP4 and ENCDNS_IP6, are used to configure an initiator with encry
resolvers to an initiator. Both attribute types share the format that pted DNS
is shown in <xref target="ri_attr"></xref>. The information included resolvers. Both attribute types share the format
in these attributes adheres to the recommendation in <xref shown in <xref target="ri_attr" format="default"/>. The information incl
section="3.1.9" target="I-D.ietf-add-dnr"></xref>.</t> uded
in these attributes adheres to the recommendation in <xref section="3.1.
<t><figure anchor="ri_attr" title="Attributes Format"> 9" target="RFC9463" format="default"/>.</t>
<artwork><![CDATA[ 1 2 <figure anchor="ri_attr">
3 <name>Format of ENCDNS_IP4 and ENCDNS_IP6 Configuration Attributes</na
me>
<artwork name="" type="" align="left" alt=""><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-----------------------------+-------------------------------+ +-+-----------------------------+-------------------------------+
|R| Attribute Type | Length | |R| Attribute Type | Length |
+-+-----------------------------+---------------+---------------+ +-+-----------------------------+---------------+---------------+
| Service Priority | Num Addresses | ADN Length | | Service Priority | Num Addresses | ADN Length |
+-------------------------------+---------------+---------------+ +-------------------------------+---------------+---------------+
~ IP Addresses ~ ~ IP Address(es) ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
~ Authentication Domain Name ~ ~ Authentication Domain Name ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
~ Service Parameters (SvcParams) ~ ~ Service Parameters (SvcParams) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The description of the fields shown in <xref target="ri_attr" format=
<t>The description of the fields of the attribute shown in <xref "default"/> is as follows:</t>
target="ri_attr"></xref> is as follows:</t> <dl newline="false" spacing="normal">
<dt>R (Reserved, 1 bit):</dt><dd>This bit <bcp14>MUST</bcp14> be set t
<t><list style="symbols"> o zero and <bcp14>MUST</bcp14> be
<t>R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be ignored on receipt (see <xref section="3.15.1" target="RFC7296" form
ignored on receipt (see <xref section="3.15.1" at="default"/> for details).</dd>
target="RFC7296"></xref> for details).</t> <dt>Attribute Type (15 bits):</dt><dd>Identifier for the Configuration
Attribute Type. This is set to 27 for ENCDNS_IP4 or 28 for
<t>Attribute Type (15 bits) - Identifier for Configuration ENCDNS_IP6, as registered in <xref target="IANA1" format="default"/>
Attribute Type. This is set to TBA1 for ENCDNS_IP4 or TBA2 for .</dd>
ENCDNS_IP6, as registered in <xref target="IANA1"></xref>.</t> <dt>Length (2 octets, unsigned integer):</dt><dd><t>Length of the encl
osed
<t>Length (2 octets, unsigned integer) - Length of the enclosed data in octets. In particular, this field is set to:</t>
data in octets. In particular, this field is set to:<list <ul spacing="normal">
style="symbols"> <li>0, if the Configuration payload has type (1) CFG_REQUEST
<t>0, if the Configuration payload has (i) type CFG_REQUEST and no specific DNS resolver is requested or (2) CFG_ACK. If the
and no specific DNS resolver is requested or (ii) type "Length" field is set to 0, then the subsequent fields
CFG_ACK. If the 'Length' field is set to 0, then later fields shown in <xref target="ri_attr" format="default"/> are not prese
shown in <xref target="ri_attr"></xref> are not present.</t> nt.</li>
<li>(4 + 'Length of the ADN' + N * 4 + 'Length of SvcParams') for
<t>(4 + 'Length of the ADN' + N * 4 + Length of SvcParams) for ENCDNS_IP4 attributes if the Configuration payload has type
ENCDNS_IP4 attributes if the Configuration payload has types CFG_REQUEST, CFG_REPLY, or CFG_SET, with N being the number of
CFG_REQUEST or CFG_REPLY or CFG_SET; N being the number of included IPv4 addresses ("Num Addresses").</li>
included IPv4 addresses ('Num addresses').</t> <li>(4 + 'Length of the ADN' + N * 16 + 'Length of SvcParams')
<t>(4 + 'Length of the ADN' + N * 16 + Length of SvcParams)
for ENCDNS_IP6 attributes if the Configuration payload has for ENCDNS_IP6 attributes if the Configuration payload has
types CFG_REQUEST or CFG_REPLY or CFG_SET; N being the number type CFG_REQUEST, CFG_REPLY, or CFG_SET, with N being the number
of included IPv6 addresses ('Num addresses').</t> of included IPv6 addresses ("Num Addresses").</li>
</list></t> </ul>
</dd>
<t>Service Priority (2 octets) - The priority of this attribute <dt>Service Priority (2 octets):</dt><dd>The priority of this attribut
e
compared to other ENCDNS_IP* instances. This 16-bit unsigned compared to other ENCDNS_IP* instances. This 16-bit unsigned
integer is interpreted following the rules specified in <xref integer is interpreted following the rules specified in <xref sectio
section="2.4.1" target="I-D.ietf-dnsop-svcb-https"></xref>. As n="2.4.1" target="RFC9460" format="default"/>. As
AliasMode (<xref section="2.4.2" AliasMode (<xref section="2.4.2" target="RFC9460" format="default"/>
target="I-D.ietf-dnsop-svcb-https"></xref>) is not supported, this ) is not supported, this
field MUST NOT be set to 0. Note that AliasMode is not supported field <bcp14>MUST NOT</bcp14> be set to 0. Note that AliasMode is no
t supported
because such a mode will trigger additional Do53 queries while the because such a mode will trigger additional Do53 queries while the
data can be supplied directly in the IKE response.</t> data can be supplied directly in the IKE response.</dd>
<dt>Num Addresses (1 octet):</dt><dd>Indicates the number of enclosed
<t>Num Addresses (1 octet) - Indicates the number of enclosed IPv4 IPv4
(for ENCDNS_IP4) or IPv6 (for ENCDNS_IP6) addresses. This value (for ENCDNS_IP4) or IPv6 (for ENCDNS_IP6) addresses. This value
MUST NOT be set to 0 if the Configuration payload is of type <bcp14>MUST NOT</bcp14> be set to 0 if the Configuration payload has type
CFG_REPLY or CFG_SET. This may be set to 0 in CFG_REQUEST to CFG_REPLY or CFG_SET. This may be set to 0 in CFG_REQUEST to
indicate that no IP address is encoded in the attribute.</t> indicate that no IP address is encoded in the attribute.</dd>
<dt>ADN Length (1 octet):</dt><dd>Indicates the length of the
<t>ADN Length (1 octet) - Indicates the length of the "Authentication Domain Name" field in octets. When set to 0,
"Authentication Domain Name" field in octets. When set to '0', this means that no ADN is enclosed in the attribute.</dd>
this means that no ADN is enclosed in the attribute.</t> <dt>IP Address(es) (variable):</dt><dd>Includes one or more IP address
es
<t>IP Address(es) (variable) - Includes one or more IP addresses
that can be used to reach the encrypted DNS resolver identified by that can be used to reach the encrypted DNS resolver identified by
the Authentication Domain Name. For ENCDNS_IP4 this field contains the ADN. For ENCDNS_IP4, this field contains
one or more 4-octet IPv4 addresses, and for ENCDNS_IP6 this field one or more 4-octet IPv4 addresses, and for ENCDNS_IP6, this field
contains one or more 16-octet IPv6 addresses.</t> contains one or more 16-octet IPv6 addresses.</dd>
<dt>Authentication Domain Name (variable):</dt><dd><t>A fully qualifie
<t>Authentication Domain Name (variable) - A fully qualified d
domain name of the encrypted DNS resolver, in DNS presentation domain name of the encrypted DNS resolver, in DNS presentation
format and using an Internationalized Domain Names for format and using an Internationalized Domain Names for
Applications (IDNA) A-label <xref target="RFC5890"></xref>. The Applications (IDNA) A-label <xref target="RFC5890" format="default"/
name MUST NOT contain any terminators (e.g., NULL, CR). <vspace >. The
blankLines="1" />An example of a valid ADN for DoH server is name <bcp14>MUST NOT</bcp14> contain any terminators (e.g., NULL, CR
"doh1.example.com".</t> ). </t>
<t>An example of a valid ADN for a DoH server is
<t>Service Parameters (SvcParams) (variable) - Specifies a set of "doh1.example.com".</t></dd>
service parameters that are encoded following the rules in <xref <dt>Service Parameters (SvcParams) (variable):</dt><dd><t>Specifies
section="2.1" target="I-D.ietf-dnsop-svcb-https"></xref>. Section a set of
3.1.5 of <xref target="I-D.ietf-add-dnr"></xref> lists a set of service parameters that are encoded following the same rules
for encoding SvcParams using the wire format specified in <xref section="2.2" ta
rget="RFC9460" format="default"/>. <xref section="3.1.5" target="RFC9463" format
="default"/> lists a set of
service parameters that are recommended to be supported by service parameters that are recommended to be supported by
implementations. <vspace blankLines="1" />The service parameters implementations. </t>
MUST NOT include "ipv4hint" or "ipv6hint" SvcParams as they are <t>The service parameters
superseded by the included IP addresses. <vspace <bcp14>MUST NOT</bcp14> include "ipv4hint" or "ipv6hint" SvcParams,
blankLines="1" />If no "port" service parameter is included, this 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 reminder, indicates that default port numbers should be used. As a reminder,
the default port number is 853 for DoT (Section 6 of <xref the default port number is 853 for DoT (<xref section="6" target="RF
target="RFC7858"></xref>), 443 for DoH (Section 8.1 of <xref C7858" format="default"/>), 443 for DoH (<xref section="8.1" target="RFC8484" fo
target="RFC8484"></xref>), and 853 for DoQ (Section 8 of <xref rmat="default"/>), and 853 for DoQ (<xref section="8" target="RFC9250" format="d
target="RFC9250"></xref>). <vspace blankLines="1" />The service efault"/>). </t>
<t>The service
parameters apply to all IP addresses in the ENCDNS_IP* parameters apply to all IP addresses in the ENCDNS_IP*
Configuration Payload Attribute.</t> Configuration Payload Attribute.</t></dd>
</list></t> </dl>
</section> </section>
<section anchor="digest" numbered="true" toc="default">
<section anchor="digest" <name>ENCDNS_DIGEST_INFO Configuration Payload Attribute</name>
title="ENCDNS_DIGEST_INFO Configuration Payload Attribute"> <t>The ENCDNS_DIGEST_INFO Configuration Payload Attribute (<xref target=
<t>The ENCDNS_DIGEST_INFO configuration payload attribute (<xref "digest_attr_full" format="default"/>) allows IKEv2 responders to specify
target="digest_attr_full"></xref>) allows IKEv2 responders to specify
a certificate digest that initiators can use when validating TLS a certificate digest that initiators can use when validating TLS
connections to encrypted resolvers. This attribute can also be sent by connections to encrypted resolvers. This attribute can also be sent by
the initiator to request specific hash algorithms for such the initiator to request specific hash algorithms for such
digests.</t> digests.</t>
<figure anchor="digest_attr_full">
<t><figure anchor="digest_attr_full" <name>ENCDNS_DIGEST_INFO Attribute Format</name>
title="ENCDNS_DIGEST_INFO Attribute Format"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ 1 2 1 2 3
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
+-+-----------------------------+-------------------------------+ +-+-----------------------------+-------------------------------+
|R| Attribute Type | Length | |R| Attribute Type | Length |
+-+-------------+---------------+-------------------------------+ +-+-------------+---------------+-------------------------------+
| Num Hash Algs | ADN Length | | | Num Hash Algs | ADN Length | |
+---------------+---------------+ + +---------------+---------------+ +
~ Authentication Domain Name ~ ~ Authentication Domain Name ~
+-------------------------------+-------------------------------+ +---------------------------------------------------------------+
~ List of Hash Algorithm Identifiers ~ ~ List of Hash Algorithm Identifiers ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
~ Certificate Digest ~ ~ Certificate Digest ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure>Some of the fields shown in <xref </figure>
target="digest_attr_full"></xref> can be omitted as further detailed <t>Some of the fields shown in <xref target="digest_attr_full" format="d
efault"/> can be omitted, as further detailed
below.</t> below.</t>
<t>The format of the ENCDNS_DIGEST_INFO attribute if the Configuration
<t>The format of ENCDNS_DIGEST_INFO attribute if the Configuration payload has type CFG_REQUEST is shown in <xref target="digest_attr" form
payload has type CFG_REQUEST is shown in <xref at="default"/>.</t>
target="digest_attr"></xref>.</t> <figure anchor="digest_attr">
<name>ENCDNS_DIGEST_INFO Attribute Format in CFG_REQUEST</name>
<t><figure anchor="digest_attr" <artwork name="" type="" align="left" alt=""><![CDATA[
title="ENCDNS_DIGEST_INFO Attribute Format in CFG_REQUEST"> 1 2 3
<artwork><![CDATA[ 1 2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-----------------------------+-------------------------------+ +-+-----------------------------+-------------------------------+
|R| Attribute Type | Length | |R| Attribute Type | Length |
+-+-------------+---------------+-------------------------------+ +-+-------------+---------------+-------------------------------+
| Num Hash Algs | ADN Length | | | Num Hash Algs | ADN Length | |
+---------------+---------------+ + +---------------+---------------+ +
~ List of Hash Algorithm Identifiers ~ ~ List of Hash Algorithm Identifiers ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The description of the fields shown in <xref target="digest_attr" for
<t>The description of the fields of the attribute shown in <xref mat="default"/> is as follows:</t>
target="digest_attr"></xref> is as follows:<list style="symbols"> <dl newline="false" spacing="normal">
<t>R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be <dt>R (Reserved, 1 bit):</dt><dd>This bit <bcp14>MUST</bcp14> be set t
ignored on receipt (see <xref section="3.15.1" o zero and <bcp14>MUST</bcp14> be
target="RFC7296"></xref> for details).</t> ignored on receipt (see <xref section="3.15.1" target="RFC7296" form
at="default"/> for details).</dd>
<t>Attribute Type (15 bits) - Identifier for Configuration <dt>Attribute Type (15 bits):</dt><dd>Identifier for the Configuration
Attribute Type; is set to TBA3 value listed in <xref Attribute Type. This is set to 29; see <xref target="IANA1" format=
target="IANA1"></xref>.</t> "default"/>.</dd>
<dt>Length (2 octets, unsigned integer):</dt><dd>Length of the enclose
<t>Length (2 octets, unsigned integer) - Length of the enclosed d
data in octets. This field MUST be set to "2 + (2 * 'number of data in octets. This field <bcp14>MUST</bcp14> be set to "2 + (2 * '
included hash algorithm identifiers')".</t> number of
included hash algorithm identifiers')".</dd>
<t>Num Hash Algs (1 octet) - Indicates the number of included <dt>Num Hash Algs (1 octet):</dt><dd>Indicates the number of identifie
'Hash Algorithm Identifiers'. This field MUST be set to "(Length rs included in the "List of Hash Algorithm Identifiers" field. This field <bcp14
&ndash; 2)/2".</t> >MUST</bcp14> be set to "(Length
- 2)/2".</dd>
<t>ADN Length (1 octet) - MUST be set to 0.</t> <dt>ADN Length (1 octet):</dt><dd><bcp14>MUST</bcp14> be set to 0.</dd
>
<t>List of Hash Algorithm Identifiers (variable) - Specifies a <dt>List of Hash Algorithm Identifiers (variable):</dt><dd><t>Specifie
s a
list of 16-bit hash algorithm identifiers that are supported by list of 16-bit hash algorithm identifiers that are supported by
the encrypted DNS client. This list may be controlled by a local the encrypted DNS client. This list may be controlled by a local
policy.<vspace blankLines="1" />The values of this field are taken policy.</t>
from the Hash Algorithm Identifiers of IANA's "Internet Key <t>The values of this field are identifiers taken
Exchange Version 2 (IKEv2) Parameters" registry <xref from "IKEv2 Hash Algorithms" on IANA's "Internet Key
target="IANA-IKE-HASH"></xref>. <vspace blankLines="1" />There is Exchange Version 2 (IKEv2) Parameters" registry <xref target="IANA-I
no padding between the hash algorithm identifiers. <vspace KE-HASH" format="default"/>. </t>
blankLines="1" />Note that SHA2-256 is mandatory to implement (see <t>There is
<xref target="hash"></xref>).</t> no padding between the hash algorithm identifiers. </t>
</list></t> <t>Note that SHA2-256 is mandatory to implement (see
<xref target="hash" format="default"/>).</t>
<t>The format of ENCDNS_DIGEST_INFO attribute if the Configuration </dd>
payload has types CFG_REPLY or CFG_SET is shown in <xref </dl>
target="digest_attr_res"></xref>.</t> <t>The format of the ENCDNS_DIGEST_INFO attribute if the Configuration
payload has type CFG_REPLY or CFG_SET is shown in <xref target="digest_a
<t><figure anchor="digest_attr_res" ttr_res" format="default"/>.</t>
title="ENCDNS_DIGEST_INFO Attribute Format in CFG_REPLY or CFG_SET"> <figure anchor="digest_attr_res">
<artwork><![CDATA[ 1 2 <name>ENCDNS_DIGEST_INFO Attribute Format in CFG_REPLY or CFG_SET</nam
3 e>
<artwork name="" type="" align="left" alt=""><![CDATA[
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-----------------------------+-------------------------------+ +-+-----------------------------+-------------------------------+
|R| Attribute Type | Length | |R| Attribute Type | Length |
+-+-----------------------------+---------------+---------------+ +-+-------------+---------------+-------------------------------+
| Num Hash Algs | ADN Length | | | Num Hash Algs | ADN Length | |
+---------------+---------------+ + +---------------+---------------+ +
~ Authentication Domain Name ~ ~ Authentication Domain Name ~
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| Hash Algorithm Identifier | ~ | Hash Algorithm Identifier | ~
+-------------------------------+ + +-------------------------------+ +
~ Certificate Digest ~ ~ Certificate Digest ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +---------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure>The description of the fields of the attribute shown in </figure>
<xref target="digest_attr"></xref> is as follows:</t> <t>The description of the fields shown in
<xref target="digest_attr_res" format="default"/> is as follows:</t>
<t><list style="symbols"> <dl newline="false" spacing="normal">
<t>R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be <dt>R (Reserved, 1 bit):</dt><dd>This bit <bcp14>MUST</bcp14> be set t
ignored on receipt (see <xref section="3.15.1" o zero and <bcp14>MUST</bcp14> be
target="RFC7296"></xref> for details).</t> ignored on receipt (see <xref section="3.15.1" target="RFC7296" form
at="default"/> for details).</dd>
<t>Attribute Type (15 bits) - Identifier for Configuration <dt>Attribute Type (15 bits):</dt><dd>Identifier for the Configuration
Attribute Type; is set to TBA3 value listed in <xref Attribute Type. This is set to 29; see <xref target="IANA1" format=
target="IANA1"></xref>.</t> "default"/>.</dd>
<dt>Length (2 octets, unsigned integer):</dt><dd>Length of the data in
<t>Length (2 octets, unsigned integer) - Length of the data in octets.</dd>
octets.</t> <dt>Num Hash Algs (1 octet):</dt><dd><bcp14>MUST</bcp14> be set to 1.<
/dd>
<t>Num Hash Algs (1 octet) - MUST be set to 1.</t> <dt>ADN Length (1 octet):</dt><dd>Indicates the length of the
"Authentication Domain Name" field in octets. When set to 0,
<t>ADN Length (1 octet) - Indicates the length of the
"Authentication Domain Name" field in octets. When set to '0',
this means that the digest applies on the ADN conveyed in the this means that the digest applies on the ADN conveyed in the
ENCDNS_IP* Configuration Payload Attribute(s).</t> ENCDNS_IP* Configuration Payload Attribute.</dd>
<dt>Authentication Domain Name (variable):</dt><dd>A fully qualified
<t>Authentication Domain Name (variable) - A fully qualified
domain name of the encrypted DNS resolver following the syntax domain name of the encrypted DNS resolver following the syntax
defined in <xref target="RFC5890"></xref>. The name MUST NOT defined in <xref target="RFC5890" format="default"/>. The name <bcp1 4>MUST NOT</bcp14>
contain any terminators (e.g., NULL, CR). A name is included only contain any terminators (e.g., NULL, CR). A name is included only
when multiple ADNs are included in the ENCDNS_IP* Configuration when multiple ADNs are included in the ENCDNS_IP* Configuration
Payload Attributes.</t> Payload Attribute.</dd>
<dt>Hash Algorithm Identifier (2 octets):</dt><dd>Specifies the 16-bit
<t>Hash Algorithm Identifier (2 octets) - Specifies the 16-bit
hash algorithm identifier selected by the DNS resolver to generate hash algorithm identifier selected by the DNS resolver to generate
the digest of its certificate.</t> the digest of its certificate.</dd>
<dt>Certificate Digest (variable):</dt><dd>Includes the Subject
<t>Certificate Digest (variable) - This field includes the Subject Public Key Info (SPKI) hash (<xref target="hash" format="default"/>)
Public Key Info (SPKI) hash (<xref target="hash"></xref>) of the of the
encrypted DNS resolver certificate using the algorithm identified encrypted DNS resolver certificate using the algorithm identified
in the 'Hash Algorithm Identifier' field. The length of this field in the "Hash Algorithm Identifier" field. The length of this field
is "Length &ndash; 4 &ndash; 'ADN Length'".</t> is "Length - 4 - 'ADN Length'".</dd>
</list></t> </dl>
<t>The ENCDNS_DIGEST_INFO attribute may be present in the <t>The ENCDNS_DIGEST_INFO attribute may be present in the
Configuration payload of CFG_ACK. In such a case, the Configuration payload of CFG_ACK. In such a case, the
ENCDNS_DIGEST_INFO MUST be returned with zero-length data.</t> ENCDNS_DIGEST_INFO <bcp14>MUST</bcp14> be returned with zero-length data
.</t>
<t>As discussed in <xref section="3.15.1" target="RFC7296"></xref>, <t>As discussed in <xref section="3.15.1" target="RFC7296" format="defau
lt"/>,
there are no defined uses for the CFG_SET/CFG_ACK exchange. The use of there are no defined uses for the CFG_SET/CFG_ACK exchange. The use of
the ENCDNS_DIGEST_INFO attribute for these messages is provided for the ENCDNS_DIGEST_INFO attribute for these messages is provided for
completeness.</t> completeness.</t>
</section> </section>
</section> </section>
<section anchor="protocol" numbered="true" toc="default">
<section anchor="protocol" title="IKEv2 Protocol Exchange"> <name>IKEv2 Protocol Exchange</name>
<t>This section describes how the attributes defined in <xref <t>This section describes how the attributes defined in <xref target="RI"
target="RI"></xref> are used to configure an IKEv2 initiator with one or format="default"/> are used to configure an IKEv2 initiator with one or
more encrypted DNS resolvers. As a reminder, badly formatted attributes more encrypted DNS resolvers. As a reminder, badly formatted attributes
or unacceptable fields are handled as per Section 2.21 of <xref or unacceptable fields are handled as per <xref section="2.21" target="RFC
target="RFC7296"></xref>.</t> 7296" format="default"/>.</t>
<t>Initiators first indicate support for encrypted DNS by including <t>Initiators first indicate support for encrypted DNS by including
ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders supply ENCDNS_IP* attributes in their CFG_REQUEST payloads. Responders supply
encrypted DNS configuration by including ENCDNS_IP* attributes in their encrypted DNS configuration by including ENCDNS_IP* attributes in their
CFG_REPLY payloads. Concretely:</t> CFG_REPLY payloads. Concretely:</t>
<ul spacing="normal">
<t><list style="empty"> <li>If the initiator supports encrypted DNS, it includes either or
<t>If the initiator supports encrypted DNS, it includes either or
both of the ENCDNS_IP4 and ENCDNS_IP6 attributes in its CFG_REQUEST. both of the ENCDNS_IP4 and ENCDNS_IP6 attributes in its CFG_REQUEST.
If the initiator does not want to request specific DNS resolvers, it If the initiator does not want to request specific DNS resolvers, it
sets the Length field to 0 for the attribute. For a given attribute sets the "Length" field to 0 for the attribute. For a given attribute
type, the initiator MAY send either an empty attribute or a list of type, the initiator <bcp14>MAY</bcp14> send either an empty attribute
distinct suggested resolvers. The initiator MAY also include the or a list of
distinct suggested resolvers. The initiator <bcp14>MAY</bcp14> also in
clude the
ENCDNS_DIGEST_INFO attribute with a list of hash algorithms that are ENCDNS_DIGEST_INFO attribute with a list of hash algorithms that are
supported by the encrypted DNS client.</t> supported by the encrypted DNS client.</li>
<li>If the request includes multiple bitwise identical attributes,
<t>If the request includes multiple bitwise identical attributes, only the first occurrence is processed, and the rest <bcp14>SHOULD</bc
only the first occurrence is processed, and the rest SHOULD be p14> be
ignored by the responder. The responder MAY discard the full request ignored by the responder. The responder <bcp14>MAY</bcp14> discard the
if the count of repeated attributes exceeds an (implementation full request
specific) threshold.</t> if the count of repeated attributes exceeds an
(implementation-specific) threshold.</li>
<t>For each ENCDNS_IP* attribute from the CFG_REQUEST, if the <li>For each ENCDNS_IP* attribute from the CFG_REQUEST, if the
responder supports the corresponding address family, and absent any responder supports the corresponding address family, and absent any
policy restrictions, the responder sends back ENCDNS_IP* policy restrictions, the responder sends back one or more ENCDNS_IP*
attribute(s) in the CFG_REPLY with an appropriate list of IP attributes in the CFG_REPLY with an appropriate list of IP
addresses, service parameters, and an ADN. The list of IP addresses addresses, service parameters, and an ADN. The list of IP addresses
MUST include at least one IP address. The service parameters SHOULD <bcp14>MUST</bcp14> include at least one IP address. The service param eters <bcp14>SHOULD</bcp14>
include at least the "alpn" service parameter. The "alpn" service include at least the "alpn" service parameter. The "alpn" service
parameter may not be required in contexts such as a variant of DNS parameter may not be required in contexts such as a variant of DNS
over CoAP where the messages are encrypted using Object Security for over the Constrained Application Protocol (CoAP) where the messages ar
Constrained RESTful Environments (OSCORE) <xref e encrypted using Object Security for
target="RFC8613"></xref>.</t> Constrained RESTful Environments (OSCORE) <xref target="RFC8613" forma
t="default"/>.</li>
<t>The responder MAY ignore suggested values from the initiator (if <li>The responder <bcp14>MAY</bcp14> ignore suggested values from the in
any). Multiple instances of the same ENCDNS_IP* attribute MAY be itiator (if
any). Multiple instances of the same ENCDNS_IP* attribute <bcp14>MAY</
bcp14> be
returned if distinct ADNs or service parameters need to be assigned returned if distinct ADNs or service parameters need to be assigned
to the initiator. In such instances, the different attributes can to the initiator. In such instances, the different attributes can
have matching or distinct IP addresses. These instances MUST be have matching or distinct IP addresses. These instances <bcp14>MUST</b cp14> be
presented to a local DNS client following their service priority presented to a local DNS client following their service priority
(i.e., smaller service priority values indicates a higher (i.e., a smaller service priority value indicates a higher
preference).</t> preference).</li>
<li>In addition, the responder <bcp14>MAY</bcp14> return the ENCDNS_DIGE
<t>In addition, the responder MAY return the ENCDNS_DIGEST_INFO ST_INFO
attribute to convey a digest of the certificate of the encrypted DNS attribute to convey a digest of the certificate of the encrypted DNS
and the identifier of the hash algorithm that is used to generate and the identifier of the hash algorithm that is used to generate
the digest.</t> the digest.</li>
<li>If the CFG_REQUEST includes an ENCDNS_IP* attribute but the
<t>If the CFG_REQUEST includes an ENCDNS_IP* attribute but the CFG_REPLY does not include an ENCDNS_IP* attribute matching the reques
CFG_REPLY does not include an ENCDNS_IP* matching the requested ted
address family, this is an indication that requested address family address family, this is an indication that the requested address famil
y
is not supported by the responder or the responder is not configured is not supported by the responder or the responder is not configured
to provide corresponding resolver addresses.</t> to provide corresponding resolver addresses.</li>
<li>If the initiator receives both ENCDNS_IP* and INTERNAL_IP6_DNS
<t>If the initiator receives both ENCDNS_IP* and INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes, it is <bcp14>RECOMMENDED</bcp14> tha
(or INTERNAL_IP4_DNS) attributes, it is RECOMMENDED that the t the
initiator uses the encrypted DNS resolvers.</t> initiator use the encrypted DNS resolvers.</li>
</list></t> </ul>
<t>The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, or
<t>The DNS client establishes an encrypted DNS session (e.g., DoT, DoH, DoQ) with the address or addresses conveyed in ENCDNS_IP* and uses the mec
DoQ) with the address(es) conveyed in ENCDNS_IP* and uses the mechanism hanisms
discussed in Section 8 of <xref target="RFC8310"></xref> to authenticate discussed in <xref section="8" target="RFC8310" format="default"/> to auth
the DNS resolver certificate using the authentication domain name enticate
the DNS resolver certificate using the ADN
conveyed in ENCDNS_IP*.</t> conveyed in ENCDNS_IP*.</t>
<t>If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the client <t>If the CFG_REPLY includes an ENCDNS_DIGEST_INFO attribute, the client
has to create an SPKI hash (<xref target="hash"></xref>) of the DNS has to create an SPKI hash (<xref target="hash" format="default"/>) of the DNS
resolver certificate received in the TLS handshake using the negotiated resolver certificate received in the TLS handshake using the negotiated
hash algorithm in the ENCDNS_DIGEST_INFO attribute. If the computed hash algorithm in the ENCDNS_DIGEST_INFO attribute. If the computed
digest for an ADN matches the one sent in the ENCDNS_DIGEST_INFO digest for an ADN matches the digest sent in the ENCDNS_DIGEST_INFO
attribute, the encrypted DNS resolver certificate is successfully attribute, the encrypted DNS resolver certificate is successfully
validated. If so, the client continues with the TLS connection as validated. If so, the client continues with the TLS connection as
normal. Otherwise, the client MUST treat the resolver certificate normal. Otherwise, the client <bcp14>MUST</bcp14> treat the resolver certi ficate
validation failure as a non-recoverable error. This approach is similar validation failure as a non-recoverable error. This approach is similar
to certificate usage PKIX-EE(1) with selector SPKI(1) defined in <xref to certificate usage PKIX-EE(1) with selector SPKI(1) as defined in <xref
target="RFC7671"></xref> but without PKIX validation.</t> target="RFC7671" format="default"/>, but without PKIX validation.</t>
<t>If the IPsec connection is a split-tunnel configuration and the <t>If the IPsec connection is a split-tunnel configuration and the
initiator negotiated INTERNAL_DNS_DOMAIN as per <xref initiator negotiated INTERNAL_DNS_DOMAIN as per <xref target="RFC8598" for
target="RFC8598"></xref>, the DNS client resolves the internal names mat="default"/>, the DNS client resolves the internal names
using ENCDNS_IP* DNS resolvers.</t> using ENCDNS_IP* DNS resolvers.</t>
<t indent="3">Note: <xref target="RFC8598" format="default"/> requires t
<t><list style="empty"> hat the INTERNAL_IP6_DNS
<t>Note: <xref target="RFC8598"></xref> requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attribute be present when
(or INTERNAL_IP4_DNS) attribute to be mandatory present when
INTERNAL_DNS_DOMAIN is included. This specification relaxes that INTERNAL_DNS_DOMAIN is included. This specification relaxes that
constraint in the presence of ENCDNS_IP* attributes. That is, if constraint in the presence of ENCDNS_IP* attributes. That is, if
ENCDNS_IP* attributes are supplied, it is allowed for responders to ENCDNS_IP* attributes are supplied, responders are allowed to
include INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS include INTERNAL_DNS_DOMAIN even in the absence of INTERNAL_IP6_DNS
(or INTERNAL_IP4_DNS) attributes.</t> (or INTERNAL_IP4_DNS) attributes.</t>
</list></t>
</section> </section>
<section anchor="hash" numbered="true" toc="default">
<section anchor="hash" title="Subject Public Key Info (SPKI) Hash"> <name>Subject Public Key Info (SPKI) Hash</name>
<t>The SPKI hash of the encrypted DNS resolver certificate is the output <t>The SPKI hash of the encrypted DNS resolver certificate is the output
of a cryptographic hash algorithm whose input is the DER-encoded ASN.1 of a cryptographic hash algorithm whose input is the DER-encoded ASN.1
representation of the SPKI.</t> representation of the SPKI.</t>
<t>Implementations <bcp14>MUST</bcp14> support SHA2-256 <xref target="RFC6
<t>Implementations MUST support SHA2-256 <xref 234" format="default"/>.</t>
target="RFC6234"></xref>.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>This document adheres to the security considerations defined in <xref <t>This document adheres to the security considerations defined in <xref t
target="RFC7296"></xref>. In particular, this document does not alter arget="RFC7296" format="default"/>. In particular, this document does not alter
the trust on the DNS configuration provided by a responder.</t> the trust that the initiator has placed on the DNS configuration provided
by a responder.</t>
<t>Networks are susceptible to internal attacks as discussed in <xref <t>Networks are susceptible to internal attacks as discussed in <xref sect
section="3.2" target="I-D.arkko-farrell-arch-model-t"></xref>. Hosting ion="3.2" target="I-D.arkko-farrell-arch-model-t" format="default"/>. Hosting
encrypted DNS resolvers even in case of split-VPN configuration can encrypted DNS resolvers even in the case of split-VPN configuration can
minimize the attack vector (e.g., a compromised network device cannot minimize the attack vector (e.g., a compromised network device cannot
monitor/modify DNS traffic). This specification describes a mechanism to monitor/modify DNS traffic). This specification describes a mechanism for
restrict access to the DNS messages to only the parties that need to restricting access to the DNS messages to only the parties that need to
know.</t> know.</t>
<t>If the IKEv2 responder has used the NULL Authentication method <xref ta
<t>If the IKEv2 responder has used NULL Authentication method <xref rget="RFC7619" format="default"/> to authenticate itself, the initiator <bcp14>M
target="RFC7619"></xref> to authenticate itself, the initiator MUST NOT UST NOT</bcp14>
use returned ENCDNS_IP* resolvers configuration unless it is use returned ENCDNS_IP* resolvers configuration unless the initiator is
pre-configured, e.g., in the operating system or the application.</t> preconfigured, e.g., in the operating system or the application.</t>
<t>This specification does not extend the scope of accepting DNSSEC <t>This specification does not extend the scope of accepting DNSSEC
trust anchors beyond the usage guidelines defined in <xref section="6" trust anchors beyond the usage guidelines defined in <xref section="6" tar
target="RFC8598"></xref>.</t> get="RFC8598" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>As discussed in <xref target="RFC9076"></xref>, the use of encrypted <t>As discussed in <xref target="RFC9076" format="default"/>, the use of e
ncrypted
DNS does not reduce the data available in the DNS resolver. For example, DNS does not reduce the data available in the DNS resolver. For example,
the reader may refer to <xref section="8" target="RFC8484"></xref> or the reader may refer to <xref section="8" target="RFC8484" format="default
<xref section="7" target="RFC9250"></xref> for a discussion on specific "/> or
privacy considerations to encrypted DNS.</t> <xref section="7" target="RFC9250" format="default"/> for a discussion on
</section> specific
privacy considerations for encrypted DNS.</t>
<section anchor="IANA1" title="IANA Considerations">
<t>This document requests IANA to assign the following new IKEv2
Configuration Payload Attribute Types from the "IKEv2 Configuration
Payload Attribute Types" namespace available at <xref
target="IANA-IKE-CFG"></xref>.</t>
<t><figure>
<artwork><![CDATA[ Multi-
Value Attribute Type Valued Length Reference
TBA1 ENCDNS_IP4 YES 0 or more RFC XXXX
TBA2 ENCDNS_IP6 YES 0 or more RFC XXXX
TBA3 ENCDNS_DIGEST_INFO YES 0 or more RFC XXXX
]]></artwork>
</figure></t>
</section> </section>
<section anchor="IANA1" numbered="true" toc="default">
<section title="Acknowledgements"> <name>IANA Considerations</name>
<t>Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy <t>IANA has assigned the following new IKEv2
Pauly for the review and comments.</t> Configuration Payload Attribute Types in the "IKEv2 Configuration
Payload Attribute Types" namespace available at <xref target="IANA-IKE-CFG
<t>Yoav and Paul suggested the use of one single attribute carrying both " format="default"/>.</t>
the name and an IP address instead of depending on the existing <table anchor="tab-1">
INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes.</t> <thead>
<tr>
<t>Thanks to Tero Kivinen for the Shepherd review and Roman Danyliw for <th>Value</th>
the AD review.</t> <th>Attribute Type</th>
<th>Multivalued</th>
<t>Thanks to Stewart Bryant for the gen-art review, Dhruv Dhody for the <th>Length</th>
ops-dir review, and Patrick Mevzek for the dns-dir review.</t> <th>Reference</th>
</tr>
<t>Thanks to Paul Wouters, Zaheduzzaman Sarker, Eric Vyncke, and Robert </thead>
Wilton for the comments during the IESG review.</t> <tbody>
<tr>
<td>27</td>
<td>ENCDNS_IP4</td>
<td>YES</td>
<td>0 or more</td>
<td>RFC 9464</td>
</tr>
<tr>
<td>28</td>
<td>ENCDNS_IP6</td>
<td>YES</td>
<td>0 or more</td>
<td>RFC 9464</td>
</tr>
<tr>
<td>29</td>
<td>ENCDNS_DIGEST_INFO</td>
<td>YES</td>
<td>0 or more</td>
<td>RFC 9464</td>
</tr>
</tbody>
</table>
</section> </section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.RFC.7296'?>
<?rfc include='reference.RFC.8310'?>
<?rfc include='reference.RFC.5890'?>
<?rfc include='reference.RFC.6234'?>
<?rfc include='reference.I-D.ietf-dnsop-svcb-https'?>
<?rfc include='reference.RFC.8598'?>
<reference anchor="IANA-IKE-HASH"
target="https://www.iana.org/assignments/ikev2-parameters/ikev2
-parameters.xhtml#hash-algorithms">
<front>
<title>IKEv2 Hash Algorithms</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.8499'?>
<?rfc include='reference.RFC.7858'?>
<?rfc include='reference.RFC.9250'?>
<?rfc include='reference.RFC.8484'?> <displayreference target="I-D.arkko-farrell-arch-model-t" to="INTERNET-THREAT-MO
DEL"/>
<?rfc include='reference.RFC.7619'?>
<?rfc include='reference.RFC.7671'?>
<?rfc include='reference.RFC.9076'?> <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.7
296.xml"/>
<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
890.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
234.xml"/>
<?rfc include='reference.RFC.8613'?> <!-- 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 HTT
PS 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>
<?rfc include='reference.I-D.ietf-add-dnr'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 598.xml"/>
<?rfc include='reference.I-D.arkko-farrell-arch-model-t'?> <reference anchor="IANA-IKE-HASH" target="https://www.iana.org/assignmen
ts/ikev2-parameters/">
<front>
<title>IKEv2 Hash Algorithms</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
499.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
858.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
250.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.7
619.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
671.xml"/>
<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.8
613.xml"/>
<reference anchor="IANA-IKE-CFG" <!-- draft-ietf-add-dnr (RFC 9463) -->
target="https://www.iana.org/assignments/ikev2-parameters/ikev2 <reference anchor='RFC9463' target='https://www.rfc-editor.org/info/rfc9463'>
-parameters.xhtml#ikev2-parameters-21"> <front>
<front> <title>
<title>IKEv2 Configuration Payload Attribute Types</title> DHCP and Router Advertisement Options for the Discovery of Network-designated Re
solvers (DNR)
</title>
<author initials="M." surname="Boucadair" fullname="Mohamed Boucadair" role="edi
tor">
<organization>Orange</organization>
</author>
<author initials="T." surname="Reddy.K" fullname="Tirumaleswar Reddy.K" role="ed
itor">
<organization>Nokia</organization>
</author>
<author initials="D." surname="Wing" fullname="Dan Wing">
<organization>Cloud Software Group</organization>
</author>
<author initials="N." surname="Cook" fullname="Neil Cook">
<organization>Open-Xchange</organization>
</author>
<author initials="T." surname="Jensen" fullname="Tommy Jensen">
<organization>Microsoft</organization>
</author>
<date month="November" year="2023"/>
</front>
<seriesInfo name="RFC" value="9463"/>
<seriesInfo name="DOI" value="10.17487/RFC9463"/>
</reference>
<author> <!-- draft-arkko-farrell-arch-model-t (Expired)
<organization></organization> Had to add "draft-" and "-04" per Robert Sparks in order to get
</author> the link to work -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.draf
t-arkko-farrell-arch-model-t-04.xml"/>
<date /> <reference anchor="IANA-IKE-CFG" target="https://www.iana.org/assignment
</front> s/ikev2-parameters/">
</reference> <front>
<title>IKEv2 Configuration Payload Attribute Types</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references>
</references> </references>
<section numbered="true" toc="default">
<section title="Configuration Payload Examples"> <name>Configuration Payload Examples</name>
<t></t> <section numbered="true" toc="default">
<name>Configuration of Encrypted IPv6 DNS Resolvers without Suggested Va
<section title="Configuration of Encrypted IPv6 DNS Resolvers without Sugg lues</name>
ested Values"> <t><xref target="ex1" format="default"/> depicts an example of a CFG_REQ
<t><xref target="ex1"></xref> depicts an example of a CFG_REQUEST to UEST to
request the configuration of IPv6 DNS resolvers without providing any request the configuration of IPv6 DNS resolvers without providing any
suggested values. In this example, the initiator uses the suggested values. In this example, the initiator uses the
ENCDNS_DIGEST_INFO attribute to indicate that the encrypted DNS client ENCDNS_DIGEST_INFO attribute to indicate that the encrypted DNS client
supports SHA2-256 (2), SHA2-384 (3), and SHA2-512 (4) hash algorithms supports SHA2-256 (2), SHA2-384 (3), and SHA2-512 (4) hash algorithms
for certificate digests. The label of these algorithms is taken from for certificate digests. The label of these algorithms is taken from
<xref target="IANA-IKE-HASH"></xref>. The use of INTERNAL_IP6_ADDRESS <xref target="IANA-IKE-HASH" format="default"/>. The use of INTERNAL_IP6
is explained in <xref target="RFC7296"></xref>; it is thus not _ADDRESS
is explained in <xref target="RFC7296" format="default"/> and thus is no
t
reiterated here.</t> reiterated here.</t>
<figure anchor="ex1">
<t><figure anchor="ex1" title="Example of CFG_REQUEST"> <name>Example of a CFG_REQUEST</name>
<artwork><![CDATA[CP(CFG_REQUEST) = <artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REQUEST)
=
INTERNAL_IP6_ADDRESS() INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS() INTERNAL_IP6_DNS()
ENCDNS_IP6() ENCDNS_IP6()
ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))]]></artwork> ENCDNS_DIGEST_INFO(0, (SHA2-256, SHA2-384, SHA2-512))
</figure></t> ]]></artwork>
</figure>
<t><xref target="ex2"></xref> depicts an example of a CFG_REPLY that <t><xref target="ex2" format="default"/> depicts an example of a CFG_REP
can be sent by a responder as a response the above CFG_REQUEST. This LY that
can be sent by a responder as a response to the above CFG_REQUEST. This
response indicates the following information to identify the encrypted response indicates the following information to identify the encrypted
DNS resolver:</t> DNS resolver:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Its service priority, which is 1.</li>
<t>Its Service Priority is 1</t> <li>Its single (1) IPv6 address (2001:db8:99:88:77:66:55:44).</li>
<li>Its ADN (doh.example.com). This ADN has
<t>Its single (1) IPv6 address (2001:db8:99:88:77:66:55:44)</t> a length of 15.</li>
<li>Its supported HTTP version (h2).</li>
<t>Its authentication domain name (doh.example.com). This ADN has <li>The relative form of the URI Template (/dns-query{?dns}).</li>
a length of 15.</t> <li>The SPKI hash of the resolver's certificate using SHA2-256
(8b6e7a5971cc6bb0b4db5a71...).</li>
<t>Its supported HTTP version (h2)</t> </ul>
<figure anchor="ex2">
<t>The relative form of the URI Template (/dns-query{?dns})</t> <name>Example of a CFG_REPLY</name>
<artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REPLY) =
<t>The SPKI hash of the resolver's certificate using SHA2-256
(8b6e7a5971cc6bb0b4db5a71...)</t>
</list><figure anchor="ex2" title="Example of CFG_REPLY">
<artwork><![CDATA[CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64) INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64)
ENCDNS_IP6(1, 1, 15, ENCDNS_IP6(1, 1, 15,
(2001:db8:99:88:77:66:55:44), (2001:db8:99:88:77:66:55:44),
"doh.example.com", "doh.example.com",
(alpn=h2 dohpath=/dns-query{?dns})) (alpn=h2 dohpath=/dns-query{?dns}))
ENCDNS_DIGEST_INFO(0, SHA2-256, ENCDNS_DIGEST_INFO(0, SHA2-256,
8b6e7a5971cc6bb0b4db5a71...) 8b6e7a5971cc6bb0b4db5a71...)
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>In the example depicted in <xref target="ex2" format="default"/>, no
<t>In the example depicted in <xref target="ex2"></xref>, no ADN is ADN is
included in the ENCDNS_DIGEST_INFO attribute because only one ADN is included in the ENCDNS_DIGEST_INFO attribute because only one ADN is
provided in the ENCDNS_IP6 attribute. There is no ambiguity to provided in the ENCDNS_IP6 attribute. Identifying the encrypted resolver
identify the encrypted resolver associated with the supplied associated with the supplied digest is therefore unambiguous.</t>
digest.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Configuration of Encrypted IPv6 DNS Resolvers with Suggest <name>Configuration of Encrypted IPv6 DNS Resolvers with Suggested Value
ed Values"> s</name>
<t>An initiator may provide suggested values in the CFG_REQUEST when <t>An initiator may provide suggested values in the CFG_REQUEST when
requesting an encrypted DNS resolver. For example, the initiator requesting an encrypted DNS resolver. For example, the initiator
may:</t> may:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Indicate a preferred resolver that is identified by an IPv6 <t>Indicate a preferred resolver that is identified by an IPv6
address (see <xref target="ex3"></xref>).<figure anchor="ex3" address (see <xref target="ex3" format="default"/>).</t>
title="Example of CFG_REQUEST with a Preferred Resolver Identifi <figure anchor="ex3">
ed by Its IP Address"> <name>Example of a CFG_REQUEST with a Preferred Resolver Identifie
<artwork><![CDATA[CP(CFG_REQUEST) = d by Its IP Address</name>
<artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REQUE
ST) =
INTERNAL_IP6_ADDRESS() INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS() INTERNAL_IP6_DNS()
ENCDNS_IP6(1, 1, 0, ENCDNS_IP6(1, 1, 0,
(2001:db8:99:88:77:66:55:44)) (2001:db8:99:88:77:66:55:44))
]]></artwork> ]]></artwork>
</figure></t> </figure>
</li>
<li>
<t>Indicate a preferred resolver that is identified by an ADN (see <t>Indicate a preferred resolver that is identified by an ADN (see
<xref target="ex4"></xref>).<figure anchor="ex4" <xref target="ex4" format="default"/>).</t>
title="Example of CFG_REQUEST with a Preferred Resolver Identifi <figure anchor="ex4">
ed by Its ADN"> <name>Example of a CFG_REQUEST with a Preferred Resolver Identifie
<artwork><![CDATA[CP(CFG_REQUEST) = d by Its ADN</name>
<artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REQUE
ST) =
INTERNAL_IP6_ADDRESS() INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS() INTERNAL_IP6_DNS()
ENCDNS_IP6(1, 0, 15, "doh.example.com") ENCDNS_IP6(1, 0, 15, "doh.example.com")
]]></artwork> ]]></artwork>
</figure></t> </figure>
</li>
<li>
<t>Indicate a preferred transport protocol (DoT, in the example <t>Indicate a preferred transport protocol (DoT, in the example
depicted in <xref target="ex5"></xref>)<figure anchor="ex5" depicted in <xref target="ex5" format="default"/>).</t>
title="Example of CFG_REQUEST with a Preferred Transport Protoco <figure anchor="ex5">
l"> <name>Example of a CFG_REQUEST with a Preferred Transport Protocol
<artwork><![CDATA[CP(CFG_REQUEST) = </name>
<artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REQUE
ST) =
INTERNAL_IP6_ADDRESS() INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS() INTERNAL_IP6_DNS()
ENCDNS_IP6(1, 0, 0, (alpn=dot)) ENCDNS_IP6(1, 0, 0, (alpn=dot))
]]></artwork> ]]></artwork>
</figure></t> </figure>
</li>
<t>or any combination thereof.</t> <li>or any combination thereof.</li>
</list></t> </ul>
</section> </section>
<section numbered="true" toc="default">
<section title="Split DNS"> <name>Split DNS</name>
<t>An initiator may also indicate that it supports Split DNS by <t>An initiator may also indicate that it supports Split DNS by
including the INTERNAL_DNS_DOMAIN attribute in a CFG_REQUEST as shown including the INTERNAL_DNS_DOMAIN attribute in a CFG_REQUEST as shown
in <xref target="ex6"></xref>. In this example, the initiator does not in <xref target="ex6" format="default"/>. In this example, the initiator
indicate any preference for the requested encrypted DNS server nor does not
indicate any preference for the requested encrypted DNS server, nor does
it indicate
which DNS queries will be forwarded through the IPsec tunnel.</t> which DNS queries will be forwarded through the IPsec tunnel.</t>
<figure anchor="ex6">
<t><figure anchor="ex6" <name>Example of a CFG_REQUEST with Support for Split DNS</name>
title="Example of CFG_REQUEST with Support of Split DNS"> <artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REQUEST)
<artwork><![CDATA[CP(CFG_REQUEST) = =
INTERNAL_IP6_ADDRESS() INTERNAL_IP6_ADDRESS()
INTERNAL_IP6_DNS() INTERNAL_IP6_DNS()
ENCDNS_IP6() ENCDNS_IP6()
INTERNAL_DNS_DOMAIN() INTERNAL_DNS_DOMAIN()
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t><xref target="ex7" format="default"/> shows an example of the respond
<t><xref target="ex7"></xref> shows an example of a reply of the er's reply. Absent any prohibited local policy, the initiator uses the
responder. Absent any prohibited local policy, the initiator uses the
encrypted DNS server (doh.example.com) for any subsequent DNS queries encrypted DNS server (doh.example.com) for any subsequent DNS queries
for "example.com" and its subdomains.</t> for "example.com" and its subdomains.</t>
<figure anchor="ex7">
<t><figure anchor="ex7" <name>Example of a CFG_REPLY with INTERNAL_DNS_DOMAIN</name>
title="Example of CFG_REPLY with INTERNAL_DNS_DOMAIN"> <artwork name="" type="" align="left" alt=""><![CDATA[CP(CFG_REPLY) =
<artwork><![CDATA[CP(CFG_REPLY) =
INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64) INTERNAL_IP6_ADDRESS(2001:db8:0:1:2:3:4:5/64)
ENCDNS_IP6(1, 1, 15, ENCDNS_IP6(1, 1, 15,
(2001:db8:99:88:77:66:55:44), (2001:db8:99:88:77:66:55:44),
"doh.example.com", "doh.example.com",
(alpn=h2 dohpath=/dns-query{?dns})) (alpn=h2 dohpath=/dns-query{?dns}))
INTERNAL_DNS_DOMAIN(example.com) INTERNAL_DNS_DOMAIN(example.com)
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t></t>
</section> </section>
</section> </section>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>Many thanks to <contact fullname="Yoav Nir"/>, <contact fullname="Chris
tian Jacquenet"/>, <contact fullname="Paul Wouters"/>, and <contact fullname="To
mmy Pauly"/> for their reviews and comments.</t>
<t><contact fullname="Yoav"/> and <contact fullname="Paul"/> suggested the
use of one single attribute carrying both
the name and an IP address instead of depending on the existing
INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes.</t>
<t>Thanks to <contact fullname="Tero Kivinen"/> for the Shepherd review an
d <contact fullname="Roman Danyliw"/> for
the AD review.</t>
<t>Thanks to <contact fullname="Stewart Bryant"/> for the gen-art review,
<contact fullname="Dhruv Dhody"/> for the
ops-dir review, and <contact fullname="Patrick Mevzek"/> for the dns-dir r
eview.</t>
<t>Thanks to <contact fullname="Paul Wouters"/>, <contact fullname="Zahedu
zzaman Sarker"/>, <contact fullname="Éric Vyncke"/>, and <contact fullname="Robe
rt Wilton"/> for their comments during the IESG review.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 145 change blocks. 
608 lines changed or deleted 635 lines changed or added

This html diff was produced by rfcdiff 1.48.