Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 7219 A. Garcia-Martinez
Category: Standards Track UC3M
ISSN: 2070-1721 May 2014
Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 7219 A. Garcia-Martinez
Category: Standards Track UC3M
ISSN: 2070-1721 May 2014
SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)
安全邻居发现（发送）源地址验证改进（SAVI）
Abstract
摘要
This memo specifies SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI), a mechanism to provide source address validation using the SEND protocol. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of IPv6 source addresses.
此备忘录指定了安全邻居发现（SEND）源地址验证改进（SAVI），这是一种使用SEND协议提供源地址验证的机制。所提出的机制补充了入口过滤技术，以便在控制IPv6源地址时提供更精细的粒度。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc7219.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7219.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Background on SEND SAVI . . . . . . . . . . . . . . . . . . . 4
2.1. Address Validation Scope . . . . . . . . . . . . . . . . 4
2.2. Binding Creation for SEND SAVI . . . . . . . . . . . . . 4
2.3. SEND SAVI Protection Perimeter . . . . . . . . . . . . . 7
2.4. Special Cases . . . . . . . . . . . . . . . . . . . . . . 9
3. SEND SAVI Specification . . . . . . . . . . . . . . . . . . . 11
3.1. SEND SAVI Data Structures . . . . . . . . . . . . . . . . 11
3.2. SEND SAVI Device Configuration . . . . . . . . . . . . . 12
3.3. Traffic Processing . . . . . . . . . . . . . . . . . . . 13
3.3.1. Transit Traffic Processing . . . . . . . . . . . . . 13
3.3.2. Local Traffic Processing . . . . . . . . . . . . . . 13
3.4. SEND SAVI Port Configuration Guidelines . . . . . . . . . 27
3.5. VLAN Support . . . . . . . . . . . . . . . . . . . . . . 28
3.6. Protocol Constants . . . . . . . . . . . . . . . . . . . 28
4. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 29
4.1. Change of the Attachment Point of a Host . . . . . . . . 29
4.1.1. Moving to a Port of the Same Switch . . . . . . . . . 29
4.1.2. Moving to a Port of a Different Switch . . . . . . . 30
4.2. Attack of a Malicious Host . . . . . . . . . . . . . . . 31
4.2.1. M Attaches to the Same Switch as the Victim's Switch 31
4.2.2. M Attaches to a Different Switch to the Victim's
Switch . . . . . . . . . . . . . . . . . . . . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
5.1. Protection against Replay Attacks . . . . . . . . . . . . 33
5.2. Protection against Denial-of-Service Attacks . . . . . . 34
5.3. Considerations on the Deployment Model for Trust Anchors 36
5.4. Residual Threats . . . . . . . . . . . . . . . . . . . . 36
5.5. Privacy Considerations . . . . . . . . . . . . . . . . . 37
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.1. Normative References . . . . . . . . . . . . . . . . . . 37
7.2. Informative References . . . . . . . . . . . . . . . . . 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Background on SEND SAVI . . . . . . . . . . . . . . . . . . . 4
2.1. Address Validation Scope . . . . . . . . . . . . . . . . 4
2.2. Binding Creation for SEND SAVI . . . . . . . . . . . . . 4
2.3. SEND SAVI Protection Perimeter . . . . . . . . . . . . . 7
2.4. Special Cases . . . . . . . . . . . . . . . . . . . . . . 9
3. SEND SAVI Specification . . . . . . . . . . . . . . . . . . . 11
3.1. SEND SAVI Data Structures . . . . . . . . . . . . . . . . 11
3.2. SEND SAVI Device Configuration . . . . . . . . . . . . . 12
3.3. Traffic Processing . . . . . . . . . . . . . . . . . . . 13
3.3.1. Transit Traffic Processing . . . . . . . . . . . . . 13
3.3.2. Local Traffic Processing . . . . . . . . . . . . . . 13
3.4. SEND SAVI Port Configuration Guidelines . . . . . . . . . 27
3.5. VLAN Support . . . . . . . . . . . . . . . . . . . . . . 28
3.6. Protocol Constants . . . . . . . . . . . . . . . . . . . 28
4. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 29
4.1. Change of the Attachment Point of a Host . . . . . . . . 29
4.1.1. Moving to a Port of the Same Switch . . . . . . . . . 29
4.1.2. Moving to a Port of a Different Switch . . . . . . . 30
4.2. Attack of a Malicious Host . . . . . . . . . . . . . . . 31
4.2.1. M Attaches to the Same Switch as the Victim's Switch 31
4.2.2. M Attaches to a Different Switch to the Victim's
Switch . . . . . . . . . . . . . . . . . . . . . . . 32
5. Security Considerations . . . . . . . . . . . . . . . . . . . 33
5.1. Protection against Replay Attacks . . . . . . . . . . . . 33
5.2. Protection against Denial-of-Service Attacks . . . . . . 34
5.3. Considerations on the Deployment Model for Trust Anchors 36
5.4. Residual Threats . . . . . . . . . . . . . . . . . . . . 36
5.5. Privacy Considerations . . . . . . . . . . . . . . . . . 37
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.1. Normative References . . . . . . . . . . . . . . . . . . 37
7.2. Informative References . . . . . . . . . . . . . . . . . 38
This memo specifies SEND SAVI, a mechanism to provide source address validation for IPv6 networks using the SEND protocol [RFC3971]. The proposed mechanism complements ingress filtering techniques to provide a finer granularity on the control of the source addresses used.
此备忘录指定SEND SAVI，这是一种使用发送协议[RFC3971]为IPv6网络提供源地址验证的机制。所提出的机制补充了入口过滤技术，以便在控制所使用的源地址时提供更精细的粒度。
SEND SAVI uses the DAD_NSOL (Duplicate Address Detection Neighbor SOLicitation) and the DAD_NADV (DAD Neighbor ADVertisement) messages defined in [RFC4862] and the NUD_NSOL (Neighbor Unreachability Detection Neighbor SOLicitation) and NUD_NADV (NUD Neighbor ADVertisement) messages defined in [RFC4861] to validate the address ownership claim of a node. Using the information contained in these messages, host IPv6 addresses are associated to switch ports, so that data packets will be validated by checking for consistency in this binding, as described in [RFC7039]. In addition, SEND SAVI prevents hosts from generating packets containing off-link IPv6 source addresses.
SEND SAVI使用[RFC4862]中定义的DAD_NSL（重复地址检测邻居请求）和DAD_NADV（DAD邻居播发）消息以及[RFC4861]中定义的NUD_NSL（邻居不可达检测邻居请求）和NUD_NADV（NUD邻居播发）消息验证节点的地址所有权声明。使用这些消息中包含的信息，主机IPv6地址与交换机端口相关联，以便通过检查此绑定中的一致性来验证数据包，如[RFC7039]中所述。此外，SEND SAVI防止主机生成包含脱离链路IPv6源地址的数据包。
Scalability of a distributed SAVI system comprising multiple SEND SAVI devices is preserved by means of a deployment scenario in which SEND SAVI devices form a "protection perimeter". In this deployment scenario, the distributed SAVI system only validates the packets when they ingress to the protection perimeter, not in every SEND SAVI device traversed.
包括多个发送SAVI设备的分布式SAVI系统的可伸缩性通过部署场景得以保持，其中发送SAVI设备形成“保护周界”。在此部署场景中，分布式SAVI系统仅在数据包进入保护周界时验证数据包，而不是在每个经过的发送SAVI设备中验证数据包。
The SEND SAVI specification, as defined in this document, is limited to links and prefixes in which every IPv6 host and every IPv6 router uses the SEND protocol [RFC3971] to protect the exchange of Neighbor Discovery information. If the SEND protocol is not used, we can deploy other SAVI solutions relying on monitoring different address configuration mechanisms to prove address ownership. For example, FCFS (First-Come, First-Served) SAVI [RFC6620] can be used by nodes locally configuring IPv6 addresses by means of the Stateless Address Autoconfiguration mechanism [RFC4862].
本文档中定义的发送SAVI规范仅限于每个IPv6主机和每个IPv6路由器使用发送协议[RFC3971]来保护邻居发现信息交换的链路和前缀。如果不使用发送协议，我们可以部署其他SAVI解决方案，依靠监视不同的地址配置机制来证明地址所有权。例如，FCFS（先到先得）SAVI[RFC6620]可由通过无状态地址自动配置机制[RFC4862]本地配置IPv6地址的节点使用。
SEND SAVI is designed to be deployed in SEND networks with as few changes to the deployed implementations as possible. In particular, SEND SAVI does not require any changes in the nodes whose source address is to be verified. This is because verification solely relies in the usage of already available protocols. Therefore, SEND SAVI neither defines a new protocol nor defines any new message on existing protocols, nor does it require that a host or router use an existing protocol message in a different way.
SEND SAVI设计用于在发送网络中部署，对部署的实现进行尽可能少的更改。特别是，SEND SAVI不需要对其源地址进行验证的节点进行任何更改。这是因为验证仅依赖于使用已有的协议。因此，SEND SAVI既不定义新协议，也不在现有协议上定义任何新消息，也不要求主机或路由器以不同的方式使用现有协议消息。
An overview of the general framework about Source Address Validation Improvement is presented in [RFC7039].
[RFC7039]概述了源地址验证改进的一般框架。
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]中所述进行解释。
The application scenario of SEND SAVI is limited to the local link. This means that the goal of SEND SAVI is to verify that the source addresses of the packets generated by the nodes attached to the local link have not been spoofed and that only legitimate routers generate packets with off-link IPv6 source addresses.
SEND SAVI的应用场景仅限于本地链路。这意味着SEND SAVI的目标是验证连接到本地链路的节点生成的数据包的源地址没有被欺骗，并且只有合法的路由器生成具有脱离链路IPv6源地址的数据包。
In a link, there usually are hosts and routers attached. Hosts generate packets with their own addresses as the source address. This is called "local traffic". Routers may send packets containing a source address other than their own, since they can forward packets generated by other hosts (usually located in a different link). This is the so-called transit traffic.
在链路中，通常连接有主机和路由器。主机以其自己的地址作为源地址生成数据包。这被称为“本地交通”。路由器可以发送包含其自身地址以外的源地址的数据包，因为它们可以转发由其他主机（通常位于不同的链路）生成的数据包。这就是所谓的过境交通。
SEND SAVI allows the validation of the source address of the local traffic, i.e., it allows verification that the source addresses of the packets generated by the nodes attached to the local link have not been spoofed. SEND SAVI also provides means to prevent hosts from generating packets with source addresses derived from off-link prefixes. However, SEND SAVI does not provide the means to verify if a given router is actually authorized to forward packets containing a particular off-link source address. Other techniques, like ingress filtering [RFC2827], are recommended to validate transit traffic.
SEND SAVI允许验证本地通信量的源地址，即，它允许验证连接到本地链路的节点生成的数据包的源地址没有被欺骗。SEND-SAVI还提供了防止主机生成源地址来自非链接前缀的数据包的方法。然而，SEND SAVI不提供验证给定路由器是否实际被授权转发包含特定断开链路源地址的数据包的方法。建议使用其他技术（如入口过滤[RFC2827]）来验证过境流量。
SEND SAVI devices filter packets according to bindings between a layer-2 anchor (the binding anchor) and an IPv6 address. These bindings should allow legitimate nodes to use the bounded IPv6 address as source address and prevent illegitimate nodes from doing so.
发送SAVI设备根据第2层锚（绑定锚）和IPv6地址之间的绑定过滤数据包。这些绑定应允许合法节点使用绑定的IPv6地址作为源地址，并防止非法节点这样做。
Any SAVI solution is not stronger than the binding anchor it uses. If the binding anchor is easily spoofable (e.g., a Media Access Control (MAC) address), then the resulting solution will be weak. The treatment of non-compliant packets needs to be tuned accordingly. In particular, if the binding anchor is easily spoofable and the SEND SAVI device is configured to drop non-compliant packets, then the usage of SEND SAVI may open a new vector of Denial-of-Service (DoS)
任何SAVI解决方案都不比它使用的绑定锚强。如果绑定锚很容易伪造（例如，媒体访问控制（MAC）地址），那么最终的解决方案将很弱。需要相应地调整不兼容数据包的处理。特别是，如果绑定锚很容易被欺骗，并且发送SAVI设备被配置为丢弃不兼容的分组，那么发送SAVI的使用可能会打开拒绝服务（DoS）的新载体
attacks, based on spoofed binding anchors. For that reason, implementations of this specification use switch ports as their binding anchors. Other forms of binding anchors are out of the scope of this specification, and proper analysis of the implications of using them should be performed before their usage.
基于伪造绑定锚的攻击。因此，本规范的实现使用交换机端口作为其绑定锚。其他形式的绑定锚不在本规范的范围内，在使用之前，应对使用它们的含义进行适当的分析。
SEND [RFC3971] provides tools to assure that a Neighbor Discovery (ND) message containing a Cryptographically Generated Address (CGA) [RFC3972] option and signed by an RSA option has been generated by the legitimate owner of the CGA IPv6 address.
SEND[RFC3971]提供了一些工具，以确保包含加密生成地址（CGA）[RFC3972]选项并由RSA选项签名的邻居发现（ND）消息已由CGA IPv6地址的合法所有者生成。
SEND SAVI uses SEND-validated messages to create bindings between the CGA and the port of the SEND SAVI device from which it is reasonable to receive packets with the CGA as the source address. The events that trigger the binding creation process in a SEND SAVI device are:
SEND SAVI使用SEND validated messages在CGA和SEND SAVI设备的端口之间创建绑定，从该端口接收以CGA作为源地址的数据包是合理的。在发送SAVI设备中触发绑定创建过程的事件有：
o The reception of a DAD_NSOL message, indicating the attempt of a node to configure an address. This may occur when a node configures an address for the first time or after being idle for some time or when the node has changed the physical attachment point to the layer-2 infrastructure.
o 接收到一条DAD\u NSOL报文，表示节点试图配置地址。当节点第一次配置地址或空闲一段时间后，或者当节点将物理连接点更改为第2层基础结构时，可能会发生这种情况。
o The reception of any other packet (including data packets) with a source address for which no binding exists. This may occur if DAD_NSOL messages were lost, a node has changed the physical attachment point to the layer-2 infrastructure without issuing a DAD_NSOL message, a SAVI device loses a binding (for example, due to a restart), or the link topology changed.
o 接收源地址不存在绑定的任何其他数据包（包括数据包）。如果DAD\u NSL消息丢失，节点在未发出DAD\u NSL消息的情况下更改了到第2层基础结构的物理连接点，SAVI设备丢失绑定（例如，由于重新启动），或者链路拓扑更改，则可能会发生这种情况。
When the binding creation process is triggered, the SEND SAVI device has to assure that the node for which the binding is to be created is the legitimate owner of the address. For the case in which the binding creation process is initiated by a DAD_NSOL exchange, the SEND SAVI device waits for the reception of a validated DAD_NADV message, indicating that the other node has configured the address before, or validated DAD_NSOL messages arriving from other locations, indicating that another node is trying to configure the same address at the same time. For the case in which packets other than a DAD_NSOL initiate the creation of the binding, the SEND SAVI device explicitly requires the node sending those packets to prove address ownership by issuing a secured NUD_NSOL, which has to be answered with a secured NUD_NADV by the probed node.
触发绑定创建过程时，发送SAVI设备必须确保要为其创建绑定的节点是地址的合法所有者。对于绑定创建过程由DAD\u NSOL交换发起的情况，发送SAVI设备等待接收经验证的DAD\u NADV消息，该消息指示另一节点之前已经配置了地址，或者从其他位置到达的经验证的DAD\u NSOL消息，指示另一个节点正试图同时配置同一地址。对于除DAD_\n sol之外的分组发起绑定创建的情况，发送SAVI设备明确要求发送这些分组的节点通过发出安全NUD_\n sol来证明地址所有权，该安全NUD_\n sol必须由被探测节点用安全NUD_NADV来回答。
SEND SAVI devices issue secured NUD_NSOL messages periodically in order to refresh bindings, which have to be answered with a valid NUD_NADV message by the node for which the binding exists.
SEND SAVI devices会定期发出安全的NUD_NSOL消息以刷新绑定，绑定存在的节点必须使用有效的NUD_NADV消息对绑定进行应答。
SEND SAVI devices only forward packets with off-link source addresses if they are received from a port manually configured to connect to a router.
如果从手动配置为连接到路由器的端口接收数据包，则发送SAVI设备仅转发具有断开链路源地址的数据包。
SEND SAVI needs to be protected against replay attacks, i.e., attacks in which a secured SEND message is replayed by another node. As discussed before, the SEND SAVI specification uses SEND messages to create a binding between the address contained in the message (that must be signed by a node possessing the private key associated to the address) and the port through which the message is received. If an attacker manages to obtain such a message from another node, for example, because the message was sent to the all-nodes multicast address or because the attacker has subscribed to the Solicited Node multicast address associated to a remote node, it could replay it preserving the original signature. This may create an illegitimate binding in the SEND SAVI device or could be used to abort address configuration at the other node. While SEND provides some means to limit the impact of the replay of ND messages, the emphasis for SEND anti-replay protection is to limit to a short period of time the validity of the ND information transmitted in the message, for example, the relationship between an IPv6 address and a layer-2 address. Note that the period must be long enough to assure that the information sent by the legitimate sender is considered valid despite the possible differences in clock synchronization between the sender and receiver(s). For example, with the values recommended by [RFC3971] for TIMESTAMP_FUZZ and TIMESTAMP_DRIFT, a node receiving a DAD_NSOL message would not discard replays of this message being received within a period of approximately 2 seconds (more precisely, 2/0.99 seconds). The underlying assumption for SEND security is that even if the message is replayed by another node during this period of time, the information disseminated by ND is still the same. However, allowing a node to replay a SEND message does have an impact on the SEND SAVI operation, regardless of the time elapsed since it was generated, since the node can create a new binding in a SEND SAVI device for the port to which an illegitimate node attaches. As can be concluded, the protection provided by SEND is not enough in all cases for SEND SAVI.
SEND SAVI需要防止重播攻击，即安全发送消息被另一个节点重播的攻击。如前所述，SEND SAVI规范使用SEND messages在消息中包含的地址（必须由拥有与地址相关联的私钥的节点签名）和接收消息的端口之间创建绑定。如果攻击者设法从另一个节点获取此类消息，例如，因为该消息被发送到“所有节点”多播地址，或者因为攻击者已订阅与远程节点关联的请求节点多播地址，则攻击者可以保留原始签名来重播该消息。这可能会在发送SAVI设备中创建非法绑定，或用于中止其他节点的地址配置。虽然SEND提供了一些方法来限制ND消息重放的影响，但SEND防重放保护的重点是将消息中传输的ND信息的有效性限制在短时间内，例如，IPv6地址和第2层地址之间的关系。请注意，周期必须足够长，以确保合法发送方发送的信息被视为有效，尽管发送方和接收方之间的时钟同步可能存在差异。例如，使用[RFC3971]推荐的时间戳模糊和时间戳漂移值，接收DAD\u NSOL消息的节点不会在大约2秒（更准确地说，2/0.99秒）的时间段内放弃接收到的该消息的重播。发送安全性的基本假设是，即使消息在这段时间内由另一个节点重播，ND传播的信息仍然是相同的。然而，允许节点重播发送消息确实会对发送SAVI操作产生影响，而不管其生成后经过了多长时间，因为节点可以在发送SAVI设备中为非法节点连接的端口创建新绑定。可以得出结论，SEND提供的保护在所有情况下都不足以保护SEND SAVI。
SEND SAVI increases the protection against the replay attacks compared to SEND. First, each node is required to connect to the SEND SAVI topology through a different port to prevent eavesdropping before entering the SAVI protection perimeter. Then, SEND SAVI bindings are updated only according to messages whose dissemination can be restricted in the SEND SAVI topology without interfering with the normal SEND operation. The messages used by SEND SAVI to create bindings are DAD_NSOL messages, for which SEND SAVI limits its propagation to the ports through which a previous binding for the same IPv6 address existed (see Section 3.3.2), and NUD_NADV messages
与SEND相比，SEND SAVI增强了对重播攻击的保护。首先，每个节点需要通过不同的端口连接到SEND SAVI拓扑，以防止在进入SAVI保护周界之前发生窃听。然后，仅根据消息更新发送SAVI绑定，这些消息的传播可以在不干扰正常发送操作的情况下限制在发送SAVI拓扑中。SEND SAVI用于创建绑定的消息是DAD_NSOL消息，对于这些消息，SEND SAVI将其传播限制到存在相同IPv6地址的先前绑定的端口（参见第3.3.2节）和NUD_NADV消息
in response to a secured NUD_NSOL sent by the SEND SAVI device only through the tested port. Finally, SEND SAVI filtering rules prevent nodes from replaying messages generated by the SEND SAVI devices themselves. Section 5.1 discusses in more detail the protection provided by SEND SAVI against replay attacks.
响应SEND SAVI设备仅通过测试端口发送的安全NUD_NSOL。最后，SEND SAVI筛选规则防止节点重播SEND SAVI设备本身生成的消息。第5.1节更详细地讨论了SEND SAVI针对重播攻击提供的保护。
In order to reduce computing and state requirements in SEND SAVI devices, SEND SAVI devices can be deployed to form a "protection perimeter" [RFC7039]. With this deployment strategy, SEND SAVI devices perform source-address validation only when packets enter in the protected realm defined through the protection perimeter. The perimeter is defined by appropriate configuration of the roles of each port, which can be 'Validating' or 'Trusted':
为了减少发送SAVI设备中的计算和状态要求，可以部署发送SAVI设备以形成“保护周界”[RFC7039]。使用此部署策略，SEND SAVI设备仅当数据包进入通过保护周界定义的受保护领域时才执行源地址验证。周界由每个端口角色的适当配置定义，可以是“验证”或“受信任”：
o Validating ports (VPs) are ports in which SEND SAVI filtering and binding creation are performed.
o 验证端口（VP）是执行发送SAVI筛选和绑定创建的端口。
o Trusted ports (TPs) are ports in which limited processing is performed. Only SEND messages related with certificates, prefix information, and DAD operation are processed in order to update the state of the SEND SAVI device or the state related with any of the Validating ports of the switch.
o 受信任端口（TPs）是执行有限处理的端口。仅处理与证书、前缀信息和DAD操作相关的发送消息，以便更新发送SAVI设备的状态或与交换机的任何验证端口相关的状态。
Figure 1 shows a typical topology involving trusted and untrusted infrastructure.
图1显示了涉及受信任和不受信任基础架构的典型拓扑。
+--+ +--+ +--+ +--+
|H1| |H2| |H3| |R1|
+--+ +--+ +--+ +--+
| | | |
+------------SEND SAVI PROTECTION PERIMETER-----------+
| | | | | |
| +-1-----2-+ +-1-----2-+ |
| | SEND- | | SEND- | |
| | SAVI1 | | SAVI2 | |
| +-3--4----+ +--3--4---+ |
| | | +--------------+ | | |
| | +----------| |--------+ | |
| | | SWITCH-A | | |
| | +----------| | | |
| | | +--------------+ | |
| +-1--2----+ +-----1---+ |
| | SEND- | | SEND- | |
| | SAVI3 | | SAVI4 | |
| +-3-----4-+ +----4----+ |
| | | | |
+------------SEND SAVI PROTECTION PERIMETER-----------+
| | |
+--+ +--+ +--+
|R2| |H4| |H5|
+--+ +--+ +--+
+--+ +--+ +--+ +--+
|H1| |H2| |H3| |R1|
+--+ +--+ +--+ +--+
| | | |
+------------SEND SAVI PROTECTION PERIMETER-----------+
| | | | | |
| +-1-----2-+ +-1-----2-+ |
| | SEND- | | SEND- | |
| | SAVI1 | | SAVI2 | |
| +-3--4----+ +--3--4---+ |
| | | +--------------+ | | |
| | +----------| |--------+ | |
| | | SWITCH-A | | |
| | +----------| | | |
| | | +--------------+ | |
| +-1--2----+ +-----1---+ |
| | SEND- | | SEND- | |
| | SAVI3 | | SAVI4 | |
| +-3-----4-+ +----4----+ |
| | | | |
+------------SEND SAVI PROTECTION PERIMETER-----------+
| | |
+--+ +--+ +--+
|R2| |H4| |H5|
+--+ +--+ +--+
Figure 1: SAVI Protection Perimeter
图1:SAVI保护周界
Trusted ports are used for connections with trusted infrastructures, such as routers and other SEND SAVI devices. Port 2 of SEND-SAVI2 and port 3 of SEND-SAVI3 are Validating ports because they connect to routers. Port 3 of SEND-SAVI1 and port 1 of SEND-SAVI3 as well as port 4 of SEND-SAVI2 and port 1 of SEND-SAVI4 are trusted because they connect two SAVI devices. Finally, port 4 of SEND-SAVI1, port 3 of SEND-SAVI2, and port 2 of SEND-SAVI3 are trusted because they connect to SWITCH-A to which only trusted nodes are connected.
可信端口用于与可信基础结构（如路由器和其他发送SAVI设备）的连接。SEND-SAVI2的端口2和SEND-SAVI3的端口3是验证端口，因为它们连接到路由器。SEND-SAVI1的端口3和SEND-SAVI3的端口1以及SEND-SAVI2的端口4和SEND-SAVI4的端口1是受信任的，因为它们连接两个SAVI设备。最后，SEND-SAVI1的端口4、SEND-SAVI2的端口3和SEND-SAVI3的端口2是受信任的，因为它们连接到交换机-A，而交换机-A只连接受信任的节点。
Validating ports are used for connection with non-trusted infrastructures; therefore, hosts connect normally to Validating ports. So, in Figure 1 above, ports 1 and 2 of SEND-SAVI1, port 1 of SEND-SAVI2, and port 4 of SEND-SAVI3 are Validating ports because they connect to hosts. Port 4 of SEND-SAVI4 is also a Validating port because it is connected to host H5.
验证端口用于与非可信基础设施的连接；因此，主机通常连接到验证端口。因此，在上面的图1中，SEND-SAVI1的端口1和2、SEND-SAVI2的端口1以及SEND-SAVI3的端口4都是验证端口，因为它们连接到主机。SEND-SAV4的端口4也是一个验证端口，因为它连接到主机H5。
For a more detailed discussion on this, see Section 3.4.
有关这方面的更详细讨论，请参见第3.4节。
Multi-subnet links: In some cases, a given subnet may have several prefixes. This is supported by SEND SAVI as any port can support multiple prefixes.
多子网链接：在某些情况下，给定的子网可能有多个前缀。SEND SAVI支持这一点，因为任何端口都可以支持多个前缀。
Multihomed hosts: A multihomed host is a host with multiple interfaces. The interaction between SEND SAVI and multihomed hosts is as follows. If the different interfaces of the host are assigned different IP addresses and packets sent from each interface and always carry the address assigned to that interface as the source address, then from the perspective of a SEND SAVI device, this is equivalent to two hosts with a single interface, each with an IP address. SEND SAVI supports this without additional considerations. If the different interfaces share the same IP address or if the interfaces have different addresses but the host sends packets using the address of one of the interfaces through any of the interfaces, then SEND SAVI does not directly support it. It would require either connecting at least one interface of the multihomed host to a Trusted port or manually configuring the SEND SAVI bindings to allow binding the address of the multihomed host to multiple anchors simultaneously.
多宿主主机：多宿主主机是具有多个接口的主机。SEND SAVI和多宿主主机之间的交互如下所示。如果为主机的不同接口分配了不同的IP地址和从每个接口发送的数据包，并且始终将分配给该接口的地址作为源地址，那么从发送SAVI设备的角度来看，这相当于两个具有单个接口的主机，每个主机具有一个IP地址。SEND SAVI支持此功能，无需额外考虑。如果不同接口共享相同的IP地址，或者如果接口具有不同的地址，但主机通过任何接口使用其中一个接口的地址发送数据包，则SEND SAVI不直接支持它。它需要将多宿主主机的至少一个接口连接到受信任端口，或者手动配置SEND SAVI绑定，以允许将多宿主主机的地址同时绑定到多个锚。
Virtual switches: A hypervisor or a host operating system may perform bridging functions between virtual hosts running on the same machine. The hypervisor or host OS may in turn connect to a SEND SAVI system. This scenario is depicted in Figure 2, with two virtual machines, VM1 and VM2, connected through a virtual switch, VS1, to SEND SAVI device SEND-SAVI1. The attachment points of VS1 to VM1 and VM2 are configured as Validating.
虚拟交换机：虚拟机监控程序或主机操作系统可以在同一台机器上运行的虚拟主机之间执行桥接功能。虚拟机监控程序或主机操作系统可以依次连接到SEND SAVI系统。此场景如图2所示，两个虚拟机VM1和VM2通过虚拟交换机VS1连接，以发送SAVI设备SEND-SAV1。VS1到VM1和VM2的连接点配置为验证。
Host1
+----------------+
| +---+ +---+ |
| |VM1| |VM2| |
| +---+ +---+ |
| | | |
| +-1-----2--+ |
| | VS1 | |
| +--3-------+ |
| | |
+----|-----------+
|
|
+--1-----2--+
| SEND- |
| SAVI1 |
+--3---4----+
| |
Host1
+----------------+
| +---+ +---+ |
| |VM1| |VM2| |
| +---+ +---+ |
| | | |
| +-1-----2--+ |
| | VS1 | |
| +--3-------+ |
| | |
+----|-----------+
|
|
+--1-----2--+
| SEND- |
| SAVI1 |
+--3---4----+
| |
Figure 2: Virtual Switches Connected to the SEND SAVI Device
图2：连接到SEND SAVI设备的虚拟交换机
In order to provide proper security against replay attacks, performing SEND SAVI filtering as close to untrusted hosts as possible (see Sections 3.4 and 5.1) is recommended. In this scenario, this objective can be achieved by enabling SEND SAVI validation in VS1. Ideally, VS1 could be integrated into the SEND SAVI protection perimeter if the hypervisor or host OS at Host1 can be trusted (even though VM1 and VM2 could not be trusted). To do so, both the attachment to SEND-SAVI1 at VS1, and port 1 at SEND-SAVI1, are configured as Trusted.
为了针对重播攻击提供适当的安全性，建议尽可能靠近不受信任的主机执行SEND SAVI过滤（请参见第3.4节和第5.1节）。在这种情况下，可以通过在VS1中启用SEND SAVI验证来实现这一目标。理想情况下，如果可以信任主机1上的虚拟机监控程序或主机操作系统（即使无法信任VM1和VM2），则VS1可以集成到SEND SAVI保护周界中。为此，VS1上发送至SAV1的附件和发送至SAV1的端口1都配置为受信任。
If the administrator of the network does not trust VS1, port 1 of SEND-SAVI1 is configured as Validating, so that every address being used at Host1 is validated at SEND-SAVI1 by SEND SAVI. The attachment point to the physical network at VS1 should be configured as Trusted if the host administrator knows that it is connected to a SEND SAVI device; in this case, VS1 relies on the infrastructure comprised by the physical SEND SAVI devices but not vice versa. Packets egressing from VM1 are validated twice: first at VS1 and then at SEND-SAVI1. Packets going in the reverse direction (from an external host to VM1) are validated once: when they first reach a SEND SAVI device. If the administrator of VS1 does not trust the physical switch to which it attaches, it can configure the attachment to SEND-SAVI1 as Validating. In Figure 2 above, this means that a packet going from another host to VM1 would be validated twice: once when entering the SEND SAVI perimeter formed by the physical devices and again when entering at VS1.
如果网络管理员不信任VS1，则将SEND-Sav1的端口1配置为验证，以便主机1上使用的每个地址都由SEND-SAVI在SEND-Sav1上验证。如果主机管理员知道VS1物理网络的连接点连接到发送SAVI设备，则应将其配置为受信任的连接点；在这种情况下，VS1依赖于由物理发送SAVI设备组成的基础设施，但反之亦然。从VM1退出的数据包验证两次：首先在VS1，然后在SEND-1。反向（从外部主机到VM1）的数据包验证一次：当它们第一次到达发送SAVI设备时。如果VS1的管理员不信任其所连接的物理交换机，则可以将附件配置为SEND-SAVI1作为验证。在上面的图2中，这意味着从另一个主机到VM1的数据包将被验证两次：一次是在进入由物理设备形成的发送SAVI周界时，另一次是在VS1处。
Untrusted routers: One can envision scenarios where routers are dynamically attached to a SEND SAVI network. A typical example would be a mobile phone connecting to a SEND SAVI switch where the mobile phone is acting as a router for other personal devices that are accessing the network through it. Regarding the validation of the source address performed in a SEND SAVI device, such an untrusted router does not seem to directly fall in the category of trusted infrastructure (if this was the case, it is likely that all devices would be trusted); hence, it cannot be connected to a Trusted port, and if it is connected to a Validating port, the SEND SAVI switch would discard all the packets containing an off-link source address coming from that device. Although the SEND SAVI device to which this router attaches could be configured to permit the transit of packets with source addresses belonging to the set of prefixes reachable through the untrusted router, such a mechanism is out of the scope of this document. As a result, the default mechanism described in this specification cannot be applied in such a scenario.
不受信任的路由器：可以想象路由器动态连接到发送SAVI网络的场景。一个典型的例子是连接到SEND SAVI交换机的移动电话，其中移动电话充当通过它访问网络的其他个人设备的路由器。关于在发送SAVI设备中执行的源地址验证，此类不受信任的路由器似乎不直接属于受信任基础设施的类别（如果是这种情况，则很可能所有设备都是受信任的）；因此，它不能连接到受信任的端口，如果它连接到验证端口，SEND SAVI交换机将丢弃包含来自该设备的断开链路源地址的所有数据包。尽管此路由器所连接的发送SAVI设备可以配置为允许传输具有源地址的数据包，这些源地址属于可通过不受信任的路由器访问的前缀集，但这种机制不在本文档的范围内。因此，本规范中描述的默认机制无法应用于此类场景。
The following three data structures are defined for SEND SAVI operations.
为发送SAVI操作定义了以下三种数据结构。
SEND SAVI Database: The SEND SAVI function relies on state information binding the source IPv6 address used in data packets to the port through which the legitimate node connects. Such information is stored in the SEND SAVI Database. The SEND SAVI Database is populated with the contents of validated SEND messages. Each entry contains the following information:
发送SAVI数据库：发送SAVI功能依赖于将数据包中使用的源IPv6地址绑定到合法节点连接的端口的状态信息。此类信息存储在SEND SAVI数据库中。SEND SAVI数据库由已验证的发送消息的内容填充。每个条目包含以下信息：
o IPv6 source address
o IPv6源地址
o Binding anchor: the port through which the packet was received
o 绑定锚：接收数据包的端口
o Lifetime
o 一生
o Status: TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, TESTING_VP'
o 状态：暂定、暂定、有效、正在测试、正在测试
o Alternative binding anchor: the port from which a DAD_NSOL message or any data packet has been received while a different port was stored in the binding anchor for the address.
o 备用绑定锚：当地址的绑定锚中存储了不同的端口时，接收到DAD\u NSOL消息或任何数据包的端口。
o Creation time: the value of the local clock when the entry was first created
o 创建时间：首次创建条目时本地时钟的值
SEND SAVI Prefix List: SEND SAVI devices need to know which ones are the link prefixes in order to identify local and off-link traffic. A SEND SAVI device MUST support discovering this information from the Prefix Information option [RFC4861] with the L bit set of Router Advertisement (RADV) messages coming from Trusted ports, as described in Section 3.3.2. The list of prefixes MAY also be configured manually. This information is not specific to a given port. The SEND SAVI Prefix List contains one entry per prefix in use, as follows:
发送SAVI前缀列表：发送SAVI设备需要知道哪些是链路前缀，以便识别本地和非链路流量。如第3.3.2节所述，发送SAVI设备必须支持从前缀信息选项[RFC4861]发现来自可信端口的L位路由器广告（RADV）消息集的此信息。前缀列表也可以手动配置。此信息不是特定于给定端口的。SEND SAVI Prefix列表中每个正在使用的前缀包含一个条目，如下所示：
o Prefix: the prefix included in a Prefix Information option.
o 前缀：包含在前缀信息选项中的前缀。
o Prefix lifetime: time in seconds that the prefix is valid. Initially set to the Valid Lifetime value of the Prefix Information option of a valid RADV message or set to a value of all 1 bits (0xffffffff), which represents infinity, if configured manually.
o 前缀生存期：前缀有效的时间（秒）。最初设置为有效RADV消息前缀信息选项的有效生存期值，或设置为所有1位的值（0xffffffff），如果手动配置，则表示无穷大。
When the SEND SAVI device boots, it MUST send a Router Solicitation (RSOL) message, which does not need to be secured if the unspecified address is used (see [RFC3971], Sections 5.1.1 and 5.2.1). The SAVI device SHOULD issue a RSOL message in case the prefix entry is about to expire.
当SEND SAVI设备启动时，它必须发送路由器请求（RSOL）消息，如果使用未指定的地址，则不需要保护该消息（请参阅[RFC3971]，第5.1.1和5.2.1节）。如果前缀条目即将过期，SAVI设备应发出RSOL消息。
In order to perform the SEND SAVI operation, some basic parameters of the SEND SAVI device have to be configured. Since a SEND SAVI device operates as a SEND node to generate NUD_NSOL, RSOL, or Certification Path Solicitation (CPS) messages:
为了执行发送SAVI操作，必须配置发送SAVI设备的一些基本参数。由于发送SAVI设备作为发送节点来生成NUD_NSOL、RSOL或认证路径请求（CPS）消息：
o The SEND SAVI device MUST be configured with a valid CGA address. When the SEND SAVI device configures this address, it MUST behave as a regular SEND node, i.e., using secured NSOL messages to perform DAD, etc., in addition to fulfilling the requirements stated for regular IPv6 nodes [RFC6434].
o 发送SAVI设备必须配置有效的CGA地址。发送SAVI设备配置此地址时，除了满足常规IPv6节点的要求外，还必须作为常规发送节点，即使用安全的NSOL消息执行DAD等[RFC6434]。
o The SEND SAVI device MAY be configured with at least one trust anchor if it is configured to validate RADV messages (see Section 3.3.2). In this case, the SEND SAVI device MAY be configured with certification paths. The alternative is obtaining them by means of issuing Certification Path Solicitation messages, as detailed in the SEND specification [RFC3971].
o 如果将发送SAVI设备配置为验证RADV消息，则可将其配置为至少一个信任锚（见第3.3.2节）。在这种情况下，发送SAVI设备可以配置有认证路径。另一种方法是通过发出认证路径请求消息来获取它们，如发送规范[RFC3971]中所述。
In addition, the port role for each port of the SEND SAVI device MUST be configured. The guidelines for this configuration are specified in Section 3.4.
此外，必须为发送SAVI设备的每个端口配置端口角色。第3.4节规定了该配置的指南。
In this section, we describe how packets are processed by a SEND SAVI device. Behavior varies depending on if the packet belongs to local or transit traffic. This is determined by checking if the prefix of the source address is included in the SEND SAVI Prefix List or in the unspecified address (local traffic) or not included in the SEND SAVI Prefix List (transit traffic).
在本节中，我们将描述发送SAVI设备如何处理数据包。根据数据包属于本地还是传输流量，行为会有所不同。这是通过检查源地址的前缀是否包含在发送SAVI前缀列表中或未指定的地址（本地通信量）中或未包含在发送SAVI前缀列表（中转通信量）中来确定的。
Transit traffic processing occurs as follows:
过境交通处理如下：
o If the SEND SAVI device receives a transit traffic packet through a Trusted port, it forwards it without any SAVI processing.
o 如果发送SAVI设备通过受信任的端口接收到传输流量数据包，则在不进行任何SAVI处理的情况下转发该数据包。
o If the SEND SAVI device receives a transit traffic packet through a Validating port, it discards the packet.
o 如果发送SAVI设备通过验证端口接收到传输业务数据包，则丢弃该数据包。
If the verification of the source address of a packet shows that it belongs to local traffic, this packet is processed using the state machine described in this section.
如果数据包的源地址验证表明它属于本地通信量，则使用本节中描述的状态机处理该数据包。
For the rest of the section, the following assumptions hold:
对于本节的其余部分，以下假设成立：
o When it is stated that a secured NUD_NSOL message is issued by a SEND SAVI device through a port P, it means that the SEND SAVI device generates a NUD_NSOL message, according to the Neighbor Unreachability Detection procedure described in [RFC4861], addressed to the IPv6 target address, which is the source address of the packet triggering the procedure. This message is secured by SEND as defined in [RFC3971]. The source address used for issuing the NUD_NSOL message is the source address of the SEND SAVI device. The message is sent only through port P.
o 当声明安全NUD_NSOL消息由发送SAVI设备通过端口P发出时，这意味着发送SAVI设备根据[RFC4861]中描述的邻居不可访问性检测过程生成一条NUD_NSOL消息，该消息发往IPv6目标地址，这是触发过程的数据包的源地址。此消息由[RFC3971]中定义的发送保护。用于发出NUD_NSOL消息的源地址是发送SAVI设备的源地址。消息仅通过端口P发送。
o When it is stated that a validated NUD_NADV message is received by a SEND SAVI device, it means that a SEND secured NUD_NADV message has been received by the same port P through which the corresponding NUD_NSOL message was issued, and the NUD_NADV message has been validated according to [RFC3971] to prove ownership for the IPv6 address under consideration and to prove that it is a response for the previous NUD_NSOL message issued by the SEND SAVI device (containing the same nonce value as the NUD_NSOL message to which it answers).
o 当说明发送SAVI设备接收到经验证的NUD_NADV消息时，这意味着发送安全NUD_NADV消息已由发出相应NUD_NSOL消息的同一端口P接收，并且已根据[RFC3971]对NUD_NADV消息进行验证证明所考虑的IPv6地址的所有权，并证明它是发送SAVI设备发出的前一条NUD_NSOL消息的响应（包含与其应答的NUD_NSOL消息相同的nonce值）。
We use VP to refer to a Validating port and TP to refer to a Trusted port.
我们使用VP表示验证端口，使用TP表示可信端口。
The state machine is defined for a binding of a given source IPv6 address in a given SEND SAVI device. In the transitions considered, packets described as inputs refer to the IPaddr IPv6 address associated to the state machine.
状态机是为给定发送SAVI设备中给定源IPv6地址的绑定定义的。在考虑的转换中，被描述为输入的数据包引用与状态机关联的IPaddr IPv6地址。
The possible states for a given IPaddr are NO_BIND, TENTATIVE_DAD, TENTATIVE_NUD, VALID, TESTING_VP, and TESTING_VP'. The NO_BIND state represents that no binding exists for IPaddr; this is the state for all addresses unless a binding is explicitly created.
给定IPADR的可能状态为无绑定、暂定、暂定、有效、测试和测试。NO_BIND状态表示IPaddr不存在绑定；这是所有地址的状态，除非显式创建绑定。
The states can be classified into 'forwarding' states, i.e., states in which packets received from the port associated to the IPv6 address are forwarded, and 'non-forwarding' states, i.e., states in which packets different to the ones used for signaling are not forwarded. VALID, TENTATIVE_DAD, TESTING_VP, and TESTING_VP' are forwarding states, and NO_BIND and TENTATIVE_NUD are non-forwarding states.
这些状态可分为“转发”状态，即转发从与IPv6地址相关联的端口接收的分组的状态，以及“非转发”状态，即不转发与用于信令的分组不同的分组的状态。有效、暂定、测试和测试为转发状态，无绑定和暂定为非转发状态。
The SEND SAVI device MUST join the Solicited Node Multicast group for all the addresses whose state is other than NO_BIND. This is needed to make sure that the SEND SAVI device receives DAD_NSOL messages issued for those addresses. Note that it may not be enough to relay on the Multicast Listener Discovery (MLD) messages being sent by the node attached to a Validating port for which a binding for the corresponding address exists, since the node may move and packets sent to that particular Solicited Node Multicast group may no longer be forwarded to the SEND SAVI device.
发送SAVI设备必须加入请求节点多播组，以获得其状态不是NOU BIND的所有地址。这是确保发送SAVI设备接收为这些地址发出的DAD\u NSOL消息所必需的。注意，由于节点可能移动并且发送到该特定请求节点多播组的分组可能不再被转发到发送SAVI设备，因此中继由连接到存在对应地址的绑定的验证端口的节点发送的多播侦听器发现（MLD）消息可能是不够的。
In order to determine which traffic is on-link and off-link, the SEND SAVI device MUST support discovery of this information from the Prefix Information option with the L bit set of RADV messages. In this case, at least one router SHOULD be configured to advertise RADV messages containing a Prefix Information option with the prefixes that the untrusted nodes can use as source addresses, and the bit L set. An alternative to this is to manually configure the SEND SAVI Prefix List or restrict the use of link-local addresses.
为了确定链路上和链路下的通信量，SEND SAVI设备必须支持从带有L位RADV消息集的前缀信息选项中发现该信息。在这种情况下，应至少配置一个路由器，以通告包含前缀信息选项的RADV消息，该前缀具有非受信任节点可以用作源地址的前缀以及位L集。另一种方法是手动配置发送SAVI前缀列表或限制使用链接本地地址。
SEND SAVI devices MUST discard RADV messages received from Validating ports. RADV messages are only accepted and processed when received through Trusted ports.
发送SAVI设备必须丢弃从验证端口接收的RADV消息。RADV消息仅在通过受信任端口接收时才被接受和处理。
SEND SAVI devices SHOULD NOT validate RADV messages to update the SEND SAVI Prefix List and forward them to other nodes. These messages can only be received from Trusted ports, and we assume that routers are trusted. Validating RADV messages would be required in
发送SAVI设备不应验证RADV消息以更新发送SAVI前缀列表并将其转发给其他节点。这些消息只能从受信任的端口接收，我们假设路由器是受信任的。在中需要验证RADV消息
any SEND SAVI device the node is traversing. Besides, hosts will validate this message before using the information it contains.
节点正在穿越的任何发送SAVI设备。此外，主机将在使用此消息包含的信息之前验证此消息。
In case SEND SAVI devices are configured to validate RADV messages, SEND SAVI devices SHOULD support the processing of validated Certification Path Advertisement (CPA) messages, sent in reply to CPS messages, to acquire certificates used to validate router messages; alternatively, it SHOULD be configured with a certification path.
如果发送SAVI设备配置为验证RADV消息，则发送SAVI设备应支持处理已验证的认证路径公告（CPA）消息，该消息作为对CPS消息的回复发送，以获取用于验证路由器消息的证书；或者，它应该配置一个认证路径。
The state machine defined for the SEND SAVI operation adheres to the following design guidelines:
为SEND SAVI操作定义的状态机遵循以下设计准则：
o The only events that trigger state changes from forwarding to non-forwarding states, and vice versa, are the reception of DAD_NSOL, DAD_NADV, and NUD_NADV or the expiration of a timer. The other possible input to consider is 'any other packet', which could generate changes to states belonging to the same forwarding or non-forwarding class as the original state. In other words, when 'any other packet' is received, the state cannot move from forwarding to non-forwarding, and vice versa. The reduced set of messages being able to trigger a change simplifies the processing at SEND SAVI devices.
o 触发状态从转发状态更改为非转发状态（反之亦然）的唯一事件是接收DAD_NSOL、DAD_NADV和NUD_NADV或计时器过期。另一个可能考虑的输入是“任何其他分组”，它可以产生属于同一转发或非转发类的状态作为原始状态的变化。换句话说，当接收到“任何其他数据包”时，状态不能从转发移动到非转发，反之亦然。能够触发更改的消息集的减少简化了SEND SAVI设备的处理。
o DAD_NADV and NUD_NADV are only processed when they are a response to a DAD_NSOL or a NUD_NSOL message.
o DAD_NADV和NUD_NADV仅当它们是对DAD_NSOL或NUD_NSOL消息的响应时才被处理。
o SEND SAVI devices MUST only use ND messages received through Validating ports if they are valid; otherwise, they discard them. SEND SAVI devices SHOULD assume that such messages received from Trusted ports have been validated by other SEND SAVI devices, or come from a trusted device such a router, so they SHOULD NOT attempt to validate them in order to reduce the processing load at the SEND SAVI device.
o 发送SAVI设备必须仅使用通过验证端口接收的ND消息（如果它们有效）；否则，他们会丢弃它们。SEND SAVI设备应假定从受信任端口接收的此类消息已由其他SEND SAVI设备验证，或来自受信任设备（如路由器），因此它们不应尝试验证这些消息以减少SEND SAVI设备的处理负载。
o The only messages the SEND SAVI device is required to generate specifically per each source IP address are MLD and NUD_NSOL messages. This also keeps the state machine simple.
o SEND SAVI设备需要专门针对每个源IP地址生成的唯一消息是MLD和NUD_NSOL消息。这也使状态机保持简单。
o Well-behaved nodes are expected to initiate communication by sending secured DAD_NSOL messages. The SEND SAVI state machine is tailored to efficiently process these events. The reception of other packet types without receiving previously validated DAD_NSOL messages is assumed to be a consequence of bad-behaving nodes or infrequent events (such as packet loss, a change in the topology connecting the switches, etc.). While a binding will ultimately be created for nodes affected by such events, simplicity of the state machine is prioritized over any possible optimization for these cases.
o 行为良好的节点应通过发送安全的DAD\u NSL消息来启动通信。SEND SAVI状态机是为有效处理这些事件而定制的。在未接收到先前验证的DAD\u NSOL消息的情况下接收其他数据包类型被认为是节点行为不良或不频繁事件（例如数据包丢失、连接交换机的拓扑结构变化等）的结果。虽然最终将为受此类事件影响的节点创建绑定，但在这些情况下，状态机的简单性优先于任何可能的优化。
o If a node has a configured address, and it can prove that it owns this address, the binding is preserved regardless of any indication that a binding for the same source address could be configured in other SEND SAVI devices. Bindings for the same source address in two or more SEND SAVI devices may occur due to several reasons, for example, when a host moves (the two bindings exist just for a short period of time) or when many nodes generate the same address and the DAD procedure has failed. In these infrequent cases, SEND SAVI preserves connectivity for the resulting bindings.
o 如果节点具有已配置的地址，并且可以证明其拥有该地址，则绑定将被保留，而不管是否有任何迹象表明可以在其他发送SAVI设备中配置相同源地址的绑定。两个或多个SEND SAVI设备中相同源地址的绑定可能由于多种原因而发生，例如，当主机移动时（这两个绑定只存在很短的一段时间），或者当许多节点生成相同地址且DAD过程失败时。在这些不常见的情况下，SEND SAVI会保留结果绑定的连接。
Next, we describe how different inputs are processed, depending on the state of the binding of the IP address 'IPaddr'. Note that every ND message is assumed to be validated according to the SEND specification.
接下来，我们将根据IP地址“IPaddr”的绑定状态描述如何处理不同的输入。注意，假设每个ND消息都根据发送规范进行验证。
To facilitate the reader's understanding of the most relevant transitions of the SEND SAVI state machine, a simplified version, which does not contain every possible transition, is depicted in Figure 3:
为了便于读者理解SEND SAVI状态机最相关的转换，图3中描述了一个简化版本，它不包含所有可能的转换：
+-------------+
| |
| TESTING_VP' |
| |
+-------------+
Timeout/VP=VP' | ^
| |
VP_NUD_NADV/- | | VP'_DAD_NSOL/
| | VP_NUD_NSOL
| |
v |
VP_DAD_NSOL/- +--------+
+------------- | |
| | VALID |< -------------------+
| +-------- >| | |
| | +--------+ |
| | ^ | |
| | VP_NUD_ | | Timeout, |
| | NADV/- | | TP_DAD_NSOL/VP_NUD_NSOL|
| | | v |
| | +------------+ |
| | | | |
| | | TESTING_VP | |
| | | | |
| | +------------+ |
| | | |
| | | Timeout/- |
| | VP*, | |
| | Timeout/- | VP_NUD_NADV/- |
v | | |
+---------------+ | +---------------+
| | | | |
| TENTATIVE_DAD | | | TENTATIVE_NUD |
| | | | |
+---------------+ | +---------------+
^ | | | ^
| | | Timeout/- | |
| | TP_DAD_NSOL, | | |
| | TP_DAD_NADV/- | | |
| | v | |
| | +---------+ | |
| +--------- >| |< -----+ |
| | NO_BIND | |
+--------------| |-----------------+
VP_DAD_NSOL/- +---------+ VP*/VP_NUD_NSOL
+-------------+
| |
| TESTING_VP' |
| |
+-------------+
Timeout/VP=VP' | ^
| |
VP_NUD_NADV/- | | VP'_DAD_NSOL/
| | VP_NUD_NSOL
| |
v |
VP_DAD_NSOL/- +--------+
+------------- | |
| | VALID |< -------------------+
| +-------- >| | |
| | +--------+ |
| | ^ | |
| | VP_NUD_ | | Timeout, |
| | NADV/- | | TP_DAD_NSOL/VP_NUD_NSOL|
| | | v |
| | +------------+ |
| | | | |
| | | TESTING_VP | |
| | | | |
| | +------------+ |
| | | |
| | | Timeout/- |
| | VP*, | |
| | Timeout/- | VP_NUD_NADV/- |
v | | |
+---------------+ | +---------------+
| | | | |
| TENTATIVE_DAD | | | TENTATIVE_NUD |
| | | | |
+---------------+ | +---------------+
^ | | | ^
| | | Timeout/- | |
| | TP_DAD_NSOL, | | |
| | TP_DAD_NADV/- | | |
| | v | |
| | +---------+ | |
| +--------- >| |< -----+ |
| | NO_BIND | |
+--------------| |-----------------+
VP_DAD_NSOL/- +---------+ VP*/VP_NUD_NSOL
Figure 3: Simplified SEND SAVI State Machine
图3：简化的发送SAVI状态机
Each state transition is characterized by any of the events that may trigger the change and the message(s) generated as a result of this change. The meaning of some terms are referred next:
每个状态转换的特征是可能触发更改的任何事件以及由此更改生成的消息。下面将介绍一些术语的含义：
o VP_DAD_NSOL as a triggering event means that a validated DAD_NSOL message has been received from the current BINDING_ANCHOR port VP.
o VP_DAD_NSOL作为触发事件意味着已从当前绑定锚端口VP接收到已验证的DAD_NSOL消息。
o VP* means any packet (data packet) received from the current BINDING_ANCHOR port VP.
o VP*指从当前绑定锚端口VP接收的任何数据包（数据包）。
o TP_DAD_NSOL as a triggering event means that a DAD_NSOL message was received from a Trusted port.
o TP_DAD_NSOL作为触发事件意味着从受信任端口接收到DAD_NSOL消息。
o - means that no message is sent. VP=VP' means that the BINDING_ANCHOR is set to VP'.
o -表示不发送任何消息。VP=VP'表示绑定锚定设置为VP'。
The notation
符号
Timeout, TP_DAD_NSOL/VP_NUD_NSOL
超时，TP\u DAD\u NSOL/VP\u NUD\u NSOL
means that the transition is triggered by either a timeout expiration or the reception of a DAD_NSOL message from a Trusted port, and in addition to the transition, a NUD_NSOL message is sent through port VP.
表示转换由超时过期或从受信任端口接收DAD\u NSOL消息触发，除转换外，还通过端口VP发送NUD\u NSOL消息。
For the rest of the description, we assume the following:
对于其余的描述，我们假设如下：
o When a validated message is required (i.e., a 'validated DAD_NSOL'), messages are check for validity in the considered switch according to [RFC3971], and messages not fulfilling these conditions are discarded.
o 当需要验证的消息（即“验证的DAD\u NSOL”）时，将根据[RFC3971]检查所考虑的交换机中的消息的有效性，不满足这些条件的消息将被丢弃。
o When any SEND message is received from a validated port, the SEND SAVI SHOULD assume that the message has been validated by the SEND SAVI device through which the message accessed the SEND SAVI protection perimeter (unless the SEND SAVI perimeter has been breached), or the device generating it is trusted. In this case, the SAVI device does not perform any further validation. Performing validation for SEND messages received through a Trusted port may affect performance negatively.
o 当从验证端口接收到任何发送消息时，发送SAVI应假定该消息已由发送SAVI设备验证，消息通过该设备访问发送SAVI保护周界（除非发送SAVI周界已被破坏），或者生成该周界的设备是可信的。在这种情况下，SAVI设备不执行任何进一步的验证。对通过受信任端口接收的发送消息执行验证可能会对性能产生负面影响。
NO_BIND
不受约束
When the node is in this state, there are no unresolved NUD_NSOL messages generated by SEND SAVI or DAD_NSOL propagated to any Validating port, so the only relevant inputs are DAD_NSOL messages coming either from a Validating port (VP) or Trusted port (TP), or any packet other than DAD_NSOL coming from a VP or TP. There are no timers configured for this state.
当节点处于此状态时，发送SAVI或DAD\u NSL生成的未解析NUD\u NSL消息不会传播到任何验证端口，因此唯一相关的输入是来自验证端口（VP）或受信任端口（TP）的DAD\u NSL消息，或来自VP或TP的除DAD\u NSL以外的任何数据包。没有为此状态配置计时器。
Messages received from a Validating port:
从验证端口接收的消息：
o If a validated DAD_NSOL message is received from a Validating port VP, the SEND SAVI device forwards this message to all appropriate Trusted ports (the subset of Trusted ports that belong to the forwarding layer-2 topology, with the restrictions imposed by the MLD snooping mechanism, if applied). DAD_NSOL messages are not sent through any of the ports configured as Validating ports. The SEND SAVI device sets the LIFETIME to TENT_LT, stores all the information required for future validation of the corresponding DAD_NADV message (such as the nonce of the message), creates a new entry in the SEND SAVI Database for IPaddr, sets BINDING_ANCHOR to VP, and changes the state to TENTATIVE_DAD. Creation time is set to the current value of the local clock.
o 如果从验证端口VP接收到经验证的DAD\u NSOL消息，则发送SAVI设备将该消息转发到所有适当的受信任端口（属于转发层2拓扑的受信任端口子集，受MLD窥探机制施加的限制，如果适用）。DAD\u NSOL消息不会通过任何配置为验证端口的端口发送。SEND SAVI设备将生存期设置为TENT_LT，存储未来验证相应DAD_NADV消息所需的所有信息（如消息的nonce），在SEND SAVI数据库中为IPaddr创建新条目，将绑定_锚定设置为VP，并将状态更改为暂定_DAD。创建时间设置为本地时钟的当前值。
Note that in this case, it is not possible to check address ownership by sending a NUD_NSOL because while the node is waiting for a possible DAD_NADV, its address is in tentative state and the node cannot respond to NSOL messages [RFC4862].
注意，在这种情况下，不可能通过发送NUD_NSL来检查地址所有权，因为当节点等待可能的DAD_NADV时，其地址处于暂定状态，并且节点无法响应NSL消息[RFC4862]。
o If any packet other than a DAD_NSOL is received through a Validating port VP, the SEND SAVI device issues a secured NUD_NSOL through port VP. The SEND SAVI device sets the LIFETIME to TENT_LT. The SEND SAVI device creates a new entry in the SEND SAVI Database for IPaddr, sets BINDING_ANCHOR to VP, and the state is changed to TENTATIVE_NUD. Creation time is set to the current value of the local clock. The SAVI device MAY discard the packet while the NUD procedure is being executed or MAY store it in order to send it if the next transitions are (strictly) TENTATIVE_NUD and then VALID.
o 如果通过验证端口VP接收到除DAD\u NSL以外的任何数据包，则发送SAVI设备通过端口VP发出安全NUD\u NSL。SEND SAVI设备将生存期设置为TENT_LT。SEND SAVI设备在SEND SAVI数据库中为IPaddr创建一个新条目，将BINDING_ANCHOR设置为VP，状态更改为暂定。创建时间设置为本地时钟的当前值。SAVI设备可以在执行NUD过程时丢弃该分组，或者如果下一个转换是（严格地）暂时的且随后是有效的，则可以存储该分组以便发送它。
Messages received from a Trusted port:
从受信任端口接收的消息：
o If a DAD_NSOL message containing IPaddr as the target address is received through a Trusted port, it MUST NOT be forwarded through any of the Validating ports: it is sent through the proper Trusted ports. The state is not changed.
o 如果通过受信任端口接收到包含IPaddr作为目标地址的DAD\u NSOL消息，则不得通过任何验证端口转发该消息：该消息通过适当的受信任端口发送。状态没有改变。
o Any packet other than a DAD_NSOL received from a Trusted port is forwarded to its destination. This packet is assumed to come from a SEND SAVI device that has securely validated the binding, according to the SEND SAVI rules (unless the SEND SAVI perimeter has been breached). The state is not changed.
o 从受信任端口接收的除DAD\u NSL之外的任何数据包都会转发到其目的地。根据SEND-SAVI规则，假定此数据包来自已安全验证绑定的SEND-SAVI设备（除非违反了SEND-SAVI周界）。状态没有改变。
TENTATIVE_DAD
爸爸
To arrive at this state, the SEND SAVI device has received a validated DAD_NSOL coming from the BINDING_ANCHOR port, and it has forwarded it to the appropriate TPs. The relevant events occurring in this state are the reception of a DAD_NADV message from a TP, a DAD_NSOL message from the BINDING_ANCHOR port, other Validating port or TP, a data packet from the BINDING_ANCHOR port, and the expiration of the LIFETIME timer initiated when the DAD_NSOL was received at the BINDING_ANCHOR port.
要达到此状态，发送SAVI设备已接收到来自绑定锚端口的已验证DAD\u NSOL，并已将其转发到相应的TPs。在此状态下发生的相关事件包括从TP接收DAD_NADV消息、从BINDING_锚端口、其他验证端口或TP接收DAD_NSOL消息、从BINDING_锚端口接收数据包，以及在BINDING_锚端口接收DAD_NSOL时启动的生存期计时器过期。
Messages received from a Trusted port:
从受信任端口接收的消息：
o The reception of a valid DAD_NADV message from a Trusted port indicates that the binding cannot be configured for the BINDING_ANCHOR port. The state is changed to NO_BIND, and the LIFETIME is cleared.
o 从受信任端口接收到有效的DAD_NADV消息表示无法为绑定_锚端口配置绑定。状态更改为“无绑定”，并清除生存期。
o The reception of a valid DAD_NSOL from a Trusted port indicates that a node connected to another SEND SAVI device may be trying to configure the same address at the same time. The DAD_NSOL message is forwarded to the BINDING_ANCHOR port, so that the node at this port will not configure the address, as stated in [RFC4862]. The DAD_NSOL message is also forwarded to all appropriate Trusted ports. Then, the LIFETIME is cleared, and the state is changed to NO_BIND.
o 从受信任端口接收到有效的DAD\u NSL表示连接到另一个发送SAVI设备的节点可能正在尝试同时配置相同的地址。DAD_NSOL消息被转发到绑定锚端口，因此该端口上的节点将不会配置地址，如[RFC4862]中所述。DAD\u NSOL消息也会转发到所有适当的受信任端口。然后，清除生存期，并将状态更改为无绑定。
o Any packet other than a validated DAD_NSOL or DAD_NADV received from a Trusted port is forwarded to its destination. This packet is assumed to come from a SEND SAVI device that has securely validated the binding, according to the SEND SAVI rules (unless the SEND SAVI perimeter has been breached). The state is not changed.
o 从受信任端口接收的任何数据包（验证的DAD_NSL或DAD_NADV除外）都将转发到其目的地。根据SEND-SAVI规则，假定此数据包来自已安全验证绑定的SEND-SAVI设备（除非违反了SEND-SAVI周界）。状态没有改变。
Messages received from a Validating port different from the BINDING_ANCHOR:
从不同于绑定锚的验证端口接收的消息：
o A validated DAD_NSOL is received from a Validating port VP' different from the BINDING_ANCHOR port. The reception of a valid DAD_NSOL from port VP' indicates that a node connected to VP' may be trying to configure the same address at the same time. The DAD_NSOL message is forwarded to the BINDING_ANCHOR port, so that the node at this port will not configure the address, as stated in [RFC4862]. The DAD_NSOL message is also forwarded to all appropriate Trusted ports. Then, the BINDING_ANCHOR is set to VP' (through which the DAD_NSOL message was received), the LIFETIME is set to TENT_LT, and the state remains in TENTATIVE_DAD.
o 从与绑定锚端口不同的验证端口VP'接收已验证的DAD\u NSOL。从端口VP'接收到有效的DAD\u NSL表示连接到VP'的节点可能正在尝试同时配置相同的地址。DAD_NSOL消息被转发到绑定锚端口，因此该端口上的节点将不会配置地址，如[RFC4862]中所述。DAD\u NSOL消息也会转发到所有适当的受信任端口。然后，绑定锚被设置为VP’（通过它接收DAD\u NSOL消息），生存期被设置为TENT\u LT，并且状态保持为暂定状态。
o Any packet other than a validated DAD_NSOL received from a Validating port VP' different from the BINDING_ANCHOR port is discarded. The state is not changed.
o 从与绑定锚端口不同的验证端口VP'接收到的除已验证DAD\u NSL之外的任何数据包都将被丢弃。状态没有改变。
Messages received from the BINDING_ANCHOR port:
从绑定锚端口接收的消息：
o If a validated DAD_NSOL is received from the BINDING_ANCHOR port, the LIFETIME is set to TENT_LT, and the state remains in TENTATIVE_DAD.
o 如果从绑定锚端口接收到已验证的DAD\u NSOL，则生存期设置为TENT\u LT，并且状态保持为暂定DAD。
o If any packet other than a DAD_NSOL is received from the BINDING_ANCHOR port, it is assumed that the node has configured its address, although it has done it in less time than expected by the SEND SAVI device (less than TENT_LT). Since the node proved address ownership by means of the validated DAD_NSOL message, the LIFETIME is set to DEFAULT_LT, and the state is changed to VALID.
o 如果从绑定锚端口接收到除DAD\u NSOL以外的任何数据包，则假定节点已配置其地址，尽管它在比发送SAVI设备预期的时间更短的时间内完成了该操作（小于TENT）。由于节点通过验证的DAD\u NSL消息证明了地址所有权，因此生存期设置为默认值，状态更改为有效。
LIFETIME expires:
生命周期到期：
o If LIFETIME expires, it is assumed that no other node has configured this address. Therefore, the Validating port VP (currently stored in the BINDING_ANCHOR) could be bound to this IPv6 address. The LIFETIME is set to DEFAULT_LT, and the state is changed to VALID.
o 如果生存期到期，则假定没有其他节点配置此地址。因此，验证端口VP（当前存储在绑定锚中）可以绑定到此IPv6地址。生存期设置为默认值，状态更改为有效。
VALID
有效的
To arrive at this state, the SEND SAVI device has successfully validated address ownership and has created a binding for IPaddr. Relevant transitions for this state are triggered by the reception of DAD_NSOL from the BINDING_ANCHOR port, other Validating port or a TP, and any packet other than DAD_NSOL from a Validating port other than
要达到此状态，SEND SAVI设备已成功验证地址所有权，并已为IPaddr创建绑定。此状态的相关转换是由从绑定锚端口、其他验证端口或TP接收DAD\u NSL，以及从其他验证端口接收DAD\u NSL以外的任何数据包触发的
the BINDING_ANCHOR or a TP. The expiration of LIFETIME is also relevant to trigger a check for address ownership for the node at the BINDING_ANCHOR port.
绑定锚或TP。生存期到期还与触发绑定锚端口处节点的地址所有权检查有关。
Messages received from the BINDING_ANCHOR port:
从绑定锚端口接收的消息：
o If a validated DAD_NSOL with IPaddr as a source address is received through the BINDING_ANCHOR port, it is forwarded to the appropriate Trusted ports. The LIFETIME is set to TENT_LT, and the state is changed to TENTATIVE_DAD.
o 如果通过绑定锚端口接收到以IPaddr作为源地址的已验证DAD\u NSOL，则会将其转发到适当的受信任端口。生命周期设置为TENT\u LT，状态更改为暂定\u DAD。
o Any packet other than a DAD_NSOL containing IPaddr as a source address arriving from the BINDING_ANCHOR port is forwarded appropriately. The state is not changed.
o 从绑定锚端口到达的任何数据包（包含IPaddr作为源地址的DAD\u NSL除外）都会被适当地转发。状态没有改变。
Messages received from a Trusted port:
从受信任端口接收的消息：
o If a DAD_NSOL with IPaddr as a source address is received through a Trusted port, the message is forwarded to VP. The LIFETIME is set to TENT_LT, a secured NUD_NSOL message is sent to IPaddr through VP, and the state is changed to TESTING_VP.
o 如果通过受信任端口接收到源地址为IPaddr的DAD\u NSOL，则消息将转发到VP。生存期设置为TENT\u LT，安全NUD\u NSOL消息通过VP发送到IPaddr，状态更改为TESTING\u VP。
o If any packet other than a DAD_NSOL with IPaddr as a source address is received through a Trusted port, the packet is forwarded to VP and to other appropriate Trusted ports. A secured NUD_NSOL is sent to the BINDING_ANCHOR port, the LIFETIME is set to TENT_LT, and the state is changed to TESTING_VP.
o 如果通过受信任端口接收到除源地址为IPaddr的DAD\u NSOL以外的任何数据包，则该数据包将转发到VP和其他适当的受信任端口。安全NUD\u NSOL被发送到绑定\u锚端口，生存期设置为TENT\u LT，状态更改为TESTING\u VP。
Messages received from a Validating port different from the BINDING_ANCHOR:
从不同于绑定锚的验证端口接收的消息：
o If a validated DAD_NSOL packet with IPaddr as a source address is received through a Validating port VP' (a VP' different from the current BINDING ANCHOR), the message is forwarded to the BINDING_ANCHOR port. In addition, a secured NUD_NSOL is sent to the BINDING_ANCHOR port, the ALTERNATIVE BINDING ANCHOR is set to port VP' (for future use if the node at VP' is finally selected), the LIFETIME is set to TENT_LT, and the state is changed to TESTING_VP'.
o 如果通过验证端口VP（与当前绑定锚不同的VP）接收到以IPaddr作为源地址的已验证DAD\u NSOL数据包，则消息将转发到绑定锚端口。此外，安全的NUD_NSOL被发送到绑定_锚端口，备用绑定锚被设置为端口VP’（如果最后选择了VP’处的节点，则用于将来使用），生存期被设置为TENT_LT，状态更改为TESTING_VP’。
o If any packet other than a DAD_NSOL with IPaddr as a source address is received from a Validating port VP', different from the current BINDING_ANCHOR for this binding, VP, the packet is discarded. The SEND SAVI device MAY issue a secured NUD_NSOL through the BINDING_ANCHOR port, store VP' in the ALTERNATIVE BINDING ANCHOR for possible future use, set the LIFETIME to TENT_LT, and change the state to TESTING_VP'. An alternative to this behavior is that the SEND SAVI device MAY not do anything (in
o 如果从验证端口VP'接收到除源地址为IPaddr的DAD\u NSL以外的任何数据包，而该数据包与该绑定的当前绑定锚VP'不同，则该数据包将被丢弃。发送SAVI设备可通过绑定锚端口发出安全NUD\u NSOL，将VP'存储在备用绑定锚中以备将来使用，将生存期设置为TENT\LT，并将状态更改为TESTING\u VP'。此行为的另一种选择是发送SAVI设备可能不执行任何操作（在
this case, the state would eventually change after a maximum DEFAULT_LT time; if the node at VP does not respond to a NUD_NSOL at TESTING_VP, the state is moved to NO_BIND). Then, a packet arriving from VP' would trigger a process that may end up with binding for the node connecting to VP'.
在这种情况下，状态最终会在最长违约时间后发生变化；如果VP处的节点在测试VP时未响应NUD（无约束），则状态将移动到“无约束”）。然后，从VP'到达的数据包将触发一个进程，该进程最终可能会绑定到连接到VP'的节点。
LIFETIME expires:
生命周期到期：
o If LIFETIME expires, a secured NUD_NSOL message is sent through the BINDING_ANCHOR port to IPaddr, the LIFETIME is set to TENT_LT, and the state is changed to TESTING_VP. In the TESTING_VP state, packets are still being forwarded until the timer expires without receiving a NUD_NADV.
o 如果生存期到期，将通过绑定锚端口向IPaddr发送一条受保护的NUD\u NSOL消息，生存期设置为TENT\u LT，状态更改为TESTING\u VP。在TESTING_VP状态下，数据包仍在转发，直到计时器过期而没有收到NUD_NADV。
TESTING_VP
测试
When the SEND SAVI device enters the TESTING_VP state, the current Validating port is under check through a secured NUD_NSOL message generated by the SEND SAVI device. While testing, packets from the current Validating port are forwarded. Packets coming from Trusted ports are also forwarded. The relevant events for this state are the reception of a NUD_NADV message from VP; the reception of a DAD_NSOL message from VP, VP', or TP; the reception of any packet other than the previous cases from VP, VP', or TP; and the expiration of the timer associated to the reception of NUD_NADV.
当发送SAVI设备进入测试VP状态时，当前验证端口通过发送SAVI设备生成的安全NUD NSOL消息进行检查。测试时，转发来自当前验证端口的数据包。来自受信任端口的数据包也会被转发。该状态的相关事件是接收到VP的NUD_NADV消息；接收来自VP、VP'或TP的DAD\u NSOL消息；从VP、VP'或TP接收除先前情况以外的任何数据包；以及与NUD_NADV的接收相关联的计时器的到期。
Messages received from the BINDING_ANCHOR port:
从绑定锚端口接收的消息：
o If a validated NUD_NADV is received from VP, the LIFETIME is changed to DEFAULT_LT, and the state is changed to VALID. The message is not forwarded to any other port.
o 如果从VP接收到已验证的NUU NADV，则生存期将更改为默认值，状态将更改为有效。消息不会转发到任何其他端口。
o If a validated DAD_NSOL message is received from VP, it is forwarded to the appropriate Trusted ports, the LIFETIME is set to DEFAULT_LT, and the state is changed to TENTATIVE_DAD.
o 如果从VP接收到已验证的DAD\u NSOL消息，则该消息将转发到相应的受信任端口，生存期设置为默认值，状态更改为暂定的\u DAD。
o Any packet other than DAD_NSOL or NUD_NADV containing IPaddr as a source address arriving from the BINDING_ANCHOR port is forwarded. Neither the LIFETIME nor the state are changed.
o 除了DAD\u NSL或NUD\u NADV之外，任何包含IPaddr作为源地址的数据包（从绑定锚端口到达）都会被转发。生命周期和状态都不会改变。
Messages received from a Trusted port:
从受信任端口接收的消息：
o If a DAD_NSOL packet is received from a Trusted port, the message is forwarded to VP and the appropriate Trusted ports. Neither the LIFETIME nor the state are changed. The node at the BINDING_ANCHOR port is under check; if it still is at this port, it should answer with a NUD_NADV and also with a DAD_NADV. If it is not there, neither the NUD_NADV nor the DAD_NADV will be
o 如果从受信任端口接收到DAD\u NSOL数据包，则消息将转发到VP和相应的受信任端口。生命周期和状态都不会改变。绑定锚端口的节点正在检查中；如果它仍然在这个端口，它应该用一个NUD_-NADV和一个DAD_-NADV应答。如果它不在那里，努德纳德夫和达德纳德夫都不会在那里
received, the timer will expire, and the local state will move to NO_BIND.
收到后，计时器将过期，并且本地状态将移动到NO_BIND。
o If a packet other than a DAD_NSOL arrives from a Trusted port, the packet is forwarded. Neither the LIFETIME nor the state are changed.
o 如果来自受信任端口的数据包不是DAD\u NSL，则该数据包将被转发。生命周期和状态都不会改变。
Messages received from a Validating port different from the BINDING_ANCHOR:
从不同于绑定锚的验证端口接收的消息：
o If a valid DAD_NSOL is received from a Validating port VP' other than the current BINDING_ANCHOR port, the message is forwarded to the BINDING_ANCHOR port and to the appropriate Trusted ports. In addition, a secured NUD_NSOL is sent to the BINDING_ANCHOR port, the ALTERNATIVE BINDING ANCHOR is set to VP' (for future use if the node at VP' is finally selected), the LIFETIME is set to TENT_LT, and the state is changed to TESTING_VP'.
o 如果从验证端口VP'而不是当前绑定锚端口接收到有效的DAD\u NSOL，则消息将转发到绑定锚端口和适当的受信任端口。此外，安全的NUD_NSOL被发送到绑定_锚端口，备用绑定锚设置为VP'（如果最终选择了VP'处的节点，供将来使用），生存期设置为TENT_LT，状态更改为TESTING_VP'。
o Any other packet received from a Validating port VP' other than the BINDING_ANCHOR port is discarded. This may occur because the node has moved but has not issued a DAD_NSOL or the DAD_NSOL message has been lost. The state will eventually move to NO_BIND, and then the packets sent from VP' will trigger the creation of the binding for VP'.
o 从验证端口VP'接收的任何其他数据包（绑定锚端口除外）将被丢弃。这可能是因为节点已移动但尚未发出DAD\u NSL或DAD\u NSL消息已丢失。该状态最终将移动到NO_BIND，然后从VP'发送的数据包将触发为VP'创建绑定。
LIFETIME expires:
生命周期到期：
o If the LIFETIME expires, the LIFETIME is cleared and the state is changed to NO_BIND.
o 如果生存期到期，将清除生存期，并将状态更改为“无绑定”。
TESTING_VP'
测试VP'
To arrive at this state, the SEND SAVI device has received an indication that a node at VP' different from the BINDING_ANCHOR port wants to send data with IPaddr as a source address and has occurred while a binding existed for VP. The port VP' that triggered the change of the state to TESTING_VP' was stored at the ALTERNATIVE_BINDING_ANCHOR, so that it can be retrieved if the node at VP' is determined as the legitimate owner of IPaddr. The SEND SAVI device has issued a NUD_NSOL to IPaddr through the BINDING_ANCHOR port. The relevant events that may occur in this case are the reception of a NUD_NADV from port VP (the BINDING_ANCHOR port); the reception of a DAD_NSOL from VP, VP', TP, and VP" (VP" different from VP and VP'); the reception of any other packet from VP, VP', TP, or VP"; and the expiration of the timer.
要达到此状态，SEND SAVI设备已接收到一个指示，表明位于VP'的节点（与绑定锚端口不同）希望使用IPaddr作为源地址发送数据，并且在VP存在绑定时发生。触发状态更改为TESTING_VP的端口VP'存储在备用_BINDING_锚中，因此，如果VP'处的节点被确定为IPaddr的合法所有者，则可以检索该端口。发送SAVI设备已通过绑定锚端口向IPaddr发出NUD\u NSOL。在这种情况下可能发生的相关事件是从端口VP（绑定锚端口）接收NUD_NADV；接收来自VP、VP'，TP和VP（VP“不同于VP和VP”）；接收来自VP、VP’、TP或VP”的任何其他数据包以及计时器到期。
Messages received from the BINDING_ANCHOR port:
从绑定锚端口接收的消息：
o A validated NUD_NADV is received from the BINDING_ANCHOR port. The reception of a valid NUD_NADV indicates that the node at VP is defending its address. The BINDING_ANCHOR in use is kept, the LIFETIME is set to DEFAULT_LT, and the state is changed to VALID.
o 从BINDING_锚点端口接收已验证的NUD_NADV。接收到有效的NUD_NADV表示VP处的节点正在保护其地址。保留正在使用的绑定锚，将生存期设置为默认值，并将状态更改为有效。
o If a valid DAD_NSOL is received from the BINDING_ANCHOR port, it is forwarded to VP' (the port stored in the ALTERNATIVE_BINDING_ANCHOR). The BINDING_ANCHOR in use is kept, the LIFETIME is set to TENT_LT, and the state is changed to TENTATIVE_DAD. When the DAD_NSOL message is received by the node at VP', the address will not be configured.
o 如果从绑定锚端口接收到有效的DAD\u NSOL，它将转发到VP'（存储在备用绑定锚中的端口）。使用中的绑定锚被保留，生存期设置为TENT\u LT，状态更改为暂定\u DAD。当节点在VP'处接收到DAD\u NSOL消息时，将不配置地址。
o Any packet other than a validated DAD_NSOL, or a validated NUD_NADV coming from the BINDING_ANCHOR port, is forwarded, and the state is not changed.
o 除了来自绑定锚端口的已验证DAD_NSL或已验证NUD_NADV之外的任何数据包都会被转发，并且状态不会更改。
Messages received from the ALTERNATIVE_BINDING_ANCHOR Validating port:
从备用\u绑定\u锚验证端口接收的消息：
o If a valid DAD_NSOL is received from the port stored in the ALTERNATIVE_BINDING_ANCHOR, it is forwarded to the BINDING_ANCHOR port. The BINDING_ANCHOR and the ALTERNATIVE BINDING ANCHOR are kept, the LIFETIME is set to DEFAULT_LT, and the state is not changed.
o 如果从备用绑定锚中存储的端口接收到有效的DAD\u NSOL，则会将其转发到绑定锚端口。将保留绑定锚定和备用绑定锚定，生存期设置为默认值，状态不变。
o Any packet other than a validated DAD_NSOL coming from the ALTERNATIVE_BINDING_ANCHOR port is discarded, and the state is not changed.
o 除了来自备用绑定锚端口的已验证DAD\u NSL之外的任何数据包都将被丢弃，并且状态不会更改。
Messages received from a Validating port different from the BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports:
从不同于绑定锚和备用绑定锚端口的验证端口接收的消息：
o If a validated DAD_NSOL is received from port VP", different from BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports, it is forwarded to the BINDING_ANCHOR and the ALTERNATIVE_BINDING_ANCHOR ports. The node at the ALTERNATIVE BINDING ANCHOR port is expected to unconfigure its address if the message triggering the transition to this state was a DAD_NSOL message received from the ALTERNATIVE_BINDING_ANCHOR port (and not any other packet). The state remains in TESTING_VP', although VP" is stored in the ALTERNATIVE_BINDING_ANCHOR for future use if the node at VP" is finally selected. The LIFETIME is not changed.
o 如果从端口VP接收到已验证的DAD\u NSOL“，与绑定锚和备用绑定锚端口不同，它被转发到绑定锚和备用绑定锚端口。如果触发转换到此状态的消息是从备用绑定锚端口（而不是任何其他数据包）接收的DAD\u NSOL消息，则备用绑定锚端口处的节点应取消其地址配置。虽然VP“存储在备用的_绑定_锚中，以备将来在最终选择VP处的节点时使用，但状态仍保持在测试_VP'中。生命周期没有改变。
o Any packet other than a validated DAD_NSOL received from port VP" is discarded and does not affect the state.
o 除了从“端口VP”接收的已验证数据包之外的任何数据包都将被丢弃，并且不会影响状态。
Messages received from a Trusted port:
从受信任端口接收的消息：
o If a DAD_NSOL is received from a Trusted port, the message is forwarded to the BINDING_ANCHOR, ALTERNATIVE_BINDING_ANCHOR ports, and other appropriate Trusted ports. The LIFETIME is left unchanged, and the state is changed to TESTING_VP. The node at the ALTERNATIVE_BINDING_ANCHOR port is expected to unconfigure its address if the packet triggering the transition to this state was a DAD_NSOL message received from the ALTERNATIVE_BINDING_ANCHOR port.
o 如果从受信任端口接收到DAD\u NSOL，则消息将转发到绑定锚、备用绑定锚端口和其他适当的受信任端口。生命周期保持不变，状态更改为TESTING_VP。如果触发转换到此状态的数据包是从备用\u绑定\u锚端口接收的DAD \u NSOL消息，则备用\u绑定\u锚端口处的节点应取消其地址配置。
o Any packet other than a DAD_NSOL coming from a Trusted port is forwarded appropriately, but the state is not changed.
o 来自受信任端口的除DAD\u NSL之外的任何数据包都会被适当地转发，但状态不会改变。
LIFETIME expires:
生命周期到期：
o If LIFETIME expires, it is assumed that the node for which the binding existed is no longer connected through the BINDING_ANCHOR port. Therefore, the BINDING_ANCHOR is set to the ALTERNATIVE_BINDING_ANCHOR port value. The LIFETIME is set to DEFAULT_LT, and the state is changed to VALID.
o 如果生存期到期，则假定存在绑定的节点不再通过绑定锚端口连接。因此，绑定锚被设置为可选的绑定锚端口值。生存期设置为默认值，状态更改为有效。
TENTATIVE_NUD
试探性的
To arrive at this state, a data packet has been received through the BINDING_ANCHOR port without any existing binding in the SEND SAVI device. The SEND SAVI device has sent a NUD_NSOL message to the BINDING_ANCHOR port. The relevant events for this case are the reception of a NUD_NADV from the BINDING_ANCHOR port; the reception of a DAD_NSOL from the BINDING_ANCHOR port, other VP different from the BINDING_ANCHOR port, or a TP; and the reception of any packet other than a DAD_NSOL and a NUD_NADV from the BINDING_ANCHOR port and a DAD_NSOL for other VP different from the BINDING_ANCHOR port, or TP. In addition, the LIFETIME may expire.
为了达到这种状态，通过绑定锚端口接收到数据包，发送SAVI设备中没有任何现有绑定。发送SAVI设备已向绑定锚端口发送NUD_NSOL消息。本案的相关事件包括从BINDING_锚港接收NUD_NADV；从绑定锚端口、与绑定锚端口不同的其他VP或TP接收DAD\u NSOL；以及从绑定锚端口接收除DAD_-nsl和NUD_-NADV之外的任何分组，以及接收与绑定锚端口或TP不同的其他VP的DAD_-nsl。此外，生存期可能会到期。
Messages received from the BINDING_ANCHOR port:
从绑定锚端口接收的消息：
o If a validated NUD_NADV message is received through the BINDING_ANCHOR port, the LIFETIME is set to TENT_LT, and the state is changed to VALID. The message is not forwarded to any port.
o 如果通过BINDING_锚端口接收到已验证的NUD_NADV消息，则生存期设置为TENT_LT，状态更改为VALID。消息不会转发到任何端口。
o If a validated DAD_NSOL message is received through the BINDING_ANCHOR port, it is forwarded to the appropriate Trusted ports, the LIFETIME is set to TENT_LT, and the state is changed to TENTATIVE_DAD.
o 如果通过绑定锚端口接收到已验证的DAD\u NSOL消息，则会将其转发到相应的受信任端口，生存期设置为TENT\u LT，状态更改为暂定的DAD。
o Any packet other than NUD_NADV or DAD_NSOL received through the BINDING_ANCHOR port is discarded.
o 除了通过绑定锚端口接收的NUD_NADV或DAD_NSL之外的任何数据包都将被丢弃。
Messages received from a Validating port different from the BINDING_ANCHOR:
从不同于绑定锚的验证端口接收的消息：
o If a validated DAD_NSOL message is received through port VP' different from the BINDING_ANCHOR port, it is forwarded to the appropriate Trusted ports, the LIFETIME is set to TENT_LT, the BINDING_ANCHOR is set to VP', and the state is changed to TENTATIVE_DAD.
o 如果通过与绑定锚端口不同的端口VP'接收已验证的DAD\u NSOL消息，则会将其转发到相应的受信任端口，生存期设置为TENT\u LT，绑定锚设置为VP'，状态更改为暂定DAD。
o Any packet other than validated DAD_NSOL received through port VP' MUST NOT be forwarded unless the next state for the binding is VALID. The packets received MAY be discarded or MAY be stored to be sent if the state changes later to VALID. The state is left unchanged.
o 除非绑定的下一个状态有效，否则不得转发通过端口“VP”接收的已验证数据包以外的任何数据包。接收到的分组可以被丢弃，或者如果稍后状态变为有效，则可以被存储以发送。状态保持不变。
Messages received from a Trusted port:
从受信任端口接收的消息：
o If a DAD_NSOL message is received through a Trusted port, it is forwarded to the BINDING_ANCHOR port, and the state is left unchanged.
o 如果通过受信任的端口接收DAD\u NSOL消息，则会将其转发到绑定锚端口，并且状态保持不变。
o Any other packet received from a Trusted port is forwarded appropriately. This packet may come from a SEND SAVI device that has securely validated the attachment of the node to its Validating port, according to SEND SAVI rules. The state is left unchanged.
o 从受信任端口接收的任何其他数据包都会被适当地转发。根据发送SAVI规则，此数据包可能来自已安全验证节点到其验证端口的连接的发送SAVI设备。状态保持不变。
LIFETIME expires:
生命周期到期：
o If LIFETIME expires, the LIFETIME is cleared and the state is changed to NO_BIND.
o 如果生存期到期，将清除生存期并将状态更改为“无绑定”。
The detailed guidelines for port configuration in SEND SAVI devices are:
SEND SAVI设备中端口配置的详细指南如下：
o Ports connected to another SEND SAVI device MUST be configured as Trusted ports. Not doing so will prevent off-link traffic from being forwarded, along with the following effects for on-link traffic: significantly increase the CPU time, memory consumption, and signaling traffic due to SEND SAVI validation, in both the SEND SAVI devices and the node whose address is being validated.
o 连接到另一个SEND SAVI设备的端口必须配置为受信任端口。不这样做将阻止转发断开链路的通信量，以及对链路上通信量的以下影响：由于发送SAVI验证，在发送SAVI设备和地址正在验证的节点中，CPU时间、内存消耗和信令通信量都会显著增加。
o Ports connected to hosts SHOULD be configured as Validating ports. Not doing so will allow the host connected to that port to send packets with a spoofed source address.
o 连接到主机的端口应配置为验证端口。不这样做将允许连接到该端口的主机发送带有伪造源地址的数据包。
o No more than one host SHOULD be connected to each port. Connecting more than one host to a port will allow hosts to generate packets with the same source address as the other hosts connected to the same port, and will allow replaying attacks to be performed as described in Section 5.1.
o 每个端口最多只能连接一台主机。将多个主机连接到一个端口将允许主机生成与连接到同一端口的其他主机具有相同源地址的数据包，并允许按照第5.1节中的说明执行重播攻击。
o Ports connected to routers MUST be configured as Trusted ports. Not doing so results in SEND SAVI devices discarding off-link traffic. Note that this means that since routers are connected through Trusted ports, they can generate traffic with any source address, even those belonging to the link.
o 连接到路由器的端口必须配置为受信任端口。不这样做会导致发送SAVI设备丢弃断开链路的通信量。请注意，这意味着由于路由器是通过受信任的端口连接的，因此它们可以生成具有任何源地址的通信量，即使是属于链路的源地址。
o Ports connected to a chain of one or more legacy switches that have other SEND SAVI devices but have no routers or hosts attached to them SHOULD be configured as Trusted ports. Not doing so will significantly increase the memory consumption in the SEND SAVI devices and increase the signaling traffic due to SEND SAVI validation.
o 连接到一个或多个具有其他SEND SAVI设备但未连接路由器或主机的传统交换机链的端口应配置为受信任端口。不这样做将显著增加发送SAVI设备中的内存消耗，并由于发送SAVI验证而增加信令流量。
In the case where the SEND SAVI device is a switch that supports customer VLANs [IEEE.802-1Q.2005], the SEND SAVI specification MUST behave as if there was one SEND SAVI process per customer VLAN. The SEND SAVI process of each customer VLAN will store the binding information corresponding to the nodes attached to that particular customer VLAN.
如果发送SAVI设备是支持客户VLAN的交换机[IEEE.802-1Q.2005]，则发送SAVI规范的行为必须如同每个客户VLAN有一个发送SAVI进程一样。每个客户VLAN的发送SAVI进程将存储与连接到该特定客户VLAN的节点对应的绑定信息。
TENT_LT is 500 milliseconds.
这是500毫秒。
DEFAULT_LT is 5 minutes.
默认值为5分钟。
In this section, we include two cases that illustrate the behavior of
SEND SAVI, the change of the attachment port of a host, and the
attack of a malicious host. We use the topology depicted in
Figure 4.
+---+
| H |
+---+
|
|
+-1-----2-+ +-1-----2-+
| | | |
| SAVI1 | | SAVI2 |
| | | |
+-3-----4-+ +-3-----4-+
| |
-------------------
In this section, we include two cases that illustrate the behavior of
SEND SAVI, the change of the attachment port of a host, and the
attack of a malicious host. We use the topology depicted in
Figure 4.
+---+
| H |
+---+
|
|
+-1-----2-+ +-1-----2-+
| | | |
| SAVI1 | | SAVI2 |
| | | |
+-3-----4-+ +-3-----4-+
| |
-------------------
Figure 4: Reference SEND SAVI Topology for Protocol Walk-Through
图4：协议遍历的参考发送SAVI拓扑
There are two cases, depending on whether the host H moves to a different port on the same switch or to a different switch.
有两种情况，这取决于主机H是移动到同一交换机上的不同端口，还是移动到不同的交换机。
Host H is connected to port 1 of SAVI1 and moves to port 2 of the same switch. Before moving, the SEND SAVI state associated to IPH, the IP address of H, is:
主机H连接到SAVI1的端口1，并移动到同一交换机的端口2。移动前，与IPH（H的IP地址）关联的发送SAVI状态为：
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
In the general case, H issues a DAD_NSOL message for IPH when it is connected to a different port. When SAVI1 receives this message, it validates it and changes its state to:
在一般情况下，H在连接到其他端口时会为IPH发出DAD\u NSL消息。SAVI1收到此消息后，将对其进行验证并将其状态更改为：
SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2,
TIMER=TENT_LT / SAVI2=NO_BIND
SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2,
TIMER=TENT_LT / SAVI2=NO_BIND
The DAD_NSOL message is propagated to port 1, because it is the current BINDING_ANCHOR, and the Trusted port 3; it is not propagated to Validating port 4. SAVI1 configures a timer for TENT_LT seconds. In addition, SAVI1 generates a NUD_NSOL and sends it through port 1. When SAVI2 receives this message through its Trusted port, it discards it and remains in the NO_BIND state.
DAD\u NSOL消息被传播到端口1，因为它是当前绑定锚和受信任端口3；它不会传播到验证端口4。SAVI1配置了一个帐篷秒计时器。此外，SAV1生成NUD_NSOL并通过端口1发送。当SAVI2通过其受信任端口接收此消息时，它将丢弃该消息并保持NO_BIND状态。
SAVI1 waits for a NUD_NADV message to be received from port 1. Since there is no node attached to 1, there is no response for either of these messages. When TENT_LT expires at SAVI1, the state changes to:
SAVI1等待从端口1接收NUD_NADV消息。由于没有节点连接到1，因此这些消息都没有响应。当帐篷在SAVI1到期时，状态变为：
SAVI1=VALID, BINDING_ANCHOR=2 / SAVI2=NO_BIND
SAVI1=VALID, BINDING_ANCHOR=2 / SAVI2=NO_BIND
If the node moving does not issue a DAD_NSOL when it attaches to port 2, then SAVI1 will receive a data packet through this port. The data packet is discarded, SAVI1 issues a secured NUD_NSOL through port 1, and the state changes to TESTING_VP'.
如果移动节点在连接到端口2时未发出DAD\u NSOL，则SAV1将通过该端口接收数据包。数据包被丢弃，SAV1通过端口1发出一个安全的NUD_NSOL，状态更改为TESTING_VP'。
SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2
TIMER=TENT_LT / SAVI2=NO_BIND
SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2
TIMER=TENT_LT / SAVI2=NO_BIND
SAVI1 waits for a NUD_NADV message to be received from port 1. Since there is no node attached to 1, there is no response for neither of these messages. When TENT_LT expires at SAVI1, the state changes to:
SAVI1等待从端口1接收NUD_NADV消息。由于没有节点连接到1，因此这两条消息都没有响应。当帐篷在SAVI1到期时，状态变为：
SAVI1=VALID, BINDING_ANCHOR=2 / SAVI2=NO_BIND
SAVI1=VALID, BINDING_ANCHOR=2 / SAVI2=NO_BIND
An alternative behavior allowed by the specification for the case in which the host does not issue a DAD_NSOL is that SAVI1 does nothing. In this case, after some time (bounded by DEFAULT_LT), the switch will change the state for IPH to TESTING_VP, check if H is still at port 1 (which it is not), and move the state to NO_BIND. Then, a packet arriving from port 2 would trigger a process that finishes with a VALID stated with BINDING_ANCHOR=2.
对于主机不发出DAD\u NSOL的情况，规范允许的另一种行为是SAV1不执行任何操作。在这种情况下，经过一段时间（默认值为\u LT）后，交换机将IPH的状态更改为TESTING\u VP，检查H是否仍在端口1（不是），并将状态移动到NO\u BIND。然后，从端口2到达的数据包将触发一个进程，该进程以绑定_ANCHOR=2的有效声明结束。
Host H, connected to port 1 of SAVI1, moves to port 4 of SAVI2. Before moving, the SEND SAVI state associated to IPH, the IP address of H, is:
主机H连接到SAVI1的端口1，移动到SAVI2的端口4。移动前，与IPH（H的IP地址）关联的发送SAVI状态为：
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
If H issues a DAD_NSOL message for IPH when it connects to port 4 of SAVI2, the state is changed to:
如果H在连接到SAVI2的端口4时发出IPH的DAD_NSOL消息，则状态更改为：
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_DAD,
BINDING_ANCHOR=4, TIMER=TENT_LT
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_DAD,
BINDING_ANCHOR=4, TIMER=TENT_LT
The DAD_NSOL message is propagated only through the Trusted port of SAVI2. Then, SAVI1 changes its state as follows:
DAD_NSOL消息仅通过SAVI2的受信任端口传播。然后，SAVI1将其状态更改如下：
SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT /
SAVI2=TENTATIVE_DAD, BINDING_ANCHOR=4, TIMER=TENT_LT
SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT /
SAVI2=TENTATIVE_DAD, BINDING_ANCHOR=4, TIMER=TENT_LT
SAVI1 propagates the DAD_NSOL message to port 1. Since the only node that can answer with a secured DAD_NUD has moved, the timer at SAVI2 expires, and SAVI2 changes its state to VALID:
SAV1将DAD\u NSOL消息传播到端口1。由于唯一可以使用安全DAD_NUD进行应答的节点已移动，SAVI2的计时器将过期，SAVI2将其状态更改为有效：
SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT / SAVI2=VALID,
BINDING_ANCHOR=4
SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT / SAVI2=VALID,
BINDING_ANCHOR=4
Just a very short time after, the timer at SAVI1 expires, and the state changes to NO_BIND:
就在很短的时间之后，SAVI1的计时器过期，状态变为NO_BIND：
SAVI1=NO_BIND / SAVI2=VALID, BINDING_ANCHOR=4
SAVI1=NO_BIND / SAVI2=VALID, BINDING_ANCHOR=4
If host H does not send a DAD_NSOL when it moves to SAVI2 but instead sends a data packet, SAVI2 changes its state to TENTATIVE_NUD:
如果主机H在移动到SAVI2时不发送DAD\u NSOL，而是发送数据包，则SAVI2将其状态更改为暂定NUD：
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_NUD,
BINDING_ANCHOR=4, TIMER=TENT_LT
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_NUD,
BINDING_ANCHOR=4, TIMER=TENT_LT
SAVI2 issues a secured NUD_NSOL through port 4. H is assumed to have the address configured (otherwise, it should not have generated a data packet), so it can respond with a NUD_NADV. When SAVI1 receives the NUD_NADV and validates it, the state is changed to VALID:
SAVI2通过端口4发出安全NUD_NSOL。假设H配置了地址（否则，它不应该生成数据包），因此它可以使用NUD_NADV进行响应。当SAV1接收到NUD_NADV并对其进行验证时，状态变为有效：
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=VALID, BINDING_ANCHOR=4
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=VALID, BINDING_ANCHOR=4
After some time (bounded by DEFAULT_LT), the state in SAVI1 will expire, and SAVI1 will perform a check for host H:
一段时间后（默认情况下有界），SAV1中的状态将过期，SAV1将对主机H执行检查：
SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT / SAVI2=VALID,
BINDING_ANCHOR=4
SAVI1=TESTING_VP, BINDING_ANCHOR=1, TIMER=TENT_LT / SAVI2=VALID,
BINDING_ANCHOR=4
SAVI1 issues a NUD_NSOL through port 1 for IPH. No response is received in this case, so SAVI1 changes its state to NO_BIND:
SAVI1通过IPH的端口1发布NUD_NSOL。在这种情况下没有收到响应，因此SAV1将其状态更改为“无绑定”：
SAVI1=NO_BIND / SAVI2=VALID, BINDING_ANCHOR=4
SAVI1=NO_BIND / SAVI2=VALID, BINDING_ANCHOR=4
Host H is attached to the SEND SAVI infrastructure through port 1 of SAVI1. We consider that host M starts sending data packets using IPH (the IP address of H) as the source address, without issuing a DAD_NSOL (a similar analysis can be done for this case).
主机H通过SAV1的端口1连接到发送SAVI基础设施。我们认为，主机M开始发送数据包使用IPH（IP地址的H）作为源地址，而不发布DADYNSOL（可以进行类似的分析，这种情况下）。
The initial state before the attack of M is:
M攻击前的初始状态为：
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
M attaches to port 2 of SAVI1 and starts sending data packets. When SAVI1 receives the data packet, the packet is discarded. SEND SAVI may issue a secured NUD_NSOL through port 1 and changes the state to:
M连接到SAV1的端口2并开始发送数据包。当SAVI1接收到数据分组时，该分组被丢弃。SEND SAVI可通过端口1发出安全NUD_NSOL，并将状态更改为：
SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2,
TIMER=TENT_LT / SAVI2=NO_BIND
SAVI1=TESTING_VP', BINDING_ANCHOR=1, ALTERNATIVE_BINDING_ANCHOR=2,
TIMER=TENT_LT / SAVI2=NO_BIND
Host H is still attached to port 1, so it receives the NUD_NSOL and responds with a secured NUD_NADV. SAVI1 receives this message, validates it, and changes its state again to:
主机H仍然连接到端口1，因此它接收NUD_NSOL并使用安全的NUD_NADV进行响应。SAVI1接收此消息，对其进行验证，并再次将其状态更改为：
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
To prevent the drain of CPU resources in SAVI1, the processing of further packets received from port 2 may be rate-limited, as discussed in Section 5.2.
如第5.2节所述，为了防止SAV1中CPU资源的流失，从端口2接收的其他数据包的处理可能会受到速率限制。
An alternative to the previous behavior is that SAVI1 does nothing when node M starts sending packets from port 2. In this case, when the timer to renew the state triggers (this time it's bounded by DEFAULT_LT), SAVI1 moves the state to TESTING_VP, sends a NUD_NSOL through port 1, host H responds, and the state remains in VALID for BINDING_ANCHOR=1. In this way, communication of host H is also defended.
前一种行为的替代方法是，当节点M开始从端口2发送数据包时，SAVI1不执行任何操作。在这种情况下，当更新状态的计时器触发时（这一次为默认值\u LT所限定），SAVI1将状态移动到测试\u VP，通过端口1发送NUD\u NSOL，主机H响应，并且该状态对于绑定\u ANCHOR=1保持有效。这样，主机H的通信也受到了保护。
The initial state before the attack of M is:
M攻击前的初始状态为：
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
M attaches to port 2 of SAVI2 and starts sending data packets. When SAVI2 receives the data packet, it changes the state to:
M连接到SAVI2的端口2并开始发送数据包。当SAVI2接收到数据包时，它将状态更改为：
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_DAD,
BINDING_ANCHOR=2, TIMER=TENT_LT
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=TENTATIVE_DAD,
BINDING_ANCHOR=2, TIMER=TENT_LT
SAVI2 issues a secured NUD_NSOL through port 2. Since M does not own the IPH CGA, it cannot respond to the message. When the timer expires, the state is moved back to:
SAVI2通过端口2发布安全NUD_NSOL。由于M不拥有IPH CGA，因此它无法响应该消息。计时器到期时，状态移回：
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
SAVI1=VALID, BINDING_ANCHOR=1 / SAVI2=NO_BIND
To prevent the drain of CPU resources in SAVI2, the processing of further packets received from port 2 may be rate-limited, as discussed in Section 5.2.
如第5.2节所述，为了防止SAVI2中CPU资源的流失，从端口2接收的其他数据包的处理可能会受到速率限制。
SEND SAVI operates only with validated SEND messages to create bindings. Note that IPv6 packets generated by non-SEND nodes will be discarded by the first SEND SAVI device receiving it. Therefore, attackers cannot obtain any benefit by not using SEND. In order to perform address validation in a mixed scenario comprising SEND and non-SEND devices, a different solution is required, which should be addressed in another document.
SEND SAVI仅使用已验证的发送消息来创建绑定。请注意，由非发送节点生成的IPv6数据包将被接收它的第一个发送SAVI设备丢弃。因此，攻击者无法通过不使用SEND获得任何好处。为了在由发送设备和非发送设备组成的混合场景中执行地址验证，需要一个不同的解决方案，该解决方案应在另一个文档中解决。
Nodes MUST NOT assume that all SEND messages received from a SEND SAVI device are validated, since these devices only validate the messages strictly required for SEND SAVI operation. Among the number of messages that are not validated by SEND SAVI, we can name NUD_NSOL messages generated by other nodes and its corresponding NUD_NADV responses, or RSOL messages.
节点不得假设从发送SAVI设备接收的所有发送消息都经过验证，因为这些设备仅验证发送SAVI操作严格要求的消息。在SEND SAVI未验证的消息数量中，我们可以将其他节点生成的NUD_NSOL消息及其相应的NUD_NADV响应命名为RSOL消息。
SEND SAVI improves protection compared to conventional SAVI as a result of the increased ability of SEND nodes to prove address ownership.
由于发送节点证明地址所有权的能力增强，因此与传统SAVI相比，发送SAVI改进了保护。
A critical security consideration regarding SEND SAVI deals with the need of proper configuration of the roles of the ports in a SEND SAVI deployment scenario. Regarding security, the main requirement is that ports defining the protected perimeter SHOULD be configured as Validating ports. Not doing so will allow an attacker to send packets using any source address, regardless of the bindings established in other SEND SAVI devices.
关于SEND-SAVI的一个关键安全考虑事项涉及在SEND-SAVI部署场景中正确配置端口角色的需要。关于安全性，主要要求是定义受保护周界的端口应配置为验证端口。不这样做将允许攻击者使用任何源地址发送数据包，而不考虑在其他send SAVI设备中建立的绑定。
One possible concern about SEND SAVI is its behavior when an attacker tries to forge the identity of a legitimate node by replaying SEND messages used by the SEND SAVI specification. An attacker could replay any of these messages to interfere with the SEND SAVI operation. For example, it could replay a DAD_NSOL message to abort the configuration of an address for a legitimate node and to gain the right to use the address for DEFAULT_LT seconds.
有关SEND SAVI的一个可能的问题是，当攻击者试图通过重播SEND SAVI规范使用的SEND消息来伪造合法节点的身份时，SEND SAVI的行为。攻击者可以重播这些消息中的任何一条来干扰SEND SAVI操作。例如，它可以重播DAD\u NSOL消息以中止合法节点的地址配置，并获得在默认\u LT秒内使用该地址的权利。
We can analyze two different cases when considering SEND SAVI replay attacks:
在考虑发送SAVI重播攻击时，我们可以分析两种不同的情况：
o When the SEND message replayed is used to create or update binding information for SEND SAVI, since the port through which this message is received is key to the SEND SAVI operation. SEND SAVI creates and maintains bindings as a result of the reception of DAD_NSOL messages and of the exchange of NUD_NSOL/NUD_NADV messages.
o 当使用重播的发送消息创建或更新发送SAVI的绑定信息时，因为接收此消息的端口是发送SAVI操作的关键。SEND SAVI通过接收DAD_NSOL消息和交换NUD_NSOL/NUD_NADV消息来创建和维护绑定。
o When the SEND message replayed does not result in the update of binding information for SEND SAVI and, thus, is not related to the specific port through which it was received. Such situations are the reception of CPA messages containing certificates, and the processing of an RADV message coming from a Trusted port, which can be used in SEND SAVI to populate the SEND SAVI Prefix List. In these two cases, the security risks are equivalent to those of the SEND operation, i.e., we can consider that the information will not be changed by its legitimate sender for the time during which the SEND specification allows replaying (which depends on the values of TIMESTAMP_FUZZ and TIMESTAMP_DRIFT [RFC3971]).
o 当重播的发送消息不会导致发送SAVI的绑定信息的更新，因此与接收该消息的特定端口无关时。这种情况是接收包含证书的CPA消息，以及处理来自受信任端口的RADV消息，可在SEND SAVI中使用该端口填充SEND SAVI前缀列表。在这两种情况下，安全风险相当于发送操作的安全性，即，我们可以考虑，在发送规范允许重放的时间（其依赖于时间戳模糊和时间戳漂移[RCF971]）的情况下，信息不会由其合法发送者改变。
For replay of messages belonging to the second case, i.e., messages that do not result in changes in the SEND SAVI binding information, the security provided by SEND is sufficient. For the replay of messages belonging to the first case, DAD_NSOL and NUD_NSOL/NUD_NADV messages, protection results from the behavior of SEND SAVI, as specified in Section 3.3.2, which restricts the ports to which the messages involved in SEND SAVI binding updates are disseminated. SEND SAVI devices only forward these messages to ports for which a binding to the address being tested by the DAD_NSOL message existed. Therefore, it is not enough for an attacker to subscribe to a Solicited Node address to receive DAD_NSOL messages sent to that address, but the attacker needs to generate a valid DAD_NSOL message associated to the address for which the binding is being tested, which is deemed unfeasible [RFC3971].
对于属于第二种情况的消息的重播，即不会导致SEND SAVI绑定信息的更改的消息，SEND提供的安全性就足够了。对于属于第一种情况的消息（DAD_NSL和NUD_NSL/NUD_NADV消息）的重播，根据第3.3.2节的规定，发送SAVI的行为会产生保护，这将限制发送SAVI绑定更新中涉及的消息传播到的端口。发送SAVI设备仅将这些消息转发到存在与DAD\u NSOL消息测试的地址绑定的端口。因此，攻击者订阅请求的节点地址以接收发送到该地址的DAD\u NSOL消息是不够的，但攻击者需要生成与测试绑定的地址相关联的有效DAD\u NSOL消息，这被认为是不可行的[RFC3971]。
The attacks against the SEND SAVI device basically consist of making the SEND SAVI device consume its resources until it runs out of them. For instance, a possible attack would be to send packets with different source addresses, making the SEND SAVI device create state for each of the addresses and waste memory. At some point, the SEND SAVI device runs out of memory and needs to decide how to react. The result is that some form of garbage collection is needed to prune the entries. When the SEND SAVI device runs out of the memory allocated for the SEND SAVI Database, it is RECOMMENDED that it creates new entries by deleting the entries with a higher Creation time. This implies that older entries are preserved and newer entries overwrite each other. In an attack scenario where the attacker sends a batch of data packets with different source addresses, each new source address is likely to rewrite another source address created by the attack itself. It should be noted that entries are also garbage collected using the DEFAULT_LT, which is updated by NUD_NSOL/NUD_NADV exchanges. The result is that in order for an attacker to actually fill the SEND SAVI Database with false source addresses, it needs to continuously answer to NUD_NSOL for all the different source
对SEND SAVI设备的攻击基本上包括使SEND SAVI设备消耗其资源，直到资源耗尽为止。例如，可能的攻击是发送具有不同源地址的数据包，使发送SAVI设备为每个地址创建状态并浪费内存。有时，SEND SAVI设备内存不足，需要决定如何响应。结果是需要某种形式的垃圾收集来修剪条目。当SEND SAVI设备耗尽为SEND SAVI数据库分配的内存时，建议它通过删除创建时间较长的条目来创建新条目。这意味着旧条目将被保留，而新条目将相互覆盖。在攻击者发送具有不同源地址的一批数据包的攻击场景中，每个新的源地址都可能重写攻击本身创建的另一个源地址。应该注意的是，条目也使用默认值进行垃圾收集，默认值由NUD_NSL/NUD_NADV交换更新。结果是，为了让攻击者实际使用错误的源地址填充SEND SAVI数据库，它需要连续回答所有不同源的NUD_NSOL
addresses, so that the entries grow old and compete with the legitimate entries. The result is that the cost of the attack is highly increased for the attacker.
地址，以便条目变旧并与合法条目竞争。结果是攻击者的攻击成本大大增加。
In addition, it is also RECOMMENDED that a SEND SAVI device reserves a minimum amount of memory for each available port (in the case where the port is used as part of the L2 anchor). The REQUIRED minimum is the memory needed to store four bindings associated to the port, although it SHOULD be raised if the ratio between the maximum number of bindings allowed in the device and the number of ports is high. The motivation for setting a minimum number of bindings per port is as follows. An attacker attached to a given port of a SEND SAVI device may attempt to launch a DoS attack towards the SEND SAVI device by creating many bindings for different addresses. It can do so by sending DAD_NSOL for different addresses. The result is that the attack will consume all the memory available in the SEND SAVI device. The above recommendation aims to reserve a minimum amount of memory per port, so that nodes located in different ports can make use of the reserved memory for their port even if a DoS attack is occurring in a different port.
此外，还建议发送SAVI设备为每个可用端口保留最小内存量（如果端口用作L2锚的一部分）。所需的最小值是存储与端口关联的四个绑定所需的内存，但如果设备中允许的最大绑定数与端口数之间的比率较高，则应提高该值。设置每个端口的最小绑定数的动机如下。连接到SEND SAVI设备的给定端口的攻击者可能试图通过为不同地址创建多个绑定来对SEND SAVI设备发起DoS攻击。它可以通过发送不同地址的DAD\u NSOL来实现。结果是，攻击将消耗SEND SAVI设备中的所有可用内存。上述建议旨在为每个端口保留最小数量的内存，以便位于不同端口的节点可以利用其端口的保留内存，即使在不同端口中发生DoS攻击。
The SEND SAVI device may store data packets while the address is being verified, for example, when a DAD_NSOL is lost before arriving to the SEND SAVI device to which the host attaches; when the host sends data packets, these data packets may be stored until the SEND SAVI device verifies the binding by means of a NUD packet exchange. In this case, the memory for data packet storage may also be a target of DoS attacks. A SEND SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions (such as being able to store new bindings) to have available memory even in the case of an attack, such as those described above.
发送SAVI设备可以在验证地址时存储数据分组，例如，当在到达主机所连接的发送SAVI设备之前丢失数据分组时；当主机发送数据分组时，可以存储这些数据分组，直到发送SAVI设备通过NUD分组交换验证绑定为止。在这种情况下，用于数据包存储的内存也可能成为DoS攻击的目标。SEND SAVI设备必须限制用于存储数据包的内存量，允许其他功能（例如能够存储新绑定）即使在发生攻击（例如上述攻击）的情况下也具有可用内存。
It is worth noting that the potential of DoS attacks against the SEND SAVI network is increased due to the use of costly cryptographic operations in order to validate the address of the nodes. An attacker could generate packets using new source addresses in order to make the closest SEND SAVI device spend CPU time to validate DAD_NSOL messages or to generate a secure NUD_NSOL. This attack can be used to drain CPU resources of SEND SAVI devices with a very low cost for the attacker. In order to solve this problem, rate-limiting the processing of packets that trigger SEND SAVI events SHOULD be enforced on a per-port basis.
值得注意的是，由于使用昂贵的加密操作来验证节点的地址，因此针对SEND SAVI网络的DoS攻击的可能性增加。攻击者可以使用新的源地址生成数据包，以使最近的发送SAVI设备花费CPU时间来验证DAD\u NSOL消息或生成安全的NUD\u NSOL。此攻击可用于耗尽SEND SAVI设备的CPU资源，攻击者的成本非常低。为了解决这个问题，应该在每个端口的基础上对触发SEND SAVI事件的数据包的处理进行速率限制。
The SEND specification [RFC3971] proposes two deployment models for trust anchors: either a centralized model relaying on a globally rooted public key infrastructure or a more local, decentralized deployment model in which end hosts are configured with a collection of public keys that are trusted only on a domain.
SEND规范[RFC3971]为信任锚提出了两种部署模型：一种是在全局根公钥基础设施上中继的集中式模型，另一种是更本地的分散式部署模型，其中终端主机配置有一组仅在域上受信任的公钥。
The appeal of a centralized model is the possibility for hosts to use SEND to validate routers as they move through links belonging to different organizations without additional configuration. However, without any further protection, it also enables routers authorized with a certificate path rooted on a global trust anchor to appear as legitimate routers in a link in which they were not intended to act as such. This threat already existed for SEND deployments, for which links configured to accept centralized trust anchors may send outgoing traffic and use prefix information from alien routers. In a SEND SAVI deployment, such routers may be able to deliver off-link traffic to any node of the link.
集中式模型的吸引力在于，当路由器通过属于不同组织的链路时，主机可以使用发送来验证路由器，而无需额外配置。但是，在没有任何进一步保护的情况下，它还允许使用基于全局信任锚的证书路径授权的路由器在其不打算作为合法路由器的链路中显示为合法路由器。此威胁已存在于发送部署中，配置为接受集中式信任锚的链路可能会发送传出流量并使用来自外部路由器的前缀信息。在发送SAVI部署中，这样的路由器可以向链路的任何节点发送脱离链路的通信量。
In order to cope with this threat, SEND SAVI specifies that nodes are only allowed to behave as routers if they connect through Trusted ports. In particular, RADV messages and traffic with off-link source addresses are discarded when received through Validating ports, which are the ports intended for non-trusted infrastructure, as moving nodes. The protection provided by filtering RADV messages prevents SEND nodes from identifying alien routers as legitimate routers, even though the trust anchor of these routers is valid.
为了应对这种威胁，SEND SAVI规定，只有通过受信任端口连接的节点才允许充当路由器。特别是，当通过验证端口接收到RADV消息和具有非链接源地址的流量时，会丢弃这些消息和流量，这些端口是作为移动节点用于非可信基础设施的端口。过滤RADV消息所提供的保护可防止发送节点将外来路由器识别为合法路由器，即使这些路由器的信任锚是有效的。
Besides, it is worth to say that SEND SAVI supports a decentralized deployment model.
此外，值得一提的是SEND SAVI支持分散部署模型。
SEND SAVI assumes that a host will be able to defend its address when the DAD procedure is executed for its addresses, and that it will answer to a NUD_NSOL with a NUD_NADV when required. This is needed, among other things, to support mobility within a link (i.e., to allow a host to detach and reconnect to a different layer-2 anchor of the same IP subnetwork, without changing its IP address). If the SEND SAVI device does not see the DAD_NADV or the NUD_NADV, it may grant the binding to a different binding anchor. This means that if an attacker manages to prevent a host from defending its source address, it will be able to destroy the existing binding and create a new one, with a different binding anchor. An attacker may do so, for example, by launching a DoS attack to the host that will prevent it to issue proper replies.
SEND SAVI假设主机在为其地址执行DAD过程时能够保护其地址，并在需要时使用NUD_NADV对NUD_NSOL进行应答。除其他外，这需要支持链路内的移动性（即，允许主机分离并重新连接到同一IP子网的不同第2层锚，而不改变其IP地址）。如果发送SAVI设备没有看到DAD_NADV或NUD_NADV，它可能会将绑定授予不同的绑定锚。这意味着，如果攻击者成功阻止主机保护其源地址，它将能够破坏现有绑定并使用不同的绑定锚创建新绑定。攻击者可能会这样做，例如，通过对主机发起DoS攻击来阻止主机发出正确的回复。
A SEND SAVI device MUST delete binding anchor information as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND), except where there is an identified reason why that information is likely to be involved in the detection, prevention, or tracing of actual source address spoofing. Information about the majority of hosts that never spoof SHOULD NOT be logged.
发送SAVI设备必须尽快删除绑定锚定信息（即，一旦给定地址的状态恢复到无绑定状态），除非有确定的原因说明该信息可能涉及实际源地址欺骗的检测、预防或跟踪。不应记录绝大多数从不欺骗的主机的信息。
Thanks to Jean-Michel Combes, Ana Kukec, Ted Lemon, Adrian Farrel, Barry Leiba, Brian Haberman, Vicent Roca, and Benoit Claise for their reviews and comments on this document. The text has also benefited from feedback provided by Tony Cheneau and Greg Daley.
感谢Jean-Michel Combes、Ana Kukec、Ted Lemon、Adrian Farrel、Barry Leiba、Brian Haberman、Vicent Roca和Benoit Claise对本文件的评论和评论。文本还受益于托尼·切诺和格雷格·戴利提供的反馈。
Marcelo Bagnulo is partly funded by Trilogy 2, a research project supported by the European Commission under its Seventh Framework Program. Alberto Garcia-Martinez was supported, in part, by project TEC2012-38362-C03-01, granted by the Spanish Economy and Competitiveness Ministry.
Marcelo Bagnulo的部分资金来自Trilogy 2，该研究项目由欧盟委员会第七个框架计划支持。阿尔贝托·加西亚·马丁内斯（Alberto Garcia Martinez）得到了西班牙经济和竞争力部授予的TEC2012-38362-C03-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., 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月。
[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月。
[IEEE.802-1Q.2005] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks", IEEE Standard 802.1Q, May 2005.
[IEEE.802-1Q.2005]电气和电子工程师协会，“局域网和城域网/虚拟桥接局域网的IEEE标准”，IEEE标准802.1Q，2005年5月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements", RFC 6434, December 2011.
[RFC6434]Jankiewicz，E.，Loughney，J.和T.Narten，“IPv6节点要求”，RFC 64342011年12月。
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, May 2012.
[RFC6620]Nordmark，E.，Bagnulo，M.和E.Levy Abegnoli，“FCFS SAVI：本地分配IPv6地址的先到先得源地址验证改进”，RFC 6620，2012年5月。
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, "Source Address Validation Improvement (SAVI) Framework", RFC 7039, October 2013.
[RFC7039]Wu，J.，Bi，J.，Bagnulo，M.，Baker，F.，和C.Vogt，“源地址验证改进（SAVI）框架”，RFC 7039，2013年10月。
Authors' Addresses
作者地址
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
马德里卡洛斯三世大学。西班牙马德里勒加内斯30大学28911
Phone: 34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Phone: 34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Alberto Garcia-Martinez Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
阿尔贝托·加西亚·马丁内斯马德里卡洛斯三世大学。西班牙马德里勒加内斯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