rfc8973xml2.original.xml   rfc8973.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dots-server-
<?rfc tocdepth="3"?> discovery-15" number="8973" ipr="trust200902" obsoletes="" updates="" submission
<?rfc tocindent="yes"?> Type="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocD
<?rfc symrefs="yes"?> epth="3" symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?> <!-- xml2rfc v2v3 conversion 3.4.0 -->
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-dots-server-discovery-15"
ipr="trust200902">
<front> <front>
<title <title abbrev="DOTS Server/Call Home Client Discovery">DDoS
abbrev="DOTS Server/Call Home Client Discovery">Distributed-Denial-of-Servic
e
Open Threat Signaling (DOTS) Agent Discovery</title> Open Threat Signaling (DOTS) Agent Discovery</title>
<seriesInfo name="RFC" value="8973"/>
<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>
<region/>
<region></region>
<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 abbrev="McAfee">McAfee, Inc.</organization> <organization abbrev="McAfee">McAfee, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Embassy Golf Link Business Park</street> <street>Embassy Golf Link Business Park</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560071</code> <code>560071</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>TirumaleswarReddy_Konda@McAfee.com</email> <email>TirumaleswarReddy_Konda@McAfee.com</email>
</address> </address>
</author> </author>
<date year="2021" month="January"/>
<date />
<workgroup>DOTS</workgroup> <workgroup>DOTS</workgroup>
<keyword>Automation</keyword> <keyword>Automation</keyword>
<keyword>Provisioning</keyword> <keyword>Provisioning</keyword>
<keyword>Configuration</keyword> <keyword>Configuration</keyword>
<keyword>Location</keyword> <keyword>Location</keyword>
<keyword>Deployment</keyword> <keyword>Deployment</keyword>
<keyword>Multihoming</keyword> <keyword>Multihoming</keyword>
<keyword>DDoS</keyword> <keyword>DDoS</keyword>
<keyword>Security</keyword> <keyword>Security</keyword>
<abstract> <abstract>
<t>This document specifies mechanisms to configure Distributed Denial of <t>This document specifies mechanisms to configure DDoS
Service Open Threat Signaling (DOTS) clients with their DOTS servers. Open Threat Signaling (DOTS) clients with their DOTS servers.
The discovery procedure also covers the DOTS Signal Channel Call Home. The discovery procedure also covers the DOTS signal channel Call Home.
Knowing the appropriate DOTS server for a given location can be useful It can be useful to know the appropriate DOTS server for a given location
to engage mitigation actions even in cases where the DOTS client cannot in order to engage mitigation actions. This is true even in cases where th
localize the attack, but only knows that some resources are under attack e DOTS client cannot
localize the attack: cases where it only knows that some resources are und
er attack
and that help is needed.</t> and that help is needed.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>DDoS Open Threat Signaling (DOTS) <xref target="RFC8811"></xref> <name>Introduction</name>
specifies an architecture, in which a DOTS client can inform a DOTS <t>DDoS Open Threat Signaling (DOTS) <xref target="RFC8811" format="defaul
t"/>
specifies an architecture in which a DOTS client can inform a DOTS
server that the network is under a potential attack and that appropriate server that the network is under a potential attack and that appropriate
mitigation actions are required. Indeed, because the lack of a common mitigation actions are required. Indeed, because the lack of a common
method to coordinate a real-time response among involved actors and method to coordinate a real-time response among involved actors and
network domains inhibits the effectiveness of DDoS attack mitigation, network domains inhibits the effectiveness of DDoS attack mitigation,
the DOTS signal channel protocol <xref target="RFC8782"></xref> is meant the DOTS signal channel protocol <xref target="RFC8782" format="default"/> is meant
to carry requests for DDoS attack mitigation. With this approach, DOTS to carry requests for DDoS attack mitigation. With this approach, DOTS
can reduce the impact of an attack and lead to more efficient defensive can reduce the impact of an attack and lead to more efficient defensive
actions in various deployment scenarios such as those discussed in <xref actions in various deployment scenarios, such as those discussed in <xref
target="I-D.ietf-dots-use-cases"></xref>. Moreover, DOTS clients can target="I-D.ietf-dots-use-cases" format="default"/>. Moreover, DOTS clients can
instruct a DOTS server to install named filtering rules by means of the instruct a DOTS server to install named filtering rules by means of the
DOTS data channel protocol <xref target="RFC8783"></xref>.</t> DOTS data channel protocol <xref target="RFC8783" format="default"/>.</t>
<t>The basic high-level DOTS architecture is illustrated in <xref target="
<t>The basic high-level DOTS architecture is illustrated in <xref arch" format="default"/>.</t>
target="arch"></xref>.</t> <figure anchor="arch">
<name>Basic DOTS Architecture</name>
<t><figure align="center" anchor="arch" title="Basic DOTS Architecture"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[ +-----------+ +---- +-----------+ +-------------+
---------+ | Mitigator | ~~~~~~~~~~ | DOTS Server |
| Mitigator | ~~~~~~~~~~ | DOTS Server | +-----------+ +------+------+
+-----------+ +------+------+ |
| |
| |
| +---------------+ +------+------+
+---------------+ +------+------+ | Attack Target | ~~~~~~ | DOTS Client |
| Attack Target | ~~~~~~ | DOTS Client | +---------------+ +-------------+
+---------------+ +-------------+
]]></artwork> ]]></artwork>
</figure></t> ---------------+ +-------------+
</figure>
<t><xref target="RFC8811"></xref> specifies that the DOTS client may be <t><xref target="RFC8811" format="default"/> specifies that the DOTS clien
t may be
provided with a list of DOTS servers, each associated with one or more provided with a list of DOTS servers, each associated with one or more
IP addresses. These addresses may or may not be of the same address IP addresses. These addresses may or may not be of the same address
family. The DOTS client establishes one or more DOTS sessions by family. The DOTS client establishes one or more DOTS sessions by
connecting to the provided DOTS server addresses.</t> connecting to the provided DOTS server addresses.</t>
<t>This document specifies methods for DOTS clients to discover their <t>This document specifies methods for DOTS clients to discover their
DOTS server(s). The rationale for specifying multiple discovery DOTS server(s). The rationale for specifying multiple discovery
mechanisms is discussed in <xref target="rationale"></xref>.</t> mechanisms is discussed in <xref target="rationale" format="default"/>.</t
>
<t>The discovery methods can also be used by a DOTS server to locate a <t>The discovery methods can also be used by a DOTS server to locate a
DOTS client in the context of DOTS Signal Channel Call Home <xref DOTS client in the context of DOTS signal channel Call Home <xref target="
target="I-D.ietf-dots-signal-call-home"></xref>. The basic high-level I-D.ietf-dots-signal-call-home" format="default"/>. The basic high-level
DOTS Call Home architecture is illustrated in <xref DOTS Call Home architecture is illustrated in <xref target="fa" format="de
target="fa"></xref>.</t> fault"/>.</t>
<figure anchor="fa">
<t><figure align="center" anchor="fa" <name>Basic DOTS Signal Channel Call Home Functional Architecture</name>
title="Basic DOTS Signal Channel Call Home Functional Architecture"> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center"><![CDATA[+---------------+ +----------- +---------------+ +-------------+
--+
| Alert | ~~~~~~ | Call Home | | Alert | ~~~~~~ | Call Home |
| | | DOTS client | | | | DOTS Client |
+---------------+ +------+------+ +---------------+ +------+------+
| |
| |
| |
+---------------+ +------+------+ +---------------+ +------+------+
| Attack | ~~~~~~ | Call Home | | Attack | ~~~~~~ | Call Home |
| Source(s) | | DOTS server | | Source(s) | | DOTS Server |
+---------------+ +-------------+ ]]></artwork> +---------------+ +-------------+
</figure></t> ]]></artwork>
</figure>
<t>A DOTS agent may be used to establish base DOTS channels, DOTS Call <t>A DOTS agent may be used to establish base DOTS channels, DOTS Call
Home, or both. This specification accommodates all these deployment Home, or both. This specification accommodates all these deployment
cases.</t> cases.</t>
<t>Considerations for the selection of DOTS server(s) by multihomed
<t>Considerations for the selection of DOTS server(s) by multi-homed DOTS clients are out of this document's scope; readers should refer to
DOTS clients are out of this document scope; readers should refer to <xref target="I-D.ietf-dots-multihoming" format="default"/> for more detai
<xref target="I-D.ietf-dots-multihoming"></xref> for more details.</t> ls.</t>
<t>This document assumes that security credentials to authenticate DOTS <t>This document assumes that security credentials to authenticate DOTS
server(s) are pre-provisioned to a DOTS client using a mechanism such as server(s) are pre-provisioned to a DOTS client using a mechanism such as
(but not limited to) those discussed in <xref target="RFC8572"></xref> (but not limited to) those discussed in <xref target="RFC8572" format="def
or <xref target="I-D.ietf-anima-bootstrapping-keyinfra"></xref>. DOTS ault"/>
or <xref target="I-D.ietf-anima-bootstrapping-keyinfra" format="default"/>
. DOTS
clients use those credentials for authentication purposes following the clients use those credentials for authentication purposes following the
rules documented in <xref target="RFC8782"></xref>.</t> rules documented in <xref target="RFC8782" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
only when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>The reader should be familiar with the terms defined in <xref be interpreted as
target="RFC3958"></xref>.</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
<t>DHCP refers to both DHCPv4 <xref target="RFC2131"></xref> and DHCPv6 </t>
<xref target="RFC8415"></xref>.</t> <t>The reader should be familiar with the terms defined in <xref target="
RFC3958"
<t>"DOTS client" refers to a DOTS-aware software module responsible for format="default"/>.</t>
<t>This document makes use of the following terms:</t>
<dl newline="false" spacing="normal">
<dt>DHCP:</dt>
<dd>refers to both DHCPv4 <xref target="RFC2131" format="default"/> and DH
CPv6
<xref target="RFC8415" format="default"/>.</dd>
<dt>DOTS client:</dt>
<dd>refers to a DOTS-aware software module responsible for
requesting attack response coordination with other DOTS-aware requesting attack response coordination with other DOTS-aware
elements.</t> elements.</dd>
<dt>DOTS server:</dt>
<t>"DOTS server" is a DOTS-aware software module handling and responding <dd>is a DOTS-aware software module handling and responding
to messages from DOTS clients. The DOTS server enables mitigation on to messages from DOTS clients. The DOTS server enables mitigation on
behalf of the DOTS client, if requested, by communicating the DOTS behalf of the DOTS client, if requested, by communicating the DOTS
client's request to the mitigator and returning selected mitigator client's request to the mitigator and returning selected mitigator
feedback to the requesting DOTS client.</t> feedback to the requesting DOTS client.</dd>
<dt>Call Home DOTS client or server:</dt>
<t>"Call Home DOTS client" (or "Call Home DOTS server") refers to a DOTS <dd>refers to a DOTS
client (or DOTS server) deployed in a Call Home scenario (<xref client or server deployed in a Call Home scenario (<xref target="fa" forma
target="fa"></xref>).</t> t="default"/>).</dd>
<dt>DOTS agent:</dt>
<t>"DOTS agent" is any DOTS-aware software module capable of <dd>is any DOTS-aware software module capable of
participating in a DOTS channel.</t> participating in a DOTS channel.</dd>
<dt>Peer DOTS agent:</dt>
<t>"Peer DOTS agent" refers to the peer DOTS server (base DOTS <dd>refers to the peer DOTS server (base DOTS
operation) or to a peer Call Home DOTS client (for DOTS Signal Channel operation) or to a peer Call Home DOTS client (for DOTS signal channel
Call Home).</t> Call Home).</dd>
</dl>
</section> </section>
<section anchor="rationale" numbered="true" toc="default">
<section anchor="rationale" title="Why Multiple Discovery Mechanisms?"> <name>Why Multiple Discovery Mechanisms?</name>
<t>Analysis of the various use cases sketched in <xref <t>Analysis of the various use cases sketched in <xref target="I-D.ietf-do
target="I-D.ietf-dots-use-cases"></xref> reveals that it is unlikely ts-use-cases" format="default"/> reveals that it is unlikely
that one single discovery method can be suitable for all the sample that one single discovery method can be suitable for all the sample
deployments. Concretely:<list style="symbols"> deployments. Concretely:</t>
<t>Many of the use cases discussed in <xref <ul spacing="normal">
target="I-D.ietf-dots-use-cases"></xref> do involve a Customer <li>Many of the use cases discussed in <xref target="I-D.ietf-dots-use-c
Premises Equipment (CPE) device. Multiple CPEs, connected to ases" format="default"/>
distinct network providers, may even be considered. It is intuitive do involve Customer Premises Equipment (CPE). Multiple CPEs connected t
to leverage existing mechanisms such as discovery using service o
resolution or DHCP to provision the CPE acting as a DOTS client with distinct network providers may even be considered.
the DOTS server(s).</t> It is intuitive
to leverage existing mechanisms, such as discovery using service
<t>Resolving a DOTS server domain name offered by an upstream resolution or DHCP, to provision the CPE acting as a DOTS client with
the DOTS server(s).</li>
<li>Resolving a DOTS server domain name offered by an upstream
transit provider provisioned to a DOTS client into IP address(es) transit provider provisioned to a DOTS client into IP address(es)
requires the use of the appropriate DNS resolvers; otherwise, requires the use of the appropriate DNS resolvers; otherwise,
resolving those names will fail. The use of protocols such as DHCP resolving those names will fail. The use of protocols, such as DHCP,
does allow associating provisioned DOTS server domain names with a does allow associating provisioned DOTS server domain names with a
list of DNS servers to be used for name resolution. Furthermore, list of DNS servers to be used for name resolution. Furthermore,
DHCP allows directly providing IP addresses therefore avoiding the DHCP allows for directly providing IP addresses, therefore, avoiding t
need for extra lookup delays.</t> he
need for extra lookup delays.</li>
<t>Some of the use cases may allow DOTS clients to have direct <li>Some of the use cases may allow DOTS clients to have direct
communications with upstream DOTS servers, that is, no DOTS gateway communications with upstream DOTS servers, that is, no DOTS gateway
is involved. Leveraging existing protocol behaviors that do not is involved. Leveraging existing protocol behaviors that do not
require specific features on the node embedding the DOTS client may require specific features on the node embedding the DOTS client may
ease DOTS deployment. Typically, the use of Straightforward-Naming ease DOTS deployment. Typically, the use of Straightforward-Naming
Authority Pointer (S-NAPTR) lookups <xref target="RFC3958"></xref> Authority Pointer (S-NAPTR) lookups <xref target="RFC3958" format="def ault"/>
allows the DOTS server administrators to provision the preferred allows the DOTS server administrators to provision the preferred
DOTS transport protocol between the DOTS client and the DOTS server DOTS transport protocol between the DOTS client and the DOTS server
and allows the DOTS client to discover this preference.</t> and allows the DOTS client to discover this preference.</li>
<li>The upstream network provider is not the DDoS mitigation provider
<t>The upstream network provider is not the DDoS mitigation provider for some of these use cases. It is safe to assume that, for such
for some of these use cases. It is safe to assume that for such
deployments, the DOTS server(s) domain name is provided during the deployments, the DOTS server(s) domain name is provided during the
service subscription (i.e., manual/local configuration).</t> service subscription (i.e., manual/local configuration).</li>
<li>Multiple DOTS clients may be enabled within a network (e.g., an
<t>Multiple DOTS clients may be enabled within a network (e.g.,
enterprise network). Dynamic discovery needs to be deterministic enterprise network). Dynamic discovery needs to be deterministic
from an operational standpoint.</t> from an operational standpoint.</li>
<li>Some of the use cases may involve a DOTS gateway that is
<t>Some of the use cases may involve a DOTS gateway that is
responsible for selecting the appropriate DOTS server(s) to relay responsible for selecting the appropriate DOTS server(s) to relay
requests received from DOTS clients.</t> requests received from DOTS clients.</li>
</list></t> </ul>
<t>Consequently, this document describes a unified discovery logic <t>Consequently, this document describes a unified discovery logic
(<xref target="logic"></xref>) which involves the following (<xref target="logic" format="default"/>) that involves the following
mechanisms:</t> mechanisms:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>dynamic discovery using DHCP (<xref target="dhcp" format="default"/>
<t>Dynamic discovery using DHCP (<xref target="dhcp"></xref>).</t> )</li>
<li>a resolution mechanism based on S-NAPTR resource records in the DNS
<t>A resolution mechanism based on Straightforward Naming Authority (<xref target="srvr" format="default"/>)</li>
Pointer (S-NAPTR) resource records in the Domain Name System (DNS) <li>DNS Service Discovery (<xref target="DNSSD" format="default"/>)</li>
(<xref target="srvr"></xref>).</t> </ul>
<t>DNS Service Discovery (<xref target="DNSSD"></xref>).</t>
</list></t>
</section> </section>
<section anchor="logic" numbered="true" toc="default">
<section anchor="logic" title="DOTS Discovery Procedure"> <name>DOTS Discovery Procedure</name>
<t>Operators will need a consistent set of ways in which DOTS clients <t>Operators will need a consistent set of ways in which DOTS clients
can discover this information and a consistent priority among these can discover this information and a consistent priority among these
options. If some devices prefer manual configuration over dynamic options. If some devices prefer manual configuration over dynamic
discovery, while others prefer dynamic discovery over manual discovery while others prefer dynamic discovery over manual
configuration, the result will be a process where the operator must find configuration, the result will be a process where the operator must find
devices that are using the wrong DOTS server(s), determine how to ensure devices that are using the wrong DOTS server(s), determine how to ensure
the devices are configured properly, and then reconfigure the device the devices are configured properly, and then reconfigure the device
through the preferred method.</t> through the preferred method.</t>
<t>All DOTS clients <bcp14>MUST</bcp14> support at least one of the three
<t>All DOTS clients MUST support at least one of the three mechanisms mechanisms
below to determine a DOTS server list. All DOTS clients SHOULD implement below to determine a DOTS server list. All DOTS clients <bcp14>SHOULD</bcp
14> implement
all three, or as many as are practical for any specific device, of the all three, or as many as are practical for any specific device, of the
following ways to discover DOTS servers in order to facilitate the following ways to discover DOTS servers in order to facilitate the
deployment of DOTS in large scale environments. For example, a CPE will deployment of DOTS in large-scale environments. For example, a CPE will
support the first two mechanisms, a host within a LAN will support the support the first two mechanisms, a host within a LAN will support the
last two mechanisms, or an application server will support a local last two mechanisms, or an application server will support a local
configuration. More examples are discussed in <xref configuration. More examples are discussed in <xref target="rationale" for
target="rationale"></xref>. DOTS clients will prefer information mat="default"/>. DOTS clients will prefer information
received from the discovery methods in the order listed below.</t> received from the discovery methods in the order listed below.</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> <t>Explicit Configuration:</t>
<t>Explicit configuration:<list style="symbols"> <dl newline="false" spacing="normal">
<t>Local/Manual configuration: A DOTS client will learn the DOTS <dt>Local/Manual Configuration:</dt>
<dd><t>A DOTS client will learn the DOTS
server(s) by means of local or manual DOTS configuration (i.e., server(s) by means of local or manual DOTS configuration (i.e.,
DOTS servers configured at the system level). Configuration DOTS servers configured at the system level). Configuration
discovered from a DOTS client application is considered as local discovered from a DOTS client application is considered a local
configuration.<vspace blankLines="1" />An implementation may configuration.</t>
<t>An implementation may
give the user an opportunity (e.g., by means of configuration give the user an opportunity (e.g., by means of configuration
file options or menu items) to specify DOTS server(s) for each file options or menu items) to specify DOTS server(s) for each
address family. These may be specified either as a list of IP address family. These may be specified either as a list of IP
addresses or the DNS name of a DOTS server. When only DOTS addresses or the DNS name of a DOTS server. When only DOTS
server IP addresses are configured, a reference identifier must server IP addresses are configured, a reference identifier must
also be configured for authentication purposes.</t> also be configured for authentication purposes.</t></dd>
</dl>
<t>Automatic configuration (e.g., DHCP): The DOTS client <dl newline="false" spacing="normal">
<dt>Automatic Configuration (e.g., DHCP):</dt>
<dd>The DOTS client
attempts to discover DOTS server(s) names and/or addresses from attempts to discover DOTS server(s) names and/or addresses from
DHCP, as described in <xref target="dhcp"></xref>.</t> DHCP, as described in <xref target="dhcp" format="default"/>.</dd>
</list></t> </dl>
</li>
<t>Service Resolution : The DOTS client attempts to discover DOTS <li>Service Resolution: The DOTS client attempts to discover DOTS
server name(s) using service resolution, as specified in <xref server name(s) using service resolution, as specified in <xref target=
target="srvr"></xref>.</t> "srvr" format="default"/>.</li>
<li>DNS-SD: DNS-based Service Discovery. The DOTS client attempts to
<t>DNS SD: DNS Service Discovery. The DOTS client attempts to
discover DOTS server name(s) using DNS service discovery, as discover DOTS server name(s) using DNS service discovery, as
specified in <xref target="DNSSD"></xref>.</t> specified in <xref target="DNSSD" format="default"/>.</li>
</list></t> </ol>
<t>Some of these mechanisms imply the use of DNS to resolve the IP <t>Some of these mechanisms imply the use of DNS to resolve the IP
address(es) of the DOTS server, while others imply an IP address of the address(es) of the DOTS server, while others imply an IP address of the
relevant DOTS server is obtained directly. Implementation options may relevant DOTS server is obtained directly. Implementation options may
vary on a per device basis, as some devices may not have DNS vary on a per-device basis, as some devices may not have DNS
capabilities and/or suitable DNS configuration.</t> capabilities and/or suitable DNS configuration.</t>
<t>On hosts with more than one interface or address family (IPv4/IPv6), <t>On hosts with more than one interface or address family (IPv4/IPv6),
the DOTS server discovery procedure has to be performed for each the DOTS server discovery procedure has to be performed for each
interface/address-family combination. A DOTS client may choose to interface-/address-family combination. A DOTS client may choose to
perform the discovery procedure only for a desired interface/address perform the discovery procedure only for a desired interface/address
combination if the client does not wish to discover a DOTS server for combination if the client does not wish to discover a DOTS server for
all interface/address-family combinations.</t> all interface-/address-family combinations.</t>
<t>This procedure is also followed by a Call Home DOTS server to <t>This procedure is also followed by a Call Home DOTS server to
discover its Call Home DOTS client in the context of <xref discover its Call Home DOTS client in the context of <xref target="I-D.iet
target="I-D.ietf-dots-signal-call-home"></xref>.</t> f-dots-signal-call-home" format="default"/>.</t>
<t>The discovery method is performed upon the bootstrapping of a DOTS agen
<t>The discovery method is performed upon bootstrapping of a DOTS agent, t
and is reiterated by the DOTS agent upon the following events:</t> and is reiterated by the DOTS agent upon the following events:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>expiry of a validity timer (e.g., DHCP lease, DHCP information
<t>Expiry of a validity timer (e.g., DHCP lease, DHCP information refresh time, or DNS TTL) associated with a discovered DOTS agent</li>
refresh time, DNS TTL) associated with a discovered DOTS agent.</t> <li>expiry of the certificate of a peer DOTS agent currently in
use</li>
<t>Expiry of the certificate of a peer DOTS agent currently in <li>attachment to a new network</li>
use.</t> </ul>
<t>Attachment to a new network.</t>
</list></t>
</section> </section>
<section anchor="dhcp" numbered="true" toc="default">
<section anchor="dhcp" title="DHCP Options for DOTS Agent Discovery"> <name>DHCP Options for DOTS Agent Discovery</name>
<t>As reported in Section 1.7.2 of <xref target="RFC6125"></xref>:<list <t>As reported in <xref target="RFC6125" sectionFormat="of" section="1.7.2
style="empty"> "/>:</t>
<t>"Some certification authorities issue server certificates based <blockquote>
Some certification authorities issue server certificates based
on IP addresses, but preliminary evidence indicates that such on IP addresses, but preliminary evidence indicates that such
certificates are a very small percentage (less than 1%) of issued certificates are a very small percentage (less than 1%) of issued
certificates".</t> certificates.
</list></t> </blockquote>
<t>In order to allow for PKIX-based authentication between a DOTS client <t>In order to allow for PKIX-based authentication between a DOTS client
and server while accommodating the current best practices for issuing and server while accommodating the current best practices for issuing
certificates, this document allows DOTS agents to retrieve the names of certificates, this document allows DOTS agents to retrieve the names of
their peer DOTS agents. These names can be used for two purposes: to their peer DOTS agents. These names can be used for two purposes: (1) to
retrieve the list of IP addresses of a peer DOTS agent or to be retrieve the list of IP addresses of a peer DOTS agent or (2) to be
presented as a reference identifier for authentication purposes.</t> presented as a reference identifier for authentication purposes.</t>
<t>Defining the option to include a list of IP addresses would avoid
<t>Defining the option to include a list of IP addresses would avoid a depending on an underlying name resolution, but that design requires
dependency on an underlying name resolution, but that design requires
also supplying a name for PKIX-based authentication purposes.</t> also supplying a name for PKIX-based authentication purposes.</t>
<t>Given that DOTS gateways can be involved in a DOTS session, a peer <t>Given that DOTS gateways can be involved in a DOTS session, a peer
DOTS agent can be reachable using a link-local address. Such addresses DOTS agent can be reachable using a link-local address. Such addresses
can also be discovered using the options defined in <xref can also be discovered using the options defined in <xref target="opt" for
target="opt"></xref>.</t> mat="default"/>.</t>
<t>The list of the IP addresses returned by DHCP servers is typically <t>The list of the IP addresses returned by DHCP servers is typically
used to feed the DOTS server selection procedure including when DOTS used to feed the DOTS server selection procedure, including when DOTS
agents are provided with primary and backup IP addresses of their peer agents are provided with primary and backup IP addresses of their peer
DOTS agents. An example of DOTS server selection procedure is specified DOTS agents. An example of the DOTS server selection procedure is specifie
in Section 4.3 of <xref target="RFC8782"></xref>.</t> d
in <xref target="RFC8782" sectionFormat="of" section="4.3"/>.</t>
<t>The design assumes that the same peer DOTS agent is used for <t>The design assumes that the same peer DOTS agent is used for
establishing both signal and data channels. For more customized establishing both signal and data channels. For more customized
configurations (e.g., transport-specific configuration, distinct DOTS configurations (e.g., transport-specific configuration and distinct DOTS
servers for the signal and the data channels), an operator can supply servers for the signal and data channels), an operator can supply
only a DOTS reference identifier that will be then passed to the only a DOTS reference identifier that will be then passed to the
procedure described in <xref target="srvr"></xref>.</t> procedure described in <xref target="srvr" format="default"/>.</t>
<t>The design allows terminating the base DOTS channels and DOTS Call <t>The design allows terminating the base DOTS channels and DOTS Call
Home on the same or distinct peer DOTS agents. If distinct peer DOTS Home on the same or distinct peer DOTS agents. If distinct peer DOTS
agents are deployed, the DHCP option can return, for example, a list of agents are deployed, the DHCP option can return, for example, a list of
IP addresses to a requesting DOTS agent. This list includes the IP IP addresses to a requesting DOTS agent. This list includes the IP
address to be used for the base DOTS channels and the IP address for the address to be used for the base DOTS channels and the IP address for the
DOTS Call Home. The DOTS client (or Call Home DOTS server) will then use DOTS Call Home. The DOTS client (or Call Home DOTS server) will then use
the address selection procedure specified in Section 4.3 of <xref the address selection procedure specified in <xref target="RFC8782"
target="RFC8782"></xref> to identify the IP address of the peer DOTS sectionFormat="of" section="4.3"/> to identify the IP address of the peer
server (or Call Home DOTS client). For example: <list style="empty"> DOTS
<t>Let's consider that the DOTS server is reachable at server (or Call Home DOTS client). </t>
2001:db8:122:300::1 while the Call Home DOTS client is reachable at <t>For example, let's consider that the DOTS server is reachable at
2001:db8:122:300::1, while the Call Home DOTS client is reachable at
2001:db8:122:300::2. The DHCP server will then return one DOTS 2001:db8:122:300::2. The DHCP server will then return one DOTS
reference identifier and a list that includes both reference identifier and a list that includes both
2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP 2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting DHCP
client. That list is passed to the DOTS client (or Call Home DOTS client. That list is passed to the DOTS client (or Call Home DOTS
server) which will try to establish connections to the addresses of server), which will try to establish connections to the addresses of
that list and destination port number 4646 (or the Call Home port that list and destination port number 4646 (or the Call Home port
number). As a result, the DOTS client (or Call Home DOTS server) number). As a result, the DOTS client (or Call Home DOTS server)
will select 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS will select 2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS
server (or Call Home DOTS client).</t> server (or Call Home DOTS client).</t>
</list></t> <section anchor="opt" numbered="true" toc="default">
<name>DHCPv6 DOTS Options</name>
<section anchor="opt" title="DHCPv6 DOTS Options"> <section numbered="true" toc="default">
<section title="Format of DOTS Reference Identifier Option"> <name>Format of DOTS Reference Identifier Option</name>
<t>The DHCPv6 DOTS Reference Identifier option is used to configure <t>The DHCPv6 DOTS Reference Identifier option is used to configure
a name of the DOTS server (or the name of the Call Home DOTS the name of the DOTS server (or the name of the Call Home DOTS
client). The format of this option is shown in <xref client). The format of this option is shown in <xref target="ri_option
target="ri_option"></xref>.</t> " format="default"/>.</t>
<figure anchor="ri_option">
<t><figure anchor="ri_option" <name>DHCPv6 DOTS Reference Identifier Option</name>
title="DHCPv6 DOTS Reference Identifier Option"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ 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
2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_V6_DOTS_RI | Option-length |
| OPTION_V6_DOTS_RI | Option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | | dots-agent-name (FQDN) |
| dots-agent-name (FQDN) | | |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>The fields of the option shown in <xref -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
target="ri_option"></xref> are as follows:<?rfc subcompact="yes" ?></t </figure>
> <t>The fields of the option shown in <xref target="ri_option" format="
default"/> are as follows:</t>
<t><list style="symbols"> <dl newline="false" spacing="compact">
<t>Option-code: OPTION_V6_DOTS_RI (TBA1, see <xref <dt>Option-code:</dt>
target="iana6"></xref>)</t> <dd>OPTION_V6_DOTS_RI (141, see <xref target="iana6" format="default"
/>).</dd>
<t>Option-length: Length of the dots-agent-name field in <dt>Option-length:</dt>
octets.</t> <dd>Length of the dots-agent-name field in
octets.</dd>
<t>dots-agent-name: A fully qualified domain name of the peer <dt>dots-agent-name:</dt>
DOTS agent. This field is formatted as specified in Section 10 <dd>A fully qualified domain name of the peer
of <xref target="RFC8415"></xref>.</t> DOTS agent. This field is formatted as specified in <xref target="
</list></t> RFC8415"
sectionFormat="of" section="10"/>.</dd>
<t><?rfc subcompact="no" ?>An example of the dots-agent-name </dl>
encoding is shown in <xref target="fqdn"></xref>. This example <t>An example of the dots-agent-name
conveys the FQDN "dots.example.com.&rdquo;, and the resulting encoding is shown in <xref target="fqdn" format="default"/>. This exam
ple
conveys the FQDN "dots.example.com", and the resulting
Option-length field is 18.</t> Option-length field is 18.</t>
<figure anchor="fqdn">
<t><figure anchor="fqdn" <name>An Example of the dots-agent-name Encoding</name>
title="An example of the dots-agent-name Encoding"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ +------+------+------+------+------+------ +------+------+------+------+------+------+------+------+------+
+------+------+------+ | 0x04 | d | o | t | s | 0x07 | e | x | a |
| 0x04 | d | o | t | s | 0x07 | e | x | a | +------+------+------+------+------+------+------+------+------+
+------+------+------+------+------+------+------+------+------+ | m | p | l | e | 0x03 | c | o | m | 0x00 |
| m | p | l | e | 0x03 | c | o | m | 0x00 | +------+------+------+------+------+------+------+------+------+
+------+------+------+------+------+------+------+------+------+
]]></artwork> ]]></artwork>
</figure></t> ------+------+------+------+------+------+------+------+------+
</figure>
<t></t> <t/>
</section> </section>
<section anchor="add" numbered="true" toc="default">
<section anchor="add" title="Format of DOTS Address Option"> <name>Format of DOTS Address Option</name>
<t>The DHCPv6 DOTS Address option can be used to configure a list of <t>The DHCPv6 DOTS Address option can be used to configure a list of
IPv6 addresses of a DOTS server (or a Call Home DOTS client). The IPv6 addresses of a DOTS server (or a Call Home DOTS client). The
format of this option is shown in <xref format of this option is shown in <xref target="dhcpv6_option" format=
target="dhcpv6_option"></xref>.</t> "default"/>.</t>
<figure anchor="dhcpv6_option">
<t><figure anchor="dhcpv6_option" title="DHCPv6 DOTS Address Option"> <name>DHCPv6 DOTS Address Option</name>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_DOTS_ADDRESS | Option-length | | OPTION_V6_DOTS_ADDRESS | Option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| DOTS ipv6-address | | DOTS ipv6-address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| DOTS ipv6-address | | DOTS ipv6-address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>The fields of the option shown in <xref -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
target="dhcpv6_option"></xref> are as follows:<?rfc subcompact="yes" ? </figure>
></t> <t>The fields of the option shown in <xref target="dhcpv6_option"
format="default"/> are as follows:</t>
<t><list style="symbols"> <dl newline="false" spacing="compact">
<t>Option-code: OPTION_V6_DOTS_ADDRESS (TBA2, see <xref <dt>Option-code:</dt>
target="iana6"></xref>)</t> <dd>OPTION_V6_DOTS_ADDRESS (142, see <xref target="iana6" format="def
ault"/>).</dd>
<t>Option-length: Length of the 'DOTS ipv6-address(es)' field in <dt>Option-length:</dt>
octets. MUST be a multiple of 16.</t> <dd>Length of the DOTS ipv6-address fields in
octets. This <bcp14>MUST</bcp14> be a multiple of 16.</dd>
<t>DOTS ipv6-address(es): Includes one or more IPv6 addresses <dt>DOTS ipv6-address:</dt>
<xref target="RFC4291"></xref> of the peer DOTS agent to be used <dd>Includes one or more IPv6 addresses
<xref target="RFC4291" format="default"/> of the peer DOTS agent t
o be used
by a DOTS agent for establishing a DOTS session. The addresses by a DOTS agent for establishing a DOTS session. The addresses
are listed in the order of preference for use by the DOTS are listed in the order of preference for use by the DOTS
agent.<vspace blankLines="1" />Note, IPv4-mapped IPv6 addresses agent.</dd>
(Section 2.5.5.2 of <xref target="RFC4291"></xref>) may be </dl>
<t>Note that IPv4-mapped IPv6 addresses
(<xref target="RFC4291" sectionFormat="of" section="2.5.5.2"/>) ma
y be
included in this option when there is no DHCPv4 server able to included in this option when there is no DHCPv4 server able to
advertise the DHCPv4 DOTS options (<xref advertise the DHCPv4 DOTS options (<xref target="dhcpv4" format="d
target="dhcpv4"></xref>) and when only IPv4 connectivity is efault"/>)
possible to the peer DOTS agent.</t> and when only IPv4 connectivity is possible to the peer DOTS agent.
</list></t> </t>
<t/>
<t><?rfc subcompact="no" ?></t>
</section> </section>
<section numbered="true" toc="default">
<section title="DHCPv6 Client Behavior"> <name>DHCPv6 Client Behavior</name>
<t>DHCP clients MAY request options OPTION_V6_DOTS_RI and <t>DHCP clients <bcp14>MAY</bcp14> request options OPTION_V6_DOTS_RI a
OPTION_V6_DOTS_ADDRESS, as defined in <xref nd
target="RFC8415"></xref>, Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, OPTION_V6_DOTS_ADDRESS, as defined in Sections <xref target="RFC8415"
18.2.6, and 21.7. As a convenience to the reader, it is mentioned section="18.2.1"
sectionFormat="bare"/>, <xref target="RFC8415" section="18.2.2" section
Format="bare"/>,
<xref target="RFC8415" section="18.2.4" sectionFormat="bare"/>, <xref t
arget="RFC8415"
section="18.2.5" sectionFormat="bare"/>, <xref target="RFC8415" section
="18.2.6"
sectionFormat="bare"/>, and <xref target="RFC8415" section="21.7" secti
onFormat="bare"/>
of <xref target="RFC8415"/>. As a convenience to the reader, it is ment
ioned
here that the DHCP client includes the requested option codes in the here that the DHCP client includes the requested option codes in the
Option Request Option.</t> Option Request option.</t>
<t>If the DHCP client receives more than one instance of option
<t>If the DHCP client receives more than one instance of OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS), it <bcp14>MUST</bcp14>
OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use use
only the first instance of that option.</t> only the first instance of that option.</t>
<t>The DHCP client <bcp14>MUST</bcp14> silently discard multicast and
<t>The DHCP client MUST silently discard multicast and host loopback host loopback
addresses <xref target="RFC6890"></xref> conveyed in addresses <xref target="RFC6890" format="default"/> conveyed in
OPTION_V6_DOTS_ADDRESS.</t> OPTION_V6_DOTS_ADDRESS.</t>
<t>If the DHCP client receives and validates both OPTION_V6_DOTS_RI <t>If the DHCP client receives and validates both OPTION_V6_DOTS_RI
and OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used and OPTION_V6_DOTS_ADDRESS, the content of OPTION_V6_DOTS_RI is used
as the reference identifier for authentication purposes (e.g., PKIX as the reference identifier for authentication purposes (e.g., PKIX
<xref target="RFC6125"></xref>), while the valid addresses included <xref target="RFC6125" format="default"/>), while the valid addresses included
in OPTION_V6_DOTS_ADDRESS are used to reach the peer DOTS agent. In in OPTION_V6_DOTS_ADDRESS are used to reach the peer DOTS agent. In
other words, the name conveyed in OPTION_V6_DOTS_RI MUST NOT be other words, the name conveyed in OPTION_V6_DOTS_RI <bcp14>MUST NOT</b
passed to an underlying resolution library in the presence of valid cp14> be
passed to an underlying resolution library in the presence of a valid
OPTION_V6_DOTS_ADDRESS in a response.</t> OPTION_V6_DOTS_ADDRESS in a response.</t>
<t>If the DHCP client receives OPTION_V6_DOTS_RI only, but <t>If the DHCP client receives OPTION_V6_DOTS_RI only, but
OPTION_V6_DOTS_RI contains more than one name, the DHCP client MUST OPTION_V6_DOTS_RI contains more than one name, the DHCP client <bcp14>
use only the first name. Once the name is validated (Section 10 of MUST</bcp14>
<xref target="RFC8415"></xref>), the name is passed to a name use only the first name. Once the name is validated (<xref target="RFC
8415"
sectionFormat="of" section="10"/>), the name is passed to a name
resolution library. Moreover, that name is also used as a reference resolution library. Moreover, that name is also used as a reference
identifier for authentication purposes.</t> identifier for authentication purposes.</t>
<t>If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the <t>If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, the
address(es) included in OPTION_V6_DOTS_ADDRESS are used to reach the address(es) included in OPTION_V6_DOTS_ADDRESS are used to reach the
peer DOTS agent. In addition, these addresses can be used as peer DOTS agent. In addition, these addresses can be used as
identifiers for authentication.</t> identifiers for authentication.</t>
</section> </section>
</section> </section>
<section anchor="dhcpv4" numbered="true" toc="default">
<section anchor="dhcpv4" title="DHCPv4 DOTS Options"> <name>DHCPv4 DOTS Options</name>
<section title="Format of DOTS Reference Identifier Option"> <section numbered="true" toc="default">
<t>The DHCPv4 <xref target="RFC2132"></xref> DOTS Reference <name>Format of DOTS Reference Identifier Option</name>
<t>The DHCPv4 <xref target="RFC2132" format="default"/> DOTS Reference
Identifier option is used to configure a name of the peer DOTS Identifier option is used to configure a name of the peer DOTS
agent. The format of this option is illustrated in <xref agent. The format of this option is illustrated in <xref target="dhcpr
target="dhcpri_dots"></xref>.</t> i_dots" format="default"/>.</t>
<figure anchor="dhcpri_dots">
<t><figure anchor="dhcpri_dots" <name>DHCPv4 DOTS Reference Identifier Option</name>
title="DHCPv4 DOTS Reference Identifier Option"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ Code Length Peer DOTS agent name
Code Length Peer DOTS agent name +-----+-----+-----+-----+-----+-----+-----+--
+-----+-----+-----+-----+-----+-----+-----+-- | 147 | n | s1 | s2 | s3 | s4 | s5 | ...
|TBA3 | n | s1 | s2 | s3 | s4 | s5 | ... +-----+-----+-----+-----+-----+-----+-----+--
+-----+-----+-----+-----+-----+-----+-----+--
The values s1, s2, s3, etc. represent the domain name labels in the
domain name encoding.
]]></artwork> ]]></artwork>
</figure></t> -----+-----+-----+-----+-----+-----+-----+--
</figure>
<t>The fields of the option shown in <xref <t>The values s1, s2, s3, etc. represent the domain name labels in the
target="dhcpri_dots"></xref> are as follows:<?rfc subcompact="yes" ?>< domain name encoding.</t>
list <t>The fields of the option shown in <xref target="dhcpri_dots"
style="symbols"> format="default"/> are as follows:</t>
<t>Code: OPTION_V4_DOTS_RI (TBA3, see <xref <dl newline="false" spacing="compact">
target="iana4"></xref>).</t> <dt>Code:</dt>
<dd>OPTION_V4_DOTS_RI (147, see <xref target="iana4" format="default"
<t>Length: Includes the length of the "Peer DOTS agent name" />).</dd>
field in octets.</t> <dt>Length:</dt>
<dd>Includes the length of the "Peer DOTS agent name"
<t>Peer DOTS agent name: The domain name of the peer DOTS agent. field in octets.</dd>
This field is formatted as specified in Section 10 of <xref <dt>Peer DOTS agent name:</dt>
target="RFC8415"></xref>.</t> <dd>The domain name of the peer DOTS agent. This field is formatted a
</list></t> s
specified in <xref target="RFC8415" sectionFormat="of" section="10"/>
<t><?rfc subcompact="no" ?></t> .</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Format of DOTS Address Option"> <name>Format of DOTS Address Option</name>
<t>The DHCPv4 DOTS Address option can be used to configure a list of <t>The DHCPv4 DOTS Address option can be used to configure a list of
IPv4 addresses of a peer DOTS agent. The format of this option is IPv4 addresses of a peer DOTS agent. The format of this option is
illustrated in <xref target="dhcp_dots"></xref>.</t> illustrated in <xref target="dhcp_dots" format="default"/>.</t>
<figure anchor="dhcp_dots">
<t><figure anchor="dhcp_dots" title="DHCPv4 DOTS Address Option"> <name>DHCPv4 DOTS Address Option</name>
<artwork><![CDATA[ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 <artwork name="" type="" align="left" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
| Code=TBA4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=148 | Length |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ DOTS IPv4 Address | | |
| | | DOTS IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- | |
| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
+ DOTS IPv4 Address | | | | |
| | optional | DOTS IPv4 Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | optional
. ... . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- . ... . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
]]></artwork> ]]></artwork>
</figure></t> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
</figure>
<t>The fields of the option shown in <xref <t>The fields of the option shown in <xref target="dhcp_dots" format="
target="dhcp_dots"></xref> are as follows:<?rfc subcompact="yes" ?><li default"/> are as follows:</t>
st <dl newline="false" spacing="compact">
style="symbols"> <dt>Code:</dt>
<t>Code: OPTION_V4_DOTS_ADDRESS (TBA4, see <xref <dd>OPTION_V4_DOTS_ADDRESS (148, see <xref target="iana4" format="def
target="iana4"></xref>).</t> ault"/>).</dd>
<dt>Length:</dt>
<t>Length: is set to 4*N, where N is the number of IPv4 <dd>Set to 4*N, where N is the number of IPv4
addresses included in the option.</t> addresses included in the option.</dd>
<dt>DOTS IPv4 Address(es):</dt>
<t>DOTS IPv4 Address(es): Contains one or more IPv4 addresses of <dd>Contains one or more IPv4 addresses of
the peer DOTS agent to be used by a DOTS agent. The addresses the peer DOTS agent to be used by a DOTS agent. The addresses
are listed in the order of preference for use by the DOTS are listed in the order of preference for use by the DOTS
agent.</t> agent.</dd>
</list></t> </dl>
<t>OPTION_V4_DOTS_ADDRESS is a
<t><?rfc subcompact="no" ?>OPTION_V4_DOTS_ADDRESS is a
concatenation-requiring option. As such, the mechanism specified in concatenation-requiring option. As such, the mechanism specified in
<xref target="RFC3396"></xref> MUST be used if <xref target="RFC3396" format="default"/> <bcp14>MUST</bcp14> be used if
OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255 OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255
octets.</t> octets.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="DHCPv4 Client Behavior"> <name>DHCPv4 Client Behavior</name>
<t>To discover a peer DOTS agent, the DHCPv4 client MUST include <t>To discover a peer DOTS agent, the DHCPv4 client <bcp14>MUST</bcp14
> include
both OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter both OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter
Request List Option <xref target="RFC2132"></xref>.</t> Request List option <xref target="RFC2132" format="default"/>.</t>
<t>If the DHCP client receives more than one instance of <t>If the DHCP client receives more than one instance of
OPTION_V4_DOTS_RI option, it MUST use only the first instance of OPTION_V4_DOTS_RI option, it <bcp14>MUST</bcp14> use only the first in stance of
that option.</t> that option.</t>
<t>The DHCP client <bcp14>MUST</bcp14> silently discard multicast and
<t>The DHCP client MUST silently discard multicast and host loopback host loopback
addresses <xref target="RFC6890"></xref> conveyed in addresses <xref target="RFC6890" format="default"/> conveyed in
OPTION_V4_DOTS_ADDRESS.</t> OPTION_V4_DOTS_ADDRESS.</t>
<t>If the DHCP client receives and validates both OPTION_V4_DOTS_RI <t>If the DHCP client receives and validates both OPTION_V4_DOTS_RI
and OPTION_V4_DOTS_ADDRESS, the content of OPTION_V4_DOTS_RI is used and OPTION_V4_DOTS_ADDRESS, the content of OPTION_V4_DOTS_RI is used
as the reference identifier for authentication purposes (e.g., PKIX as the reference identifier for authentication purposes (e.g., PKIX
<xref target="RFC6125"></xref>), while the valid addresses included <xref target="RFC6125" format="default"/>), while the valid addresses included
in OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS agent. In in OPTION_V4_DOTS_ADDRESS are used to reach the peer DOTS agent. In
other words, the name conveyed in OPTION_V4_DOTS_RI MUST NOT be other words, the name conveyed in OPTION_V4_DOTS_RI <bcp14>MUST NOT</b
passed to underlying resolution library in the presence of valid cp14> be
passed to an underlying resolution library in the presence of valid
OPTION_V4_DOTS_ADDRESS in a response.</t> OPTION_V4_DOTS_ADDRESS in a response.</t>
<t>If the DHCP client receives OPTION_V4_DOTS_RI only, but <t>If the DHCP client receives OPTION_V4_DOTS_RI only, but
OPTION_V4_DOTS_RI option contains more than one name, as OPTION_V4_DOTS_RI option contains more than one name, as
distinguished by the presence of multiple root labels, the DHCP distinguished by the presence of multiple root labels, the DHCP
client MUST use only the first name. Once the name is validated client <bcp14>MUST</bcp14> use only the first name. Once the name is v
(Section 10 of <xref target="RFC8415"></xref>), the name is passed alidated
(<xref target="RFC8415" sectionFormat="of" section="10"/>), the name i
s passed
to a name resolution library. Moreover, that name is also used as a to a name resolution library. Moreover, that name is also used as a
reference identifier for authentication purposes.</t> reference identifier for authentication purposes.</t>
<t>If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the <t>If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, the
address(es) included in OPTION_V4_DOTS_ADDRESS are used to reach the address(es) included in OPTION_V4_DOTS_ADDRESS are used to reach the
peer DOTS server. In addition, these addresses can be used as peer DOTS server. In addition, these addresses can be used as
identifiers for authentication.</t> identifiers for authentication.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="srvr" numbered="true" toc="default">
<section anchor="srvr" title="Discovery using Service Resolution"> <name>Discovery Using Service Resolution</name>
<t>This mechanism is performed in two steps:<list style="numbers"> <t>This mechanism is performed in two steps:</t>
<t>A DNS domain name is retrieved for each combination of interface <ol spacing="normal" type="1">
<li>A DNS domain name is retrieved for each combination of interface
and address family. A DOTS agent has to determine the domain in and address family. A DOTS agent has to determine the domain in
which it is located relying on dynamic means such as DHCP (<xref which it is located relying on dynamic means, such as DHCP (<xref
target="dhcp"></xref>). Implementations may allow the user to target="dhcp" format="default"/>). Implementations may allow the user t
specify a default name that is used, if no specific name has been o
configured.</t> specify a default name that is used if no specific name has been
configured.</li>
<t>Retrieved DNS domain names are then used for S-NAPTR lookups <li>Retrieved DNS domain names are then used for S-NAPTR lookups
<xref target="RFC3958"></xref>. Further DNS lookups may be necessary <xref target="RFC3958" format="default"/>. Further DNS lookups may be
to determine the peer DOTS agent IP address(es).</t> necessary
</list></t> to determine the peer DOTS agent IP address(es).</li>
</ol>
<t>Once the DOTS agent has retrieved its DNS domain or discovered the <t>Once the DOTS agent has retrieved its DNS domain or discovered the
peer DOTS agent name that needs to be resolved, an S-NAPTR lookup with peer DOTS agent name that needs to be resolved, an S-NAPTR lookup with
the appropriate application service and the desired protocol tag is made the appropriate application service and the desired protocol tag is made
to obtain information necessary to connect to the authoritative peer to obtain information necessary to connect to the authoritative peer
DOTS agent within the given domain.</t> DOTS agent within the given domain.</t>
<!--IANA flag-->
<t>This specification defines 'DOTS' and 'DOTS-CALL-HOME' as application <t>This specification defines "DOTS" and "DOTS-CALL-HOME" as application
service tags (Sections <xref format="counter" target="serviceT"></xref> service tags (Sections <xref format="counter" target="serviceT"/>
and <xref format="counter" target="serviceT2"></xref>). It also defines and <xref format="counter" target="serviceT2"/>). It also defines
"signal.udp" (<xref target="suappt"></xref>), "signal.tcp" (<xref "signal.udp" (<xref target="suappt" format="default"/>), "signal.tcp" (<xr
target="stappt"></xref>), and "data.tcp" (<xref target="dappt"></xref>) ef target="stappt" format="default"/>), and "data.tcp" (<xref target="dappt" for
as application protocol tags. An example is provided in <xref mat="default"/>)
target="ssrv"></xref>.</t> as application protocol tags. An example is provided in <xref target="ssrv
" format="default"/>.</t>
<t>In the example below, for domain 'example.net', the resolution <t>In the example below, for domain "example.net", the resolution
algorithm will result in IP address(es), port, tag, and protocol tuples algorithm will result in IP address, port, tag, and protocol tuples
listed in Table 1.</t> listed in <xref target="results" format="default"/>.</t>
<figure anchor="ssrv">
<t><figure anchor="ssrv" <name>Example of Discovery of DOTS Servers Using Service Resolution</name>
title="Example of Discovery of DOTS Servers using Service Resolution"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[ example.net. example.net.
IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net.
IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net.
IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net. IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net.
signal.example.net. signal.example.net.
IN NAPTR 100 10 "s" DOTS:signal.udp "" _dots-signal._udp.example.net. IN NAPTR 100 10 "s" DOTS:signal.udp "" _dots-signal._udp.example.net.
IN NAPTR 200 10 "s" DOTS:signal.tcp "" _dots-signal._tcp.example.net. IN NAPTR 200 10 "s" DOTS:signal.tcp "" _dots-signal._tcp.example.net.
data.example.net. data.example.net.
IN NAPTR 100 10 "s" DOTS:data.tcp "" _dots-data._tcp.example.net. IN NAPTR 100 10 "s" DOTS:data.tcp "" _dots-data._tcp.example.net.
IN NAPTR 200 10 "a" DOTS:data.tcp "" b.example.net. IN NAPTR 200 10 "a" DOTS:data.tcp "" b.example.net.
_dots-signal._udp.example.net. _dots-signal._udp.example.net.
IN SRV 0 0 5000 a.example.net. IN SRV 0 0 5000 a.example.net.
_dots-signal._tcp.example.net. _dots-signal._tcp.example.net.
IN SRV 0 0 5001 a.example.net. IN SRV 0 0 5001 a.example.net.
_dots-data._tcp.example.net. _dots-data._tcp.example.net.
IN SRV 0 0 5002 a.example.net. IN SRV 0 0 5002 a.example.net.
a.example.net. a.example.net.
IN AAAA 2001:db8::1 IN AAAA 2001:db8::1
b.example.net. b.example.net.
IN AAAA 2001:db8::2 IN AAAA 2001:db8::2
]]></artwork> ]]></artwork>
</figure><figure> </figure>
<artwork><![CDATA[ +-------+----------+-------------+------+--- <table anchor="results" align="center">
-----+ <name>Resolution Results</name>
| Order | Protocol | IP address | Port | Tag | <thead>
+-------+----------+-------------+------+--------+ <tr>
| 1 | UDP | 2001:db8::1 | 5000 | Signal | <th>Order</th>
| 2 | TCP | 2001:db8::1 | 5001 | Signal | <th>Protocol</th>
| 3 | TCP | 2001:db8::1 | 5002 | Data | <th>IP address</th>
| 4 | TCP | 2001:db8::2 | 443 | Data | <th>Port</th>
+-------+----------+-------------+------+--------+ <th>Tag</th>
Table 1: Resolution Results]]></artwork> </tr>
</figure></t> </thead>
<tbody>
<t>An example is provided in <xref target="callhome"></xref> for the <tr>
<td>1</td>
<td>UDP</td>
<td>2001:db8::1</td>
<td>5000</td>
<td>Signal</td>
</tr>
<tr>
<td>2</td>
<td>TCP</td>
<td>2001:db8::1</td>
<td>5001</td>
<td>Signal</td>
</tr>
<tr>
<td>3</td>
<td>TCP</td>
<td>2001:db8::1</td>
<td>5002</td>
<td>Data</td>
</tr>
<tr>
<td>4</td>
<td>TCP</td>
<td>2001:db8::2</td>
<td>443</td>
<td>Data</td>
</tr>
</tbody>
</table>
<t>An example is provided in <xref target="callhome" format="default"/> fo
r the
Call Home case. In this example, the resolution algorithm will result in Call Home case. In this example, the resolution algorithm will result in
IP address(es), port, and protocol listed in Table 2 for domain IP address, port, and protocol tuples listed in <xref target="call-home" f
'example.net'.</t> ormat="default"/> for domain
"example.net".</t>
<t><figure anchor="callhome" <figure anchor="callhome">
title="Example of Discovery of DOTS Call Home Client using Service Res <name>Example of Discovery of DOTS Call Home Client Using Service Resolu
olution"> tion</name>
<artwork><![CDATA[ example.net. <artwork name="" type="" align="left" alt=""><![CDATA[
IN NAPTR 100 10 "" DOTS-CALL-HOME:signal.udp "" signal.example.net. example.net.
IN NAPTR 200 10 "" DOTS-CALL-HOME:signal.tcp "" signal.example.net. IN NAPTR 100 10 "" DOTS-CALL-HOME:signal.udp "" signal.example.net.
IN NAPTR 200 10 "" DOTS-CALL-HOME:signal.tcp "" signal.example.net.
signal.example.net. signal.example.net.
IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp "" IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp ""
_dots-call-home._udp.example.net. _dots-call-home._udp.example.net.
IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp "" IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp ""
_dots-call-home._tcp.example.net. _dots-call-home._tcp.example.net.
_dots-call-home._udp.example.net. _dots-call-home._udp.example.net.
IN SRV 0 0 6000 b.example.net. IN SRV 0 0 6000 b.example.net.
_dots-call-home._tcp.example.net.
IN SRV 0 0 6001 b.example.net.
b.example.net. _dots-call-home._tcp.example.net.
IN AAAA 2001:db8::2 IN SRV 0 0 6001 b.example.net.
b.example.net.
IN AAAA 2001:db8::2
]]></artwork> ]]></artwork>
</figure><figure> </figure>
<artwork><![CDATA[ +-------+----------+-------------+------+ <table anchor="call-home" align="center">
| Order | Protocol | IP address | Port | <name>Resolution Results (Call Home)</name>
+-------+----------+-------------+------+ <thead>
| 1 | UDP | 2001:db8::2 | 6000 | <tr>
| 2 | TCP | 2001:db8::2 | 6001 | <th>Order</th>
+-------+----------+-------------+------+ <th>Protocol</th>
Table 2: Resolution Results (Call Home)]]></artwork> <th>IP address</th>
</figure></t> <th>Port</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>UDP</td>
<td>2001:db8::2</td>
<td>6000</td>
</tr>
<tr>
<td>2</td>
<td>TCP</td>
<td>2001:db8::2</td>
<td>6001</td>
</tr>
</tbody>
</table>
<t>Note that customized port numbers are used for the DOTS signal <t>Note that customized port numbers are used for the DOTS signal
channel, DOTS data channel, and DOTS signal channel call home in the channel, DOTS data channel, and DOTS signal channel Call Home in the
examples shown in Figures <xref format="counter" target="ssrv"></xref> examples shown in Figures <xref format="counter" target="ssrv"/>
and <xref format="counter" target="callhome"></xref> for illustration and <xref format="counter" target="callhome"/> for illustration
purposes. If default port numbers are used in a deployment, the purposes. If default port numbers are used in a deployment, the
discovery procedure will return 4646 (DOTS signal channel) and 443 (DOTS discovery procedure will return 4646 (DOTS signal channel) and 443 (DOTS
data channel) as DOTS service port numbers.</t> data channel) as DOTS service port numbers.</t>
<t>If no DOTS-specific S-NAPTR records can be retrieved, the discovery <t>If no DOTS-specific S-NAPTR records can be retrieved, the discovery
procedure fails for this domain name (and the corresponding interface procedure fails for this domain name (and the corresponding interface
and IP protocol version). If more domain names are known, the discovery and IP protocol version). If more domain names are known, the discovery
procedure MAY perform the corresponding S-NAPTR lookups immediately. procedure <bcp14>MAY</bcp14> perform the corresponding S-NAPTR lookups imm
However, before retrying a lookup that has failed, a DOTS client MUST ediately.
However, before retrying a lookup that has failed, a DOTS client <bcp14>MU
ST</bcp14>
wait a time period that is appropriate for the encountered error (e.g., wait a time period that is appropriate for the encountered error (e.g.,
NXDOMAIN, timeout, etc.).</t> NXDOMAIN, timeout, etc.).</t>
</section> </section>
<section anchor="DNSSD" numbered="true" toc="default">
<section anchor="DNSSD" title="DNS Service Discovery"> <name>DNS Service Discovery</name>
<t>DNS-based Service Discovery (DNS-SD) <xref target="RFC6763"></xref> <t>DNS-based Service Discovery (DNS-SD) <xref target="RFC6763" format="def
ault"/>
provides generic solutions for discovering services. DNS-SD defines a provides generic solutions for discovering services. DNS-SD defines a
set of naming rules for certain DNS record types that they use for set of naming rules for certain DNS record types that they use for
advertising and discovering services.</t> advertising and discovering services.</t>
<t><xref target="RFC6763" sectionFormat="of" section="4.1"/> specifies tha
<t>Section 4.1 of <xref target="RFC6763"></xref> specifies that a t a
service instance name in DNS-SD has the following structure:</t> service instance name in DNS-SD has the following structure:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t><figure align="center"> <Instance> . <Service> . <Domain>
<artwork><![CDATA[<Instance> . <Service> . <Domain>]]></artwork> ]]></artwork>
</figure></t> <t>The &lt;Domain&gt; portion specifies the DNS subdomain where the
service instance is registered. It is a conventional domain name, such as
<t>The &lt;Domain&gt; portion specifies the DNS sub-domain where the "example.com".</t>
service instance is registered. It is a conventional domain name such as <t>The &lt;Service&gt; portion of the DOTS service instance name <bcp14>MU
"example.com.".</t> ST</bcp14> be
"_dots-signal._udp", "_dots-signal._tcp", "_dots-data._tcp",
<t>The &lt;Service&gt; portion of the DOTS service instance name MUST be "_dots-call-home._udp", or "_dots-call-home._tcp".</t>
"_dots-signal._udp" or "_dots-signal._tcp" or "_dots-data._tcp" or
"_dots-call-home._udp" or "_dots-call-home._tcp".</t>
<t>This document does not define any keys; the TXT record of a DNS-SD <t>This document does not define any keys; the TXT record of a DNS-SD
service is thus empty (Section 6 of <xref target="RFC6763"></xref>).</t> service is thus empty (<xref target="RFC6763" sectionFormat="of" section="
6"/>).</t>
<t><xref target="sdex"></xref> depicts an excerpt of the DNS zone <t><xref target="sdex" format="default"/> depicts an excerpt of the DNS zo
ne
configuration file listing record examples to discover two DOTS signal configuration file listing record examples to discover two DOTS signal
channel servers. In this example, only UDP is supported as transport for channel servers. In this example, only UDP is supported as transport for
the establishment of the DOTS signal channel.</t> the establishment of the DOTS signal channel.</t>
<figure anchor="sdex">
<t><figure anchor="sdex" <name>An Example of DNS-SD Records for the UDP DOTS Signal Channel Invol
title="An Example of DNS-SD Records for the UDP DOTS Signal Channel in ving Two Servers with the Same Priority</name>
volving Two Servers with the Same Priority."> <artwork name="" type="" align="left" alt=""><![CDATA[_dots-signal._udp.
<artwork><![CDATA[_dots-signal._udp.example.net. PTR a._dots-signal._ example.net. PTR a._dots-signal._udp.example.net.
udp.example.net.
_dots-signal._udp.example.net. PTR b._dots-signal._udp.example.net. _dots-signal._udp.example.net. PTR b._dots-signal._udp.example.net.
a._dots-signal._udp.example.net. SRV 0 0 4646 a.example.net. a._dots-signal._udp.example.net. SRV 0 0 4646 a.example.net.
b._dots-signal._udp.example.net. SRV 0 0 4646 b.example.net. b._dots-signal._udp.example.net. SRV 0 0 4646 b.example.net.
a._dots-signal._udp.example.net. TXT "" a._dots-signal._udp.example.net. TXT ""
b._dots-signal._udp.example.net. TXT "" b._dots-signal._udp.example.net. TXT ""
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>DOTS-related security considerations are discussed in Section 4 of <t>DOTS-related security considerations are discussed in <xref target="RFC
<xref target="RFC8811"></xref>. As a reminder, DOTS agents must 8811"
sectionFormat="of" section="5"/>. As a reminder, DOTS agents must
authenticate each other using (D)TLS before a DOTS session is considered authenticate each other using (D)TLS before a DOTS session is considered
valid according to the <xref target="RFC8782"></xref>.</t> valid according to the <xref target="RFC8782" format="default"/>.</t>
<t>An attacker may block some protocol messages (e.g., DHCP) to force <t>An attacker may block some protocol messages (e.g., DHCP) to force
the client to use a discovery mechanism with a lower priority. The the client to use a discovery mechanism with a lower priority. The
security implications of such attack are those inherent to the fallback security implications of such attack are those inherent to the fallback
discovery mechanism discussed in the following subsections.</t> discovery mechanism discussed in the following subsections.</t>
<t>The results of the discovery procedure are a function of the <t>The results of the discovery procedure are a function of the
interface/address family. Contacting a discovered DOTS server via an interface/address family. Contacting a discovered DOTS server via an
interface to which it is not bound may exacerbate the delay required to interface to which it is not bound may exacerbate the delay required to
establish a DOTS channel. Moreover, such behavior may reveal that a DOTS establish a DOTS channel. Moreover, such behavior may reveal that a DOTS
service is enabled by a DOTS client domain and exposes the identity of service is enabled by a DOTS client domain and exposes the identity of
the DOTS service provider (that can be inferred from the name and the the DOTS service provider (which can be inferred from the name and the
destination IP address) to external networks.</t> destination IP address) to external networks.</t>
<t>Security considerations related to how security credentials to <t>Security considerations related to how security credentials to
authenticate DOTS server(s) are provisioned to a DOTS client are those authenticate DOTS server(s) are provisioned to a DOTS client are those
inherent to the mechanism used for that purpose (see for example, <xref inherent to the mechanism used for that purpose (for example, see <xref ta
target="RFC8572"></xref>).</t> rget="RFC8572" format="default"/>).</t>
<section numbered="true" toc="default">
<section title="DHCP"> <name>DHCP</name>
<t>The security considerations in <xref target="RFC2131"></xref> and <t>The security considerations in <xref target="RFC2131" format="default
<xref target="RFC8415"></xref> are to be considered. In particular, "/> and
<xref target="RFC8415" format="default"/> are to be considered. In parti
cular,
issues related to rogue DHCP servers and means to mitigate many of issues related to rogue DHCP servers and means to mitigate many of
these attacks are discussed in Section 22 of <xref these attacks are discussed in <xref target="RFC8415" sectionFormat="of"
target="RFC8415"></xref>.</t> section="22"/>.</t>
<t>An attacker can get a domain name, get a domain-validated public
<t>An attacker can get a domain name, domain-validated public certificate from a certification authority (CA), and host a DOTS agent.
certificate from a CA, and host a DOTS agent. An active attacker can An active attacker can
then spoof DHCP responses to include the attacker's DOTS agent. Such then spoof DHCP responses to include the attacker's DOTS agent. Such
an attacker can also launch other attacks as discussed in Section 22 an attacker can also launch other attacks, as discussed in <xref target=
of <xref target="RFC8415"></xref>. In addition to the mitigations "RFC8415"
listed in Section 22 of <xref target="RFC8415"></xref>, a DOTS agent sectionFormat="of" section="22"/>. In addition to the mitigations
may be pre-configured with a list of trusted DOTS domain names. If listed in <xref target="RFC8415" sectionFormat="of" section="22"/>, a DO
such a list is pre-configured, a DOTS agent will accept a TS agent
may be preconfigured with a list of trusted DOTS domain names. If
such a list is preconfigured, a DOTS agent will accept a
DHCP-discovered name if it matches a name in that list. Also, the DOTS DHCP-discovered name if it matches a name in that list. Also, the DOTS
agent has to check that the 'DNS-ID' identifier type within agent has to check that the "DNS-ID" identifier type within
subjectAltName in the server certificate matches a pre-configured subjectAltName in the server certificate matches a preconfigured
name. If the DOTS agent is instructed to trust subdomains of the names name. If the DOTS agent is instructed to trust subdomains of the names
in that list as well (e.g., "*.example.com"), a DOTS agent will accept in that list as well (e.g., "*.example.com"), a DOTS agent will accept
a DHCP-discovered name that matches a name in the pre-configured list a DHCP-discovered name that matches a name in the preconfigured list
(e.g., "dots-1.example.com" or "dots-2.example.com").</t> (e.g., "dots-1.example.com" or "dots-2.example.com").</t>
<t>Relying on an underlying resolution library to resolve a supplied <t>Relying on an underlying resolution library to resolve a supplied
reference identifier has similar security issues as those discussed in reference identifier has similar security issues as those discussed in
<xref target="res"></xref> (e.g., an active attacker may modify DNS <xref target="res" format="default"/> (e.g., an active attacker may modi fy DNS
messages used to resolve the supplied reference identifier and point messages used to resolve the supplied reference identifier and point
the client to an attacker server).</t> the client to an attacker server).</t>
<t>Supplying both an IP address and the reference identifier makes it <t>Supplying both an IP address and the reference identifier makes it
easier to use a mis-issued certificate.</t> easier to use a mis-issued certificate.</t>
</section> </section>
<section anchor="res" numbered="true" toc="default">
<section anchor="res" title="Service Resolution"> <name>Service Resolution</name>
<t>The primary attack against the methods described in <xref <t>The primary attack against the methods described in <xref target="srv
target="srvr"></xref> is one that would lead to impersonation of a r" format="default"/> is one that would lead to impersonation of a
peer DOTS agent. An attacker could attempt to compromise the S-NAPTR peer DOTS agent. An attacker could attempt to compromise the S-NAPTR
resolution.</t> resolution.</t>
<t>The DOTS client (or a Call Home DOTS server) constructs one <t>The DOTS client (or a Call Home DOTS server) constructs one
reference identifier for the DOTS server (or a Call Home DOTS client) reference identifier for the DOTS server (or a Call Home DOTS client)
based on the domain name which is used for S-NAPTR lookup: DNS-ID. If based on the domain name that is used for S-NAPTR lookup: DNS-ID. If
the reference identifier is found (as described in Section 6 of <xref the reference identifier is found (as described in <xref target="RFC6125
target="RFC6125"></xref>) in the PKIX certificate's subjectAltName "
sectionFormat="of" section="6"/>) in the PKIX certificate's subjectAltNam
e
extension, the DOTS client should accept the certificate for the extension, the DOTS client should accept the certificate for the
server.</t> server.</t>
<t>DNS Security Extensions (DNSSEC) <xref target="RFC4033" format="defau
<t>DNS Security Extensions (DNSSEC) <xref target="RFC4033"></xref> lt"/>
uses cryptographic keys and digital signatures to provide uses cryptographic keys and digital signatures to provide
authentication of DNS data. The information that is retrieved from the authentication of DNS data. The information that is retrieved from the
S-NAPTR lookup and that is validated using DNSSEC is thereby proved to S-NAPTR lookup and that is validated using DNSSEC is thereby proved to
be the authoritative data.</t> be the authoritative data.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="DNS Service Discovery"> <name>DNS Service Discovery</name>
<t>Since DNS-SD is a specification for how to name and use records in <t>Since DNS-SD is a specification for how to name and use records in
the existing DNS system, it has no specific additional security the existing DNS system, it has no specific additional security
requirements over and above those that already apply to DNS queries requirements over and above those that already apply to DNS queries
and DNS updates. For DNS queries, DNSSEC SHOULD be used where the and DNS updates. For DNS queries, DNSSEC <bcp14>SHOULD</bcp14> be used w here the
authenticity of information is important. For DNS updates, secure authenticity of information is important. For DNS updates, secure
updates <xref target="RFC2136"></xref><xref target="RFC3007"></xref> updates <xref target="RFC2136" format="default"/> <xref target="RFC3007"
SHOULD generally be used to control which clients have permission to format="default"/>
<bcp14>SHOULD</bcp14> generally be used to control which clients have pe
rmission to
update DNS records.</t> update DNS records.</t>
<t>Note that means such as DNS over TLS (DoT) <xref target="RFC7858" for
<t>Note that means such as DNS over TLS (DoT) <xref mat="default"/> or DNS over HTTPS (DoH) <xref target="RFC8484" format="default"/
target="RFC7858"></xref> or DNS over HTTPS (DoH) <xref > can be used to prevent eavesdroppers from
target="RFC8484"></xref> can be used to prevent eavesdroppers from
accessing DNS messages.</t> accessing DNS messages.</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t></t> <t/>
<section numbered="true" toc="default">
<section title="The Service Name and Transport Protocol Port Number Regist <name>Service Name and Transport Protocol Port Number Registry</name>
ry"> <t>IANA has allocated the following service names from the
<t>IANA is requested to allocate the following service names from the
registry available at: registry available at:
https://www.iana.org/assignments/service-names-port-numbers/service-name <eref target="https://www.iana.org/assignments/service-names-port-number
s-port-numbers.xhtml.</t> s/l" brackets="angle"/>.</t>
<dl newline="false" spacing="compact" indent="25">
<t><figure align="center"> <dt>Service Name:</dt>
<artwork><![CDATA[ Service Name: dots-data <dd>dots-data</dd>
Port Number: N/A <dt>Port Number:</dt>
Transport Protocol(s): TCP <dd>N/A</dd>
Description: DOTS Data Channel Protocol <dt>Transport Protocol(s):</dt>
<dd>TCP</dd>
<dt>Description:</dt>
<dd>DOTS Data Channel Protocol.
The service name is used to construct the The service name is used to construct the
SRV service name "_dots-data._tcp" for SRV service name "_dots-data._tcp" for
discovering DOTS servers used to establish discovering DOTS servers used to establish
DOTS data channel. DOTS data channel.</dd>
Assignee: IESG <iesg@ietf.org> <dt>Assignee:</dt>
Contact: IETF Chair <chair@ietf.org> <dd>IESG: iesg@ietf.org</dd>
Reference: [ThisDocument] <dt>Contact:</dt>
<dd>IETF Chair: chair@ietf.org</dd>
Service Name: dots-call-home <dt>Reference:</dt>
Transport Protocol(s): TCP/UDP <dd>[RFC8973]</dd>
Description: DOTS Signal Channel Call Home Protocol. </dl>
<dl newline="false" spacing="compact" indent="25">
<dt>Service Name:</dt>
<dd>dots-call-home</dd>
<dt>Transport Protocol(s):</dt>
<dd>TCP/UDP</dd>
<dt>Description:</dt>
<dd>DOTS Signal Channel Call Home Protocol.
The service name is used to construct the The service name is used to construct the
SRV service names "_dots-call-home._udp" SRV service names "_dots-call-home._udp"
and "_dots-call-home._tcp" for discovering and "_dots-call-home._tcp" for discovering
Call Home DOTS clients used to establish Call Home DOTS clients used to establish
DOTS signal channel call home. DOTS signal channel Call Home.</dd>
Assignee: IESG <iesg@ietf.org> <dt>Assignee:</dt>
Contact: IETF Chair <chair@ietf.org> <dd>IESG: iesg@ietf.org</dd>
Reference: [ThisDocument] <dt>Contact:</dt>
]]></artwork> <dd>IETF Chair: chair@ietf.org</dd>
</figure></t> <dt>Reference:</dt>
<dd>[RFC8973]</dd>
<t>IANA is requested to update the following entry from the registry </dl>
<t>IANA has updated the following entry from the registry
available at: available at:
https://www.iana.org/assignments/service-names-port-numbers/service-name <eref target="https://www.iana.org/assignments/service-names-port-number
s-port-numbers.xhtml.</t> s/" brackets="angle"/>.</t>
<dl newline="false" spacing="compact" indent="25">
<t><figure align="center"> <dt>Port Number:</dt>
<artwork><![CDATA[ Service Name: dots-signal <dd>4646</dd>
Port Number: 4646 <dt>Transport Protocol(s):</dt>
Transport Protocol(s): TCP/UDP <dd>TCP/UDP</dd>
Description: DOTS Signal Channel Protocol. <dt>Description:</dt>
<dd>DOTS Signal Channel Protocol.
The service name is used to construct the The service name is used to construct the
SRV service names "_dots-signal._udp" and SRV service names "_dots-signal._udp" and
"_dots-signal._tcp" for discovering DOTS "_dots-signal._tcp" for discovering DOTS
servers used to establish DOTS signal servers used to establish DOTS signal
channel. channel.</dd>
Assignee: IESG <iesg@ietf.org> <dt>Assignee:</dt>
Contact: IETF Chair <chair@ietf.org> <dd>IESG: iesg@ietf.org</dd>
Reference: [RFC8782][ThisDocument] <dt>Contact:</dt>
]]></artwork> <dd>IETF Chair: chair@ietf.org</dd>
</figure></t> <dt>Reference:</dt>
<dd>[RFC8782][RFC8973]</dd>
</dl>
</section> </section>
<section anchor="iana6" numbered="true" toc="default">
<section anchor="iana6" title="DHCPv6 Options"> <name>DHCPv6 Options</name>
<t>IANA is requested to assign the following new DHCPv6 Option Codes <t>IANA has assigned the following new DHCPv6 Option Codes
in the registry maintained in: in the registry maintained in
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xht <eref target="https://www.iana.org/assignments/dhcpv6-parameters/" brack
ml#dhcpv6-parameters-2.</t> ets="angle"/>.</t>
<table align="center">
<t><figure> <name>DHCPv6 Options</name>
<artwork><![CDATA[Value Description Client ORO Sin <thead>
gleton Option <tr>
TBA1 OPTION_V6_DOTS_RI Yes Yes <th>Value</th>
TBA2 OPTION_V6_DOTS_ADDRESS Yes Yes]]></artwork> <th>Description</th>
</figure></t> <th>Client ORO</th>
<th>Singleton Option</th>
</tr>
</thead>
<tbody>
<tr>
<td>141</td>
<td>OPTION_V6_DOTS_RI</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>142</td>
<td>OPTION_V6_DOTS_ADDRESS</td>
<td>Yes</td>
<td>Yes</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="iana4" numbered="true" toc="default">
<section anchor="iana4" title="DHCPv4 Options"> <name>DHCPv4 Options</name>
<t>IANA is requested to assign the following new DHCPv4 Option Codes <t>IANA has assigned the following new DHCPv4 Option Codes
in the registry maintained in: in the registry maintained in
https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parame <eref target="https://www.iana.org/assignments/bootp-dhcp-parameters/" b
ters.xhtml#options.</t> rackets="angle"/>.</t>
<table align="left">
<texttable style="headers"> <name>DHCPv4 Options</name>
<ttcol align="right">Name</ttcol> <thead>
<tr>
<ttcol>Tag</ttcol> <th align="right">Name</th>
<th align="left">Tag</th>
<ttcol>Data Length</ttcol> <th align="left">Data Length</th>
<th align="left">Meaning</th>
<ttcol>Meaning</ttcol> <th align="left">Reference</th>
</tr>
<ttcol>Reference</ttcol> </thead>
<tbody>
<c>OPTION_V4_DOTS_RI</c> <tr>
<td align="right">OPTION_V4_DOTS_RI</td>
<c>TBA3</c> <td align="left">147</td>
<td align="left">N</td>
<c>N</c> <td align="left">The name of the peer DOTS agent.</td>
<td align="left">[RFC8973]</td>
<c>The name of the peer DOTS agent.</c> </tr>
<tr>
<c>[ThisDocument]</c> <td align="right">OPTION_V4_DOTS_ADDRESS</td>
<td align="left">148</td>
<c>OPTION_V4_DOTS_ADDRESS</c> <td align="left">N (the minimal length is 4)</td>
<td align="left">N/4 IPv4 addresses of peer DOTS agent(s).</td>
<c>TBA4</c> <td align="left">[RFC8973]</td>
</tr>
<c>N (the minimal length is 4)</c> </tbody>
</table>
<c>N/4 IPv4 addresses of peer DOTS agent(s).</c> <t/>
<c>[ThisDocument]</c>
</texttable>
<t></t>
</section> </section>
<section numbered="true" toc="default">
<section title="Application Service &amp; Application Protocol Tags"> <name>Application Service &amp; Application Protocol Tags</name>
<t>This document requests IANA to make the following allocations from <t>IANA has made the following allocations from
the registries available at: the registries available at
https://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.x <eref target="https://www.iana.org/assignments/s-naptr-parameters/" brac
html#s-naptr-parameters-1 kets="angle"/>
for Application Service Tags and for application service tags and application protocol tags.</t>
https://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.x <section anchor="serviceT" numbered="true" toc="default">
html#s-naptr-parameters-2 <name>DOTS Application Service Tag Registration</name>
for Application Protocol Tags.</t> <dl newline="false" spacing="compact" indent="35">
<dt>Application Service Tag:</dt>
<section anchor="serviceT" <dd>DOTS</dd>
title="DOTS Application Service Tag Registration"> <dt>Intended Usage:</dt>
<t><list style="symbols"> <dd>See <xref target="srvr" format="default"/></dd>
<t>Application Service Tag: DOTS</t> <dt>Security Considerations:</dt>
<dd>See <xref target="Security" format="default"/></dd>
<t>Intended Usage: See <xref target="srvr"></xref></t> <dt>Interoperability Considerations:</dt>
<dd>None</dd>
<t>Security Considerations: See <xref <dt>Relevant Publications:</dt>
target="Security"></xref></t> <dd>RFC 8973</dd>
</dl>
<t>Interoperability considerations: None</t>
<t>Relevant publications: This document</t>
</list></t>
</section> </section>
<section anchor="serviceT2" numbered="true" toc="default">
<section anchor="serviceT2" <name>DOTS Call Home Application Service Tag Registration</name>
title="DOTS Call Home Application Service Tag Registration"> <dl newline="false" spacing="compact" indent="35">
<t><list style="symbols"> <dt>Application Service Tag:</dt>
<t>Application Service Tag: DOTS-CALL-HOME</t> <dd>DOTS-CALL-HOME</dd>
<dt>Intended Usage:</dt>
<t>Intended Usage: See <xref target="srvr"></xref></t> <dd>See <xref target="srvr" format="default"/></dd>
<dt>Security Considerations:</dt>
<t>Security Considerations: See <xref <dd>See <xref target="Security" format="default"/></dd>
target="Security"></xref></t> <dt>Interoperability Considerations:</dt>
<dd>None</dd>
<t>Interoperability considerations: None</t> <dt>Relevant Publications:</dt>
<dd>RFC 8973</dd>
<t>Relevant publications: This document</t> </dl>
</list></t>
</section> </section>
<section anchor="suappt" numbered="true" toc="default">
<section anchor="suappt" <name>signal.udp Application Protocol Tag Registration</name>
title="signal.udp Application Protocol Tag Registration"> <dl newline="false" spacing="compact" indent="35">
<t><list style="symbols"> <dt>Application Protocol Tag:</dt>
<t>Application Protocol Tag: signal.udp</t> <dd>signal.udp</dd>
<dt>Intended Usage:</dt>
<t>Intended Usage: See <xref target="srvr"></xref></t> <dd>See <xref target="srvr" format="default"/></dd>
<dt>Security Considerations:</dt>
<t>Security Considerations: See <xref <dd>See <xref target="Security" format="default"/></dd>
target="Security"></xref></t> <dt>Interoperability Considerations:</dt>
<dd>None</dd>
<t>Interoperability considerations: None</t> <dt>Relevant Publications:</dt>
<dd>RFC 8973</dd>
<t>Relevant publications: This document</t> </dl>
</list></t>
</section> </section>
<section anchor="stappt" numbered="true" toc="default">
<section anchor="stappt" <name>signal.tcp Application Protocol Tag Registration</name>
title="signal.tcp Application Protocol Tag Registration"> <dl newline="false" spacing="compact" indent="35">
<t><list style="symbols"> <dt>Application Protocol Tag:</dt>
<t>Application Protocol Tag: signal.tcp</t> <dd>signal.tcp</dd>
<dt>Intended Usage:</dt>
<t>Intended Usage: See <xref target="srvr"></xref></t> <dd>See <xref target="srvr" format="default"/></dd>
<dt>Security Considerations:</dt>
<t>Security Considerations: See <xref <dd>See <xref target="Security" format="default"/></dd>
target="Security"></xref></t> <dt>Interoperability Considerations:</dt>
<dd>None</dd>
<t>Interoperability considerations: None</t> <dt>Relevant Publications:</dt>
<dd>RFC 8973</dd>
<t>Relevant publications: This document</t> </dl>
</list></t>
</section> </section>
<section anchor="dappt" numbered="true" toc="default">
<section anchor="dappt" <name>data.tcp Application Protocol Tag Registration</name>
title="data.tcp Application Protocol Tag Registration"> <dl newline="false" spacing="compact" indent="35">
<t><list style="symbols"> <dt>Application Protocol Tag:</dt>
<t>Application Protocol Tag: data.tcp</t> <dd>data.tcp</dd>
<dt>Intended Usage:</dt>
<t>Intended Usage: See <xref target="srvr"></xref></t> <dd>See <xref target="srvr" format="default"/></dd>
<dt>Security Considerations:</dt>
<t>Security Considerations: See <xref <dd>See <xref target="Security" format="default"/></dd>
target="Security"></xref></t> <dt>Interoperability Considerations:</dt>
<dd>None</dd>
<t>Interoperability considerations: None</t> <dt>Relevant Publications:</dt>
<dd>RFC 8973</dd>
<t>Relevant publications: This document</t> </dl>
</list></t>
</section> </section>
</section> </section>
</section> </section>
<section title="Contributors">
<t><figure>
<artwork><![CDATA[ Prashanth Patil
Cisco Systems, Inc.
Email: praspati@cisco.com]]></artwork>
</figure></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Brian Carpenter for the review of the BRSKI text used be in
previous versions of the specification.</t>
<t>Many thanks to Russ White for the review, comments, and text
contribution.</t>
<t>Thanks to Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the
review and comments.</t>
<t>Thanks to Bernie Volz for the review of the DHCP section.</t>
<t>Many thanks to Benjamin Kaduk for the detailed AD review.</t>
<t>Thanks to Zhen Cao, Kyle Rose, Nagendra Nainar, and Peter Yee for the
directorate reviews.</t>
<t>Thanks to Barry Leiba, Martin Duke, Roman Danyliw, Eric Vyncke, and
Magnus Westerlund for the IESG review.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <displayreference target="I-D.ietf-dots-signal-call-home" to="DOTS-SIG-CALL-HOME
<?rfc include="reference.RFC.2119"?> "/>
<displayreference target="I-D.ietf-dots-multihoming" to="DOTS-MULTIHOMING"/>
<?rfc include='reference.RFC.8415'?> <displayreference target="I-D.ietf-anima-bootstrapping-keyinfra" to="BTSRP-KEYIN
FR"/>
<?rfc include='reference.RFC.3958'?> <displayreference target="I-D.ietf-dots-use-cases" to="DOTS-USE-CASES"/>
<references>
<?rfc include='reference.RFC.2131'?> <name>References</name>
<references>
<?rfc include='reference.RFC.2132'?> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6763'?> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.3396'?> FC.8415.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.4291'?> FC.3958.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.8174'?> FC.2131.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.6890'?> FC.2132.xml"/>
</references> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6763.xml"/>
<references title="Informative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.8782'?> FC.3396.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7858'?> FC.4291.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.8484'?> FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.8811'?> FC.6890.xml"/>
</references>
<?rfc include='reference.I-D.ietf-dots-signal-call-home'?> <references>
<name>Informative References</name>
<?rfc include='reference.RFC.8572'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8782.xml"/>
<?rfc include='reference.RFC.6125'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7858.xml"/>
<?rfc include='reference.RFC.4033'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8484.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8811.xml"/>
<?rfc include='reference.RFC.2136'?> <!-- [I-D.ietf-dots-signal-call-home] IESG state Waiting for Writeup -->
<?rfc include='reference.RFC.3007'?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-dots-signal-call-home.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8572.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6125.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4033.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2136.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3007.xml"/>
<?rfc include='reference.I-D.ietf-dots-use-cases' <!-- [I-D.ietf-dots-use-cases] in AUTH48 state as of 12/15/20; RFC 8903 -->
?> <xi:include
href="https://datatracker.ietf.org/doc/bibxml3/reference.I
-D.ietf-dots-use-cases.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8783.xml"/>
<?rfc include='reference.RFC.8783'?> <!-- [I-D.ietf-anima-bootstrapping-keyinfra] in EDIT*R state as of 12/15/20; -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-an
ima-bootstrapping-keyinfra.xml"/>
<?rfc include='reference.I-D.ietf-anima-bootstrapping-keyinfra'?> <!-- [I-D.ietf-dots-multihoming] IESG state I-D Exists -->
<?rfc include='reference.I-D.ietf-dots-multihoming'?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-dots-multihoming.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Brian Carpenter"/> for the review of the B
ootstrapping
Remote Secure Key Infrastructure (BRSKI) text used in
previous draft versions of the specification.</t>
<t>Many thanks to <contact fullname="Russ White"/> for the review, comment
s, and text
contribution.</t>
<t>Thanks to <contact fullname="Dan Wing"/>, <contact fullname="Pei Wei"/>
,
<contact fullname="Valery Smyslov"/>, and <contact fullname="Jon Shallow"/
> for the
review and comments.</t>
<t>Thanks to <contact fullname="Bernie Volz"/> for the review of the DHCP
section.</t>
<t>Many thanks to <contact fullname="Benjamin Kaduk"/> for the detailed AD
review.</t>
<t>Thanks to <contact fullname="Zhen Cao"/>, <contact fullname="Kyle Rose"
/>,
<contact fullname="Nagendra Nainar"/>, and <contact fullname="Peter Yee"/>
for the
directorate reviews.</t>
<t>Thanks to <contact fullname="Barry Leiba"/>, <contact fullname="Martin
Duke"/>,
<contact fullname="Roman Danyliw"/>, <contact fullname="Éric Vyncke"/>, an
d
<contact fullname="Magnus Westerlund"/> for the IESG review.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Prashanth Patil">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal/>
<email>praspati@cisco.com</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 191 change blocks. 
899 lines changed or deleted 975 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/