[要約] RFC 8973は、DDoS Open Threat Signaling (DOTS) エージェントの発見に関する技術仕様です。この文書の目的は、DDoS攻撃の脅威に対処するために、DOTSクライアントとサーバーが互いを発見し、通信を確立する方法を定義することです。利用場面としては、DDoS攻撃の検出時に迅速な対応を可能にするためのシステム間通信の自動化が挙げられます。
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 8973 Orange
Category: Standards Track T. Reddy.K
ISSN: 2070-1721 McAfee
January 2021
DDoS Open Threat Signaling (DOTS) Agent Discovery
DDOSオープン脅威シグナリング（ドット）エージェント発見
Abstract
概要
This document specifies mechanisms to configure DDoS Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS signal channel Call Home. It can be useful to know the appropriate DOTS server for a given location in order to engage mitigation actions. This is true even in cases where the DOTS client cannot localize the attack: cases where it only knows that some resources are under attack and that help is needed.
このドキュメントでは、DDOS Open Threatシグナリング（ドット）クライアントをドットサーバーで構成するメカニズムを指定します。発見手順では、ドット信号チャネル呼び出しホームもカバーしています。緩和措置を講じるために、特定の場所のために適切なドットサーバーを知ることが有用であり得る。これは、DOTSクライアントが攻撃をローカライズできない場合でも、一部のリソースが攻撃しているだけであり、そのヘルプが必要とされている場合でも当てはまります。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8973.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8973で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
3. Why Multiple Discovery Mechanisms?
4. DOTS Discovery Procedure
5. DHCP Options for DOTS Agent Discovery
5.1. DHCPv6 DOTS Options
5.1.1. Format of DOTS Reference Identifier Option
5.1.2. Format of DOTS Address Option
5.1.3. DHCPv6 Client Behavior
5.2. DHCPv4 DOTS Options
5.2.1. Format of DOTS Reference Identifier Option
5.2.2. Format of DOTS Address Option
5.2.3. DHCPv4 Client Behavior
6. Discovery Using Service Resolution
7. DNS Service Discovery
8. Security Considerations
8.1. DHCP
8.2. Service Resolution
8.3. DNS Service Discovery
9. IANA Considerations
9.1. Service Name and Transport Protocol Port Number Registry
9.2. DHCPv6 Options
9.3. DHCPv4 Options
9.4. Application Service & Application Protocol Tags
9.4.1. DOTS Application Service Tag Registration
9.4.2. DOTS Call Home Application Service Tag Registration
9.4.3. signal.udp Application Protocol Tag Registration
9.4.4. signal.tcp Application Protocol Tag Registration
9.4.5. data.tcp Application Protocol Tag Registration
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
DDoS Open Threat Signaling (DOTS) [RFC8811] specifies an architecture in which a DOTS client can inform a DOTS server that the network is under a potential attack and that appropriate mitigation actions are required. Indeed, because the lack of a common method to coordinate a real-time response among involved actors and network domains inhibits the effectiveness of DDoS attack mitigation, the DOTS signal channel protocol [RFC8782] is meant to carry requests for DDoS attack mitigation. With this approach, DOTS can reduce the impact of an attack and lead to more efficient defensive actions in various deployment scenarios, such as those discussed in [DOTS-USE-CASES]. Moreover, DOTS clients can instruct a DOTS server to install named filtering rules by means of the DOTS data channel protocol [RFC8783].
DDOS Open Threat Signaling（DOTS）[RFC8811]は、ドットクライアントがネットワークが潜在的な攻撃の下にあること、および適切な緩和アクションが必要であることをドットサーバーに通知できるアーキテクチャを指定します。確かに、関与するアクターとネットワークドメインの間でリアルタイムの応答を調整する一般的な方法の欠如は、DDOS攻撃の軽減の有効性を禁止しているため、DOTS信号チャネルプロトコル[RFC8782]はDDOS攻撃の軽減の要求を継続することを意図しています。このアプローチでは、ドットは攻撃の影響を軽減し、Dots-use-ecessで説明されているようなさまざまな展開シナリオでより効率的な防御的な行動を招く可能性があります。さらに、ドットクライアントは、ドットデータチャネルプロトコル[RFC8783]によって、名前付きフィルタリングルールをインストールするようにドットサーバに指示することができる。
The basic high-level DOTS architecture is illustrated in Figure 1.
基本的な高水準ドットアーキテクチャを図1に示します。
+-----------+ +-------------+
| Mitigator | ~~~~~~~~~~ | DOTS Server |
+-----------+ +------+------+
|
|
|
+---------------+ +------+------+
| Attack Target | ~~~~~~ | DOTS Client |
+---------------+ +-------------+
Figure 1: Basic DOTS Architecture
図1：基本ドットアーキテクチャ
[RFC8811] specifies that the DOTS client may be 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 family. The DOTS client establishes one or more DOTS sessions by connecting to the provided DOTS server addresses.
[RFC8811]ドットクライアントにドットサーバーのリストを指定して、それぞれ1つ以上のIPアドレスに関連付けられていることを指定します。これらのアドレスは同じアドレスファミリである場合とそうでない場合があります。ドットクライアントは、提供されたドットサーバアドレスに接続することによって1つ以上のドットセッションを確立する。
This document specifies methods for DOTS clients to discover their DOTS server(s). The rationale for specifying multiple discovery mechanisms is discussed in Section 3.
このドキュメントでは、ドットクライアントが自分のドットサーバーを検出するためのメソッドを指定します。複数の発見メカニズムを指定するための理論的根拠はセクション3で説明されています。
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 [DOTS-SIG-CALL-HOME]. The basic high-level DOTS Call Home architecture is illustrated in Figure 2.
DOTS信号チャネル呼び出しホーム[DOTS-SIG-CALL-HOME]のコンテキストでドットクライアントを見つけるためにDOTSサーバーによっても使用できます。基本的な高水準ドット呼び出しホームアーキテクチャを図2に示します。
+---------------+ +-------------+
| Alert | ~~~~~~ | Call Home |
| | | DOTS Client |
+---------------+ +------+------+
|
|
|
+---------------+ +------+------+
| Attack | ~~~~~~ | Call Home |
| Source(s) | | DOTS Server |
+---------------+ +-------------+
Figure 2: Basic DOTS Signal Channel Call Home Functional Architecture
図2：基本ドット信号チャネル呼び出しホーム機能アーキテクチャ
A DOTS agent may be used to establish base DOTS channels, DOTS Call Home, or both. This specification accommodates all these deployment cases.
ドットエージェントは、ベースドットチャネル、ドットコールホーム、またはその両方を確立するために使用され得る。この仕様はこれらすべての展開ケースに対応しています。
Considerations for the selection of DOTS server(s) by multihomed DOTS clients are out of this document's scope; readers should refer to [DOTS-MULTIHOMING] for more details.
マルチホームドットクライアントによるドットサーバーの選択に関する考慮事項は、このドキュメントの範囲外です。詳細については、読者は[DOTS-MULTIHOMING]を参照してください。
This document assumes that security credentials to authenticate DOTS server(s) are pre-provisioned to a DOTS client using a mechanism such as (but not limited to) those discussed in [RFC8572] or [BTSRP-KEYINFR]. DOTS clients use those credentials for authentication purposes following the rules documented in [RFC8782].
このドキュメントは、[RFC8572]または[BTSRP-keyinfr]で説明されている（ただし、これに限定されない）メカニズムを使用して、DOTSサーバーを認証するためのセキュリティ認証情報がドットクライアントに事前にプロビジョニングされていると想定しています。ドットクライアントは、[RFC8782]に記載されている規則に従って認証目的でそれらの認証情報を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The reader should be familiar with the terms defined in [RFC3958].
リーダーは[RFC3958]で定義されている用語に精通している必要があります。
This document makes use of the following terms:
この文書は以下の用語を利用しています。
DHCP: refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415].
DHCP：DHCPV4 [RFC2131]およびDHCPV6 [RFC8415]の両方を指す。
DOTS client: refers to a DOTS-aware software module responsible for requesting attack response coordination with other DOTS-aware elements.
ドットクライアント：他のドット対応要素との攻撃応答調整を要求する責任を負うドット対応ソフトウェアモジュールを指します。
DOTS server: is a DOTS-aware software module handling and responding to messages from DOTS clients. The DOTS server enables mitigation on behalf of the DOTS client, if requested, by communicating the DOTS client's request to the mitigator and returning selected mitigator feedback to the requesting DOTS client.
DOTSサーバー：ドット対応ソフトウェアモジュールの処理とドットクライアントからのメッセージへの応答です。ドットサーバは、ドットクライアントの要求を複雑化し、選択された軽減フィードバックを要求しているドットクライアントに返すことによって、要求された場合、ドットクライアントに代わる軽減を可能にします。
Call Home DOTS client or server: refers to a DOTS client or server deployed in a Call Home scenario (Figure 2).
コールホームドットクライアントまたはサーバー：コールホームシナリオでデプロイされたドットクライアントまたはサーバーを参照します（図2）。
DOTS agent: is any DOTS-aware software module capable of participating in a DOTS channel.
ドットエージェント：ドットチャネルに参加できるドット対応ソフトウェアモジュールです。
Peer DOTS agent: refers to the peer DOTS server (base DOTS operation) or to a peer Call Home DOTS client (for DOTS signal channel Call Home).
ピアトドットエージェント：ピアトドットサーバ（基本ドット操作）またはピアコールホームドットクライアント（ドット信号チャネルコールホーム用）を指します。
Analysis of the various use cases sketched in [DOTS-USE-CASES] reveals that it is unlikely that one single discovery method can be suitable for all the sample deployments. Concretely:
Dots-Use-Sepoキーでスケッチされたさまざまなユースケースの分析は、1つのディスカバリメソッドがすべてのサンプル展開に適している可能性が低いことがわかります。具体的に：
* Many of the use cases discussed in [DOTS-USE-CASES] do involve Customer Premises Equipment (CPE). Multiple CPEs connected to distinct network providers may even be considered. It is intuitive to leverage existing mechanisms, such as discovery using service resolution or DHCP, to provision the CPE acting as a DOTS client with the DOTS server(s).
* [ドットユースケース]で説明したユースケースの多くは、顧客宅内機器（CPE）を含んでいます。異なるネットワークプロバイダに接続されている複数のCPEを考慮することもできます。DOTSサーバーを使用してドットクライアントとして機能するCPEをプロビジョニングするために、サービス解決またはDHCPを使用したディスカバリなどの既存のメカニズムを活用することは直感的です。
* Resolving a DOTS server domain name offered by an upstream transit provider provisioned to a DOTS client into IP address(es) requires the use of the appropriate DNS resolvers; otherwise, resolving those names will fail. The use of protocols, such as DHCP, does allow associating provisioned DOTS server domain names with a list of DNS servers to be used for name resolution. Furthermore, DHCP allows for directly providing IP addresses, therefore, avoiding the need for extra lookup delays.
* DOTSクライアントにプロビジョニングされたアップストリームトランジットプロバイダがIPアドレスにプロビジョニングされたドットサーバドメイン名を解決するには、適切なDNSリゾルバを使用する必要があります。それ以外の場合は、それらの名前を解決すると失敗します。DHCPなどのプロトコルの使用は、プロビジョニングされたドットサーバードメイン名を名前解決に使用されるDNSサーバーのリストと関連付けます。さらに、DHCPは、追加のルックアップ遅延の必要性を回避するために、IPアドレスを直接提供することを可能にします。
* Some of the use cases may allow DOTS clients to have direct communications with upstream DOTS servers, that is, no DOTS gateway is involved. Leveraging existing protocol behaviors that do not require specific features on the node embedding the DOTS client may ease DOTS deployment. Typically, the use of Straightforward-Naming Authority Pointer (S-NAPTR) lookups [RFC3958] allows the DOTS server administrators to provision the preferred DOTS transport protocol between the DOTS client and the DOTS server and allows the DOTS client to discover this preference.
* ユースケースの中には、ドットクライアントがアップストリームドットサーバーと直接通信することができます。つまり、ドットゲートウェイが含まれていないことがあります。ドットクライアントを埋め込むノード上の特定の機能を必要としない既存のプロトコル動作を活用すると、ドットの展開が容易になる可能性があります。通常、直接的な命名権限ポインタ（S-NAPTR）検索[RFC3958]の使用により、ドットサーバー管理者はドットクライアントとドットサーバーとの間で優先ドットトランスポートプロトコルをプロビジョニングし、ドットクライアントがこの好みを発見することを可能にします。
* The upstream network provider is not the DDoS mitigation provider 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 service subscription (i.e., manual/local configuration).
* アップストリームネットワークプロバイダは、これらのユースケースのいくつかについてのDDOS軽減プロバイダーではありません。そのような展開のために、サービスサブスクリプション中にドットサーバドメイン名が提供されていると仮定することは（すなわち、手動/ローカル構成）。
* Multiple DOTS clients may be enabled within a network (e.g., an enterprise network). Dynamic discovery needs to be deterministic from an operational standpoint.
* 複数のドットクライアントは、ネットワーク内で有効にされてもよい（例えば、エンタープライズネットワーク）。動的発見は、運用上の観点から決定的である必要があります。
* Some of the use cases may involve a DOTS gateway that is responsible for selecting the appropriate DOTS server(s) to relay requests received from DOTS clients.
* ユースケースの中には、ドットクライアントから受信したリレーション要求に対する適切なドットサーバーを選択する責任があるドットゲートウェイを含めることができます。
Consequently, this document describes a unified discovery logic (Section 4) that involves the following mechanisms:
したがって、このドキュメントでは、次のメカニズムを含むUnified Discovery Logic（セクション4）について説明します。
* dynamic discovery using DHCP (Section 5)
* DHCPを用いた動的発見（セクション5）
* a resolution mechanism based on S-NAPTR resource records in the DNS (Section 6)
* DNSのS-NAPTRリソースレコードに基づく解決メカニズム（セクション6）
* DNS Service Discovery (Section 7)
* DNSサービス発見（セクション7）
Operators will need a consistent set of ways in which DOTS clients can discover this information and a consistent priority among these options. If some devices prefer manual configuration over dynamic discovery while others prefer dynamic discovery over manual 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 the devices are configured properly, and then reconfigure the device through the preferred method.
オペレータは、ドットクライアントがこの情報とこれらのオプションの間で一貫した優先順位を発見できる一貫した方法を必要とします。マニュアル構成を介して動的検出を好みながら、動的検出を介してマニュアル設定を希望するデバイスが一部のデバイスを使用すると、その結果、誤ったドットサーバーを使用しているデバイスが表示され、デバイスが正しく設定されていることを確認する方法が決定されます。次に、好ましい方法を通して装置を再構成する。
All DOTS clients MUST support at least one of the three mechanisms below to determine a DOTS server list. All DOTS clients SHOULD implement 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 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 last two mechanisms, or an application server will support a local configuration. More examples are discussed in Section 3. DOTS clients will prefer information received from the discovery methods in the order listed below.
すべてのドットクライアントは、ドットサーバーリストを決定するために、以下の3つのメカニズムのうちの少なくとも1つをサポートしなければなりません。すべてのドットクライアントは、大規模な環境でのドットの展開を容易にするために、次のような方法の3つまたは複数のものすべてを実用的であるべきである。たとえば、CPEは最初の2つのメカニズムをサポートし、LAN内のホストは最後の2つのメカニズムをサポートし、またはアプリケーションサーバーはローカル構成をサポートします。さらに詳しく説明します.Dotsクライアントは、以下にリストされている順序で検出方法から受信した情報を優先します。
1. Explicit Configuration:
1. 明示的な設定：
Local/Manual Configuration: A DOTS client will learn the DOTS server(s) by means of local or manual DOTS configuration (i.e., DOTS servers configured at the system level). Configuration discovered from a DOTS client application is considered a local configuration.
ローカル/マニュアル設定：ドットクライアントは、ローカルまたは手動ドット設定（すなわち、システムレベルで構成されたドットサーバ）を用いてドットサーバを学習する。ドットクライアントアプリケーションから検出された設定はローカル構成と見なされます。
An implementation may give the user an opportunity (e.g., by means of configuration file options or menu items) to specify DOTS server(s) for each address family. These may be specified either as a list of IP addresses or the DNS name of a DOTS server. When only DOTS server IP addresses are configured, a reference identifier must also be configured for authentication purposes.
実装は、各アドレスファミリのためのドットサーバを指定するために（例えば、構成ファイルオプションまたはメニュー項目によって）ユーザに機会を与えることができる。これらは、DOTアドレスのリストまたはDOTSサーバーのDNS名のいずれかとして指定できます。ドットサーバーのIPアドレスのみが設定されている場合は、参照識別子も認証目的で設定する必要があります。
Automatic Configuration (e.g., DHCP): The DOTS client attempts to discover DOTS server(s) names and/or addresses from DHCP, as described in Section 5.
自動設定（例えば、DHCP）：DOTSクライアントは、セクション5で説明されているように、DOTSサーバーの名前および/またはDHCPからのアドレスを検出しようとします。
2. Service Resolution: The DOTS client attempts to discover DOTS server name(s) using service resolution, as specified in Section 6.
2. サービスの解決：ドットクライアントは、セクション6で指定されているように、サービスの解決を使用してドットサーバー名を検出しようとします。
3. DNS-SD: DNS-based Service Discovery. The DOTS client attempts to discover DOTS server name(s) using DNS service discovery, as specified in Section 7.
3. DNS-SD：DNSベースのサービス発見。DOTSクライアントは、セクション7で指定されているように、DNSサービス検出を使用してドットサーバー名を検出しようとします。
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 relevant DOTS server is obtained directly. Implementation options may vary on a per-device basis, as some devices may not have DNS capabilities and/or suitable DNS configuration.
これらのメカニズムの中には、DOTSサーバーのIPアドレスを解決するためのDNSの使用を意味しますが、その他のドットサーバーのIPアドレスは直接取得されます。デバイスごとに実装オプションは、DNS機能や適切なDNS構成を持たない可能性があるため、デバイスごとに異なる場合があります。
On hosts with more than one interface or address family (IPv4/IPv6), the DOTS server discovery procedure has to be performed for each interface-/address-family combination. A DOTS client may choose to perform the discovery procedure only for a desired interface/address combination if the client does not wish to discover a DOTS server for all interface-/address-family combinations.
複数のインタフェースまたはアドレスファミリ（IPv4 / IPv6）を持つホストでは、DOTSサーバーの検出手順をインターフェイス/アドレス - ファミリの組み合わせごとに実行する必要があります。ドットクライアントは、クライアントがすべてのインタフェース/アドレスファミリの組み合わせに対してドットサーバを検出したくない場合に、所望のインタフェース/アドレスの組み合わせに対してのみ検出手順を実行することを選択することができる。
This procedure is also followed by a Call Home DOTS server to discover its Call Home DOTS client in the context of [DOTS-SIG-CALL-HOME].
この手順には、[Dots-Sig-Call-Home]のコンテキストでコールホームドットクライアントを発見するためのコールホームドットサーバーが続きます。
The discovery method is performed upon the bootstrapping of a DOTS agent and is reiterated by the DOTS agent upon the following events:
発見方法は、ドットエージェントのブートストラップ時に実行され、次のイベントではドットエージェントによって繰り返されます。
* expiry of a validity timer (e.g., DHCP lease, DHCP information refresh time, or DNS TTL) associated with a discovered DOTS agent
* 発見されたドットエージェントに関連する有効性タイマ（例えば、DHCPリース、DHCP情報更新時間、またはDNS TTL）の有効期限
* expiry of the certificate of a peer DOTS agent currently in use
* 現在使用中のピアトドットエージェントの証明書の有効期限
* attachment to a new network
* 新しいネットワークへの添付
As reported in Section 1.7.2 of [RFC6125]:
[RFC6125]のセクション1.7.2で報告されているように：
| Some certification authorities issue server certificates based on
| IP addresses, but preliminary evidence indicates that such
| certificates are a very small percentage (less than 1%) of issued
| certificates.
In order to allow for PKIX-based authentication between a DOTS client and server while accommodating the current best practices for issuing certificates, this document allows DOTS agents to retrieve the names of 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 (2) to be presented as a reference identifier for authentication purposes.
証明書を発行するための現在のベストプラクティスを収容しながら、ドットクライアントとサーバー間のPKIXベースの認証を可能にするために、このドキュメントはドットエージェントがそれらのピアドットエージェントの名前を取得することを可能にします。これらの名前は2つの目的に使用できます。（1）認証目的で、ピアトドットエージェントまたは（2）のIPアドレスのリストを取得するには、（1）、認証目的で参照識別子として表示されます。
Defining the option to include a list of IP addresses would avoid depending on an underlying name resolution, but that design requires also supplying a name for PKIX-based authentication purposes.
IPアドレスのリストを含めるオプションを定義すると、基礎となる名前解決によっては避けられませんが、そのデザインはPKIXベースの認証目的で名前を指定する必要があります。
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 can also be discovered using the options defined in Section 5.1.
ドットゲートウェイがドットセッションに関与できることを考えると、リンクローカルアドレスを使用してピアトドットエージェントを到達可能にすることができます。そのようなアドレスは、セクション5.1で定義されているオプションを使用して発見することもできます。
The list of the IP addresses returned by DHCP servers is typically used to feed the DOTS server selection procedure, including when DOTS agents are provided with primary and backup IP addresses of their peer DOTS agents. An example of the DOTS server selection procedure is specified in Section 4.3 of [RFC8782].
DTOSエージェントがピアドットエージェントのプライマリおよびバックアップIPアドレスを指定して、DOTSエージェントに提供されている場合など、DHCPサーバーによって返されるIPアドレスのリストは、通常、ドットサーバーの選択手順をフィードするために使用されます。[RFC8782]の4.3節では、ドットサーバ選択手順の例を指定します。
The design assumes that the same peer DOTS agent is used for establishing both signal and data channels. For more customized configurations (e.g., transport-specific configuration and distinct DOTS servers for the signal and data channels), an operator can supply only a DOTS reference identifier that will be then passed to the procedure described in Section 6.
設計は、同じピアトドットエージェントが信号チャネルとデータチャネルの両方を確立するために使用されることを前提としています。よりカスタマイズされた構成（例えば、信号チャネルおよびデータチャネルのためのトランスポート固有構成および別個のドットサーバ）について、オペレータは、セクション6で説明されている手順に渡されるであろうドット参照識別子のみを供給することができる。
The design allows terminating the base DOTS channels and DOTS Call 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 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 DOTS Call Home. The DOTS client (or Call Home DOTS server) will then use the address selection procedure specified in Section 4.3 of [RFC8782] to identify the IP address of the peer DOTS server (or Call Home DOTS client).
この設計により、基本ドットチャネルとドットコールホームを同じまたは別個のピアトドットエージェントに停止させることができます。別個のピアドットエージェントがデプロイされている場合、DHCPオプションは、例えば、要求側ドットエージェントへのIPアドレスのリストを返すことができます。このリストには、基本ドットチャネルに使用されるIPアドレスと、ドットコールホームのIPアドレスが含まれています。ドットクライアント（または呼び出しホームドットサーバー）は、[RFC8782]のセクション4.3で指定されているアドレス選択手順を使用して、ピアトドットサーバーのIPアドレス（またはホームドットクライアントを呼び出します）を識別します。
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 reference identifier and a list that includes both 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 server), which will try to establish connections to the addresses of that list and destination port number 4646 (or the Call Home port 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 server (or Call Home DOTS client).
たとえば、DOTSサーバーが2001年に到達可能であると考えてみましょう.Call Home Dots Clientは2001で到達可能な一方、DB8：122：300 :: 2。その後、DHCPサーバーは1つのドット参照識別子と、2001：DB8：122：300 :: 1,2001：300 :: 1,200：300 :: 2の両方を含むリストを返します。そのリストはドットクライアント（またはホームドットサーバーを呼び出します）に渡されます。これは、そのリストのアドレスと宛先ポート番号4646（または呼び出しホームポート番号）への接続を確立しようとします。その結果、ドットクライアント（または呼び出しホームドットサーバー）は、ドットサーバーとして2001：DB8：122：300 :: 1（または2001：DB8：122：300 :: 2）を選択します（またはホームドットクライアントを呼び出します）。。
The DHCPv6 DOTS Reference Identifier option is used to configure the name of the DOTS server (or the name of the Call Home DOTS client). The format of this option is shown in Figure 3.
DHCPv6 dotsリファレンス識別子オプションは、ドットサーバーの名前（または呼び出しホームドットクライアントの名前）を設定するために使用されます。このオプションのフォーマットを図3に示します。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_DOTS_RI | Option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| dots-agent-name (FQDN) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DHCPv6 DOTS Reference Identifier Option
図3：DHCPv6ドットリファレンス識別子オプション
The fields of the option shown in Figure 3 are as follows:
図3に示すオプションのフィールドは次のとおりです。
Option-code: OPTION_V6_DOTS_RI (141, see Section 9.2). Option-length: Length of the dots-agent-name field in octets. dots-agent-name: A fully qualified domain name of the peer DOTS agent. This field is formatted as specified in Section 10 of [RFC8415].
オプションコード：option_v6_dots_ri（141、セクション9.2を参照）。オプション長：オクテットのdots-agent-nameフィールドの長さ。dots-agent-name：ピアトドットエージェントの完全修飾ドメイン名。このフィールドは[RFC8415]のセクション10で指定されているようにフォーマットされています。
An example of the dots-agent-name encoding is shown in Figure 4. This example conveys the FQDN "dots.example.com", and the resulting Option-length field is 18.
DOTS-Agent-Nameエンコーディングの例を図4に示します。この例では、FQDN "dots.example.com"を伝え、結果として得られるオプション長フィールドは18です。
+------+------+------+------+------+------+------+------+------+
| 0x04 | d | o | t | s | 0x07 | e | x | a |
+------+------+------+------+------+------+------+------+------+
| m | p | l | e | 0x03 | c | o | m | 0x00 |
+------+------+------+------+------+------+------+------+------+
Figure 4: An Example of the dots-agent-name Encoding
図4：dots-agent-nameエンコーディングの例
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 format of this option is shown in Figure 5.
DHCPv6ドットアドレスオプションを使用して、ドットサーバー（またはコールホームドットクライアント）のIPv6アドレスのリストを設定できます。このオプションのフォーマットを図5に示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DOTS ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DOTS ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DHCPv6 DOTS Address Option
図5：DHCPv6ドットアドレスオプション
The fields of the option shown in Figure 5 are as follows:
図5に示すオプションのフィールドは次のとおりです。
Option-code: OPTION_V6_DOTS_ADDRESS (142, see Section 9.2). Option-length: Length of the DOTS ipv6-address fields in octets. This MUST be a multiple of 16. DOTS ipv6-address: Includes one or more IPv6 addresses [RFC4291] of the peer DOTS agent to be used by a DOTS agent for establishing a DOTS session. The addresses are listed in the order of preference for use by the DOTS agent.
オプションコード：option_v6_dots_address（142、セクション9.2を参照）。オプション長：OCTETのDOTS IPv6アドレスフィールドの長さ。これは16の倍数でなければなりません.Dots IPv6-address：ドットセッションを確立するためのドットエージェントによって使用されるピアトドットエージェントの1つ以上のIPv6アドレス[RFC4291]を含みます。アドレスは、ドットエージェントによる使用のための好みの順序でリストされています。
Note that IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) may be included in this option when there is no DHCPv4 server able to advertise the DHCPv4 DOTS options (Section 5.2) and when only IPv4 connectivity is possible to the peer DOTS agent.
DHCPv4ドットオプション（セクション5.2）をアドバタイズできるDHCPv4サーバーがない場合（セクション5.2）、ピアにIPv4接続が可能な場合は、このオプションにIPv4マップIPv6アドレス（[RFC4291]）を含めることができます。ドットエージェント。
DHCP clients MAY request options OPTION_V6_DOTS_RI and OPTION_V6_DOTS_ADDRESS, as defined in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7 of [RFC8415]. As a convenience to the reader, it is mentioned here that the DHCP client includes the requested option codes in the Option Request option.
DHCPクライアントは、[RFC8415]のセクション18.2.1,18.2.2,18.2.4,18.2.5,18.2.6、および21.7で定義されているように、オプションoption_v6_dots_riおよびoption_v6_dots_addressを要求することができます。リーダーの便宜上、DHCPクライアントはオプション要求オプションで要求されたオプションコードを含むことが言及されています。
If the DHCP client receives more than one instance of option OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS), it MUST use only the first instance of that option.
DHCPクライアントがオプションOPTION_V6_DOTS_RI（またはOPTION_V6_DOTS_ADDRESS）の複数のインスタンスを受信した場合は、そのオプションの最初のインスタンスのみを使用する必要があります。
The DHCP client MUST silently discard multicast and host loopback addresses [RFC6890] conveyed in OPTION_V6_DOTS_ADDRESS.
DHCPクライアントは、MulticastとHost Loopbackアドレス[RFC6890]を黙って廃棄しなければなりません[RFC6890]はoption_v6_dots_addressで伝えられます。
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 as the reference identifier for authentication purposes (e.g., PKIX [RFC6125]), while the valid addresses included 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 passed to an underlying resolution library in the presence of a valid OPTION_V6_DOTS_ADDRESS in a response.
DHCPクライアントがoption_v6_dots_riとoption_v6_dots_addressの両方を受信して検証した場合、option_v6_dots_riの内容は認証目的のための参照識別子（例えば、PKIX [RFC6125]）として使用され、Option_v6_dots_addressに含まれる有効なアドレスはピアトドットエージェントに到達するために使用されます。言い換えれば、option_v6_dots_riで伝達された名前は、応答内の有効なoption_v6_dots_addressの存在下、基礎となる解像ライブラリに渡されてはいけません。
If the DHCP client receives OPTION_V6_DOTS_RI only, but OPTION_V6_DOTS_RI contains more than one name, the DHCP client MUST use only the first name. Once the name is validated (Section 10 of [RFC8415]), the name is passed to a name resolution library. Moreover, that name is also used as a reference identifier for authentication purposes.
DHCPクライアントがoption_v6_dots_riを受信した場合、option_v6_dots_riに複数の名前が含まれていますが、DHCPクライアントは最初の名前のみを使用する必要があります。名前が検証されると（[RFC8415]のセクション10）、名前は名前解決ライブラリに渡されます。さらに、その名前は認証目的のための参照識別子としても使用されます。
If the DHCP client receives OPTION_V6_DOTS_ADDRESS only, 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 identifiers for authentication.
DHCPクライアントがoption_v6_dots_addressのみを受け取る場合、option_v6_dots_addressに含まれるアドレスはピアトドットエージェントに到達するために使用されます。さらに、これらのアドレスを認証の識別子として使用できます。
The DHCPv4 [RFC2132] DOTS Reference Identifier option is used to configure a name of the peer DOTS agent. The format of this option is illustrated in Figure 6.
DHCPv4 [RFC2132]ドット参照識別子オプションは、ピアトドットエージェントの名前を設定するために使用されます。このオプションのフォーマットを図6に示します。
Code Length Peer DOTS agent name
+-----+-----+-----+-----+-----+-----+-----+--
| 147 | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+--
Figure 6: DHCPv4 DOTS Reference Identifier Option
図6：DHCPv4ドットリファレンス識別子オプション
The values s1, s2, s3, etc. represent the domain name labels in the domain name encoding.
値S1、S2、S3等は、ドメイン名エンコード内のドメイン名ラベルを表す。
The fields of the option shown in Figure 6 are as follows:
図6に示すオプションのフィールドは次のとおりです。
Code: OPTION_V4_DOTS_RI (147, see Section 9.3). Length: Includes the length of the "Peer DOTS agent name" field in octets. Peer DOTS agent name: The domain name of the peer DOTS agent. This field is formatted as specified in Section 10 of [RFC8415].
コード：option_v4_dots_ri（147、セクション9.3を参照）。長さ：オクテットの「ピアトエージェント名」フィールドの長さを含みます。ピアトドットエージェント名：ピアトドットエージェントのドメイン名。このフィールドは[RFC8415]のセクション10で指定されているようにフォーマットされています。
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 illustrated in Figure 7.
DHCPv4ドットアドレスオプションを使用して、ピアトドットエージェントのIPv4アドレスのリストを設定できます。このオプションのフォーマットを図7に示します。
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code=148 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DOTS IPv4 Address |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| | |
| DOTS IPv4 Address | |
| | optional
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. ... . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
Figure 7: DHCPv4 DOTS Address Option
図7：DHCPv4ドットアドレスオプション
The fields of the option shown in Figure 7 are as follows:
図7に示すオプションのフィールドは次のとおりです。
Code: OPTION_V4_DOTS_ADDRESS (148, see Section 9.3). Length: Set to 4*N, where N is the number of IPv4 addresses included in the option. DOTS IPv4 Address(es): Contains one or more IPv4 addresses of 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 agent.
コード：option_v4_dots_address（148、セクション9.3を参照）。長さ：4 * nに設定します。ここで、nはオプションに含まれるIPv4アドレスの数です。DOTS IPv4アドレス（ES）：ドットエージェントによって使用されるピアトドットエージェントの1つ以上のIPv4アドレスを含みます。アドレスは、ドットエージェントによる使用のための好みの順序でリストされています。
OPTION_V4_DOTS_ADDRESS is a concatenation-requiring option. As such, the mechanism specified in [RFC3396] MUST be used if OPTION_V4_DOTS_ADDRESS exceeds the maximum DHCPv4 option size of 255 octets.
option_v4_dots_addressは連結要求オプションです。そのため、Option_v4_dots_addressが255オクテットの最大DHCPv4オプションサイズを超えると、[RFC3396]で指定されたメカニズムを使用する必要があります。
To discover a peer DOTS agent, the DHCPv4 client MUST include both OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter Request List option [RFC2132].
ピアトドットエージェントを検出するには、DHCPv4クライアントは、パラメータ要求リストオプション[RFC2132]で、option_v4_dots_riとoption_v4_dots_addressの両方を含める必要があります。
If the DHCP client receives more than one instance of OPTION_V4_DOTS_RI option, it MUST use only the first instance of that option.
DHCPクライアントがOption_v4_dots_riオプションの複数のインスタンスを受信した場合は、そのオプションの最初のインスタンスのみを使用する必要があります。
The DHCP client MUST silently discard multicast and host loopback addresses [RFC6890] conveyed in OPTION_V4_DOTS_ADDRESS.
DHCPクライアントは、MulticastとHost Loopbackアドレス[RFC6890]を黙って破棄しなければなりません[RFC6890]はoption_v4_dots_addressで伝えられます。
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 as the reference identifier for authentication purposes (e.g., PKIX [RFC6125]), while the valid addresses included 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 passed to an underlying resolution library in the presence of valid OPTION_V4_DOTS_ADDRESS in a response.
DHCPクライアントがoption_v4_dots_riとoption_v4_dots_addressの両方を受信して検証する場合、option_v4_dots_riのコンテンツは認証目的のための参照識別子（例えば、PKIX [RFC6125]）として使用されますが、Option_v4_dots_addressに含まれる有効なアドレスはピアトドットエージェントに到達するために使用されます。言い換えれば、option_v4_dots_riで伝達された名前は、応答内の有効なoption_v4_dots_addressの存在下、基礎となる解像ライブラリに渡されてはいけません。
If the DHCP client receives OPTION_V4_DOTS_RI only, but OPTION_V4_DOTS_RI option contains more than one name, as distinguished by the presence of multiple root labels, the DHCP client MUST use only the first name. Once the name is validated (Section 10 of [RFC8415]), the name is passed to a name resolution library. Moreover, that name is also used as a reference identifier for authentication purposes.
DHCPクライアントがoption_v4_dots_riを受信した場合、option_v4_dots_riオプションに複数のルートラベルが存在すると、DHCPクライアントは最初の名前のみを使用する必要があります。名前が検証されると（[RFC8415]のセクション10）、名前は名前解決ライブラリに渡されます。さらに、その名前は認証目的のための参照識別子としても使用されます。
If the DHCP client receives OPTION_V4_DOTS_ADDRESS only, 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 identifiers for authentication.
DHCPクライアントがoption_v4_dots_addressのみを受信した場合、option_v4_dots_addressに含まれるアドレスは、ピアドットサーバーに到達するために使用されます。さらに、これらのアドレスを認証の識別子として使用できます。
This mechanism is performed in two steps:
このメカニズムは2つのステップで実行されます。
1. A DNS domain name is retrieved for each combination of interface and address family. A DOTS agent has to determine the domain in which it is located relying on dynamic means, such as DHCP (Section 5). Implementations may allow the user to specify a default name that is used if no specific name has been configured.
1. DNSドメイン名は、インターフェイスとアドレスファミリの組み合わせごとに取得されます。ドットエージェントは、DHCPなどのダイナミックな手段に頼っている配列を決定する必要があります（セクション5）。実装は、特定の名前が設定されていない場合に使用されるデフォルトの名前をユーザーに指定することができます。
2. Retrieved DNS domain names are then used for S-NAPTR lookups [RFC3958]. Further DNS lookups may be necessary to determine the peer DOTS agent IP address(es).
2. 検索されたDNSドメイン名は、S-NAPTRルックアップ[RFC3958]に使用されます。ピアトドットエージェントIPアドレスを決定するには、さらにDNSルックアップが必要になる場合があります。
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 the appropriate application service and the desired protocol tag is made to obtain information necessary to connect to the authoritative peer DOTS agent within the given domain.
ドットエージェントがDNSドメインを取得したか、または解決する必要があるピアドットエージェント名を検出したら、適切なアプリケーションサービスを使用したS-NAPTRルックアップと、希望のプロトコルタグが、信頼できるピアドットへの接続に必要な情報を取得するために行われます。与えられたドメイン内のエージェント。
This specification defines "DOTS" and "DOTS-CALL-HOME" as application service tags (Sections 9.4.1 and 9.4.2). It also defines "signal.udp" (Section 9.4.3), "signal.tcp" (Section 9.4.4), and "data.tcp" (Section 9.4.5) as application protocol tags. An example is provided in Figure 8.
この仕様は、アプリケーションサービスタグとして「ドット」と「ドットコールホーム」を定義しています（セクション9.4.1および9.4.2）。また、「Signal.UDP」（セクション9.4.3）、「SIGNAL.TCP」（セクション9.4.4）、および「Data.TCP」（9.4.5項）をアプリケーションプロトコルタグとして定義します。例を図8に示す。
In the example below, for domain "example.net", the resolution algorithm will result in IP address, port, tag, and protocol tuples listed in Table 1.
以下の例では、ドメイン "example.net"の場合、解決アルゴリズムは表1にリストされているIPアドレス、ポート、タグ、およびプロトコルタプルをもたらします。
example.net. IN NAPTR 100 10 "" DOTS:signal.udp "" signal.example.net. IN NAPTR 200 10 "" DOTS:signal.tcp "" signal.example.net. IN NAPTR 300 10 "" DOTS:data.tcp "" data.example.net.
例.net。NAPTR 100 10 "" "" "" "" "Signal.udp" "Signal.example.net。NAPTR 200 10 "" "" "" "" "" Signal.tcp "" Signal.example.net。NAPTR 300 10 "" "dots：data.tcp" "data.example.net。
signal.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.
signal.example.net。NAPTR 100 10 "" dots：signal.udp "" _dots-signal._udp.example.net。NAPTR 200 10 "" "" "dots：signal.tcp" "_dots-signal._tcp.example.net。
data.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.
data.example.net。NAPTR 100 10 "" "" dots：data.tcp "" _dots-data._tcp.example.net。NAPTR 200 10 "" "dots：data.tcp" "b.example.net。
_dots-signal._udp.example.net. IN SRV 0 0 5000 a.example.net.
_dots-signal._udp.example.net。SRV 0 0 5000 A.example.net
_dots-signal._tcp.example.net. IN SRV 0 0 5001 a.example.net.
_dots-signal._tcp.example.net。SRV 0 0 5001 A.example.net。
_dots-data._tcp.example.net. IN SRV 0 0 5002 a.example.net.
_dots-data._tcp.example.net。SRV 0 0 5002 A.example.netで。
a.example.net. IN AAAA 2001:db8::1
a.example.net。AAAA 2001：DB8 :: 1
b.example.net. IN AAAA 2001:db8::2
b.example.net。AAAA 2001：DB8 :: 2
Figure 8: Example of Discovery of DOTS Servers Using Service Resolution
図8：サービス解決を用いたドットサーバの発見例
+=======+==========+=============+======+========+
| Order | Protocol | IP address | Port | Tag |
+=======+==========+=============+======+========+
| 1 | UDP | 2001:db8::1 | 5000 | Signal |
+-------+----------+-------------+------+--------+
| 2 | TCP | 2001:db8::1 | 5001 | Signal |
+-------+----------+-------------+------+--------+
| 3 | TCP | 2001:db8::1 | 5002 | Data |
+-------+----------+-------------+------+--------+
| 4 | TCP | 2001:db8::2 | 443 | Data |
+-------+----------+-------------+------+--------+
Table 1: Resolution Results
表1：解決結果
An example is provided in Figure 9 for the Call Home case. In this example, the resolution algorithm will result in IP address, port, and protocol tuples listed in Table 2 for domain "example.net".
呼び出しホームケースについては、図9に例を示します。この例では、解決アルゴリズムは、ドメイン "example.net"の表2にリストされているIPアドレス、ポート、およびプロトコルタプルをもたらします。
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.
例.net。NAPTR 100 10 "" "" "" "DOTS-Call-Home：signal.udp" "Signal.example.net。NAPTR 200 10 "" "" dots-call-home：signal.tcp "" signal.example.net。
signal.example.net. IN NAPTR 100 10 "s" DOTS-CALL-HOME:signal.udp "" _dots-call-home._udp.example.net. IN NAPTR 200 10 "s" DOTS-CALL-HOME:signal.tcp "" _dots-call-home._tcp.example.net.
signal.example.net。NAPTR 100 10 "" "dots-call-home：signal.udp" "_dots-call-home._udp.example.net。NAPTR 200 10 "" dots-call-home：signal.tcp "" _dots-call-home._tcp.example.net。
_dots-call-home._udp.example.net. IN SRV 0 0 6000 b.example.net.
_dots-call-home._udp.example.net。SRV 0 0 6000 B.example.net。
_dots-call-home._tcp.example.net. IN SRV 0 0 6001 b.example.net.
_dots-call-home._tcp.example.net。SRV 0 0 6001 B.example.net。
b.example.net. IN AAAA 2001:db8::2
b.example.net。AAAA 2001：DB8 :: 2
Figure 9: Example of Discovery of DOTS Call Home Client Using Service Resolution
図9：サービス解決を使用したドットコールホームクライアントの発見の例
+=======+==========+=============+======+
| Order | Protocol | IP address | Port |
+=======+==========+=============+======+
| 1 | UDP | 2001:db8::2 | 6000 |
+-------+----------+-------------+------+
| 2 | TCP | 2001:db8::2 | 6001 |
+-------+----------+-------------+------+
Table 2: Resolution Results (Call Home)
表2：解決結果（home home）
Note that customized port numbers are used for the DOTS signal channel, DOTS data channel, and DOTS signal channel Call Home in the examples shown in Figures 8 and 9 for illustration purposes. If default port numbers are used in a deployment, the discovery procedure will return 4646 (DOTS signal channel) and 443 (DOTS data channel) as DOTS service port numbers.
なお、図8および図9に示す実施例では、図8および図9に示すように、カスタマイズされたポート番号がドット信号チャネル、ドットデータチャネル、およびドット信号チャネルコールホームに使用されることに留意されたい。デフォルトのポート番号がデプロイメントで使用されている場合、検出手順はドットサービスポート番号として4646（ドット信号チャネル）と443（ドットデータチャネル）を返します。
If no DOTS-specific S-NAPTR records can be retrieved, the discovery procedure fails for this domain name (and the corresponding interface and IP protocol version). If more domain names are known, the discovery procedure MAY perform the corresponding S-NAPTR lookups immediately. However, before retrying a lookup that has failed, a DOTS client MUST wait a time period that is appropriate for the encountered error (e.g., NXDOMAIN, timeout, etc.).
ドット固有のS-NAPTRレコードを取得できない場合、検出手順はこのドメイン名（および対応するインタフェースおよびIPプロトコルバージョン）に対して失敗します。より多くのドメイン名が既知である場合、検出手順はすぐに対応するS-NAPTRルックアップを実行することができる。ただし、失敗したルックアップを再試行する前に、ドットクライアントは、検出されたエラー（例えば、NXDomain、Timeoutなど）に適した期間を待つ必要があります。
DNS-based Service Discovery (DNS-SD) [RFC6763] provides generic solutions for discovering services. DNS-SD defines a set of naming rules for certain DNS record types that they use for advertising and discovering services.
DNSベースのサービス発見（DNS-SD）[RFC6763]は、サービスを発見するための一般的なソリューションを提供します。DNS-SDは、サービスと検出サービスに使用する特定のDNSレコードタイプの命名規則のセットを定義します。
Section 4.1 of [RFC6763] specifies that a service instance name in DNS-SD has the following structure:
[RFC6763]のセクション4.1は、DNS-SDのサービスインスタンス名に次の構成があることを指定します。
<Instance> . <Service> . <Domain>
The <Domain> portion specifies the DNS subdomain where the service instance is registered. It is a conventional domain name, such as "example.com".
<domain>部分は、サービスインスタンスが登録されているDNSサブドメインを指定します。「example.com」などの従来のドメイン名です。
The <Service> portion of the DOTS service instance name MUST be "_dots-signal._udp", "_dots-signal._tcp", "_dots-data._tcp", "_dots-call-home._udp", or "_dots-call-home._tcp".
ドットサービスインスタンス名の<service>部分は、 "_dots-signal._udp"、 "_dots-signal._tcp"、 "_dots-data._tcp"、 "_dots-call-home._udp"、または "_dotsです。-call-home._tcp "。
This document does not define any keys; the TXT record of a DNS-SD service is thus empty (Section 6 of [RFC6763]).
この文書はキーを定義しません。したがって、DNS-SDサービスのTXTレコードが空です（[RFC6763]のセクション6）。
Figure 10 depicts an excerpt of the DNS zone configuration file listing record examples to discover two DOTS signal channel servers. In this example, only UDP is supported as transport for the establishment of the DOTS signal channel.
図10は、DNSゾーン構成ファイル一覧記録例の抜粋を示しており、2つのドット信号チャネルサーバを検出する。この例では、ドット信号チャネルを確立するためのトランスポートとしてUDPのみがサポートされている。
_dots-signal._udp.example.net. PTR a._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. b._dots-signal._udp.example.net. SRV 0 0 4646 b.example.net. a._dots-signal._udp.example.net. TXT "" b._dots-signal._udp.example.net. TXT ""
_dots-signal._udp.example.net。PTR A._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。B._dots-signal._udp.example.net。SRV 0 0 4646 B.example.net。a._dots-signal._udp.example.net。txt "" b._dots-signal._udp.example.net。TXT ""
Figure 10: An Example of DNS-SD Records for the UDP DOTS Signal Channel Involving Two Servers with the Same Priority
図10：同じ優先順位を持つ2つのサーバーを含むUDPドット信号チャネルのDNS-SDレコードの例
DOTS-related security considerations are discussed in Section 5 of [RFC8811]. As a reminder, DOTS agents must authenticate each other using (D)TLS before a DOTS session is considered valid according to the [RFC8782].
ドット関連のセキュリティ上の考慮事項については、[RFC8811]のセクション5で説明します。リマインダとして、ドットエージェントは、ドットセッションが[RFC8782]に従って有効であると見なされる前に（D）TLSを使用して互いを認証しなければなりません。
An attacker may block some protocol messages (e.g., DHCP) to force the client to use a discovery mechanism with a lower priority. The security implications of such attack are those inherent to the fallback discovery mechanism discussed in the following subsections.
攻撃者は、クライアントにより低い優先順位を持つ発見メカニズムを使用するように強制するために、プロトコルメッセージ（例えばDHCP）をブロックすることができる。そのような攻撃のセキュリティへの影響は、以下のサブセクションで議論された秋の発見メカニズムに固有のものです。
The results of the discovery procedure are a function of the interface/address family. Contacting a discovered DOTS server via an 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 service is enabled by a DOTS client domain and exposes the identity of the DOTS service provider (which can be inferred from the name and the destination IP address) to external networks.
検出手順の結果は、インターフェース/アドレスファミリの機能です。検出されたドットサーバーをバインドされていないインターフェイスを介して連絡しても、ドットチャネルを確立するのに必要な遅延を悪化させる可能性があります。さらに、そのような動作は、ドットサービスがドットクライアントドメインによって有効にされ、ドットサービスプロバイダ（名前および宛先IPアドレスから推測することができる）のIDを外部ネットワークに公開することを明らかにし得る。
Security considerations related to how security credentials to authenticate DOTS server(s) are provisioned to a DOTS client are those inherent to the mechanism used for that purpose (for example, see [RFC8572]).
セキュリティ上の考慮事項ドットサーバーを認証するためのセキュリティ認証情報がドットクライアントにプロビジョニングされる方法に関連するものは、その目的に使用されるメカニズムに固有のものです（たとえば、[RFC8572]を参照）。
The security considerations in [RFC2131] and [RFC8415] are to be considered. In particular, issues related to rogue DHCP servers and means to mitigate many of these attacks are discussed in Section 22 of [RFC8415].
[RFC2131]と[RFC8415]のセキュリティ上の考慮事項を考慮する必要があります。特に、これらの攻撃の多くを軽減するための不正なDHCPサーバーに関連する問題については、[RFC8415]のセクション22で説明されています。
An attacker can get a domain name, get a domain-validated public certificate from a certification authority (CA), and host a DOTS agent. An active attacker can then spoof DHCP responses to include the attacker's DOTS agent. Such an attacker can also launch other attacks, as discussed in Section 22 of [RFC8415]. In addition to the mitigations listed in Section 22 of [RFC8415], a DOTS 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 agent has to check that the "DNS-ID" identifier type within subjectAltName in the server certificate matches a preconfigured 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 a DHCP-discovered name that matches a name in the preconfigured list (e.g., "dots-1.example.com" or "dots-2.example.com").
攻撃者はドメイン名を取得し、証明機関（CA）からドメイン検証済みの公開証明書を取得し、ドットエージェントをホストすることができます。アクティブな攻撃者は、攻撃者のドットエージェントを含めることを可能にすると、その後のDHCPの反応を偽装することができます。[RFC8415]のセクション22で説明したように、そのような攻撃者は他の攻撃を発売することもできます。[RFC8415]のセクション22にリストされている軽減に加えて、ドットエージェントは信頼できるドットドメイン名のリストで事前設定されてもよい。そのようなリストが事前設定されている場合、ドットエージェントはそのリスト内の名前と一致する場合はDHCP-Discovered Nameを受け入れます。また、ドットエージェントは、サーバー証明書のSubjectalTName内の「DNS-ID」識別子タイプが事前設定された名前と一致することを確認する必要があります。ドットエージェントがそのリスト内の名前のサブドメインを信頼するように指示されている場合（たとえば、 "* .example.com"）、ドットエージェントは事前設定リスト内の名前と一致するDHCP-Discoveredの名前を受け入れます（例："dots-1.example.com"または "dots-2.example.com"）。
Relying on an underlying resolution library to resolve a supplied reference identifier has similar security issues as those discussed in Section 8.2 (e.g., an active attacker may modify DNS messages used to resolve the supplied reference identifier and point the client to an attacker server).
供給されたリファレンス識別子を解決するために基礎となる解像度ライブラリに依存している（例えば、アクティブな攻撃者は、提供された参照識別子を解決し、クライアントを攻撃者サーバにポイントするために使用されるDNSメッセージを変更することができる）。
Supplying both an IP address and the reference identifier makes it easier to use a mis-issued certificate.
IPアドレスと参照識別子の両方を供給すると、誤発行された証明書を使いやすくなります。
The primary attack against the methods described in Section 6 is one that would lead to impersonation of a peer DOTS agent. An attacker could attempt to compromise the S-NAPTR resolution.
セクション6に記載されている方法に対する一次攻撃は、ピアトドットエージェントの偽装につながるものである。攻撃者はS-NAPTRの解決を損なうことを試みる可能性があります。
The DOTS client (or a Call Home DOTS server) constructs one reference identifier for the DOTS server (or a Call Home DOTS client) 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 [RFC6125]) in the PKIX certificate's subjectAltName extension, the DOTS client should accept the certificate for the server.
ドットクライアント（またはコールホームドットサーバ）は、S - NAPTRルックアップに使用されるドメイン名に基づいて、ドットサーバ（またはコールホームドットクライアント）の1つの参照識別子を構成します.DNS-ID。PKIX証明書のSubjectLatName拡張子内の参照識別子が見つかった場合（[RFC6125のセクション6の[RFC6125]のセクションで説明されているように）場合、ドットクライアントはサーバーの証明書を受け入れる必要があります。
DNS Security Extensions (DNSSEC) [RFC4033] uses cryptographic keys and digital signatures to provide authentication of DNS data. The information that is retrieved from the S-NAPTR lookup and that is validated using DNSSEC is thereby proved to be the authoritative data.
DNS Security Extensions（DNSSEC）[RFC4033]は、暗号化キーとデジタル署名を使用してDNSデータの認証を提供します。S-NAPTR検索から取得され、DNSSECを使用して検証された情報は、それによって権限のあるデータであることが証明されています。
Since DNS-SD is a specification for how to name and use records in the existing DNS system, it has no specific additional security requirements over and above those that already apply to DNS queries and DNS updates. For DNS queries, DNSSEC SHOULD be used where the authenticity of information is important. For DNS updates, secure updates [RFC2136] [RFC3007] SHOULD generally be used to control which clients have permission to update DNS records.
DNS-SDは既存のDNSシステムでレコードの名前と使用方法の指定であるため、すでにDNSクエリやDNSの更新に適用されているもの以上の特定の追加のセキュリティ要件はありません。DNSクエリの場合、情報の信頼性が重要な場合はDNSSECを使用する必要があります。DNSの更新の場合、Secure Updates [RFC2136] [RFC3007] [RFC3007]は一般に、どのクライアントにDNSレコードを更新する権限があるかを制御する必要があります。
Note that means such as DNS over TLS (DoT) [RFC7858] or DNS over HTTPS (DoH) [RFC8484] can be used to prevent eavesdroppers from accessing DNS messages.
TLS（DOT）[RFC7858]またはHTTPS（DOH）[RFC8484]を介したDNS（DOH）[RFC8484]などの手段を使用して、盗聴者がDNSメッセージにアクセスできないようにすることができます。
IANA has allocated the following service names from the registry available at: <https://www.iana.org/assignments/service-names-port-numbers/>.
IANAは、<https：//www.iana.org/assignments/service-names-port-numbers/>で利用可能なレジストリから次のサービス名を割り当てました。
Service Name: dots-data
Port Number: N/A
Transport Protocol(s): TCP
Description: DOTS Data Channel Protocol. The service
name is used to construct the SRV service
name "_dots-data._tcp" for discovering DOTS
servers used to establish DOTS data channel.
Assignee: IESG: iesg@ietf.org
Contact: IETF Chair: chair@ietf.org
Reference: [RFC8973]
Service Name: dots-call-home Transport Protocol(s): TCP/UDP Description: DOTS Signal Channel Call Home Protocol. The service name is used to construct the SRV service names "_dots-call-home._udp" and "_dots-call-home._tcp" for discovering Call Home DOTS clients used to establish DOTS signal channel Call Home. Assignee: IESG: iesg@ietf.org Contact: IETF Chair: chair@ietf.org Reference: [RFC8973]
サービス名：ドットコールホームトランスポートプロトコル：TCP / UDP説明：ドット信号チャネル呼び出しホームプロトコル。サービス名は、ドット信号チャネル呼び出しホームを確立するために使用されるコールホームドットクライアントを検出するためのSRVサービス名「_dots-call-home._udp」および「_dots-call-home._tcp」を構築するために使用されます。譲受人：IESG：IESG@IETF.ORG連絡先：IETF議長：議長@IETF.ORGリファレンス：[RFC8973]
IANA has updated the following entry from the registry available at: <https://www.iana.org/assignments/service-names-port-numbers/>.
IANAは、<https：//www.iana.org/assignments/service-names-port-numbers/>で利用可能なレジストリから次のエントリを更新しました。
Port Number: 4646
Transport Protocol(s): TCP/UDP
Description: DOTS Signal Channel Protocol. The service
name is used to construct the SRV service
names "_dots-signal._udp" and "_dots-
signal._tcp" for discovering DOTS servers
used to establish DOTS signal channel.
Assignee: IESG: iesg@ietf.org
Contact: IETF Chair: chair@ietf.org
Reference: [RFC8782][RFC8973]
IANA has assigned the following new DHCPv6 Option Codes in the registry maintained in <https://www.iana.org/assignments/ dhcpv6-parameters/>.
IANAには、<https：//www.iana.org/ashignments/dhcpv6-parameters />に維持されているレジストリに、次の新しいDHCPv6オプションコードが割り当てられています。
+=======+========================+============+==================+
| Value | Description | Client ORO | Singleton Option |
+=======+========================+============+==================+
| 141 | OPTION_V6_DOTS_RI | Yes | Yes |
+-------+------------------------+------------+------------------+
| 142 | OPTION_V6_DOTS_ADDRESS | Yes | Yes |
+-------+------------------------+------------+------------------+
Table 3: DHCPv6 Options
表3：DHCPv6オプション
IANA has assigned the following new DHCPv4 Option Codes in the registry maintained in <https://www.iana.org/assignments/bootp-dhcp-parameters/>.
IANAには、<https：//www.iana.org/ashignments/bootp-dhcp-parameters/>に維持されているレジストリに、次の新しいDHCPv4オプションコードが割り当てられています。
+========================+=====+=========+==============+===========+
| Name | Tag | Data | Meaning | Reference |
| | | Length | | |
+========================+=====+=========+==============+===========+
| OPTION_V4_DOTS_RI | 147 | N | The name | [RFC8973] |
| | | | of the | |
| | | | peer DOTS | |
| | | | agent. | |
+------------------------+-----+---------+--------------+-----------+
| OPTION_V4_DOTS_ADDRESS | 148 | N (the | N/4 IPv4 | [RFC8973] |
| | | minimal | addresses | |
| | | length | of peer | |
| | | is 4) | DOTS | |
| | | | agent(s). | |
+------------------------+-----+---------+--------------+-----------+
Table 4: DHCPv4 Options
表4：DHCPv4オプション
IANA has made the following allocations from the registries available at <https://www.iana.org/assignments/s-naptr-parameters/> for application service tags and application protocol tags.
IANAは、<https://www.iana.org/assignments/s-naptr-parameters/>で利用可能なレジストリから次の割り当てを行いました。
Application Service Tag: DOTS Intended Usage: See Section 6 Security Considerations: See Section 8 Interoperability Considerations: None Relevant Publications: RFC 8973
アプリケーションサービスタグ：ドット対象使用方法：セクション6セキュリティ上の考慮事項を参照してください。セクション8の相互運用性に関する考慮事項：なし関連出版物：RFC 8973
Application Service Tag: DOTS-CALL-HOME Intended Usage: See Section 6 Security Considerations: See Section 8 Interoperability Considerations: None Relevant Publications: RFC 8973
アプリケーションサービスタグ：ドットコールホームの使用方法：セクション6セキュリティ上の考慮事項：セクション8の相互運用性に関する考慮事項：なし関連出版物：RFC 8973
Application Protocol Tag: signal.udp Intended Usage: See Section 6 Security Considerations: See Section 8 Interoperability Considerations: None Relevant Publications: RFC 8973
アプリケーションプロトコルタグ：signal.udpの使用方法：セクション6セキュリティ上の考慮事項を参照してください.8つの相互運用性に関する考慮事項を参照してください。
Application Protocol Tag: signal.tcp Intended Usage: See Section 6 Security Considerations: See Section 8 Interoperability Considerations: None Relevant Publications: RFC 8973
アプリケーションプロトコルタグ：Signal.TCPの使用法：セクション6セキュリティ上の考慮事項：セクション8の相互運用性に関する考慮事項を参照してください。関連出版物：RFC 8973
Application Protocol Tag: data.tcp Intended Usage: See Section 6 Security Considerations: See Section 8 Interoperability Considerations: None Relevant Publications: RFC 8973
アプリケーションプロトコルタグ：data.tcpの使用法：セクション6セキュリティ上の考慮事項：セクション8の相互運用性に関する考慮事項：なし関連出版物：RFC 8973
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131] DROMS、R.、「動的ホスト構成プロトコル」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https：//www.rfc-editor.org/info/rfc2131>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <https://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S.およびR.ROMS、「DHCPオプションおよびBOOTPベンダー拡張」、RFC 2132、DOI 10.17487 / RFC2132、1997年3月、<https：//www.rfc-editor.org/info/rfc2132>。
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, DOI 10.17487/RFC3396, November 2002, <https://www.rfc-editor.org/info/rfc3396>.
[RFC3396]レモン、T.およびS.チェシャー、「動的ホスト構成プロトコル（DHCPv4）」、RFC 3396、DOI 10.17487 / RFC3396、2002年11月、<https://www.rfc-editor.org/ info / rfc3396>。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, January 2005, <https://www.rfc-editor.org/info/rfc3958>.
[RFC3958] Daigle、L.およびA.ニュートン、「SRV RRSおよび動的委任発見サービスを使用したドメインベースのアプリケーションサービスの場所（DDDS）」、RFC 3958、DOI 10.17487 / RFC3958、2005年1月、<HTTPS：// WWW.rfc-editor.org / info / rfc3958>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//www.rfc-editor.org/info/rfc4291>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S.およびM. Krochmal、「DNSベースのサービス発見」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https：//www.rfc-editor.org/info/rfc6763>。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <https://www.rfc-editor.org/info/rfc6890>.
[RFC6890]綿、M.、Vegoda、L.、Boicha、R.、Ed。、B. Haberman、BCP 153、RFC 6890、DOI 10.17487 / RFC6890、2013年4月、<https://www.rfc-editor.org/info/rfc6890>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[BTSRP-KEYINFR] Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. H., and K. Watsen, "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Work in Progress, Internet-Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11 November 2020, <https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-45>.
[BTSRP-Keyinfr]プリチキン、M.、Richardson、MC、Eckert、T.、Behringer、MH、およびK。Watsen、「ブートストラップリモートセキュリティ鍵インフラ（Brski）」、進行中の作業、インターネットドラフト、ドラフトIETF-anima-bootstrapping-keyinfra-45、2020年11月11日、<https：//tools.ietf.org/html/draft-ietf-anima-bootstrapp-keyInfra-45>。
[DOTS-MULTIHOMING] Boucadair, M., Reddy, T., and W. Pan, "Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)", Work in Progress, Internet-Draft, draft-ietf-dots-multihoming-05, 23 November 2020, <https://tools.ietf.org/html/draft-ietf-dots-multihoming-05>.
[DOT-MULTIHOMING] Boucadair、M.、Reddy、T.、およびW. Pan、「配布サービス拒否開放シグナル伝達（ドット）」の「マルチホーミング展開に関する考慮事項」、進行中の作業、インターネットドラフト、Doft-IETF-DOTS-MULTIHOMING-05,2020、<https://tools.ietf.org/html/draft-ietf-dots-multihoming-05>
[DOTS-SIG-CALL-HOME] Reddy, T., Boucadair, M., and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home", Work in Progress, Internet-Draft, draft-ietf-dots-signal-call-home-13, 11 January 2021, <https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-13>.
[DOTS-SIG-CALL-HOME] Reddy、T.、Boucadair、M.、J. Shallow、「配布サービス拒否オープン脅威シグナリング（ドット）信号チャネルコールホーム」、進行中の作業、インターネットドラフト、ドラフト-IETF-dots-signal-home-13,2021、<https：//tools.ietf.org/html/draft-ietf-dots-signal-call-home-13>。
[DOTS-USE-CASES] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat Signaling", Work in Progress, Internet-Draft, draft-ietf-dots-use-cases-25, 5 July 2020, <https://tools.ietf.org/html/draft-ietf-dots-use-cases-25>.
[ドットユースケース]ドビンズ、R.、Migault、D.、Moskowitz、R.、Teague、N.、Xia、L.、K。西塚、「DDOSオープン脅威シグナル伝達のためのユースケース」、進行中の作業、インターネットドラフト、ドラフト - IETF - DOTS-expe-ecase-25,25,57月5日、<https：//tools.ietf.org/html/draft-ietf-dots-use-cases-25>。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <https://www.rfc-editor.org/info/rfc2136>.
[RFC2136] Vixie、P.、ED。、Thomson、S.、Rekhter、Y.、J.Bound、「ドメイン名システム（DNSアップデート）の動的更新（DNSアップデート）」、RFC 2136、DOI 10.17487 / RFC2136、1997年4月<https://www.rfc-editor.org/info/rfc2136>。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, DOI 10.17487/RFC3007, November 2000, <https://www.rfc-editor.org/info/rfc3007>.
[RFC3007]ウェリントン、B.、「セキュアドメインネームシステム（DNS）動的更新」、RFC 3007、DOI 10.17487 / RFC3007、2000年11月、<https：//www.rfc-editor.org/info/rfc3007>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ紹介および要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https：//www.rfc-editor.org/info/rfc4033>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Transport Layer Security（TLS）のコンテキストでのX.509（PKIX）証明書を使用したInternet Publicキーインフラストラクチャ内のインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証の表現と検証RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC7858] HU、Z.、Zhu、L.、Heidemann、J.、Mankin、A.、Wessels、D.、およびP.HOFFMAN、「トランスポート層セキュリティ（TLS）のDNSの仕様（TLS）」、RFC 7858、DOI10.17487 / RFC7858、2016年5月、<https://www.rfc-editor.org/info/rfc7858>。
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, <https://www.rfc-editor.org/info/rfc8484>.
[RFC8484] HOFFMAN、P.およびP.Mcmanus、「HTTPS経由のDNSクエリ（DOH）」、RFC 8484、DOI 10.17487 / RFC8484、2018年10月、<https：//www.rfc-editor.org/info/rfc8484>。
[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero Touch Provisioning (SZTP)", RFC 8572, DOI 10.17487/RFC8572, April 2019, <https://www.rfc-editor.org/info/rfc8572>.
[RFC8572] Watsen、K.、Farrer、I.、およびM.Abrahamsson、「Secure The Touch Provisioning（SZTP）」、RFC 8572、DOI 10.17487 / RFC8572、2019年4月、<https：//www.rfc-編集者。ORG / INFO / RFC8572>。
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., Mortensen, A., and N. Teague, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, <https://www.rfc-editor.org/info/rfc8782>.
[RFC8782] Reddy.K、T.、ED。、Boucadair、M.、Ed。、Patil、P.、Mortensen、A.、およびN. TeaGue、 "Distribe Service Open Threatシグナリング（ドット）信号Channel Specification "、RFC 8782、DOI 10.17487 / RFC8782、2020年5月、<https：//www.rfc-editor.org/info/rfc8782>。
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification", RFC 8783, DOI 10.17487/RFC8783, May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[RFC8783] Boucadair、M.、Ed。そして、「分散サービス拒否オープン脅威シグナル伝達（ドット）データチャネル仕様」、RFC 8783、DOI 10.17487 / RFC8783、<https：//www.rfc-編集者。ORG / INFO / RFC8783>。
[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F., Teague, N., and R. Compton, "DDoS Open Threat Signaling (DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811, August 2020, <https://www.rfc-editor.org/info/rfc8811>.
[RFC8811] Mortensen、A.、ED。、Reddy.K、T.、ED。、Andreasen、F.、Teague、N.、R. Compton、DDOSオープン脅威シグナル伝達（ドット）アーキテクチャ "、RFC 8811、DOI 10.17487 / RFC8811、2020年8月、<https://www.rfc-editor.org/info/rfc8811>。
Acknowledgements
謝辞
Thanks to Brian Carpenter for the review of the Bootstrapping Remote Secure Key Infrastructure (BRSKI) text used in previous draft versions of the specification.
ブートストラップリモートセキュアキーインフラストラクチャ（Brski）テキストのレビューのためにBrian Carpenterに感謝します。
Many thanks to Russ White for the review, comments, and text contribution.
レビュー、コメント、テキストの貢献のためにラスホワイトに感謝します。
Thanks to Dan Wing, Pei Wei, Valery Smyslov, and Jon Shallow for the review and comments.
Dan Wing、Pei Wei、Valery Smyslov、Jon Shallowのおかげで、レビューやコメントに感謝します。
Thanks to Bernie Volz for the review of the DHCP section.
DHCPセクションのレビューのためにBernie Volzのおかげで。
Many thanks to Benjamin Kaduk for the detailed AD review.
詳細な広告レビューのためにBenjamin Kadukに感謝します。
Thanks to Zhen Cao, Kyle Rose, Nagendra Nainar, and Peter Yee for the directorate reviews.
Zhen Cao、Kyle Rose、Nagendra Nainar、Peter Yeeのおかげで議長のレビューに感謝します。
Thanks to Barry Leiba, Martin Duke, Roman Danyliw, Éric Vyncke, and Magnus Westerlund for the IESG review.
Barry Leiba、Martin Duke、Roman Danyliw、Eric Vyncke、およびMagnus WesterlundのためのIESGレビューのおかげでください。
Contributors
貢献者
Prashanth Patil Cisco Systems, Inc.
Prashanth Patil Cisco Systems、Inc。
Email: praspati@cisco.com
Authors' Addresses
著者の住所
Mohamed Boucadair Orange 35000 Rennes France
Mohamed Boucadair Orange 35000 Rennesフランス
Email: mohamed.boucadair@orange.com
Tirumaleswar Reddy.K McAfee, Inc. Embassy Golf Link Business Park Bangalore 560071 Karnataka India
Tirumaleswar Reddy.k McAfee、Inc。大使館ゴルフリンクビジネスパークバンガロール560071カルナタカインド
Email: TirumaleswarReddy_Konda@McAfee.com