Network Working Group J. Arkko, Ed.
Request for Comments: 3971 Ericsson
Category: Standards Track J. Kempf
DoCoMo Communications Labs USA
B. Zill
Microsoft
P. Nikander
Ericsson
March 2005
SEcure Neighbor Discovery (SEND)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec.
IPv6ノードは、リンク上の他のノードを発見するためにルータを見つけるために、それらのリンク層アドレスを決定するため、およびアクティブ近隣へのパスについての到達可能性情報を維持するために近隣探索プロトコル（NDP）を使用します。固定されていない場合は、NDPは様々な攻撃に対して脆弱です。この文書では、NDPのためのセキュリティ・メカニズムを指定します。元NDP仕様のものとは異なり、これらのメカニズムは、IPsecを使用しないでください。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . 4
2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Neighbor and Router Discovery Overview. . . . . . . . . . . . 6
4. Secure Neighbor Discovery Overview. . . . . . . . . . . . . . 8
5. Neighbor Discovery Protocol Options . . . . . . . . . . . . . 9
5.1. CGA Option. . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Processing Rules for Senders. . . . . . . . . . 11
5.1.2. Processing Rules for Receivers. . . . . . . . . 12
5.1.3. Configuration . . . . . . . . . . . . . . . . . 13
5.2. RSA Signature Option. . . . . . . . . . . . . . . . . . 14
5.2.1. Processing Rules for Senders. . . . . . . . . . 16
5.2.2. Processing Rules for Receivers. . . . . . . . . 16
5.2.3. Configuration . . . . . . . . . . . . . . . . . 17
5.2.4. Performance Considerations. . . . . . . . . . . 18
5.3. Timestamp and Nonce Options . . . . . . . . . . . . . . 19
5.3.1. Timestamp Option. . . . . . . . . . . . . . . . 19
5.3.2. Nonce Option. . . . . . . . . . . . . . . . . . 20
5.3.3. Processing Rules for Senders. . . . . . . . . . 21
5.3.4. Processing Rules for Receivers. . . . . . . . . 21
6. Authorization Delegation Discovery. . . . . . . . . . . . . . 24
6.1. Authorization Model . . . . . . . . . . . . . . . . . . 24
6.2. Deployment Model. . . . . . . . . . . . . . . . . . . . 25
6.3. Certificate Format. . . . . . . . . . . . . . . . . . . 26
6.3.1. Router Authorization Certificate Profile. . . . 26
6.3.2. Suitability of Standard Identity Certificates . 29
6.4. Certificate Transport . . . . . . . . . . . . . . . . . 29
6.4.1. Certification Path Solicitation Message Format. 30
6.4.2. Certification Path Advertisement Message Format 32
6.4.3. Trust Anchor Option . . . . . . . . . . . . . . 34
6.4.4. Certificate Option. . . . . . . . . . . . . . . 36
6.4.5. Processing Rules for Routers. . . . . . . . . . 37
6.4.6. Processing Rules for Hosts. . . . . . . . . . . 38
6.5. Configuration . . . . . . . . . . . . . . . . . . . . . 39
7. Addressing. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. CGAs. . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2. Redirect Addresses. . . . . . . . . . . . . . . . . . . 40
7.3. Advertised Subnet Prefixes. . . . . . . . . . . . . . . 40
7.4. Limitations . . . . . . . . . . . . . . . . . . . . . . 41
8. Transition Issues . . . . . . . . . . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9.1. Threats to the Local Link Not Covered by SEND . . . . . 44
9.2. How SEND Counters Threats to NDP. . . . . . . . . . . . 45
9.2.1. Neighbor Solicitation/Advertisement Spoofing. . 45
9.2.2. Neighbor Unreachability Detection Failure . . . 46
9.2.3. Duplicate Address Detection DoS Attack. . . . . 46
9.2.4. Router Solicitation and Advertisement Attacks . 46
9.2.5. Replay Attacks. . . . . . . . . . . . . . . . . 47
9.2.6. Neighbor Discovery DoS Attack . . . . . . . . . 48
9.3. Attacks against SEND Itself . . . . . . . . . . . . . . 48
10. Protocol Values . . . . . . . . . . . . . . . . . . . . . . . 49
10.1. Constants . . . . . . . . . . . . . . . . . . . . . . . 49
10.2. Variables . . . . . . . . . . . . . . . . . . . . . . . 49
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 50
12.1. Normative References. . . . . . . . . . . . . . . . . . 50
12.2. Informative References. . . . . . . . . . . . . . . . . 51
Appendices. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
A. Contributors and Acknowledgments. . . . . . . . . . . . 53
B. Cache Management. . . . . . . . . . . . . . . . . . . . 53
C. Message Size When Carrying Certificates . . . . . . . . 54
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 55
Full Copyright Statements . . . . . . . . . . . . . . . . . . . . 56
IPv6 defines the Neighbor Discovery Protocol (NDP) in RFCs 2461 [4] and 2462 [5]. Nodes on the same link use NDP to discover each other's presence and link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. NDP is used by both hosts and routers. Its functions include Neighbor Discovery (ND), Router Discovery (RD), Address Autoconfiguration, Address Resolution, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Redirection.
IPv6は、RFCの2461年に近隣探索プロトコル（NDP）を定義し[4]、2462 [5]。同じリンク上のノードは、ルータを見つけるために、互いの存在とリンク層アドレスを発見するNDPを使用して、アクティブな隣人へのパスについての到達可能性情報を保持します。 NDPは、ホストとルーターの両方で使用されています。その機能は、近隣探索（ND）、ルータ検出（RD）、アドレスの自動構成、アドレス解決、近隣到達不能検出（NUD）、重複アドレス検出（DAD）、およびリダイレクトが含まれます。
The original NDP specifications called for the use of IPsec to protect NDP messages. However, the RFCs do not give detailed instructions for using IPsec to do this. In this particular application, IPsec can only be used with a manual configuration of security associations, due to bootstrapping problems in using IKE [19, 15]. Furthermore, the number of manually configured security associations needed for protecting NDP can be very large [20], making that approach impractical for most purposes.
元NDP仕様はNDPメッセージを保護するためにIPsecを使用するために呼ばれます。しかし、RFCはこれを行うためにIPsecを使用するための詳細な指示を与えることはありません。この特定の用途では、IPsecは唯一によるIKE [19、15]を使用してブートストラップ問題が、セキュリティアソシエーションの手動設定を使用することができます。また、NDPを保護するために必要な手動で設定されたセキュリティアソシエーションの数がほとんどの目的のために実用的でないというアプローチを行う、[20]非常に大きくすることができます。
The SEND protocol is designed to counter the threats to NDP. These threats are described in detail in [22]. SEND is applicable in environments where physical security on the link is not assured (such as over wireless) and attacks on NDP are a concern.
SENDプロトコルは、NDPへの脅威に対抗するために設計されています。これらの脅威は、[22]に詳細に記載されています。 SENDは、リンク上の物理的なセキュリティは、（例えば無線経由など）が保証されていないとNDPへの攻撃が懸念されている環境に適用可能です。
This document is organized as follows. Sections 2 and 3 define some terminology and present a brief review of NDP, respectively. Section 4 describes the overall approach to securing NDP. This approach involves the use of new NDP options to carry public key - based signatures. A zero-configuration mechanism is used for showing address ownership on individual nodes; routers are certified by a trust anchor [7]. The formats, procedures, and cryptographic mechanisms for the zero-configuration mechanism are described in a related specification [11].
次のようにこの文書は、組織化されています。セクション2と3は、それぞれ、いくつかの用語を定義し、NDPの簡単なレビューを提示します。第4節では、NDPを確保する総合的なアプローチを説明しています。ベースの署名 - このアプローチでは、公開鍵を運ぶために新NDPオプションの使用を含みます。ゼロ設定機構は、個々のノード上のアドレスの所有権を示すために使用されます。ルータは、トラストアンカーによって認定されている[7]。ゼロコンフィギュレーションメカニズムの形式、手順、および暗号化機構は、関連仕様書[11]に記載されています。
The required new NDP options are discussed in Section 5. Section 6 describes the mechanism for distributing certification paths to establish an authorization delegation chain to a trust anchor.
必要な新しいNDPオプションは、第5節第6節で議論されているトラストアンカーへの権限委譲チェーンを確立するための証明書パスを配布するためのメカニズムについて説明します。
Finally, Section 8 discusses the co-existence of secured and unsecured NDP on the same link, and Section 9 discusses security considerations for SEcure Neighbor Discovery (SEND).
最後に、第8節は、同じリンク上の担保と無担保NDPの共存について説明し、第9節では、安全な近隣探索（SEND）のセキュリティの考慮事項について説明します。
The use of identity certificates provisioned on end hosts for authorizing address use is out of the scope for this document, as is the security of NDP when the entity defending an address is not the same as the entity claiming that address (also known as "proxy ND"). These are extensions of SEND that may be treated in separate documents, should the need arise.
NDPのセキュリティであるとしてアドレスを防御エンティティはまた、「プロキシとして知られ、そのアドレスを（主張するエンティティと同じでない場合、アドレスの使用を許可するため、エンドホスト上でプロビジョニングID証明書を使用するには、この文書の範囲外でありますND」）。これらは、必要が生じた場合、別の文書に処理することができるSENDの拡張です。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" are to be interpreted as described in [2].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。キーワード "MUST"、 "NOT MUST"、 "SHOULD NOT"、 "RECOMMENDED"、 "SHOULD"、及び[2]に記載のように解釈される "場合があります"。
Authorization Delegation Discovery (ADD)
認証委任ディスカバリー（ADD）
A process through which SEND nodes can acquire a certification path from a peer node to a trust anchor.
ノードを送信するプロセスは、トラストアンカーにピア・ノードから認証パスを取得することができます。
Certificate Revocation List (CRL)
証明書失効リスト（CRL）
In one method of certificate revocation, an authority periodically issues a signed data structure called the Certificate Revocation List. This is a time-stamped list identifying revoked certificates, signed by the issuer, and made freely available in a public repository.
証明書の失効の一つの方法では、当局は、定期的に証明書失効リストと呼ばれる署名されたデータ構造を発行します。これは、発行者によって署名され、公開リポジトリで自由に利用できるように失効された証明書を、特定するタイムスタンプ付きのリストです。
Certification Path Advertisement (CPA)
証明のパス広告（CPA）
The advertisement message used in the ADD process.
ADDプロセスで使用される広告メッセージ。
Certification Path Solicitation (CPS)
証明のパス要請（CPS）
The solicitation message used in the ADD process.
ADDプロセスで使用される要請メッセージ。
Cryptographically Generated Address (CGA)
暗号的に生成されたアドレス（CGA）
A technique [11] whereby an IPv6 address of a node is cryptographically generated by using a one-way hash function from the node's public key and some other parameters.
ノードのIPv6アドレスが暗号ノードの公開鍵といくつかの他のパラメータから一方向ハッシュ関数を用いて生成する技術[11]。
Distinguished Encoding Rules (DER)
識別符号化規則（DER）
An encoding scheme for data values, defined in [12].
[12]で定義されたデータ値の符号化方式。
Duplicate Address Detection (DAD)
重複アドレス検出（DAD）
A mechanism assuring that two IPv6 nodes on the same link are not using the same address.
同じリンク上の2つのIPv6ノードが同じアドレスを使用していないことを保証するメカニズム。
Fully Qualified Domain Name (FQDN)
完全修飾ドメイン名（FQDN）
A fully qualified domain name consists of a host and domain name, including the top-level domain.
完全修飾ドメイン名は、トップレベルドメインを含め、ホスト名とドメイン名で構成されています。
Internationalized Domain Name (IDN)
国際化ドメイン名（IDN）
Internationalized Domain Names can be used to represent domain names that contain characters outside the ASCII set. See RFC 3490 [9].
国際化ドメイン名はASCIIセット以外の文字を含むドメイン名を表すために使用することができます。 RFC 3490 [9]を参照してください。
Neighbor Discovery (ND)
近隣探索（ND）
The Neighbor Discovery function of the Neighbor Discovery Protocol (NDP). NDP contains functions besides ND.
近隣探索プロトコル（NDP）の近隣探索機能。 NDPはND以外の機能が含まれています。
Neighbor Discovery Protocol (NDP)
近隣探索プロトコル（NDP）
The IPv6 Neighbor Discovery Protocol [7, 8].
IPv6近隣探索プロトコル[7、8]。
The Neighbor Discovery Protocol is a part of ICMPv6 [6].
近隣探索プロトコルは、ICMPv6の[6]の一部です。
Neighbor Unreachability Detection (NUD)
近隣到達不能検出（NUD）
A mechanism used for tracking the reachability of neighbors.
ネイバーの到達可能性を追跡するために使用されるメカニズム。
Non-SEND node
非SENDノード
An IPv6 node that does not implement this specification but uses only the Neighbor Discovery protocol defined in RFCs 2461 and 2462, as updated, without security.
この仕様を実装しますが、セキュリティなしに、更新されたRFC 2461および2462で定義された唯一の近隣探索プロトコルを使用していないIPv6ノード。
Nonce
使節
An unpredictable random or pseudo-random number generated by a node and used exactly once. In SEND, nonces are used to assure that a particular advertisement is linked to the solicitation that triggered it.
予測不可能なランダムまたは疑似乱数は、ノードによって生成され、一度だけ使用されます。 SENDにおいて、ナンスは、特定の広告がそれをトリガ勧誘に連結されることを保証するために使用されます。
Router Authorization Certificate
ルータの認証証明書
An X.509v3 [7] public key certificate using the profile specified in Section 6.3.1.
6.3.1節で指定されたプロファイルを使用してのX.509v3 [7]公開鍵証明書。
SEND node
ノードを送信
An IPv6 node that implements this specification.
この仕様を実装してIPv6ノード。
Router Discovery (RD)
ルーター検出（RD）
Router Discovery allows the hosts to discover what routers exist on the link, and what subnet prefixes are available. Router Discovery is a part of the Neighbor Discovery Protocol.
ルータ検出は、ホストがリンク上に存在するどのようなルータを発見することができ、そしてどのようなサブネットプレフィックスがご利用いただけます。ルーター検出は近隣探索プロトコルの一部です。
Trust Anchor
トラストアンカー
Hosts are configured with a set of trust anchors to protect Router Discovery. A trust anchor is an entity that the host trusts to authorize routers to act as routers. A trust anchor configuration consists of a public key and some associated parameters (see Section 6.5 for a detailed explanation of these parameters).
ホストは、ルータ検出を保護するためのトラストアンカーのセットで構成されています。トラストアンカーは、ホスト信託がルータとして動作するようにルータを承認するエンティティです。トラストアンカーの設定は、公開鍵といくつかの関連するパラメータ（これらのパラメータの詳細な説明については、セクション6.5を参照）で構成されています。
The Neighbor Discovery Protocol has several functions. Many of these are overloaded on a few central message types, such as the ICMPv6 Neighbor Advertisement message. In this section, we review some of these tasks and their effects in order to better understand how the messages should be treated. This section is not normative, and if this section and the original Neighbor Discovery RFCs are in conflict, the original RFCs, as updated, take precedence.
近隣探索プロトコルは、いくつかの機能があります。これらの多くは、ICMPv6の近隣広告メッセージとして、いくつかの中央メッセージタイプにオーバーロードされています。このセクションでは、私たちはより良いメッセージがどのように扱われるべきかを理解するために、これらのタスクとその効果のいくつかを確認します。このセクションは規範的ではなく、このセクションと、元の近隣探索RFCが競合している場合は、元のRFCは、更新されたとして、優先されます。
The main functions of NDP are as follows:
次のようにNDPの主な機能は以下のとおりです。
o The Router Discovery function allows IPv6 hosts to discover the local routers on an attached link. Router Discovery is described in Section 6 of RFC 2461 [4]. The main purpose of Router Discovery is to find neighboring routers willing to forward packets on behalf of hosts. Subnet prefix discovery involves determining which destinations are directly on a link; this information is necessary in order to know whether a packet should be sent to a router or directly to the destination node.
ルーター検出機能O IPv6が取り付けられ、リンクのローカルルータを発見するためにホストできます。ルータ探索は、RFC 2461のセクション6で説明されている[4]。ルーター検出の主な目的は、ホストに代わってパケットを転送するために喜ん隣接しているルータを見つけることです。サブネットプレフィックスの発見は、リンク上で直接である目的地決定することを含みます。この情報は、パケットがルータに直接宛先ノードに送信すべきかどうかを知るために必要です。
o The Redirect function is used for automatically redirecting a host to a better first-hop router, or to inform hosts that a destination is in fact a neighbor (i.e., on-link). Redirect is specified in Section 8 of RFC 2461 [4].
Oリダイレクト機能が自動的より良い最初のホップルータにホストをリダイレクトするために使用される、または宛先が実際に近隣であるホストに通知する（即ち、オンリンク）。リダイレクトは、RFC 2461のセクション8で指定されている[4]。
o Address Autoconfiguration is used for automatically assigning addresses to a host [5]. This allows hosts to operate without explicit configuration related to IP connectivity. The default autoconfiguration mechanism is stateless. To create IP addresses, hosts use any prefix information delivered to them during Router Discovery and then test the newly formed addresses for uniqueness. A stateful mechanism, DHCPv6 [18], provides additional autoconfiguration features.
Oアドレス自動設定は、[5]、自動的にホストにアドレスを割り当てるために使用されます。これは、ホストがIP接続に関連する明示的な設定なしで動作させることができます。デフォルトの自動設定メカニズムはステートレスです。 IPアドレスを作成するには、ホストはRouter Discoveryの間にそれらに配信任意のプレフィックス情報を使用して、独自性のために新たに形成されたアドレスをテストします。ステートフル機構、DHCPv6の[18]、追加の自動設定機能を提供します。
o Duplicate Address Detection (DAD) is used for preventing address collisions [5]: for instance, during Address Autoconfiguration. A node that intends to assign a new address to one of its interfaces first runs the DAD procedure to verify that no other node is using the same address. As the rules forbid the use of an address until it has been found unique, no higher layer traffic is possible until this procedure has been completed. Thus, preventing attacks against DAD can help ensure the availability of communications for the node in question.
O重複検出（DAD）をアドレス[5]のアドレス衝突を防止するために使用される：例えば、アドレス自動設定時。そのインターフェイスのいずれかに新しいアドレスを割り当てるしようノードは、最初は他のノードが同じアドレスを使用していないことを確認するために、DAD手順を実行します。それはユニークな発見されたまでのルールは、アドレスの使用を禁止するように、この手順が完了するまで、何より高い層のトラフィックは可能ではありません。このように、DADに対する攻撃を防止することが問題のノードのための通信の可用性を確保することができます。
o The Address Resolution function allows a node on the link to resolve another node's IPv6 address to the corresponding link-layer address. Address Resolution is defined in Section 7.2 of RFC 2461 [4], and it is used for hosts and routers alike. Again, no higher level traffic can proceed until the sender knows the link layer address of the destination node or the next hop router. Note that the source link layer address on link layer frames is not checked against the information learned through Address Resolution. This allows for an easier addition of network elements such as bridges and proxies and eases the stack implementation requirements, as less information has to be passed from layer to layer.
Oアドレス解決機能は、リンク上のノードは、対応するリンク層アドレスに別のノードのIPv6アドレスを解決することができます。アドレス解決は、RFC 2461 [4]のセクション7.2で定義され、それは同様に、ホストとルータのために使用されます。送信者は、宛先ノードまたはネクストホップルータのリンク層アドレスを知るまでここでも、ないより高いレベルのトラフィックを進めることができます。リンク層フレーム上のソースリンク層アドレスは、アドレス解決を通じて学習した情報と照合されていないことに注意してください。これは、ブリッジとプロキシのようなネットワーク要素のより容易な付加を可能にし、より少ない情報が層から層に渡さなければならないように、スタックの実装要件を緩和します。
o Neighbor Unreachability Detection (NUD) is used for tracking the reachability of neighboring nodes, both hosts and routers. NUD is defined in Section 7.3 of RFC 2461 [4]. NUD is security sensitive, because an attacker could claim that reachability exists when in fact it does not.
O近隣到達不能検出（NUD）は、ホストとルーターの両方を、隣接ノードの到達可能性を追跡するために使用されます。 NUDは、RFC 2461のセクション7.3で定義されている[4]。攻撃者は、実際にはそうでないときの到達性が存在することを主張する可能性があるため、NUDは、セキュリティに敏感です。
The NDP messages follow the ICMPv6 message format. All NDP functions are realized by using the Router Solicitation (RS), Router Advertisement (RA), Neighbor Solicitation (NS), Neighbor Advertisement (NA), and Redirect messages. An actual NDP message includes an NDP message header, consisting of an ICMPv6 header and ND message-specific data, and zero or more NDP options. The NDP message options are formatted in the Type-Length-Value format.
NDPメッセージは、ICMPv6メッセージのフォーマットに従ってください。すべてのNDPの機能は、ルータ要請（RS）、ルータ広告（RA）、近隣要請（NS）、近隣広告（NA）を用いて実現し、メッセージをリダイレクトしています。実際のNDPメッセージはICMPv6のヘッダーとNDメッセージ特有のデータ、及びゼロ以上NDPオプションから成る、NDPメッセージヘッダを含みます。 NDPメッセージオプションはなType-Length-値の形式でフォーマットされています。
<------------NDP Message---------------->
*-------------------------------------------------------------*
| IPv6 Header | ICMPv6 | ND Message- | ND Message |
| Next Header = 58 | Header | specific | Options |
| (ICMPv6) | | data | |
*-------------------------------------------------------------*
<--NDP Message header-->
To secure the various functions in NDP, a set of new Neighbor Discovery options is introduced. They are used to protect NDP messages. This specification introduces these options, an authorization delegation discovery process, an address ownership proof mechanism, and requirements for the use of these components in NDP.
NDPでの様々な機能を確保するために、新しい近隣探索オプションのセットが導入されています。彼らは、NDPメッセージを保護するために使用されています。この仕様は、これらのオプション、承認委譲発見プロセス、アドレス所有権証拠メカニズムを導入し、そしてNDPにおけるこれらのコンポーネントの使用のための要件。
The components of the solution specified in this document are as follows:
次のように、この文書で指定されたソリューションのコンポーネントは次のとおりです。
o Certification paths, anchored on trusted parties, are expected to certify the authority of routers. A host must be configured with a trust anchor to which the router has a certification path before the host can adopt the router as its default router. Certification Path Solicitation and Advertisement messages are used to discover a certification path to the trust anchor without requiring the actual Router Discovery messages to carry lengthy certification paths. The receipt of a protected Router Advertisement message for which no certification path is available triggers the authorization delegation discovery process.
信頼できる関係者に固定Oの認定パスは、ルータの権限を証明することが期待されています。ホストは、ホストがそのデフォルトルータとしてルータを採用することができます前に、ルータが証明書パスを持っているにトラストアンカーを設定する必要があります。証明のパス要請と広告メッセージが長い証明書パスを運ぶために、実際のルータ発見メッセージを必要とせずにトラストアンカーへの証明書パスを発見するために使用されています。何の証明書パスが利用できないために保護されたRouter Advertisementメッセージの受信は承認委譲発見プロセスをトリガーします。
o Cryptographically Generated Addresses are used to make sure that the sender of a Neighbor Discovery message is the "owner" of the claimed address. A public-private key pair is generated by all nodes before they can claim an address. A new NDP option, the CGA option, is used to carry the public key and associated parameters.
O暗号的に生成されたアドレスは、近隣探索メッセージの送信者が主張アドレスの「所有者」であることを確認するために使用されています。彼らは住所を請求することができる前に、公開鍵と秘密鍵のペアは、すべてのノードによって生成されます。新NDPオプション、CGAオプションは、公開鍵と関連するパラメータを運ぶために使用されます。
This specification also allows a node to use non-CGAs with certificates that authorize their use. However, the details of such use are beyond the scope of this specification and are left for future work.
また、この仕様は、ノードがその使用を許可する証明書で非CGAsを使用することができます。しかし、そのような使用の詳細については、この仕様の範囲を超えており、今後の作業のために残されています。
o A new NDP option, the RSA Signature option, is used to protect all messages relating to Neighbor and Router discovery.
O新NDPオプション、RSA署名オプションは、近隣とルータの発見に関連するすべてのメッセージを保護するために使用されます。
Public key signatures protect the integrity of the messages and authenticate the identity of their sender. The authority of a public key is established either with the authorization delegation process, by using certificates, or through the address ownership proof mechanism, by using CGAs, or with both, depending on configuration and the type of the message protected.
公開鍵署名は、メッセージの完全性を保護し、その送信者の身元を認証します。公開鍵の権限を設定し、保護されたメッセージの種類に応じて、承認委譲プロセスで、証明書を使用することによって、またはアドレス所有権証拠メカニズムを通じて、CGAsを使用することによって、またはその両方のいずれかで確立されています。
Note: RSA is mandated because having multiple signature algorithms would break compatibility between implementations or increase implementation complexity by forcing the implementation of multiple algorithms and the mechanism to select among them. A second signature algorithm is only necessary as a recovery mechanism, in case a flaw is found in RSA. If this happens, a stronger signature algorithm can be selected, and SEND can be revised. The relationship between the new algorithm and the RSA-based SEND described in this document would be similar to that between the RSA-based SEND and Neighbor Discovery without SEND. Information signed with the stronger algorithm has precedence over that signed with RSA, in the same way that RSA-signed information now takes precedence over unsigned information. Implementations of the current and revised specs would still be compatible.
注：複数の署名アルゴリズムを有する実装間の互換性を破壊又は複数のアルゴリズムを実装し、それらの中から選択するためのメカニズムを強制することにより、実装の複雑さを増加させるためRSAが義務付けられています。欠陥がRSAで発見された場合に第2の署名アルゴリズムは、回復メカニズムとしてのみ必要です。このような場合は、より強力な署名アルゴリズムを選択することができ、SENDを改訂することができます。新しいアルゴリズムと、この文書に記載さRSAベースのSENDとの間の関係は、SENDことなくRSAベースの送信および近隣探索の間のものと同様であろう。強力なアルゴリズムで署名された情報はそれ以上の優先順位は、RSA署名情報が今、符号なしの情報よりも優先されるのと同じように、RSAで署名しました。現在の改訂仕様の実装はまだ互換性があるでしょう。
o In order to prevent replay attacks, two new Neighbor Discovery options, Timestamp and Nonce, are introduced. Given that Neighbor and Router Discovery messages are in some cases sent to multicast addresses, the Timestamp option offers replay protection without any previously established state or sequence numbers. When the messages are used in solicitation-advertisement pairs, they are protected with the Nonce option.
Oリプレイ攻撃を防ぐために、二つの新しい近隣探索オプション、タイムスタンプとノンスでは、導入されています。近隣とルータ検出メッセージをマルチキャストアドレスに送信されたいくつかのケースであることを考えると、タイムスタンプオプションは、以前に確立状態またはシーケンス番号なしで再生保護を提供しています。メッセージは、勧誘・広告ペアで使用される場合、それらはNonceのオプションを指定して保護されています。
The options described in this section MUST be supported.
このセクションで説明するオプションをサポートしなければなりません。
The CGA option allows the verification of the sender's CGA. The format of the CGA option is described as follows:
CGAオプションは、送信者のCGAの検証を可能にします。次のようにCGAオプションのフォーマットが記載されています：
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 | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. CGA Parameters .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
11
１１
Length
長さ
The length of the option (including the Type, Length, Pad Length, Reserved, CGA Parameters, and Padding fields) in units of 8 octets.
8つのオクテットの単位で（タイプ、長さ、パッドの長さ、予約、CGAパラメータ、およびパディングフィールドを含む）オプションの長さ。
Pad Length
パッドの長さ
The number of padding octets beyond the end of the CGA Parameters field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers.
CGAパラメータフィールドの終わりを超えたが、長さフィールドで指定された長さの範囲内のパディングオクテットの数。パディングオクテットは送信者によってゼロに設定し、受信機で無視しなければなりません。
Reserved
予約済み
An 8-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
8ビットのフィールドは、将来の使用のために予約します。値は送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
CGA Parameters
CGAパラメータ
A variable-length field containing the CGA Parameters data structure described in Section 4 of [11].
[11]のセクション4で説明CGAパラメータデータ構造を含む可変長フィールド。
This specification requires that if both the CGA option and the RSA Signature option are present, then the public key found from the CGA Parameters field in the CGA option MUST be that referred by the Key Hash field in the RSA Signature option. Packets received with two different keys MUST be silently discarded. Note that a future extension may provide a mechanism allowing the owner of an address and the signer to be different parties.
この仕様は、CGAオプションとRSA署名オプションの両方が存在する場合には、CGAオプションでCGAパラメータフィールドから見つかった公開鍵がそのRSA署名オプションでキーハッシュフィールドによって参照されている必要があります。二つの異なるキーで受信したパケットは黙って捨てなければなりません。将来の拡張は、アドレスの所有者と署名者が異なる当事者ことを可能にする機構を提供することができることに留意されたいです。
Padding
パディング
A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field.
可変長フィールド、オプションの長さを8の倍数になってパッド長フィールドに指定されているような多くのオクテットを含みます。
If the node has been configured to use SEND, the CGA option MUST be present in all Neighbor Solicitation and Advertisement messages and MUST be present in Router Solicitation messages unless they are sent with the unspecified source address. The CGA option MAY be present in other messages.
ノードがSENDを使用するように設定されている場合は、CGAオプションは、すべての近隣要請や広告メッセージに存在している必要があり、それらは、不特定の送信元アドレスに送信されない限り、ルータ要請メッセージの中に存在しなければなりません。 CGAオプションは、他のメッセージに存在してもよいです。
A node sending a message using the CGA option MUST construct the message as follows:
次のようにCGAオプションを使用してメッセージを送信するノードは、メッセージを構築しなければなりません。
The CGA Parameter field in the CGA option is filled according to the rules presented above and in [11]. The public key in the field is taken from the configuration used to generate the CGA, typically from a data structure associated with the source address. The address MUST be constructed as specified in Section 4 of [11]. Depending on the type of the message, this address appears in different places, as follows:
CGAオプションでCGAパラメータフィールドは、上記および[11]に提示規則に従って充填されています。フィールド内の公開鍵は、典型的には、送信元アドレスに関連付けられたデータ構造体から、CGAを生成するために使用されるコンフィギュレーションから取られます。 [11]のセクション4で指定されたアドレスを構成しなければなりません。次のようにメッセージの種類に応じて、このアドレスは、別の場所に表示されます。
Redirect
リダイレクト
The address MUST be the source address of the message.
アドレスは、メッセージの送信元アドレスであるに違いありません。
Neighbor Solicitation
近隣要請
The address MUST be the Target Address for solicitations sent for Duplicate Address Detection; otherwise it MUST be the source address of the message.
アドレスは、重複アドレス検出のために送ら勧誘のターゲットアドレスでなければなりません。それ以外の場合は、メッセージの送信元アドレスであるに違いありません。
Neighbor Advertisement
近隣広告
The address MUST be the source address of the message.
アドレスは、メッセージの送信元アドレスであるに違いありません。
Router Solicitation
ルーター要請
The address MUST be the source address of the message. Note that the CGA option is not used when the source address is the unspecified address.
アドレスは、メッセージの送信元アドレスであるに違いありません。送信元アドレスが未指定のアドレスであるとき、CGAオプションが使用されていないことに注意してください。
Router Advertisement
ルータアドバタイズメント
The address MUST be the source address of the message.
アドレスは、メッセージの送信元アドレスであるに違いありません。
Neighbor Solicitation and Advertisement messages without the CGA option MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node). The processing of unsecured messages is specified in Section 8. Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the unsecured messages.
CGAオプションなし近隣要請及び広告メッセージは、セキュリティで保護されていないものとして扱わなければならない（すなわち、非SENDノードによって送信されたNDPメッセージと同様に処理します）。無担保のメッセージの処理が簡単に無担保のメッセージを捨てるかもしれ非SENDノードと相互運用しようとしないノードを送信セクション8ノートに指定されています。
Router Solicitation messages without the CGA option MUST also be treated as unsecured, unless the source address of the message is the unspecified address.
メッセージの送信元アドレスが未指定アドレスでない限り、CGAオプションなしのルータ要請メッセージはまた、無担保として扱わなければなりません。
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing a CGA option MUST be checked as follows:
、近隣要請をリダイレクトし、次のように、CGAオプションを含む近隣広告、ルーター要請、およびルーターアドバタイズメッセージをチェックしなければなりません。
If the interface has been configured to use CGA, the receiving node MUST verify the source address of the packet by using the algorithm described in Section 5 of [11]. The inputs to the algorithm are the claimed address, as defined in the previous section, and the CGA Parameters field.
インターフェースがCGAを使用するように構成されている場合、受信ノードは、[11]のセクション5で説明されたアルゴリズムを使用して、パケットの送信元アドレスを確認しなければなりません。前のセクション、およびCGAパラメータフィールドで定義されるようなアルゴリズムへの入力は、特許請求のアドレスです。
If the CGA verification is successful, the recipient proceeds with a more time-consuming cryptographic check of the signature. Note that even if the CGA verification succeeds, no claims about the validity of the use can be made until the signature has been checked.
CGA検証が成功した場合、受信者は署名のより多くの時間がかかるの暗号チェックして進めます。 CGA検証が成功しても署名が確認されるまで、使用の妥当性についての主張を行うことはできないことに注意してください。
A receiver that does not support CGA or has not specified its use for a given interface can still verify packets by using trust anchors, even if a CGA is used on a packet. In such a case, the CGA property of the address is simply left unverified.
CGAをサポートしていないか、指定されたインターフェイスのためのその使用を指定していない受信機は依然としてCGAをパケットで使用されても、トラストアンカーを使用してパケットを検証することができます。このような場合には、アドレスのCGAプロパティは単に未確認のままです。
All nodes that support the verification of the CGA option MUST record the following configuration information:
CGAオプションの検証をサポートするすべてのノードは、次の設定情報を記録しなければなりません。
minbits
minbits
The minimum acceptable key length for public keys used in the generation of CGAs. The default SHOULD be 1024 bits. Implementations MAY also set an upper limit for the amount of computation needed when verifying packets that use these security associations. The upper limit SHOULD be at least 2048 bits. Any implementation should follow prudent cryptographic practice in determining the appropriate key lengths.
CGAsの生成に使用される公開鍵のための最小許容されるキーの長さ。デフォルトは1024ビットであるべきです。また、実装はこれらのセキュリティアソシエーションを使用してパケットを検証する際に必要な計算量の上限を設定することができます。上限は、少なくとも2048ビットであるべきです。任意の実装では、適切なキーの長さを決定する際に慎重な暗号練習に従ってください。
All nodes that support the sending of the CGA option MUST record the following configuration information:
CGAオプションの送信をサポートするすべてのノードは、次の設定情報を記録しなければなりません。
CGA parameters
CGAパラメータ
Any information required to construct CGAs, as described in [11].
記載されているように、CGAsを構築するために必要な情報[11]。
The RSA Signature option allows public key-based signatures to be attached to NDP messages. The format of the RSA Signature option is described in the following diagram:
RSA署名オプションは、公開鍵ベースの署名はNDPメッセージに添付することができます。 RSA署名オプションのフォーマットは、以下の図に記載されています。
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Key Hash |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Digital Signature .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
12
１２
Length
長さ
The length of the option (including the Type, Length, Reserved, Key Hash, Digital Signature, and Padding fields) in units of 8 octets.
8つのオクテットの単位で（タイプ、長さ、予約、キーハッシュ、デジタル署名、およびパディングフィールドを含む）オプションの長さ。
Reserved
予約済み
A 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver.
16ビットのフィールドは、将来の使用のために予約します。値は送信者によってゼロに初期化されなければならない、そして受信機によって無視されなければなりません。
Key Hash
キーハッシュ
A 128-bit field containing the most significant (leftmost) 128 bits of a SHA-1 [14] hash of the public key used for constructing the signature. The SHA-1 hash is taken over the presentation used in the Public Key field of the CGA Parameters data structure carried in the CGA option. Its purpose is to associate the signature to a particular key known by the receiver. Such a key can either be stored in the certificate cache of the receiver or be received in the CGA option in the same message.
署名を構築するために使用される公開鍵のSHA-1 [14]ハッシュの最上位（左端）128ビットを含む128ビットのフィールド。 SHA-1ハッシュはCGAオプションで運ばCGAパラメータのデータ構造の公開鍵分野で使用されるプレゼンテーション引き継がれます。その目的は、受信機によって知られている特定のキーに署名を関連付けることです。そのようなキーは、いずれかの受信機の証明書キャッシュに格納することができ、または同じメッセージにCGAオプションで受信されます。
Digital Signature
デジタル署名
A variable-length field containing a PKCS#1 v1.5 signature, constructed by using the sender's private key over the following sequence of octets:
PKCS＃1 v1.5のシグネチャを含む可変長フィールドは、オクテット以下の一連のオーバー送信者の秘密鍵を用いて構成します：
1. The 128-bit CGA Message Type tag [11] value for SEND, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08. (The tag value has been generated randomly by the editor of this specification.).
1. SENDのための128ビットのCGAメッセージタイプタグ[11]の値、0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08。 （タグ値は、本明細書の編集者によってランダムに生成されています。）。
4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the ICMP header.
ICMPヘッダから4の8ビットのタイプ、8ビットのコード、および16ビットのチェックサムフィールド。
5. The NDP message header, starting from the octet after the ICMP Checksum field and continuing up to but not including NDP options.
5. NDPメッセージヘッダ、NDPオプションを含むICMPチェックサムフィールドの後オクテットから開始し、最大継続的ではなく。
The signature value is computed with the RSASSA-PKCS1-v1_5 algorithm and SHA-1 hash, as defined in [13].
[13]で定義されている署名値は、RSASSA-PKCS1-v1_5のアルゴリズムとSHA-1ハッシュを用いて計算されます。
This field starts after the Key Hash field. The length of the Digital Signature field is determined by the length of the RSA Signature option minus the length of the other fields (including the variable length Pad field).
このフィールドは、キーハッシュフィールドの後に開始します。デジタル署名フィールドの長さは、RSA署名オプションマイナス（可変長パッドフィールドを含む）他のフィールドの長さの長さによって決定されます。
Padding
パディング
This variable-length field contains padding, as many bytes long as remain after the end of the signature.
多くのバイトが長い署名の終了後に残るように、この可変長フィールドは、パディングを含ま。
If the node has been configured to use SEND, Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages MUST contain the RSA Signature option. Router Solicitation messages not sent with the unspecified source address MUST contain the RSA Signature option.
ノードが近隣要請、SENDを使用するように設定されている場合は、近隣広告、ルータアドバタイズメント、およびメッセージのリダイレクトは、RSA署名オプションを含まなければなりません。不特定の送信元アドレスに送信されていないルータ要請メッセージは、RSA署名オプションを含まなければなりません。
A node sending a message with the RSA Signature option MUST construct the message as follows:
次のようにRSA署名オプションを使用してメッセージを送信するノードは、メッセージを構築しなければなりません。
o The message is constructed in its entirety, without the RSA Signature option.
Oメッセージは、RSA署名オプションを使用せずに、その全体が構成されています。
o The RSA Signature option is added as the last option in the message.
O RSA署名オプションは、メッセージの最後のオプションとして追加されます。
o The data to be signed is constructed as explained in Section 5.2, under the description of the Digital Signature field.
データOデジタル署名フィールドの説明の下で、セクション5.2で説明したように構成されて署名されます。
o The message, in the form defined above, is signed by using the configured private key, and the resulting PKCS#1 v1.5 signature is put in the Digital Signature field.
メッセージO、上記で定義された形式で、構成された秘密鍵を用いて署名され、得られたPKCS＃1 V1.5署名は、デジタル署名フィールドに入れられます。
Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages without the RSA Signature option MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node). See Section 8.
RSA署名オプションなしで近隣要請、近隣広告、ルータ広告、リダイレクトメッセージは、セキュリティで保護されていないものとして扱わなければならない（すなわち、非SENDノードによって送信されたNDPメッセージと同様に処理します）。セクション8を参照してください。
Router Solicitation messages without the RSA Signature option MUST also be treated as unsecured, unless the source address of the message is the unspecified address.
メッセージの送信元アドレスが未指定アドレスでない限り、RSA署名オプションなしルータ要請メッセージはまた、保護されていないものとして扱われなければなりません。
Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing an RSA Signature option MUST be checked as follows:
次のようにRSA署名オプションを含むリダイレクト、近隣要請、近隣広告、ルーター要請、およびルーターアドバタイズメッセージをチェックしなければなりません。
o The receiver MUST ignore any options that come after the first RSA Signature option. (The options are ignored for both signature verification and NDP processing purposes.)
O受信機は、最初のRSA署名オプションの後に来るすべてのオプションを無視しなければなりません。 （オプションは、署名検証およびNDP処理目的の両方のために無視されます。）
o The Key Hash field MUST indicate the use of a known public key, either one learned from a preceding CGA option in the same message, or one known by other means.
Oキーハッシュフィールドが知られている公開鍵を使用することを示してしなければならない、どちらか一方は同じメッセージ、または他の手段によって知られているもので、前のCGAオプションから学びました。
o The Digital Signature field MUST have correct encoding and MUST not exceed the length of the RSA Signature option minus the Padding.
Oデジタル署名フィールドが正しいエンコーディングを有していなければならず、RSA署名オプションマイナスパディングの長さを超えてはなりません。
o The Digital Signature verification MUST show that the signature has been calculated as specified in the previous section.
Oデジタル署名の検証は、前のセクションで指定された署名が計算されていることを示さなければなりません。
o If the use of a trust anchor has been configured, a valid certification path (see Section 6.3) between the receiver's trust anchor and the sender's public key MUST be known.
トラストアンカーの使用が設定されている場合は、O、有効な証明書パスは、受信者のトラストアンカーと送信者の公開鍵が知らなければならない間（6.3節を参照してください）。
Note that the receiver may verify just the CGA property of a packet, even if, in addition to CGA, the sender has used a trust anchor.
受信機は、CGAに加えて、送信者がトラストアンカーを使用している場合でも、パケットのちょうどCGAプロパティを確認することがあります。
Messages that do not pass all the above tests MUST be silently discarded if the host has been configured to accept only secured ND messages. The messages MAY be accepted if the host has been configured to accept both secured and unsecured messages but MUST be treated as an unsecured message. The receiver MAY also otherwise silently discard packets (e.g., as a response to an apparent CPU exhausting DoS attack).
ホストが唯一の確保NDメッセージを受け入れるように設定されている場合は、上記のすべてのテストに合格しないメッセージは静かに捨てなければなりません。ホストは、両方の固定および保護されていないメッセージを受け入れるように構成されているが、セキュリティで保護されていないメッセージとして処理しなければならない場合にメッセージを受け付けるようにしてもよいです。受信機はまた、そうでない場合はサイレント（例えば、DoS攻撃を排気明らかCPUに対する応答として）パケットを捨てるかもしれ。
All nodes that support the reception of the RSA Signature options MUST allow the following information to be configured for each separate NDP message type:
RSA署名オプションの受信をサポートするすべてのノードは、次の情報がそれぞれ別々のNDPメッセージタイプのために構成されることを可能にしなければなりません。
authorization method
認証方法
This parameter determines the method through which the authority of the sender is determined. It can have four values:
このパラメータは、送信者の権限が決定され、それを通して方法を決定します。それは4つの値を持つことができます。
trust anchor
トラストアンカー
The authority of the sender is verified as described in Section 6.3. The sender may claim additional authorization through the use of CGAs, but this is neither required nor verified.
6.3節で説明したように、送信者の権限が検証されます。送信者はCGAsを使用して追加の許可を請求することができるが、これは必要ありませんも検証もされていません。
CGA
CGA
The CGA property of the sender's address is verified as described in [11]. The sender may claim additional authority through a trust anchor, but this is neither required nor verified.
[11]に記載されているように、送信者のアドレスのCGA性が検証されます。送信者は、トラストアンカーを通じて追加の権限を請求することができるが、これは必要ありませんも検証もされていません。
trust anchor and CGA
トラストアンカーとCGA
Both the trust anchor and the CGA verification is required.
トラストアンカーとCGA検証の両方が必要です。
trust anchor or CGA
トラストアンカーまたはCGA
Either the trust anchor or the CGA verification is required.
トラストアンカーまたはCGA検証のいずれかが必要です。
anchor
アンカー
The allowed trust anchor(s), if the authorization method is not set to CGA.
許可トラストアンカー（s）は、認証方法は、CGAに設定されていない場合。
All nodes that support sending RSA Signature options MUST record the following configuration information:
RSA署名オプションの送信をサポートするすべてのノードは、次の設定情報を記録しなければなりません。
keypair
鍵ペア
A public-private key pair. If authorization delegation is in use, a certification path from a trust anchor to this key pair must exist.
公開鍵と秘密鍵のペア。承認委任を使用している場合は、この鍵ペアのトラストアンカーからの証明書パスが存在している必要があります。
CGA flag
CGAフラグ
A flag that indicates whether CGA is used or not. This flag may be per interface or per node. (Note that in future extensions of the SEND protocol, this flag may also be per subnet prefix.)
CGAが使用されているか否かを示すフラグ。このフラグは、インターフェイス単位またはノードごとであってもよいです。 （SENDプロトコルの将来の拡張では、このフラグはまた、サブネットプレフィックスごとであってもよいことに留意されたいです。）
The construction and verification of the RSA Signature option is computationally expensive. In the NDP context, however, hosts typically only have to perform a few signature operations as they enter a link, a few operations as they find a new on-link peer with which to communicate, or Neighbor Unreachability Detection with existing neighbors.
RSA署名オプションの構築と検証は計算上高価です。 NDPの文脈では、しかし、ホストは、典型的に、それらが既存の隣人を持つ新しい通信するとオンリンクピア、または近隣到達不能検出を見つけるように、彼らは、リンク、いくつかの操作を入力すると、いくつかの署名操作を実行しなければなりません。
Routers are required to perform a larger number of operations, particularly when the frequency of router advertisements is high due to mobility requirements. Still, the number of required signature operations is on the order of a few dozen per second, some of which can be precomputed as explained below. A large number of router solicitations may cause a higher demand for performing asymmetric operations, although the base NDP protocol limits the rate at which multicast responses to solicitations can be sent.
ルータは、ルータ広告の頻度が原因モビリティ要件に高く、特に操作のより多くを実行するために必要とされます。依然として、必要な署名操作の数は、以下に説明するように事前に計算することができるいくつかは毎秒数十のオーダーです。ベースNDPプロトコルは懇願にマルチキャスト応答を送信することができる速度を制限するが、ルータ要請の多数は、非対称の操作を実行するための高い需要を引き起こし得ます。
Signatures can be precomputed for unsolicited (multicast) Neighbor and Router Advertisements if the timing of the future advertisements is known. Typically, solicited neighbor advertisements are sent to the unicast address from which the solicitation was sent. Given that the IPv6 header is covered by the signature, it is not possible to precompute solicited advertisements.
将来の広告のタイミングが既知である場合署名が求められていない（マルチキャスト）近隣とルータ広告の事前に計算することができます。典型的には、要請近隣広告は、要請を送信したユニキャストアドレスに送信されます。 IPv6ヘッダーは署名によって覆われていることを考えると、要請広告を事前に計算することは不可能です。
The purpose of the Timestamp option is to make sure that unsolicited advertisements and redirects have not been replayed. The format of this option is described in the following:
タイムスタンプオプションの目的は、未承諾広告やリダイレクトが再生されていないことを確認することです。このオプションの形式は、以下に説明されています。
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Timestamp +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
13
１３
Length
長さ
The length of the option (including the Type, Length, Reserved, and Timestamp fields) in units of 8 octets; i.e., 2.
8つのオクテットの単位で（タイプ、長さ、予約、およびタイムスタンプフィールドを含む）オプションの長さ。即ち、2。
Reserved
予約済み
A 48-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
48ビットのフィールドは、将来の使用のために予約します。値は送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Timestamp
タイムスタンプ
A 64-bit unsigned integer field containing a timestamp. The value indicates the number of seconds since January 1, 1970, 00:00 UTC, by using a fixed point format. In this format, the integer number of seconds is contained in the first 48 bits of the field, and the remaining 16 bits indicate the number of 1/64K fractions of a second.
タイムスタンプを含む64ビット符号なし整数フィールド。値は固定小数点形式を使用して、1970年1月1日午前0時UTCからの秒数を示します。この形式では、秒の整数フィールドの最初の48ビットに含まれ、残りの16ビットは、第二の1 / 64Kのフラクションの数を示します。
Implementation note: This format is compatible with the usual representation of time under UNIX, although the number of bits available for the integer and fraction parts may vary.
実装注：整数と小数部分のために利用可能なビットの数は変化し得るが、このフォーマットは、UNIX下の時間の通常の表現と互換性があります。
The purpose of the Nonce option is to make sure that an advertisement is a fresh response to a solicitation sent earlier by the node. The format of this option is described in the following:
ナンスオプションの目的は、広告がノードによって以前送信された勧誘に新鮮な応答であることを確認することです。このオプションの形式は、以下に説明されています。
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 | Nonce ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
14
１４
Length
長さ
The length of the option (including the Type, Length, and Nonce fields) in units of 8 octets.
8つのオクテットの単位で（タイプ、長さ、およびノンスフィールドを含む）オプションの長さ。
Nonce
使節
A field containing a random number selected by the sender of the solicitation message. The length of the random number MUST be at least 6 bytes. The length of the random number MUST be selected so that the length of the nonce option is a multiple of 8 octets.
要請メッセージの送信者により選択された乱数を含むフィールド。乱数の長さは少なくとも6バイトでなければなりません。ナンスオプションの長さが8つのオクテットの倍数になるように乱数の長さが選択されなければなりません。
If the node has been configured to use SEND, all solicitation messages MUST include a Nonce. When sending a solicitation, the sender MUST store the nonce internally so that it can recognize any replies containing that particular nonce.
ノードがSENDを使用するように設定されている場合は、すべての要請メッセージには、nonceを含まなければなりません。勧誘を送信する場合、それはその特定のnonceを含む任意の応答を認識できるように、送信者は内部ナンスを保存しなければなりません。
If the node has been configured to use SEND, all advertisements sent in reply to a solicitation MUST include a Nonce, copied from the received solicitation. Note that routers may decide to send a multicast advertisement to all nodes instead of a response to a specific host. In such a case, the router MAY still include the nonce value for the host that triggered the multicast advertisement. (Omitting the nonce value may cause the host to ignore the router's advertisement, unless the clocks in these nodes are sufficiently synchronized so that timestamps function properly.)
ノードがSENDを使用するように構成されている場合、要請に対する応答で送信されたすべての広告が受信された要請からコピーされたノンスを含まなければなりません。ルータは代わりに特定のホストへの応答のすべてのノードにマルチキャスト広告を送信することを決定してもよいことに注意してください。そのような場合には、ルータは、まだマルチキャスト広告を引き起こしたホストの一回だけの値を含んでいてもよいです。 （ノンス値を省略すると、タイムスタンプが正しく機能するようにこれらのノード内のクロックが十分に同期されない限り、ホストは、ルータの広告を無視することがあります。）
If the node has been configured to use SEND, all solicitation, advertisement, and redirect messages MUST include a Timestamp. Senders SHOULD set the Timestamp field to the current time, according to their real time clocks.
ノードは、すべての勧誘、広告、SENDを使用するように構成された、とのメッセージをリダイレクトされた場合にタイムスタンプを含まなければなりません。送信者は、彼らのリアルタイムクロックに応じて、現在の時刻にタイムスタンプフィールドを設定する必要があります。
The processing of the Nonce and Timestamp options depends on whether a packet is a solicited advertisement. A system may implement the distinction in various ways. Section 5.3.4.1 defines the processing rules for solicited advertisements. Section 5.3.4.2 defines the processing rules for all other messages.
ナンスおよびタイムスタンプオプションの処理は、パケットが募集広告であるかどうかに依存します。システムは、様々な方法で区別を実装することができます。セクション5.3.4.1は請求さ広告のための処理規則を定義します。セクション5.3.4.2は、他のすべてのメッセージの処理ルールを定義します。
In addition, the following rules apply in all cases:
また、以下のルールがすべての場合に適用されます。
o Messages received without at least one of the Timestamp and Nonce options MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node).
Oメッセージは、タイムスタンプとノンスオプションの少なくとも一つの保護されていないとして扱われなければならなく受信（すなわち、非SENDノードによって送信されたNDPメッセージと同様に処理）。
o Messages received with the RSA Signature option but without the Timestamp option MUST be silently discarded.
Oメッセージは、RSA署名オプションではなくタイムスタンプオプションが静かに捨てなければならないことなく、受信しました。
o Solicitation messages received with the RSA Signature option but without the Nonce option MUST be silently discarded.
O要請メッセージは、RSA署名オプションではなくナンスオプションは黙って捨てなければなりませんなしで受信しました。
o Advertisements sent to a unicast destination address with the RSA Signature option but without a Nonce option SHOULD be processed as unsolicited advertisements.
O広告はRSA署名オプションを使用してユニキャスト宛先アドレスに送信されたが、ナンスオプションを使用せずに未承諾広告として処理されるべきです。
o An implementation MAY use some mechanism such as a timestamp cache to strengthen resistance to replay attacks. When there is a very large number of nodes on the same link, or when a cache filling attack is in progress, it is possible that the cache holding the most recent timestamp per sender will become full. In this case, the node MUST remove some entries from the cache or refuse some new requested entries. The specific policy as to which entries are preferred over others is left as an implementation decision. However, typical policies may prefer existing entries to new ones, CGAs with a large Sec value to smaller Sec values, and so on. The issue is briefly discussed in Appendix B.
O実装は、リプレイ攻撃に対する耐性を強化するために、このようなタイムスタンプキャッシュとしていくつかのメカニズムを使用するかもしれません。同じリンク上のノードの非常に大きな数がある場合、または攻撃を充填キャッシュが進行しているとき、送信者ごとに最新のタイムスタンプを保持しているキャッシュがいっぱいになる可能性があります。この場合、ノードがキャッシュからいくつかのエントリを削除したり、いくつかの新しい要求されたエントリを拒否しなければなりません。エントリが他のものより好まれるようれる特定のポリシーが実装決定として残されます。しかし、一般的なポリシーがように、新しいものへの既存のエントリを好む小さい秒の値に大きな秒の値を持つCGAs、とあります。問題は簡単に付録Bで説明されています
o The receiver MUST be prepared to receive the Timestamp and Nonce options in any order, as per RFC 2461 [4], Section 9.
O受信機は、RFC 2461に従って、任意の順序でタイムスタンプとノンスオプションを受信するように準備しなければなりません[4]、セクション9。
The receiver MUST verify that it has recently sent a matching solicitation, and that the received advertisement contains a copy of the Nonce sent in the solicitation.
受信機は、それが最近のマッチング勧誘を送信し、受信した広告が勧誘に送信されたNonceのコピーが含まれていることをしていることを確かめなければなりません。
If the message contains a Nonce option but the Nonce value is not recognized, the message MUST be silently discarded.
メッセージはノンスオプションが含まれていますが、ノンス値が認識されない場合、メッセージは静かに捨てなければなりません。
Otherwise, if the message does not contain a Nonce option, it MAY be considered an unsolicited advertisement and processed according to Section 5.3.4.2.
メッセージはナンスオプションが含まれていない場合はそれ以外の場合、それは、セクション5.3.4.2に従って迷惑広告とみなされ、処理されてもよいです。
If the message is accepted, the receiver SHOULD store the receive time of the message and the timestamp time in the message, as specified in Section 5.3.4.2.
メッセージが受け入れられた場合、受信機は、セクション5.3.4.2で指定されるように、メッセージとメッセージのタイムスタンプの時間の時間を受け取り格納する必要があります。
Receivers SHOULD be configured with an allowed timestamp Delta value, a "fuzz factor" for comparisons, and an allowed clock drift parameter. The recommended default value for the allowed Delta is TIMESTAMP_DELTA; for fuzz factor TIMESTAMP_FUZZ; and for clock drift, TIMESTAMP_DRIFT (see Section 10.2).
受信機は、許可されたタイムスタンプデルタ値、比較のための「ファズ因子」、および許可クロックドリフトパラメータで構成されるべきです。許可デルタのための推奨されるデフォルト値はTIMESTAMP_DELTAです。ファズ因子TIMESTAMP_FUZZため、そして、クロックドリフト、TIMESTAMP_DRIFT（10.2節を参照）。
To facilitate timestamp checking, each node SHOULD store the following information for each peer:
タイムスタンプチェックを容易にするために、各ノードは、各ピアのために、以下の情報を格納する必要があります。
o The receive time of the last received and accepted SEND message. This is called RDlast.
最後に受信したと認められたSENDメッセージの受信時間、O。これはRDlastと呼ばれています。
o The time stamp in the last received and accepted SEND message. This is called TSlast.
最後に受信したと認められたSENDメッセージのタイムスタンプO。これはTSlastと呼ばれています。
An accepted SEND message is any successfully verified Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, or Redirect message from the given peer. The RSA Signature option MUST be used in such a message before it can update the above variables.
受け入れられたSENDメッセージは、任意の検証に成功近隣要請、近隣広告、ルータ要請、ルータ広告、または所与のピアからメッセージをリダイレクトします。それは上記の変数を更新することができる前に、RSA署名オプションは、メッセージで使用されなければなりません。
Receivers SHOULD then check the Timestamp field as follows:
次のようにレシーバは、タイムスタンプフィールドをチェックする必要があります：
o When a message is received from a new peer (i.e., one that is not stored in the cache), the received timestamp, TSnew, is checked, and the packet is accepted if the timestamp is recent enough to the reception time of the packet, RDnew:
Oメッセージは、新たなピアから受信した場合（すなわち、キャッシュに格納されていない1）、受信タイムスタンプ、TSnewは、チェックされ、タイムスタンプは、パケットの受信時に十分に最近のものである場合、パケットが受け入れられます、RDnew：
-Delta < (RDnew - TSnew) < +Delta
- デルタ<（RDnew - TSnew）<+デルタ
The RDnew and TSnew values SHOULD be stored in the cache as RDlast and TSlast.
RDnewとTSnew値はRDlastとTSlastとしてキャッシュに格納する必要があります。
o If the timestamp is NOT within the boundaries but the message is a Neighbor Solicitation message that the receiver should answer, the receiver SHOULD respond to the message. However, even if it does respond to the message, it MUST NOT create a Neighbor Cache entry. This allows nodes that have large differences in their clocks to continue communicating with each other by exchanging NS/NA pairs.
タイムスタンプが境界内にありませんが、メッセージは受信者が答える必要近隣要請メッセージである場合には、O、受信機はメッセージに応答する必要があります。しかし、それはメッセージに応答ない場合でも、それはNeighbor Cacheエントリーを作成してはいけません。これは、それらのクロックに大きな違いがあるノードがNS / NA対を交換することによって互いに通信を継続することを可能にします。
o When a message is received from a known peer (i.e., one that already has an entry in the cache), the timestamp is checked against the previously received SEND message:
Oメッセージが既知のピアから受信された場合（すなわち、既にキャッシュ内にエントリを有するもの）のタイムスタンプが以前に受信されたSENDメッセージと照合され、。
TSnew + fuzz > TSlast + (RDnew - RDlast) x (1 - drift) - fuzz
TSnew +ファズ> TSlast +（RDnew - RDlast）×（1 - ドリフト） - ファズ
If this inequality does not hold, the receiver SHOULD silently discard the message. If, on the other hand, the inequality holds, the receiver SHOULD process the message.
この不等式が成立しない場合、受信機は静かにメッセージを捨てます。不等式が成立し、一方、受信機は、メッセージを処理すべき場合。
Moreover, if the above inequality holds and TSnew > TSlast, the receiver SHOULD update RDlast and TSlast. Otherwise, the receiver MUST NOT update RDlast or TSlast.
上記の不等式が成立するとTSnew> TSlast場合さらに、受信機はRDlastとTSlastを更新する必要があります。そうでない場合、受信機はRDlastまたはTSlastをアップデートしてはいけません。
As unsolicited messages may be used in a Denial-of-Service attack to make the receiver verify computationally expensive signatures, all nodes SHOULD apply a mechanism to prevent excessive use of resources for processing such messages.
未承諾メッセージが受信機は計算コストが高い署名を検証するためにサービス拒否（DoS）攻撃に使用することができるように、全てのノードは、メッセージを処理するためのリソースの過度の使用を防止するための機構を適用すべきです。
NDP allows a node to configure itself automatically based on information learned shortly after connecting to a new link. It is particularly easy to configure "rogue" routers on an unsecured link, and it is particularly difficult for a node to distinguish between valid and invalid sources of router information, because the node needs this information before communicating with nodes outside of the link.
NDPは、ノードがまもなく新しいリンクに接続した後、学習した情報に基づいて自動的に設定することができます。無担保のリンクを「ならず者」のルータを設定することが特に容易で、ノードは、リンクの外のノードと通信する前に、この情報を必要とするため、ノードが、ルータ情報の有効と無効なソースを区別することが特に困難です。
As the newly-connected node cannot communicate off-link, it cannot be responsible for searching information to help validate the router(s). However, given a certification path, the node can check someone else's search results and conclude that a particular message comes from an authorized source. In the typical case, a router already connected beyond the link can communicate if necessary with off-link nodes and construct a certification path.
新たに接続されたノードがオフリンクを伝えることができないとして、それはルータ（複数可）を検証するのに役立つ情報を検索するための責任を負うことはできません。しかし、証明書パスを考えると、ノードが誰か他の人の検索結果をチェックして、特定のメッセージが認可ソースから来ていると結論づけることができます。典型的な場合には、既にリンクを越えて接続されたルータは、必要に応じて、オフリンクノードと通信し、認証パスを構築することができます。
The Secure Neighbor Discovery Protocol mandates a certificate format and introduces two new ICMPv6 messages used between hosts and routers to allow the host to learn a certification path with the assistance of the router.
セキュア近隣探索プロトコルは、証明書の形式を義務付け、ホストがルータの支援を受けて証明書パスを学ぶことができるように、ホストとルータの間で使用される二つの新しいICMPv6メッセージを紹介します。
To protect Router Discovery, SEND requires that routers be authorized to act as routers. This authorization is provisioned in both routers and hosts. Routers are given certificates from a trust anchor, and the hosts are configured with the trust anchor(s) to authorize routers. This provisioning is specific to SEND and does not assume that certificates already deployed for some other purpose can be used.
ルータ検出を保護するため、SENDはルータがルータとして動作することを許可されている必要があります。この権限は、ルータとホストの両方にプロビジョニングされます。ルータは、トラストアンカーから証明書を与えられ、そしてホストは、ルータを認証するトラストアンカー（S）で構成されています。このプロビジョニングは、送信するために固有のものであり、すでにいくつかの他の目的のために展開された証明書を使用することができることを想定していません。
The authorization for routers in SEND is twofold:
SENDのルータのための認可は二つです：
o Routers are authorized to act as routers. The router belongs to the set of routers trusted by the trust anchor. All routers in this set have the same authorization.
Oルータはルータとして動作することが許可されています。ルータは、トラストアンカーが信頼するルータのセットに属します。このセット内のすべてのルータが同じ権限を持っています。
o Optionally, routers may also be authorized to advertise a certain set of subnet prefixes. A specific router is given a specific set of subnet prefixes to advertise; other routers have an authorization to advertise other subnet prefixes. Trust anchors may also delegate a certain set of subnet prefixes to someone (such as an ISP) who, in turn, delegates parts of this set to individual routers.
任意選択的にO、ルータは、サブネット・プレフィックスの特定のセットを広告することを許可することができます。特定のルータを宣伝するために、サブネットプレフィックスの特定のセットを与えられています。他のルータは、他のサブネットプレフィックスを通知する権限を持っています。トラストアンカーは、個々のルータにこのセットの人、順番に、委譲部（例えばISPのような）誰かにサブネット・プレフィックスの特定のセットを委任することができます。
Note that while communicating with hosts, routers typically also present a number of other parameters beyond the above. For instance, routers have their own IP addresses, subnet prefixes have lifetimes, and routers control the use of stateless and stateful address autoconfiguration. However, the ability to be a router and the subnet prefixes are the most fundamental parameters to authorize. This is because the host needs to choose a router that it uses as its default router, and because the advertised subnet prefixes have an impact on the addresses the host uses. The subnet prefixes also represent a claim about the topological location of the router in the network.
ホストとの通信中に、ルータは、典型的には、上記以外の他のパラメータの数を提示することに留意されたいです。たとえば、ルータはサブネットプレフィックスが寿命を持って、自分自身のIPアドレスを持っており、ルータはステートレスとステートフルアドレス自動設定の使用を制御します。しかし、ルータとサブネットプレフィックスである能力を許可する最も基本的なパラメータです。ホストはそれがデフォルトルータとして使用するルータを選択する必要があるため、および広告を出してサブネットプレフィックスは、アドレスのホストの使用に影響を与えるためです。サブネットプレフィックスは、ネットワーク内のルータの位相的な位置についてのクレームを表します。
Care should be taken if the certificates used in SEND are also used to provide authorization in other circumstances; for example, with routing protocols. It is necessary to ensure that the authorization information is appropriate for all applications. SEND certificates may authorize a larger set of subnet prefixes than the router is authorized to advertise on a given interface. For instance, SEND allows the use of the null prefix, which might cause verification or routing problems in other applications. It is RECOMMENDED that SEND certificates containing the null prefix are only used for SEND.
SENDに使用される証明書は、他の状況での承認を提供するために使用されている場合は注意が必要です。例えば、ルーティングプロトコルを有します。認証情報は、すべてのアプリケーションに適していることを保証する必要があります。ルータが与えられたインタフェースに広告を掲載することが許可されているよりも、サブネットプレフィックスの大規模なセットを許可することができる証明書を送信します。例えば、SENDは、他のアプリケーションでの検証やルーティングの問題を引き起こす可能性がある、ヌル接頭語を使用することができます。 SENDのためにのみ使用されているヌル接頭語を含む証明書を送信することをお勧めします。
Note that end hosts need not be provisioned with their own certified public keys, just as Web clients today do not require end host provisioning with certified keys. Public keys for CGA generation do not need to be certified, as these keys derive their ability to authorize operations on the CGA by the tie to the address.
そのエンドホストが認証キーを持つエンドホストのプロビジョニングを必要としない、今日だけでWebクライアントとして、自らの公認の公開鍵をプロビジョニングする必要はありません注意してください。これらのキーは、アドレスにタイでCGAの操作を許可する能力を引き出すようCGAを生成するための公開鍵は、認定する必要はありません。
The deployment model for trust anchors can be either a globally rooted public key infrastructure or a more local, decentralized deployment model similar to that currently used for TLS in Web servers. The centralized model assumes a global root capable of authorizing routers and, optionally, the address space they advertise. The end hosts are configured with the public keys of the global root. The global root could operate, for instance, under the Internet Assigned Numbers Authority (IANA) or as a co-operative among Regional Internet Registries (RIRs). However, no such global root currently exists.
トラストアンカーの展開モデルは、グローバルに根ざした公開鍵インフラストラクチャまたは現在のWebサーバーでTLSのために使用されるものと同様の、よりローカルな、分散型展開モデルのいずれかになります。集中型モデルは、グローバルルーターを承認すること根と、必要に応じて、彼らは宣伝アドレス空間を想定しています。エンドホストは、グローバルルートの公開鍵を使用して構成されています。グローバルルートは、例えば、IANA（Internet Assigned Numbers Authority）の下で、または地域インターネットレジストリ（のRIR）の間で協同として、動作することができます。しかし、そのような世界的なルートは現在存在しません。
In the decentralized model, end hosts are configured with a collection of trusted public keys. The public keys could be issued from various places; for example, a) a public key for the end host's own organization, b) a public key for the end host's home ISP and for ISPs with which the home ISP has a roaming agreement, or c) public keys for roaming brokers acting as intermediaries for ISPs that don't want to run their own certification authority.
分散型モデルでは、エンドホストは、信頼できる公開鍵の集まりで構成されています。公開鍵は、さまざまな場所から発行することができ、エンドホストの自身の組織のために例えば、a）の公開鍵、エンドホストのホームISP用と家庭用ISPがローミング契約を持っているとISPのためのb）の公開鍵、または仲介者として機能し、ローミング仲介業者のためのc）の公開鍵自分の証明機関を実行したくないのISPのために。
This decentralized model works even when a SEND node is used both in networks that have certified routers and in networks that do not. As discussed in Section 8, a SEND node can fall back to the use of a non-SEND router. This makes it possible to start with a local trust anchor even if there is no trust anchor for all possible networks.
この分散型モデルは、SENDノードがルーターを認定しているネットワークではとそうでないネットワークの両方で使用された場合でも動作します。セクション8で説明したように、送信ノードは、非SENDルータの使用にフォールバックすることができます。これは、すべての可能なネットワークのためのトラストアンカーが存在しない場合でも、ローカルのトラストアンカーを開始することが可能となります。
The certification path of a router terminates in a Router Authorization Certificate that authorizes a specific IPv6 node to act as a router. Because authorization paths are not a common practice in the Internet at the time of this writing, the path MUST consist of standard Public Key Certificates (PKC, in the sense of [8]). The certification path MUST start from the identity of a trust anchor shared by the host and the router. This allows the host to anchor trust for the router's public key in the trust anchor. Note that there MAY be multiple certificates issued by a single trust anchor.
ルータの証明書パスは、ルータとして動作するために特定のIPv6ノードを許可ルータ認証証明書で終了します。認証パスは、この記事の執筆時点では、インターネットでは一般的ではありませんので、パスは標準の公開鍵証明書で構成されなければならない（の意味でPKC、[8]）。証明書パスは、ホストとルータが共有するトラストアンカーのアイデンティティから開始する必要があります。これは、ホストは、トラストアンカーのルータの公開鍵の信頼を固定することができます。単一トラストアンカーによって発行された複数の証明書があるかもしれないことに注意してください。
Router Authorization Certificates are X.509v3 certificates, as defined in RFC 3280 [7], and SHOULD contain at least one instance of the X.509 extension for IP addresses, as defined in [10]. The parent certificates in the certification path SHOULD contain one or more X.509 IP address extensions, back up to a trusted party (such as the user's ISP) that configured the original IP address block for the router in question, or that delegated the right to do so. The certificates for the intermediate delegating authorities SHOULD contain X.509 IP address extension(s) for subdelegations. The router's certificate is signed by the delegating authority for the subnet prefixes the router is authorized to advertise.
ルータ認可証明書は、RFC 3280で定義されている[7]、のX.509v3証明書であり、[10]で定義されるように、IPアドレスのX.509拡張の少なくとも1つのインスタンスを含むべきです。証明書パス中の親証明書が戻って、信頼できるパーティまで、一つ以上のX.509のIPアドレス拡張を含むべきである（例えば、ユーザのISP）問題のルータの元のIPアドレスブロックを構成し、またはその権利を委譲そうするために。中間委任当局の証明書は、subdelegationsのためのX.509 IPアドレス拡張子（複数可）を含むべきです。ルータの証明書は、サブネットの委任機関によって署名されているルータが広告を掲載することが許可される接頭辞。
The X.509 IP address extension MUST contain at least one addressesOrRanges element. This element MUST contain an addressPrefix element containing an IPv6 address prefix for a prefix that the router or the intermediate entity is authorized to route. If the entity is allowed to route any prefix, the IPv6 address prefix used is the null prefix, ::/0. The addressFamily element of the IPAddrBlocks sequence element MUST contain the IPv6 Address Family Identifier (0002), as specified in [10], for IPv6 subnet prefixes. Instead of an addressPrefix element, the addressesOrRange element MAY contain an addressRange element for a range of subnet prefixes, if more than one prefix is authorized. The X.509 IP address extension MAY contain additional IPv6 subnet prefixes, expressed as either an addressPrefix or an addressRange.
X.509 IPアドレス拡張子は、少なくとも1つのaddressesOrRangesの要素を含まなければなりません。この要素は、ルータまたは中間エンティティは、ルートに許可されているプレフィックスのIPv6アドレスプレフィックスを含むaddressPrefix要素を含まなければなりません。エンティティがルートに任意のプレフィックスを許可されている場合は、使用したIPv6アドレスのプレフィックスがヌル接頭語、:: / 0です。 [10]で指定されるようIPAddrBlocks配列要素のaddressFamily要素は、IPv6サブネット・プレフィックスのために、IPv6アドレスファミリー識別子（0002）を含まなければなりません。代わりにaddressPrefix要素の複数の接頭辞が許可されている場合は、addressesOrRange要素は、サブネットプレフィックスの範囲のためのaddressRange元素を含んでいてもよいです。 X.509 IPアドレス拡張子が追加のIPv6サブネットプレフィックスを含むかもしれ、addressPrefixまたはaddressRangeのいずれかで表されます。
A node receiving a Router Authorization Certificate MUST first check whether the certificate's signature was generated by the delegating authority. Then the client SHOULD check whether all the addressPrefix or addressRange entries in the router's certificate are contained within the address ranges in the delegating authority's certificate, and whether the addressPrefix entries match any addressPrefix entries in the delegating authority's certificate. If an addressPrefix or addressRange is not contained within the delegating authority's subnet prefixes or ranges, the client MAY attempt to take an intersection of the ranges/subnet prefixes and to use that intersection. If the resulting intersection is empty, the client MUST NOT accept the certificate. If the addressPrefix in the certificate is missing or is the null prefix, ::/0, the parent prefix or range SHOULD be used. If there is no parent prefix or range, the subnet prefixes that the router advertises are said to be unconstrained (see Section 7.3). That is, the router is allowed to advertise any prefix.
ルータの認証証明書を受信したノードは、最初の証明書の署名が委任機関によって生成されたかどうかをチェックしなければなりません。その後、クライアントがルータの証明書内のすべてのaddressPrefixまたはaddressRangeエントリは委任機関の証明書でアドレス範囲内に含まれているかどうかを確認する必要があり、かつaddressPrefixエントリは委任権限の証明書内の任意のaddressPrefixエントリと一致するかどうか。 addressPrefixまたはaddressRangeが委任権限のサブネットプレフィックスまたは範囲内に含まれていない場合、クライアントは、範囲/サブネットプレフィックスの交差点を取るようにし、その交点を使用しようとするかもしれません。結果の共通部分が空の場合、クライアントが証明書を受け入れてはいけません。証明書addressPrefixがないかヌル接頭辞、:: / 0でされている場合は、親の接頭辞または範囲を使用する必要があります。親プレフィックスや範囲がない場合は、ルータアドバタイズが制約されていないといわれているサブネットプレフィックスは（7.3節を参照してください）。つまり、ルータは、任意のプレフィックスを通知することが許可されています。
The above checks SHOULD be done for all certificates in the path. If any of the checks fail, the client MUST NOT accept the certificate. The client also has to perform validation of advertised subnet prefixes as discussed in Section 7.3.
上記のチェックはパス内のすべての証明書のために行われるべきです。チェックのいずれかが失敗した場合、クライアントは、証明書を受け入れてはいけません。また、クライアントは、7.3節で述べたように広告を出してサブネットプレフィックスの検証を実行する必要があります。
Hosts MUST check the subjectPublicKeyInfo field within the last certificate in the certificate path to ensure that only RSA public keys are used to attempt validation of router signatures. Hosts MUST disregard the certificate for SEND if it does not contain an RSA key.
ホストは唯一のRSA公開鍵は、ルータの署名の検証を試みるために使用されることを保証するために、証明書のパスの最後の証明書にSubjectPublicKeyInfoでフィールドをチェックしなければなりません。それはRSAキーが含まれていない場合、ホストはSENDの証明書を無視しなければなりません。
As it is possible that some public key certificates used with SEND do not immediately contain the X.509 IP address extension element, an implementation MAY contain facilities that allow the prefix and range checks to be relaxed. However, any such configuration options SHOULD be switched off by default. The system SHOULD have a default configuration that requires rigorous prefix and range checks.
それがSENDで使用されるいくつかの公開鍵証明書はすぐにX.509 IPアドレス拡張要素が含まれていない可能性があるため、実装はプレフィックスと範囲チェックを緩和することを可能にする施設を含むかもしれません。しかし、そのような設定オプションがデフォルトでオフにする必要があります。システムは、厳格なプレフィックスと範囲チェックが必要で、既定の構成を有しているべきです。
The following is an example of a certification path. Suppose that isp_group_example.net is the trust anchor. The host has this certificate:
以下は、認証パスの一例です。 isp_group_example.netは、トラストアンカーであると仮定します。ホストは、この証明書を持っています：
Certificate 1: Issuer: isp_group_example.net Validity: Jan 1, 2004 through Dec 31, 2004 Subject: isp_group_example.net Extensions: IP address delegation extension: Prefixes: P1, ..., Pk ... possibly other extensions ... ... other certificate parameters ...
証明書1：発行者：isp_group_example.net有効期限：2004年12月31日件名による2004年1月1日：isp_group_example.net拡張機能：IPアドレス委任拡張：プレフィックス：P1、...、Pkは...おそらく他の拡張機能...。 ...他の証明書パラメータ...
When the host attaches to a link served by router_x.isp_foo_example.net, it receives the following certification path:
ホストはrouter_x.isp_foo_example.netによって提供リンクに接続する場合は、以下の証明書パスを受け取ります。
Certificate 2: Issuer: isp_group_example.net Validity: Jan 1, 2004 through Dec 31, 2004 Subject: isp_foo_example.net Extensions: IP address delegation extension: Prefixes: Q1, ..., Qk ... possibly other extensions ... ... other certificate parameters ...
証明書2：発行者：isp_group_example.net有効期限：2004年1月1日2004年12月31日件名経由：isp_foo_example.net拡張機能：IPアドレス委任拡張：プレフィックス：Q1、...、Qkは...おそらく他の拡張機能...。 ...他の証明書パラメータ...
Certificate 3: Issuer: isp_foo_example.net Validity: Jan 1, 2004 through Dec 31, 2004 Subject: router_x.isp_foo_example.net Extensions: IP address delegation extension: Prefixes R1, ..., Rk ... possibly other extensions ...
証明書3：発行者：isp_foo_example.net有効期限：2004年1月1日2004年12月31日件名経由：router_x.isp_foo_example.net拡張機能：IPアドレス委任拡張：プレフィックスR1、...、Rkと...おそらく他の拡張機能...
... other certificate parameters ...
...他の証明書パラメータ...
When the three certificates are processed, the usual RFC 3280 [7] certificate path validation is performed. Note, however, that when a node checks certificates received from a router, it typically does not have a connection to the Internet yet, and so it is not possible to perform an on-line Certificate Revocation List (CRL) check, if necessary. Until this check is performed, acceptance of the certificate MUST be considered provisional, and the node MUST perform a check as soon as it has established a connection with the Internet through the router. If the router has been compromised, it could interfere with the CRL check. Should performance of the CRL check be disrupted or should the check fail, the node SHOULD immediately stop using the router as a default and use another router on the link instead.
3つの証明書を処理する場合、通常のRFC 3280 [7]認証パスの検証が行われます。ノードのチェック証明書はルータから受信したとき、それは一般的に、まだインターネットに接続されていないこと、しかし、注意してください、そして必要に応じて、オンライン証明書失効リスト（CRL）のチェックを実行することはできません。このチェックが実行されるまでは、証明書の受け入れは暫定考えなければなりませんし、ノードはすぐにそれがルータを介してインターネットとの接続を確立しているように、チェックを実行しなければなりません。ルータが侵害された場合は、CRLチェックに干渉することがあります。 CRLチェックのパフォーマンスが中断されなければならないか、チェックが失敗した場合、ノードはすぐにデフォルトとしてルータの使用を停止し、代わりに、リンク上の別のルータを使用すべきです。
In addition, the IP addresses in the delegation extension MUST be a subset of the IP addresses in the delegation extension of the issuer's certificate. So in this example, R1, ..., Rs must be a subset of Q1,...,Qr, and Q1,...,Qr must be a subset of P1,...,Pk. If the certification path is valid, then router_foo.isp_foo_example.com is authorized to route the prefixes R1,...,Rs.
また、委任拡張内のIPアドレスは、発行者の証明書の委任延長でのIPアドレスのサブセットである必要があります。したがって、この例では、R1は、...、RsはQ1のサブセットである必要があり、...、QRが、そしてQ1は、...、QRがP1、...、Pkののサブセットでなければなりません。証明書パスが有効である場合には、router_foo.isp_foo_example.comはルートプレフィックスR1、...、ルピーに許可されています。
As deployment of the IP address extension is, itself, not common, a network service provider MAY choose to deploy standard identity certificates on the router to supply the router's public key for signed Router Advertisements.
IPアドレス拡張の展開があるので、それ自体は、一般的ではありません、ネットワーク・サービス・プロバイダは、署名されたルータ広告のためのルータの公開鍵を供給するために、ルータ上での標準的な身元証明書を展開することを選択するかもしれません。
If there is no prefix information further up in the certification path, a host interprets a standard identity certificate as allowing unconstrained prefix advertisements.
さらにアップ証明書パスにはプレフィックス情報がない場合、ホストは、制約のない接頭語の広告を許可するなどの標準的な身元証明書を解釈します。
If the other certificates contain prefix information, a standard identity certificate is interpreted as allowing those subnet prefixes.
他の証明書は、プレフィックス情報が含まれている場合は、標準の識別証明書は、それらのサブネットプレフィックスを許可すると解釈されます。
The Certification Path Solicitation (CPS) message is sent by a host when it wishes to request a certification path between a router and one of the host's trust anchors. The Certification Path Advertisement (CPA) message is sent in reply to the CPS message. These messages are kept separate from the rest of Neighbor and Router Discovery to reduce the effect of the potentially voluminous certification path information on other messages.
それはルータとホストのトラストアンカーの1の間で証明書パスを要求したいときに証明書のパス要請（CPS）のメッセージがホストによって送信されます。証明のパス広告（CPA）のメッセージがCPSメッセージへの返信で送信されます。これらのメッセージは、他のメッセージに潜在的に膨大な証明書パス情報の影響を低減するために近隣とルータ探索の残りの部分から分離して保持されています。
The Authorization Delegation Discovery (ADD) process does not exclude other forms of discovering certification paths. For instance, during fast movements, mobile nodes may learn information (including the certification paths) about the next router from a previous router, or nodes may be preconfigured with certification paths from roaming partners.
権限委譲発見（ADD）プロセスは、証明経路を発見他の形態を除外するものではありません。例えば、高速移動中、モバイルノードが前ルータから次ルータについて（認証パスを含む）の情報を学習することができる、またはノードがローミングパートナーから認証パスで事前設定することができます。
Where hosts themselves are certified by a trust anchor, these messages MAY also optionally be used between hosts to acquire the peer's certification path. However, the details of such usage are beyond the scope of this specification.
自体はトラストアンカーによって認定されているホスト場合は、これらのメッセージはまた、必要に応じて、ピアの証明書パスを取得するためにホストの間で使用されるかもしれません。しかし、このような使用の詳細については、この仕様の範囲を超えています。
Hosts send Certification Path Solicitations in order to prompt routers to generate Certification Path Advertisements.
ホストは、証明のパス広告を生成するためにルータを促すために証明書のパス要請を送信します。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Component |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IPフィールド：
Source Address
送信元アドレス
A link-local unicast address assigned to the sending interface, or to the unspecified address if no address is assigned to the sending interface.
送信インタフェースに割り当てられたリンクローカルユニキャストアドレス、または全くアドレスを送信インタフェースに割り当てられていない場合、不特定のアドレスへ。
Destination Address
宛先アドレス
Typically the All-Routers multicast address, the Solicited-Node multicast address, or the address of the host's default router.
通常、全ルーターマルチキャストアドレス、要請ノードマルチキャストアドレス、またはホストのデフォルトルータのアドレス。
Hop Limit
ホップ制限
255
２５５
ICMP Fields:
ICMPフィールド：
Type
タイプ
148
１４８
Code
コード
0
０
Checksum
チェックサム
The ICMP checksum [6].
ICMPチェックサム[6]。
Identifier
識別
A 16-bit unsigned integer field, acting as an identifier to help match advertisements to solicitations. The Identifier field MUST NOT be zero, and its value SHOULD be randomly generated. This randomness does not have to be cryptographically hard, as its purpose is only to avoid collisions.
要請にマッチ広告を支援するための識別子として機能する16ビットの符号なし整数フィールド、。識別子フィールドは、ゼロであってはなりません、その値は、ランダムに生成されるべきです。その目的は、衝突を避けるためだけであるので、このランダム性は、暗号的にハードである必要はありません。
Component
成分
This 16-bit unsigned integer field is set to 65,535 if the sender seeks to retrieve all certificates. Otherwise, it is set to the component identifier corresponding to the certificate that the receiver wants to retrieve (see Sections 6.4.2 and 6.4.6).
送信者がすべての証明書を取得しようとする場合には、この16ビットの符号なし整数フィールドが65,535に設定されています。それ以外の場合は、受信機は（セクション6.4.2および6.4.6を参照）を取得したい証明書に対応するコンポーネント識別子に設定されています。
Valid Options:
有効なオプション：
Trust Anchor
トラストアンカー
One or more trust anchors that the client is willing to accept. The first (or only) Trust Anchor option MUST contain a DER Encoded X.501 Name; see Section 6.4.3. If there is more than one Trust Anchor option, the options beyond the first may contain any type of trust anchor.
一つ以上の信頼は、クライアントが受け入れても構わないと思っているアンカー。最初の（または唯一の）トラストアンカーオプションは、DERエンコードX.501名を含まなければなりません。 6.4.3項を参照してください。複数のトラストアンカーオプションがある場合は、最初に超えたオプションは、トラストアンカーのいずれかのタイプが含まれていてもよいです。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. All included options MUST have a length greater than zero.
このプロトコルの将来のバージョンでは、新しいオプションタイプを定義することもできます。受信機は、静かに彼らが認識し、メッセージの処理を継続していない任意のオプションを無視しなければなりません。すべてのオプションはゼロより大きい長さを持っていなければならない含まれていました。
ICMP length (derived from the IP length) MUST be 8 or more octets.
（IP長に由来する）ICMP長は8オクテット以上でなければなりません。
Routers send out Certification Path Advertisement messages in response to a Certification Path Solicitation.
ルータは、証明のパス要請に応じて、証明書のパス広告メッセージを送信します。
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | All Components |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Component | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
IPフィールド：
Source Address
送信元アドレス
A link-local unicast address assigned to the interface from which this message is sent. Note that routers may use multiple addresses, and therefore this address is not sufficient for the unique identification of routers.
このメッセージが送られるインタフェースに割り当てられたリンクローカルユニキャストアドレス。ルータが複数のアドレスを使用してもよいことに留意されたいので、このアドレスはルータを一意に識別するのに十分ではありません。
Destination Address
宛先アドレス
Either the Solicited-Node multicast address of the receiver or the link-scoped All-Nodes multicast address.
受信機の要請ノードマルチキャストアドレスやリンクスコープの全ノードマルチキャストアドレスのいずれか。
Hop Limit
ホップ制限
255
２５５
ICMP Fields:
ICMPフィールド：
Type
タイプ
149
１４９
Code
コード
0
０
Checksum
チェックサム
The ICMP checksum [6].
ICMPチェックサム[6]。
Identifier
識別
A 16-bit unsigned integer field, acting as an identifier to help match advertisements to solicitations. The Identifier field MUST be zero for advertisements sent to the All-Nodes multicast address and MUST NOT be zero for others.
要請にマッチ広告を支援するための識別子として機能する16ビットの符号なし整数フィールド、。識別子フィールドには、全ノードマルチキャストアドレスに送信された広告のためのゼロでなければならないと他人のためにゼロであってはなりません。
All Components
すべてのコンポーネント
A 16-bit unsigned integer field, used to inform the receiver of the number of certificates in the entire path.
全体のパス内の証明書の数の受信機に通知するために使用される16ビットの符号なし整数フィールド、。
A single advertisement SHOULD be broken into separately sent components if there is more than one certificate in the path, in order to avoid excessive fragmentation at the IP layer.
複数の証明書パスに存在する場合、単一の広告は、IP層で過剰な断片化を回避するために、別々に送信される構成要素に分割されるべきです。
Individual certificates in a path MAY be stored and used as received before all the certificates have arrived; this makes the protocol slightly more reliable and less prone to Denial-of-Service attacks.
パス内の個々の証明書が保存され、すべての証明書が到着する前に、そのまま使用することができ、これは、プロトコルが少しより信頼性とサービス拒否攻撃を受けにくくなります。
Examples of packet lengths of Certification Path Advertisement messages for typical certification paths are listed in Appendix C.
典型的な証明書パスのための証明のパス広告メッセージのパケット長の例は、付録Cに記載されています
Component
成分
A 16-bit unsigned integer field, used to inform the receiver which certificate is being sent.
証明書が送信されて受信機に通知するために使用される16ビットの符号なし整数フィールド、。
The first message in an N-component advertisement has the Component field set to N-1, the second set to N-2, and so on. A zero indicates that there are no more components coming in this advertisement.
N成分広告の最初のメッセージはそうでN-1、N-2に対する第2の組のコンポーネントフィールドセットを有し、。ゼロはこの広告に来て、それ以上のコンポーネントが存在しないことを示しています。
The sending of path components SHOULD be ordered so that the certificate after the trust anchor is sent first. Each certificate sent after the first can be verified with the previously sent certificates. The certificate of the sender comes last. The trust anchor certificate SHOULD NOT be sent.
パス・コンポーネントの送信トラストアンカーの後に証明書が最初に送信されるように発注する必要があり。最初の後に送信される各証明書は、以前に送信された証明書で確認することができます。送信者の証明書が最後になります。トラストアンカー証明書を送るべきではありません。
Reserved
予約済み
An unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
未使用のフィールド。これは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Valid Options:
有効なオプション：
Certificate
証明書
One certificate is provided in each Certificate option to establish part of a certification path to a trust anchor.
一つの証明書は、トラストアンカーへの証明書パスの一部を確立するために、各証明書のオプションで提供されます。
The certificate of the trust anchor itself SHOULD NOT be sent.
トラストアンカー自体の証明書を送るべきではありません。
Trust Anchor
トラストアンカー
Zero or more Trust Anchor options may be included to help receivers decide which advertisements are useful for them. If present, these options MUST appear in the first component of a multi-component advertisement.
ゼロ以上のトラストアンカーオプションは、受信機が彼らのために有用である広告を決定するのに役立つために含まれ得ます。存在する場合、これらのオプションは、多成分の広告の最初のコンポーネントに表示される必要があります。
Future versions of this protocol may define new option types. Receivers MUST silently ignore any options they do not recognize and continue processing the message. All included options MUST have a length that is greater than zero.
このプロトコルの将来のバージョンでは、新しいオプションタイプを定義することもできます。受信機は、静かに彼らが認識し、メッセージの処理を継続していない任意のオプションを無視しなければなりません。すべて含まれているオプションには、ゼロより大きい長さを持たなければなりません。
The ICMP length (derived from the IP length) MUST be 8 or more octets.
（IP長に由来する）ICMP長は8オクテット以上でなければなりません。
The format of the Trust Anchor option is described in the following:
トラストアンカーオプションのフォーマットは、以下に説明されています。
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 | Name Type | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
15
１５
Length
長さ
The length of the option (including the Type, Length, Name Type, Pad Length, and Name fields), in units of 8 octets.
8つのオクテットの単位で、（タイプ、長さ、名前タイプ、パッド長さ、および名前フィールドを含む）オプションの長さ。
Name Type
名前タイプ
The type of the name included in the Name field. This specification defines two legal values for this field:
名前の種類は、[名前]フィールドに含まれています。この仕様は、このフィールドには2つの正当な値を定義します。
1 DER Encoded X.501 Name
2 FQDN
Pad Length
パッドの長さ
The number of padding octets beyond the end of the Name field but within the length specified by the Length field. Padding octets MUST be set to zero by senders and ignored by receivers.
[名前]フィールドの端部を越えなく、長さフィールドで指定された長さの範囲内のパディングオクテットの数。パディングオクテットは送信者によってゼロに設定し、受信機で無視しなければなりません。
Name
名前
When the Name Type field is set to 1, the Name field contains a DER encoded X.501 Name identifying the trust anchor. The value is encoded as defined in [12] and [7].
名前タイプフィールドが1に設定されている場合は、[名前]フィールドには、トラストアンカーを特定するDERエンコードされたX.501の名前が含まれています。値が[12]で定義されるように符号化されている[7]。
When the Name Type field is set to 2, the Name field contains a Fully Qualified Domain Name of the trust anchor; for example, "trustanchor.example.com". The name is stored as a string, in the DNS wire format, as specified in RFC 1034 [1]. Additionally, the restrictions discussed in RFC 3280 [7], Section 4.2.1.7 apply.
名前タイプフィールドが2に設定されている場合は、[名前]フィールドには、トラストアンカーの完全修飾ドメイン名が含まれています。例えば、 "trustanchor.example.com"。 RFC 1034で指定されるように名前は、DNSワイヤ形式で、文字列として格納されている[1]。また、RFC 3280で説明した制限は、[7]、セクション4.2.1.7が適用されます。
In the FQDN case, the Name field is an "IDN-unaware domain name slot", as defined in [9]. That is, it can contain only ASCII characters. An implementation MAY support internationalized domain names (IDNs) using the ToASCII operation; see [9] for more information.
FQDNの場合、Nameフィールドで定義されるように、「IDN非対応のドメイン名スロット」である[9]。つまり、ASCII文字のみを含めることができ、あります。実装は、もしToASCII操作を使用して、国際化ドメイン名（IDN）をサポートすることができます。詳細については、[9]を参照してください。
All systems MUST support the DER Encoded X.501 Name. Implementations MAY support the FQDN name type.
すべてのシステムは、DERエンコードX.501名をサポートしなければなりません。実装は、FQDN名のタイプをサポートするかもしれません。
Padding
パディング
A variable-length field making the option length a multiple of 8, beginning after the previous field ends and continuing to the end of the option, as specified by the Length field.
可変長フィールド、オプションの長さを8の倍数を行う前のフィールドの終了後に開始および長さフィールドによって指定されるように、オプションの終わりまで続きます。
The format of the certificate option is described in the following:
証明書オプションのフォーマットは、以下に説明されています。
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 | Cert Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Certificate ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
16
１６
Length
長さ
The length of the option (including the Type, Length, Cert Type, Pad Length, and Certificate fields), in units of 8 octets.
8つのオクテット単位で、（タイプ、長さ、証明書の種類、パッドの長さ、および証明書のフィールドを含む）オプションの長さ。
Cert Type
証明書の種類
The type of the certificate included in the Certificate field. This specification defines only one legal value for this field:
証明書の種類は、証明書のフィールドに含まれています。この仕様は、このフィールドのための唯一の有効な値を定義します。
1 X.509v3 Certificate, as specified below
1のX.509v3証明書として、以下に指定
Reserved
予約済み
An 8-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver.
8ビットのフィールドは、将来の使用のために予約します。値は送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Certificate
証明書
When the Cert Type field is set to 1, the Certificate field contains an X.509v3 certificate [7], as described in Section 6.3.1.
証明書タイプフィールドが1に設定されている場合、証明書フィールドは、X.509v3証明書が含まれている[7]、セクション6.3.1に記載されているように。
Padding
パディング
A variable length field making the option length a multiple of 8, beginning after the ASN.1 encoding of the previous field [7, 15] ends and continuing to the end of the option, as specified by the Length field.
可変長フィールド、オプションの長さを8の倍数を行う前のフィールド[7、15]両端のASN.1符号化後に開始および長さフィールドによって指定されるように、オプションの終わりまで続きます。
A router MUST silently discard any received Certification Path Solicitation messages that do not conform to the message format defined in Section 6.4.1. The contents of the Reserved field and of any unrecognized options MUST be ignored. Future, backward-compatible changes to the protocol may specify the contents of the Reserved field or add new options; backward-incompatible changes may use different Code values. The contents of any defined options that are not specified to be used with Router Solicitation messages MUST be ignored, and the packet processed in the normal manner. The only defined option that may appear is the Trust Anchor option. A solicitation that passes the validity checks is called a "valid solicitation".
ルータは黙っ6.4.1項で定義されたメッセージ・フォーマットに準拠していないすべての受信証明書のパス要請メッセージを捨てなければなりません。予約フィールドのと認識されないオプションの内容は無視しなければなりません。将来的には、プロトコルへの後方互換性の変更は、予約済みフィールドの内容を指定するか、または新しいオプションを追加することができ、下位互換性のない変更は、異なるコード値を使用してもよいです。ルータ要請メッセージで使用するように指定されていない任意の定義されたオプションの内容は無視しなければなりませんし、パケットは通常の方法で処理します。現れるかもしれない唯一の定義されたオプションは、トラストアンカーのオプションです。妥当性チェックに合格勧誘は、「有効な懇願」と呼ばれています。
Routers SHOULD send advertisements in response to valid solicitations received on an advertising interface. If the source address in the solicitation was the unspecified address, the router MUST send the response to the link-scoped All-Nodes multicast address. If the source address was a unicast address, the router MUST send the response to the Solicited-Node multicast address corresponding to the source address, except when under load, as specified below. Routers SHOULD NOT send Certification Path Advertisements more than MAX_CPA_RATE times within a second. When there are more solicitations, the router SHOULD send the response to the All-Nodes multicast address regardless of the source address that appeared in the solicitation.
ルータは広告インタフェースで受信した有効な要請に応じて広告を送るべきです。勧誘の送信元アドレスが未指定アドレスだった場合、ルータはリンクスコープの全ノードマルチキャストアドレスへの応答を送らなければなりません。ソースアドレスがユニキャストアドレスであった場合、ルータは、以下に指定された負荷の下で、のようにする場合を除いて、送信元アドレスに対応する要請ノードマルチキャストアドレスへの応答を送信しなければなりません。ルータは秒以内に、よりMAX_CPA_RATE時間よりも証明のパス広告を送るべきではありません。より多くの勧誘がある場合、ルータは関係なく、勧誘に登場した送信元アドレスの全ノードマルチキャストアドレスに応答を送信すべきです。
In an advertisement, the router SHOULD include suitable Certificate options so that a certification path can be established to the solicited trust anchor (or a part of it, if the Component field in the solicitation is not equal to 65,535). Note also that a single advertisement is broken into separately sent components and ordered in a particular way (see Section 6.4.2) when there is more than one certificate in the path.
（勧誘におけるコンポーネントのフィールドが65,535に等しくない場合、またはその一部）証明書パスを募集トラストアンカーに確立することができるように、広告では、ルータは、適切な証明書のオプションを含むべきです。単一の広告が別々に送ら成分に分割し、特定の方法（セクション6.4.2を参照）の経路で複数の証明書がある場合に順序付けされていることにも留意されたいです。
The anchor is identified by the Trust Anchor option. If the Trust Anchor option is represented as a DER Encoded X.501 Name, then the Name must be equal to the Subject field in the anchor's certificate. If the Trust Anchor option is represented as an FQDN, the FQDN must be equal to an FQDN in the subjectAltName field of the anchor's certificate. The router SHOULD include the Trust Anchor option(s) in the advertisement for which the certification path was found.
アンカーは、トラストアンカーオプションによって識別されます。トラストアンカーオプションはDERエンコードされたX.501名として表現されている場合は、その名前は、アンカーの証明書のサブジェクトフィールドと同じでなければなりません。トラストアンカーオプションはFQDNとして表現されている場合は、FQDNは、アンカーの証明書ののsubjectAltNameフィールドのFQDNと等しくなければなりません。ルータは、証明書パスが見つかったために広告におけるトラストアンカーのオプション（複数可）を含むべきです。
If the router is unable to find a path to the requested anchor, it SHOULD send an advertisement without any certificates. In this case, the router SHOULD include the Trust Anchor options that were solicited.
ルータが要求されたアンカーへのパスを見つけることができない場合は、すべての証明書なしで広告を送るべきです。この場合、ルータが募集されたトラストアンカーオプションを含めるべきです。
A host MUST silently discard any received Certification Path Advertisement messages that do not conform to the message format defined in Section 6.4.2. The contents of the Reserved field, and of any unrecognized options, MUST be ignored. Future, backward-compatible changes to the protocol MAY specify the contents of the Reserved field or add new options; backward-incompatible changes MUST use different Code values. The contents of any defined options not specified to be used with Certification Path Advertisement messages MUST be ignored, and the packet processed in the normal manner. The only defined options that may appear are the Certificate and Trust Anchor options. An advertisement that passes the validity checks is called a "valid advertisement".
ホストは静かに、セクション6.4.2で定義されたメッセージ・フォーマットに準拠していないすべての受信証明書のパス広告メッセージを捨てなければなりません。予約フィールドの、と認識できないオプションの内容は、無視しなければなりません。将来的には、プロトコルへの後方互換性の変更は、予約済みフィールドの内容を指定するか、または新しいオプションを加えるかもしれ。下位互換性のない変更は、異なるコード値を使用しなければなりません。証明経路広告メッセージで使用されるように指定されていない任意の定義されたオプションの内容は無視しなければなりませんし、パケットは通常の方法で処理します。現れるかもしれない唯一の定義されたオプションは、証明書およびトラストアンカーオプションです。妥当性チェックに合格広告は「有効な広告」と呼ばれています。
Hosts SHOULD store certification paths retrieved in Certification Path Discovery messages if they start from an anchor trusted by the host. The certification paths MUST be verified, as defined in Section 6.3, before storing them. Routers send the certificates one by one, starting from the trust anchor end of the path.
彼らはホストから信頼アンカーから始める場合ホストは、証明のパスディスカバリーメッセージで取得した証明書パスを格納する必要があります。それらを格納する前に、セクション6.3で定義されるように認証パスは、検証しなければなりません。ルータは、パスのトラストアンカーの端から始めて、証明書を一つずつ送ります。
Note: Except to allow for message loss and reordering for temporary purposes, hosts might not store certificates received in a Certification Path Advertisement unless they contain a certificate that can be immediately verified either to the trust anchor or to a certificate that has been verified earlier. This measure is intended to prevent Denial-of-Service attacks, whereby an attacker floods a host with certificates that the host cannot validate and overwhelms memory for certificate storage.
注意：彼らはすぐに先に確認された証明書の信頼アンカーにかのいずれか検証することができる証明書が含まれていない限り、一時的な目的のためにメッセージの損失や並べ替えを可能にすることを除いて、証明書を格納しない場合がありますホストは、証明書のパス広告で受け取りました。この措置は、攻撃者がホストを検証し、証明書格納用メモリを圧倒することができない証明書を使用してホストをフラッディングすることにより、サービス拒否攻撃を防ぐためのものです。
Note that caching this information, and the implied verification results between network attachments for use over multiple attachments to the network, can help improve performance. But periodic certificate revocation checks are still needed, even with cached results, to make sure that the certificates are still valid.
この情報をキャッシュし、ネットワークへの複数の添付ファイルにわたる使用のためのネットワークの添付ファイル間の暗黙の検証結果、パフォーマンスを向上させることができていることに注意してください。しかし、定期的な証明書失効チェックがまだ証明書がまだ有効であることを確認するために、も、キャッシュされた結果で、必要とされています。
The host SHOULD retrieve a certification path when a Router Advertisement has been received with a public key that is not available from a certificate in the hosts' cache, or when there is no certification path to one of the host's trust anchors. In these situations, the host MAY send a Certification Path Solicitation message to retrieve the path. If there is no response within CPS_RETRY seconds, the message should be retried. The wait interval for each subsequent retransmission MUST exponentially increase, doubling each time. If there is no response after CPS_RETRY_MAX seconds, the host abandons the certification path retrieval process. If the host receives only a part of a certification path within CPS_RETRY_FRAGMENTS seconds of receiving the first part, it MAY in addition transmit a Certification Path Solicitation message with the Component field set to a value not equal to 65,535. This message can be retransmitted by using the same process as for the initial message. If there are multiple missing certificates, additional CPS messages can be sent after getting a response to first one. However, the complete retrieval process may last at most CPS_RETRY_MAX seconds.
ルータ広告がホストのキャッシュに証明書から利用できない、またはホストの信頼アンカーの1への証明書パスが存在しない場合に公開鍵で受信されたとき、ホストは、証明書パスを取得する必要があります。このような状況では、ホストは、パスを取得するための証明書のパス要請メッセージを送信することができます。 CPS_RETRYの秒以内に応答がない場合は、メッセージが再試行されなければなりません。後続の各再送信の待機間隔は指数関数的に各倍加時間、増大しなければなりません。 CPS_RETRY_MAX秒後に応答がない場合、ホストは、証明書パス検索処理を放棄します。ホストが最初の部分を受信CPS_RETRY_FRAGMENTS秒以内に認証パスの一部のみを受信した場合、それは、さらに65,535に等しくない値に設定コンポーネントフィールドに証明経路要請メッセージを送信してもよいです。このメッセージは、最初のメッセージと同じプロセスを使用して再送信することができます。複数不足している証明書がある場合は、追加のCPSメッセージは、最初の1への応答を取得した後に送信することができます。しかし、完全な検索処理は、ほとんどのCPS_RETRY_MAX秒で続くかもしれません。
Certification Path Solicitations SHOULD NOT be sent if the host has a currently valid certification path from a reachable router to a trust anchor.
ホストは、トラストアンカーへの到達可能なルータから現在有効な証明書パスを持っている場合は証明のパス要請を送るべきではありません。
When soliciting certificates for a router, a host MUST send Certification Path Solicitations either to the All-Routers multicast address, if it has not selected a default router yet, or to the default router's IP address, if a default router has already been selected.
ルータの証明書を勧誘するとデフォルトルータがすでに選択されている場合、ホストは、全ルータマルチキャストアドレスに、それはまだデフォルトルータを選択していない場合、またはデフォルトルータのIPアドレスのいずれかに証明書のパス要請を送らなければなりません。
If two hosts want to establish trust with the CPS and CPA messages, the CPS message SHOULD be sent to the Solicited-Node multicast address of the receiver. The advertisements SHOULD be sent as specified above for routers. However, the exact details are outside the scope of this specification.
2つのホストがCPSやCPAのメッセージとの信頼関係を確立したい場合は、CPSのメッセージは、受信者の要請ノードマルチキャストアドレスに送信する必要があります。ルータの上記指定された広告が送信されるべきです。しかし、正確な詳細は、本明細書の範囲外です。
When processing possible advertisements sent as responses to a solicitation, the host MAY prefer to process those advertisements with the same Identifier field value as that of the solicitation first. This makes Denial-of-Service attacks against the mechanism harder (see Section 9.3).
要請に対する応答として送信可能な広告を処理する場合、ホストは最初の要請と同じ識別子フィールド値と、それらの広告を処理するために好むかもしれません。これは難しいメカニズム（セクション9.3を参照）に対するサービス拒否攻撃を行います。
End hosts are configured with a set of trust anchors in order to protect Router Discovery. A trust anchor configuration consists of the following items:
エンドホストは、ルータ検出を保護するために信頼アンカーのセットで構成されています。トラストアンカーの構成は以下の項目で構成されています。
o A public key signature algorithm and associated public key, which may optionally include parameters.
公開鍵署名アルゴリズム及び任意のパラメータを含むことができる関連する公開キー、O。
o A name as described in Section 6.4.3.
6.4.3項で説明したように名前、O。
o An optional public key identifier.
オプションの公開鍵識別子O。
o An optional list of address ranges for which the trust anchor is authorized.
Oアドレスのオプションのリストは、トラストアンカーが認可されている範囲です。
If the host has been configured to use SEND, it SHOULD possess the above information for at least one trust anchor.
ホストがSENDを使用するように設定されている場合、それは少なくとも一つの信頼アンカーのために、上記の情報を有していなければなりません。
Routers are configured with a collection of certification paths and a collection of certificates containing certified keys, down to the key and certificate for the router itself. Certified keys are required for routers so that a certification path can be established between the router's certificate and the public key of a trust anchor.
ルータがダウンルータ自身のための鍵と証明書に、証明書パスの収集と認定されたキーを含む証明書のコレクションで構成されています。証明書パスがルータの証明書および信頼点の公開鍵との間に確立することができるように認定されたキーは、ルータのために必要とされます。
If the router has been configured to use SEND, it should be configured with its own key pair and certificate, and with at least one certification path.
ルータがSENDを使用するように設定されている場合、それは自身の鍵ペアと証明書で構成され、少なくとも一つの証明書パスを持つべきです。
By default, a SEND-enabled node SHOULD use only CGAs for its own addresses. Other types of addresses MAY be used in testing, in diagnostics, or for other purposes. However, this document does not describe how to choose between different types of addresses for different communications. A dynamic selection can be provided by an API, such as the one defined in [21].
デフォルトでは、SEND対応のノードは、自身のアドレスについてのみCGAsを使用すべきです。アドレスの他のタイプの診断で、または他の目的のために、テストに使用されるかもしれません。しかし、この文書では、異なる通信用アドレスの異なる種類の間で選択する方法については説明しません。動的選択は、[21]で定義されたように、APIによって提供することができます。
If the Target Address and Destination Address fields in the ICMP Redirect message are equal, then this message is used to inform hosts that a destination is, in fact, a neighbor. In this case, the receiver MUST verify that the given address falls within the range defined by the router's certificate. Redirect messages failing this check MUST be treated as unsecured, as described in Section 7.3.
ICMPリダイレクトメッセージでターゲットアドレスと宛先アドレスフィールドが等しい場合、このメッセージは、宛先が、実際には、あるホスト、隣人に通知するために使用されています。この場合、受信機は、与えられたアドレスが、ルータの証明書によって定義された範囲内にあることを確かめなければなりません。 7.3節で説明したように、このチェックは、無担保として扱わなければならない障害が発生したメッセージをリダイレクトします。
Note that base NDP rules prevent a host from accepting a Redirect message from a router that the host is not using to reach the destination mentioned in the redirect. This prevents an attacker from tricking a node into redirecting traffic when the attacker is not the default router.
なお、ベースNDP規則は、ホストがリダイレクトで述べた宛先に到達するために使用していないルータからリダイレクトメッセージを受け入れるからホストを防ぎます。これは、攻撃者がデフォルトルータでない場合にトラフィックをリダイレクトにノードをだましからの攻撃を防ぐことができます。
The router's certificate defines the address range(s) that it is allowed to advertise securely. A router MAY, however, advertise a combination of certified and uncertified subnet prefixes. Uncertified subnet prefixes are treated as unsecured (i.e., processed in the same way as unsecured router advertisements sent by non-SEND routers). The processing of unsecured messages is specified in Section 8. Note that SEND nodes that do not attempt to interoperate with non-SEND nodes MAY simply discard the unsecured information.
ルータの証明書は、しっかりと宣伝を許可されているアドレス範囲（複数可）を定義します。ルータMAYは、しかし、認定と認定されていないサブネットプレフィックスの組み合わせを宣伝します。未承認のサブネットプレフィックスは保護されていないとして扱われる（すなわち、非SENDルータによって送信されたセキュリティで保護されていないルータ広告と同様に処理します）。無担保のメッセージの処理が簡単に無担保の情報を捨てるかもしれ非SENDノードと相互運用しようとしないノードを送信セクション8ノートに指定されています。
Certified subnet prefixes fall into the following two categories:
認定サブネットプレフィックスは、次の2つのカテゴリに分類されます。
Constrained
制約付き
If the network operator wants to constrain which routers are allowed to route particular subnet prefixes, routers should be configured with certificates having subnet prefixes listed in the prefix extension. These routers SHOULD advertise the subnet prefixes that they are certified to route, or a subset thereof.
ネットワークオペレータは、経路特定のサブネットプレフィックスに許可されているルータ制約したい場合、ルータは接頭辞の拡張子に記載されているサブネットプレフィックスを持つ証明書を使用して設定する必要があります。これらのルータは、それらがルートに認定されているサブネットプレフィックス、またはそのサブセットを宣伝すべきです。
Unconstrained
制約なし
Network operators that do not want to constrain routers this way should configure routers with certificates containing either the null prefix or no prefix extension at all.
ルータにこの方法を制限したくないネットワークオペレータはヌル接頭辞または全く接頭辞拡張子のいずれかを含む証明書でルーターを設定する必要があります。
Upon processing a Prefix Information option within a Router Advertisement, nodes SHOULD verify that the prefix specified in this option falls within the range defined by the certificate, if the certificate contains a prefix extension. Options failing this check are treated as containing uncertified subnet prefixes.
ルータ広告内のプレフィックス情報オプションを処理する際に、ノードは、証明書が、プレフィックス拡張が含まれている場合、このオプションで指定されたプレフィックスが、証明書によって定義された範囲内にあることを確認してください。このチェックに失敗オプションは、未認定サブネットプレフィックスを含むものとして扱われます。
Nodes SHOULD use one of the certified subnet prefixes for stateless autoconfiguration. If none of the advertised subnet prefixes match, the host SHOULD use a different advertising router as its default router, if one is available. If the node is performing stateful autoconfiguration, it SHOULD check the address provided by the DHCP server against the certified subnet prefixes and SHOULD NOT use the address if the prefix is not certified.
ノードは、ステートレス自動設定のための認定サブネットプレフィックスのいずれかを使用すべきです。広告を出してサブネットプレフィックスのいずれも一致しない場合が利用可能な場合、ホストは、そのデフォルトルータとして異なる広告ルータを使用すべきです。ノードがステートフル自動設定を実行している場合は、認定されたサブネットプレフィックスに対してDHCPサーバによって提供されたアドレスを確認する必要がありますし、プレフィックスが認定されていない場合は、アドレスを使用しないでください。
This specification does not address the protection of NDP packets for nodes configured with a static address (e.g., PREFIX::1). Future certification path-based authorization specifications are needed for these nodes. This specification also does not apply to addresses generated by the IPv6 stateless address autoconfiguration from a fixed interface identifiers (such as EUI-64).
この仕様は、静的アドレス（例えば、PREFIX :: 1）で構成されたノードのためのNDPパケットの保護に対処していません。将来の証明書パスベースの認証の仕様は、これらのノードのために必要とされます。本明細書はまた、（例えば、EUI-64のような）固定インタフェース識別子からIPv6ステートレスアドレス自動設定によって生成されたアドレスには適用されません。
It is outside the scope of this specification to describe the use of trust anchor authorization between nodes with dynamically changing addresses. These addresses may be the result of stateful or stateless address autoconfiguration, or may have resulted from the use of RFC 3041 [17] addresses. If the CGA method is not used, nodes are required to exchange certification paths that terminate in a certificate authorizing a node to use an IP address having a particular interface identifier. This specification does not specify the format of these certificates, as there are currently only a few cases where they are provided by the link layer, and it is up to the link layer to provide certification for the interface identifier. This may be the subject of a future specification. It is also outside the scope of this specification to describe how stateful address autoconfiguration works with the CGA method.
これは、動的に変化するアドレスを持つノード間のトラストアンカーの承認の使用を記述するために、この仕様の範囲外です。これらのアドレスは、ステートフルまたはステートレスアドレス自動設定の結果であり得るか、またはRFC 3041 [17]アドレスの使用から生じた可能性があります。 CGAの方法を使用しない場合、ノードは、特定のインタフェース識別子を持つIPアドレスを使用するノードを認証証明書で終端証明経路を交換する必要があります。現在彼らはリンク層によって提供されている唯一のいくつかの例があるとしてこの仕様は、これらの証明書の形式を指定していない、それはインタフェース識別子の認証を提供するために、リンク層までです。これは、将来の仕様書の対象となる場合があります。これは、アドレス自動設定がCGA方法でどのように動作するかステートフル記述するために、この仕様の範囲外でもあります。
The Target Address in Neighbor Advertisement is required to be equal to the source address of the packet, except in proxy Neighbor Discovery, which is not supported by this specification.
近隣広告にターゲットアドレスは、本明細書ではサポートされていないプロキシ近隣探索、を除いて、パケットの送信元アドレスに等しいことが要求されます。
During the transition to secured links, or as a policy consideration, network operators may want to run a particular link with a mixture of nodes accepting secured and unsecured messages. Nodes that support SEND SHOULD support the use of secured and unsecured NDP messages at the same time.
保護されたリンクへの遷移中、またはポリシーの考慮事項として、ネットワークオペレータは、固定され、保護されていないメッセージを受け付けるノードの混合物と特定のリンクを実行することができます。 SENDをサポートするノードが同時に担保と無担保NDPメッセージの使用をサポートする必要があります。
In a mixed environment, SEND nodes receive both secured and unsecured messages but give priority to secured ones. Here, the "secured" messages are those that contain a valid signature option, as specified above, and "unsecured" messages are those that contain no signature option.
混在環境では、送信ノードは、担保と無担保の両方のメッセージを受信するが、安全なものに優先権を与えます。ここでは、「安全な」メッセージは、上記の指定されたとおり、有効な署名オプションを含むものである、と「無担保」のメッセージには、署名オプションを含まないものです。
A SEND node SHOULD have a configuration option that causes it to ignore all unsecured Neighbor Solicitation and Advertisement, Router Solicitation and Advertisement, and Redirect messages. This can be used to enforce SEND-only networks. The default for this configuration option SHOULD be that both secured and unsecured messages are allowed.
SENDノードは、すべての無担保近隣要請や広告、ルータ要請と広告を無視することの原因となる設定オプションを持っている、とのメッセージをリダイレクトする必要があります。これは送信専用のネットワークを強制するために使用することができます。この設定オプションのデフォルトは両方の担保と無担保のメッセージが許可されていることであるべきです。
A SEND node MAY also have a configuration option whereby it disables the use of SEND completely, even for the messages it sends itself. This configuration option SHOULD be switched off by default; that is, SEND is used. Plain (non-SEND) NDP nodes will obviously send only unsecured messages. Per RFC 2461 [4], such nodes will ignore the unknown options and will treat secured messages in the same way that they treat unsecured ones. Secured and unsecured nodes share the same network resources, such as subnet prefixes and address spaces.
SENDノードはまたしても、それは自分自身を送信するメッセージのために、完全にSENDの使用を無効にすることにより、設定オプションがあるかもしれません。この設定オプションは、デフォルトではオフにすべきです。それは、SENDが使用されています。プレーン（非SEND）NDPノードは明らかにのみ保護されていないメッセージを送信します。 RFC 2461あたり[4]、そのようなノードは、未知のオプションを無視し、彼らは無担保のものを扱うのと同じ方法でセキュアなメッセージを扱います。担保と無担保のノードは、このようなサブネットプレフィックスとアドレス空間と同じネットワークリソースを共有します。
SEND nodes configured to use SEND at least in their own messages behave in a mixed environment as explained below.
以下に説明するように、混在環境で動作少なくとも、自分のメッセージにSENDを使用するように構成されたノードを送信します。
SEND adheres to the rules defined for the base NDP protocol, with the following exceptions:
以下の例外を除いて、ベースNDPプロトコルのために定義された規則に準拠を送信します。
o All solicitations sent by a SEND node MUST be secured.
O SENDノードによって送信されたすべての勧誘を確保しなければなりません。
o Unsolicited advertisements sent by a SEND node MUST be secured.
O SENDノードによって送信された未承諾広告を確保しなければなりません。
o A SEND node MUST send a secured advertisement in response to a secured solicitation. Advertisements sent in response to an unsecured solicitation MUST be secured as well, but MUST NOT contain the Nonce option.
O SENDノードは、セキュアな勧誘に応じて、セキュリティで保護された広告を送らなければなりません。無担保勧誘に応答して送信される広告も同様に確保する必要がありますが、Nonceのオプションを含めることはできません。
o A SEND node that uses the CGA authorization method to protect Neighbor Solicitations SHOULD perform Duplicate Address Detection as follows. If Duplicate Address Detection indicates that the tentative address is already in use, the node generates a new tentative CGA. If after three consecutive attempts no non-unique address is generated, it logs a system error and gives up attempting to generate an address for that interface.
次のようにO近隣要請を保護するために、CGA認証方式を使用する送信ノードは、重複アドレス検出を実行する必要があります。重複アドレス検出は、仮アドレスがすでに使用されていることを示している場合、ノードは、新しい仮CGAを生成します。 3回の連続試行した後、何の非固有のアドレスが生成されていない場合、それはシステムエラーをログに記録し、そのインターフェイスのアドレスを生成しようと断念します。
When performing Duplicate Address Detection for the first tentative address, the node accepts both secured and unsecured Neighbor Advertisements and Solicitations received in response to the Neighbor Solicitations. When performing Duplicate Address Detection for the second or third tentative address, it ignores unsecured Neighbor Advertisements and Solicitations. (The security implications of this are discussed in Section 9.2.3 and in [11].)
最初の仮アドレスの重複アドレス検出を実行する際に、ノードが固定され、保護されていない近隣広告及び要請の両方が近隣要請に応答して受信受け付けます。第二又は第三の仮アドレスの重複アドレス検出を実行するとき、それは保護されていない近隣広告と要請を無視します。 （本のセキュリティへの影響は、セクション9.2.3および[11]に記載されています。）
o The node MAY have a configuration option whereby it ignores unsecured advertisements, even when performing Duplicate Address Detection for the first tentative address. This configuration option SHOULD be disabled by default. This is a recovery mechanism for cases in which attacks against the first address become common.
Oノードは、最初の仮アドレスの重複アドレス検出を行う場合であっても、それは、セキュリティで保護されていない広告を無視することにより、設定オプションがあるかもしれません。この設定オプションは、デフォルトでは無効にする必要があります。これは、最初のアドレスへの攻撃が一般的になっている場合の回復メカニズムです。
o The Neighbor Cache, Prefix List, and Default Router list entries MUST have a secured/unsecured flag that indicates whether the message that caused the creation or last update of the entry was secured or unsecured. Received unsecured messages MUST NOT cause changes to existing secured entries in the Neighbor Cache, Prefix List, or Default Router List. Received secured messages MUST cause an update of the matching entries, which MUST be flagged as secured.
近隣Oキャッシュ、プレフィックスリスト、およびデフォルトルータリストのエントリは、エントリの作成または最後に更新が発生したメッセージが確保や無担保されたかどうかを示す無担保/保護された旗を持っていなければなりません。受信したセキュリティで保護されていないメッセージは、近隣キャッシュ、プレフィックスリスト、またはデフォルトルータリスト内の既存の確保のエントリに変更を引き起こしてはなりません。確保としてフラグ付けされなければならない一致するエントリの更新を引き起こすしなければならないセキュアなメッセージを受け取りました。
o Neighbor Solicitations for the purpose of Neighbor Unreachability Detection (NUD) MUST be sent to that neighbor's solicited-nodes multicast address if the entry is not secured with SEND.
エントリがSENDで固定されていない場合、近隣到達不能検出（NUD）の目的のためにO近隣要請はその隣人の要請ノードマルチキャストアドレスに送信されなければなりません。
Upper layer confirmations on unsecured neighbor cache entries SHOULD NOT update neighbor cache state from STALE to REACHABLE on a SEND node if the neighbor cache entry has never previously been REACHABLE. This ensures that if an entry spoofing a valid SEND host is created by a non-SEND attacker without being solicited, NUD will be done with the entry for data transmission within five seconds of use.
近隣キャッシュエントリが以前REACHABLEではありませんでした場合は無担保近隣キャッシュエントリの上位層の確認は、SENDノード上REACHABLEにSTALEから近隣キャッシュ状態を更新することはできません。これは有効なSENDホストを偽装エントリを勧誘することなく、非SENDの攻撃者によって作成された場合は、NUDを使用する5秒以内のデータ伝送のためのエントリで行われることを保証します。
As a result, in mixed mode, attackers can take over a Neighbor Cache entry of a SEND node for a longer time only if (a) the SEND node was not communicating with the victim node, so that there is no secure entry for it, and (b) the SEND node is not currently on the link (or is unable to respond).
その結果、混合モードでは、攻撃者は、そのためのセキュアなエントリが存在しないように、（a）はSENDノードは、被害者のノードと通信していなかった場合にのみ、長い時間のためのSENDノードのNeighbor Cacheエントリーを引き継ぐことができますおよび（b）はSENDノードは、リンク上で、現在ではありません（または対応することができません）。
o The conceptual sending algorithm is modified so that an unsecured router is selected only if there is no reachable SEND router for the prefix. That is, the algorithm for selecting a default router favors reachable SEND routers over reachable non-SEND ones.
セキュリティで保護されていないルータがプレフィックスには到達SENDルータが存在しない場合にのみ選択されるように、oを概念的送信アルゴリズムが修正されます。つまり、デフォルトルータを選択するためのアルゴリズムは、到達可能な非SENDのものの上に到達可能なSENDルータを好みます。
o A node MAY adopt a router sending unsecured messages, or a router for which secured messages have been received but for which full security checks have not yet been completed, while security checking is underway. Security checks in this case include certification path solicitation, certificate verification, CRL checks, and RA signature checks. A node MAY also adopt a router sending unsecured messages if a router known to be secured becomes unreachable, but because the unreachability may be the result of an attack it SHOULD attempt to find a router known to be secured as soon as possible. Note that although this can speed up attachment to a new network, accepting a router that is sending unsecured messages or for which security checks are not complete opens the node to possible attacks. Nodes that choose to accept such routers do so at their own risk. The node SHOULD, in any case, prefer a router known to be secure as soon as one is made available with completed security checks.
セキュリティチェックが進行中である間、Oノードは、ルータ送信無担保メッセージ、またはメッセージが受信されていますが、そのために、完全なセキュリティチェックがまだ完了していない固定しているため、ルータを採用することができます。この場合、セキュリティチェックは、認証パス勧誘、証明書検証、CRLチェック、およびRA署名チェックを含みます。ノードも確保されることが知られているルータが到達不能になった場合、無担保メッセージを送信するルータを採用してもよいが、到達不能攻撃の結果である可能性がありますので、できるだけ早く確保することが知られているルータを見つけることを試みる必要があります。これは、無担保メッセージやそのためのセキュリティチェックが完了していないを送信しているルータを受け入れ、新しいネットワークへの接続を高速化することができますが、可能な攻撃にノードを開くことに注意してください。ルーターを受け入れることを選択したノードは、自分の責任で行ってください。ノードは、どのような場合には、1が完成セキュリティチェックで使用可能になり次第、安全であると知られているルータを選ぶべきです。
SEND does not provide confidentiality for NDP communications.
SENDは、NDPの通信のための機密性を提供していません。
SEND does not compensate for an unsecured link layer. For instance, there is no assurance that payload packets actually come from the same peer against which the NDP was run.
SENDは、無担保リンク層を補償するものではありません。例えば、ペイロードパケットが実際にNDPを実行し、それに対して同じピアから来ることを保証はありません。
There may not be cryptographic binding in SEND between the link layer frame address and the IPv6 address. An unsecured link layer could allow nodes to spoof the link layer address of other nodes. An attacker could disrupt IP service by sending out a Neighbor Advertisement on an unsecured link layer, with the link layer source address on the frame set as the source address of a victim, a valid
リンク層フレームアドレスとIPv6アドレスのSENDに暗号の結合がない可能性があります。無担保リンク層は、ノードが他のノードのリンクレイヤアドレスを偽装する可能性があります。攻撃者は、有効な、被害者の送信元アドレスとして設定されたフレーム上のリンク層の送信元アドレスと、無担保リンク層の上に近隣広告を送信することでIPサービスを中断する可能性が
CGA address and a valid signature corresponding to itself, and a Target Link-layer Address extension corresponding to the victim. The attacker could then make a traffic stream bombard the victim in a DoS attack. This cannot be prevented just by securing the link layer.
CGAアドレスと自分自身に対応する有効な署名、および被害者に対応する目標リンク層アドレス拡張。その後、攻撃者は、トラフィックストリームがDoS攻撃で犠牲者を砲撃作ることができます。これはちょうど、リンク層を確保することによって防止することができません。
Even on a secured link layer, SEND does not require that the addresses on the link layer and Neighbor Advertisements correspond. However, performing these checks is RECOMMENDED if the link layer technology permits.
でも、保護されたリンク層の上に、リンク層及び近隣広告上のアドレスが対応している必要はありません送信します。リンクレイヤ技術が許す場合は、これらのチェックを行うことが推奨されます。
Prior to participating in Neighbor Discovery and Duplicate Address Detection, nodes must subscribe to the link-scoped All-Nodes Multicast Group and the Solicited-Node Multicast Group for the address that they are claiming as their addresses; RFC 2461 [4]. Subscribing to a multicast group requires that the nodes use MLD [16]. MLD contains no provision for security. An attacker could send an MLD Done message to unsubscribe a victim from the Solicited-Node Multicast address. However, the victim should be able to detect this attack because the router sends a Multicast-Address-Specific Query to determine whether any listeners are still on the address, at which point the victim can respond to avoid being dropped from the group. This technique will work if the router on the link has not been compromised. Other attacks using MLD are possible, but they primarily lead to extraneous (but not necessarily overwhelming) traffic.
前近隣探索に参加すると、重複アドレス検出、ノードは彼らのアドレスとして主張されているアドレスにリンクスコープ全ノードマルチキャストグループと要請ノードマルチキャストグループに加入しなければなりません。 RFC 2461 [4]。マルチキャストグループに加入すると、ノードはMLD [16]を使用する必要があります。 MLDは、セキュリティに関する規定が含まれていません。攻撃者は、要請ノードマルチキャストアドレスから被害者を解除するMLD Doneメッセージを送信することができます。ルータはリスナーが被害者がグループから削除されないように対応することができ、その時点でのアドレス、に残っているかどうかを判断するためにマルチキャストアドレス固有のクエリーを送信するためしかし、被害者がこの攻撃を検出することができるはずです。リンク上のルータが危険にさらされていない場合には、この技術は動作します。 MLDを使用して他の攻撃は可能ですが、彼らは主に余分な（必ずしも圧倒的ではない）トラフィックにつながります。
The SEND protocol is designed to counter the threats to NDP, as outlined in [22]. The following subsections contain a regression of the SEND protocol against the threats, to illustrate which aspects of the protocol counter each threat.
[22]に概説されるようにSENDプロトコルは、NDPの脅威に対抗するように設計されています。以下のサブセクションでは、プロトコル・カウンタのどの側面各脅威を説明するために、脅威に対するSENDプロトコルの退行を含みます。
This threat is defined in Section 4.1.1 of [22]. The threat is that a spoofed message may cause a false entry in a node's Neighbor Cache. There are two cases:
この脅威は、[22]のセクション4.1.1で定義されています。脅威は、偽装されたメッセージは、ノードの近隣キャッシュで虚偽を引き起こすかもしれないことです。 2つのケースがあります。
1. Entries made as a side effect of a Neighbor Solicitation or Router Solicitation. A router receiving a Router Solicitation with a Target Link-Layer Address extension and the IPv6 source address unequal to the unspecified address inserts an entry for the IPv6 address into its Neighbor Cache. Also, a node performing Duplicate Address Detection (DAD) that receives a Neighbor Solicitation for the same address regards the situation as a collision and ceases to solicit for the address.
近隣要請又はルータ要請の副作用として作製1.エントリー。ターゲットリンク層アドレス拡張と未指定アドレスへの不均等なIPv6ソースアドレスを持つルータ要請を受信したルータは、その近隣キャッシュにIPv6アドレスのエントリを挿入します。また、同じアドレスの近隣要請を受信した重複検出（DAD）をアドレス行うノードは、衝突のような状況について、およびアドレスの勧誘を停止します。
In either case, SEND counters these threats by requiring that the RSA Signature and CGA options be present in these solicitations.
いずれの場合においても、RSA署名とCGAオプションは、これらの要請に存在することを要求することによって、カウンタをこれらの脅威を送信します。
SEND nodes can send Router Solicitation messages with a CGA source address and a CGA option, which the router can verify, so that the Neighbor Cache binding is correct. If a SEND node must send a Router Solicitation with the unspecified address, the router will not update its Neighbor Cache, as per base NDP.
近隣キャッシュのバインディングが正しくなるようにノードは、ルータが確認することができCGAソースアドレスとCGAオプション付きのルータ要請メッセージを送信することができます送信します。 SENDノードが未指定アドレスにルータ要請を送信する必要がある場合、ルータは基本NDPごとに、その近隣キャッシュを更新しません。
2. Entries made as a result of a Neighbor Advertisement message. SEND counters this threat by requiring that the RSA Signature and CGA options be present in these advertisements.
近隣広告メッセージの結果として作ら2.エントリー。 RSA署名とCGAオプションは、これらの広告に存在することを要求することによって、カウンタにこの脅威を送信します。
Also see Section 9.2.5, below, for discussion about replay protection and timestamps.
また、リプレイ保護とタイムスタンプについての議論のために、以下のセクション9.2.5を参照してください。
This attack is described in Section 4.1.2 of [22]. SEND counters it by requiring that a node responding to Neighbor Solicitations sent as NUD probes include an RSA Signature option and proof of authorization to use the interface identifier in the address being probed. If these prerequisites are not met, the node performing NUD discards the responses.
この攻撃は、[22]のセクション4.1.2に記載されています。 NUDプローブとして送信される近隣要請に応答するノードがRSA署名オプションとプローブされたアドレスにインタフェース識別子を使用する許可の証拠を含めることを要求することによりカウンターにそれを送ります。これらの前提条件が満たされない場合は、NUDを実行するノードが応答を破棄します。
This attack is described in Section 4.1.3 of [22]. SEND counters this attack by requiring that the Neighbor Advertisements sent as responses to DAD include an RSA Signature option and proof of authorization to use the interface identifier in the address being tested. If these prerequisites are not met, the node performing DAD discards the responses.
この攻撃は、[22]のセクション4.1.3に記載されています。 DADへの応答として送信近隣広告は、RSA署名オプションと試験されるアドレスをインタフェース識別子を使用する許可の証拠を含めることを要求することにより、カウンタにこの攻撃を送信します。これらの前提条件が満たされない場合は、DADを実行するノードが応答を破棄します。
When a SEND node performs DAD, it may listen for address collisions from non-SEND nodes for the first address it generates, but not for new attempts. This protects the SEND node from DAD DoS attacks by non-SEND nodes or attackers simulating non-SEND nodes, at the cost of a potential address collision between a SEND node and a non-SEND node. The probability and effects of such an address collision are discussed in [11].
SENDノードは、DADを実行するとき、それはなく、新たな試みのために、それが生成する第1のアドレスのための非SENDノードからアドレス衝突をリッスンすることができます。これは、送信ノードと非SENDノードとの間の電位アドレス衝突のコストで、非SENDノードをシミュレート非SENDノード又は攻撃者によってDAD DoS攻撃からSENDノードを保護します。このようなアドレス衝突の確率と効果が[11]に記載されています。
These attacks are described in Sections 4.2.1, 4.2.4, 4.2.5, 4.2.6, and 4.2.7 of [22]. SEND counters them by requiring that Router Advertisements contain an RSA Signature option, and that the signature is calculated by using the public key of a node that can prove its authorization to route the subnet prefixes contained in any Prefix Information Options. The router proves its authorization by showing a certificate containing the specific prefix or an indication that the router is allowed to route any prefix. A Router Advertisement without these protections is discarded.
これらの攻撃は、セクション4.2.1に記載4.2.4、4.2.5、4.2.6、および[22]の4.2.7されています。ルータ広告は、RSA署名オプションが含まれていること、および署名がルートに任意のプレフィックス情報オプションに含まれるサブネットプレフィックスをその承認を証明することができるノードの公開鍵を用いて計算されることを要求することによって、カウンターにそれらを送ります。ルータは、特定のプレフィックスまたはルータが任意のプレフィックスルートに許可されていることの指示を含む証明書を示すことによって、その権限を証明します。これらの保護なしのルータ広告は破棄されます。
SEND does not protect against brute force attacks on the router, such as DoS attacks, or against compromise of the router, as described in Sections 4.4.2 and 4.4.3 of [22].
セクション4.4.2及び[22]の4.4.3に記載されているように、そのような、またはルータの妥協に対するDoS攻撃のようなルータのブルートフォース攻撃を防御しないSEND。
This attack is described in Section 4.3.1 of [22]. SEND protects against attacks in Router Solicitation/Router Advertisement and Neighbor Solicitation/Neighbor Advertisement transactions by including a Nonce option in the solicitation and requiring that the advertisement include a matching option. Together with the signatures, this forms a challenge-response protocol.
この攻撃は、[22]のセクション4.3.1に記載されています。 SENDは勧誘でNonceのオプションを含めて、広告が一致するオプションが含まれていることを要求することにより、ルータ要請/ルータアドバタイズメントおよび近隣要請/近隣広告取引における攻撃から保護します。一緒に署名して、これはチャレンジレスポンスプロトコルを形成しています。
SEND protects against attacks from unsolicited messages such as Neighbor Advertisements, Router Advertisements, and Redirects by including a Timestamp option. The following security issues are relevant only for unsolicited messages:
SENDは、タイムスタンプオプションを含めることによって、このような近隣広告、ルータ広告、およびリダイレクトなどの迷惑メールからの攻撃を防御します。次のようなセキュリティ上の問題は、迷惑メッセージのために関連しています。
o A window of vulnerability for replay attacks exists until the timestamp expires.
タイムスタンプの有効期限が切れるまでOリプレイ攻撃のための脆弱性のウィンドウが存在します。
However, such vulnerabilities are only useful for attackers if the advertised parameters change during the window. Although some parameters (such as the remaining lifetime of a prefix) change often, radical changes typically happen only in the context of some special case, such as switching to a new link layer address due to a broken interface adapter.
アドバタイズされたパラメータは、ウィンドウの中に変更した場合しかし、そのような脆弱性は、攻撃者のためにのみ有用です。 （そのような接頭語の残りの寿命のような）いくつかのパラメータが頻繁に変更するが、根本的な変化は、典型的には、原因破損インタフェースアダプタに新しいリンク層アドレスに切り替えるように、いくつかの特別なケースのコンテキストでのみ起こります。
SEND nodes are also protected against replay attacks as long as they cache the state created by the message containing the timestamp. The cached state allows the node to protect itself against replayed messages. However, once the node flushes the state for whatever reason, an attacker can re-create the state by replaying an old message while the timestamp is still valid. Because most SEND nodes are likely to use fairly coarse-grained timestamps, as explained in Section 5.3.1, this may affect some nodes.
SENDのノードはまた、限り、彼らはタイムスタンプを含むメッセージによって作成された状態をキャッシュとしてリプレイ攻撃から保護されています。キャッシュされた状態は、ノードが再生メッセージに対して自身を保護することができます。ノードが何らかの理由で状態をフラッシュした後しかし、攻撃者は、タイムスタンプがまだ有効である一方、古いメッセージを再生することで状態を再作成することができます。ほとんどは、ノードを送っているので、セクション5.3.1で説明したように、これはいくつかのノードに影響を与える可能性があり、かなり粗粒度のタイムスタンプを使用する可能性があります。
o Attacks against time synchronization protocols such as NTP [23] may cause SEND nodes to have an incorrect timestamp value. This can be used to launch replay attacks, even outside the normal window of vulnerability. To protect against these attacks, it is recommended that SEND nodes keep independently maintained clocks or apply suitable security measures for the time synchronization protocols.
OこのようなNTP [23]などの時間同期プロトコルに対する攻撃は、送信ノードが誤ったタイムスタンプ値を持たせることができます。これはさえ脆弱性の通常の窓の外、リプレイ攻撃を起動するために使用することができます。これらの攻撃から保護するために、ノードが独立して維持されたクロックを維持するか、時刻同期プロトコルのために、適切なセキュリティ対策を適用し送信することをお勧めします。
This attack is described in Section 4.3.2 of [22]. In it, the attacker bombards the router with packets for fictitious addresses on the link, causing the router to busy itself by performing Neighbor Solicitations for addresses that do not exist. SEND does not address this threat because it can be addressed by techniques such as rate limiting Neighbor Solicitations, restricting the amount of state reserved for unresolved solicitations, and clever cache management. These are all techniques involved in implementing Neighbor Discovery on the router.
この攻撃は、[22]のセクション4.3.2に記載されています。それには、攻撃者が存在しないアドレスのための近隣要請を行うことで、忙しい自体にルータを引き起こし、リンク上の架空のアドレスのためのパケットをルータに衝突します。それは未解決の勧誘のために予約状態の量、および巧妙なキャッシュ管理を制限する、ような速度制限近隣要請などの技術によって対処することができますので、SENDは、この脅威に対応していません。これらは、ルータ上で近隣探索の実装に関わる全ての技術です。
The CGAs have a 59-bit hash value. The security of the CGA mechanism has been discussed in [11].
CGAsは、59ビットのハッシュ値を持っています。 CGAメカニズムのセキュリティは[11]で議論されてきました。
Some Denial-of-Service attacks remain against NDP and SEND itself. For instance, an attacker may try to produce a very high number of packets that a victim host or router has to verify by using asymmetric methods. Although safeguards are required to prevent an excessive use of resources, this can still render SEND non-operational.
いくつかのサービス拒否攻撃は、NDPに対して残り、自身を送信します。例えば、攻撃者は被害者のホストまたはルータは、非対称な方法を使って検証しなければならないパケットの非常に高い数値を生成しようとするかもしれません。セーフガードは、資源の過度の使用を防止するために必要とされるが、これはまだ非動作、SENDレンダリングすることができます。
When CGA protection is used, SEND deals with the DoS attacks by using the verification process described in Section 5.2.2. In this process, a simple hash verification of the CGA property of the address is performed before the more expensive signature verification. However, even if the CGA verification succeeds, no claims about the validity of the message can be made until the signature has been checked.
CGAの保護が使用されている場合は、5.2.2項で説明した検証プロセスを使用してDoS攻撃との取引を送信します。このプロセスでは、アドレスのCGAプロパティの簡単なハッシュ検証は、より高価な署名検証の前に行われます。署名が確認されるまでしかし、CGA検証が成功しても、メッセージの有効性についての主張を行うことはできません。
When trust anchors and certificates are used for address validation in SEND, the defenses are not quite as effective. Implementations SHOULD track the resources devoted to the processing of packets received with the RSA Signature option and start selectively discarding packets if too many resources are spent. Implementations MAY also first discard packets that are not protected with CGA.
信頼アンカーと証明書がSENDにアドレス確認のために使用される場合、防御は非常に効果的ではありません。実装は、RSA署名オプションを指定して受信したパケットの処理に専念リソースを追跡し、あまりにも多くのリソースが費やされている場合はパケットを廃棄選択的に開始する必要があります。また、実装は最初のCGAで保護されていないパケットを捨てるかもしれ。
The Authorization Delegation Discovery process may also be vulnerable to Denial-of-Service attacks. An attack may target a router by requesting that a large number of certification paths be discovered for different trust anchors. Routers SHOULD defend against such attacks by caching discovered information (including negative responses) and by limiting the number of different discovery processes in which they engage.
認証委任ディスカバリー・プロセスはまた、サービス拒否攻撃に対して脆弱である可能性があります。攻撃は、証明書パスの多数が異なるトラストアンカーのために発見されることを要求して、ルータを標的とすることができます。ルータは（否定応答を含む）を発見した情報をキャッシュすることで、彼らが従事した別の検出プロセスの数を制限することによって、このような攻撃を防御すべきです。
Attackers may also target hosts by sending a large number of unnecessary certification paths, forcing hosts to spend useless memory and verification resources on them. Hosts can defend against such attacks by limiting the amount of resources devoted to the certification paths and their verification. Hosts SHOULD also prioritize advertisements sent as a response to solicitations the hosts have sent about unsolicited advertisements.
攻撃者はまた、それらに無用のメモリと検証リソースを過ごすためにホストを強制的に、不必要な証明書パスを大量に送信することにより、ホストを標的とすることができます。ホストは、証明書のパスとその検証に専念リソースの量を制限することによって、このような攻撃を防御することができます。また、ホストは未承諾広告について送信されたホストを勧誘するための応答として送信される広告の優先順位を決定すべきです。
Host constants:
定数をホスト：
CPS_RETRY 1 second
CPS_RETRY_FRAGMENTS 2 seconds
CPS_RETRY_MAX 15 seconds
Router constants:
ルータの定数：
MAX_CPA_RATE 10 times per second
MAX_CPA_RATE毎秒10回
TIMESTAMP_DELTA 300 seconds (5 minutes)
TIMESTAMP_FUZZ 1 second
TIMESTAMP_DRIFT 1 % (0.01)
This document defines two new ICMP message types, used in Authorization Delegation Discovery. These messages must be assigned ICMPv6 type numbers from the informational message range:
この文書では、認可の委任ディスカバリーで使用される2つの新しいICMPメッセージタイプを定義します。これらのメッセージは、情報メッセージの範囲からのICMPv6タイプ番号を割り当てる必要があります。
o The Certification Path Solicitation message (148), described in Section 6.4.1.
証明書パス要請メッセージ（148）O、セクション6.4.1に記載。
o The Certification Path Advertisement message (149), described in Section 6.4.2.
証明のパス広告メッセージ（149）O、6.4.2項で説明しました。
This document defines six new Neighbor Discovery Protocol [4] options, which must be assigned Option Type values within the option numbering space for Neighbor Discovery Protocol messages:
この文書では、近隣探索プロトコルメッセージのオプションの番号空間内のオプションタイプ値を割り当てなければならない6つの新しい近隣探索プロトコル[4]オプションを定義します。
o The CGA option (11), described in Section 5.1.
CGAオプション（11）O、5.1節で説明。
o The RSA Signature option (12), described in Section 5.2.
RSA署名オプション（12）O、5.2節で説明。
o The Timestamp option (13), described in Section 5.3.1.
タイムスタンプオプション（13）O、5.3.1項で説明。
o The Nonce option (14), described in Section 5.3.2.
ノンスオプション（14）O、セクション5.3.2に記載。
o The Trust Anchor option (15), described in Section 6.4.3.
トラストアンカーオプション（15）O、セクション6.4.3に記載。
o The Certificate option (16), described in Section 6.4.4.
証明書のオプション（16）O、6.4.4項で説明。
This document defines a new 128-bit value under the CGA Message Type [11] namespace, 0x086F CA5E 10B2 00C9 9C8C E001 6427 7C08.
この文書では、CGAメッセージタイプ[11]ネームスペース、0x086F CA5E 10B2 00C9 9C8CのE001 6427 7C08の下で新たな128ビットの値を定義します。
This document defines a new name space for the Name Type field in the Trust Anchor option. Future values of this field can be allocated by using Standards Action [3]. The current values for this field are
この文書では、トラストアンカーオプションで名前タイプフィールドの新しい名前空間を定義します。このフィールドの将来の値は標準アクションを使用して割り当てることができる[3]。このフィールドの現在の値は、
1 DER Encoded X.501 Name
1つのDERエンコードX.501名
2 FQDN
2 FQDN
Another new name space is allocated for the Cert Type field in the Certificate option. Future values of this field can be allocated by using Standards Action [3]. The current values for this field are
もう一つの新しい名前空間がCertificateオプションで証明書の種類]フィールドに割り当てられています。このフィールドの将来の値は標準アクションを使用して割り当てることができる[3]。このフィールドの現在の値は、
1 X.509v3 Certificate
1のX.509v3証明書
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[3] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Narten氏、T.、Nordmarkと、E.およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[5]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[6]コンタ、A.、およびS.デアリングを、 "インターネット制御メッセージプロトコル（ICMPv6の）インターネットプロトコルバージョン6（IPv6）の仕様は、"、RFC 2463、1998年12月。
[7] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[7] Housley氏、R.、ポーク、W.、フォード、W.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）プロフィール"、RFC 3280、2002年4月。
[8] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[8]ファレル、S.とR. Housley氏、 "認可のためのインターネット属性証明書プロフィール"、RFC 3281、2002年4月。
[9] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[9] Faltstrom、P.、ホフマン、P.および "アプリケーションにおける国際化ドメイン名（IDNA）" A.コステロ、RFC 3490、2003年3月。
[10] Lynn, C., Kent, S. and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[10]リン、C.、ケント、S.とK.ソを、 "IPアドレスとAS識別子のためのX.509拡張機能"、RFC 3779、2004年6月。
[11] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[11]オーラ、T.、 "暗号化生成アドレス（CGA）"、RFC 3972、2005年3月。
[12] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, July 2002.
[12]国際電気通信連合、 "情報技術 - ASN.1エンコーディング規則：基本符号化規則（BER）、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）の仕様"、ITU-T勧告X.690、7月2002。
[13] RSA Laboratories, "RSA Encryption Standard, Version 2.1", PKCS 1, November 2002.
[13] RSA Laboratories社、 "RSA暗号化規格、バージョン2.1"、PKCS 1、2002年11月。
[14] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
[14]米国国立標準技術研究所、 "セキュアハッシュ標準"、FIPS PUB 180-1の、1995年4月、<http://www.itl.nist.gov/fipspubs/fip180-1.htm>。
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[15]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[16] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[16]デアリング、S.、フェナー、W.およびB.ハーバーマン、 "マルチキャストリスナ発見（MLD）IPv6の"、RFC 2710、1999年10月。
[17] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[17] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[18] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[18] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.及びM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[19] Arkko, J., "Effects of ICMPv6 on IKE and IPsec Policies", Work in Progress, March 2003.
[19] Arkko、J.、 "IKEおよびIPsecポリシー上のICMPv6の影響"、進歩、2003年3月での作業。
[20] Arkko, J., "Manual SA Configuration for IPv6 Link Local Messages", Work in Progress, June 2002.
[20] Arkko、J.、 "IPv6のリンクローカルメッセージの手動SA設定"、進歩、2002年6月での作業。
[21] Nordmark, E., Chakrabarti, S. and J. Laganier, "IPv6 Socket API for Address Selection", Work in Progress, October 2003.
[21] Nordmarkと、E.、Chakrabarti、S.とJ. Laganier、 "アドレス選択のIPv6ソケットAPI"、進歩、2003年10月に作業。
[22] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[22] Nikander、P.、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
[23] Bishop, M., "A Security Analysis of the NTP Protocol", Sixth Annual Computer Security Conference Proceedings, December 1990.
[23]ビショップ、M.、「NTPプロトコルのセキュリティ分析」、第6回コンピュータセキュリティ会議議事録、1990年12月。
Appendix A. Contributors and Acknowledgments
付録A.寄稿者と謝辞
Tuomas Aura contributed the transition mechanism specification in Section 8. Jonathan Trostle contributed the certification path example in Section 6.3.1. Bill Sommerfeld was involved with much of the early design work.
Tuomasオーラセクション8ジョナサンTrostleの遷移機構の仕様に貢献セクション6.3.1において認証パスの例に貢献。ビル・ゾンマーフェルトは初期の設計作業の多くに関与しました。
The authors would also like to thank Tuomas Aura, Bill Sommerfeld, Erik Nordmark, Gabriel Montenegro, Pasi Eronen, Greg Daley, Jon Wood, Julien Laganier, Francis Dupont, Pekka Savola, Wenxiao He, Valtteri Niemi, Mike Roe, Russ Housley, Thomas Narten, and Steven Bellovin for interesting discussions in this problem space and for feedback regarding the SEND protocol.
著者らはまたのTuomasオーラ、ビルゾンマーフェルト、エリックNordmarkと、ガブリエルモンテネグロ、パシEronen、グレッグ・デイリー、ジョン・ウッド、ジュリアンLaganier、フランシスデュポン、ペッカSavola、Wenxiao彼、Valtteriニエミ、マイク・卵、ラスHousley、トーマスに感謝したいと思いますこの問題空間で興味深い議論をし、SENDプロトコルに関するフィードバックのためのNarten氏、そしてスティーブンBellovin氏。
Appendix B. Cache Management
付録B.キャッシュ管理
In this section, we outline a cache management algorithm that allows a node to remain partially functional even under a cache-filling DoS attack. This appendix is informational, and real implementations SHOULD use different algorithms in order to avoid the dangers of a mono-cultural code.
このセクションでは、ノードもキャッシュ充填DoS攻撃の下で部分的機能を維持することを可能にするキャッシュ管理アルゴリズムの概要を説明します。この付録は情報であり、実際の実装では、モノカルチャーコードの危険性を避けるために、異なるアルゴリズムを使用すべきです。
There are at least two distinct cache-related attack scenarios:
少なくとも2つの別個のキャッシュ関連の攻撃のシナリオがあります。
1. There are a number of nodes on a link, and someone launches a cache filling attack. The goal here is to make sure that the nodes can continue to communicate even if the attack is going on.
1.そこリンク上のノードの数があり、誰かが攻撃を充填キャッシュを起動します。ここでの目標は、ノードは、攻撃が起こっている場合でも通信を継続できることを確認することです。
2. There is already a cache-filling attack going on, and a new node arrives to the link. The goal here is to make it possible for the new node to become attached to the network, in spite of the attack.
2.そこに起こってキャッシュ充填攻撃がすでにあり、新しいノードがリンクに到着しました。ここでの目標は、新しいノードが攻撃にもかかわらず、ネットワークに付着することを可能にすることです。
As the intent is to limit the damage to existing, valid cache entries, it is clearly better to be very selective in throwing out entries. Reducing the timestamp Delta value is very discriminatory against nodes with a large clock difference, as an attacker can reduce its clock difference arbitrarily. Throwing out old entries just because their clock difference is large therefore seems like a bad approach.
目的は、既存の、有効なキャッシュエントリへの損傷を制限することがあるとして、エントリを投げるには非常に選択的であることが明らかに優れています。タイムスタンプデルタ値を小さくすると、攻撃者が任意のクロック差を減らすことができますよう、大きなクロック差を持つノードに対して非常に差別的です。そのクロック差が大きいからといって、古いエントリを投げるので、悪いアプローチのように思えます。
It is reasonable to have separate cache spaces for new and old entries, where when under attack, the newly cached entries would be more readily dropped. One could track traffic and only allow reasonable new entries that receive genuine traffic to be converted into old cache entries. Although such a scheme can make attacks harder, it will not fully prevent them. For example, an attacker could send a little traffic (i.e., a ping or TCP syn) after each NS to trick the victim into promoting its cache entry to the old cache. To counter this, the node can be more intelligent in keeping its cache entries than it would be just by having a black/white old/new boundary.
攻撃を受けて、新たにキャッシュされたエントリがより容易に廃棄されます新旧エントリのための個別のキャッシュスペースを持っていることが合理的です。一つは、トラフィックを追跡し、唯一の本物のトラフィックを受信する合理的な新しいエントリが古いキャッシュエントリに変換される可能性があります。このようなスキームが困難な攻撃を行うことができますが、それは完全にそれらを防ぐことはできません。例えば、攻撃者が古いキャッシュへのキャッシュエントリを促進に被害者をだまして、各NSの後に少しトラフィック（すなわち、pingやTCP SYN）を送信することができます。これに対抗するために、ノードは、それだけで黒/白の古い/新しい境界を持つことになるよりも、そのキャッシュエントリを保つことで、よりインテリジェントなことができます。
Distinction of the Sec parameter from the CGA Parameters when forcing cache entries out -- by keeping entries with larger Sec parameters preferentially -- also appears to be a possible approach, as CGAs with higher Sec parameters are harder to spoof.
CGAパラメータから秒パラメータの区別キャッシュを強制的にアウトエントリ - 優先的に大きな秒パラメータでエントリを保つことによっては - また、より高い秒のパラメータを持つCGAsとして、可能なアプローチのように見える偽装が困難です。
Appendix C. Message Size When Carrying Certificates
付録C.メッセージサイズの証明書キャリング
In one example scenario using SEND, an Authorization Delegation Discovery test run was made with a certification path length of 4. Three certificates are sent by using Certification Path Advertisement messages, as the trust anchor's certificate is already known by both parties. With a key length of 1024 bits, the certificate lengths in the test run ranged from 864 to 888 bytes; the variation is due to the differences in the certificate issuer names and address prefix extensions. The different certificates had between 1 and 4 address prefix extensions.
トラストアンカーの証明書がすでに両当事者が知られているようにSENDを使用した1例のシナリオでは、認証委任ディスカバリーのテストランは、証明経路広告メッセージを使用して送信されます。4. 3つの証明書の証明書パスの長さで作られました。 1024ビットの鍵長と、テスト実行中の証明書の長さは、864から888バイトの範囲でした。バリエーションは、証明書発行者の名前とアドレスプレフィックス拡張の違いによるものです。異なる証明書は、1〜4アドレスプレフィックス拡張を持っていました。
The three Certification Path Advertisement messages ranged from 1050 to 1,066 bytes on an Ethernet link layer. The certificate itself accounts for the bulk of the packet. The rest is the trust anchor option, ICMP header, IPv6 header, and link layer header.
3つの証明のパス広告メッセージは、イーサネット・リンク層の上に1050年から1066バイトの範囲でした。証明書自体は、パケットの大部分を占めています。残りはトラストアンカーオプション、ICMPヘッダ、IPv6ヘッダ、およびリンク層のヘッダです。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson Jorvas 02420 Finland
ヤリArkkoエリクソン02420 Jorvasフィンランド
EMail: jari.arkko@ericsson.com
メールアドレス：jari.arkko@ericsson.com
James Kempf DoCoMo Communications Labs USA 181 Metro Drive San Jose, CA 94043 USA
ジェームズ・ケンプドコモコミュニケーション研究所USA 181メトロドライブサンノゼ、CA 94043 USA
EMail: kempf@docomolabs-usa.com
メールアドレス：kempf@docomolabs-usa.com
Brian Zill Microsoft Research One Microsoft Way Redmond, WA 98052 USA
ブライアンZillマイクロソフトリサーチ1マイクロソフト道、レッドモンド、ワシントン98052 USA
EMail: bzill@microsoft.com
メールアドレス：bzill@microsoft.com
Pekka Nikander Ericsson Jorvas 02420 Finland
ペッカNikanderエリクソン02420 Jorvasフィンランド
EMail: Pekka.Nikander@nomadiclab.com
メールアドレス：Pekka.Nikander@nomadiclab.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。