[要約] RFC 6496は、Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)に関する規格です。その目的は、SENDプロトコルを使用してセキュアなネイバー検出をサポートするためのセキュアプロキシNDの仕様を提供することです。
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)
安全な近隣発見のための安全なプロキシndサポート（送信）
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.
Secure Neighbor Discovery（送信）特定の脅威に対する隣人発見（ND）シグナルを保護する方法を指定します。本日定義されているように、送信は、NDメッセージを送信するノードがメッセージが送信されるアドレスの所有者であるか、ノードがルーターとして機能することを許可するキーを所有していることを想定しています。各メッセージのデジタル署名を生成するために使用されるキーまたはキー。これは、アドレス所有者の秘密鍵の知識を所有していないノードによって実行されるプロキシNDシグナリングおよび/またはルーターのキーの知識を送信を使用して保護できないことを意味します。このドキュメントは、プロキシnd操作を保護するために、電流の送信仕様を拡張します。
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
Secure Neighbor Discovery（SEND）[RFC3971]は、特定の脅威[RFC3756]に対して、隣接発見（ND）シグナル伝達[RFC4861]を保護する方法を指定します。本日定義されているように、送信は、NDメッセージを送信するノードがメッセージが送信されるアドレスの所有者であるか、ノードを認可するキーを所有するアドレスの所有者であると仮定します。
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.
ルーターとして機能し、各メッセージのデジタル署名を生成するために使用される秘密キーまたはキーを所有しています。これは、アドレス所有者の秘密鍵の知識を所有していないノードによって実行されるプロキシNDシグナリングおよび/またはルーターのキーの知識を送信を使用して保護できないことを意味します。
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をサポートして、電流の送信仕様を拡張します。この時点から、そのような拡張機能を「SECURE Proxy nd Support for Send」と呼びます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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
Proxied IPv6アドレス
An IPv6 address that does not belong to the Secure ND Proxy and for which the Secure ND Proxy is performing advertisements.
安全なNDプロキシに属していないIPv6アドレスは、安全なNDプロキシが広告を実行しているためです。
Non-SEND node
非センドノード
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]仕様を実装していないが、追加のセキュリティなしで[RFC4861]および[RFC4862]で定義されたNDプロトコルを使用する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].
安全なプロキシndサポートのためにこのドキュメントで定義されている仕様を実装していないが、[RFC3971]で定義されている送信仕様を使用する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.
元の送信仕様[RFC3971]は、NDメッセージを送信するノードのみがメッセージが送信されるアドレスの所有者であると暗黙的に想定しています。広告主は有効なRSA署名オプションを生成する必要があるため、この仮定はNDメッセージのプロキシを許可しません。ルーター証明書に関連付けられていました。
To be able to separate the roles of owner and advertiser, the following extensions to the SEND protocol are defined:
所有者と広告主の役割を分離できるようにするために、次の拡張機能が送信プロトコルに定義されています。
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].
o 安全なプロキシnd証明書。これは、エンティティがNDプロキシとして機能することを許可する証明書である。これは、コンパニオンドキュメント[RFC6494]で説明されているように、証明書が発行される目的が明示的に指定されているX.509V3証明書です。簡単に簡単に言えば、安全なプロキシND証明書には、ルーター広告（RA）に署名およびリダイレクトメッセージに署名したり、近隣広告（NA）、近隣勧誘（NS）、またはルーターの勧誘（Rs）に署名するためのプロキシを許可するために使用できる1つ以上のkeypurposeID値が含まれています。）他のノードに代わってメッセージ。この値を含めることにより、証明書所有者は、同じ証明書に示されているさまざまなアドレスの送信メッセージのプロキシを実行できます。この証明書は、[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 Proxy Signature（PS）オプションと呼ばれる新しいNeighbor Discoveryオプション。このオプションには、プロキシの公開鍵のハッシュ値と、プロキシの秘密鍵で計算された送信メッセージのデジタル署名が含まれています。プロキシの公開鍵のハッシュは、セキュアに含まれる公開鍵に対して計算されます
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メッセージの送信処理ルールの変更：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プロキシは、送信ルーターのように信頼できるインフラストラクチャの一部になります。
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.
o PSオプションで保護されるメッセージは、安全なndプロキシによって合成されている場合、または[RFC4389]で定義された処理ルールがndメッセージである場合に生じる場合、[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 ノードがセキュリティで保護されたプロキシメッセージを正常に検証できるようにするために、ノードは安全なプロキシND証明書（[RFC6494]で説明されている形式）を認識し、このドキュメントで指定された修正処理ルールを適用する必要があります。これらのノードを「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.
o SPNDノードがプロキシの公開キーを検証するために必要な認証パスを認識できるようにするために、CPS（認定パス勧誘）メッセージに応答するデバイス（認定パス広告）メッセージを使用して、送信仕様[RFC3971]のセクション6で定義されています。[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プロキシは、送信仕様[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
これは、承認された安全なndプロキシの秘密鍵でメッセージに署名することによって達成されます。Secure NDプロキシの署名は、PSオプションと呼ばれる新しいオプションに含まれています。署名はです
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.
メッセージに存在するすべてのNeighbor Discoveryプロトコル（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
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.
署名の構築に使用される公開鍵のSHA-1 [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、0x09F5 2BE5 3B62 4C76 CB96 4E7F CDC9 2804の128ビットCGAメッセージタイプタグ[RFC3972]値（この仕様の編集者によってランダムに生成されました。）
2. The 128-bit Source Address field from the IP header.
2. IPヘッダーの128ビットのソースアドレスフィールド。
3. The 128-bit Destination Address field from the IP header.
3. IPヘッダーからの128ビットの宛先アドレスフィールド。
4. The 8-bit Type, 8-bit Code, and 16-bit Checksum fields from the ICMP header.
4. ICMPヘッダーからの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オプションまで継続しますが、継続しますが、継続します。
6. All NDP options preceding the Proxy Signature option.
6. プロキシ署名オプションに先行するすべての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].
この仕様は、送信仕様[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のキープラーズ値を持つ安全なプロキシ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.
プロキシドアドレスの安全なNDプロキシによって送信されたセキュリティ済みのNDPメッセージには、PSオプションが含まれている必要があり、CGAまたはRSA署名オプションのいずれかを含めてはなりません。セクション7では、NDPメッセージを非センドノードを含むシナリオで保護する必要がある場合について説明します。
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プロキシがプロキシドアドレスの合成送信メッセージを生成する場合、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. Secure NDプロキシがセキュリティで保護されたメッセージを変換する場合、最初に傍受されたメッセージの信頼性を検証する必要があります。インターセプトされたメッセージが送信メッセージである場合、送信仕様[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]で指定されたルールに従って、タイムスタンプとNonCEのオプションを含める必要があります。タイムスタンプオプションの値は、プロキシによって生成する必要があります。プロキシがNonCEを含むメッセージを翻訳している場合、プロキシメッセージのNonCE値は傍受されたメッセージと同じでなければなりません。プロキシが勧誘メッセージを合成している場合、非CE値はプロキシによって生成する必要があります。プロキシが広告メッセージを合成している場合、NonCe値はプロキシが応答している勧誘メッセージに対応する必要があります。
2. The Proxy Signature option MUST be added as the last option in the message.
2. メッセージの最後のオプションとして、プロキシ署名オプションを追加する必要があります。
3. The data MUST be signed as explained in Section 5.1.
3. セクション5.1で説明されているように、データに署名する必要があります。
Any SEND message without a Proxy Signature option MUST be treated as specified in the SEND specification [RFC3971].
プロキシ署名オプションのない送信メッセージは、送信仕様[RFC3971]で指定されているとおり扱う必要があります。
A SEND message including a Proxy Signature option MUST be processed as specified below:
プロキシ署名オプションを含む送信メッセージは、以下に指定するように処理する必要があります。
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を参照）を知っている必要があります。Secure Proxy 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.
* RAメッセージの場合、証明書にはID-KP-sendproxiedRouterのキープラスイド値が存在する必要があり、オンリンク決定および/またはステートレスアドレスのAutoconfigurationのRAメッセージに含まれるプレフィックスは、その証明書に関連付けられた接頭辞に含まれる必要があります。
* 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.
5. 「RSA署名オプション」を「PSオプション」に置き換えることを除き、[RFC3971]セクション5.3.4で指定されているように、NONCEオプションを処理する必要があります。これらのテストが失敗した場合、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).
6. 「RSA署名オプション」を「PSオプション」に置き換えることを除き、[RFC3971]セクション5.3.4で指定されているように、タイムスタンプオプションを処理する必要があります。これらのテストが失敗した場合、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.
7. オーバーライドビット[RFC4861]セットを使用したメッセージは、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]は証明書に依存して、ルーターが特定のプレフィックスを発表することを許可されていることを証明します。ただし、Neighbor Discovery [RFC4861]は、ルーターがリンクローカルプレフィックス（Fe80 ::/64）を発表しないと述べています。したがって、FE80 ::/64プレフィックスを承認するIPアドレスのX.509拡張機能を保持するには、送信証明書が必要ではありません。ただし、いくつかの安全なプロキシ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メッセージがプロキシされている、どの方向に、非センドホストとRFC 3971ホストとの相互作用がどのように処理されるかなど）は、主に考慮される特定のシナリオに依存します。以下に示す最初の2つのシナリオでは、NDメッセージがオフリンクノードに代わって合成されます。3番目の場合、NDメッセージは、プロキシの他のインターフェイスで受信したメッセージから翻訳されます。
The description of the problems for deploying SEND in this scenario is presented in [RFC5909].
このシナリオで送信を展開するための問題の説明は、[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）は、安定したアドレスで到達可能性を維持しながら、MNのホームアドレス（HOA）を維持しながら、あるリンクから別のリンクに移動できます。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.
このシナリオでSecure Proxy ndを展開するには、つまり、HA操作を保護するために、ホームリンクのプレフィックスにID-KP-SendProxiedownerのキープラスイド値を持つ安全なプロキシ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）で返信します[RFC4861]で説明されているように、ターゲットリンク層アドレスオプション（TLLAO）として独自のリンク層アドレス（HA_LL）を含む。次に、タイムスタンプ（プロキシによって生成）と非CE（必要に応じて、[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
PSオプションを含むNAを受信するノード（例：ホームリンクのCN、またはルーター）は、セクション5.2.2で定義されたルールを適用する必要があります。この場合、NAメッセージのオーバーライドビットを使用して、それぞれにどのメッセージが勝つかを制御することに注意してください
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].
ケース：MNがホームネットワークから移動したときにプロキシによって生成されるメッセージ、またはMIPv6仕様[RFC6275]で定義されているように、MNがホームリンクに戻る場合はMN。
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]は、MNSがモビリティ関連のシグナリングに関与することを要求することなく、MNSのIPモビリティ管理サポートを提供するネットワークベースのモビリティ管理プロトコルです。IPモビリティ管理は、プロキシモバイルIPv6ドメインでMNに完全に隠されており、2つの機能エンティティによって実行されます：ローカルモビリティアンカー（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の添付ファイルを検出すると、MNのバインディング状態の更新を要求するLMAを指示します（プロキシバインディングアップデート（PBU））。シグナリングが完了すると（プロキシバインディングACK（PBA））、MAGは、そのモビリティセッションに割り当てられたホームネットワークのプレフィックス（ES）を含むルーター広告（RA）でMNに応答し、MNに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のリンクローカルアドレスを生成する必要があります。MNが最初にPMIPv6ドメインに付着したときのLMAは、各ハンドオフ後に新しいMNのサービングマグに提供されます。したがって、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.
上記のアプローチと現在の送信仕様は互換性がありません。なぜなら、異なるMAGで同じリンクローカルアドレスを共有するには、PMIPV6ドメインのすべてのMAGSがCGAとRSA署名オプションを構築するために必要なため、同じ官民キーペアを必要とするため、許容可能なセキュリティポリシーではありません。
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.
異なる雑誌に異なる官民キーペアを使用すると、異なる雑誌がリンクローカルアドレスとして異なるCGAを使用することを意味します。したがって、MNのハンドオフごとにサービングMAGのLink-Localアドレスが変更されます。これは、PMIPv6ドメインでMAG Link-Localアドレスの割り当てが発生する方法と矛盾しています。
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].
送信保護を提供するには、各MAGがPMIPv6ドメインに関連付けられた証明書を使用してプロキシとして機能するように構成する必要があります。各MAGは、ID-KP-SendProxiedOwnerのキープラスイド値を使用して、各MAGをNAおよびRSメッセージを安全にプロキシに承認します。さらに、証明書は、同じ証明書に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リンクローカルアドレスに等しく、ソースリンク層アドレスとして独自のリンクレイヤーアドレスを持つ必要があります。次に、タイムスタンプ（プロキシによって生成）と非CE（必要に応じて、[RFC3971]に従って）を含める必要があります。最後に、メッセージに署名するPSオプションをメッセージの最後のオプションとして含める必要があります。この手順には、MAGがMNに生成できる他の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で定義された処理ルールを適用する必要があります。雑誌によって送信された未承諾メッセージは、ホストがリンクを提供する雑誌に固有のタイムスタンプ値に従って、ホストが他のリンクで以前に接続されていた他の雑誌ではなく、ホストによって検証されるべきであることに注意してください。セクション5.2.2。
The problems for deploying SEND in this scenario are presented in [RFC5909].
このシナリオで送信を展開するための問題は、[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.
Neighbor Discovery（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.
安全なNDプロキシは、プロキシインターフェイスで受信したIPv6パケットを解析して、NS、NA、RS、RA、またはリダイレクトのいずれかを含むかどうかを確認する必要があります。安全なNDプロキシは、[RFC3971]に従って、またはPSオプションが含まれている場合はセクション5.2.2に従って、受信したNDメッセージの信頼性を検証する必要があります。
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ビットに加えて、[RFC4389]プロキシによってプロキシ化された場合、受信したメッセージの他のフィールドは変更されないことに注意してください。
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.
NS、NA、RS、RA、またはリダイレクトメッセージに署名できるようにするには、使用されるキーがID-KP-SendProxiedOwnerおよびID-KP-SendProxiedRouterのkeyPurposeID値を持つ証明書に対応する必要があることに注意してください。
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ノードと非センドノードとの安全な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ノード、つまり、セクション5で必要な変更に準拠していないノードを送信しても、プロキシNDメッセージで受信したPSオプションを正しく解釈できません。これらは、未知のオプションについて[RFC4861]で指定されているように、PSオプションを静かに破棄します。として
a result, these messages will be treated as unsecured, as described in Section 8 ("Transitions Issues") of the SEND specification [RFC3971].
その結果、これらのメッセージは、送信仕様[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メッセージを交換する場合（プロキシ介入なし）、どちらの方向でも、メッセージはSEND仕様[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オプションを含む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.
NDPパケットを受信する非センドノードは、未知のオプションについて[RFC4861]で指定されているように、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.
非センドノードと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.
安全なNDプロキシは、セキュリティで保護されていないNDPメッセージの使用を同時にサポートする必要があります。安全なndプロキシには、セキュアなndプロキシを完全に無効にする構成オプションがある場合があります。この構成は、デフォルトでオフにする必要があります。つまり、セキュリティはデフォルトで提供されます。次の段落では、SPND/RFC 3971ノードと非センドノードを含む混合シナリオでプロキシメッセージに提供する保護レベルに関する安全なNDプロキシの推奨される動作について説明します。特に、プロキシノードがRFC 3971またはSPNDノード、または非センドノードであるかどうかに応じて、2つの異なる状況が発生します。
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
経験則として、プロキシノードがプロキシが動作するリンクに戻ることができる場合、セキュアNDプロキシは、送信機能（つまり、それらのノードを使用してノードに代わってPSオプションのみを生成する必要があります。
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.
これは、プロキシと同じリンクに存在する場合、メッセージを防御するために送信を使用できます。つまり、RFC 3971ノードまたはSPNDノードのいずれかです）。これは、[RFC3971]で指定されているように、非担保された情報よりも保護された情報を優先し、重複するアドレス検出（DAD）手順を適切に実行できるようにすることに関連しています。したがって、この場合、安全なNDプロキシは、SPNDおよびRFC 3971ホストのPSオプションを含むメッセージを合成/翻訳する必要があり、非センドノードの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.
o ndメッセージがプロキシの動作リンクに到達できるノードに対して翻訳されるシナリオの場合、ルールを簡単に適用できます。PSオプションを含むメッセージのこの仕様のセクション5.2.2（つまり、別のプロキシが以前に元のメッセージが保護されていることを確認したことを意味します）、PSオプションを含めることにより、メッセージを安全にプロキシにする必要があります。プロキシで無担保操作が有効になっている場合、無担保NDメッセージをプロキシできますが、受信したメッセージの安全な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.
o NDメッセージがリモートノードに代わって合成されるシナリオの場合、特定のアプリケーションシナリオに従ってさまざまな考慮事項を作成する必要があります。
* 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
* MIPV6の場合、MNがホームリンクに戻ることができる場合、プロキシはノードが送信を使用してアドレスを守るかどうかを知ることが必要です。非センドMNをプロキシするためのPSオプションを含むHAは、プロキシによって送信されたNDメッセージが、MNがホームリンクに戻ったときに非センドMNのNDメッセージよりも優先されるようになります（プロキシメッセージがある場合でも、ビットを1）にオーバーライドします。RFC 3971またはSPND MNにPSオプションを使用しないと、MNがホームリンクの場合よりも不在の場合、ホームリンクのアドレスがより脆弱になり、安全なプロキシNDメカニズムの目的を打ち負かします。したがって、この場合、HAは送信機能を知っている必要があります
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の場合、MNがSPNDまたはRFC 3971ホストである場合、PSオプションを使用し、非センドホストにPSオプションを使用してはなりません。
* 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メッセージが送信によって保護されないリンクに移動するノードは、MNが新しい情報を取得することを妨げます。キャッシュされた情報が期限切れになります。ただし、この場合、すべてのMAGがNDメッセージを保護するための同じセキュリティを提供し、すべてのMAGSまたはMAGSが安全な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プロキシに存在して、接続されている非センドノードを指定して、これらのノードに送信されたプロキシメッセージがパフォーマンスの理由で安全なプロキシ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.
このドキュメントで説明されているメカニズムは、安全なNDプロキシがプロキシアドレスの送信メッセージを合成または翻訳したり、特定のターゲットアドレスのトラフィックをリダイレクトしたり、RAメッセージを使用してプレフィックス情報を宣伝できるようにする新しいPSオプションを導入します。SPNDノードは、適切に承認されたセキュアNDプロキシによって生成された有効なPSオプションを含む場合にのみそのようなメッセージを受け入れます（NA、NS、およびRSメッセージを保護するための値ID-KP-SENDProxiedOwnerを含むキープラスインドを含む証明書を使用するか、または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メッセージと同じです。非センドホストまたは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
PSオプションを含むメッセージがSPNDノードによって受信されると、メッセージに含まれるCGAまたはRSAオプションも削除され、残りのメッセージがさらに処理されます。適切に形成されたプロキシメッセージは、PSとCGA/RSAのオプションを同時に含めるべきではありませんが、表示されている場合はセキュリティに影響しない場合は破棄します。PSオプションが検証されている場合、メッセージに含まれる情報はプロキシによって有効に生成され、尊重される必要があります（非レプレイ保護はNonCEおよびタイムスタンプオプションによって提供されることを忘れないでください）。PSオプションが検証されていない場合、
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.
無担保メッセージとして扱われます。いずれにせよ、攻撃者が虚偽または古いCGA/RSA情報を適用して安全なndプロキシによって保護されたメッセージへのゲインはありません。
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プロキシは、侵害されたルーターのように、ホストからのトラフィックを吸い上げるか、ホストのために中程度の攻撃をマウントすることができますオフリンクホストとの通信。ID-KP-SendProxiedownerのkeypurposeID値を備えた認可証明書を提供する妥協した安全なNDプロキシは、ホストが送信しても、オンリンクホスト間の通信のためにトラフィックを吸い上げたり、中間のホストを攻撃したりすることができます。異なるアプリケーションシナリオには、1つのタイプの承認、もう1つのタイプ、またはその両方が必要になる場合があることに注意してください。セキュリティリスクを最小限に抑えるために、承認機能は、展開するためにアプリケーションシナリオで厳密に必要なものを超えてはなりません。
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プロキシがその機能を実行するメッセージと、この関数が実行されるリンクは、各プロキシとシナリオに対して適切に構成する必要があります。この構成は、Secure Proxy NDが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では、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は、PSオプションの新しいIPv6ネイバーディスカバリーオプションタイプを32に割り当てました。32。値は、http：//www.ianaにあるIANA "IPv6 neighbor Discoveryオプションフォーマット「レジストリ」で指定された名前空間から割り当てられています。org/assignments/icmpv6-parameters。
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.
このテキストは、Jari Arkko、Jean-Michel Combes、Roque Gagliano、Tony Cheneau、Marcelo Bagnulo、Alexey Melnikov、Sandra Murphy、およびSean Turnerが提供するフィードバックの恩恵を受けています。
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).
アルベルト・ガルシア・マルティネスの研究は、T2C2プロジェクト（TIN2008-06739-C04-01、スペイン科学イノベーション省によって付与）によって部分的にサポートされていました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213] Gundavelli、S.、Ed。、Leung、K.、Devarapalli、V.、Chowdhury、K。、およびB. Patil、「Proxy Mobile IPv6」、RFC 5213、2008年8月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275] Perkins、C.、ed。、Johnson、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] Gagliano、R.、Krishnan、S。、およびA. Kukec、「Secure Neighbor Discovery（Send）の証明書プロファイルと証明書管理」、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]国立標準技術研究所、「Secure Hash Standard」、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.、Ed。、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trust Models and Threats」、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。、Krishnan、S。、およびG. Daley、「隣接発見プロキシ：問題文」、RFC 5909、2010年7月。
Authors' Addresses
著者のアドレス
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Suresh Krishnan Ericsson 8400 Decarie Blvd.QCカナダのマウントロイヤルの町
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Julien Laganier Juniper Networks 1094 North Mathilda Avenue Sunnyvale, CA 94089 USA
Julien Laganier Juniper Networks 1094 North Mathilda Avenue Sunnyvale、CA 94089 USA
Phone: +1 408 936 0385
EMail: 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
電話：メール：marco.bonola@gmail.com
Alberto Garcia-Martinez U. Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
アルベルト・ガルシア・マルティネス・U・カルロスIII deマドリードav。Universidad 30 Leganes、Madrid 28911スペイン
Phone: +34 91 6248782
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/