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
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支持安全邻居发现（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操作的安全。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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
安全邻居发现（发送）[RFC3971]指定针对特定威胁[RFC3756]保护邻居发现（ND）信令[RFC4861]的方法。如今天所定义的，SEND假设发送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信令不能使用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".
本文档扩展了当前的SEND规范，支持代理ND。从这一点开始，我们将这种扩展称为“发送的安全代理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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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
非发送节点
An IPv6 node that does not implement the SEND [RFC3971] specification but uses the ND protocol defined in [RFC4861] and [RFC4862], without additional security.
一种IPv6节点，不实现发送[RFC3971]规范，但使用[RFC4861]和[RFC4862]中定义的ND协议，无需额外的安全性。
RFC 3971 node
RFC3971节点
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.
一个IPv6节点，根据本文档中定义的规范接收和验证消息，以实现安全代理ND支持。
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.
由安全ND代理发出的NDP消息，作为由地址所有者发出或由代表地址所有者的另一节点发出的接收NDP消息的结果。
Synthetic NDP message
合成NDP报文
An NDP message issued by a Secure ND Proxy that is not the result of a received NDP message.
由安全ND代理发出的NDP消息，它不是收到的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消息的节点才是发送该消息的地址的所有者。这种假设不允许代理ND消息，因为广告客户需要生成有效的RSA签名选项，而RSA签名选项又需要拥有用于生成加密生成地址（CGA）或与路由器证书关联的公钥-私钥对。
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代理的证书。它是一个X.509v3证书，其中明确指定了颁发证书的目的，如附带文档[RFC6494]中所述。简言之，安全代理ND证书包括一个或多个KeyPurposeId值，可用于授权代理签署路由器公告（RA）和重定向消息，或代表其他节点签署邻居公告（NA）、邻居请求（NS）或路由器请求（RS）消息。包含此值允许证书所有者对同一证书中指示的一系列地址执行发送消息代理。此证书可以通过[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）选项。此选项包含代理的公钥的哈希值，以及使用代理的私钥计算的发送消息的数字签名。代理的公钥散列是根据安全代理中包含的公钥计算的
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代理合成的，则根据[RFC4861]生成；如果消息是翻译的ND消息，则根据[RFC4389]中定义的处理规则生成。
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节点知道验证代理公钥所需的认证路径，对发送规范[RFC3971]第6节中定义的带有CPA（认证路径公告）消息的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代理通过添加新的处理规则来执行发送规范[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代理的私钥对消息进行签名来实现的。安全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.
对消息中存在的所有邻居发现协议（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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
一个128位字段，包含用于构造签名的公钥SHA-1[SHA1]散列的最高有效（最左边）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。（标签值由本规范的编辑器随机生成。）
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消息必须使用与安全代理ND证书对应的密钥进行签名，密钥目的id值[RFC6494]为id kp sendProxiedOwner，并且消息的源地址必须包含在与证书关联的前缀中。RA和重定向消息必须使用与具有id kp sendProxiedRouter KEYPURSEID值的安全代理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. 如果安全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. 必须根据发送[RFC3971]中指定的规则包括时间戳和Nonce选项。时间戳选项中的值必须由代理生成。如果代理正在翻译包含nonce的消息，则代理消息中的nonce值必须与拦截消息中的nonce值相同。如果代理正在合成请求消息，则必须由代理生成Nonce值。如果代理正在合成广告消息，则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节）。安全代理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的KeyPurposeId值，并且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. 必须按照[RFC3971]第5.3.4节的规定处理Nonce选项，但将“RSA签名选项”替换为“PS选项”除外；如果这些测试失败，则包括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. 必须按照[RFC3971]第5.3.4节的规定处理时间戳选项，但将“RSA签名选项”替换为“PS选项”除外。如果这些测试失败，则包括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]依赖证书来证明路由器有权宣布某个前缀。但是，邻居发现[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支持。请注意，应用安全代理ND支持的特定方式（代理哪些ND消息、在哪个方向、如何处理与非发送主机和RFC 3971主机的交互等）在很大程度上取决于所考虑的特定场景。在下面介绍的前两个场景中，代表断开链路的节点合成ND消息。在第三种方法中，ND消息从代理的其他接口接收的消息转换而来。
The description of the problems for deploying SEND in this scenario is presented in [RFC5909].
[RFC5909]中介绍了在此场景中部署SEND的问题。
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.
为了在此场景中部署安全代理ND，即为了保护HA操作，需要一个密钥目的id值为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代理。当HA在主链路上截获NS时，HA会检查NS内的目标地址是否与绑定缓存中MN的任何主地址匹配，如果匹配，则会使用[RFC4861]中所述的邻居播发（NA）进行回复，其中包含其自己的链路层地址（HA）作为目标链路层地址选项（TLLAO）。然后，必须包括时间戳（由代理生成）和nonce（如果合适，根据[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 |
| |------------------------->|
| | |
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].
案例：如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提供IP移动性管理支持，而无需MNs参与移动性相关信令。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）。在检测到MN的连接时，新接入链路上的MAG向LMA发出信号，请求更新MN的绑定状态（通过代理绑定更新（PBU））。一旦信令完成（它接收到代理绑定Ack（PBA）），MAG就向MN回复路由器通告（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 | |
|<---------------------| |
| | |
| | |
| | |
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第一次连接到PMIPv6域时，LMA生成MN连接到的链路上的MAG链路本地地址，并在每次切换后提供给新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.
上述方法与当前的发送规范不兼容，因为在不同的MAG上共享相同的链路本地地址将要求PMIPv6域的所有MAG使用相同的公私密钥对构造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.
在不同的MAG上使用不同的公私密钥对意味着不同的MAG使用不同的CGA作为链路本地地址。因此，在MN的每次切换之后，服务MAG的链路本地地址将改变，这与在PMIPv6域中发生MAG链路本地地址分配的方式相矛盾。
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的KeyPurposeId值安全代理NA和RS消息。此外，证书还必须授权MAG通过将id kp sendProxiedRouter的KeyPurposeId值关联到同一证书来播发前缀。请注意，[RFC6494]支持包含多个KeyPurposeId值。
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链路本地地址，其自身链路层地址作为源链路层地址。然后，必须包括时间戳（由代理生成）和nonce（如果合适，根据[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.
从MAG接收包含PS选项的消息的节点必须应用第5.2.2节中定义的处理规则。注意，根据第5.2.2节的处理步骤6，主机应根据特定于为链路服务的MAG的时间戳值，而不是主机之前在其他链路中连接到的任何其他MAG，验证MAG发送的未经请求的消息。
The problems for deploying SEND in this scenario are presented in [RFC5909].
[RFC5909]中介绍了在此场景中部署SEND的问题。
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 | |
|<-------------------------| |
| | |
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:RFC4389邻居发现代理操作
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.
安全ND代理必须解析它在代理接口上接收的任何IPv6数据包，以检查它是否包含以下NDP消息之一：NS、NA、RS、RA或重定向。安全ND代理必须根据[RFC3971]或第5.2.2节（如果包含PS选项）验证收到的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）），将目标链路层地址保持为与目标IPv6地址相对应的邻居条目中的地址，设置代理RA消息的P位等。请注意，除了链路层地址和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或重定向消息进行签名，所使用的密钥必须对应于KeyPurposeId值为id kp sendProxiedOwner和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.
为了部署此场景，代理段中的节点必须知道授权代理操作的证书。为此，可能要求每个代理段（可能是代理本身）至少配置一个设备，以通过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.
在本节中，我们将讨论安全ND代理和SPND节点与RFC 3971节点和非发送节点的交互。如[RFC3971]所述，网络运营商可能希望同时运行接受安全NDP消息和不安全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选项。这些发送节点会自动放弃PS选项，如[RFC4861]中针对任何未知选项所述。像
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消息（无需代理干预）时，在任一方向上，都会根据发送规范[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消息的能力，而不影响它们生成由SEND保护的消息的方式）。
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数据包的非发送节点会自动放弃PS选项，如[RFC4861]中针对任何未知选项所述。因此，这些节点将由安全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消息和非安全NDP消息，尽管其配置可能会导致不对非安全NDP消息执行代理。安全ND代理还可以具有一个配置选项，通过该选项它可以完全禁用安全ND代理。默认情况下应关闭此配置；也就是说，默认情况下提供安全性。在以下段落中，我们将讨论安全ND代理在涉及SPND/RFC 3971节点和非发送节点的混合场景中为代理消息提供的保护级别的建议行为。具体而言，根据代理节点是RFC 3971还是SPND节点，还是非发送节点，会出现两种不同的情况。
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.
如果存在于与代理相同的链接上，则可以使用SEND来保护其消息（换句话说，RFC3971节点或SPND节点）。如[RFC3971]所述，这与允许节点选择安全信息而不是不安全信息以及正确执行重复地址检测（DAD）过程有关。因此，在这种情况下，对于SPND和RFC 3971主机，安全ND代理必须合成/转换包含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消息的场景，可以轻松应用该规则：仅适用于根据发送规范[RFC3971]在安全ND代理中验证的消息，或根据本规范第5.2.2节，适用于包含PS选项的消息（这意味着另一个代理以前检查过原始消息是否安全），必须通过包含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可以返回到主链接，则要求代理知道节点是否可以使用SEND来保护其地址。当MN返回到主链路时，包括用于代理非发送MN的PS选项的HA将使代理发送的ND消息比非发送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消息不受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代理中可能存在一个配置选项，用于指定其连接到的非发送节点，以便出于性能原因，发送到这些节点的代理消息不会根据安全代理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.
本文档中描述的机制引入了一个新的PS选项，允许安全ND代理合成或翻译代理地址的发送消息，重定向给定目标地址的通信量，或通过RA消息发布前缀信息。SPND节点仅在包含由正确授权的安全ND代理生成的有效PS选项时才接受此类消息（证书包含值为id kp sendProxiedOwner的KeyPurposeId，用于保护NA、NS和RS消息，或包含值为id kp sendProxiedRouter的KeyPurposeId，用于保护RA和重定向消息）。此类消息具有针对[RFC3971]第9节所述威胁的保护，相当于使用RSA签名选项签名的消息。
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
当SPND节点接收到包含PS选项的消息时，也包括在消息中的任何CGA或RSA选项都将被删除，剩余的消息将被进一步处理。虽然格式正确的代理消息不能同时包含PS和CGA/RSA选项，但如果出现，则丢弃它们不会影响安全性。如果验证了PS选项，则消息中包含的信息已由代理有效生成，应予以尊重（请记住，防重播保护是通过Nonce和Timestamp选项提供的）。如果未验证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值为id kp sendProxiedRouter的授权证书的受损安全ND代理可以像受损路由器一样，从主机中抽取流量，或装载中间人攻击。受危害的安全ND代理服务器提供了一个授权证书，其KeyPurposeId值为id kp sendProxiedOwner，即使主机使用SEND，该代理服务器也可以从流量中抽取流量或发起中间人攻击，以便在链路主机之间进行通信。请注意，不同的应用程序场景可能需要一种授权类型，另一种授权类型，或者两者都需要。为了最大限度地降低安全风险，授权功能不得超过要部署的应用程序场景严格要求的功能。
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用于将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代理时，就时间戳验证而言，每个主机和代表该主机的每个代理都被视为不同的对等方。由于主机和代理提供的信息（包括不同的链路层地址）可能不同，因此重播攻击可能会影响第三个节点的操作：重播不再位于链路中的主机发出的消息可以阻止使用代理，当主机返回链路时重放代理的消息可以阻止与主机的通信。在对等方（主机或代理）的时间戳对接收方不再有效之前，可以执行此类攻击。从新对等方接收的第一条消息的漏洞窗口通常大于从同一对等方接收的后续消息的漏洞窗口（请参见[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。该值已从位于的IANA“IPv6邻居发现选项格式”注册表中指定的命名空间中分配http://www.iana.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.
该文本得益于贾里·阿尔科、让·米歇尔·库姆斯、罗克·加利亚诺、托尼·切诺、马塞洛·巴格鲁、阿列克谢·梅尔尼科夫、桑德拉·墨菲和肖恩·特纳提供的反馈。
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，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年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，“邻居发现代理（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.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年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无状态地址自动配置”，RFC 48622007年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，“代理移动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 62752011年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，“安全邻居发现（SEND）的证书配置文件和证书管理”，RFC 64942012年2月。
[RSA] RSA Laboratories, "PKCS #1 v2.1: RSA Cryptography Standard", June 2002.
[RSA]RSA实验室，“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-11995年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邻居发现（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.，Krishnan，S.和G.Daley，“保护邻居发现代理：问题声明”，RFC 59092010年7月。
Authors' Addresses
作者地址
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
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号，邮编94089
Phone: +1 408 936 0385
EMail: julien.ietf@gmail.com
Phone: +1 408 936 0385
EMail: julien.ietf@gmail.com
Marco Bonola Rome Tor Vergata University Via del Politecnico, 1 Rome I-00133 Italy
意大利罗马I-00133号，马可·博诺拉（Marco Bonola Rome）经德尔波利特尼科（del Politecnico）前往维加塔大学
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.卡洛斯三世马德里大道。西班牙马德里勒加内斯30大学28911
Phone: +34 91 6248782
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/
Phone: +34 91 6248782
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/