Internet Engineering Task Force (IETF) J-M. Combes
Request for Comments: 5909 France Telecom Orange
Category: Informational S. Krishnan
ISSN: 2070-1721 Ericsson
G. Daley
Netstar Logicalis
July 2010
Internet Engineering Task Force (IETF) J-M. Combes
Request for Comments: 5909 France Telecom Orange
Category: Informational S. Krishnan
ISSN: 2070-1721 Ericsson
G. Daley
Netstar Logicalis
July 2010
Securing Neighbor Discovery Proxy: Problem Statement
保护邻居发现代理：问题陈述
Abstract
摘要
Neighbor Discovery Proxies are used to provide an address presence on a link for nodes that are no longer present on the link. They allow a node to receive packets directed at its address by allowing another device to perform Neighbor Discovery operations on its behalf.
邻居发现代理用于为链路上不再存在的节点提供链路上的地址存在。它们允许节点通过允许另一个设备代表其执行邻居发现操作来接收指向其地址的数据包。
Neighbor Discovery Proxy is used in Mobile IPv6 and related protocols to provide reachability from nodes on the home network when a Mobile Node is not at home, by allowing the Home Agent to act as proxy. It is also used as a mechanism to allow a global prefix to span multiple links, where proxies act as relays for Neighbor Discovery messages.
邻居发现代理用于移动IPv6和相关协议中，通过允许归属代理充当代理，在移动节点不在家时提供归属网络上节点的可达性。它还用作一种机制，允许全局前缀跨越多个链路，其中代理充当邻居发现消息的中继。
Neighbor Discovery Proxy currently cannot be secured using Secure Neighbor Discovery (SEND). Today, SEND assumes that a node advertising an address is the address owner and in possession of appropriate public and private keys for that node. This document describes how existing practice for proxy Neighbor Discovery relates to SEND.
当前无法使用安全邻居发现（SEND）保护邻居发现代理。现在，SEND假设一个公布地址的节点是地址所有者，并且拥有该节点的适当公钥和私钥。本文档描述了代理邻居发现的现有实践与发送的关系。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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/rfc5909.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5909.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy . . . . . . 4
2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy . . . . . . 6
2.3. Bridge-Like ND Proxies . . . . . . . . . . . . . . . . . . 6
3. Proxy Neighbor Discovery and SEND . . . . . . . . . . . . . . 9
3.1. CGA Signatures and Proxy Neighbor Discovery . . . . . . . 9
3.2. Non-CGA Signatures and Proxy Neighbor Discovery . . . . . 10
3.3. Securing Proxy DAD . . . . . . . . . . . . . . . . . . . . 11
3.4. Securing Router Advertisements . . . . . . . . . . . . . . 11
4. Potential Approaches to Securing Proxy ND . . . . . . . . . . 12
4.1. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . 12
4.1.1. Mobile IPv6 and Router-Based Authorization . . . . . . 13
4.1.2. Mobile IPv6 and Per-Address Authorization . . . . . . 13
4.1.3. Cryptographic-Based Solutions . . . . . . . . . . . . 13
4.1.4. Solution Based on the 'Point-to-Point' Link Model . . 14
4.2. Secured Proxy ND and Bridge-Like Proxies . . . . . . . . . 14
4.2.1. Authorization Delegation . . . . . . . . . . . . . . . 14
4.2.2. Unauthorized Routers and Proxies . . . . . . . . . . . 14
4.2.3. Multiple Proxy Spans . . . . . . . . . . . . . . . . . 15
4.2.4. Routing Infrastructure Delegation . . . . . . . . . . 15
4.2.5. Local Delegation . . . . . . . . . . . . . . . . . . . 16
4.2.6. Host Delegation of Trust to Proxies . . . . . . . . . 17
4.3. Proxying Unsecured Addresses . . . . . . . . . . . . . . . 17
5. Two or More Nodes Defending the Same Address . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Router Trust Assumption . . . . . . . . . . . . . . . . . 19
6.2. Certificate Transport . . . . . . . . . . . . . . . . . . 19
6.3. Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. IPv6 Mobile Nodes and Neighbor Discovery Proxy . . . . . . 4
2.2. IPv6 Fixed Nodes and Neighbor Discovery Proxy . . . . . . 6
2.3. Bridge-Like ND Proxies . . . . . . . . . . . . . . . . . . 6
3. Proxy Neighbor Discovery and SEND . . . . . . . . . . . . . . 9
3.1. CGA Signatures and Proxy Neighbor Discovery . . . . . . . 9
3.2. Non-CGA Signatures and Proxy Neighbor Discovery . . . . . 10
3.3. Securing Proxy DAD . . . . . . . . . . . . . . . . . . . . 11
3.4. Securing Router Advertisements . . . . . . . . . . . . . . 11
4. Potential Approaches to Securing Proxy ND . . . . . . . . . . 12
4.1. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . 12
4.1.1. Mobile IPv6 and Router-Based Authorization . . . . . . 13
4.1.2. Mobile IPv6 and Per-Address Authorization . . . . . . 13
4.1.3. Cryptographic-Based Solutions . . . . . . . . . . . . 13
4.1.4. Solution Based on the 'Point-to-Point' Link Model . . 14
4.2. Secured Proxy ND and Bridge-Like Proxies . . . . . . . . . 14
4.2.1. Authorization Delegation . . . . . . . . . . . . . . . 14
4.2.2. Unauthorized Routers and Proxies . . . . . . . . . . . 14
4.2.3. Multiple Proxy Spans . . . . . . . . . . . . . . . . . 15
4.2.4. Routing Infrastructure Delegation . . . . . . . . . . 15
4.2.5. Local Delegation . . . . . . . . . . . . . . . . . . . 16
4.2.6. Host Delegation of Trust to Proxies . . . . . . . . . 17
4.3. Proxying Unsecured Addresses . . . . . . . . . . . . . . . 17
5. Two or More Nodes Defending the Same Address . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Router Trust Assumption . . . . . . . . . . . . . . . . . 19
6.2. Certificate Transport . . . . . . . . . . . . . . . . . . 19
6.3. Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Neighbor Discovery Proxy is defined in IPv6 Neighbor Discovery [RFC4861]. It is used in networks where a prefix has to span multiple links [RFC4389] but also in Mobile IPv6 [RFC3775] (and so in Mobile-IPv6-based protocols like Network Mobility (NEMO) [RFC3963], Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5568], or Hierarchical Mobile IPv6 (HMIPv6) [RFC5380]) and in the Internet Key Exchange Protocol (IKE) version 2 (IKEv2) [RFC4306]. It allows a device that is not physically present on a link to have another advertise its presence, and forward packets to the off-link device.
邻居发现代理在IPv6邻居发现[RFC4861]中定义。它用于前缀必须跨越多个链路的网络[RFC4389]，也用于移动IPv6[RFC3775]（以及基于移动IPv6的协议，如网络移动性（NEMO）[RFC3963]、移动IPv6快速切换（FMIPv6）[RFC5568]或分层移动IPv6（HMIPv6）[RFC5380]）和Internet密钥交换协议（IKE）版本2（IKEv2）[RFC4306]。它允许链路上物理上不存在的设备让另一个设备公布其存在，并将数据包转发到断开链路的设备。
Neighbor Discovery Proxy relies upon another device, the proxy, to monitor for Neighbor Solicitations (NSs), and answer with Neighbor Advertisements (NAs). These proxy Neighbor Advertisements direct data traffic through the proxy. Proxied traffic is then forwarded to the end destination.
邻居发现代理依赖于另一个设备，即代理，来监视邻居请求（NSs），并使用邻居公告（NAs）进行应答。这些代理邻居播发通过代理直接传输数据。然后，代理流量被转发到最终目的地。
This section describes the different scenarios where the interaction between Secure Neighbor Discovery (SEND) and ND Proxy raises issues.
本节描述了安全邻居发现（SEND）和ND代理之间的交互引起问题的不同场景。
The goal of IPv6 mobility is to allow nodes to remain reachable while moving around in the IPv6 Internet. The following text is focused on Mobile IPv6 but the issue raised by the interaction between SEND and ND Proxy may be the same with Mobile IPv6 based protocols (e.g., NEMO, HMIPv6).
IPv6移动性的目标是允许节点在IPv6 Internet中移动时保持可访问性。以下文本主要关注移动IPv6，但发送和ND代理之间的交互所引发的问题可能与基于移动IPv6的协议（例如，NEMO、HMIPv6）相同。
For Mobile IPv6 Mobile Nodes (MNs), it is necessary to keep existing sessions going or to allow new sessions even when one leaves the home network.
对于移动IPv6移动节点（MN），即使离开家庭网络，也需要保持现有会话继续或允许新会话。
In order to continue existing sessions, when nodes are present on the home link, the Proxy (i.e., the Home Agent in Mobile IPv6) sends an unsolicited NA to the all-nodes multicast address on the home link as specified [RFC3775].
为了继续现有会话，当节点出现在归属链路上时，代理（即移动IPv6中的归属代理）会按照规定向归属链路上的所有节点多播地址发送未经请求的NA[RFC3775]。
For new sessions, the Proxy, which listens to the MN's address responds with a Neighbor Advertisement that originates at its own IPv6 address and has the proxy's address as the Target Link-Layer Address, but contains the absent mobile in the Target Address field of the Neighbor Advertisement. In this case, SEND cannot be applied because the address in the Target Address field is not the same as the one in the Source Address field of the IP header.
对于新会话，侦听MN地址的代理使用邻居播发进行响应，邻居播发源自其自己的IPv6地址，并将代理地址作为目标链路层地址，但在邻居播发的目标地址字段中包含缺少的移动设备。在这种情况下，无法应用发送，因为目标地址字段中的地址与IP标头的源地址字段中的地址不同。
As seen in Figure 1, solicitors send a multicast solicitation to the solicited nodes multicast address (based on the unicast address) of the absent node (a mobile node that is away from the home link).
如图1所示，律师向缺席节点（远离主链路的移动节点）的请求节点多播地址（基于单播地址）发送多播请求。
Absent Mobile Proxy Solicitor
缺席流动代理律师
NS:SL3=S,DL3=Sol(A),TA=A
+-----+ SL2=s,DL2=sol(a),SLL=s
| |<================
| |
| |================>
+-----+ NA:SL3=P,DL3=S,TA=A,
SL2=p,DL2=s,TLL=p
NS:SL3=S,DL3=Sol(A),TA=A
+-----+ SL2=s,DL2=sol(a),SLL=s
| |<================
| |
| |================>
+-----+ NA:SL3=P,DL3=S,TA=A,
SL2=p,DL2=s,TLL=p
Legend:
SL3: Source IPv6 Address NS: Neighbor Solicitation
DL3: Destination IPv6 Address NA: Neighbor Advertisement
SL2: Source Link-Layer Address RS: Router Solicitation
DL2: Destination Link-Layer Address RA: Router Advertisement
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Legend:
SL3: Source IPv6 Address NS: Neighbor Solicitation
DL3: Destination IPv6 Address NA: Neighbor Advertisement
SL2: Source Link-Layer Address RS: Router Solicitation
DL2: Destination Link-Layer Address RA: Router Advertisement
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 1
图1
While at home, if the MN has configured Cryptographically Generated Addresses (CGAs) [RFC3972], it can secure establishment by its on-link neighbors of Neighbor Cache Entries (NCEs) for its CGAs by using SEND [RFC3971]. SEND security requires a node sending Neighbor Advertisements for a given address to be in possession of the public/ private key pair that generated the address.
在家时，如果MN配置了加密生成的地址（CGA）[RFC3972]，它可以通过使用发送[RFC3971]通过其链路上的邻居为其CGA建立邻居缓存项（NCE）。发送安全性要求发送给定地址的邻居播发的节点拥有生成该地址的公钥/私钥对。
When an MN moves away from the home link, a proxy has to undertake Neighbor Discovery signaling on behalf of the MN. In Mobile IPv6, the role of the proxy is undertaken by the Home Agent. While the Home Agent has a security association with the MN, it does not have access to the public/private key pair used to generate the MN's CGA. Thus, the Home Agent acting as an ND proxy cannot use SEND for the address it is proxying [RFC3971].
当MN离开归属链路时，代理必须代表MN执行邻居发现信令。在移动IPv6中，代理的角色由归属代理承担。虽然归属代理与MN具有安全关联，但它不能访问用于生成MN的CGA的公钥/私钥对。因此，充当ND代理的归属代理无法将SEND用于其代理的地址[RFC3971]。
When an MN moves from the home network to a visited network, the proxy will have to override the MN's existing Neighbor Cache Entries that are flagged as secure [RFC3971]. This is needed for the Home Agent to intercept traffic sent on-link to the MN that would otherwise be sent to the MN's link-layer address.
当MN从家庭网络移动到访问网络时，代理必须覆盖标记为安全的MN现有邻居缓存项[RFC3971]。这是归属代理截获在到MN的链路上发送的流量所必需的，否则这些流量将被发送到MN的链路层地址。
With the current SEND specification, any solicitation or advertisement sent by the proxy will be unsecure and thus will not be able to update the MN's NCE for the home address because it is flagged as secured. These existing Neighbor Cache Entries will only time-out after Neighbor Unreachability Detection [RFC4861] concludes the Home Address is unreachable at the link layer recorded in the NCE.
在当前的发送规范中，代理发送的任何请求或广告都是不安全的，因此将无法更新MN的NCE以获得家庭地址，因为它被标记为安全的。只有在邻居不可访问性检测[RFC4861]得出在NCE中记录的链路层无法访问家庭地址的结论后，这些现有的邻居缓存项才会超时。
Where secured proxy services are not able to be provided, a proxy's advertisement may be overridden by a rogue proxy without the receiving host realizing that an attack has occurred. This is identical to what happens in a network where SEND is not deployed.
如果无法提供安全代理服务，则在接收主机未意识到攻击已发生的情况下，恶意代理可能会覆盖代理的播发。这与未部署SEND的网络中发生的情况相同。
This scenario is a sub-case of the previous one. In this scenario, the IPv6 node will never be on the link where the ND messages are proxied. For example, an IPv6 node gains remote access to a network protected by a security gateway that runs IKEv2 [RFC4306]. When a node needs an IP address in the network protected by a security gateway, the security gateway assigns an address dynamically using Configuration Payload during IKEv2 exchanges. The security gateway then needs to receive packets sent to this address; one way to do so would be to proxy ND messages.
此场景是前一个场景的子场景。在这种情况下，IPv6节点永远不会位于ND消息被代理的链路上。例如，IPv6节点可以远程访问受运行IKEv2[RFC4306]的安全网关保护的网络。当节点在受安全网关保护的网络中需要IP地址时，安全网关在IKEv2交换期间使用配置负载动态分配地址。然后，安全网关需要接收发送到此地址的数据包；一种方法是代理ND消息。
The Neighbor Discovery (ND) Proxy specification [RFC4389] defines an alternative method to classic bridging. Just as with classic bridging, multiple link-layer segments are bridged into a single segment, but with the help of proxying at the IP layer rather than link-layer bridging. In this case, the proxy forwards messages while modifying their source and destination MAC addresses, and it rewrites their solicited and override flags and Link-Layer Address Options.
邻居发现（ND）代理规范[RFC4389]定义了经典桥接的替代方法。与经典桥接一样，多个链路层段桥接为单个段，但借助于IP层代理而不是链路层桥接。在这种情况下，代理在修改消息的源和目标MAC地址的同时转发消息，并重写其请求和覆盖标志以及链路层地址选项。
This rewriting is incompatible with SEND signed messages for a number of reasons:
此重写与发送签名邮件不兼容，原因如下：
o Rewriting elements within the message will break the digital signature.
o 重写消息中的元素将破坏数字签名。
o The source IP address of each packet is the packet's origin, not the proxy's address. The proxy is unable to generate another signature for this address, as it doesn't have the CGA private key [RFC3971].
o 每个数据包的源IP地址是数据包的源地址，而不是代理地址。代理无法为此地址生成另一个签名，因为它没有CGA私钥[RFC3971]。
Thus, proxy modification of SEND solicitations may require sharing of credentials between the proxied node and the proxying node or creation of new options with proxying capabilities.
因此，发送请求的代理修改可能需要在代理节点和代理节点之间共享凭据，或者创建具有代理功能的新选项。
While bridge-like ND proxies aim to provide as little interference with ND mechanisms as possible, SEND has been designed to prevent modification or spoofing of advertisements by devices on the link.
虽然类似网桥的ND代理旨在尽可能少地干扰ND机制，但SEND的设计旨在防止链路上的设备修改或欺骗广告。
Of particular note is the fact that ND Proxy performs a different kind of proxy Neighbor Discovery to Mobile IPv6 [RFC3775] [RFC4389]. RFC 3775 (Mobile IPv6) specifies that the Home Agent as proxy sends Neighbor Advertisements from its own address with the Target Address set to the absent Mobile Node's address. The Home Agent's own link-layer address is placed in the Target Link-Layer Address Option [RFC3775]. On the other hand, ND Proxy resends messages containing their original address, even after modification (i.e., the IP source address remains the same) [RFC4389]. Figure 2 describes packet formats for proxy Neighbor solicitation and advertisement as specified by RFC 4389.
特别值得注意的是，ND Proxy执行与移动IPv6不同的代理邻居发现[RFC3775][RFC4389]。RFC 3775（移动IPv6）指定作为代理的归属代理从其自身地址发送邻居广告，目标地址设置为缺席移动节点的地址。归属代理自己的链路层地址位于目标链路层地址选项[RFC3775]中。另一方面，即使在修改之后，ND代理也会重新发送包含其原始地址的消息（即，IP源地址保持不变）[RFC4389]。图2描述了RFC4389指定的代理邻居请求和播发的数据包格式。
Advertiser Proxy Solicitor
广告主代理律师
NS:SL3=S,DL3=Sol(A),TA=A, NS:SL3=S,DL3=Sol(A),TA=A,
SL2=p,DL2=sol(a),SLL=p +-----+ SL2=s,DL2=sol(a),SLL=s
<==================| |<================
| |
==================>| |================>
NA:SL3=A,DL3=S,TA=A, +-----+ NA:SL3=A,DL3=S,TA=A
SL2=a,DL2=p,TLL=a SL2=p,DL2=s,TLL=p
NS:SL3=S,DL3=Sol(A),TA=A, NS:SL3=S,DL3=Sol(A),TA=A,
SL2=p,DL2=sol(a),SLL=p +-----+ SL2=s,DL2=sol(a),SLL=s
<==================| |<================
| |
==================>| |================>
NA:SL3=A,DL3=S,TA=A, +-----+ NA:SL3=A,DL3=S,TA=A
SL2=a,DL2=p,TLL=a SL2=p,DL2=s,TLL=p
Legend:
SL3: Source IPv6 Address NS: Neighbor Solicitation
DL3: Destination IPv6 Address NA: Neighbor Advertisement
SL2: Source Link-Layer Address
DL2: Destination Link-Layer Address
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Legend:
SL3: Source IPv6 Address NS: Neighbor Solicitation
DL3: Destination IPv6 Address NA: Neighbor Advertisement
SL2: Source Link-Layer Address
DL2: Destination Link-Layer Address
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 2
图2
In order to use the same security procedures for both ND Proxy and Mobile IPv6, changes may be needed to the proxying procedures in [RFC4389], as well as changes to SEND.
为了对ND代理和移动IPv6使用相同的安全过程，可能需要更改[RFC4389]中的代理过程，以及更改发送。
An additional (and undocumented) requirement for bridge-like proxying is the operation of router discovery. Router discovery packets may similarly modify Neighbor Cache state, and require protection from SEND.
网桥式代理的另一个（未记录）要求是路由器发现的操作。路由器发现数据包可能类似地修改邻居缓存状态，并需要防止发送。
In Figure 3, the router discovery messages propagate without modification to the router address, but elements within the message change. This is consistent with the description of Neighbor Discovery above.
在图3中，路由器发现消息在不修改路由器地址的情况下传播，但是消息中的元素发生了变化。这与上面对邻居发现的描述一致。
Advertiser Proxy Solicitor
广告主代理律师
RS:SL3=S,DL3=AllR, RS:SL3=S,DL3=AllR,
SL2=p,DL2=allr,SLL=p +-----+ SL2=s,DL2=allr,SLL=s
<==================| |<================
| |
==================>| |================>
RA:SL3=A,DL3=S, +-----+ RA:SL3=A,DL3=S,
SL2=a,DL2=p,SLL=a SL2=p,DL2=s,SLL=p
RS:SL3=S,DL3=AllR, RS:SL3=S,DL3=AllR,
SL2=p,DL2=allr,SLL=p +-----+ SL2=s,DL2=allr,SLL=s
<==================| |<================
| |
==================>| |================>
RA:SL3=A,DL3=S, +-----+ RA:SL3=A,DL3=S,
SL2=a,DL2=p,SLL=a SL2=p,DL2=s,SLL=p
Legend:
SL3: Source IPv6 Address RS: Router Solicitation
DL3: Destination IPv6 Address RA: Router Advertisement
SL2: Source Link-Layer Address
DL2: Destination Link-Layer Address
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Legend:
SL3: Source IPv6 Address RS: Router Solicitation
DL3: Destination IPv6 Address RA: Router Advertisement
SL2: Source Link-Layer Address
DL2: Destination Link-Layer Address
TA: Target Address
SLL/TLL: Source/Target Link-Layer Address Option
Figure 3
图3
Once again, these messages may not be signed with a CGA signature by the proxy, because it does not own the source address.
同样，代理可能不会使用CGA签名对这些消息进行签名，因为它不拥有源地址。
Additionally, Authorization Delegation Discovery messages need to be exchanged for bridge-like ND proxies to prove their authority to forward. Unless the proxy receives explicit authority to act as a router, or the router knows of its presence, no authorization may be made. This explicit authorization requirement may be at odds with the zero configuration goal of ND proxying [RFC4389].
此外，授权委托发现消息需要与类似网桥的ND代理交换，以证明其转发权限。除非代理收到作为路由器的明确授权，或者路由器知道其存在，否则不得进行授权。这种明确的授权要求可能与ND代理的零配置目标不一致[RFC4389]。
An alternative (alluded to in an appendix of ND Proxy [RFC4389]) suggests that the proxy send Router Advertisements (RAs) from its own address. As described by ND Proxy, this is insufficient for providing proxied Neighbor Advertisement service, but may be matched with Neighbor solicitation and advertisement services using the proxy's source address in the same way as Mobile IPv6 [RFC4389] [RFC3775]. This means that all router and Neighbor advertisements would come from the proxied address, but may contain a target address that allows proxied Neighbor presence to be established with peers on other segments. Router discovery in this case has the identity of the original (non-proxy) router completely obscured in router discovery messages.
另一种选择（在ND Proxy[RFC4389]的附录中提及）建议代理从其自己的地址发送路由器广告（RAs）。如ND Proxy所述，这不足以提供代理邻居广告服务，但可以使用代理的源地址以与移动IPv6[RFC4389][RFC3775]相同的方式与邻居请求和广告服务相匹配。这意味着所有路由器和邻居播发将来自代理地址，但可能包含一个目标地址，该地址允许与其他段上的对等方建立代理邻居存在。在这种情况下，路由器发现将原始（非代理）路由器的身份完全隐藏在路由器发现消息中。
The resultant proxy messages would have no identifying information indicating their origin, which means that proxying between multiple links would require state to be stored on outstanding solicitations (effectively a ND only NAT). This level of state storage may be undesirable.
生成的代理消息将没有指示其来源的标识信息，这意味着多个链接之间的代理将需要在未完成的请求上存储状态（实际上是一个仅NAT）。这种级别的状态存储可能是不需要的。
Mobile IPv6 does not experience this issue when supplying its own address, since ND messages are never forwarded on to the absent node (the Home Agent having sufficient information to respond itself).
移动IPv6在提供其自己的地址时不会遇到此问题，因为ND消息从未转发到缺席节点（归属代理具有足够的信息自行响应）。
Authorization from a router may still be required for Router Advertisement, and will be discussed in Section 4.2.
路由器广告可能仍然需要来自路由器的授权，将在第4.2节中讨论。
There are currently no existing secured Neighbor Discovery procedures for proxied addresses, and all Neighbor Advertisements from SEND nodes are required to have equal source and target addresses, and be signed by the transmitter (Section 7.4 of [RFC3971]).
目前没有针对代理地址的现有安全邻居发现程序，来自发送节点的所有邻居播发要求具有相同的源地址和目标地址，并由发送方签名（RFC3971第7.4节）。
Signatures over SEND messages are required to be applied on the CGA source address of the message, and there is no way of indicating that a message is proxied.
发送消息上的签名需要应用于消息的CGA源地址，并且无法指示消息已被代理。
Even if the message is able to be transmitted from the original owner, differences in link-layer addressing and options require modification by a proxy. If a message is signed with a CGA-based signature, the proxy is unable to regenerate a signature over the changed message as it lacks the keying material.
即使消息能够从原始所有者处传输，链路层地址和选项的差异也需要通过代理进行修改。如果消息使用基于CGA的签名进行签名，则代理无法在更改的消息上重新生成签名，因为它缺少密钥材料。
Therefore, a router wishing to provide proxy Neighbor Advertisement service cannot use existing SEND procedures on those messages.
因此，希望提供代理邻居播发服务的路由器不能对这些消息使用现有的发送过程。
A host may wish to establish a session with a device that is not on-link but is proxied. As a SEND host, it prefers to create Neighbor Cache Entries using secured procedures. Since SEND signatures cannot be applied to an existing proxy Neighbor Advertisement, it must accept non-SEND advertisements in order to receive proxy Neighbor Advertisements.
主机可能希望与不在链路上但被代理的设备建立会话。作为发送主机，它更喜欢使用安全过程创建邻居缓存项。由于发送签名无法应用于现有代理邻居播发，因此它必须接受非发送播发才能接收代理邻居播发。
Neighbor Cache spoofing of another node therefore becomes trivial, as any address may be proxy-advertised to the SEND node, and overridden only if the node is there to protect itself. When a node is present to defend itself, it may also be difficult for the solicitor determine the difference between a proxy-spoofing attack, and a situation where a proxied device returns to a link and overrides other proxy advertisers [RFC4861].
因此，对另一个节点的邻居缓存欺骗变得微不足道，因为任何地址都可能被代理播发到发送节点，并且只有当该节点在那里保护自身时才会被覆盖。当存在节点进行自我保护时，律师也可能难以确定代理欺骗攻击与代理设备返回链接并覆盖其他代理广告商的情况之间的区别[RFC4861]。
SEND defines one public-key and signature format for use with Cryptographically Generated Addresses (CGAs) [RFC3972]. CGAs are intended to tie address ownership to a particular public/private key pair.
SEND定义了一种公钥和签名格式，用于加密生成的地址（CGA）[RFC3972]。CGA旨在将地址所有权与特定的公钥/私钥对联系起来。
In SEND as defined today, Neighbor Discovery messages (including the IP Addresses from the IPv6 header) are signed with the same key used to generate the CGA. This means that message recipients have proof that the signer of the message owned the address.
在今天定义的SEND中，邻居发现消息（包括来自IPv6报头的IP地址）使用用于生成CGA的相同密钥进行签名。这意味着邮件收件人有证据证明邮件的签名者拥有该地址。
When a proxy replaces the message's source IPv6 address with its own CGA, the existing CGA option and RSA signature option would need to be replaced with ones that correspond to the CGA of the proxy. To be valid according to the SEND specification, the Target Address of the Neighbor Advertisement message would need to be replaced also to be equal to the Source Address [RFC3971].
当代理将消息的源IPv6地址替换为其自己的CGA时，需要将现有的CGA选项和RSA签名选项替换为与代理的CGA相对应的选项。要根据发送规范有效，还需要替换邻居播发消息的目标地址，使其等于源地址[RFC3971]。
Additional authorization information may be needed to prove that the proxy is indeed allowed to advertise for the target address, as is described in Section 4.
如第4节所述，可能需要额外的授权信息来证明代理确实被允许公布目标地址。
Where a proxy retains the original source address in a proxied message, existing security checks for SEND will fail, since fields within the message will be changed. In order to achieve secured proxy Neighbor Discovery in this case, extended authorization mechanisms may be needed for SEND.
当代理在代理消息中保留原始源地址时，现有的发送安全检查将失败，因为消息中的字段将被更改。在这种情况下，为了实现安全的代理邻居发现，发送可能需要扩展授权机制。
SEND provides mechanisms for extension of SEND to non-CGA-based authorization. Messages are available for Authorization Delegation Discovery, which is able to carry arbitrary PKIX/X.509 certificates [RFC5280].
SEND提供了将SEND扩展到非基于CGA的授权的机制。消息可用于授权委托发现，它能够携带任意PKIX/X.509证书[RFC5280]。
There is, however, no specification of keying information option formats analogous to the SEND CGA Option [RFC3971]. The existing option allows a host to verify message integrity by specifying a key and algorithm for digital signature, without providing authorization via mechanisms other than CGA ownership.
但是，没有类似于发送CGA选项[RFC3971]的键控信息选项格式规范。现有选项允许主机通过指定数字签名的密钥和算法来验证消息完整性，而无需通过CGA所有权以外的机制提供授权。
The digital signature in SEND is transported in the RSA Signature Option. As currently specified, the signature operation is performed over a CGA Message type, and allows for CGA verification. Updating the signature function to support non-CGA operations may be necessary.
发送中的数字签名在RSA签名选项中传输。按照当前的规定，签名操作在CGA消息类型上执行，并允许CGA验证。可能需要更新签名函数以支持非CGA操作。
Within SEND, more advanced functions such as routing may be authorized by certificate path verification using Authorization Delegation Discovery.
在SEND中，更高级的功能（如路由）可以通过使用授权委托发现的证书路径验证进行授权。
With non-CGA signatures and authentication, certificate contents for authorization may need to be determined, as outlined in Section 4.
对于非CGA签名和身份验证，可能需要确定授权的证书内容，如第4节所述。
While SEND provides for extensions to new non-CGA methods, existing SEND hosts may silently discard messages with unverifiable RSA signature options (Section 5.2.2 of [RFC3971]), if configured only to accept SEND messages. In cases where unsecured Neighbor Cache Entries are still accepted, messages from new algorithms will be treated as unsecured.
虽然SEND提供了对新的非CGA方法的扩展，但如果仅配置为接受SEND消息，则现有的发送主机可能会自动丢弃带有无法验证的RSA签名选项的消息（RFC3971的第5.2.2节）。在仍然接受不安全的邻居缓存项的情况下，来自新算法的消息将被视为不安全。
Initiation of proxy Neighbor Discovery also requires Duplicate Address Detection (DAD) checks of the address [RFC4862]. These DAD checks need to be performed by sending Neighbor Solicitations, from the unspecified source address, with the target being the proxied address.
代理邻居发现的启动还需要对地址进行重复地址检测（DAD）检查[RFC4862]。这些DAD检查需要通过从未指定的源地址发送邻居请求来执行，目标是代理地址。
In existing SEND procedures, the address that is used for CGA tests on DAD NS is the target address. A Proxy that originates this message while the proxied address owner is absent is unable to generate a CGA-based signature for this address and must undertake DAD with an unsecured NS. It may be possible that the proxy can ensure that responding NAs are secured though.
在现有的发送过程中，用于DAD NS上的CGA测试的地址是目标地址。当代理地址所有者不在时发起此消息的代理无法为此地址生成基于CGA的签名，并且必须使用不安全的NS进行DAD。但是，代理可能可以确保响应的NAs是安全的。
Where bridge-like ND proxy operations are being performed, DAD NSs may be copied from the original source, without modification (considering they have an unspecified source address and contain no link-layer address options) [RFC4389].
如果正在执行类似网桥的ND代理操作，则可以从原始源复制DAD NSs，无需修改（考虑到它们具有未指定的源地址且不包含链路层地址选项）[RFC4389]。
If non-CGA-based signatures are available, then the signature over the DAD NS doesn't need to have a CGA relationship to the Target Address, but authorization for address configuration needs to be shown using certificates.
如果可以使用非基于CGA的签名，则DAD NS上的签名不需要与目标地址具有CGA关系，但需要使用证书显示地址配置的授权。
In case there is a DAD collision between two SEND nodes on different interfaces of the proxy, it is possible that the proxy may not have the authority to modify the NA defending the address. In this case, the proxy still needs to modify the NA and pass it onto the other interfaces even if it will fail SEND verification on the receiving node.
如果代理的不同接口上的两个发送节点之间存在DAD冲突，则代理可能没有修改地址的权限。在这种情况下，代理仍然需要修改NA并将其传递到其他接口，即使它在接收节点上发送验证失败。
While Router Solicitations are protected in the same manner as Neighbor Solicitations, the security for Router Advertisements is mainly based on the use of certificates. Even though the mechanism for securing RAs is different, the problems that arise due to the modification of the L2 addresses are exactly the same: the proxy needs to have the right security material (e.g., certificate) to sign the RA messages after modification.
虽然路由器请求的保护方式与邻居请求相同，但路由器广告的安全性主要基于证书的使用。尽管保护RAs的机制不同，但由于修改L2地址而产生的问题是完全相同的：代理需要具有正确的安全材料（例如证书），以便在修改后对RA消息进行签名。
SEND nodes already have the concept of delegated authority through requiring external authorization of routers to perform their routing and advertisement roles. The authorization of these routers takes the form of delegation certificates.
发送节点通过要求路由器的外部授权来执行其路由和播发角色，已经具有委托权限的概念。这些路由器的授权采用授权证书的形式。
Proxy Neighbor Discovery requires a delegation of authority (on behalf of the absent address owner) to the proxier. Without this authority, other devices on the link have no reason to trust an advertiser.
代理邻居发现需要（代表缺席的地址所有者）将权限委托给代理。没有这个权限，链接上的其他设备就没有理由信任广告商。
For bridge-like proxies, it is assumed that there is no preexisting trust between the host owning the address and the proxy. Therefore, authority may necessarily be dynamic or based on topological roles within the network [RFC4389].
对于桥接式代理，假定拥有地址的主机和代理之间不存在预先存在的信任。因此，权限可能是动态的或基于网络中的拓扑角色[RFC4389]。
Existing trust relationships lend themselves to providing authority for proxying in two alternative ways.
现有的信任关系有助于以两种替代方式提供代理权限。
First, the SEND router authorization mechanisms described above provide delegation from the organization responsible for routing in an address domain to the certified routers. It may be argued that routers so certified may be trusted to provide service for nodes that form part of a link's address range, but are themselves absent. Devices which are proxies could either be granted the right to proxy by the network's router, or be implicitly allowed to proxy by virtue of being an authorized router.
首先，上面描述的发送路由器授权机制提供了从负责地址域中路由的组织到认证路由器的委托。有人可能会说，这样认证的路由器可以被信任为构成链路地址范围一部分但自身不存在的节点提供服务。作为代理的设备可以被网络的路由器授予代理权，或者由于是授权路由器而被隐式允许代理。
Second, where the proxied address is itself a CGA, the holder of the public and private keys is seen to be authoritative about the address's use. If this address owner was able to sign the proxier's address and public key information, it would be possible to identify that the proxy is known and trusted by the CGA address owner for proxy service. This method requires that the proxied address know or learn the proxy's address and public key, and that the certificate signed by the proxied node's is passed to the proxy, either while they share the same link, or at a later stage.
其次，当代理地址本身是CGA时，公钥和私钥的持有者被视为对地址的使用具有权威性。如果该地址所有者能够对代理服务器的地址和公钥信息进行签名，则可以确定代理服务器是CGA地址所有者已知的，并且是代理服务器服务的信任者。此方法要求代理地址知道或了解代理的地址和公钥，并在代理节点共享同一链接时或稍后将代理节点签名的证书传递给代理。
In both methods, the original address owner's advertisements need to override the proxy if it suddenly returns, and therefore timing and replay protection from such messages need to be carefully considered.
在这两种方法中，如果代理突然返回，原始地址所有者的广告需要覆盖代理，因此需要仔细考虑针对此类消息的定时和重播保护。
Mobile IPv6 has a security association between the Mobile Node and Home Agent. The Mobile Node sends a Binding Update to the Home Agent, to indicate that it is not at home. This implies that the
移动IPv6在移动节点和归属代理之间具有安全关联。移动节点向归属代理发送绑定更新，以指示它不在家。这意味着
Mobile Node wishes the Home Agent to begin proxy Neighbor Discovery operations for its home address(es).
移动节点希望归属代理开始其归属地址的代理邻居发现操作。
A secured Proxy Neighbor Advertisements proposal based on existing router trust would require no explicit authorization signaling between HA and MN to allow proxying. Hosts on the home link will believe proxied advertisements solely because they come from a trusted router.
基于现有路由器信任的安全代理邻居广告方案不需要HA和MN之间的明确授权信令来允许代理。主链接上的主机只会相信代理广告，因为它们来自受信任的路由器。
Where the home agent operates as a router without explicit trust to route from the advertising routing infrastructure (such as in a home, with a router managed by an ISP), more explicit proxying authorization may be required, as described in Section 4.2.
如果归属代理作为路由器运行，而不明确信任来自广告路由基础设施的路由（例如在家中，路由器由ISP管理），则可能需要更明确的代理授权，如第4.2节所述。
Where proxy Neighbor Discovery is delegated by the MN to the home agent, the MN needs to learn the public key for the Home Agent, so that it can generate a certificate authorizing the public/private key pair to be used in proxying. It may conceivably do this using Certificate Path Solicitations either over a home tunnel, when it is away from home, or during router discovery while still at home [RFC3971] [RFC3775].
当代理邻居发现由MN委托给归属代理时，MN需要学习归属代理的公钥，以便它能够生成一个证书，授权在代理中使用的公钥/私钥对。可以想象，它可以通过家庭隧道（当它不在家时）或在路由器发现期间（当它仍在家时）使用证书路径请求来实现这一点[RFC3971][RFC3775]。
When sending its Binding Update to the HA, the MN would need to provide a certificate containing the subject's (i.e., proxy HA's) public key and address, the issuer's (i.e., MN's) CGA and public key, and timestamps indicating when the authority began and when it ends. This certificate would need to be transmitted at binding time. Messaging or such an exchange mechanism would have to be developed.
当向HA发送其绑定更新时，MN需要提供一个证书，其中包含主体（即代理HA）的公钥和地址、颁发者（即MN）的CGA和公钥，以及指示授权何时开始和何时结束的时间戳。此证书需要在绑定时传输。必须开发消息传递或此类交换机制。
Specific cryptographic algorithms may help to allow trust between entities of a same group.
特定的加密算法可能有助于允许同一组的实体之间的信任。
This is the case, for example, with ring signature algorithms. These algorithms generate a signature using the private key of any member from the same group, but to verify the signature the public keys of all group members are required. Applied to SEND, the addresses are cryptographically generated using multiple public keys, and the Neighbor Discovery messages are signed with an RSA ring signature [RING]. (Note that the cryptographic algorithms that are the foundation for [RING] and other similar solutions are not widely accepted in the security community; additional research is needed before a Standards Track protocol could be developed.)
例如，环签名算法就是这样。这些算法使用来自同一组的任何成员的私钥生成签名，但要验证签名，需要所有组成员的公钥。应用于发送时，使用多个公钥加密生成地址，并使用RSA环签名[ring]对邻居发现消息进行签名。（注意，作为[RANK ]和其他类似解决方案的基础的密码算法在安全社区中没有被广泛接受；在制定标准跟踪协议之前需要进行更多的研究。）
Another approach is to use the 'Point-to-Point' link model.
另一种方法是使用“点对点”链接模型。
In this model, one prefix is provided per MN, and only an MN and the HA are on a same link. The consequence is the HA no longer needs to act as ND Proxy.
在该模型中，每个MN提供一个前缀，并且只有MN和HA位于同一链路上。其结果是，医管局不再需要充当ND代理。
One way to design such a solution is to use virtual interfaces, on the MN and the HA, and a virtual link between them. Addresses generated on the virtual interfaces will only be advertised on the virtual link. For Mobile IPv6, this results in a virtual Home Network where the MN will never come back.
设计这种解决方案的一种方法是在MN和HA上使用虚拟接口，以及它们之间的虚拟链接。在虚拟接口上生成的地址将仅在虚拟链路上公布。对于移动IPv6，这将导致虚拟家庭网络中的MN永远不会回来。
In link-extension environments, the role of a proxy is more explicitly separated from that of a router. In SEND, routers may expect to be authorized by the routing infrastructure to advertise and may provide this authority to hosts in order to allow them to change forwarding state.
在链路扩展环境中，代理的角色与路由器的角色更明确地分开。在发送中，路由器可能期望得到路由基础设施的授权以进行广告，并可能向主机提供此权限，以便允许它们更改转发状态。
Proxies are not part of the traditional infrastructure of the Internet, and hosts or routers may not have an explicit reason to trust them, except that they can forward packets to regions where otherwise those hosts or routers could not reach.
代理不是互联网传统基础设施的一部分，主机或路由器可能没有明确的理由信任它们，除非它们可以将数据包转发到那些主机或路由器无法到达的区域。
If a proxy can convince a device that it should be trusted to perform proxying function, it may require that device to vouch for its operation in dealing with other devices. It may do this by receiving a certificate, signed by the originating device that the proxy is believed capable of proxying under certain circumstances.
如果代理可以使设备相信它应该被信任来执行代理功能，那么它可能需要该设备证明它在处理其他设备时的操作。它可以通过接收由发起设备签名的证书来实现这一点，该证书被认为在某些情况下该代理能够代理。
This allows nodes receiving proxied Neighbor Discovery packets to quickly check if the proxy is authorized for the operation. There are several bases for such trust, and requirements in proxied environments, which are discussed below.
这允许接收代理邻居发现数据包的节点快速检查代理是否被授权进行操作。这种信任有几个基础，代理环境中的需求将在下面讨论。
Routers may be advertising on networks without any explicit authorization, and SEND hosts will register these routers if there are no other options [RFC3971]. While proxies may similarly attempt to advertise without authority, this provides no security for the routing infrastructure. Any device can be setup as a SEND proxy/ router so long as it signs its own ND messages from its CGA.
路由器可能在没有任何明确授权的情况下在网络上发布广告，如果没有其他选项，发送主机将注册这些路由器[RFC3971]。虽然代理也可能尝试在没有授权的情况下发布，但这并不能为路由基础结构提供安全性。任何设备都可以设置为发送代理/路由器，只要它从其CGA签署自己的ND消息。
This may not help in the case that a proxy attempts to update Neighbor Cache Entries for a SEND node that moves between links, since the SEND node's authority to advertise its own CGA address would not be superseded by a proxy with no credentials.
如果代理试图更新在链路之间移动的发送节点的邻居缓存项，这可能没有帮助，因为发送节点公布其自身CGA地址的权限不会被没有凭据的代理所取代。
Proxies may have multiple levels of nesting, which allow the network to connect between non-adjacent segments.
代理可以有多个嵌套级别，允许网络在非相邻段之间连接。
In this case, authority delegated at one point will have to be redelegated (possibly in a diluted form) to proxies further away from the origin of the trust.
在这种情况下，在某一点上授予的权限必须重新授予（可能以稀释形式）远离信托起源的代理人。
Trust Proxy A Proxy B Distant Origin - T Node - D
信任代理A代理B远程源-T节点-D
+-----+ +-----+
| | | |
+-----+ +-----+ +-----+ +-----+
| | | | | |
------------| |------------| |----------
| | | |
+-----+ +-----+
==========> ==============> ==========>
Deleg(A,T) Deleg(B,Deleg(A,T)) Advertise(D, Deleg(B,
Deleg(A,T))
+-----+ +-----+
| | | |
+-----+ +-----+ +-----+ +-----+
| | | | | |
------------| |------------| |----------
| | | |
+-----+ +-----+
==========> ==============> ==========>
Deleg(A,T) Deleg(B,Deleg(A,T)) Advertise(D, Deleg(B,
Deleg(A,T))
Figure 4
图4
As shown in Figure 4, the Proxy A needs to redelegate authority to proxy for T to Proxy B; this allows it to proxy advertisements that target T back to D.
如图4所示，代理A需要将T的代理权限重新委派给代理B；这允许它将以T为目标的广告代理回D。
Where it is possible for the proxy to pre-establish trust with the routing infrastructure, or at least to the local router, it may be possible to authorize proxying as a function of routing within the subnet. The router or CA may then be able to certify proxying for only a subset of the prefixes for which it is itself certified.
如果代理可以预先与路由基础设施建立信任，或者至少与本地路由器建立信任，则可以授权代理作为子网内路由的一项功能。然后，路由器或CA可以仅为其自身已认证的前缀子集认证代理。
If a router or CA provides certification for a particular prefix, it may be able to indicate that only proxying is supported, so that Neighbor Cache Entries of routers connected to Internet infrastructure are never overridden by the proxy, if the router is present on a segment.
如果路由器或CA为特定前缀提供认证，则它可能能够指示仅支持代理，因此，如果路由器位于某个段上，则连接到Internet基础设施的路由器的邻居缓存项永远不会被代理覆盖。
Hosts understanding such certificates may allow authorized proxies and routers to override the host when assuming proxy roles, if the host is absent.
如果主机不在，理解此类证书的主机可能允许授权代理和路由器在担任代理角色时覆盖主机。
Proxy certificate signing could be done either dynamically (requiring exchanges of identity and authorization information) or statically when the network is set up.
代理证书签名可以动态完成（需要交换身份和授权信息），也可以在网络建立时静态完成。
Where no trust tie exists between the authority that provides the routing infrastructure and the provider of bridging and proxying services, it may still be possible for SEND hosts to trust the bridging provider to authorize proxying operations.
如果提供路由基础设施的机构与桥接和代理服务的提供商之间不存在信任关系，则发送主机仍可以信任桥接提供商来授权代理操作。
SEND itself requires that routers be able to show authorization, but doesn't require routers to have a single trusted root.
发送本身要求路由器能够显示授权，但不要求路由器具有单个受信任的根。
A local bridging/proxying authority trust delegation may be possible. It would be possible for this authority to pass out local-use certificates, allowing proxying on a specific subnet or subnets, with a separate authorization chain to those subnets for the routers with Internet access.
可以进行本地桥接/代理权限信任委托。该机构可以分发本地使用证书，允许代理特定子网或子网，并为具有Internet访问权限的路由器提供到这些子网的单独授权链。
This would require little modification to SEND, other than the addition of router-based proxy authority (as in Section 4.2.4), and proxies would in effect be treated as routers by SEND hosts [RFC3971]. Distribution of keying and trust material for the initial bootstrap of proxies would not be provided though (and may be static).
除添加基于路由器的代理权限（如第4.2.4节所述）外，发送时几乎不需要修改，并且代理实际上被发送主机视为路由器[RFC3971]。但是，不会提供代理初始引导的密钥和信任材料的分发（可能是静态的）。
Within small domains, key management and distribution may be a tractable problem, so long as these operations are simple enough to perform.
在小型域中，密钥管理和分发可能是一个容易处理的问题，只要这些操作足够简单即可执行。
Since these domains may be small, it may be necessary to provide certificate chains for trust anchors that weren't requested in Certificate Path Solicitations, if the proxy doesn't have a trust chain to any requested trust anchor.
由于这些域可能很小，如果代理没有到任何请求的信任锚点的信任链，则可能需要为证书路径请求中未请求的信任锚点提供证书链。
This is akin to 'suggesting' an appropriate trusted root. It may allow for user action in allowing trust extension when visiting domains without ties to a global keying infrastructure. In this case, the trust chain would have to start with a self-signed certificate from the original CA.
这类似于“建议”一个适当的可信根。它可以允许用户在访问域时执行允许信任扩展的操作，而无需与全局键控基础设施建立联系。在这种情况下，信任链必须从原始CA的自签名证书开始。
Unlike Mobile IPv6, for bridge-like proxied networks, there is no existing security association upon which to transport proxying authorization credentials.
与移动IPv6不同，对于类似网桥的代理网络，不存在用于传输代理授权凭据的现有安全关联。
Thus, proxies need to convince Neighbors to delegate proxy authority to them, in order to proxy-advertise to nodes on different segments. It will be difficult without additional information to distinguish between legitimate proxies and devices that have no need or right to proxy (and may want to make two network segments appear connected).
因此，代理需要说服邻居将代理权限委托给他们，以便向不同网段上的节点进行代理播发。如果没有额外的信息，就很难区分合法代理和不需要代理或无权代理（并且可能希望使两个网段看起来是连接的）的设备。
When proxy advertising, proxies must not only identify that proxying needs to occur, but provide proof that they are allowed to do so, so that SEND Neighbor Cache Entries may be updated. Unless the authorization to update such entries is tied to address ownership proofs from the proxied host or the verifiable routing infrastructure, spoofing may occur.
代理播发时，代理不仅必须确定需要进行代理，而且必须提供允许代理的证据，以便更新发送邻居缓存项。除非更新这些条目的授权与来自代理主机或可验证路由基础设施的地址所有权证明相关联，否则可能会发生欺骗。
When a host received a proxied Neighbor advertisement, it would be necessary to check authorization in the same way that authorization delegation discovery is performed in SEND.
当主机收到代理邻居播发时，有必要以与在发送中执行授权委托发现相同的方式检查授权。
Otherwise, certificate transport will be required to exchange authorization between proxied nodes and proxies.
否则，将需要证书传输来在代理节点和代理之间交换授权。
Proxies would have to be able to delegate this authorization to downstream proxies, as described in Section 4.2.3.
代理人必须能够将该授权委托给下游代理人，如第4.2.3节所述。
Where the original Neighbor Discovery message is unsecured, there is an argument for not providing secured proxy service for that node.
在原始邻居发现消息不安全的情况下，存在不为该节点提供安全代理服务的理由。
In both the Mobile IPv6 and extended networks cases, the node may arrive back at the network and require other hosts to map their existing Neighbor Cache Entry to the node's link-layer address. The re-arriving node's overriding of link-layer address mappings will occur without SEND in this case.
在移动IPv6和扩展网络两种情况下，节点可能会返回网络，并要求其他主机将其现有邻居缓存条目映射到节点的链路层地址。在这种情况下，重新到达的节点覆盖链路层地址映射将在不发送的情况下发生。
It is notable that without SEND protection any node may spoof the arrival, and effectively steal service across an extended network. This is the same as in the non-proxy case, and is not made significantly worse by the proxy's presence (although the identity of the attacker may be masked if source addresses are being replaced).
值得注意的是，在没有发送保护的情况下，任何节点都可能欺骗到达，并在扩展网络中有效地窃取服务。这与非代理情况下的情况相同，并且代理的存在不会使情况变得更糟（尽管如果替换源地址，攻击者的身份可能会被掩盖）。
If signatures over the proxied messages were to be used, re-arrival and override of the Neighbor Cache Entries would have to be allowed, so the signatures would indicate that at least the proxy wasn't spoofing (even if the original sender was).
如果要使用代理消息上的签名，则必须允许重新到达和覆盖邻居缓存项，因此签名将表明至少代理没有欺骗（即使原始发件人是）。
For non-SEND routers, though, it may be possible for secured proxies to send signed router advertisement messages, in order to ensure that routers aren't spoofed, and subsequently switched to different parts of the extended network.
不过，对于非发送路由器，安全代理可能会发送签名路由器广告消息，以确保路由器不会被欺骗，并随后切换到扩展网络的不同部分。
This has problems in that the origin is again unsecured, and any node on the network could spoof router advertisement for an unsecured address. These spoofed messages may become almost indistinguishable (except for the non-CGA origin address) from unspoofed messages from SEND routers.
这有一个问题，即源地址再次是不安全的，网络上的任何节点都可能欺骗路由器广告以获得不安全的地址。这些伪造消息可能与来自发送路由器的未伪造消息几乎无法区分（非CGA源地址除外）。
Given these complexities, the simplest method is to allow unsecured devices to be spoofed from any port on the network, as is the case today.
鉴于这些复杂性，最简单的方法是允许从网络上的任何端口欺骗不安全的设备，就像今天的情况一样。
All the previous sections of this document focused on the case where two nodes defend the same address (i.e., the node and the proxy). However, there are also cases where two or more nodes are defending the same address. This is at least the case for:
本文档前面的所有部分都关注两个节点维护相同地址（即节点和代理）的情况。但是，也存在两个或多个节点在保护同一地址的情况。至少在以下情况下是这样的：
o Nodes having the same address, as the Mobile Access Gateway's (MAG's) ingress link-local address in Proxy Mobile IPv6 (PMIPv6) [RFC5213].
o 与代理移动IPv6（PMIPv6）中的移动接入网关（MAG）入口链路本地地址具有相同地址的节点[RFC5213]。
o Nodes having a common anycast address [RFC4291].
o 具有公共选播地址[RFC4291]的节点。
The problem statement, described previously in this document, applies for these cases, and the issues are the same from a signaling point of view.
本文档前面描述的问题陈述适用于这些情况，从信令的角度来看，问题是相同的。
Multicast addresses are not mentioned here because Neighbor Discovery Protocol is not used for them.
这里没有提到多播地址，因为它们不使用邻居发现协议。
In the first case, [RFC5213] assumes that the security material used by SEND (i.e., public-private key pair) is shared between all the MAGs. For the second case, there is no solution today. But, in the same way, it should be possible to assume that the nodes having a common anycast address could also share the security material.
在第一种情况下，[RFC5213]假设SEND使用的安全材料（即，公私密钥对）在所有MAG之间共享。对于第二种情况，目前没有解决方案。但是，以同样的方式，应该可以假设具有公共选播地址的节点也可以共享安全材料。
It is important to notice that when many nodes defending the same address are not in the same administrative domain (e.g., MAGs in different administrative domains but in the same PMIPv6 domain [RFC5213]), sharing the security material used by SEND may raise a security issue.
需要注意的是，当维护同一地址的多个节点不在同一管理域中时（例如，不同管理域中的MAG但在同一PMIPv6域[RFC5213]），共享SEND使用的安全材料可能会引发安全问题。
Router-based authorization for Secured Proxy ND may occur without the knowledge or consent of a device. It is susceptible to the 'Good Router Goes Bad' attack described in [RFC3756].
基于路由器的安全代理ND授权可能在设备不知情或不同意的情况下发生。它容易受到[RFC3756]中描述的“好路由器坏掉”攻击。
Certificate delegation relies upon transfer of the new credentials to the proxying HA in order to undertake ND proxy on its behalf. Since the binding cannot come into effect until DAD has taken place, the delegation of the proxying authority necessarily predates the return of the Binding Ack, as described in [RFC3775]. In the case above described, the home tunnel that comes into creation as part of the binding process may be required for transport of Certificate Path Solicitations or Advertisements [RFC3971]. This constitutes a potential chicken-and-egg problem. Either modifications to initial home binding semantics or certificate transport are required. This may be trivial if certificates are sent in the clear between the MN's Care-of Address (CoA) and the HA without being tunneled.
证书授权依赖于将新凭证转让给代理HA，以便代表其进行ND代理。由于在DAD发生之前绑定无法生效，代理权限的委托必然早于绑定Ack的返回，如[RFC3775]中所述。在上述情况下，可能需要作为绑定过程的一部分创建的主隧道来传输证书路径请求或广告[RFC3971]。这构成了一个潜在的鸡和蛋的问题。需要修改初始主绑定语义或证书传输。如果证书在MN的转交地址（CoA）和HA之间以明文形式发送，而不进行隧道传输，则这可能是微不足道的。
All of the presented methods rely on accurate timekeeping on the receiver nodes of Neighbor Discovery Timestamp Options.
所有提出的方法都依赖于邻居发现时间戳选项的接收器节点上的精确计时。
For router-authorized proxy ND, a Neighbor may not know that a particular ND message is replayed from the time when the proxied host was still on-link, since the message's timestamp falls within the valid timing window. Where the router advertises its secured proxy NA, a subsequent replay of the old message will override the NCE created by the proxy.
对于经路由器授权的代理ND，邻居可能不知道从被代理主机仍在链路上的时间开始重播特定ND消息，因为消息的时间戳落在有效的定时窗口内。当路由器播发其安全代理NA时，旧消息的后续重播将覆盖代理创建的NCE。
Creating the NCE in this way, without reference to accurate subsequent timing, may only be done once. Otherwise, the receiver will notice that the timestamp of the advertisement is old or doesn't match.
以这种方式创建NCE，而不参考准确的后续计时，只能执行一次。否则，接收者将注意到广告的时间戳是旧的或不匹配的。
One way of creating a sequence of replayable messages that have timestamps likely to be accepted is to pretend to do an unsecured DAD on the address each second while the MN is at home. The attacker saves each DAD defense in a sequence. The granularity of SEND timestamp matching is around one second, so the attacker has a set of SEND NAs to advertise, starting at a particular timestamp, and valid for as many seconds as the original NA gathering occurred.
创建具有可能被接受的时间戳的可重放消息序列的一种方法是，当MN在家时，假装每秒对地址执行不安全的DAD。攻击者按顺序保存每个DAD防御。发送时间戳匹配的粒度约为1秒，因此攻击者有一组发送NAs进行广告，从特定时间戳开始，有效期与原始NA收集发生的时间相同。
This sequence may then be played against any host that doesn't have a timestamp history for that MN, by tracking the number of seconds elapsed since the initial transmission of the replayed NA to that victim, and replaying the appropriate cached NA.
然后，可以对没有该MN的时间戳历史的任何主机播放该序列，方法是跟踪从重播的NA初始传输到该受害者以来经过的秒数，并重播适当的缓存NA。
Where certificate-based authorization of ND proxy is in use, the origination/starting timestamp of the delegated authority may be used to override a replayed (non-proxy) SEND NA, while also ensuring that the Proxy NA's timestamp (provided by the proxy) is fresh. A returning MN would advertise a more recent timestamp than the delegated authority and thus override it. This method is therefore not subject to the above attack, since the proxy advertisement's certificate will have a timestamp greater than any replayed messages, preventing it from being overridden.
在使用基于证书的ND代理授权的情况下，可使用委托权限的发起/开始时间戳覆盖重播（非代理）发送NA，同时还确保代理NA的时间戳（由代理提供）是新的。返回的MN将公布比委托权限更近的时间戳，从而覆盖它。因此，此方法不会受到上述攻击，因为代理播发的证书的时间戳将大于任何重播消息，从而防止其被覆盖。
James Kempf and Dave Thaler particularly contributed to work on this document. Contributions to discussion on this topic helped to develop this document. The authors would also like to thank Jari Arkko, Vijay Devarapalli, Mohan Parthasarathy, Marcelo Bagnulo, Julien Laganier, Tony Cheneau, Michaela Vanderveen, Sean Shen, and Sheng Jiang for their comments and suggestions.
詹姆斯·肯普夫（James Kempf）和戴夫·泰勒（Dave Thaler）特别对本文件的编写做出了贡献。对该主题讨论的贡献有助于编写本文件。作者还要感谢贾里·阿尔科、维杰·德瓦拉帕利、莫汉·帕塔萨拉蒂、马塞洛·巴格努洛、朱利安·拉盖尼尔、托尼·切诺、迈克尔·范德尔文、肖恩·申和盛江的评论和建议。
Jean-Michel Combes is partly funded by MobiSEND, a research project supported by the French 'National Research Agency' (ANR).
Jean-Michel Combes的部分资金来自MobiSEND，这是一个由法国“国家研究机构”（ANR）支持的研究项目。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，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月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]Kaufman，C.，“互联网密钥交换（IKEv2）协议”，RFC43062005年12月。
[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月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5213]Gundavelli，S.，Leung，K.，Devarapalli，V.，Chowdhury，K.，和B.Patil，“代理移动IPv6”，RFC 5213，2008年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008.
[RFC5380]Soliman，H.，Castelluccia，C.，ElMalki，K.，和L.Bellier，“分层移动IPv6（HMIPv6）移动性管理”，RFC 53802008年10月。
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
[RFC5568]Koodli，R.，“移动IPv6快速切换”，RFC 5568，2009年7月。
[RING] Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying using Multi-Key Cryptographically Generated Addresses (MCGAs)", Work in Progress, August 2005.
[RING]Kempf，J.和C.Gentry，“使用多密钥加密生成地址（MCGAs）的安全IPv6地址代理”，正在进行的工作，2005年8月。
Authors' Addresses
作者地址
Jean-Michel Combes France Telecom Orange 38 rue du General Leclerc 92794 Issy-les-Moulineaux Cedex 9 France
Jean-Michel Combes France Telecom Orange Leclerc将军街38号92794 Issy les Moulineaux Cedex 9法国
EMail: jeanmichel.combes@orange-ftgroup.com
EMail: jeanmichel.combes@orange-ftgroup.com
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal QC Canada
苏雷什·克里希南·爱立信德卡里大道8400号。加拿大皇家山镇
EMail: Suresh.Krishnan@ericsson.com
EMail: Suresh.Krishnan@ericsson.com
Greg Daley Netstar Logicalis Level 6/616 St Kilda Road Melbourne, Victoria 3004 Australia
澳大利亚维多利亚州墨尔本市圣基尔达路616号6层格雷格·戴利·Netstar Logicalis 3004
Phone: +61 401 772 770
EMail: hoskuld@hotmail.com
Phone: +61 401 772 770
EMail: hoskuld@hotmail.com