[要約] RFC 8801は、ネットワーク内のプロビジョニングドメイン名とデータを発見するための手法を定義しています。このRFCの目的は、ネットワーク内のデバイスが自身のプロビジョニングドメイン名を特定し、適切なサービスを利用できるようにすることです。
Internet Engineering Task Force (IETF) P. Pfister
Request for Comments: 8801 É. Vyncke
Category: Standards Track Cisco
ISSN: 2070-1721 T. Pauly
Apple Inc.
D. Schinazi
Google LLC
W. Shao
Cisco
July 2020
Discovering Provisioning Domain Names and Data
プロビジョニングドメイン名とデータの検出
Abstract
概要
Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider.
プロビジョニングドメイン（PvD）は、一貫したネットワーク構成情報のセットとして定義されます。 PvDを使用すると、ホームルーターがブロードバンドプロバイダーとセルラーネットワークプロバイダーの両方を介して接続を提供する場合など、ホストが複数のネットワークとインターフェイスへの接続を同時に管理できます。
This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate between PvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS.
このドキュメントでは、ルーターアドバタイズ（RA）オプションを使用してPvDを明示的に識別するメカニズムを定義します。このRAオプションは、ホストがPvDを区別するために比較できるPvD識別子を通知します。このオプションは、PvDに関するいくつかの情報を直接運ぶことができ、オプションで、HTTP over TLSを使用して取得できるPvD追加情報をポイントできます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。これは公開レビューを受けており、Internet Engineering Steering Group（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/rfc8801.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8801で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Specification of Requirements
2. Terminology
3. Provisioning Domain Identification Using Router Advertisements
3.1. PvD Option for Router Advertisements
3.2. Router Behavior
3.3. Non-PvD-Aware Host Behavior
3.4. PvD-Aware Host Behavior
3.4.1. DHCPv6 Configuration Association
3.4.2. DHCPv4 Configuration Association
3.4.3. Connection Sharing by the Host
3.4.4. Usage of DNS Servers
4. Provisioning Domain Additional Information
4.1. Retrieving the PvD Additional Information
4.2. Operational Consideration to Providing the PvD Additional
Information
4.3. PvD Additional Information Format
4.3.1. Example
4.4. Detecting Misconfiguration and Misuse
5. Operational Considerations
5.1. Exposing Extra RA Options to PvD-Aware Hosts
5.2. Different RAs for PvD-Aware and Non-PvD-Aware Hosts
5.3. Enabling Multihoming for PvD-Aware Hosts
5.4. Providing Additional Information to PvD-Aware Hosts
6. Security Considerations
7. Privacy Considerations
8. IANA Considerations
8.1. Change to IPv6 Neighbor Discovery Option Formats Registry
8.2. New Entry in the Well-Known URIs Registry
8.3. New Additional Information PvD Keys Registry
8.4. New PvD Option Flags Registry
8.5. PvD JSON Media Type Registration
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
Provisioning Domains (PvDs) are defined in [RFC7556] as consistent sets of network configuration information. This information includes properties that are traditionally associated with a single networking interface, such as source addresses, DNS configuration, proxy configuration, and gateway addresses.
プロビジョニングドメイン（PvD）は、一貫したネットワーク構成情報のセットとして[RFC7556]で定義されています。この情報には、送信元アドレス、DNS構成、プロキシ構成、ゲートウェイアドレスなど、従来は単一のネットワークインターフェイスに関連付けられていたプロパティが含まれます。
Clients that are aware of PvDs can take advantage of multiple network interfaces simultaneously. This enables using two PvDs in parallel for separate connections or for multi-path transports.
PvDを認識するクライアントは、複数のネットワークインターフェイスを同時に利用できます。これにより、別々の接続またはマルチパストランスポートに2つのPvDを並行して使用できます。
While most PvDs today are discovered implicitly (such as by receiving information via Router Advertisements from a router on a network that a client host directly connects to), [RFC7556] also defines the notion of Explicit PvDs. IPsec Virtual Private Networks are considered Explicit PvDs, but Explicit PvDs can also be discovered via the local network router. Discovering Explicit PvDs allows two key advancements in managing multiple PvDs:
今日のほとんどのPvDは暗黙的に発見されますが（クライアントホストが直接接続するネットワーク上のルーターからルーターアドバタイズを介して情報を受信するなど）、[RFC7556]は明示的なPvDの概念も定義します。 IPsecバーチャルプライベートネットワークは明示的なPvDと見なされますが、明示的なPvDはローカルネットワークルーターを介して検出することもできます。明示的なPvDを検出すると、複数のPvDを管理する上で2つの重要な進歩が可能になります。
1. The ability to discover and use multiple PvDs on a single interface, such as when a local router can provide connectivity to two different Internet Service Providers.
1. ローカルルーターが2つの異なるインターネットサービスプロバイダーへの接続を提供できる場合など、単一のインターフェイスで複数のPvDを検出して使用する機能。
2. The ability to associate Additional Information about PvDs to describe the properties of the network.
2. PvDに関する追加情報を関連付けてネットワークのプロパティを説明する機能。
While [RFC7556] defines the concept of Explicit PvDs, it does not define the mechanism for discovering multiple Explicit PvDs on a single network and their Additional Information.
[RFC7556]は明示的なPvDの概念を定義していますが、単一のネットワーク上の複数の明示的なPvDとそれらの追加情報を検出するメカニズムは定義していません。
This document specifies a way to identify PvDs with Fully Qualified Domain Names (FQDNs), called PvD IDs. Those identifiers are advertised in a new Router Advertisement (RA) [RFC4861] option called the PvD Option, which, when present, associates the PvD ID with all the information present in the Router Advertisement as well as any configuration object, such as addresses, derived from it. The PvD Option may also contain a set of other RA options, along with an optional inner Router Advertisement message header. These options and optional inner header are only visible to 'PvD-aware' hosts, allowing such hosts to have a specialized view of the network configuration.
このドキュメントでは、PvD IDと呼ばれる完全修飾ドメイン名（FQDN）でPvDを識別する方法を指定します。これらの識別子は、PvDオプションと呼ばれる新しいルーターアドバタイズメント（RA）[RFC4861]オプションでアドバタイズされます。このオプションは、存在する場合、PvD IDをルーターアドバタイズメントに存在するすべての情報とアドレスなどの構成オブジェクトに関連付けます。それから派生した。 PvDオプションには、オプションの内部ルーターアドバタイズメッセージヘッダーと共に、他のRAオプションのセットも含まれる場合があります。これらのオプションとオプションの内部ヘッダーは「PvD対応」ホストにのみ表示され、そのようなホストがネットワーク構成の特殊なビューを持つことができます。
Since PvD IDs are used to identify different ways to access the Internet, multiple PvDs (with different PvD IDs) can be provisioned on a single host interface. Similarly, the same PvD ID could be used on different interfaces of a host in order to inform that those PvDs ultimately provide equivalent services.
PvD IDはインターネットにアクセスするさまざまな方法を識別するために使用されるため、複数のPvD（異なるPvD IDを持つ）を単一のホストインターフェイスでプロビジョニングできます。同様に、同じPvD IDをホストの異なるインターフェイスで使用して、それらのPvDが最終的に同等のサービスを提供することを通知できます。
This document also introduces a mechanism for hosts to retrieve optional Additional Information related to a specific PvD by means of an HTTP-over-TLS query using a URI derived from the PvD ID. The retrieved JSON object contains Additional Information that would typically be considered too large to be directly included in the Router Advertisement but might be considered useful to the applications, or even sometimes users, when choosing which PvD should be used.
このドキュメントでは、PvD IDから派生したURIを使用したHTTP-over-TLSクエリによって、ホストが特定のPvDに関連するオプションの追加情報を取得するためのメカニズムも紹介します。取得したJSONオブジェクトには追加情報が含まれていますが、これらは通常、ルーターアドバタイズに直接含めるには大きすぎると見なされますが、使用するPvDを選択するときに、アプリケーション、または場合によってはユーザーにとっても役立つと考えられます。
For example, if Alice has both a cellular network provider and a broadband provider in her home, her PvD-aware devices and applications would be aware of both available uplinks. These applications could fail-over between these networks or run connections over both (potentially using multi-path transports). Applications could also select specific uplinks based on the properties of the network; for example, if the cellular network provides free high-quality video streaming, a video-streaming application could select that network while most of the other traffic on Alice's device uses the broadband provider.
たとえば、アリスが自宅にセルラーネットワークプロバイダーとブロードバンドプロバイダーの両方を所有している場合、彼女のPvD対応デバイスとアプリケーションは、利用可能な両方のアップリンクを認識します。これらのアプリケーションは、これらのネットワーク間でフェールオーバーしたり、両方で接続を実行したりする可能性があります（マルチパストランスポートを使用している可能性があります）。アプリケーションは、ネットワークのプロパティに基づいて特定のアップリンクを選択することもできます。たとえば、セルラーネットワークが無料の高品質ビデオストリーミングを提供している場合、ビデオストリーミングアプリケーションはそのネットワークを選択できますが、アリスのデバイス上の他のほとんどのトラフィックはブロードバンドプロバイダーを使用します。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the following terminology:
このドキュメントでは、次の用語を使用しています。
Provisioning Domain (PvD): A set of network configuration information; for more information, see [RFC7556].
プロビジョニングドメイン（PvD）：ネットワーク構成情報のセット。詳細については、[RFC7556]を参照してください。
PvD ID: A Fully Qualified Domain Name (FQDN) used to identify a PvD.
PvD ID：PvDを識別するために使用される完全修飾ドメイン名（FQDN）。
Explicit PvD: A PvD uniquely identified with a PvD ID. For more information, see [RFC7556].
明示的なPvD：PvD IDで一意に識別されるPvD。詳細については、[RFC7556]を参照してください。
Implicit PvD: A PvD that, in the absence of a PvD ID, is identified by the host interface to which it is attached and the address of the advertising router. See also [RFC7556].
暗黙のPvD：PvD IDがない場合に、それが接続されているホストインターフェイスとアドバタイズルーターのアドレスによって識別されるPvD。 [RFC7556]も参照してください。
PvD-aware host: A host that supports the association of network configuration information into PvDs and the use of these PvDs as described in this document. Also named "PvD-aware node" in [RFC7556].
PvD対応ホスト：ネットワーク構成情報のPvDへの関連付け、およびこのドキュメントで説明されているこれらのPvDの使用をサポートするホスト。 [RFC7556]では「PvD対応ノード」とも呼ばれています。
Explicit PvDs are identified by a PvD ID. The PvD ID is a Fully Qualified Domain Name (FQDN) that identifies the network operator. Network operators MUST use names that they own or manage to avoid naming conflicts. The same PvD ID MAY be used in several access networks when they ultimately provide identical services (e.g., in all home networks subscribed to the same service); else, the PvD ID MUST be different to follow Section 2.4 of [RFC7556].
明示的なPvDはPvD IDによって識別されます。 PvD IDは、ネットワークオペレーターを識別する完全修飾ドメイン名（FQDN）です。ネットワークオペレーターは、名前の競合を回避するために、所有または管理する名前を使用する必要があります。複数のアクセスネットワークが最終的に同一のサービスを提供する場合（たとえば、同じサービスに加入しているすべてのホームネットワーク）、同じPvD IDを使用できます（MAY）。それ以外の場合、PvD IDは、[RFC7556]のセクション2.4と異なる必要があります。
This document introduces a Router Advertisement (RA) option called the PvD Option. It is used to convey the FQDN identifying a given PvD (see Figure 1), bind the PvD ID with configuration information received over DHCPv4 (see Section 3.4.2), enable the use of HTTP over TLS to retrieve the PvD Additional Information JSON object (see Section 4), as well as contain any other RA options that would otherwise be valid in the RA.
このドキュメントでは、PvDオプションと呼ばれるルーターアドバタイズ（RA）オプションを紹介します。特定のPvDを識別するFQDNを伝達するために使用され（図1を参照）、PvD IDをDHCPv4経由で受信した構成情報にバインドし（セクション3.4.2を参照）、HTTP over TLSを使用してPvDの追加情報JSONオブジェクトを取得できるようにします（セクション4を参照）。また、RAで有効な他のRAオプションが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |H|L|R| Reserved | Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
... PvD ID FQDN ...
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
... Router Advertisement message header ...
... (Only present when R-flag is set) ...
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: PvD Option Format
図1：PvDオプションの形式
Type: (8 bits) Set to 21.
タイプ：（8ビット）21に設定します。
Length: (8 bits) The length of the option in units of 8 octets, including the Type and Length fields, the Router Advertisement message header, if any, as well as the RA options that are included within the PvD Option.
長さ：（8ビット）8オクテット単位のオプションの長さ。タイプフィールドと長さフィールド、ルーターアドバタイズメッセージヘッダー（ある場合）、およびPvDオプションに含まれるRAオプションを含みます。
H-flag: (1 bit) 'HTTP' flag stating whether some PvD Additional Information is made available through HTTP over TLS, as described in Section 4.
H-フラグ：（1ビット）セクション4で説明されているように、一部のPvD追加情報がHTTP over TLSを介して利用可能になるかどうかを示す「HTTP」フラグ。
L-flag: (1 bit) 'Legacy' flag stating whether the PvD is associated with IPv4 information assigned using DHCPv4 (see Section 3.4.2).
Lフラグ：（1ビット）PvDがDHCPv4を使用して割り当てられたIPv4情報に関連付けられているかどうかを示す「レガシー」フラグ（セクション3.4.2を参照）。
R-flag: (1 bit) 'Router Advertisement' flag stating whether the PvD Option header is followed (right after padding to the next 64-bit boundary) by a Router Advertisement message header (see Section 4.2 of [RFC4861]). The usage of the inner message header is described in Section 3.4.
Rフラグ：（1ビット）ルーターアドバタイズメッセージヘッダーがPvDオプションヘッダーの後に続く（次の64ビット境界にパディングした直後）かどうかを示す「ルーターアドバタイズ」フラグ（[RFC4861]のセクション4.2を参照）。内部メッセージヘッダーの使用法については、セクション3.4で説明します。
Reserved: (9 bits) Reserved for later use. It MUST be set to zero by the sender and ignored by the receiver.
予約済み：（9ビット）後で使用するために予約されています。送信者はゼロに設定し、受信者は無視する必要があります。
Delay: (4 bits) Unsigned integer used to delay HTTP GET queries from hosts by a randomized backoff (see Section 4.1). If the H-flag is not set, senders SHOULD set the delay to zero, and receivers SHOULD ignore the value.
遅延：（4ビット）ランダムバックオフによってホストからのHTTP GETクエリを遅延させるために使用される符号なし整数（セクション4.1を参照）。 Hフラグが設定されていない場合、送信者は遅延をゼロに設定する必要があり（SHOULD）、受信者は値を無視する必要があります（SHOULD）。
Sequence Number: (16 bits) Sequence number for the PvD Additional Information, as described in Section 4. If the H-flag is not set, senders SHOULD set the Sequence Number to zero, and receivers SHOULD ignore the value.
シーケンス番号：（16ビット）セクション4で説明されている、PvD追加情報のシーケンス番号。Hフラグが設定されていない場合、送信者はシーケンス番号をゼロに設定し（SHOULD）、受信者は値を無視する必要があります（SHOULD）。
PvD ID FQDN: The FQDN used as PvD ID encoded in DNS format, as described in Section 3.1 of [RFC1035]. Domain name compression as described in Section 4.1.4 of [RFC1035] MUST NOT be used.
PvD ID FQDN：[RFC1035]のセクション3.1で説明されているように、DNS形式でエンコードされたPvD IDとして使用されるFQDN。 [RFC1035]のセクション4.1.4で説明されているドメイン名圧縮は使用してはなりません。
Padding: Zero or more padding octets to the next 8-octet boundary (see Section 4.6 of [RFC4861]). It MUST be set to zero by the sender and ignored by the receiver.
パディング：次の8オクテット境界までのゼロ以上のパディングオクテット（[RFC4861]のセクション4.6を参照）。送信者はゼロに設定し、受信者は無視する必要があります。
RA message header: (16 octets) When the R-flag is set, a full Router Advertisement message header as specified in [RFC4861]. The sender MUST set the Type field to 134 (the value for "Router Advertisement") and set the Code field to 0. Receivers MUST ignore both of these fields. The Checksum field MUST be set to 0 by the sender; non-zero checksums MUST be ignored by the receiver without causing the processing of the message to fail. All other fields are to be set and parsed as specified in [RFC4861] or any updating documents.
RAメッセージヘッダー：（16オクテット）Rフラグが設定されている場合、[RFC4861]で指定されている完全なルーターアドバタイズメッセージヘッダー。送信者はタイプフィールドを134（「ルーターアドバタイズ」の値）に設定し、コードフィールドを0に設定する必要があります。受信者はこれらのフィールドの両方を無視する必要があります。チェックサムフィールドは、送信者が0に設定する必要があります。ゼロ以外のチェックサムは、メッセージの処理を失敗させることなく、受信者によって無視される必要があります。他のすべてのフィールドは、[RFC4861]または更新ドキュメントで指定されているとおりに設定および解析されます。
Options: Zero or more RA options that would otherwise be valid as part of the Router Advertisement main body but are instead included in the PvD Option so as to be ignored by hosts that are not PvD aware.
オプション：ルーターアドバタイズメントの本体の一部として有効であるが、代わりにPvDオプションに含まれ、PvDに対応していないホストによって無視されるゼロ以上のRAオプション。
Figure 2 shows an example of a PvD Option with "example.org" as the PvD ID FQDN and includes both a Recursive DNS Server (RDNSS) option and a Prefix Information Option. It has a Sequence Number of 123 and indicates the presence of PvD Additional Information that is expected to be fetched with a delay factor of 1.
図2は、PvD ID FQDNとして「example.org」を使用し、再帰DNSサーバー（RDNSS）オプションとプレフィックス情報オプションの両方を含むPvDオプションの例を示しています。シーケンス番号は123で、遅延係数1でフェッチされることが予想されるPvD追加情報の存在を示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+-----------------------------------------------+
| Type: 21 | Length: 12 |1|0|0| Reserved |Delay:1|
+---------------+-------------------------------+---------------+
| Seq number: 123 | 7 | e |
+---------------+-----------------------------------------------+
| x | a | m | p |
+---------------------------------------------------------------+
| l | e | 3 | o |
+---------------------------------------------------------------+
| r | g | 0 | 0 (padding) |
+---------------------------------------------------------------+
| 0 (padding) | 0 (padding) | 0 (padding) | 0 (padding) |
+---------------+---------------+---------------+---------------+
| RDNSS option (RFC 8106) length: 5 ...
... ...
... |
+---------------------------------------------------------------+
| Prefix Information Option (RFC 4861) length: 4 ...
... |
... |
+---------------------------------------------------------------+
Figure 2: Example PvD Option
図2：PvDオプションの例
A router MAY send RAs containing one PvD Option but MUST NOT include more than one PvD Option in each RA. The PvD Option MUST NOT contain further PvD Options.
ルータは、1つのPvDオプションを含むRAを送信してもよいが、各RAに複数のPvDオプションを含めてはならない（MUST NOT）。 PvDオプションに追加のPvDオプションを含めることはできません。
The PvD Option MAY contain zero, one, or more RA options that would otherwise be valid as part of the same RA. Such options are processed by PvD-aware hosts and ignored by other hosts as per Section 4.2 of [RFC4861].
PvDオプションには、同じRAの一部として有効である0、1、またはそれ以上のRAオプションが含まれる場合があります。そのようなオプションはPvD対応ホストによって処理され、[RFC4861]のセクション4.2に従って他のホストによって無視されます。
In order to provide multiple different PvDs, a router MUST send multiple RAs. RAs sent from different link-local source addresses establish distinct Implicit PvDs in the absence of a PvD Option. Explicit PvDs MAY share link-local source addresses with an Implicit PvD and any number of other Explicit PvDs.
複数の異なるPvDを提供するために、ルーターは複数のRAを送信する必要があります。異なるリンクローカルソースアドレスから送信されたRAは、PvDオプションがない場合、異なる暗黙のPvDを確立します。明示的なPvDは、暗黙的なPvDおよびその他の任意の数の明示的なPvDとリンクローカルソースアドレスを共有する場合があります。
In other words, different Explicit PvDs MAY be advertised with RAs using the same link-local source address, but different Implicit PvDs, advertised by different RAs, MUST use different link-local addresses because these Implicit PvDs are identified by the source addresses of the RAs. If a link-local address on the router is changed, then any new RA will be interpreted as a different Implicit PvD by PvD-aware hosts.
言い換えると、同じリンクローカルソースアドレスを使用して、異なる明示的PvDをRAでアドバタイズできますが、異なるRAによってアドバタイズされる異なる暗黙的PvDは、異なるリンクローカルアドレスを使用する必要があります。これらの暗黙的PvDは、 RA。ルーターのリンクローカルアドレスが変更された場合、新しいRAはPvD対応ホストによって異なる暗黙のPvDとして解釈されます。
As specified in [RFC4861] and [RFC6980], when the set of options causes the size of an advertisement to exceed the link MTU, multiple router advertisements MUST be sent to avoid fragmentation, each containing a subset of the options. In such cases, the PvD Option header (i.e., all fields except the Options field) MUST be repeated in all the transmitted RAs. The options within the Options field MAY be transmitted only once, included in one of the transmitted PvD Options.
[RFC4861]と[RFC6980]で指定されているように、オプションのセットによってアドバタイズメントのサイズがリンクMTUを超える場合、フラグメンテーションを回避するために、それぞれがオプションのサブセットを含む複数のルーターアドバタイズメントを送信する必要があります。そのような場合、PvDオプションヘッダー（つまり、オプションフィールドを除くすべてのフィールド）は、送信されたすべてのRAで繰り返される必要があります。オプションフィールド内のオプションは、送信されたPvDオプションの1つに含まれる1回だけ送信される場合があります。
As the PvD Option has a new option code, non-PvD-aware hosts will simply ignore the PvD Option and all the options it contains (see Section 4.2 of [RFC4861]). This ensures the backward compatibility required in Section 3.3 of [RFC7556]. This behavior allows for a mixed-mode network where a mix of PvD-aware and non-PvD-aware hosts coexist.
PvDオプションに新しいオプションコードがあるため、PvD非対応のホストはPvDオプションとそれに含まれるすべてのオプションを単に無視します（[RFC4861]のセクション4.2を参照）。これにより、[RFC7556]のセクション3.3で必要な下位互換性が保証されます。この動作により、PvD対応のホストとPvD非対応のホストが混在する混在モードのネットワークが可能になります。
Hosts MUST associate received RAs and included configuration information (e.g., Router Valid Lifetime, Prefix Information [RFC4861], Recursive DNS Server [RFC8106], and Routing Information [RFC4191] options) with the Explicit PvD identified by the first PvD Option present in the received RA, if any, or with the Implicit PvD identified by the host interface and the source address of the received RA otherwise. If an RA message header is present both within the PvD Option and outside it, the header within the PvD Option takes precedence.
ホストは、受信したRAと含まれる構成情報（たとえば、ルーターの有効期間、プレフィックス情報[RFC4861]、再帰DNSサーバー[RFC8106]、およびルーティング情報[RFC4191]オプション）を、受信したRA（ある場合）、またはホストインターフェースによって識別された暗黙のPvDと受信したRAのソースアドレス（それ以外の場合）。 RAメッセージヘッダーがPvDオプション内とその外側の両方に存在する場合、PvDオプション内のヘッダーが優先されます。
In case multiple PvD Options are found in a given RA, hosts MUST ignore all but the first PvD Option.
特定のRAで複数のPvDオプションが見つかった場合、ホストは最初のPvDオプション以外はすべて無視する必要があります。
If a host receives PvD Options flags that it does not recognize (currently in the Reserved field), it MUST ignore these flags.
ホストが認識しないPvDオプションフラグを受信した場合（現在はReservedフィールドにあります）、これらのフラグを無視する必要があります。
Similarly, hosts MUST associate all network configuration objects (e.g., default routers, addresses, more specific routes, and DNS Recursive Resolvers) with the PvD associated with the RA that provisioned the object. For example, addresses that are generated using a received Prefix Information Option (PIO) are associated with the PvD of the last received RA that included the given PIO.
同様に、ホストはすべてのネットワーク構成オブジェクト（たとえば、デフォルトルーター、アドレス、より具体的なルート、DNS再帰リゾルバー）を、オブジェクトをプロビジョニングしたRAに関連付けられたPvDに関連付ける必要があります。たとえば、受信したプレフィックス情報オプション（PIO）を使用して生成されたアドレスは、特定のPIOを含んだ最後に受信したRAのPvDに関連付けられます。
PvD IDs MUST be compared in a case-insensitive manner as defined by [RFC4343]. For example, "pvd.example.com." or "PvD.Example.coM." would refer to the same PvD.
PvD IDは、[RFC4343]で定義されているように、大文字と小文字を区別しない方法で比較する必要があります。たとえば、「pvd.example.com」。または「PvD.Example.coM。」同じPvDを参照します。
While performing PvD-specific operations such as resolving names, executing the default address selection algorithm [RFC6724], or executing the default router selection algorithm when forwarding packets [RFC4861] [RFC4191] [RFC8028], hosts and applications MAY consider only the configuration associated with any non-empty subset of PvDs. For example, a host MAY associate a given process with a specific PvD, or a specific set of PvDs, while associating another process with another PvD. A PvD-aware application might also be able to select, on a per-connection basis, which PvDs should be used. In particular, constrained devices such as small battery-operated devices (e.g., Internet of Things (IoT)) or devices with limited CPU or memory resources may purposefully use a single PvD while ignoring some received RAs containing different PvD IDs.
名前の解決、デフォルトのアドレス選択アルゴリズムの実行[RFC6724]、またはパケット転送時のデフォルトのルーター選択アルゴリズムの実行[RFC4861] [RFC4191] [RFC8028]などのPvD固有の操作の実行中、ホストとアプリケーションは関連する構成のみを考慮してもよい（MAY） PvDの空でないサブセットを使用します。たとえば、ホストは、別のプロセスを別のPvDに関連付けながら、特定のプロセスを特定のPvDまたは特定のPvDのセットに関連付けることができます（MAY）。 PvD対応アプリケーションは、接続ごとに、どのPvDを使用するかを選択できる場合もあります。特に、小型の電池式デバイス（Internet of Things（IoT）など）や制限されたCPUまたはメモリリソースを備えたデバイスなどの制約されたデバイスは、意図的に単一のPvDを使用し、異なるPvD IDを含む受信したRAを無視する場合があります。
The way an application expresses its desire to use a given PvD, or a set of PvDs, and the way this selection is enforced are out of the scope of this document. Useful insights about these considerations can be found in [MPVD-API].
アプリケーションが特定のPvDまたはPvDのセットを使用するという願望を表現する方法、およびこの選択が強制される方法は、このドキュメントの範囲外です。これらの考慮事項に関する有用な洞察は、[MPVD-API]にあります。
When a host retrieves stateless configuration elements using DHCPv6 (e.g., DNS recursive resolvers or DNS domain search lists [RFC3646]), they MUST be associated with all the Explicit and Implicit PvDs received on the same interface and contained in an RA with the O-flag set [RFC4861].
ホストがDHCPv6を使用してステートレス構成要素（例：DNS再帰リゾルバーまたはDNSドメイン検索リスト[RFC3646]）を取得する場合、それらは同じインターフェイスで受信され、RAに含まれるすべての明示的および暗黙的PvDに関連付けられ、O-フラグセット[RFC4861]。
When a host retrieves stateful assignments using DHCPv6, such assignments MUST be associated with the received PvD that was received with RAs with the M-flag set and including a matching PIO. A PIO is considered to match a DHCPv6 assignment when the IPv6 prefix from the PIO includes the assignment from DHCPv6. For example, if a PvD's associated PIO defines the prefix "2001:db8:cafe::/64", a DHCPv6 IA_NA message that assigns the address "2001:db8:cafe::1234:4567" would be considered to match.
ホストがDHCPv6を使用してステートフルな割り当てを取得する場合、そのような割り当ては、Mフラグが設定され、一致するPIOを含むRAで受信された受信PvDに関連付けられている必要があります。 PIOからのIPv6プレフィックスにDHCPv6からの割り当てが含まれている場合、PIOはDHCPv6割り当てと一致すると見なされます。たとえば、PvDに関連付けられたPIOがプレフィックス「2001：db8：cafe :: / 64」を定義している場合、アドレス「2001：db8：cafe :: 1234：4567」を割り当てるDHCPv6 IA_NAメッセージは一致すると見なされます。
In cases where an address would be assigned by DHCPv6 and no matching PvD could be found, hosts MAY associate the assigned address with any Implicit PvD received on the same interface or to multiple Implicit PvDs received on the same interface. This is intended to resolve backward-compatibility issues with rare deployments choosing to assign addresses with DHCPv6 while not sending any matching PIO. Implementations are suggested to flag or log such scenarios as errors to help detect misconfigurations.
DHCPv6によってアドレスが割り当てられ、一致するPvDが見つからなかった場合、ホストは、割り当てられたアドレスを、同じインターフェイスで受信したすべての暗黙のPvDまたは同じインターフェイスで受信した複数の暗黙のPvDに関連付けることができます。これは、一致するPIOを送信せずにDHCPv6でアドレスを割り当てることを選択するまれな展開での下位互換性の問題を解決することを目的としています。実装では、このようなシナリオにエラーとしてフラグを付けたりログに記録したりして、誤った構成の検出を支援することが推奨されています。
Associating DHCPv4 [RFC2131] configuration elements with Explicit PvDs allows hosts to treat a set of IPv4 and IPv6 configurations as a single PvD with shared properties. For example, consider a router that provides two different uplinks. One could be a broadband network that has data rate and streaming properties described in PvD Additional Information and that provides both IPv4 and IPv6 network access. The other could be a cellular network that provides only IPv6 network access and uses NAT64 [RFC6146]. The broadband network can be represented by an Explicit PvD that points to the Additional Information and also marks association with DHCPv4 information. The cellular network can be represented by a different Explicit PvD that is not associated with DHCPv4.
DHCPv4 [RFC2131]構成要素を明示的なPvDに関連付けると、ホストはIPv4およびIPv6構成のセットを共有プロパティを持つ単一のPvDとして扱うことができます。たとえば、2つの異なるアップリンクを提供するルーターについて考えます。 1つは、PvDの追加情報で説明されているデータレートとストリーミングプロパティを持ち、IPv4とIPv6の両方のネットワークアクセスを提供するブロードバンドネットワークです。もう1つは、IPv6ネットワークアクセスのみを提供し、NAT64 [RFC6146]を使用するセルラーネットワークです。ブロードバンドネットワークは、追加情報をポイントし、DHCPv4情報との関連付けをマークする明示的なPvDで表すことができます。セルラーネットワークは、DHCPv4に関連付けられていない別のExplicit PvDで表すことができます。
When a PvD-aware host retrieves configuration elements from DHCPv4, the information is associated either with a single Explicit PvD on that interface or else with all Implicit PvDs on the same interface.
PvD対応ホストがDHCPv4から構成要素を取得すると、情報はそのインターフェイス上の単一の明示的PvDまたは同じインターフェイス上のすべての暗黙的PvDに関連付けられます。
An Explicit PvD indicates its association with DHCPv4 information by setting the L-flag in the PvD Option. If there is exactly one Explicit PvD that sets this flag, hosts MUST associate the DHCPv4 information with that PvD. Multiple Explicit PvDs on the same interface marking this flag is a misconfiguration, and hosts SHOULD NOT associate the DHCPv4 information with any Explicit PvD in this case.
明示的なPvDは、PvDオプションでLフラグを設定することにより、DHCPv4情報との関連付けを示します。このフラグを設定する明示的なPvDが1つしかない場合、ホストはDHCPv4情報をそのPvDに関連付ける必要があります。このフラグをマークする同じインターフェイス上の複数の明示的PvDは設定ミスであり、ホストはこの場合DHCPv4情報を明示的PvDに関連付けないでください。
If no single Explicit PvD claims association with DHCPv4, the configuration elements coming from DHCPv4 MUST be associated with all Implicit PvDs identified by the interface on which the DHCPv4 transaction happened. This maintains existing host behavior.
単一の明示的PvDがDHCPv4との関連付けを要求しない場合、DHCPv4からの構成要素は、DHCPv4トランザクションが発生したインターフェイスによって識別されるすべての暗黙的PvDに関連付けられている必要があります。これにより、既存のホストの動作が維持されます。
The situation in which a host shares connectivity from an upstream interface (e.g., cellular) to a downstream interface (e.g., Wi-Fi) is known as 'tethering'. Techniques such as ND Proxy [RFC4389], 64share [RFC7278], or prefix delegation (e.g., using DHCPv6-PD [RFC8415]) may be used for that purpose.
ホストがアップストリームインターフェース（セルラーなど）からダウンストリームインターフェース（Wi-Fiなど）への接続を共有する状況は、「テザリング」と呼ばれます。そのために、NDプロキシ[RFC4389]、64share [RFC7278]、またはプレフィックス委任（たとえば、DHCPv6-PD [RFC8415]を使用）などの手法を使用できます。
Whenever the RAs received from the upstream interface contain a PvD Option, hosts that are sharing connectivity SHOULD include a PvD Option within the RAs sent downstream with:
アップストリームインターフェイスから受信したRAにPvDオプションが含まれている場合は常に、接続を共有しているホストは、以下を使用してダウンストリームに送信されたRA内にPvDオプションを含める必要があります。
* The same PvD ID FQDN
* 同じPvD ID FQDN
* The same H-flag, Delay, and Sequence Number values
* 同じHフラグ、遅延、シーケンス番号の値
* The L-flag set whenever the host is sharing IPv4 connectivity received from the same upstream interface
* ホストが同じアップストリームインターフェイスから受信したIPv4接続を共有している場合は常に設定されるLフラグ
* The bits in the Reserved field set to 0
* 予約済みフィールドのビットが0に設定されている
The values of the R-flag, Router Advertisement message header, and Options field depend on whether or not the connectivity should be shared only with PvD-aware hosts (see Section 3.2). In particular, all options received within the upstream PvD Option and included in the downstream RA SHOULD be included in the downstream PvD Option.
Rフラグ、ルーターアドバタイズメントメッセージヘッダー、およびオプションフィールドの値は、接続をPvD対応ホストのみと共有するかどうかによって異なります（セクション3.2を参照）。特に、アップストリームPvDオプション内で受信され、ダウンストリームRAに含まれるすべてのオプションは、ダウンストリームPvDオプションに含まれる必要があります。
PvD-aware hosts can be provisioned with recursive DNS servers via RA options passed within an Explicit PvD, via RA options associated with an Implicit PvD, via DHCPv6 or DHCPv4, or from some other provisioning mechanism that creates an Explicit PvD (such as a VPN). In all of these cases, the recursive DNS server addresses SHOULD be associated with the corresponding PvD. Specifically, queries sent to a configured recursive DNS server SHOULD be sent from a local IP address that was provisioned for the PvD via RA or DHCP. Answers received from the DNS server SHOULD only be used on the same PvD.
PvD対応ホストは、明示的PvD内で渡されるRAオプション、暗黙的PvDに関連付けられたRAオプション、DHCPv6またはDHCPv4を介して、または明示的PvDを作成する他のプロビジョニングメカニズム（VPNなど）から、再帰DNSサーバーでプロビジョニングできます。 ）。これらすべてのケースで、再帰DNSサーバーアドレスは対応するPvDに関連付けられる必要があります（SHOULD）。具体的には、構成済みの再帰DNSサーバーに送信されるクエリは、RAまたはDHCPを介してPvD用にプロビジョニングされたローカルIPアドレスから送信する必要があります（SHOULD）。 DNSサーバーから受信した回答は、同じPvDでのみ使用する必要があります。
PvD-aware applications will be able to select which PvD(s) to use for DNS resolution and connections, which allows them to effectively use multiple Explicit PvDs. In order to support non-PvD-aware applications, however, PvD-aware hosts SHOULD ensure that non-PvD-aware name resolution APIs like "getaddrinfo" only use resolvers from a single PvD for a given query. Handling DNS across PvDs is discussed in Section 5.2.1 of [RFC7556], and PvD APIs are discussed in Section 6 of [RFC7556].
PvD対応アプリケーションは、DNS解決と接続に使用するPvDを選択できるため、複数のExplicit PvDを効果的に使用できます。ただし、PvD非対応のアプリケーションをサポートするために、PvD対応のホストは、「getaddrinfo」のような非PvD対応の名前解決APIが、特定のクエリに対して単一のPvDからのリゾルバーのみを使用することを確認する必要があります。 PvD間のDNSの処理については、[RFC7556]のセクション5.2.1で説明されており、PvD APIについては、[RFC7556]のセクション6で説明されています。
Maintaining the correct usage of DNS within PvDs avoids various practical errors such as:
PvD内でDNSの正しい使用法を維持することで、次のようなさまざまな実際的なエラーを回避できます。
* A PvD associated with a VPN or otherwise private network may provide DNS answers that contain addresses inaccessible over another PvD. This includes the DNS queries to retrieve PvD Additional Information, which could otherwise send identifying information to the recursive DNS system (see Section 4.1).
* VPNまたはその他のプライベートネットワークに関連付けられたPvDは、別のPvDを介してアクセスできないアドレスを含むDNS応答を提供する場合があります。これには、PvDの追加情報を取得するためのDNSクエリが含まれます。これは、識別情報を再帰的なDNSシステムに送信する可能性があります（セクション4.1を参照）。
* A PvD that uses a NAT64 [RFC6146] and DNS64 [RFC6147] will synthesize IPv6 addresses in DNS answers that are not globally routable and would be invalid on other PvDs. Conversely, an IPv4 address resolved via DNS on another PvD cannot be directly used on a NAT64 network.
* NAT64 [RFC6146]およびDNS64 [RFC6147]を使用するPvDは、グローバルにルーティングできず、他のPvDでは無効になるDNS回答のIPv6アドレスを合成します。逆に、別のPvDでDNSを介して解決されたIPv4アドレスは、NAT64ネットワークで直接使用できません。
Additional information about the network characteristics can be retrieved based on the PvD ID. This set of information is called PvD Additional Information and is encoded as a JSON object [RFC8259]. This JSON object is restricted to the Internet JSON (I-JSON) profile, as defined in [RFC7493].
ネットワーク特性に関する追加情報は、PvD IDに基づいて取得できます。この情報のセットはPvD追加情報と呼ばれ、JSONオブジェクト[RFC8259]としてエンコードされます。このJSONオブジェクトは、[RFC7493]で定義されているインターネットJSON（I-JSON）プロファイルに制限されています。
The purpose of this JSON object is to provide Additional Information to applications on a client host about the connectivity that is provided using a given interface and source address. It typically includes data that would be considered too large, or not critical enough, to be provided within an RA option. The information contained in this object MAY be used by the operating system, network libraries, applications, or users in order to decide which set of PvDs should be used for which connection, as described in Section 3.4.
このJSONオブジェクトの目的は、特定のインターフェイスとソースアドレスを使用して提供される接続性に関する追加情報をクライアントホスト上のアプリケーションに提供することです。これには通常、RAオプション内で提供するには大きすぎる、または十分に重要ではないと見なされるデータが含まれます。このオブジェクトに含まれる情報は、セクション3.4で説明されているように、どの接続にどのPvDのセットを使用するかを決定するために、オペレーティングシステム、ネットワークライブラリ、アプリケーション、またはユーザーが使用できます。
The Additional Information related to a PvD is specifically intended to be optional and is targeted at optimizing or informing the behavior of user-facing hosts. This information can be extended to provide hints for host system behavior (such as captive portal or walled-garden PvD detection) or application behavior (describing application-specific services offered on a given PvD). This content may not be appropriate for light-weight IoT devices. IoT devices might need only a subset of the information and would in some cases prefer a smaller representation like Concise Binary Object Representation (CBOR) [RFC7049]. Delivering a reduced version of the PvD Additional Information designed for such devices is not defined in this document.
PvDに関連する追加情報は、特にオプションであることが意図されており、ユーザーに面するホストの動作を最適化または通知することを目的としています。この情報を拡張して、ホストシステムの動作（キャプティブポータルやWalled-Garden PvD検出など）またはアプリケーションの動作（特定のPvDで提供されるアプリケーション固有のサービスについて説明する）のヒントを提供できます。このコンテンツは、軽量のIoTデバイスには適さない場合があります。 IoTデバイスは、情報のサブセットのみを必要とする場合があり、場合によっては、簡潔なバイナリオブジェクト表現（CBOR）[RFC7049]のようなより小さな表現を好むでしょう。このようなデバイス用に設計されたPvD追加情報の削減バージョンの提供は、このドキュメントでは定義されていません。
When the H-flag of the PvD Option is set, hosts MAY attempt to retrieve the PvD Additional Information associated with a given PvD by performing an HTTP-over-TLS [RFC2818] GET query to "https://<PvD-ID>/.well-known/pvd". Inversely, hosts MUST NOT do so whenever the H-flag is not set.
PvDオプションのHフラグが設定されている場合、ホストは「https：// <PvD-ID>へのHTTP-over-TLS [RFC2818] GETクエリを実行して、特定のPvDに関連付けられたPvD追加情報を取得しようとする場合があります。 /.well-known/pvd "。逆に、Hフラグが設定されていない場合は、ホストがこれを行うことはできません。
Recommendations for how to use TLS securely can be found in [RFC7525].
TLSを安全に使用する方法の推奨事項は、[RFC7525]にあります。
When a host retrieves the PvD Additional Information, it MUST verify that the TLS server certificate is valid for the performed request, specifically, that a DNS-ID [RFC6125] on the certificate is equal to the PvD ID expressed as an FQDN. This validation indicates that the owner of the FQDN authorizes its use with the prefix advertised by the router. If this validation fails, hosts MUST close the connection and treat the PvD as if it has no Additional Information.
ホストがPvDの追加情報を取得するとき、TLSサーバー証明書が実行された要求に対して有効であること、特に証明書のDNS-ID [RFC6125]がFQDNとして表現されたPvD IDに等しいことを確認する必要があります。この検証は、FQDNの所有者が、ルーターによってアドバタイズされたプレフィックスでの使用を承認することを示しています。この検証が失敗した場合、ホストは接続を閉じ、PvDを追加情報がないかのように扱う必要があります。
HTTP requests and responses for PvD Additional Information use the "application/pvd+json" media type (see Section 8.5). Clients SHOULD include this media type as an Accept header field in their GET requests, and servers MUST mark this media type as their Content-Type header field in responses.
PvDの追加情報のHTTP要求と応答では、「application / pvd + json」メディアタイプを使用します（セクション8.5を参照）。クライアントはこのメディアタイプをGETリクエストのAcceptヘッダーフィールドとして含めるべきであり、サーバーはこのメディアタイプを応答のContent-Typeヘッダーフィールドとしてマークしなければなりません（MUST）。
Note that the DNS name resolution of the PvD ID, any connections made for certificate validation (such as Online Certificate Status Protocol (OCSP) [RFC6960]), and the HTTP request itself MUST be performed using the considered PvD. In other words, the name resolution, PKI checks, source address selection, as well as the next-hop router selection MUST be performed while exclusively using the set of configuration information attached with the PvD, as defined in Section 3.4. In some cases, it may therefore be necessary to wait for an address to be available for use (e.g., once the Duplicate Address Detection or DHCPv6 processes are complete) before initiating the HTTP-over-TLS query. In order to address privacy concerns around linkability of the PvD HTTP connection with future user-initiated connections, if the host has a temporary address per [RFC4941] in this PvD, then it SHOULD use a temporary address to fetch the PvD Additional Information and MAY deprecate the used temporary address and generate a new temporary address afterward.
PvD IDのDNS名前解決、証明書検証のために行われたすべての接続（オンライン証明書ステータスプロトコル（OCSP）[RFC6960]など）、およびHTTP要求自体は、考慮されたPvDを使用して実行する必要があります。言い換えると、名前解決、PKIチェック、送信元アドレスの選択、およびネクストホップルーターの選択は、セクション3.4で定義されているように、PvDに添付された構成情報のセットを排他的に使用しながら実行する必要があります。したがって、場合によっては、HTTP-over-TLSクエリを開始する前に、アドレスが使用可能になるまで（たとえば、重複アドレス検出またはDHCPv6プロセスが完了すると）待機する必要がある場合があります。 PvD HTTP接続と将来のユーザー開始接続とのリンク可能性に関するプライバシーの懸念に対処するため、ホストがこのPvDの[RFC4941]ごとに一時アドレスを持っている場合、一時アドレスを使用してPvD追加情報をフェッチする必要があります。使用された一時アドレスを非推奨にし、後で新しい一時アドレスを生成します。
If the HTTP status of the answer is greater than or equal to 400, the host MUST close its connection and consider that there is no PvD Additional Information. If the HTTP status of the answer is between 300 and 399, inclusive, it MUST follow the redirection(s). If the HTTP status of the answer is between 200 and 299, inclusive, the response is expected to be a single JSON object.
回答のHTTPステータスが400以上の場合、ホストは接続を閉じ、PvDの追加情報がないと見なす必要があります。回答のHTTPステータスが300から399までの場合、リダイレクトに従う必要があります。回答のHTTPステータスが200以上299以下の場合、応答は単一のJSONオブジェクトであると予想されます。
After retrieval of the PvD Additional Information, hosts MUST remember the last Sequence Number value received in an RA including the same PvD ID. Whenever a new RA for the same PvD is received with a different Sequence Number value, or whenever the expiry date for the additional information is reached, hosts MUST deprecate the Additional Information and stop using it.
PvD追加情報を取得した後、ホストは、同じPvD IDを含む、RAで受信した最後のシーケンス番号値を記憶する必要があります。同じPvDの新しいRAが異なるシーケンス番号値で受信された場合、または追加情報の有効期限に達した場合は常に、ホストは追加情報を非推奨にして使用を停止する必要があります。
Hosts retrieving a new PvD Additional Information object MUST check for the presence and validity of the mandatory fields specified in Section 4.3. A retrieved object including an expiration time that is already past or missing a mandatory element MUST be ignored.
新しいPvD追加情報オブジェクトを取得するホストは、セクション4.3で指定された必須フィールドの存在と有効性を確認する必要があります。既に過ぎているか必須要素が欠落している有効期限を含む取得されたオブジェクトは無視されなければなりません。
In order to avoid synchronized queries toward the server hosting the PvD Additional Information when an object expires, object updates are delayed by a randomized backoff time.
オブジェクトが期限切れになったときにPvD追加情報をホストするサーバーへのクエリの同期を回避するために、オブジェクトの更新はランダム化されたバックオフ時間によって遅延されます。
* When a host performs a JSON object update after it detected a change in the PvD Option Sequence Number, it MUST add a delay before sending the query. The target time for the delay is calculated as a random time between zero and 2^((10 + Delay)) milliseconds, where 'Delay' corresponds to the 4-bit unsigned integer in the last received PvD Option.
* ホストがPvDオプションシーケンス番号の変更を検出した後にJSONオブジェクトの更新を実行する場合、クエリを送信する前に遅延を追加する必要があります。遅延のターゲット時間は、0から2 ^（（10 +遅延））ミリ秒の間のランダムな時間として計算されます。「遅延」は、最後に受信したPvDオプションの4ビットの符号なし整数に対応します。
* When a host last retrieved a JSON object at time A that includes an expiry time B using the "expires" key, and the host is configured to keep the PvD Additional Information up to date, it MUST add some randomness into its calculation of the time to fetch the update. The target time for fetching the updated object is calculated as a uniformly random time in the interval [(B-A)/2,B].
* ホストが最後に「expires」キーを使用して有効期限Bを含むJSONオブジェクトを時間Aで取得し、PvD追加情報を最新に保つように構成されている場合、時間の計算にランダム性を追加する必要がありますアップデートを取得します。更新されたオブジェクトを取得するためのターゲット時間は、[（B-A）/ 2、B]の間隔で一様にランダムな時間として計算されます。
In the example in Figure 2, the Delay field value is 1; this means that the host calculates its delay by choosing a uniformly random time between 0 and 2^((10 + 1)) milliseconds, i.e., between 0 and 2048 milliseconds.
図2の例では、Delayフィールドの値は1です。これは、ホストが0から2 ^（（10 + 1））ミリ秒、つまり0から2048ミリ秒の間で一様にランダムな時間を選択することにより、遅延を計算することを意味します。
Since the Delay value is directly within the PvD Option rather than the object itself, an operator may perform a push-based update by incrementing the Sequence Number value while changing the Delay value depending on the criticality of the update and the capacity of its PvD Additional Information servers.
遅延値はオブジェクト自体ではなくPvDオプション内に直接あるため、オペレーターは、更新の重要度とそのPvDの容量に応じて遅延値を変更しながらシーケンス番号値を増分することにより、プッシュベースの更新を実行できます。情報サーバー。
In addition to adding a random delay when fetching Additional Information, hosts MUST enforce a minimum time between requesting Additional Information for a given PvD on the same network. This minimum time is RECOMMENDED to be 10 seconds, in order to avoid hosts causing a denial-of-service on the PvD server. Hosts also MUST limit the number of requests that are made to different PvD Additional Information servers on the same network within a short period of time. A RECOMMENDED value is to issue no more than five PvD Additional Information requests in total on a given network within 10 seconds. For more discussion, see Section 6.
追加情報を取得するときにランダムな遅延を追加することに加えて、ホストは、同じネットワーク上の特定のPvDに追加情報を要求する間の最小時間を強制する必要があります。ホストがPvDサーバーでサービス拒否を引き起こすのを避けるために、この最小時間は10秒にすることをお勧めします。ホストはまた、同じネットワーク上の異なるPvD追加情報サーバーに対して短期間に行われる要求の数を制限する必要があります。推奨値は、10秒以内に特定のネットワークで合計5つ以下のPvD追加情報要求を発行することです。詳細については、セクション6を参照してください。
The PvD Additional Information object includes a set of IPv6 prefixes (under the key "prefixes") that MUST be checked against all the Prefix Information Options advertised in the RA. If any of the prefixes included in any associated PIO is not covered by at least one of the listed prefixes, the PvD Additional Information MUST be considered to be a misconfiguration and MUST NOT be used by the host. See Section 4.4 for more discussion on handling such misconfigurations.
PvD追加情報オブジェクトには、RAでアドバタイズされるすべてのプレフィックス情報オプションに対してチェックする必要があるIPv6プレフィックスのセット（「プレフィックス」の下）が含まれています。関連付けられたPIOに含まれるいずれかのプレフィックスがリストされたプレフィックスの少なくとも1つでカバーされていない場合、PvD追加情報は構成ミスと見なされ、ホストで使用してはなりません（MUST NOT）。このような誤った構成の処理に関する詳細は、4.4項を参照してください。
If the request for PvD Additional Information fails due to a TLS certificate validation error, an HTTP error, or because the retrieved file does not contain valid PvD JSON, hosts MUST close any connection used to fetch the PvD Additional Information and MUST NOT request the information for that PvD ID again for the duration of the local network attachment. If a host detects 10 or more such failures to fetch PvD Additional Information, the local network is assumed to be misconfigured or under attack and the host MUST NOT make any further requests for any PvD Additional Information, belonging to any PvD ID, for the duration of the local network attachment. For more discussion, see Section 6.
TLS証明書の検証エラー、HTTPエラー、または取得したファイルに有効なPvD JSONが含まれていないためにPvD追加情報のリクエストが失敗した場合、ホストはPvD追加情報をフェッチするために使用された接続を閉じなければならず、情報をリクエストしてはなりません（MUST NOT）ローカルネットワーク接続の期間中、そのPvD IDに対して再度。ホストがPvD追加情報を取得するために10以上のこのような失敗を検出した場合、ローカルネットワークは誤って構成されているか、攻撃を受けていると見なされ、ホストはその期間、PvD IDに属するPvD追加情報をこれ以上要求してはなりませんローカルネットワーク接続の。詳細については、セクション6を参照してください。
4.2. Operational Consideration to Providing the PvD Additional Information
4.2. PvD追加情報の提供に関する運用上の考慮事項
Whenever the H-flag is set in the PvD Option, a valid PvD Additional Information object MUST be made available to all hosts receiving the RA by the network operator. In particular, when a captive portal is present, hosts MUST still be allowed to perform DNS, certificate validation, and HTTP-over-TLS operations related to the retrieval of the object, even before logging into the captive portal.
PvDオプションでHフラグが設定されている場合は常に、ネットワークオペレーターがRAを受信するすべてのホストが有効なPvD追加情報オブジェクトを使用できるようにする必要があります。特に、キャプティブポータルが存在する場合でも、キャプティブポータルにログインする前であっても、ホストはオブジェクトの取得に関連するDNS、証明書の検証、HTTP-over-TLS操作の実行を許可されている必要があります。
Routers SHOULD increment the PvD Option Sequence Number by one whenever a new PvD Additional Information object is available and should be retrieved by hosts. If the value exceeds what can be stored in the Sequence Number field, it MUST wrap back to zero.
ルーターは、新しいPvD追加情報オブジェクトが利用可能であり、ホストによって取得される必要がある場合は常に、PvDオプションシーケンス番号を1だけ増やす必要があります。値がシーケンス番号フィールドに格納できる値を超える場合は、ゼロに折り返す必要があります。
The server providing the JSON files SHOULD also check whether the client address is contained by the prefixes listed in the Additional Information and SHOULD return a 403 response code if there is no match.
JSONファイルを提供するサーバーは、追加情報にリストされているプレフィックスにクライアントアドレスが含まれているかどうかを確認し（SHOULD）、一致がない場合は403応答コードを返す必要があります（SHOULD）。
The PvD Additional Information is a JSON object.
PvD追加情報はJSONオブジェクトです。
The following table presents the mandatory keys, which MUST be included in the object:
次の表は、オブジェクトに含める必要がある必須キーを示しています。
+============+===============+===========+========================+
| JSON key | Description | Type | Example |
+============+===============+===========+========================+
| identifier | PvD ID FQDN | String | "pvd.example.com." |
+------------+---------------+-----------+------------------------+
| expires | Date after | [RFC3339] | "2020-05-23T06:00:00Z" |
| | which this | Date | |
| | object is no | | |
| | longer valid | | |
+------------+---------------+-----------+------------------------+
| prefixes | Array of IPv6 | Array of | ["2001:db8:1::/48", |
| | prefixes | strings | "2001:db8:4::/48"] |
| | valid for | | |
| | this PvD | | |
+------------+---------------+-----------+------------------------+
Table 1
表1
A retrieved object that does not include all three of these keys at the root of the JSON object MUST be ignored. All three keys need to be validated; otherwise, the object MUST be ignored. The value stored for "identifier" MUST be matched against the PvD ID FQDN presented in the PvD Option using the comparison mechanism described in Section 3.4. The value stored for "expires" MUST be a valid date in the future. If the PIO of the received RA is not covered by at least one of the "prefixes" key, the retrieved object SHOULD be ignored.
JSONオブジェクトのルートにこれらの3つすべてのキーを含まない取得されたオブジェクトは無視する必要があります。 3つのキーすべてを検証する必要があります。それ以外の場合、オブジェクトは無視する必要があります。 「識別子」に保存された値は、セクション3.4で説明されている比較メカニズムを使用して、PvDオプションで提示されたPvD ID FQDNと一致する必要があります。 「expires」に格納される値は、将来の有効な日付である必要があります。受信したRAのPIOが「接頭辞」キーの少なくとも1つでカバーされていない場合、取得したオブジェクトは無視する必要があります（SHOULD）。
The following table presents some optional keys that MAY be included in the object.
次の表は、オブジェクトに含めることができるいくつかのオプションのキーを示しています。
+============+======================+==========+====================+
| JSON key | Description | Type | Example |
+============+======================+==========+====================+
| dnsZones | DNS zones searchable | Array | ["example.com", |
| | and accessible | of | "sub.example.com"] |
| | | strings | |
+------------+----------------------+----------+--------------------+
| noInternet | No Internet; set to | Boolean | true |
| | "true" when the PvD | | |
| | is restricted | | |
+------------+----------------------+----------+--------------------+
Table 2
表2
It is worth noting that the JSON format allows for extensions. Whenever an unknown key is encountered, it MUST be ignored along with its associated elements.
JSON形式では拡張が可能であることは注目に値します。不明なキーが検出された場合は常に、関連する要素とともに無視する必要があります。
Private-use or experimental keys MAY be used in the JSON dictionary. In order to avoid such keys colliding with the keys registered by IANA, implementers or vendors defining private-use or experimental keys MUST create sub-dictionaries. If a set of PvD Additional Information keys are defined by an organization that has a formal URN namespace [IANA-URN], the URN namespace SHOULD be used as the top-level JSON key for the sub-dictionary. For other private uses, the sub-dictionary key SHOULD follow the format of "vendor-*", where the "*" is replaced by the implementer's or vendor's identifier. For example, keys specific to the FooBar organization could use "vendor-foobar". If a host receives a sub-dictionary with an unknown key, the host MUST ignore the contents of the sub-dictionary.
JSON辞書では、私用または実験的な鍵を使用できます。そのようなキーがIANAによって登録されたキーと衝突することを回避するために、私用または実験的なキーを定義する実装者またはベンダーは、サブディクショナリを作成する必要があります。一連のPvD追加情報キーが正式なURN名前空間[IANA-URN]を持つ組織によって定義されている場合、URN名前空間をサブディクショナリの最上位のJSONキーとして使用する必要があります（SHOULD）。他の私的使用の場合、サブ辞書キーは「vendor- *」の形式に従う必要があります（SHOULD）。「*」は、実装者またはベンダーの識別子に置き換えられます。たとえば、FooBar組織に固有のキーには「vendor-foobar」を使用できます。ホストが未知のキーを持つサブ辞書を受け取った場合、ホストはサブ辞書の内容を無視しなければなりません（MUST）。
The following two examples show how the JSON keys defined in this document can be used:
次の2つの例は、このドキュメントで定義されているJSONキーの使用方法を示しています。
{
"identifier": "cafe.example.com.",
"expires": "2020-05-23T06:00:00Z",
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
}
{
"identifier": "company.foo.example.com.",
"expires": "2020-05-23T06:00:00Z",
"prefixes": ["2001:db8:1::/48", "2001:db8:4::/48"],
"vendor-foo":
{
"private-key": "private-value",
},
}
Hosts MUST validate the TLS server certificate when retrieving PvD Additional Information, as detailed in Section 4.1.
セクション4.1で説明されているように、ホストはPvDの追加情報を取得するときにTLSサーバー証明書を検証する必要があります。
Hosts MUST verify that all prefixes in all the RA PIOs are covered by a prefix from the PvD Additional Information. An adversarial router attempting to spoof the definition of an Explicit PvD, without the ability to modify the PvD Additional Information, would need to perform IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296] in order to circumvent this check. Thus, this check cannot prevent all spoofing, but it can detect misconfiguration or mismatched routers that are not adding a NAT.
ホストは、すべてのRA PIOのすべてのプレフィックスがPvD追加情報のプレフィックスでカバーされていることを確認する必要があります。 PvDの追加情報を変更する機能なしに、明示的なPvDの定義を偽装しようとする敵対ルーターは、このチェックを回避するために、IPv6-to-IPv6ネットワークプレフィックス変換（NPTv6）[RFC6296]を実行する必要があります。したがって、このチェックではすべてのスプーフィングを防ぐことはできませんが、NATを追加していない構成の誤りやルーターの不一致を検出できます。
If NPTv6 is being added in order to spoof PvD ownership, the HTTPS server for Additional Information can detect this misconfiguration. The HTTPS server SHOULD validate the source addresses of incoming connections (see Section 4.1). This check gives reasonable assurance that NPTv6 was not used and restricts the information to the valid network users.If the PvD does not provision IPv4 (it does not include the L-flag in the RA), the server cannot validate the source addresses of connections using IPv4. Thus, the PvD ID FQDN for such PvDs SHOULD NOT have a DNS A record.
PvDの所有権を偽装するためにNPTv6が追加されている場合、追加情報用のHTTPSサーバーがこの誤った構成を検出できます。 HTTPSサーバーは着信接続の送信元アドレスを検証する必要があります（セクション4.1を参照）。このチェックは、NPTv6が使用されなかったことを合理的に保証し、情報を有効なネットワークユーザーに制限します。PvDがIPv4をプロビジョニングしない場合（RAにLフラグが含まれていない場合）、サーバーは接続の送信元アドレスを検証できませんIPv4を使用します。したがって、そのようなPvDのPvD ID FQDNにはDNS Aレコードが必要です（SHOULD NOT）。
This section describes some example use cases of PvDs. For the sake of simplicity, the RA messages will not be described in the usual ASCII art but rather in an indented list. Values in the PvD Option header that are not included in the example are assumed to be zero or false (such as the H-flag, Sequence Number, and Delay fields).
このセクションでは、PvDのいくつかの使用例について説明します。簡単にするために、RAメッセージは通常のASCIIアートではなく、インデントされたリストで記述されます。この例に含まれていないPvDオプションヘッダーの値は、ゼロまたはfalse（Hフラグ、シーケンス番号、遅延フィールドなど）であると見なされます。
In this example, there is one RA message sent by the router. This message contains some options applicable to all hosts on the network and also a PvD Option that also contains other options only visible to PvD-aware hosts.
この例では、ルーターから送信されたRAメッセージが1つあります。このメッセージには、ネットワーク上のすべてのホストに適用可能ないくつかのオプションと、PvD対応ホストにのみ表示される他のオプションも含むPvDオプションが含まれています。
* RA Header: router lifetime = 6000
* RAヘッダー：ルーターの寿命= 6000
* Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64
* プレフィックス情報オプション：長さ= 4、プレフィックス= 2001：db8：cafe :: / 64
* PvD Option header: length = 3 + 5 + 4, PvD ID FQDN = example.org., R-flag = 0 (actual length of the header with padding 24 bytes = 3 * 8 bytes)
* PvDオプションヘッダー：長さ= 3 + 5 + 4、PvD ID FQDN = example.org。、Rフラグ= 0（パディング付きのヘッダーの実際の長さ= 24バイト= 3 * 8バイト）
- Recursive DNS Server: length = 5, addresses = [2001:db8:cafe::53, 2001:db8:f00d::53]
- 再帰DNSサーバー：長さ= 5、アドレス= [2001：db8：cafe :: 53、2001：db8：f00d :: 53]
- Prefix Information Option: length = 4, prefix = 2001:db8:f00d::/64
- プレフィックス情報オプション：長さ= 4、プレフィックス= 2001：db8：f00d :: / 64
Note that a PvD-aware host will receive two different prefixes, "2001:db8:cafe::/64" and "2001:db8:f00d::/64", both associated with the same PvD (identified by "example.org."). A non-PvD-aware host will only receive one prefix, "2001:db8:cafe::/64".
PvD対応ホストは、2つの異なるプレフィックス「2001：db8：cafe :: / 64」と「2001：db8：f00d :: / 64」を受け取り、どちらも同じPvD（「example.org 。」）。 PvD非対応のホストは、「2001：db8：cafe :: / 64」という1つのプレフィックスのみを受け取ります。
It is expected that for some years, networks will have a mixed environment of PvD-aware hosts and non-PvD-aware hosts. If there is a need to give specific information to PvD-aware hosts only, then it is RECOMMENDED to send two RA messages, one for each class of hosts. This approach allows for two distinct sets of configuration information to be sent in a way that will not disrupt non-PvD-aware hosts. It also lowers the risk that a single RA message will approach its MTU limit due to duplicated information.
数年の間、ネットワークはPvD対応ホストと非PvD対応ホストの混合環境になると予想されます。特定の情報をPvD対応ホストのみに提供する必要がある場合は、ホストのクラスごとに1つずつ、2つのRAメッセージを送信することをお勧めします。このアプローチでは、PvD非対応のホストを混乱させない方法で、2つの異なる構成情報セットを送信できます。また、情報の重複が原因で、単一のRAメッセージがMTU制限に近づくリスクも低くなります。
If two RA messages are sent for this reason, they MUST be sent from two different link-local source addresses (Section 3.2). For example, here is the RA sent for non-PvD-aware hosts:
この理由で2つのRAメッセージが送信される場合、それらは2つの異なるリンクローカル送信元アドレスから送信されなければなりません（セクション3.2）。たとえば、PvD非対応のホストに送信されるRAは次のとおりです。
* RA Header: router lifetime = 6000 (non-PvD-aware hosts will use this router as a default router)
* RAヘッダー：ルーターライフタイム= 6000（PvD非対応ホストはこのルーターをデフォルトルーターとして使用します）
* Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64
* プレフィックス情報オプション：長さ= 4、プレフィックス= 2001：db8：cafe :: / 64
* Recursive DNS Server Option: length = 3, addresses = [2001:db8:cafe::53]
* 再帰DNSサーバーオプション：長さ= 3、アドレス= [2001：db8：cafe :: 53]
* PvD Option header: length = 3 + 2, PvD ID FQDN = foo.example.org., R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes)
* PvDオプションヘッダー：長さ= 3 + 2、PvD ID FQDN = foo.example.org。、Rフラグ= 1（ヘッダーの実際の長さ24バイト= 3 * 8バイト）
- RA Header: router lifetime = 0 (PvD-aware hosts will not use this router as a default router), implicit length = 2
- RAヘッダー：ルーターライフタイム= 0（PvD対応ホストはこのルーターをデフォルトルーターとして使用しません）、暗黙の長さ= 2
And here is the RA sent for PvD-aware hosts:
そして、これがPvD対応ホストに送信されるRAです。
* RA Header: router lifetime = 0 (non-PvD-aware hosts will not use this router as a default router)
* RAヘッダー：ルーターライフタイム= 0（PvD非対応のホストはこのルーターをデフォルトルーターとして使用しません）
* PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN = bar.example.org., R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes)
* PvDオプションヘッダー：長さ= 3 + 2 + 4 + 3、PvD ID FQDN = bar.example.org。、Rフラグ= 1（ヘッダーの実際の長さ24バイト= 3 * 8バイト）
- RA Header: router lifetime = 1600 (PvD-aware hosts will use this router as a default router), implicit length = 2
- RAヘッダー：ルーターライフタイム= 1600（PvD対応ホストはこのルーターをデフォルトルーターとして使用します）、暗黙の長さ= 2
- Prefix Information Option: length = 4, prefix = 2001:db8:f00d::/64
- プレフィックス情報オプション：長さ= 4、プレフィックス= 2001：db8：f00d :: / 64
- Recursive DNS Server Option: length = 3, addresses = [2001:db8:f00d::53]
- 再帰DNSサーバーオプション：長さ= 3、アドレス= [2001：db8：f00d :: 53]
In the above example, non-PvD-aware hosts will only use the first listed RA sent by their default router and use the "2001:db8:cafe::/64" prefix. PvD-aware hosts will autonomously configure addresses from both PIOs but will only use the source address in "2001:db8:f00d::/64" to communicate past the first-hop router since only the router sending the second RA will be used as the default router; similarly, they will use the DNS server "2001:db8:f00d::53" when communicating from this address.
上記の例では、PvD非対応のホストは、デフォルトルーターによって送信された最初にリストされたRAのみを使用し、「2001：db8：cafe :: / 64」プレフィックスを使用します。 PvD対応ホストは、両方のPIOから自律的にアドレスを構成しますが、2番目のRAを送信するルーターのみが次のように使用されるため、「2001：db8：f00d :: / 64」のソースアドレスのみを使用して、最初のホップルーターを越えて通信します。デフォルトルーター。同様に、このアドレスから通信する場合、DNSサーバー「2001：db8：f00d :: 53」を使用します。
In this example, the goal is to have one prefix from one RA be usable by both non-PvD-aware and PvD-aware hosts and to have another prefix usable only by PvD-aware hosts. This allows PvD-aware hosts to be able to effectively multihome on the network.
この例では、1つのRAの1つのプレフィックスを非PvD対応ホストとPvD対応ホストの両方で使用できるようにし、別のプレフィックスをPvD対応ホストだけで使用できるようにすることが目標です。これにより、PvD対応のホストがネットワーク上で効果的にマルチホームできるようになります。
The first RA is usable by all hosts. The only difference for PvD-aware hosts is that they can explicitly identify the PvD ID associated with the RA. PvD-aware hosts will also use this prefix to communicate with non-PvD-aware hosts on the same network.
最初のRAはすべてのホストで使用できます。 PvD対応ホストの唯一の違いは、RAに関連付けられたPvD IDを明示的に識別できることです。 PvD対応ホストもこのプレフィックスを使用して、同じネットワーク上の非PvD対応ホストと通信します。
* RA Header: router lifetime = 6000 (non-PvD-aware hosts will use this router as a default router)
* RAヘッダー：ルーターライフタイム= 6000（PvD非対応ホストはこのルーターをデフォルトルーターとして使用します）
* Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64
* プレフィックス情報オプション：長さ= 4、プレフィックス= 2001：db8：cafe :: / 64
* Recursive DNS Server Option: length = 3, addresses = [2001:db8:cafe::53]
* 再帰DNSサーバーオプション：長さ= 3、アドレス= [2001：db8：cafe :: 53]
* PvD Option header: length = 3, PvD ID FQDN = foo.example.org., R-flag = 0 (actual length of the header 24 bytes = 3 * 8 bytes)
* PvDオプションヘッダー：長さ= 3、PvD ID FQDN = foo.example.org。、Rフラグ= 0（ヘッダーの実際の長さ24バイト= 3 * 8バイト）
The second RA contains a prefix usable only by PvD-aware hosts. Non-PvD-aware hosts will ignore this RA; hence, only the PvD-aware hosts will be multihomed.
2番目のRAには、PvD対応ホストでのみ使用可能なプレフィックスが含まれています。 PvD非対応のホストはこのRAを無視します。したがって、PvD対応のホストのみがマルチホームになります。
* RA Header: router lifetime = 0 (non-PvD-aware hosts will not use this router as a default router)
* RAヘッダー：ルーターライフタイム= 0（PvD非対応のホストはこのルーターをデフォルトルーターとして使用しません）
* PvD Option header: length = 3 + 2 + 4 + 3, PvD ID FQDN = bar.example.org., R-flag = 1 (actual length of the header 24 bytes = 3 * 8 bytes)
* PvDオプションヘッダー：長さ= 3 + 2 + 4 + 3、PvD ID FQDN = bar.example.org。、Rフラグ= 1（ヘッダーの実際の長さ24バイト= 3 * 8バイト）
- RA Header: router lifetime = 1600 (PvD-aware hosts will use this router as a default router), implicit length = 2
- RAヘッダー：ルーターライフタイム= 1600（PvD対応ホストはこのルーターをデフォルトルーターとして使用します）、暗黙の長さ= 2
- Prefix Information Option: length = 4, prefix = 2001:db8:f00d::/64
- プレフィックス情報オプション：長さ= 4、プレフィックス= 2001：db8：f00d :: / 64
- Recursive DNS Server Option: length = 3, addresses = [2001:db8:f00d::53]
- 再帰DNSサーバーオプション：長さ= 3、アドレス= [2001：db8：f00d :: 53]
Note: the above examples assume that the router has received its PvD IDs from upstream routers or via some other configuration mechanism. Another document could define ways for the router to generate its own PvD IDs to allow the above scenario in the absence of PvD ID provisioning.
注：上記の例は、ルーターが上流ルーターから、または他の構成メカニズムを介してPvD IDを受信していることを前提としています。別のドキュメントでは、ルーターが独自のPvD IDを生成して、PvD IDプロビジョニングがない場合に上記のシナリオを可能にする方法を定義できます。
In this example, the router indicates that it provides Additional Information using the H-flag. The Sequence Number on the PvD Option is set to 7 in this example.
この例では、ルータはHフラグを使用して追加情報を提供することを示しています。この例では、PvDオプションのシーケンス番号は7に設定されています。
* RA Header: router lifetime = 6000
* RAヘッダー：ルーターの寿命= 6000
* Prefix Information Option: length = 4, prefix = 2001:db8:cafe::/64
* プレフィックス情報オプション：長さ= 4、プレフィックス= 2001：db8：cafe :: / 64
* Recursive DNS Server Option: length = 3, addresses = [2001:db8:cafe::53]
* 再帰DNSサーバーオプション：長さ= 3、アドレス= [2001：db8：cafe :: 53]
* PvD Option header: length = 3, PvD ID FQDN = cafe.example.com., Sequence Number = 7, R-flag = 0, H-flag = 1 (actual length of the header with padding 24 bytes = 3 * 8 bytes)
* PvDオプションヘッダー：長さ= 3、PvD ID FQDN = cafe.example.com。、シーケンス番号= 7、Rフラグ= 0、Hフラグ= 1（パディング付きヘッダーの実際の長さ= 24バイト= 3 * 8バイト） ）
A PvD-aware host will fetch <https://cafe.example.com/.well-known/ pvd> to get the additional information. The following example shows a GET request that the host sends, in HTTP/2 syntax [RFC7540]:
PvD対応のホストは<https://cafe.example.com/.well-known/pvd>をフェッチして、追加情報を取得します。次の例は、ホストが送信するGETリクエストをHTTP / 2構文[RFC7540]で示しています。
:method = GET
:scheme = https
:authority = cafe.example.com
:path = /.well-known/pvd
accept = application/pvd+json
The HTTP server will respond with the JSON Additional Information:
HTTPサーバーはJSONの追加情報で応答します。
:status = 200
content-type = application/pvd+json
content-length = 116
{
"identifier": "cafe.example.com.",
"expires": "2020-05-23T06:00:00Z",
"prefixes": ["2001:db8:cafe::/48"],
}
At this point, the host has the PvD Additional Information and knows the expiry time. When either the expiry time passes or a new Sequence Number is provided in an RA, the host will re-fetch the Additional Information.
この時点で、ホストにはPvDの追加情報があり、有効期限がわかります。有効期限が経過するか、RAに新しいシーケンス番号が提供されると、ホストは追加情報を再フェッチします。
For example, if the router sends a new RA with the Sequence Number set to 8, the host will re-fetch the Additional Information:
たとえば、ルーターがシーケンス番号を8に設定して新しいRAを送信した場合、ホストは追加情報を再フェッチします。
* PvD Option header: length = 3 + 5 + 4 , PvD ID FQDN = cafe.example.com., Sequence Number = 8, R-flag = 0, H-flag = 1 (actual length of the header with padding 24 bytes = 3 * 8 bytes)
* PvDオプションヘッダー：長さ= 3 + 5 + 4、PvD ID FQDN = cafe.example.com。、シーケンス番号= 8、Rフラグ= 0、Hフラグ= 1（24バイトのパディングを含むヘッダーの実際の長さ= 3 * 8バイト）
However, if the router sends a new RA, but the Sequence Number has not changed, the host would not re-fetch the Additional Information (until and unless the expiry time of the Additional Information has passed).
ただし、ルーターが新しいRAを送信してもシーケンス番号が変更されていない場合、ホストは追加情報を再フェッチしません（追加情報の有効期限が経過するまでは）。
Since the PvD Option can contain an RA header and other RA options, any security considerations that apply for specific RA options continue to apply when used within a PvD Option.
PvDオプションにはRAヘッダーとその他のRAオプションを含めることができるため、特定のRAオプションに適用されるセキュリティに関する考慮事項は、PvDオプション内で使用される場合も引き続き適用されます。
Although some solutions such as IPsec or SEcure Neighbor Discovery (SeND) [RFC3971] can be used in order to secure the IPv6 Neighbor Discovery Protocol, in practice, actual deployments largely rely on link-layer or physical-layer security mechanisms (e.g., 802.1x [IEEE8021X]) in conjunction with RA-Guard [RFC6105].
IPsecやSEcure Neighbor Discovery（SeND）[RFC3971]などのいくつかのソリューションはIPv6 Neighbor Discovery Protocolを保護するために使用できますが、実際には、実際の展開は主にリンク層または物理層のセキュリティメカニズム（802.1など）に依存していますx [IEEE8021X]）RA-Guard [RFC6105]と組み合わせて。
If multiple RAs are sent for a single PvD to avoid fragmentation, dropping packets can lead to processing only part of a PvD Option, which could lead to hosts receiving only part of the contained options. As discussed in Section 3.2, routers MUST include the PvD Option in all fragments generated.
断片化を回避するために単一のPvDに複数のRAが送信される場合、パケットをドロップするとPvDオプションの一部のみが処理され、ホストが含まれているオプションの一部のみを受信する可能性があります。セクション3.2で説明したように、ルーターは、生成されるすべてのフラグメントにPvDオプションを含める必要があります。
This specification does not improve the Neighbor Discovery Protocol security model but simply validates that the owner of the PvD FQDN authorizes its use with the prefix advertised by the router. In combination with implicit trust in the local router (if present), this gives the host some level of assurance that the PvD is authorized for use in this environment. However, when the local router cannot be trusted, no such guarantee is available.
この仕様は、近隣探索プロトコルのセキュリティモデルを改善するのではなく、PvD FQDNの所有者がルーターによってアドバタイズされたプレフィックスでの使用を許可することを検証するだけです。ローカルルーター（存在する場合）の暗黙的な信頼と組み合わせることで、PvDがこの環境での使用を承認されていることをホストにある程度保証します。ただし、ローカルルーターを信頼できない場合、そのような保証はありません。
It must be noted that Section 4.4 of this document only provides reasonable assurance against misconfiguration but does not prevent a hostile network access provider from advertising incorrect information that could lead applications or hosts to select a hostile PvD. However, a host that correctly implements the multiple PvD architecture [RFC7556] using the mechanism described in this document will be less susceptible to some attacks than a host that does not by being able to check for the various misconfigurations or inconsistencies described in this document.
このドキュメントのセクション4.4は、設定ミスに対する妥当な保証を提供するだけであり、敵意のあるネットワークアクセスプロバイダーが、アプリケーションまたはホストが敵対的なPvDを選択する可能性のある不正な情報をアドバタイズすることを妨げないことに注意する必要があります。ただし、このドキュメントで説明されているメカニズムを使用して複数のPvDアーキテクチャ[RFC7556]を正しく実装するホストは、このドキュメントで説明されているさまざまな設定ミスや矛盾をチェックできないホストよりも、一部の攻撃を受けにくくなります。
Since expiration times provided in PvD Additional Information use absolute time, these values can be skewed due to clock skew or for hosts without an accurate time base. Such time values MUST NOT be used for security-sensitive functionality or decisions.
PvD追加情報で提供される有効期限は絶対時間を使用するため、これらの値は、クロックスキューが原因で、または正確なタイムベースのないホストでスキューされる可能性があります。このような時間の値は、セキュリティの影響を受けやすい機能や決定に使用してはなりません（MUST NOT）。
An attacker generating RAs on a local network can use the H-flag and the PvD ID to cause hosts on the network to make requests for PvD Additional Information from servers. This can become a denial-of-service attack, in which an attacker can amplify its attack by triggering TLS connections to arbitrary servers in response to sending UDP packets containing RA messages. To mitigate this attack, hosts MUST:
ローカルネットワークでRAを生成する攻撃者は、HフラグとPvD IDを使用して、ネットワーク上のホストにサーバーからのPvD追加情報を要求させることができます。これはサービス拒否攻撃になる可能性があり、攻撃者はRAメッセージを含むUDPパケットの送信に応答して任意のサーバーへのTLS接続をトリガーすることにより、攻撃を拡大できます。この攻撃を緩和するために、ホストは以下を実行する必要があります。
* limit the rate at which they fetch a particular PvD's Additional Information;
* 特定のPvDの追加情報を取得する速度を制限します。
* limit the rate at which they fetch any PvD Additional Information on a given local network;
* 特定のローカルネットワークでPvD追加情報を取得する速度を制限します。
* stop making requests for a PvD ID that does not respond with valid JSON; and
* 有効なJSONで応答しないPvD IDのリクエストを停止します。そして
* stop making requests for all PvD IDs once a certain number of failures is reached on a particular network.
* 特定のネットワークで特定の数の障害が発生すると、すべてのPvD IDのリクエストを停止します。
Details are provided in Section 4.1. This attack can be targeted at generic web servers, in which case the host behavior of stopping requesting for any server that doesn't behave like a PvD Additional Information server is critical. Limiting requests for a specific PvD ID might not be sufficient if the attacker changes the PvD ID values quickly, so hosts also need to stop requesting if they detect consistent failure when on a network that is under attack. For cases in which an attacker is pointing hosts at a valid PvD Additional Information server (but one that is not actually associated with the local network), the server SHOULD reject any requests that do not originate from the expected IPv6 prefix as described in Section 4.2.
詳細はセクション4.1に記載されています。この攻撃は一般的なWebサーバーを対象とすることができます。この場合、PvD追加情報サーバーのように動作しないサーバーへのリクエストを停止するホストの動作が重要です。攻撃者がPvD ID値をすばやく変更する場合、特定のPvD IDに対する要求を制限するだけでは不十分な場合があるため、攻撃を受けているネットワーク上でホストが一貫した障害を検出した場合、ホストも要求を停止する必要があります。攻撃者がホストを有効なPvD追加情報サーバー（実際にはローカルネットワークに関連付けられていないサーバー）に向けている場合、サーバーは、セクション4.2で説明されているように、予想されるIPv6プレフィックスから発信されていない要求を拒否する必要があります（SHOULD）。 。
Retrieval of the PvD Additional Information over HTTPS requires early communications between the connecting host and a server that may be located further than the first-hop router. Although this server is likely to be located within the same administrative domain as the default router, this property can't be ensured. To minimize the leakage of identity information while retrieving the PvD Additional Information, hosts SHOULD make use of an IPv6 temporary address and SHOULD NOT include any privacy-sensitive data, such as a User-Agent header field or an HTTP cookie.
HTTPSを介したPvDの追加情報の取得には、接続しているホストと、ファーストホップルーターよりも遠くにあるサーバーとの間の早期の通信が必要です。このサーバーはデフォルトのルーターと同じ管理ドメイン内にある可能性が高いですが、このプロパティは保証されません。 PvDの追加情報を取得する際のID情報の漏洩を最小限に抑えるため、ホストはIPv6一時アドレスを使用する必要があり（SHOULD）、User-AgentヘッダーフィールドやHTTP Cookieなどのプライバシーに配慮したデータを含めないでください。
Hosts might not always fetch PvD Additional Information, depending on whether or not they expect to use the information. However, if a host allows requesting Additional Information for certain PvD IDs, an attacker could send various PvD IDs in RAs to detect which PvD IDs are allowed by the client. To avoid this, hosts SHOULD either fetch Additional Information for all eligible PvD IDs on a given local network or fetch the information for none of them.
ホストは、情報を使用することを期待するかどうかに応じて、常にPvD追加情報をフェッチするとは限りません。ただし、ホストが特定のPvD IDの追加情報の要求を許可している場合、攻撃者はRAでさまざまなPvD IDを送信して、クライアントで許可されているPvD IDを検出する可能性があります。これを回避するために、ホストは、特定のローカルネットワーク上のすべての適格なPvD IDの追加情報をフェッチするか、いずれの情報もフェッチしないでください。
From a user privacy perspective, retrieving the PvD Additional Information is not different from establishing a first connection to a remote server or even performing a single DNS lookup. For example, most operating systems already perform early queries to static web sites, such as <http://captive.example.com/hotspot-detect.html>, in order to detect the presence of a captive portal.
ユーザーのプライバシーの観点から見ると、PvDの追加情報の取得は、リモートサーバーへの最初の接続の確立や、単一のDNSルックアップの実行と同じです。たとえば、ほとんどのオペレーティングシステムは、キャプティブポータルの存在を検出するために、<http://captive.example.com/hotspot-detect.html>などの静的Webサイトへの初期のクエリをすでに実行しています。
The DNS queries associated with the PvD Additional Information MUST use the DNS servers indicated by the associated PvD, as described in Section 4.1. This ensures the name of the PvD Additional Information server is not unintentionally sent on another network, thus leaking identifying information about the networks with which the client is associated.
セクション4.1で説明されているように、PvDの追加情報に関連付けられているDNSクエリは、関連付けられているPvDによって示されるDNSサーバーを使用する必要があります。これにより、PvD追加情報サーバーの名前が誤って別のネットワークに送信されることがなくなり、クライアントが関連付けられているネットワークに関する識別情報が漏洩することを防ぎます。
There may be some cases where hosts, for privacy reasons, should refrain from accessing servers that are located outside a certain network boundary. In practice, this could be implemented as an allowed list of 'trusted' FQDNs and/or IP prefixes that the host is allowed to communicate with. In such scenarios, the host SHOULD check that the provided PvD ID, as well as the IP address that it resolves into, are part of the allowed list.
プライバシー上の理由から、ホストが特定のネットワーク境界の外にあるサーバーへのアクセスを控える必要がある場合があります。実際には、これは、ホストが通信を許可されている「信頼できる」FQDNやIPプレフィックスの許可リストとして実装できます。そのようなシナリオでは、ホストは、提供されたPvD ID、および解決先のIPアドレスが許可リストの一部であることを確認する必要があります（SHOULD）。
Network operators SHOULD restrict access to PvD Additional Information to only expose it to hosts that are connected to the local network, especially if the Additional Information would provide information about local network configuration to attackers. This can be implemented by allowing access from the addresses and prefixes that the router provides for the PvD, which will match the prefixes contained in the PvD Additional Information. This technique is described in Section 4.2.
ネットワークオペレーターは、PvD追加情報へのアクセスを制限して、ローカルネットワークに接続されているホストにのみ公開する必要があります（特に、追加情報がローカルネットワーク構成に関する情報を攻撃者に提供する場合）。これは、ルーターがPvDに提供するアドレスとプレフィックスからのアクセスを許可することで実装できます。これは、PvD追加情報に含まれるプレフィックスと一致します。この手法については、セクション4.2で説明します。
IANA has removed the 'reclaimable' tag for value 21 for the PvD Option in the "IPv6 Neighbor Discovery Option Formats" registry.
IANAは、「IPv6 Neighbor Discovery Option Formats」レジストリのPvDオプションの値21の「再利用可能な」タグを削除しました。
IANA has added a new entry in the "Well-Known URIs" registry [RFC8615] with the following information:
IANAは、「既知のURI」レジストリ[RFC8615]に次の情報を含む新しいエントリを追加しました。
URI suffix: pvd
URIサフィックス：pvd
Change controller: IETF
コントローラの変更：IETF
Specification document: RFC 8801
仕様書：RFC 8801
Status: permanent
ステータス：永続的
Related information: N/A
関連情報：なし
IANA has created and will maintain a new registry called "Additional Information PvD Keys", which reserves JSON keys for use in PvD Additional Information. The initial contents of this registry are given in Section 4.3 (both the table of mandatory keys and the table of optional keys).
IANAは、「追加情報PvDキー」と呼ばれる新しいレジストリを作成して維持します。これは、PvD追加情報で使用するためのJSONキーを予約します。このレジストリの最初の内容はセクション4.3に記載されています（必須キーのテーブルとオプションキーのテーブルの両方）。
The status of a key as mandatory or optional is intentionally not denoted in the table to allow for flexibility in future use cases. Any new assignments of keys will be considered as optional for the purpose of the mechanism described in this document.
必須またはオプションとしてのキーのステータスは、将来のユースケースでの柔軟性を考慮して、意図的に表に示されていない。キーの新しい割り当ては、このドキュメントで説明されているメカニズムの目的ではオプションと見なされます。
New assignments in the "Additional Information PvD Keys" registry will be administered by IANA through Expert Review [RFC8126]. Experts are requested to ensure that defined keys do not overlap in names or semantics and that they represent non-vendor-specific use cases. Vendor-specific keys SHOULD use sub-dictionaries, as described in Section 4.3.
「追加情報PvDキー」レジストリの新しい割り当ては、エキスパートレビュー[RFC8126]を通じてIANAによって管理されます。専門家は、定義されたキーが名前やセマンティクスで重複しないこと、およびベンダー固有でない使用例を表すことを確認するように要求されます。セクション4.3で説明されているように、ベンダー固有のキーはサブディクショナリを使用する必要があります（SHOULD）。
IANA has placed the "Additional Information PvD Keys" registry within a new registry entitled "Provisioning Domains (PvDs)".
IANAは、「追加情報PvDキー」レジストリを「プロビジョニングドメイン（PvD）」という名前の新しいレジストリ内に配置しました。
IANA has also created and will maintain a new registry entitled "PvD Option Flags". This new registry reserves bit positions from 0 to 11 to be used in the PvD Option bitmask. This document assigns bit positions 0, 1, and 2 as shown in the table below. Future assignments require Standards Action [RFC8126].
IANAは、「PvDオプションフラグ」というタイトルの新しいレジストリを作成し、維持します。この新しいレジストリは、PvDオプションのビットマスクで使用される0〜11のビット位置を予約しています。このドキュメントでは、次の表に示すように、ビット位置0、1、および2を割り当てます。今後の割り当てには、標準アクション[RFC8126]が必要です。
+======+============+===========+
| Bit | Name | Reference |
+======+============+===========+
| 0 | H-flag | RFC 8801 |
+------+------------+-----------+
| 1 | L-flag | RFC 8801 |
+------+------------+-----------+
| 2 | R-flag | RFC 8801 |
+------+------------+-----------+
| 3-11 | Unassigned | |
+------+------------+-----------+
Table 3
表3
Since these flags apply to an IPv6 Router Advertisement Option, IANA has placed this registry under the existing "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry and provided a link on the new "Provisioning Domains (PvDs)" registry.
これらのフラグはIPv6ルーターアドバタイズメントオプションに適用されるため、IANAはこのレジストリを既存の「インターネット制御メッセージプロトコルバージョン6（ICMPv6）パラメータ」レジストリの下に置き、新しい「プロビジョニングドメイン（PvD）」レジストリへのリンクを提供しました。
This document registers the media type for PvD JSON text, "application/pvd+json".
このドキュメントは、PvD JSONテキストのメディアタイプ「application / pvd + json」を登録します。
Type name: application
タイプ名：アプリケーション
Subtype name: pvd+json
サブタイプ名：pvd + json
Required parameters: N/A
必須パラメーター：なし
Optional parameters: N/A
オプションのパラメーター：N / A
Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type.
エンコーディングに関する考慮事項：エンコーディングに関する考慮事項は、「application / json」メディアタイプに指定されたものと同じです。
Security considerations: See Section 6 of RFC 8801.
セキュリティに関する考慮事項：RFC 8801のセクション6をご覧ください。
Interoperability considerations: This document specifies the format of conforming messages and the interpretation thereof.
相互運用性に関する考慮事項：このドキュメントでは、適合メッセージの形式とその解釈について説明します。
Published specification: RFC 8801
公開された仕様：RFC 8801
Applications that use this media type: This media type is intended to be used by networks advertising additional Provisioning Domain information and clients looking up such information.
このメディアタイプを使用するアプリケーション：このメディアタイプは、追加のプロビジョニングドメイン情報をアドバタイズするネットワークおよびそのような情報を検索するクライアントが使用することを目的としています。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：なし
Additional information: N/A
追加情報：なし
Person & email address to contact for further information: See Authors' Addresses section
詳細については連絡先の人とメールアドレス：作者のアドレスセクションを参照してください
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: N/A
使用上の制限：N / A
Author: IETF
著者：IETF
Change controller: IETF
コントローラの変更：IETF
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。
[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。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339]クライン、G、およびC.ニューマン、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https://www.rfc-editor.org/info/rfc3339 >。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4191] Draves、R。およびD. Thaler、「デフォルトのルーター設定とより具体的なルート」、RFC 4191、DOI 10.17487 / RFC4191、2005年11月、<https://www.rfc-editor.org/info/rfc4191 >。
[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case Insensitivity Clarification", RFC 4343, DOI 10.17487/RFC4343, January 2006, <https://www.rfc-editor.org/info/rfc4343>.
[RFC4343] Eastlake 3rd、D。、「ドメインネームシステム（DNS）の大文字と小文字の区別の明確化」、RFC 4343、DOI 10.17487 / RFC4343、2006年1月、<https://www.rfc-editor.org/info/rfc4343>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：/ /www.rfc-editor.org/info/rfc4861>。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.
[RFC4941] Narten、T.、Draves、R。、およびS. Krishnan、「IPv6でのステートレスアドレス自動構成のプライバシー拡張」、RFC 4941、DOI 10.17487 / RFC4941、2007年9月、<https：//www.rfc-editor .org / info / rfc4941>。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724]ターラー、D。、エド。 、<https://www.rfc-editor.org/info/rfc6724>。
[RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery", RFC 6980, DOI 10.17487/RFC6980, August 2013, <https://www.rfc-editor.org/info/rfc6980>.
[RFC6980] Gont、F。、「IPv6 Neighbor DiscoveryによるIPv6フラグメンテーションのセキュリティへの影響」、RFC 6980、DOI 10.17487 / RFC6980、2013年8月、<https://www.rfc-editor.org/info/rfc6980>。
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.
[RFC7493]ブレイ、T。、編、「The I-JSON Message Format」、RFC 7493、DOI 10.17487 / RFC7493、2015年3月、<https://www.rfc-editor.org/info/rfc7493>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, <https://www.rfc-editor.org/info/rfc7556>.
[RFC7556] Anipko、D。、編、「Multiple Provisioning Domain Architecture」、RFC 7556、DOI 10.17487 / RFC7556、2015年6月、<https://www.rfc-editor.org/info/rfc7556>。
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, <https://www.rfc-editor.org/info/rfc8028>.
[RFC8028]ベイカー、F.、B。カーペンター、「マルチプレフィックスネットワーク内のホストによるファーストホップルータの選択」、RFC 8028、DOI 10.17487 / RFC8028、2016年11月、<https：//www.rfc-editor。 org / info / rfc8028>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[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>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.
[RFC8615]ノッティンガム、M。、「よく知られているUniform Resource Identifiers（URIs）」、RFC 8615、DOI 10.17487 / RFC8615、2019年5月、<https://www.rfc-editor.org/info/rfc8615>。
[IANA-URN] IANA, "Uniform Resource Names (URN) Namespaces", <https://www.iana.org/assignments/urn-namespaces/>.
[IANA-URN] IANA、「Uniform Resource Names（URN）Namespaces」、<https://www.iana.org/assignments/urn-namespaces/>。
[IEEE8021X] IEEE, "IEEE Standard for Local and Metropolitan Area Networks -- Port-Based Network Access Control", IEEE 802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, <https://ieeexplore.ieee.org/document/9018454>.
[IEEE8021X] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Port-Based Network Access Control」、IEEE 802.1X-2020、DOI 10.1109 / IEEESTD.2020.9018454、<https://ieeexplore.ieee.org/document/ 9018454>。
[MPVD-API] Kline, E., "Multiple Provisioning Domains API Requirements", Work in Progress, Internet-Draft, draft-kline-mif-mpvd-api-reqs-00, 1 November 2015, <https://tools.ietf.org/html/draft-kline-mif-mpvd-api-reqs-00>.
[MPVD-API] Kline、E。、「Multiple Provisioning Domains API Requirements」、Work in Progress、Internet-Draft、draft-kline-mif-mpvd-api-reqs-00、2015年11月1日、<https：// tools .ietf.org / html / draft-kline-mif-mpvd-api-reqs-00>。
[MPVD-DNS] Stenberg, M. and S. Barth, "Multiple Provisioning Domains using Domain Name System", Work in Progress, Internet-Draft, draft-stenberg-mif-mpvd-dns-00, 15 October 2015, <https://tools.ietf.org/html/draft-stenberg-mif-mpvd-dns-00>.
[MPVD-DNS] Stenberg、M。、およびS. Barth、「ドメインネームシステムを使用した複数のプロビジョニングドメイン」、進行中の作業、インターネットドラフト、draft-stenberg-mif-mpvd-dns-00、2015年10月15日、<https ：//tools.ietf.org/html/draft-stenberg-mif-mpvd-dns-00>。
[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。、「Dynamic Host Configuration Protocol」、RFC 2131、DOI 10.17487 / RFC2131、1997年3月、<https://www.rfc-editor.org/info/rfc2131>。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003, <https://www.rfc-editor.org/info/rfc3646>.
[RFC3646] Droms、R。、編、「IPv6の動的ホスト構成プロトコルのDNS構成オプション（DHCPv6）」、RFC 3646、DOI 10.17487 / RFC3646、2003年12月、<https://www.rfc-editor.org / info / rfc3646>。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「SEcure Neighbor Discovery（SEND）」、RFC 3971、DOI 10.17487 / RFC3971、2005年3月、<https：/ /www.rfc-editor.org/info/rfc3971>。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006, <https://www.rfc-editor.org/info/rfc4389>.
[RFC4389] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、RFC 4389、DOI 10.17487 / RFC4389、2006年4月、<https：//www.rfc-editor。 org / info / rfc4389>。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, <https://www.rfc-editor.org/info/rfc6105>.
[RFC6105] Levy-Abegnoli、E.、Van de Velde、G.、Popoviciu、C。、およびJ. Mohacsi、「IPv6 Router Advertisement Guard」、RFC 6105、DOI 10.17487 / RFC6105、2011年2月、<https：// www.rfc-editor.org/info/rfc6105>。
[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] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでのX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<https： //www.rfc-editor.org/info/rfc6146>。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P。、およびI. van Beijnum、「DNS64：DNS拡張機能によるIPv6クライアントからIPv4サーバーへのネットワークアドレス変換」、RFC 6147、DOI 10.17487 / RFC6147、4月2011、<https://www.rfc-editor.org/info/rfc6147>。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <https://www.rfc-editor.org/info/rfc6296>.
[RFC6296] Wasserman、M。およびF. Baker、「IPv6-to-IPv6 Network Prefix Translation」、RFC 6296、DOI 10.17487 / RFC6296、2011年6月、<https://www.rfc-editor.org/info/rfc6296 >。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、and C. Adams、 "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol-OCSP"、RFC 6960、DOI 10.17487 / RFC6960、2013年6月、<https://www.rfc-editor.org/info/rfc6960>。
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7049] Bormann、C。およびP. Hoffman、「簡潔なバイナリオブジェクト表現（CBOR）」、RFC 7049、DOI 10.17487 / RFC7049、2013年10月、<https://www.rfc-editor.org/info/rfc7049> 。
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP) Mobile Interface to a LAN Link", RFC 7278, DOI 10.17487/RFC7278, June 2014, <https://www.rfc-editor.org/info/rfc7278>.
[RFC7278] Byrne、C.、Drown、D。、およびA. Vizdal、「IPv6 / 64プレフィックスを第3世代パートナーシッププロジェクト（3GPP）モバイルインターフェイスからLANリンクに拡張」、RFC 7278、DOI 10.17487 / RFC7278、 2014年6月、<https://www.rfc-editor.org/info/rfc7278>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R。、およびM. Thomson、編、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https：// www.rfc-editor.org/info/rfc7540>。
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.
[RFC8106] Jeong、J.、Park、S.、Beloeil、L。、およびS. Madanapalli、「DNS構成のIPv6ルーターアドバタイズメントオプション」、RFC 8106、DOI 10.17487 / RFC8106、2017年3月、<https：// www .rfc-editor.org / info / rfc8106>。
[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.、Siodelski、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>。
Acknowledgments
謝辞
Many thanks to Markus Stenberg and Steven Barth for their earlier work on [MPVD-DNS], as well as to Basile Bruneau, who was author of an early draft version of this document.
[MPVD-DNS]に関する初期の作業についてMarkus StenbergとSteven Barthに感謝します。また、このドキュメントの初期ドラフトバージョンの作者であるBasile Bruneauにも感謝します。
Thanks also to Marcus Keane, Mikael Abrahamsson, Ray Bellis, Zhen Cao, Tim Chown, Lorenzo Colitti, Michael Di Bartolomeo, Ian Farrer, Phillip Hallam-Baker, Bob Hinden, Tatuya Jinmei, Erik Kline, Ted Lemon, Paul Hoffman, Dave Thaler, Suresh Krishnan, Gorry Fairhurst, Jen Lenkova, Veronika McKillop, Mark Townsley, and James Woodyatt for useful and interesting discussions and reviews.
Marcus Keane、Mikael Abrahamsson、Ray Bellis、Zhen Cao、Tim Chown、Lorenzo Colitti、Michael Di Bartolomeo、Ian Farrer、Phillip Hallam-Baker、Bob Hinden、Tatuya Jinmei、Erik Kline、Ted Lemon、Paul Hoffman、Dave Thalerにも感謝します、有益で興味深いディスカッションとレビューのためのSuresh Krishnan、Gorry Fairhurst、Jen Lenkova、Veronika McKillop、Mark Townsley、James Woodyatt。
Finally, special thanks to Thierry Danis for his valuable input and implementation efforts, Tom Jones for his integration effort into the NEAT project, and Rigil Salim for his implementation work.
最後に、貴重な入力と実装の取り組みについてはThierry Danisに、NEATプロジェクトへの統合作業についてはTom Jonesを、実装作業についてはRigil Salimに特に感謝します。
Authors' Addresses
著者のアドレス
Pierre Pfister Cisco 11 Rue Camille Desmoulins 92130 Issy-les-Moulineaux France
ピエールフィスターシスコ11 Rue Camille Desmoulins 92130イシレムリノーフランス
Email: ppfister@cisco.com
Éric Vyncke Cisco De Kleetlaan, 6 1831 Diegem Belgium
ÉricVyncke Cisco De Kleetlaan、6 1831 Diegem Belgium
Email: evyncke@cisco.com
Tommy Pauly Apple Inc. One Apple Park Way Cupertino, California 95014 United States of America
トミーポーリーアップル社ワンアップルパークウェイクパチーノ、カリフォルニア95014アメリカ合衆国
Email: tpauly@apple.com
David Schinazi Google LLC 1600 Amphitheatre Parkway Mountain View, California 94043 United States of America
David Schinazi Google LLC 1600 Amphitheatre Parkway Mountain View、California 94043 United States of America
Email: dschinazi.ietf@gmail.com
Wenqin Shao Cisco 11 Rue Camille Desmoulins 92130 Issy-les-Moulineaux France
Wenqin Shao Cisco 11 Rue Camille Desmoulins 92130イシレムリノーフランス
Email: wenshao@cisco.com