Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6496 Ericsson
Category: Experimental J. Laganier
ISSN: 2070-1721 Juniper Networks
M. Bonola
Rome Tor Vergata University
A. Garcia-Martinez
UC3M
February 2012
Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)
Abstract
抽象
SEcure Neighbor Discovery (SEND) specifies a method for securing Neighbor Discovery (ND) signaling against specific threats. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND. This document extends the current SEND specification in order to secure Proxy ND operation.
セキュア近隣探索（SEND）は、特定の脅威からシグナリング近隣探索（ND）を固定するための方法を指定します。今日定義されているように、SENDには、それは民間の所有であるように、NDメッセージを送信するノードは、メッセージを送信および/またはルータとして動作するノードを認証鍵を所有しているから、アドレスの所有者であることを前提としてい各メッセージのデジタル署名を生成するために使用されるキーまたはキー。これは、アドレスの所有者の秘密鍵および/またはルータのキーの知識の知識を持たないノードによって実行されるプロキシNDシグナリングがSENDを使用して確保することができないことを意味します。この文書では、プロキシNDの動作を確保するために、現在のSEND仕様を拡張します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6496.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6496で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
3. Terminology .....................................................3
4. Secure Proxy ND Overview ........................................4
5. Secure Proxy ND Specification ...................................5
5.1. Proxy Signature Option .....................................6
5.2. Modified SEND Processing Rules .............................8
5.2.1. Processing Rules for Senders ........................8
5.2.2. Processing Rules for Receivers ......................9
5.3. Proxying Link-Local Addresses .............................11
6. Application Scenarios ..........................................11
6.1. Scenario 1: Mobile IPv6 ...................................11
6.2. Scenario 2: Proxy Mobile IPv6 .............................13
6.3. Scenario 3: RFC 4389 Neighbor Discovery Proxy .............16
7. Backward Compatibility with RFC 3971 Nodes and Non-SEND Nodes ..17
7.1. Backward Compatibility with RFC 3971 Nodes ................17
7.2. Backward Compatibility with Non-SEND Nodes ................18
8. Security Considerations ........................................20
9. IANA Considerations ............................................22
10. Acknowledgements ..............................................22
11. References ....................................................22
11.1. Normative References .....................................22
11.2. Informative References ...................................23
SEcure Neighbor Discovery (SEND) [RFC3971] specifies a method for securing Neighbor Discovery (ND) signaling [RFC4861] against specific threats [RFC3756]. As defined today, SEND assumes that the node sending an ND message is the owner of the address from which the message is sent and/or possesses a key that authorizes the node to act as a router, so that it is in possession of the private key or keys used to generate the digital signature on each message. This means that the Proxy ND signaling performed by nodes that do not possess knowledge of the address owner's private key and/or knowledge of a router's key cannot be secured using SEND.
セキュア近隣探索（SEND）[RFC3971]は、特定の脅威[RFC3756]に対して[RFC4861]をシグナリング近隣探索（ND）を固定するための方法を指定します。今日定義されているように、SENDには、それは民間の所有であるように、NDメッセージを送信するノードは、メッセージを送信および/またはルータとして動作するノードを認証鍵を所有しているから、アドレスの所有者であることを前提としてい各メッセージのデジタル署名を生成するために使用されるキーまたはキー。これは、アドレスの所有者の秘密鍵および/またはルータのキーの知識の知識を持たないノードによって実行されるプロキシNDシグナリングがSENDを使用して確保することができないことを意味します。
This document extends the current SEND specification with support for Proxy ND. From this point on, we refer to such an extension as "Secure Proxy ND Support for SEND".
この文書では、プロキシのNDをサポートする現在のSEND仕様を拡張します。この時点から、私たちは「SENDのプロキシNDのサポートセキュア」などの拡張子を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Secure ND Proxy
セキュアNDプロキシ
A node acting on behalf of another node and authorized to secure a Neighbor Discovery Protocol (NDP) message without knowing the private key related to the source address of the other node or the key related to the router authorization.
ノードは他のノードの代わりに動作し、他のノードの送信元アドレスまたはルータの認証に関連したキーに関連した秘密鍵を知らなくても、近隣探索プロトコル（NDP）メッセージを確保するために承認しました。
Proxied IPv6 address
プロキシIPv6アドレス
An IPv6 address that does not belong to the Secure ND Proxy and for which the Secure ND Proxy is performing advertisements.
セキュアNDプロキシにし、セキュアNDプロキシは、広告を行っているために属していないIPv6アドレス。
Non-SEND node
非SENDノード
An IPv6 node that does not implement the SEND [RFC3971] specification but uses the ND protocol defined in [RFC4861] and [RFC4862], without additional security.
追加のセキュリティなしで、SEND [RFC3971]の仕様を実装するが、NDの[RFC4861]で定義されたプロトコルと[RFC4862]を使用しないIPv6ノード。
RFC 3971 node
RFC 3971ノード
An IPv6 node that does not implement the specification defined in this document for Secure Proxy ND support but uses the SEND specification as defined in [RFC3971].
[RFC3971]で定義されるようにセキュアプロキシNDをサポートするため、この文書で定義された仕様を実現するが、SEND仕様を使用しないIPv6ノード。
Secure Proxy ND (SPND) node
プロキシND（SPND）ノードを確保
An IPv6 node that receives and validates messages according to the specification defined in this document for Secure Proxy ND support.
セキュアプロキシNDをサポートするため、この文書で定義された仕様に従ってメッセージを受信し、検証IPv6ノード。
Translated NDP message
翻訳NDPメッセージ
An NDP message issued by a Secure ND Proxy as a result of a received NDP message originated by the owner of the address or originated by another node acting on behalf of the owner of the address.
受信されたNDPメッセージアドレスの所有者によって発信またはアドレスの所有者に代わって作用する別のノードによって発信の結果としてセキュアNDプロキシによって発行されたNDPメッセージ。
Synthetic NDP message
合成NDPメッセージ
An NDP message issued by a Secure ND Proxy that is not the result of a received NDP message.
受け取ったNDPメッセージの結果ではないセキュアNDプロキシによって発行されたNDPメッセージ。
The original SEND specification [RFC3971] has implicitly assumed that only the node sending an ND message is the owner of the address from which the message is sent. This assumption does not allow proxying of ND messages, since the advertiser is required to generate a valid RSA Signature option, which in turn requires possession of the public-private key pair that was used to generate a Cryptographically Generated Address (CGA), or that was associated to a router certificate.
オリジナルSEND仕様[RFC3971]は、暗黙的にNDメッセージを送信するノードのみがメッセージの送信元のアドレスの所有者であることを前提としています。この仮定は、広告主が順番に暗号化によって生成されたアドレス（CGA）を生成するために使用された公開鍵と秘密鍵のペアの所有を必要とする、有効なRSA署名オプションを、生成するために必要とされるため、NDメッセージのプロキシを許可、またはそのいませんルータの証明書に関連していました。
To be able to separate the roles of owner and advertiser, the following extensions to the SEND protocol are defined:
所有者と広告主の役割を分離することができるようにするには、SENDプロトコルに以下の拡張子が定義されています。
o A Secure Proxy ND certificate, which is a certificate authorizing an entity to act as an ND proxy. It is an X.509v3 certificate in which the purpose for which the certificate is issued has been specified explicitly, as described in a companion document [RFC6494]. Briefly, Secure Proxy ND certificates include one or more KeyPurposeId values that can be used for authorizing proxies to sign Router Advertisement (RA) and Redirect messages, or to sign Neighbor Advertisement (NA), Neighbor Solicitation (NS), or Router Solicitation (RS) messages on behalf of other nodes. The inclusion of this value allows the certificate owner to perform proxying of SEND messages for a range of addresses indicated in the same certificate. This certificate can be exchanged through the Authorization Delegation Discovery process defined in [RFC3971].
NDプロキシとして動作するエンティティを認証証明書であるセキュアプロキシND証明書、O。それは仲間ドキュメント[RFC6494]で説明したように、証明書が発行された目的は、明示的に指定されたX.509v3証明書です。簡単に言えば、セキュアプロキシND証明書は、ルータ広告（RA）に署名し、メッセージをリダイレクトし、あるいは近隣広告（NA）、近隣要請（NS）、またはルーター要請に署名するためにプロキシを承認するために使用することができる1つ以上のKeyPurposeId値（RSが含ま他のノードの代わりに）のメッセージ。この値の包含は、証明書所有者が同一の証明書に示されたアドレスの範囲に対してSENDメッセージのプロキシを実行することを可能にします。この証明書は、[RFC3971]で定義された権限委譲発見プロセスを介して交換することができます。
o A new Neighbor Discovery option called the Proxy Signature (PS) option. This option contains the hash value of the public key of the proxy, and the digital signature of the SEND message computed with the private key of the proxy. The hash of the public key of the proxy is computed over the public key contained in the Secure
O新しい近隣探索オプションは、プロキシ署名（PS）オプションと呼ばれます。このオプションは、プロキシの公開鍵のハッシュ値、およびプロキシの秘密鍵で計算SENDメッセージのデジタル署名が含まれています。プロキシの公開鍵のハッシュをセキュアに含まれる公開鍵にわたって計算されます
Proxy ND certificate. When an ND message contains a PS option, it MUST NOT contain CGA or RSA Signature options. The PS option MUST be appended to any NDP message (NA, NS, RS, RA, and Redirect) to secure it.
プロキシND証明書。 NDメッセージはPSオプションが含まれている場合は、CGAまたはRSA署名オプションを含めることはできません。 PSオプションは、それを確保するために、任意のNDPメッセージ（NA、NS、RS、RA、およびリダイレクト）に追加されなければなりません。
o A modification of the SEND processing rules for all ND messages: NA, NS, RS, RA, and Redirect. When any of these messages containing a PS option is validated, it is considered secure.
OすべてのNDメッセージのSEND処理ルールの変更：NA、NS、RS、RA、およびリダイレクト。 PSオプションを含むこれらのメッセージのいずれかが検証されると、それは安全であると考えられ。
These extensions are applied in the following way:
これらの拡張機能は、次のように適用されます。
o A Secure ND Proxy that proxies ND messages on behalf of a node can use the PS option to protect the proxied messages. This Secure ND Proxy becomes part of the trusted infrastructure just like a SEND router.
oをノードの代わりにNDメッセージをプロキシセキュアNDプロキシはプロキシされたメッセージを保護するためにPSオプションを使用することができます。このセキュアNDプロキシはちょうどSENDルータのような、信頼できるインフラの一部となります。
o The messages to be secured with the PS option are built according to [RFC4861] if they are synthesized by the Secure ND Proxy, or they result from the processing rules defined in [RFC4389] if they are translated ND messages.
それらはセキュアNDプロキシによって合成され、またはそれらがNDメッセージを翻訳している場合、彼らは[RFC4389]で定義された処理規則に起因する場合PSオプションで確保するメッセージO [RFC4861]に従って構築されています。
o In order to allow nodes to successfully validate secured proxied messages, the nodes MUST be aware of the Secure Proxy ND certificate (in the format described in [RFC6494]) and MUST apply the modified processing rules specified in this document. We call these nodes 'SPND nodes'. Note that the rules for generating ND messages in SPND nodes do not change, so these nodes behave as defined in [RFC3971] when they send ND messages.
Oノードが正常に確保プロキシメッセージを検証することを可能にするために、ノードは、（[RFC6494]に記載された形式で）セキュアプロキシND証明書を認識する必要があり、この文書で指定された修飾された処理ルールを適用しなければなりません。我々は、これらのノードのSPNDノード」と呼びます。 SPNDノードでNDメッセージを生成するためのルールが変更されないことに注意してくださいので、彼らは、NDメッセージを送信するときに、[RFC3971]で定義されたように、これらのノードが動作します。
o To allow SPND nodes to know the certification path required to validate the public key of the proxy, devices responding to CPS (Certification Path Solicitation) messages with CPA (Certification Path Advertisement) messages as defined in Section 6 of the SEND specification [RFC3971] are extended to support the certificate format specified in [RFC6494], and are configured with the appropriate certification path.
SPNDノードがプロキシの公開鍵を検証するために必要な証明書パスを知ることができるようにするにはO、SEND仕様のセクション6で定義されるようにCPA（証明経路広告）メッセージ[RFC3971]を有するCPS（認証パス要請）メッセージに応答する装置[RFC6494]で指定された証明書のフォーマットをサポートするように拡張され、適切な証明書パスが設定されています。
A Secure ND Proxy performs all the operations described in the SEND specification [RFC3971] with the addition of new processing rules to ensure that the receiving node can identify an authorized proxy generating a translated or synthetic SEND message for a proxied address.
セキュアNDプロキシは、受信ノードがプロキシアドレスの変換または合成SENDメッセージを生成認可プロキシを識別できることを保証するために、新たな処理ルールを加えてSEND仕様[RFC3971]に記載されているすべての動作を実行します。
This is accomplished by signing the message with a private key of the authorized Secure ND Proxy. The signature of the Secure ND Proxy is included in a new option called the PS option. The signature is performed over all the Neighbor Discovery Protocol (NDP) options present in the message, and the PS option is appended as the last option in the message.
これは認可された安全NDプロキシの秘密鍵でメッセージに署名することによって達成されます。セキュアNDプロキシの署名が新しいオプションに含まれているPSオプションと呼ばれます。署名がメッセージに存在するすべての近隣探索プロトコル（NDP）オプションを介して実行され、PSオプションはメッセージの最後のオプションとして付加されます。
The Proxy Signature option allows signatures based on public keys to be attached to NDP messages. The format of the PS option is described in the following diagram:
代理人署名オプションは、公開鍵に基づく署名がNDPメッセージに添付することができます。 PSオプションの形式は以下の図で説明します。
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PS Option Layout
図1：PSオプションレイアウト
Type
タイプ
32
３２
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 [SHA1] hash of the public key used for constructing the signature. Its purpose is to associate the signature to a particular key known by the receiver. Such a key MUST be the same one within the corresponding Secure Proxy ND certificate.
署名を構築するために使用される公開鍵のSHA1 [SHA1]ハッシュの最上位（左端）128ビットを含む128ビットのフィールド。その目的は、受信機によって知られている特定のキーに署名を関連付けることです。そのようなキーは、対応するセキュアなプロキシND証明書内で同じでなければなりません。
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 [RFC3972] value for Secure Proxy ND, 0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804. (The tag value has been generated randomly by the editor of this specification.)
1.セキュアプロキシNDの128ビットCGAメッセージタイプタグ[RFC3972]の値は、0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804は、（タグ値は、本明細書の編集者によってランダムに生成されています。）
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メッセージヘッダ、ICMPチェックサムフィールドの後にオクテットから出発しまで継続、しかし、NDPオプションを含みません。
The signature value is computed with the RSASSA-PKCS1-v1_5 algorithm and SHA-1 hash, as defined in [RSA]. This field starts after the Key Hash field. The length of the Digital Signature field is determined by the ASN.1 BER coding of the PKCS#1 v1.5 signature.
[RSA]で定義されるように、署名値は、RSASSA-PKCS1-v1_5のアルゴリズムとSHA-1ハッシュを用いて計算されます。このフィールドは、キーハッシュフィールドの後に開始します。デジタル署名フィールドの長さは、PKCS＃1 V1.5署名のASN.1のBER符号化によって決定されます。
Padding
パディング
This variable-length field contains padding. The length of the padding field is determined by the length of the Proxy Signature option minus the length of the other fields.
この可変長フィールドにはパディングが含まれています。パディングフィールドの長さは、代理署名オプションマイナス他のフィールドの長さの長さによって決定されます。
This specification modifies the sender and receiver processing rules defined in the SEND specification [RFC3971].
この仕様は、SEND仕様[RFC3971]で定義される送信側と受信側の処理規則を変更します。
A Secure ND Proxy MUST NOT use a key to sign NDP message types that do not correspond to the authorization granted to the considered key. NA, NS, and RS messages MUST be signed with a key corresponding to a Secure Proxy ND certificate with a KeyPurposeId value [RFC6494] of id-kp-sendProxiedOwner, and the source addresses of the messages MUST be encompassed in the prefix associated to the certificate. RA and Redirect messages MUST be signed with a key corresponding to a Secure Proxy ND certificate with a KeyPurposeId value of id-kp-sendProxiedRouter. The prefix included in the RA message for on-link determination and/or stateless address autoconfiguration, and the Target Address of the Redirect message, MUST be encompassed in the prefix associated to that certificate.
セキュアNDプロキシが考慮されたキーに付与された認証に対応していないNDPメッセージの種類を署名するキーを使用してはなりません。 NA、NS、およびRSメッセージは、ID-KP-sendProxiedOwnerのKeyPurposeId値[RFC6494]とセキュアプロキシND証明書に対応する鍵で署名されている必要があり、そしてメッセージの送信元アドレスは、に関連する接頭辞に含まれなければなりません証明書。 RAとリダイレクトメッセージは、ID-KP-sendProxiedRouterのKeyPurposeId値を持つセキュアプロキシND証明書に対応するキーで署名されなければなりません。オンリンク判断及び/又はステートレスアドレス自動設定、およびリダイレクトメッセージのターゲットアドレスのRAメッセージに含まれるプレフィックスが、その証明書に関連付けられたプレフィクスに含まれなければなりません。
A secured NDP message sent by a Secure ND Proxy for a proxied address MUST contain a PS option and MUST NOT contain either CGA or RSA Signature options. Section 7 discusses in which cases an NDP message has to be secured in a scenario including non-SEND nodes.
プロキシアドレスにSecure NDプロキシによって送信されたセキュアなNDPメッセージはPSオプションを含まなければならないし、CGAまたはRSA署名オプションのいずれかを含めることはできません。セクションNDPメッセージは非SENDノードを含むシナリオに固定されなければならない場合には7論じています。
The input of this process is a message obtained in either of the following ways:
このプロセスの入力は、以下のいずれかの方法で取得したメッセージです。
a. If the Secure ND Proxy generates synthetic SEND messages for a proxied address, the message MUST be constructed as described in the Neighbor Discovery for IP version 6 specification [RFC4861].
A。セキュアNDプロキシはプロキシアドレスの合成SENDメッセージを生成する場合、IPバージョン6仕様[RFC4861]のために近隣探索に記載されているように、メッセージが構築されなければなりません。
b. If the Secure ND Proxy translates secured messages, first the authenticity of the intercepted message MUST be verified. If the intercepted message is a SEND message, it MUST be validated as specified in Section 5 of the SEND specification [RFC3971]. If the intercepted message contains a PS option, the authenticity of the message MUST be verified as detailed in Section 5.2.2 of this specification. After validation, the CGA, RSA, or PS options of the original message MUST be removed. Then, the message to be translated MUST be processed according to the ND Proxy specification [RFC4389]. In this way, it is determined whether
B。セキュアNDプロキシは、セキュアなメッセージを変換する場合は、傍受のメッセージの最初の信憑性を確認する必要があります。傍受メッセージを送るメッセージである場合SEND仕様[RFC3971]のセクション5で指定されるように、それが検証されなければなりません。傍受メッセージがPSオプションが含まれている場合は、この仕様書の5.2.2項で説明するように、メッセージの信憑性を確認する必要があります。検証後、元のメッセージのCGA、RSA、またはPSオプションが除去されなければなりません。その後、翻訳されるメッセージは、NDプロキシ仕様[RFC4389]に従って処理されなければなりません。このように、それがか否かが判断されます
the message received should be proxied or not; the proxy
interface status is updated if needed, the outgoing interface is
determined, the link-layer header and the link-layer address
within the payload are modified if required, etc.
A Secure ND Proxy then modifies the input message as follows:
次のようにセキュアNDプロキシは、入力メッセージを修正します。
1. Timestamp and Nonce options MUST be included according to the rules specified in SEND [RFC3971]. The value in the Timestamp option MUST be generated by the proxy. If the proxy is translating a message that includes a nonce, the Nonce value in the proxied message MUST be the same as in the intercepted message. If the proxy is synthesizing a solicitation message, the Nonce value MUST be generated by the proxy. If the proxy is synthesizing an advertisement message, the Nonce value MUST correspond to the solicitation message to which the proxy is responding.
1.タイムスタンプとノンスオプションはSEND [RFC3971]で指定された規則に従って含まなければなりません。タイムスタンプオプションの値は、プロキシによって生成されなければなりません。プロキシはノンスを含むメッセージを翻訳された場合、プロキシメッセージでノンス値が傍受メッセージと同じでなければなりません。プロキシが要請メッセージを合成している場合は、ノンス値は、プロキシによって生成されなければなりません。プロキシが広告メッセージを合成している場合は、ノンス値は、プロキシが応答された要請メッセージに対応しなければなりません。
2. The Proxy Signature option MUST be added as the last option in the message.
2.プロキシ署名オプションは、メッセージの最後のオプションとして追加する必要があります。
Any SEND message without a Proxy Signature option MUST be treated as specified in the SEND specification [RFC3971].
プロキシ署名オプションなしSENDメッセージは、送信仕様[RFC3971]で指定されるように処理されなければなりません。
A SEND message including a Proxy Signature option MUST be processed as specified below:
以下に指定されるように、プロキシ署名オプションを含むSENDメッセージが処理されなければなりません。
1. The receiver MUST ignore any RSA and CGA options, as well as any options that might come after the first PS option. The options are ignored for both signature verification and NDP processing purposes.
1.受信機は、任意のRSAとCGAオプションだけでなく、最初のPSオプションの後に来るかもしれない任意のオプションを無視しなければなりません。オプションは、署名検証およびNDP処理の両方の目的のために無視されます。
2. The Key Hash field MUST indicate the use of a known public key. A valid certification path (see [RFC6494] Section 9) between the receiver's trust anchor and the sender's public key MUST be known. The Secure Proxy ND X.509v3 certificate MUST contain an extended key usage extension including the appropriate KeyPurposeId value and prefix for the message to validate:
2.キーハッシュフィールドが知られている公開鍵を使用することを示す必要があります。受信者のトラストアンカーと、送信者の公開鍵を知らなければならないとの有効な証明書パス（[RFC6494]のセクション9を参照してください）。セキュアプロキシND X.509v3証明書は、メッセージを検証するための適切なKeyPurposeId値とプレフィックスを含む拡張鍵使用拡張を含まなければなりません。
* For RA messages, a KeyPurposeId value of
id-kp-sendProxiedRouter MUST exist for the certificate, and
the prefix included in the RA message for on-link
determination and/or stateless address autoconfiguration MUST
be encompassed in the prefix associated to that certificate.
* For Redirect messages, a KeyPurposeId value of id-kp-sendProxiedRouter MUST exist for the certificate, and the prefix included in the Target Address of the Redirect message MUST be encompassed in the prefix associated to that certificate.
*リダイレクトメッセージの場合、ID-KP-sendProxiedRouterのKeyPurposeId値は、証明書のために存在し、リダイレクトメッセージのターゲットアドレスに含まれるプレフィックスは、その証明書に関連付けられたプレフィクスに含まれなければなりません。
* For NA, NS, and RS messages, a KeyPurposeId value of id-kp-sendProxiedOwner MUST exist for the certificate, and the source addresses of the messages MUST be encompassed in the prefix associated to the certificate.
* NA、NS、およびRSメッセージについて、ID-KP-sendProxiedOwnerのKeyPurposeId値は、証明書のために存在しなければなりません、そしてメッセージの送信元アドレスは、証明書に関連付けられたプレフィクスに含まれなければなりません。
If any of these tests fail, the verification fails.
これらのテストのいずれかが失敗した場合、検証は失敗します。
3. The Digital Signature field MUST have correct encoding; otherwise, the verification of the message including the PS option fails.
3.デジタル署名フィールドが正しい符号化が必要です。そうでない場合は、PSオプションを含むメッセージの検証が失敗しました。
4. The Digital Signature verification MUST show that the signature has been calculated as specified in Section 5.1; otherwise, the verification of the message including the PS option fails.
4.デジタル署名の検証は、セクション5.1で指定されるように署名が計算されていることを示さなければなりません。そうでない場合は、PSオプションを含むメッセージの検証が失敗しました。
5. The Nonce option MUST be processed as specified in [RFC3971] Section 5.3.4, except for replacing 'RSA Signature option' with 'PS option'; if these tests fail, the verification of the message including the PS option fails.
[RFC3971]セクション5.3.4で指定されるように前記ノンスオプションは、「PSオプション」と「RSA署名オプション」を置き換える以外は、処理しなければなりません。これらのテストが失敗した場合、PSオプションを含むメッセージの検証が失敗しました。
6. The Timestamp option MUST be processed as specified in [RFC3971] Section 5.3.4, except for replacing 'RSA Signature option' with 'PS option'. If these tests fail, the verification of the message including the PS option fails. The receiver SHOULD store the peer-related timing information specified in [RFC3971] Sections 5.3.4.1 and 5.3.4.2 (RDlast, TSlast) separately for each different proxy (which could be identified by the different Key Hash values of the proxied message) and separately from the timing information associated to the IP address of a node for which the message is proxied. In this way, a message received for the first time from a proxy (i.e., for which there is no information stored in the cache) for which the Timestamp option is checked SHOULD be checked as a message received from a new peer (as in [RFC3971] Section 5.3.4.2).
[RFC3971]セクション5.3.4で指定されるように前記タイムスタンプ・オプションは、「PSオプション」と「RSA署名オプション」を置き換える以外は、処理しなければなりません。これらのテストが失敗した場合、PSオプションを含むメッセージの検証が失敗しました。受信機は、（プロキシメッセージの異なるキーハッシュ値によって識別することができる）各異なるプロキシの別々[RFC3971]セクション5.3.4.1および5.3.4.2（RDlast、TSlast）で指定されたピアに関連するタイミング情報を格納しなければならず、別々のメッセージがプロキシされているノードのIPアドレスに関連付けられたタイミング情報から。このように、タイムスタンプオプションがチェックされているプロキシ（すなわち、キャッシュに格納された情報がないいる）から最初に受信したメッセージが（[のように新しいピアから受信したメッセージのようにチェックすべきですRFC3971]のセクション5.3.4.2）。
7. Messages with the Override bit [RFC4861] set MUST override an existing cache entry regardless of whether it was created as a result of an RSA Signature option or a PS option validation. When the Override bit is not set, the advertisement MUST NOT update a cached link-layer address created securely by means of RSA Signature option or PS option validation.
オーバーライドビット[RFC4861]セット7.メッセージは関係なく、それはRSA署名オプションまたはPSオプションの検証の結果として作成されたかどうかの既存のキャッシュエントリを上書きしなければなりません。オーバーライドビットが設定されていない場合、広告は、RSA署名オプションまたはPSオプションの検証によって安全に作成され、キャッシュされたリンク層アドレスをアップデートしてはいけません。
Messages for which the verification fails MUST be silently discarded if the node 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.
ノードが唯一の確保NDメッセージを受け入れるように設定されている場合は、検証が失敗したためメッセージは静かに捨てなければなりません。ホストは、両方の固定および保護されていないメッセージを受け入れるように構成されているが、セキュリティで保護されていないメッセージとして処理しなければならない場合にメッセージを受け付けるようにしてもよいです。
SEND [RFC3971] relies on certificates to prove that routers are authorized to announce a certain prefix. However, Neighbor Discovery [RFC4861] states that routers do not announce the link-local prefix (fe80::/64). Hence, it is not required for a SEND certificate to hold an X.509 extension for IP addresses that authorizes the fe80::/64 prefix. However, some Secure Proxy ND scenarios ([RFC4389], [RFC5213]) impose providing the proxying function for the link-local address of a node. When Secure ND Proxy functionality for a link-local address is required, either a list of link-local addresses, or the fe80::/64 prefix MUST be explicitly authorized to be proxied in the corresponding certificate.
[RFC3971]は、ルータが特定の接頭辞を発表することを許可されていることを証明する証明書に依存して送信してください。しかし、近隣探索[RFC4861]はルータがリンクローカルプレフィックス（FE80 :: / 64）を発表していないと述べています。したがって、FE80 :: / 64のプレフィックスを許可するIPアドレスのためのX.509拡張を保持するためにSEND証明書は必要ありません。しかし、いくつかのセキュアプロキシNDシナリオ（[RFC4389]、[RFC5213]）は、ノードのリンクローカルアドレスのプロキシ機能を提供課します。リンクローカルアドレスのためのセキュアNDプロキシ機能が必要な場合は、リンクローカルアドレスのリスト、またはFE80 :: / 64のプレフィックスのいずれかを明示的に対応する証明書にプロキシすることが許可されなければなりません。
In this section, we describe three different application scenarios for which Secure Proxy ND support for SEND can be applied. Note that the particular way in which Secure Proxy ND support is applied (which ND messages are proxied, in which direction, how the interaction with non-SEND hosts and RFC 3971 hosts is handled, etc.) largely depends on the particular scenario considered. In the first two scenarios presented below, ND messages are synthesized on behalf of off-link nodes. In the third one, ND messages are translated from the messages received in other interfaces of the proxy.
このセクションでは、SENDのためのセキュアプロキシNDのサポートを適用することができるための3つの異なるアプリケーションのシナリオについて説明します。なお、セキュアプロキシNDサポートが適用される特定の方法（NDメッセージがプロキシされ、どの方向にどのようにとの相互作用の非SENDホストとRFC 3971台のホストなど、処理される）を大きく考え特定のシナリオに依存します。以下に示す最初の2つのシナリオでは、NDメッセージは、オフリンクノードに代わって合成されます。第三のいずれかで、NDメッセージがプロキシの他のインタフェースで受信したメッセージから翻訳されます。
The description of the problems for deploying SEND in this scenario is presented in [RFC5909].
このシナリオではSEND展開するための問題の説明は、[RFC5909]に提示されています。
The Mobile IPv6 (MIPv6) protocol [RFC6275] allows a Mobile Node (MN) to move from one link to another while maintaining reachability at a stable address, the so-called MN's Home Address (HoA). When an MN attaches to a foreign network, all the packets sent to the MN's HoA by a Correspondent Node (CN) on the home link or a router are intercepted by the Home Agent (HA) on that home link, encapsulated, and tunneled to the MN's registered Care-of Address (CoA).
モバイルIPv6（MIPv6の）プロトコル[RFC6275]は安定したアドレス、いわゆるMNのホームアドレス（HoA）で到達可能性を維持しながら、モバイルノード（MN）が別のリンクから移動することができます。 MNが外部ネットワークに接続する場合は、ホームリンクまたはルータ上で相手ノード（CN）によってMNのHoAに送信されたすべてのパケットは、そのホームリンク上のホームエージェント（HA）によってインターセプトカプセル化、およびにトンネリングされていますMNの登録気付アドレス（CoA）。
To deploy Secure Proxy ND in this scenario, i.e., to secure the HA operation, a Secure Proxy ND certificate with a KeyPurposeId value of id-kp-sendProxiedOwner for the prefix of the home link is required.
このシナリオでのセキュアなプロキシNDを展開するために、即ち、HA動作を確保するために、ホームリンクのプレフィックスのID-KP-sendProxiedOwnerのKeyPurposeId値セキュアプロキシND証明書が必要です。
The Secure ND Proxy is configured with the private key associated to this certificate. When a NS is intercepted by the HA on the home link, the HA checks whether the Target Address within the NS matches with any of the MN's Home Addresses in the binding cache, and if so, it replies with a Neighbor Advertisement (NA) constructed as described in [RFC4861], containing its own link-layer address (HA_LL) as the Target Link-Layer Address Option (TLLAO). Then, a timestamp (generated by the proxy) and nonce (if appropriate, according to [RFC3971]) MUST be included. Finally, a PS option signing the message MUST be included as the last option of the message.
セキュアNDプロキシは、この証明書に関連する秘密鍵で構成されています。 NSは、ホームリンク上のHAによって傍受された場合、HAは、NS内のターゲットアドレスがバインディングキャッシュにMNのホームアドレスのいずれかと一致するかどうかをチェックし、もしそうなら、それは構築近隣広告（NA）で応答しますターゲットリンク層アドレスオプション（TLLAO）として、独自のリンク層アドレス（HA_LL）を含む、[RFC4861]で説明。 （プロキシによって生成された）タイムスタンプとノンス（適切であれば、[RFC3971]に記載）を含まなければなりません。最後に、メッセージに署名PSオプションは、メッセージの最後のオプションとして含まれなければなりません。
Node (N) Home Agent (HA) Mobile Node (MN)
on Home Link on Home Link on Foreign Link
| | |
| SRC = N | |
| DST = solicited_node (MN) | |
| ICMPv6 NS | |
| TARGET = MN | |
| SLLAO = N_LL | |
| [CGA] | |
| RSA signature | |
|-------------------------->| |
| | |
| SRC = HA | |
| DST = N | |
| ICMPv6 NA | |
| TARGET = MN | |
| TLLAO = HA_LL | |
| PS signature | |
|<--------------------------| |
| | |
| traffic | |
| dest = MN HoA | |
|-------------------------->| |
| | |
| | tunneled traffic |
| | dest = MN CoA |
| |------------------------->|
| | |
Figure 2: Proxy ND Role of the Home Agent in MIPv6
図2：MIPv6のホームエージェントのプロキシND役割
A node receiving the NA containing the PS option (e.g., the CN in the home link, or a router) MUST apply the rules defined in Section 5.2.2. Note that in this case the Override bit of the NA message is used to control which messages should prevail on each case: the message generated by the proxy when the MN moves from the home network, or the MN if it comes back to the home link, as defined in the MIPv6 specification [RFC6275].
PSオプションを含むNAを受信したノード（例えば、ホームリンクにおけるCN、またはルータ）は、セクション5.2.2で定義されたルールを適用しなければなりません。この場合にはNAメッセージのオーバーライドビットは、それぞれの場合に優先すべきメッセージを制御するために使用されることに注意してください：MNは、ホームネットワークから移動したときに、プロキシによって生成されたメッセージ、またはMNそれがバックホームリンクに来る場合、MIPv6の仕様[RFC6275]で定義されます。
Proxy Mobile IPv6 [RFC5213] is a network-based mobility management protocol that provides IP mobility management support for MNs without requiring that MNs be involved in the mobility-related signaling. The IP mobility management is totally hidden to the MN in a Proxy Mobile IPv6 domain, and it is performed by two functional entities: the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG).
プロキシモバイルIPv6 [RFC5213]はのMNは、モビリティ関連のシグナリングに関与することを必要とすることなく、MNのためのIPモビリティ管理のサポートを提供するネットワーク・ベースのモビリティ管理プロトコルです。 IPモビリティ管理は、プロキシモバイルIPv6ドメインのMNに完全に隠されている、そしてそれは、二つの機能エンティティによって実行されます。ローカルモビリティアンカー（LMA）とモバイルアクセスゲートウェイ（MAG）。
When the MN connects to a new access link, it sends a multicast Router Solicitation (RS). The MAG on the new access link, upon detecting the MN's attachment, signals the LMA requesting an update of the binding state of the MN (by means of a Proxy Binding Update (PBU)). Once the signaling is completed (it receives a Proxy Binding Ack (PBA)), the MAG replies to the MN with a Router Advertisement (RA) containing the home network prefix(es) that were assigned to that mobility session, making the MN believe it is still on the same link, so the IPv6 address reconfiguration procedure is not triggered (Figure 3).
MNは、新しいアクセスリンクに接続すると、マルチキャストルータ要請（RS）を送信します。新しいアクセスリンク上のMAGは、MNの付着を検出すると、（プロキシ・バインディング更新（PBU）によって）MNの結合状態の更新を要求LMAに信号を送ります。シグナリングが完了すると（それが受信プロキシバインディングACK（PBA））、MAGは、MNは信じて作り、その移動性セッションに割り当てられたホームネットワーク接頭語（es）を含む、ルータ広告（RA）とMNに返信しますそれは、同じリンク上にまだあるので、IPv6のアドレス再設定手順（図3）がトリガされません。
MN new MAG LMA
| | |
MN Attached | |
| | |
| MN Attached Event from MN/Network |
| | |
| SRC = MN | |
| DST = all routers | |
| ICMPv6 RS | |
| [CGA] | |
| RSA signature | |
|--------------------->| |
| | |
| |--- PBU ------------->|
| | |
| | Accept PBU
| | |
| |<------------- PBA ---|
| | |
| Accept PBA |
| | |
| |==== Bi-Dir Tunnel ===|
| | |
| SRC = MAG4MN | |
| DST = MN | |
| ICMPv6 RA | |
| SLL = MAG_LL | |
| PS | |
|<---------------------| |
| | |
| | |
| | |
Figure 3: Mobile Node's Handover in PMIPv6
図3：PMIPv6の中に移動ノードのハンドオーバ
To avoid potential link-local address collisions between the MAG and the MN after a handoff to a new link, the Proxy Mobile IPv6 specification [RFC5213] requires that the MAG's link-local address on the link to which the MN is attached be generated by the LMA when the MN first attaches to a PMIPv6 domain, and be provided to the new MN's serving MAG after each handoff. Thus, from the MN's point of view, the MAG's link-local address remains constant for the duration of that MN's session.
新しいリンクへのハンドオフ後MAGとMN間の潜在的なリンクローカルアドレスの衝突を避けるために、プロキシモバイルIPv6の仕様[RFC5213]はMNが接続されているリンク上のMAGのリンクローカルアドレスがによって生成されている必要がありますLMAは、MNときは、最初のPMIPv6ドメインに接続すると、各ハンドオフ後に新しいMNのサービス提供MAGに提供すること。したがって、ビューのMNの視点から、MAGのリンクローカルアドレスは、MNのセッションの期間中、一定のまま。
The approach described above and the current SEND specification are incompatible, since sharing the same link-local address on different MAGs would require all MAGs of a PMIPv6 domain to construct the CGA and the RSA Signature option with the same public-private key pair, which is not an acceptable security policy.
上述のアプローチと現在のSEND仕様は、異なるのMAGで同じリンクローカルアドレスを共有する同じ公開鍵と秘密鍵のペアとCGAとRSA署名オプションを構築するためにPMIPv6ドメインのすべてのMAGを必要とすることから、その互換性がありません許容可能なセキュリティポリシーではありません。
Using different public-private key pairs on different MAGs would mean that different MAGs use different CGAs as link-local addresses. Thus, the serving MAG's link-local address would change after each handoff of the MN, which is in contradiction with the way MAG link-local address assignment occurs in a PMIPv6 domain.
異なるのMAG上の異なる公開鍵と秘密鍵のペアを使用すると、異なるのMAGは、リンクローカルアドレスと異なるCGAsを使用することを意味します。このように、サービス提供MAGのリンクローカルアドレスは、リンクローカルアドレスの割り当ては、PMIPv6ドメインで発生方法のMAGと矛盾しているMN、それぞれのハンドオフ後に変更します。
To provide SEND protection, each MAG MUST be configured to act as a proxy by means of a certificate associated to the PMIPv6 domain, authorizing each MAG to securely proxy NA and RS messages by means of a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the certificate MUST also authorize the MAG to advertise prefixes by associating to the same certificate a KeyPurposeId value of id-kp-sendProxiedRouter. Note that the inclusion of multiple KeyPurposeId values is supported by [RFC6494].
SEND保護を提供するために、各MAGは、ID-KP-sendProxiedOwnerのKeyPurposeId値により確実プロキシNAおよびRSメッセージに各MAGを認可、PMIPv6ドメインに関連付けられた証明書によってプロキシとして動作するように構成されなければなりません。また、証明書は、同じ証明書ID-KP-sendProxiedRouterのKeyPurposeId値を関連付けることによってプレフィックスを広告するMAGを承認しなければなりません。複数KeyPurposeId値の包含は[RFC6494]でサポートされていることに注意してください。
When a MAG replies to an RS with an RA, the source address MUST be equal to the MAG link-local address associated to the MN in this PMIPv6 domain, with its own link-layer address as the source link-layer address. Then, a timestamp (generated by the proxy) and nonce (if appropriate, according to [RFC3971]) MUST be included. Finally, a PS option signing the message MUST be included as the last option of the message. This procedure is followed for any other ND message that could be generated by the MAG to the MN.
MAGはRAとRSに応答する場合、送信元アドレスは、ソースリンク層アドレスのような、独自のリンク層アドレスと、このPMIPv6ドメイン内のMNに関連するMAGのリンクローカルアドレスに等しくなければなりません。 （プロキシによって生成された）タイムスタンプとノンス（適切であれば、[RFC3971]に記載）を含まなければなりません。最後に、メッセージに署名PSオプションは、メッセージの最後のオプションとして含まれなければなりません。この手順は、MNとMAGによって生成することができる任意の他のNDメッセージを追跡します。
A node receiving a message from the MAG containing the PS option MUST apply the processing rules defined in Section 5.2.2. Note that unsolicited messages sent by the MAG should be validated by the host according to timestamp values specific to the MAG serving the link, not to any other MAG to which the host has been connected before in other links, according to processing step number 6 of Section 5.2.2.
PSオプションを含むMAGからのメッセージを受信したノードは、セクション5.2.2で定義された処理ルールを適用しなければなりません。 MAGによって送信された迷惑メッセージは処理ステップ番号6によれば、どのホストが他のリンクに前に接続されたへのリンクをサービングMAGへ、ない任意の他のMAGに特異的なタイムスタンプの値に応じてホストによって検証されるべきであることに注意してください5.2.2。
The problems for deploying SEND in this scenario are presented in [RFC5909].
このシナリオでは、SEND展開するための課題は、[RFC5909]に提示されています。
Link 1 Link 2
リンク1つのリンク2
Host A ND Proxy (P) Host B
| | |
| SRC = A | |
| DST = solicited_node (B) | |
| ICMPv6 NS | |
| TARGET = B | |
| SLLAO = A_LL | |
|------------------------->| |
| | SRC = A |
| | DST = solicited_node (B) |
| | ICMPv6 NS |
| | TARGET = B |
| | SLLAO = P_LL |
| |------------------------->|
| | |
| | SRC = B |
| | DST = A |
| | ICMPv6 NA |
| | TARGET = B |
| | TLLAO = B_LL |
| |<-------------------------|
| SRC = B | |
| DST = A | |
| ICMPv6 NA | |
| TARGET = B | |
| TLLAO = P_LL | |
|<-------------------------| |
| | |
Figure 4: RFC 4389 Neighbor Discovery Proxy Operation
図4：RFC 4389近隣探索プロキシの操作
The Neighbor Discovery (ND) Proxy specification [RFC4389] provides a method by which multiple link-layer segments are bridged into a single segment and specifies the IP-layer support that enables bridging under these circumstances.
近隣探索（ND）プロキシ仕様[RFC4389]は、複数のリンク層セグメントが単一のセグメントにブリッジされる方法を提供し、このような状況下で架橋可能IPレイヤのサポートを指定します。
A Secure ND Proxy MUST parse any IPv6 packet it receives on a proxy interface to check whether it contains one of the following NDP messages: NS, NA, RS, RA, or Redirect. The Secure ND Proxy MUST verify the authenticity of the received ND message, according to [RFC3971], or according to Section 5.2.2 if it contains a PS option.
NS、NA、RS、RA、またはリダイレクト：セキュアNDプロキシは、それが以下のNDPメッセージのいずれかが含まれているかどうかを確認するために、プロキシインターフェイス上で受信したすべてのIPv6パケットを解析する必要があります。セキュアNDプロキシは、[RFC3971]によれば、受信したNDメッセージの真正性を検証する、またはそれがPSオプションが含まれている場合は、セクション5.2.2に記載しなければなりません。
Then, after removing the CGA, RSA, or PS options, the message to be translated MUST be processed according to the ND Proxy specification [RFC4389]. This includes performing loop prevention checks, determining the outgoing interface for the proxied message, changing the source link-layer address to the address of the outgoing interface, changing source link-layer addresses contained in the payload (that is, in a Source Link-Layer Address Option (SLLAO) or a Target Link-Layer Address Option (TLLAO)), maintaining the destination link-layer address as the address in the neighbor entry corresponding to the destination IPv6 address, setting the P bit for proxied RA messages, etc. Note that besides link-layer addresses and the P bit of a RA, no other field of the received message is changed when proxied by an [RFC4389] proxy.
次いで、CGA、RSA、またはPSオプションを除去した後、翻訳されるメッセージは、NDプロキシ仕様[RFC4389]に従って処理されなければなりません。これは、ソースリンク - に（すなわち、ペイロードに含まれるソースリンク層アドレスを変更する、発信インターフェイスのアドレスへのソースリンク層アドレスを変更する、プロキシメッセージの発信インターフェイスを決定する、ループ防止チェックを実行することを含みます層アドレス・オプション（SLLAO）またはターゲットリンク層アドレス・オプション（TLLAO））など、プロキシRAメッセージのためのPビットをセットし、宛先IPv6アドレスに対応するネイバーエントリ内のアドレスとして送信先リンク層アドレスを維持[RFC4389]プロキシによってプロキシ場合リンク層アドレス及びRAのPビットの他に、受信したメッセージの他のフィールドが変更されないことに留意されたいです。
When any other IPv6 unicast packet is received on a proxy interface, if it is not locally destined, then it is forwarded unchanged (other than using a new link-layer header) to the proxy interface for which the next-hop address appears in the neighbor cache. If no neighbor cache entry is present, the Secure ND Proxy SHOULD queue the packet and initiate a Neighbor Discovery signaling as if the NS message were locally generated.
他のIPv6ユニキャストパケットがプロキシインタフェース上で受信されたとき、それがローカルに宛てていない場合、それは、次ホップアドレスはに表示されるプロキシインターフェイスに（新しいリンク層ヘッダを使用するよりも他の）不変転送されます近隣キャッシュ。何の近隣キャッシュエントリが存在しない場合は、セキュアNDプロキシは、パケットをキューイングし、NSメッセージがローカルで生成されたかのように、シグナリング近隣探索を開始すべきです。
Note that to be able to sign any NS, NA, RS, RA, or Redirect message, the key used MUST correspond to a certificate with KeyPurposeId values of id-kp-sendProxiedOwner and id-kp-sendProxiedRouter.
すなわち、RAを任意NS、NA、RSの署名、またはメッセージをリダイレクトできるようにするには、使用されるキーは、ID-KP-sendProxiedOwnerのKeyPurposeId値及びID-KP-sendProxiedRouter付き証明書に対応しなければなりません。
In order to deploy this scenario, nodes in proxied segments MUST know the certificate-authorizing proxy operation. To do so, it could be required that at least one device per proxied segment (maybe the proxy itself) be configured to propagate the required certification path to authorize proxy operation by means of a CPS/CPA exchange.
このシナリオを展開するために、プロキシセグメント内のノードは、証明書承認のプロキシ動作を知っていなければなりません。そうするためには、プロキシセグメント（多分プロキシ自体）ごとに少なくとも1つの装置がCPS / CPA交換によってプロキシ動作を許可するために必要な証明書パスを伝播するように構成されていることが要求される可能性があります。
In this section, we discuss the interaction of Secure ND Proxies and SPND nodes with RFC 3971 nodes and non-SEND nodes. As stated in [RFC3971], network operators may want to run a mixture of nodes accepting secured and unsecured NDP messages at the same time. Secure ND Proxies and SPND nodes SHOULD support the use of secured and unsecured NDP messages at the same time.
このセクションでは、RFC 3971のノードと非SENDノードとセキュアNDプロキシとSPNDノードの相互作用を議論します。 [RFC3971]に記載されているように、ネットワークオペレータは、同時に固定および無担保NDPメッセージを受け付けるノードの混合を実行することができます。 NDプロキシを確保し、SPNDノードが同時に確保し、無担保NDPメッセージの使用をサポートする必要があります。
RFC 3971 nodes, i.e., SEND nodes not compliant with the modifications required in Section 5, cannot correctly interpret a PS option received in a proxied ND message. These SEND nodes silently discard the PS option, as specified in [RFC4861] for any unknown option. As
RFC 3971個のノード、すなわち、正しくプロキシNDメッセージで受信したPSオプションを解釈できない、セクション5で必要な変更に対応していないノードを送ります。これらは、いずれかの未知のオプションのために[RFC4861]で指定されたノードは静かに、PSオプションを破棄送信します。なので
a result, these messages will be treated as unsecured, as described in Section 8 ("Transitions Issues") of the SEND specification [RFC3971].
SEND仕様[RFC3971]のセクション8（「遷移の問題」）に記載されているように、結果は、これらのメッセージは、セキュリティで保護されていないとして扱われます。
When RFC 3971 nodes and SPND nodes exchange ND messages (without proxy intervention), in either direction, messages are generated according to the SEND specification [RFC3971], so these nodes interoperate seamlessly.
RFC 3971ノードとSPNDノードが（プロキシの介入なし）NDメッセージを交換するとき、いずれかの方向に、メッセージは、送信仕様[RFC3971]に従って生成されるので、これらのノードはシームレスに相互運用します。
In the scenarios in which the proxy translates ND messages, the messages to translate can either be originated in an RFC 3971 node or in an SPND node, without interoperability issues (note that the difference between RFC 3971 nodes and SPND nodes only affects the ability to process received NDP messages containing a PS option, not the way they generate messages secured by SEND).
プロキシがNDメッセージを変換するシナリオでは、翻訳するメッセージは、相互運用性の問題なしに、RFC 3971ノードまたはSPNDノードに由来することができるいずれかの（RFC 3971のノードとSPNDノード間の差のみに能力に影響することに注意してくださいプロセスは、PSオプション、彼らはSENDで固定メッセージを生成しない方法）を含むNDPメッセージを受け取りました。
A configuration option MAY exist in a Secure ND Proxy to specify the RFC 3971 nodes to which it is connected, so that the proxied messages sent to these nodes are not processed according to the Secure Proxy ND specification, for performance reasons.
設定オプションは、これらのノードに送信されたプロキシ・メッセージは、パフォーマンス上の理由から、セキュアプロキシND仕様に従って処理されないように、それが接続されているRFC 3971のノードを指定するセキュアNDプロキシで存在してもよいです。
Non-SEND nodes receiving NDP packets silently discard PS options, as specified in [RFC4861] for any unknown option. Therefore, these nodes interpret messages proxied by a Secure ND Proxy as any other ND message.
未知のオプションに[RFC4861]で指定されるようにNDPパケットを受信し、非SENDノードはサイレント、PSオプションを捨てます。したがって、これらのノードは、他のNDメッセージとしてセキュアNDプロキシによってプロキシメッセージを解釈します。
When non-SEND nodes and SPND nodes exchange ND messages (without proxy intervention), in either direction, the rules specified in Section 8 of [RFC3971] apply.
非SENDノードとSPNDノードが（プロキシの介入なし）NDメッセージを交換するとき、いずれかの方向に、ルールは、[RFC3971]のセクション8で指定された適用されます。
A Secure ND Proxy SHOULD support the use of secured and unsecured NDP messages at the same time, although it MAY have a configuration that causes proxying to not be performed for unsecured NDP messages. A Secure ND Proxy MAY also have a configuration option whereby it disables secure ND proxying completely. This configuration SHOULD be switched off by default; that is, security is provided by default. In the following paragraphs, we discuss the recommended behavior of the Secure ND Proxy regarding the protection level to provide to proxied messages in a mixed scenario involving SPND/RFC 3971 nodes and non-SEND nodes. In particular, two different situations occur, depending on whether the proxied nodes are RFC 3971 or SPND nodes, or non-SEND nodes.
それは無担保NDPメッセージに対して実行されないようにプロキシが発生した構成を有していてもよいがセキュアNDプロキシは、同時に確保し、無担保NDPメッセージの使用をサポートする必要があります。それは完全に安全NDプロキシを無効にすることにより、セキュアNDプロキシも設定オプションがあるかもしれません。この設定はデフォルトではオフにすべきです。つまり、セキュリティがデフォルトで提供されています。次の段落では、我々はSPND / RFC 3971個のノードと非SENDのノードを含む混合シナリオでは、プロキシのメッセージを提供するために、保護レベルに関するセキュアNDプロキシの推奨行動を議論します。具体的には、2つの異なる状況がプロキシノードがRFC 3971またはSPNDノード、または非SENDノードであるかどうかに応じて、発生します。
As a rule of thumb, if the proxied nodes can return to the link in which the proxy operates, the Secure ND Proxy MUST only generate PS options on behalf of nodes with SEND capabilities (i.e., those nodes that could use SEND to defend their messages if present on the same link as the proxy -- in other words, either RFC 3971 nodes or SPND nodes). This is relevant to allow nodes to prefer secured information over an unsecured one, and to properly execute the Duplicate Address Detection (DAD) procedure, as specified in [RFC3971]. Therefore, in this case, the Secure ND Proxy MUST synthesize/translate messages containing the PS option for SPND and RFC 3971 hosts, and MUST NOT synthesize/translate messages containing the PS option for non-SEND nodes. Note that ND advertisements in response to solicitations generated by a Secure ND Proxy must either be secured or not secured, according to the previous considerations (i.e., according to the nature of the proxied node), and not according to the secure or unsecure nature of the solicitation message.
プロキシノードは、プロキシが動作するリンクに戻ることができた場合、親指のルールとして、セキュアNDプロキシはSEND機能を備えたノードの代わりにPSオプションを発生させなければなりません（自分のメッセージを守るためにSENDを使用することができ、すなわち、それらのノード換言すれば、RFC 3971のノードまたはSPNDノードのいずれか） - プロキシと同じリンク上に存在する場合。これは、ノードが保護されていない1つの上に保護された情報を好む、および[RFC3971]で指定されるように適切に、重複アドレス検出（DAD）手順を実行することを可能にするのに適切です。したがって、この場合には、セキュアNDプロキシは、変換/ SPNDおよびRFC 3971台のホスト用のPSオプションを含むメッセージを合成しなければならない、と変換/非SENDのノードのためのPSオプションを含むメッセージを合成してはなりません。なお、（すなわち、プロキシノードの性質に応じて）、およびセキュアなまたは非セキュアな性質に応じていない以前の考察によれば、プロキシが確保確保かのいずれかでなければならないセキュアNDによって生成された要請に応じてND広告、要請メッセージ。
In order to apply this rule, the Secure ND Proxy needs to know the security capabilities of the proxied node. The way this information is acquired depends on the application scenario, and it is discussed next:
このルールを適用するために、セキュアNDプロキシはプロキシノードのセキュリティ機能を知る必要があります。この情報が取得される方法は、アプリケーションシナリオに依存し、それが次に説明されています。
o For scenarios in which ND messages are translated for nodes that can arrive to the link in which the proxy operates, the rule can be easily applied: only for messages validated in the Secure ND Proxy according to the SEND specification [RFC3971], or according to Section 5.2.2 of this specification for messages containing a PS option (which means that another proxy previously checked that the original message was secured), the message MUST be proxied securely by the inclusion of a PS option. Unsecured ND messages could be proxied if unsecured operation is enabled in the proxy, but the message generated by the Secure ND Proxy for the received message MUST NOT include a PS option.
SEND仕様[RFC3971]に従ってのみセキュアNDプロキシで確認メッセージのため、又は記載：O NDメッセージがプロキシが動作するリンクに到達可能なノードのために翻訳されたシナリオでは、ルールは、容易に適用することができます（別のプロキシが以前に元のメッセージが確保されたことを確認することを意味する）PSオプションを含むメッセージの、本明細書のセクション5.2.2に、メッセージは、PSオプションを含めることによって確実プロキシなければなりません。無担保操作がプロキシで有効になっている場合は無担保NDメッセージをプロキシすることができますが、受信したメッセージにSecure NDプロキシによって生成されたメッセージは、PSオプションを含んではいけません。
o For scenarios in which ND messages are synthesized on behalf of remote nodes, different considerations should be made according to the particular application scenario.
NDメッセージがリモート・ノードの代わりに合成されたシナリオでは、O、別の考慮事項は、特定のアプリケーションシナリオに応じてなされるべきです。
* For MIPv6, if the MN can return to the home link, it is required that the proxy know whether the node could use SEND to defend its address or not. A HA including the PS option for proxying a non-SEND MN would make ND messages sent by the proxy be more preferred than an ND message of the non-SEND MN when the MN returns to the home link (even if the proxied messages have the Override bit set to 1). Not using the PS option for an RFC 3971 or SPND MN would make the address in the home link more vulnerable when the MN is away than when it is in the home link, defeating the purpose of the Secure Proxy ND mechanism. Therefore, in this case, the HA MUST know the SEND capabilities of the MN, MUST use the PS option if the MN is an SPND or RFC 3971 host, and MUST NOT use the PS option for non-SEND hosts.
MNがホームリンクに戻ることができた場合* MIPv6のために、プロキシが、ノードがそのアドレスかどうかを守るためにSENDを使用できるかどうかを知ることが必要とされます。 MNがホームリンクに戻ったときに非SENDのMNをプロキシ用PSオプションを含むHAは、プロキシのメッセージが持っている場合でも、（プロキシによって送信されたNDメッセージは非SENDのMNのNDメッセージよりも好ましいことになるだろうオーバーライドビット）が1に設定されます。 MNはそれがセキュアプロキシND機構の目的を破り、ホームリンクである場合よりも離れているとき、RFC 3971またはSPND MNのためのPSオプションを使用しないと、ホームリンクのアドレスはより脆弱になるだろう。したがって、この場合には、HAは、MNがSPNDまたはRFC 3971ホストで、非SENDのホストのためのPSオプションを使用してはならない場合はPSオプションを使用する必要があり、MNのSEND機能を知っている必要があります。
* For the Proxy Mobile IPv6 scenario, a node moving from a link in which the PS option has been used to protect a link-layer address to a link in which ND messages are not protected by SEND would prevent the MN from acquiring the new information until the cached information expires. However, in this case, it is reasonable to consider that all MAGs provide the same security for protecting ND messages, and that either all MAGs or no MAGs will behave as a Secure ND Proxy, so configuration is expected to be easier.
*プロキシモバイルIPv6のシナリオでは、PSオプションは、NDメッセージがSENDで保護されていないリンクへのリンク層アドレスを保護するために使用されたリンクから移動ノードは、新たな情報を取得からMNを妨げますキャッシュされた情報の有効期限が切れるまで。しかし、この場合には、すべてのMAGは、NDメッセージを保護するために同じセキュリティを提供し、すべてのMAGまたは全くのMAGのどちらかがセキュアNDプロキシとして動作しますので、設定が容易になることが期待されていることと考えるのが妥当です。
A configuration option MAY exist in a Secure ND Proxy to specify the non-SEND nodes to which it is connected, so that the proxied messages sent to these nodes are not processed according to the Secure Proxy ND specification, for performance reasons.
設定オプションは、これらのノードに送信されたプロキシ・メッセージは、パフォーマンス上の理由から、セキュアプロキシND仕様に従って処理されないように、それが接続されている非SENDノードを指定するためにセキュアNDプロキシで存在してもよいです。
The mechanism described in this document introduces a new PS option allowing a Secure ND Proxy to synthesize or translate a SEND message for a proxied address, to redirect traffic for given target addresses, or to advertise prefix information by means of RA messages. An SPND node only accepts such a message if it includes a valid PS option generated by a properly authorized Secure ND Proxy (with a certificate containing a KeyPurposeId with value id-kp-sendProxiedOwner for protecting NA, NS, and RS messages, or containing a KeyPurposeId value of id-kp-sendProxiedRouter for protecting RA and Redirect messages). Such a message has protection against the threats presented in Section 9 of [RFC3971] equivalent to a message signed with an RSA Signature option.
この文書で説明するメカニズムは、与えられた目標アドレスのトラフィックをリダイレクトする、またはRAメッセージによって、プレフィックス情報を広告するために、プロキシアドレスにSENDメッセージを合成または翻訳するためにセキュアNDプロキシを許可する新しいPSオプションを紹介します。それは適切に認可された安全NDプロキシ（NA、NS、およびRSメッセージを保護する、または収容する値Id-KP-sendProxiedOwnerとKeyPurposeIdを含む証明書とによって生成された有効なPSオプションが含まれている場合SPNDノードは、そのようなメッセージを受け付けRAを保護し、メッセージをリダイレクトするためのID-KP-sendProxiedRouterのKeyPurposeId値）。そのようなメッセージは、RSA署名オプションを使用して署名されたメッセージに相当[RFC3971]のセクション9に提示脅威に対する保護を有しています。
The security of proxied ND messages not including a PS option is the same as an unsecured ND message. The security of a proxied ND message received by a non-SEND host or RFC 3971 host is the same as an unsecured ND message.
PSオプションを含まないプロキシNDメッセージのセキュリティは、無担保NDメッセージと同じです。非SENDホストまたはRFC 3971ホストによって受信されたプロキシNDメッセージのセキュリティが保護されていないNDメッセージと同じです。
When a message including a PS option is received by an SPND node, any CGA or RSA options also included in the message are removed and the remaining message further processed. Although properly formed proxied messages MUST NOT include PS and CGA/RSA options at the same time, discarding them if they appear does not affect security. If the PS option is validated, then the information included in the message has been validly generated by a proxy, and should be honored (remember that anti-replay protection is provided by means of Nonce and Timestamp options). If the PS option is not validated, then it is treated as an unsecured message. In any case, there is no gain for an attacker from appending false or old CGA/RSA information to a message secured by a Secure ND Proxy.
PSオプションを含むメッセージをSPNDノードによって受信されると、任意のCGAまたはRSAオプションも削除されたメッセージに含まれており、残りのメッセージはさらに処理されます。が、適切に形成されたプロキシのメッセージは、彼らがセキュリティに影響を与えません表示される場合は、それらを捨て、同時にPSおよびCGA / RSAオプションを含んではいけません。 PSオプションが有効とされている場合は、そのメッセージに含まれる情報は、（アンチリプレイ保護がノンスおよびタイムスタンプオプションによって提供されていることを覚えておいてください）有効にプロキシによって生成された、と光栄する必要があります。 PSオプションが有効とされていない場合、それは無担保メッセージとして扱われます。いずれの場合においても、セキュアNDプロキシによって固定メッセージに虚偽または古いCGA / RSA情報を付加するから、攻撃者には利得がありません。
A compromised Secure ND Proxy provisioned with an authorization certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is able, like a compromised router, to siphon off traffic from the host, or mount a man-in-the-middle attack, for hosts communicating to off-link hosts. A compromised Secure ND Proxy provisioned with an authorization certificate with a KeyPurposeId value of id-kp-sendProxiedOwner can siphon off traffic or mount a man-in-the-middle attack for communication between on-link hosts, even if the hosts use SEND. Note that different application scenarios may require one type of authorization, the other, or both. To minimize security risks, authorization capabilities MUST NOT exceed the ones strictly required by the application scenario to be deployed.
ID-KP-sendProxiedRouterのKeyPurposeId値と許可証明書とプロビジョニング損なわセキュアNDプロキシは、ホストに対して、ホストからのトラフィックをオフサイフォン、またはman-in-the-middle攻撃をマウントするために、妥協ルータのように、可能ですオフリンクのホストと通信します。 ID-KP-sendProxiedOwnerのKeyPurposeId値と許可証明書とプロビジョニング損なわセキュアNDプロキシは、ホストがSENDを使用する場合でも、トラフィックをオフサイフォンまたはオンリンクホスト間の通信のためのman-in-the-middle攻撃をマウントすることができます。異なるアプリケーションシナリオ一許可の種類、その他、またはその両方を必要とし得ることに留意されたいです。セキュリティリスクを最小限に抑えるために、承認機能は厳密にデプロイされるアプリケーションのシナリオで必要とされるものを超えてはなりません。
The messages for which a Secure ND Proxy performs its function and the link for which this function is performed MUST be configured appropriately for each proxy and scenario. This configuration is especially relevant if Secure Proxy ND is used for translating ND messages from one link to another.
セキュアNDプロキシがその機能と、この機能が実行されたリンクを実行するためのメッセージを各プロキシシナリオ用に適切に設定しなければなりません。セキュアプロキシNDは、1つのリンクから別のNDメッセージを変換するために使用されている場合、この設定は特に重要です。
Section 7 discusses the security considerations resulting from the decision to append or omit the PS option, depending on the SEND-awareness of the proxied nodes.
第7節は、プロキシノードのSEND-意識に応じて、PSオプションを追加したり、省略するという決定に起因するセキュリティ上の考慮事項について説明します。
Protection against replay attacks from unsolicited messages such as NA, RA, and Redirects is provided by means of the Timestamp option. When Secure ND Proxy is used, each host, and each proxy acting on behalf of that host, are considered to be different peers in terms of timestamp verification. Since the information provided by the host and a proxy, including different link-layer addresses, may be different, a replay attack could affect the operation of a third node: replaying messages issued by a host that is no longer in the link can prevent the use of a proxy, and replaying messages of a proxy when the host is back in the link can prevent communication with the host. This kind of attack can be performed until the timestamp of the peer (either the host or a proxy) is no longer valid for the receiver. The window of vulnerability is in general larger for the first message received from a new peer than for subsequent messages received from the same peer (see [RFC3971]). A more detailed analysis of the possible attacks related to the Timestamp option is described in Section 6.3 of [RFC5909].
このようNA、RA、およびリダイレクトなどの迷惑メールからのリプレイ攻撃に対する保護はタイムスタンプオプションによって提供されます。セキュアNDプロキシを使用する場合、各ホスト、およびそのホストに代わって動作する各プロキシは、タイムスタンプの検証の面で異なるピアであると考えられています。異なるリンク層アドレスを含むホストとプロキシによって提供される情報は、異なる場合がありますので、リプレイ攻撃は、第3のノードの動作に影響を与える可能性がある：防ぐことができ、リンクされなくなっているホストによって発行された再生メッセージをプロキシの使用、およびホストがバックリンクであるときに、プロキシのメッセージを再生すると、ホストとの通信を防ぐことができます。ピアのタイムスタンプが（ホストまたはプロキシのいずれか）の受信機のためにもはや有効になるまで、この種の攻撃を実行することはできません。脆弱性の窓は、最初のメッセージのために大きく、一般的には（[RFC3971]を参照）同じピアから受信した後続のメッセージのためのより新しいピアから受信しました。タイムスタンプオプションに関連する可能攻撃のより詳細な分析は、[RFC5909]のセクション6.3に記載されています。
IANA has allocated the following a new IPv6 Neighbor Discovery Option type for the PS option, as 32. The value has been allocated from the namespace specified in the IANA "IPv6 Neighbor Discovery Option Formats" registry located at http://www.iana.org/assignments/icmpv6-parameters.
IANAは、割り当てられた値は、HTTPに位置IANAの「IPv6近隣探索オプション形式」レジストリで指定された名前空間から割り当てられた32としてPSオプションの新しいIPv6近隣探索オプションの種類は、次：//www.iana。 ORG /割り当て/ ICMPv6のパラメータ。
IANA has also allocated the following new 128-bit value under the "Cryptographically Generated Addresses (CGA) Message Type Name Space" registry [RFC3972]:
IANAは、「暗号化生成アドレス（CGA）メッセージタイプネームスペース」レジストリ[RFC3972]の下に、次の新しい128ビットの値を割り当てました。
0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804.
0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804。
The text has benefited from feedback provided by Jari Arkko, Jean-Michel Combes, Roque Gagliano, Tony Cheneau, Marcelo Bagnulo, Alexey Melnikov, Sandra Murphy, and Sean Turner.
テキストはヤリArkko、ジャン・ミッシェル・ザコームス、ロケガリアーノ、トニーCheneau、マルセロBagnulo、アレクセイ・メルニコフ、サンドラ・マーフィー、そしてショーン・ターナーによって提供されるフィードバックの恩恵を受けています。
The work of Alberto Garcia-Martinez was supported in part by the T2C2 project (TIN2008-06739-C04-01, granted by the Spanish Science and Innovation Ministry).
アルベルト・ガルシア・マルティネスの仕事は（スペインの科学イノベーション省によって付与されたTIN2008-06739-C04-01）T2C2プロジェクトによって部分的にサポートされていました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]オーラ、T.、 "暗号的に生成されたアドレス（CGA）"、RFC 3972、2005年3月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389]ターラー、D.、Talwar、M.、およびC.パテル、 "近隣探索プロキシ（NDプロキシ）"、RFC 4389、2006年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
【Ramphsi 5213] gundavelli、S。、ら、Leunji、K.、Devarapalliは、VEの、Chaudhuriの、K.、およびb。パティル、 "プロキシ・モバイル・20 6"、rphak 5213 2008年8月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]パーキンス、C.、エド。、ジョンソン、D.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 6275、2011年7月。
[RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)", RFC 6494, February 2012.
[RFC6494]ガリアーノ、R.、クリシュナン、S.、および "セキュア近隣探索のための証明書プロファイルおよび証明書の管理（SEND）" A. Kukec、RFC 6494、2012年2月。
[RSA] RSA Laboratories, "PKCS #1 v2.1: RSA Cryptography Standard", June 2002.
[RSA] RSA Laboratories社、 "PKCS＃1 v2.1の：RSA暗号化規格"、2002年6月。
[SHA1] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1 , April 1995.
[SHA1]米国国立標準技術研究所は、FIPS PUB 180-1の、1995年4月 "ハッシュ標準セキュア"。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P。、編、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing Neighbor Discovery Proxy: Problem Statement", RFC 5909, July 2010.
[RFC5909] Combesの、J-M、クリシュナン、S.、およびG.デイリー、 "近隣探索プロキシを確保：問題文"、RFC 5909、2010年7月。
Authors' Addresses
著者のアドレス
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
スレシュクリシュナンエリクソン8400 Decarie大通りマウントロイヤル、QCカナダの町
Phone: +1 514 345 7900 x42871 EMail: suresh.krishnan@ericsson.com
電話：+1 514 345 7900 x42871メール：suresh.krishnan@ericsson.com
Julien Laganier Juniper Networks 1094 North Mathilda Avenue Sunnyvale, CA 94089 USA
ジュリアンLaganierジュニパーネットワークスの1094北マチルダアベニューサニーベール、CA 94089 USA
Phone: +1 408 936 0385 EMail: julien.ietf@gmail.com
電話：+1 408 936 0385 Eメール：julien.ietf@gmail.com
Marco Bonola Rome Tor Vergata University Via del Politecnico, 1 Rome I-00133 Italy
マルコボノーラローマトルヴェルガータ大学・ストリート・ポリテクニック、1 I-00133ローマイタリア
Phone: EMail: marco.bonola@gmail.com
電話番号：Eメール：marco.bonola@gmail.com
Alberto Garcia-Martinez U. Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
マドリードのアルベルト・ガルシア・マルティネスU.カルロスIIIのAv。大学30のレガネス、マドリード28911スペイン
Phone: +34 91 6248782 EMail: alberto@it.uc3m.es URI: http://www.it.uc3m.es/
電話：+34 91 6248782 Eメール：URI alberto@it.uc3m.es：http://www.it.uc3m.es/