Internet Engineering Task Force (IETF) E. Nordmark
Request for Comments: 6620 Cisco Systems
Category: Standards Track M. Bagnulo
ISSN: 2070-1721 UC3M
E. Levy-Abegnoli
Cisco Systems
May 2012
Internet Engineering Task Force (IETF) E. Nordmark
Request for Comments: 6620 Cisco Systems
Category: Standards Track M. Bagnulo
ISSN: 2070-1721 UC3M
E. Levy-Abegnoli
Cisco Systems
May 2012
FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses
FCFS SAVI：本地分配IPv6地址的先到先得源地址验证改进
Abstract
摘要
This memo describes First-Come, First-Served Source Address Validation Improvement (FCFS SAVI), a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing.
本备忘录描述了先到先得的源地址验证改进（FCFS SAVI），这是一种使用FCFS原则为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/rfc6620.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6620.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Background to FCFS SAVI .........................................4
2.1. Scope of FCFS SAVI .........................................4
2.2. Constraints for FCFS SAVI Design ...........................5
2.3. Address Ownership Proof ....................................5
2.4. Binding Anchor Considerations ..............................6
2.5. FCFS SAVI Protection Perimeter .............................6
2.6. Special Cases .............................................10
3. FCFS SAVI Specification ........................................11
3.1. FCFS SAVI Data Structures .................................12
3.2. FCFS SAVI Algorithm .......................................12
3.2.1. Discovering On-Link Prefixes .......................12
3.2.2. Processing of Transit Traffic ......................13
3.2.3. Processing of Local Traffic ........................13
3.2.4. FCFS SAVI Port Configuration Guidelines ............21
3.2.5. VLAN Support .......................................22
3.3. Default Protocol Values ...................................22
4. Security Considerations ........................................22
4.1. Denial-of-Service Attacks .................................22
4.2. Residual Threats ..........................................23
4.3. Privacy Considerations ....................................24
4.4. Interaction with Secure Neighbor Discovery ................25
5. Contributors ...................................................25
6. Acknowledgments ................................................25
7. References .....................................................26
7.1. Normative References ......................................26
7.2. Informative References ....................................26
Appendix A. Implications of Not Following the Recommended
Behavior .............................................28
A.1. Implications of Not Generating DAD_NS Packets upon the
Reception of Non-Compliant Data Packets ...................28
A.1.1. Lack of Binding State due to Packet Loss...............28
A.1.2. Lack of Binding State due to a Change in the
Topology ..............................................31
A.1.3. Lack of Binding State due to State Loss ...............31
A.2. Implications of Not Discarding Non-Compliant Data
Packets ...................................................35
1. Introduction ....................................................4
1.1. Terminology ................................................4
2. Background to FCFS SAVI .........................................4
2.1. Scope of FCFS SAVI .........................................4
2.2. Constraints for FCFS SAVI Design ...........................5
2.3. Address Ownership Proof ....................................5
2.4. Binding Anchor Considerations ..............................6
2.5. FCFS SAVI Protection Perimeter .............................6
2.6. Special Cases .............................................10
3. FCFS SAVI Specification ........................................11
3.1. FCFS SAVI Data Structures .................................12
3.2. FCFS SAVI Algorithm .......................................12
3.2.1. Discovering On-Link Prefixes .......................12
3.2.2. Processing of Transit Traffic ......................13
3.2.3. Processing of Local Traffic ........................13
3.2.4. FCFS SAVI Port Configuration Guidelines ............21
3.2.5. VLAN Support .......................................22
3.3. Default Protocol Values ...................................22
4. Security Considerations ........................................22
4.1. Denial-of-Service Attacks .................................22
4.2. Residual Threats ..........................................23
4.3. Privacy Considerations ....................................24
4.4. Interaction with Secure Neighbor Discovery ................25
5. Contributors ...................................................25
6. Acknowledgments ................................................25
7. References .....................................................26
7.1. Normative References ......................................26
7.2. Informative References ....................................26
Appendix A. Implications of Not Following the Recommended
Behavior .............................................28
A.1. Implications of Not Generating DAD_NS Packets upon the
Reception of Non-Compliant Data Packets ...................28
A.1.1. Lack of Binding State due to Packet Loss...............28
A.1.2. Lack of Binding State due to a Change in the
Topology ..............................................31
A.1.3. Lack of Binding State due to State Loss ...............31
A.2. Implications of Not Discarding Non-Compliant Data
Packets ...................................................35
This memo describes FCFS SAVI, a mechanism that provides source address validation for IPv6 networks using the FCFS principle. The proposed mechanism is intended to complement ingress filtering techniques to help detect and prevent source address spoofing. Section 2 gives the background and description of FCFS SAVI, and Section 3 specifies the FCFS SAVI protocol.
本备忘录介绍了FCFS SAVI，这是一种使用FCFS原理为IPv6网络提供源地址验证的机制。建议的机制旨在补充入口过滤技术，以帮助检测和防止源地址欺骗。第2节给出了FCFS SAVI的背景和说明，第3节指定了FCFS SAVI协议。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The application scenario for FCFS SAVI is limited to the local link. Hence, the goal of FCFS SAVI is to verify that the source address of the packets generated by the hosts attached to the local link have not been spoofed.
FCFS SAVI的应用场景仅限于本地链路。因此，FCFS SAVI的目标是验证连接到本地链路的主机生成的数据包的源地址没有被欺骗。
In a link, hosts and routers are usually attached. Hosts generate packets with their own address as the source address. This is called "local traffic". Routers send packets containing a source IP address other than their own, since they are forwarding packets generated by other hosts (usually located in a different link). This is called "transit traffic".
在链路中，通常连接主机和路由器。主机以自己的地址作为源地址生成数据包。这被称为“本地交通”。路由器发送包含源IP地址的数据包，而不是它们自己的，因为它们转发由其他主机（通常位于不同的链路）生成的数据包。这被称为“过境交通”。
The applicability of FCFS SAVI is limited to the local traffic, i.e., to verify if the traffic generated by the hosts attached to the local link contains a valid source address. The verification of the source address of the transit traffic is out of the scope of FCFS SAVI. Other techniques, like ingress filtering [RFC2827], are recommended to validate transit traffic. In that sense, FCFS SAVI complements ingress filtering, since it relies on ingress filtering to validate transit traffic, but it provides validation of local traffic, which is not provided by ingress filtering. Hence, the security level is increased by using these two techniques.
FCFS SAVI的适用性仅限于本地通信量，即验证连接到本地链路的主机生成的通信量是否包含有效的源地址。过境交通源地址的验证不在FCFS SAVI的范围内。建议使用其他技术（如入口过滤[RFC2827]）来验证过境流量。从这个意义上说，FCFS SAVI补充了入口过滤，因为它依赖入口过滤来验证过境流量，但它提供了入口过滤不提供的本地流量验证。因此，使用这两种技术可以提高安全级别。
In addition, FCFS SAVI is designed to be used with locally assigned IPv6 addresses, in particular with IPv6 addresses configured through Stateless Address Autoconfiguration (SLAAC) [RFC4862]. Manually configured IPv6 addresses can be supported by FCFS SAVI, but manual configuration of the binding on the FCFS SAVI device provides higher security and seems compatible with manual address management. FCFS
此外，FCFS SAVI设计用于本地分配的IPv6地址，特别是通过无状态地址自动配置（SLAAC）配置的IPv6地址[RFC4862]。FCFS SAVI支持手动配置的IPv6地址，但FCFS SAVI设备上绑定的手动配置提供了更高的安全性，并且似乎与手动地址管理兼容。FCFS
SAVI can also be used with IPv6 addresses assigned via DHCPv6, since they ought to perform the Duplicate Address Detection (DAD) procedure, but there is a specific mechanism tailored for dealing with DHCP-assigned addresses defined in [SAVI-DHCP]. Additional considerations about how to use FCFS SAVI depending on the type of address management used and the nature of the addresses are discussed in the framework document [SAVI-FRAMEWORK].
SAVI也可用于通过DHCPv6分配的IPv6地址，因为它们应该执行重复地址检测（DAD）过程，但有一种特定的机制专门用于处理[SAVI-DHCP]中定义的DHCP分配地址。关于如何使用FCFS SAVI的其他注意事项，取决于使用的地址管理类型和地址的性质，在框架文档[SAVI-framework]中讨论。
FCFS SAVI is designed to be deployed in existing networks requiring a minimum set of changes. For that reason, FCFS SAVI does not require any changes in the host whose source address is to be verified. Any verification solely relies on the usage of already available protocols. That is, FCFS SAVI does not define a new protocol, define any new message on existing protocols, or require that a host use an existent protocol message in a different way. In other words, no host changes are required.
FCFS SAVI旨在部署在现有网络中，只需最少的一组更改。因此，FCFS SAVI不需要对要验证其源地址的主机进行任何更改。任何验证都完全依赖于使用已有的协议。也就是说，FCFS SAVI不定义新协议，不在现有协议上定义任何新消息，也不要求主机以不同的方式使用现有协议消息。换句话说，不需要更改主机。
FCFS SAVI validation is performed by the FCFS SAVI function. The function can be placed in different types of devices, including a router or a Layer 2 (L2) bridge. The basic idea is that the FCFS SAVI function is located in the points of the topology that can enforce the correct usage of the source address by dropping the non-compliant packets.
FCFS SAVI验证由FCFS SAVI函数执行。该功能可以放置在不同类型的设备中，包括路由器或第2层（L2）网桥。其基本思想是，FCFS SAVI函数位于拓扑点中，可以通过丢弃不兼容的数据包来强制正确使用源地址。
The main function performed by FCFS SAVI is to verify that the source address used in data packets actually belongs to the originator of the packet. Since the FCFS SAVI scope is limited to the local link, the originator of the packet is attached to the local link. In order to define a source address validation solution, we need to define the meaning of "address ownership", i.e., what it means that a given host owns a given address in the sense that the host is entitled to send packets with that source address. With that definition, we can define how a device can confirm that the source address in a datagram is owned by the originator of the datagram.
FCFS SAVI执行的主要功能是验证数据包中使用的源地址实际上属于数据包的发起人。由于FCFS SAVI作用域仅限于本地链路，因此数据包的发起人连接到本地链路。为了定义源地址验证解决方案，我们需要定义“地址所有权”的含义，即，在主机有权使用该源地址发送数据包的意义上，给定主机拥有给定地址的含义。通过该定义，我们可以定义设备如何确认数据报中的源地址属于数据报的发起人。
In FCFS SAVI, proof of address ownership is based on the First-Come, First-Served principle. The first host that claims a given source address is the owner of the address until further notice. Since no host changes are acceptable, we need to find the means to confirm address ownership without requiring a new protocol. So, whenever a source address is used for the first time, a state is created in the device that is performing the FCFS SAVI function binding the source address to a binding anchor that consists of Layer 2 information that the FCFS SAVI box has available (e.g., the port in a switched LAN).
在FCFS SAVI中，地址所有权证明基于先到先得原则。声明给定源地址的第一台主机是该地址的所有者，直至另行通知。由于不接受任何主机更改，我们需要找到在不需要新协议的情况下确认地址所有权的方法。因此，每当第一次使用源地址时，在执行FCFS SAVI功能的设备中创建一个状态，该功能将源地址绑定到绑定锚，绑定锚由FCFS SAVI框可用的第2层信息组成（例如，交换LAN中的端口）。
Subsequent data packets containing that IP source address can be checked against the same binding anchor to confirm that the originator owns the source IP address.
包含该IP源地址的后续数据包可以根据同一绑定锚进行检查，以确认发起者拥有该源IP地址。
There are, however, additional considerations to be taken into account. For instance, consider the case of a host that moves from one segment of a LAN to another segment of the same subnetwork and keeps the same IP address. In this case, the host is still the owner of the IP address, but the associated binding anchor may have changed. In order to cope with this case, the defined FCFS SAVI behavior implies verification of whether or not the host is still reachable using the previous binding anchor. In order to do that, FCFS SAVI uses the Neighbor Discovery (ND) protocol. If the host is no longer reachable at the previously recorded binding anchor, FCFS SAVI assumes that the new location is valid and creates a new binding using the new binding anchor. In case the host is still reachable using the previously recorded binding anchor, the packets coming from the new binding anchor are dropped.
然而，还需要考虑其他因素。例如，考虑主机从一个LAN段移动到同一子网的另一段并保持相同IP地址的情况。在这种情况下，主机仍然是IP地址的所有者，但关联的绑定锚可能已更改。为了应对这种情况，定义的FCFS SAVI行为意味着验证主机是否仍然可以使用以前的绑定锚访问。为了做到这一点，FCFS SAVI使用邻居发现（ND）协议。如果在先前记录的绑定锚处无法再访问主机，FCFS SAVI将假定新位置有效，并使用新绑定锚创建新绑定。如果使用先前记录的绑定锚仍然可以访问主机，则来自新绑定锚的数据包将被丢弃。
Note that this only applies to local traffic. Transit traffic generated by a router would be verified using alternative techniques, such as ingress filtering. FCFS SAVI checks would not be fulfilled by the transit traffic, since the router is not the owner of the source address contained in the packets.
请注意，这仅适用于本地流量。路由器产生的传输流量将使用替代技术（如入口过滤）进行验证。由于路由器不是数据包中包含的源地址的所有者，因此传输流量不会执行FCFS SAVI检查。
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 FCFS SAVI device is configured to drop non-compliant packets, then the usage of FCFS SAVI may open a new vector of Denial-of-Service (DoS) attacks, based on spoofed binding anchors. For that reason, in this specification, only switch ports MUST be used as 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.
任何SAVI解决方案都不比它使用的绑定锚强。如果绑定锚很容易伪造（例如，媒体访问控制（MAC）地址），那么最终的解决方案将很弱。需要相应地调整不兼容数据包的处理。特别地，如果绑定锚很容易被伪造，并且FCFS SAVI设备被配置为丢弃不兼容的分组，那么FCFS SAVI的使用可能会基于伪造的绑定锚打开拒绝服务（DoS）攻击的新载体。因此，在本规范中，只有交换机端口必须用作绑定锚。其他形式的绑定锚不在本规范的范围内，使用前应进行适当的分析。
FCFS SAVI provides perimetrical security. FCFS SAVI devices form what can be called an FCFS SAVI protection perimeter, and they verify that any packet that crosses the perimeter is compliant (i.e., the source address is validated). Once the packet is inside the perimeter, no further validations are performed on the packet. This
FCFS SAVI提供了周长安全性。FCFS SAVI设备构成可称为FCFS SAVI保护周界的设备，它们验证穿过周界的任何数据包是否符合要求（即验证源地址）。一旦数据包进入周界，就不会对数据包执行进一步的验证。这
model has implications both on how FCFS SAVI devices are deployed in the topology and on the configuration of the FCFS SAVI boxes.
该模型对FCFS SAVI设备在拓扑中的部署方式以及FCFS SAVI盒的配置都有影响。
The implication of this perimetrical security approach is that there is part of the topology that is inside the perimeter and part of the topology that is outside the perimeter. So, while packets coming from interfaces connected to the external part of the topology need to be validated by the FCFS SAVI device, packets coming from interfaces connected to the internal part of the topology do not need to be validated. This significantly reduces the processing requirements of the FCFS SAVI device. It also implies that each FCFS SAVI device that is part of the perimeter must be able to verify the source addresses of the packets coming from the interfaces connected to the external part of the perimeter. In order to do so, the FCFS SAVI device binds the source address to a binding anchor.
这种外围安全方法的含义是，部分拓扑位于外围内，部分拓扑位于外围外。因此，虽然来自连接到拓扑外部部分的接口的数据包需要由FCFS SAVI设备进行验证，但是来自连接到拓扑内部部分的接口的数据包不需要进行验证。这大大降低了FCFS SAVI设备的处理要求。它还意味着作为周界一部分的每个FCFS SAVI设备必须能够验证来自连接到周界外部部分的接口的数据包的源地址。为此，FCFS SAVI设备将源地址绑定到绑定锚。
One possible approach would be for every FCFS SAVI device to store binding information about every source address in the subnetwork. In this case, every FCFS SAVI device would store a binding for each source address of the local link. The problem with this approach is that it imposes a significant memory burden on the FCFS SAVI devices. In order to reduce the memory requirements imposed on each device, the FCFS SAVI solution described in this specification distributes the storage of FCFS SAVI binding information among the multiple FCFS SAVI devices of a subnetwork. The FCFS SAVI binding state is distributed across the FCFS SAVI devices according to the following criterion: each FCFS SAVI device only stores binding information about the source addresses bound to anchors corresponding to the interfaces that connect to the part of the topology that is outside of the FCFS SAVI protection perimeter. Since all the untrusted packet sources are by definition in the external part of the perimeter, packets generated by each of the untrusted sources will reach the perimeter through an interface of an FCFS SAVI device. The binding information for that particular source address will be stored in the first FCFS SAVI device the packet reaches.
一种可能的方法是每个FCFS SAVI设备存储子网中每个源地址的绑定信息。在这种情况下，每个FCFS SAVI设备将为本地链路的每个源地址存储一个绑定。这种方法的问题在于它给FCFS SAVI设备带来了巨大的内存负担。为了减少对每个设备的内存需求，本规范中描述的FCFS SAVI解决方案在子网的多个FCFS SAVI设备之间分配FCFS SAVI绑定信息的存储。FCFS SAVI绑定状态根据以下标准分布在FCFS SAVI设备上：每个FCFS SAVI设备仅存储绑定到锚的源地址的绑定信息，锚对应于连接到FCFS SAVI保护周界之外的拓扑部分的接口。由于根据定义，所有不受信任的数据包源位于外围的外部部分，因此每个不受信任的数据包源生成的数据包将通过FCFS SAVI设备的接口到达外围。该特定源地址的绑定信息将存储在数据包到达的第一个FCFS SAVI设备中。
The result is that the FCFS SAVI binding information will be distributed across multiple devices. In order to provide proper source address validation, it is critical that the information distributed among the different FCFS SAVI devices be coherent. In particular, it is important to avoid having the same source address bound to different binding anchors in different FCFS SAVI devices. Should that occur, then it would mean that two hosts are allowed to send packets with the same source address, which is what FCFS SAVI is trying to prevent. In order to preserve the coherency of the FCFS SAVI bindings distributed among the FCFS SAVI devices within a realm, the Neighbor Discovery (ND) protocol [RFC4861] is used, in particular the Neighbor Solicitation (NS) and Neighbor Advertisement (NA)
结果是FCFS SAVI绑定信息将分布在多个设备上。为了提供适当的源地址验证，在不同FCFS SAVI设备之间分布的信息必须一致。特别是，重要的是避免将相同的源地址绑定到不同FCFS SAVI设备中的不同绑定锚。如果出现这种情况，则意味着允许两台主机发送具有相同源地址的数据包，这正是FCFS SAVI试图阻止的。为了保持域内FCFS SAVI设备之间分布的FCFS SAVI绑定的一致性，使用邻居发现（ND）协议[RFC4861]，特别是邻居请求（NS）和邻居通告（NA）
messages. Following is a simplified example of how this might work. Before creating an FCFS SAVI binding in the local FCFS SAVI database, the FCFS SAVI device will send an NS message querying for the address involved. Should any host reply to that message with an NA message, the FCFS SAVI device that sent the NS will infer that a binding for that address exists in another FCFS SAVI device and will not create a local binding for it. If no NA message is received as a reply to the NS, then the local FCFS SAVI device will infer that no binding for that address exists in other FCFS SAVI device and will create the local FCFS SAVI binding for that address.
信息。下面是一个简化的示例，说明了这可能是如何工作的。在本地FCFS SAVI数据库中创建FCFS SAVI绑定之前，FCFS SAVI设备将发送一条NS消息，查询所涉及的地址。如果任何主机使用NA消息回复该消息，则发送NS的FCFS SAVI设备将推断该地址的绑定存在于另一个FCFS SAVI设备中，并且不会为其创建本地绑定。如果没有收到NA消息作为对NS的答复，则本地FCFS SAVI设备将推断其他FCFS SAVI设备中不存在该地址的绑定，并将为该地址创建本地FCFS SAVI绑定。
To summarize, the proposed FCFS SAVI approach relies on the following design choices:
总之，建议的FCFS SAVI方法依赖于以下设计选择：
o An FCFS SAVI provides perimetrical security, so some interfaces of an FCFS SAVI device will connect to the internal (trusted) part of the topology, and other interfaces will connect to the external (untrusted) part of the topology.
o FCFS SAVI提供外围安全性，因此FCFS SAVI设备的某些接口将连接到拓扑的内部（受信任）部分，而其他接口将连接到拓扑的外部（不受信任）部分。
o An FCFS SAVI device only verifies packets coming through an interface connected to the untrusted part of the topology.
o FCFS SAVI设备仅验证通过连接到拓扑的不受信任部分的接口发送的数据包。
o An FCFS SAVI device only stores binding information for the source addresses that are bound to binding anchors that correspond to interfaces that connect to the untrusted part of the topology.
o FCFS SAVI设备仅存储绑定到绑定锚的源地址的绑定信息，绑定锚对应于连接到拓扑的不受信任部分的接口。
o An FCFS SAVI uses NS and NA messages to preserve the coherency of the FCFS SAVI binding state distributed among the FCFS SAVI devices within a realm.
o FCFS SAVI使用NS和NA消息来保持域内FCFS SAVI设备之间分布的FCFS SAVI绑定状态的一致性。
So, in a link that is constituted of multiple L2 devices, some of which are FCFS SAVI capable and some of which are not, the FCFS-SAVI-capable devices MUST be deployed forming a connected perimeter (i.e., no data packet can get inside the perimeter without passing through an FCFS SAVI device). Packets that cross the perimeter will be validated while packets that do not cross the perimeter are not validated (hence, FCFS SAVI protection is not provided for these packets). Consider the deployment of FCFS SAVI in the topology depicted in the following figure:
因此，在由多个L2设备构成的链路中，其中一些设备具有FCFS SAVI能力，而另一些设备不具有FCFS SAVI能力，必须部署具有FCFS SAVI能力的设备以形成连接的周界（即，没有通过FCFS SAVI设备的数据包就不能进入周界）。跨周界的数据包将被验证，而不跨周界的数据包将不被验证（因此，不为这些数据包提供FCFS SAVI保护）。考虑FCFS SAVI在下面描述的拓扑结构中的部署：
+--------+
+--+ +--+ +--+ | +--+ |
|H1| |H2| |H3| | |R1| |
+--+ +--+ +--+ | +--+ |
| | | | | |
+-------------SAVI-PROTECTION-PERIMETER------+ | |
| | | | | |
| +-1-----2-+ +-1-----2-+ |
| | SAVI1 | | SAVI2 | |
| +-3--4----+ +--3------+ |
| | | +--------------+ | |
| | +----------| |--------+ |
| | | SWITCH-A | |
| | +----------| |--------+ |
| | | +--------------+ | |
| +-1--2----+ +--1------+ |
| | SAVI3 | | SAVI4 | |
| +-3-----4-+ +----4----+ |
| | | | |
| +------SAVI-PROTECTION-PERIMETER---------------+
| | | | |
| +--+| +--+ +---------+
| |R2|| |H4| |SWITCH-B |
| +--+| +--+ +---------+
+------+ | |
+--+ +--+
|H5| |H6|
+--+ +--+
+--------+
+--+ +--+ +--+ | +--+ |
|H1| |H2| |H3| | |R1| |
+--+ +--+ +--+ | +--+ |
| | | | | |
+-------------SAVI-PROTECTION-PERIMETER------+ | |
| | | | | |
| +-1-----2-+ +-1-----2-+ |
| | SAVI1 | | SAVI2 | |
| +-3--4----+ +--3------+ |
| | | +--------------+ | |
| | +----------| |--------+ |
| | | SWITCH-A | |
| | +----------| |--------+ |
| | | +--------------+ | |
| +-1--2----+ +--1------+ |
| | SAVI3 | | SAVI4 | |
| +-3-----4-+ +----4----+ |
| | | | |
| +------SAVI-PROTECTION-PERIMETER---------------+
| | | | |
| +--+| +--+ +---------+
| |R2|| |H4| |SWITCH-B |
| +--+| +--+ +---------+
+------+ | |
+--+ +--+
|H5| |H6|
+--+ +--+
Figure 1: SAVI Protection Perimeter
图1:SAVI保护周界
In Figure 1, the FCFS SAVI protection perimeter is provided by four FCFS SAVI devices, namely SAVI1, SAVI2, SAVI3, and SAVI4. These devices verify the source address and filter packets accordingly.
在图1中，FCFS SAVI保护周界由四个FCFS SAVI设备提供，即SAVI1、SAVI2、SAVI3和SAVI4。这些设备验证源地址并相应地过滤数据包。
FCFS SAVI devices then have two types of ports: Trusted Ports and Validating Ports.
FCFS SAVI设备有两种类型的端口：受信任端口和验证端口。
o Validating Ports (VPs) are those in which FCFS SAVI processing is performed. When a packet is received through one of the Validating Ports, FCFS SAVI processing and filtering will be executed.
o 验证端口（VP）是执行FCFS SAVI处理的端口。当通过其中一个验证端口接收到数据包时，将执行FCFS SAVI处理和过滤。
o Trusted Ports (TPs) are those in which FCFS SAVI processing is not performed. So, packets received through Trusted Ports are not validated, and no FCFS SAVI processing is performed on them.
o 受信任端口（TPs）是指未执行FCFS SAVI处理的端口。因此，通过受信任端口接收的数据包不会被验证，也不会对其执行FCFS SAVI处理。
Trusted Ports are used for connections with trusted infrastructure, including the communication between FCFS SAVI devices, the communication with routers, and the communication of other switches that, while not FCFS SAVI devices, only connect to trusted infrastructure (i.e., other FCFS SAVI devices, routers, or other trusted nodes). So, in Figure 1, Port 3 of SAVI1 and Port 1 of SAVI3 are trusted because they connect two FCFS SAVI devices. Port 4 of SAVI1, Port 3 of SAVI2, Port 2 of SAVI3, and Port 1 of SAVI4 are trusted because they connect to SWITCH-A, to which only trusted nodes are connected. In Figure 1, Port 2 of SAVI2 and Port 3 of SAVI3 are Trusted Ports because they connect to routers.
可信端口用于与可信基础设施的连接，包括FCFS SAVI设备之间的通信、与路由器的通信以及其他交换机的通信，这些交换机虽然不是FCFS SAVI设备，但仅连接到可信基础设施（即其他FCFS SAVI设备、路由器或其他可信节点）。因此，在图1中，SAVI1的端口3和SAVI3的端口1是可信的，因为它们连接两个FCFS SAVI设备。SAVI1的端口4、SAVI2的端口3、SAVI3的端口2和SAVI4的端口1是受信任的，因为它们连接到交换机A，而交换机A只连接受信任的节点。在图1中，SAVI2的端口2和SAVI3的端口3是受信任的端口，因为它们连接到路由器。
Validating Ports are used for connection with non-trusted infrastructure. In particular, hosts are normally connected to Validating Ports. Non-SAVI switches that are outside of the FCFS SAVI protection perimeter also are connected through Validating Ports. In particular, non-SAVI devices that connect directly to hosts or that have no SAVI-capable device between themselves and the hosts are connected through a Validating Port. So, in Figure 1, Ports 1 and 2 of SAVI1, Port 1 of SAVI2, and Port 4 of SAVI 3 are Validating Ports because they connect to hosts. Port 4 of SAVI4 is also a Validating Port because it is connected to SWITCH-B, which is a non-SAVI-capable switch that is connected to hosts H5 and H6.
验证端口用于与不受信任的基础结构的连接。特别是，主机通常连接到验证端口。FCFS SAVI保护外围以外的非SAVI交换机也通过验证端口连接。特别是，直接连接到主机或其自身与主机之间没有支持SAVI的设备的非SAVI设备通过验证端口连接。因此，在图1中，SAVI1的端口1和2、SAVI2的端口1和savi3的端口4都是验证端口，因为它们连接到主机。SAVI 4的端口4也是验证端口，因为它连接到交换机B，交换机B是连接到主机H5和H6的不支持SAVI的交换机。
Multi-subnet links: In some cases, a given subnet may have several prefixes. This is directly supported by SAVI as any port can support multiple prefixes. Forwarding of packets between different prefixes involving a router is even supported, as long as the router is connected to a Trusted Port, as recommended for all the routers.
多子网链接：在某些情况下，给定的子网可能有多个前缀。SAVI直接支持这一点，因为任何端口都可以支持多个前缀。甚至支持在涉及路由器的不同前缀之间转发数据包，只要路由器连接到可信端口，这是所有路由器的建议。
Multihomed hosts: A multihomed host is a host with multiple interfaces. The interaction between 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 always carry the address assigned to that interface as the source address, then from the perspective of a SAVI device, this is equivalent to two hosts with a single interface, each with an IP address. This is
多宿主主机：多宿主主机是具有多个接口的主机。SAVI和多宿主主机之间的交互如下所示。如果为主机的不同接口分配了不同的IP地址，并且从每个接口发送的数据包始终携带分配给该接口的地址作为源地址，那么从SAVI设备的角度来看，这相当于两个具有单个接口的主机，每个主机具有一个IP地址。这是
supported by SAVI without the need for 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 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 SAVI bindings to allow binding the address of the multihomed host to multiple anchors simultaneously.
由SAVI支持，无需额外考虑。如果不同接口共享相同的IP地址，或者如果接口具有不同的地址，但主机通过任何接口使用其中一个接口的地址发送数据包，则SAVI不直接支持它。它需要将多宿主主机的至少一个接口连接到受信任的端口，或者手动配置SAVI绑定以允许将多宿主主机的地址同时绑定到多个锚。
Untrusted routers: One can envision scenarios where routers are dynamically attached to an FCFS SAVI network. A typical example would be a mobile phone connecting to an FCFS SAVI switch where the mobile phone is acting as a router for other personal devices that are accessing the network through it. In this case, the 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 FCFS SAVI switch would discard all the packets containing an off-link source address coming from that device. As a result, the default recommendation specified in this specification does not support such a scenario.
不受信任的路由器：可以想象路由器动态连接到FCFS SAVI网络的场景。一个典型的例子是连接到FCFS SAVI交换机的移动电话，其中移动电话充当通过其访问网络的其他个人设备的路由器。在这种情况下，路由器似乎不直接属于受信任的基础设施类别（如果是这种情况，则很可能所有设备都是受信任的）；因此，它不能连接到受信任的端口，如果它连接到验证端口，FCFS SAVI交换机将丢弃包含来自该设备的断开链路源地址的所有数据包。因此，本规范中指定的默认建议不支持这种情况。
The FCFS SAVI function relies on state information binding the source address used in data packets to the binding anchor that contained the first packet that used that source IP address. Such information is stored in an FCFS SAVI database (DB). The FCFS SAVI DB will contain a set of entries about the currently used IP source addresses. Each entry will contain the following information:
FCFS SAVI函数依赖于将数据包中使用的源地址绑定到包含使用该源IP地址的第一个包的绑定锚的状态信息。此类信息存储在FCFS SAVI数据库（DB）中。FCFS SAVI DB将包含一组关于当前使用的IP源地址的条目。每个条目将包含以下信息：
o IP source address
o IP源地址
o Binding anchor: port through which the packet was received
o 绑定锚：接收数据包的端口
o Lifetime
o 一生
o Status: either TENTATIVE, VALID, TESTING_VP, or TESTING_TP-LT
o 状态：暂定、有效、测试\u VP或测试\u TP-LT
o Creation time: the value of the local clock when the entry was firstly created
o 创建时间：首次创建条目时本地时钟的值
In addition, FCFS SAVI needs to know what prefixes are directly connected, so it maintains a data structure called the FCFS SAVI Prefix List, which contains:
此外，FCFS SAVI需要知道哪些前缀是直接连接的，因此它维护一个名为FCFS SAVI前缀列表的数据结构，其中包含：
o Prefix
o 前缀
o Interface where prefix is directly connected
o 前缀直接连接的接口
In order to distinguish local traffic from transit traffic, the FCFS SAVI device relies on the FCFS SAVI Prefix List, which contains the set of on-link IPv6 prefixes. An FCFS SAVI device MUST support the following two methods for populating the Prefix List: manual configuration and Router Advertisement, as detailed next.
为了区分本地通信量和传输通信量，FCFS SAVI设备依赖于FCFS SAVI前缀列表，其中包含一组链路IPv6前缀。FCFS SAVI设备必须支持以下两种填充前缀列表的方法：手动配置和路由器公告，如下所述。
Manual configuration: An FCFS SAVI device MUST support manual configuration of the on-link prefixes included in the Prefix List. For example, this can be used when there are no prefixes being advertised on the link.
手动配置：FCFS SAVI设备必须支持手动配置前缀列表中包含的链路前缀。例如，当链接上没有播发前缀时，可以使用此选项。
Router Advertisement: An FCFS SAVI device MUST support discovery of on-link prefixes through Router Advertisement messages in Trusted Ports. For Trusted Ports, the FCFS SAVI device will learn the on-link prefixes following the procedure defined for a host to process the Prefix Information options described in Section 6.3.4 of [RFC4861] with the difference that the prefixes will be configured in the FCFS SAVI Prefix List rather than in the ND Prefix List. In addition, when the FCFS SAVI device boots, it MUST send a Router Solicitation message as described in Section 6.3.7 of [RFC4861], using the unspecified source address.
路由器公告：FCFS SAVI设备必须支持通过可信端口中的路由器公告消息发现链路上的前缀。对于受信任端口，FCFS SAVI设备将按照主机处理[RFC4861]第6.3.4节所述前缀信息选项的程序学习链路上的前缀，不同之处在于前缀将在FCFS SAVI前缀列表中配置，而不是在ND前缀列表中配置。此外，当FCFS SAVI设备引导时，它必须使用未指定的源地址发送[RFC4861]第6.3.7节所述的路由器请求消息。
The FCFS SAVI function is located in a forwarding device, such as a router or a Layer 2 switch. The following processing is performed depending on the type of port through which the packet has been received:
FCFS SAVI功能位于转发设备中，如路由器或第2层交换机。根据接收数据包的端口类型，执行以下处理：
o If the data packet is received through a Trusted Port, the data packet is forwarded, and no SAVI processing performed on the packet.
o 如果通过可信端口接收数据分组，则转发数据分组，并且不对该分组执行SAVI处理。
o If the data packet is received through a Validating Port, then the FCFS SAVI function checks whether the received data packet is local traffic or transit traffic. It does so by verifying if the source address of the packet belongs to one of the directly connected prefixes available in the receiving interface. It does so by searching the FCFS SAVI Prefix List.
o 如果通过验证端口接收数据包，则FCFS SAVI功能检查接收的数据包是本地通信量还是传输通信量。它通过验证数据包的源地址是否属于接收接口中可用的直接连接前缀之一来实现。它通过搜索FCFS SAVI前缀列表来实现。
* If the IP source address does not belong to one of the on-link prefixes of the receiving interface, the data packet is transit traffic, and the packet SHOULD be discarded. (If for some reason, discarding the packets is not acceptable, logging or triggering of alarms MAY be used). The FCFS SAVI function MAY send an ICMP Destination Unreachable Error back to the source address of the data packet, and ICMPv6, code 5 (Source address failed ingress/egress policy), should be used.
* 如果IP源地址不属于接收接口的链路前缀之一，则数据包为传输流量，应丢弃该数据包。（如果出于某种原因，丢弃数据包是不可接受的，则可以使用记录或触发报警）。FCFS SAVI功能可将ICMP目的地不可到达错误发送回数据包的源地址，并且应使用ICMPv6，代码5（源地址失败的入口/出口策略）。
* If the source address of the packet does belong to one of the prefixes available in the receiving port, then the FCFS SAVI local traffic validation process is executed as described below.
* 如果数据包的源地址确实属于接收端口中可用的前缀之一，则如下文所述执行FCFS SAVI本地流量验证过程。
* If the source address of the packet is an unspecified address, the packet is forwarded, and no SAVI processing is performed except for the case of the Neighbor Solicitation messages involved in the Duplicate Address Detection, which are treated as described in Section 3.2.3.
* 如果数据包的源地址是未指定的地址，则数据包被转发，并且除了重复地址检测中涉及的邻居请求消息的情况外，不执行SAVI处理，如第3.2.3节所述处理。
We next describe how local traffic, including both control and data packets, is processed by the FCFS SAVI device using a state machine approach.
接下来，我们将描述FCFS SAVI设备如何使用状态机方法处理本地流量，包括控制和数据包。
The state machine described is for the binding of a given source IP address (called IPAddr) in a given FCFS SAVI device. This means that all the packets described as inputs in the state machine above refer to that given IP address. In the case of data packets, the source address of the packet is IPAddr. In the case of the DAD_NS packets, the Target Address is IPAddr. The key attribute is the IP address. The full state information is as follows:
描述的状态机用于绑定给定FCFS SAVI设备中的给定源IP地址（称为IPAddr）。这意味着上述状态机中描述为输入的所有数据包都引用该给定IP地址。对于数据包，数据包的源地址是IPAddr。对于数据包，目标地址是IPAddr。密钥属性是IP地址。完整的状态信息如下所示：
o IP ADDRESS: IPAddr
o IP地址：IPAddr
o BINDING ANCHOR: P
o 绑定锚：P
o LIFETIME: LT
o 寿命：LT
The possible states are as follows:
可能的状态如下：
o NO_BIND
o 不受约束
o TENTATIVE
o 实验性的
o VALID
o 有效的
o TESTING_TP-LT
o 测试\u TP-LT
o TESTING_VP
o 测试
We will use VP for Validating Port and TP for Trusted Port.
我们将使用VP验证端口，使用TP验证受信任端口。
After bootstrapping (when no binding exists), the state for all source IP addresses is NO-BIND, i.e., there is no binding for the IP address to any binding anchor.
引导后（当不存在绑定时），所有源IP地址的状态都是no-BIND，即IP地址没有绑定到任何绑定锚。
NO_BIND: The binding for a source IP address entry is in this state when it does not have any binding to an anchor. All addresses are in this state by default after bootstrapping, unless bindings were created for them.
NO_BIND：当源IP地址项没有任何与锚的绑定时，该项的绑定处于此状态。默认情况下，所有地址在引导后都处于这种状态，除非为它们创建了绑定。
TENTATIVE: The binding for a source address for which a data packet or an NS generated by the Duplicate Address Detection (DAD) procedure has been received is in this state during the waiting period during which the DAD procedure is being executed (either by the host itself or the FCFS SAVI device on its behalf).
暂定：已接收到重复地址检测（DAD）过程生成的数据包或NS的源地址的绑定在执行DAD过程的等待期间（由主机本身或代表其的FCFS SAVI设备）处于此状态。
VALID: The binding for the source address is in this state after it has been verified. It means that it is valid and usable for filtering traffic.
有效：源地址的绑定在验证后处于此状态。这意味着它对于过滤流量是有效和可用的。
TESTING_TP-LT: A binding for a source address enters this state due to one of two reasons:
测试\u TP-LT：源地址的绑定由于以下两个原因之一而进入此状态：
o When a Duplicate Address Detection Neighbor Solicitation has been received through a Trusted Port. This implies that a host is performing the DAD procedure for that source address in another switch. This may be due to an attack or to the fact that the host may have moved. The binding in this state is then being tested to determine which is the situation.
o 当通过受信任端口接收到重复地址检测邻居请求时。这意味着主机正在另一个交换机中对该源地址执行DAD过程。这可能是由于攻击或主机可能已移动。然后，将测试此状态下的绑定以确定哪种情况。
o The lifetime of the binding entry is about to expire. This is due to the fact that no packets have been seen by the FCFS SAVI device for the LIFETIME period. This may be due to the host simply being silent or because the host has left the location. In order to determine which is the case, a test is performed to determine if the binding information should be discarded.
o 绑定项的生存期即将到期。这是因为FCFS SAVI设备在生存期内未看到任何数据包。这可能是因为主机只是处于静默状态，或者是因为主机已离开该位置。为了确定是哪种情况，执行一个测试来确定是否应该丢弃绑定信息。
TESTING_VP: A binding for a source address enters this state when a Duplicate Address Detection Neighbor Solicitation or a data packet has been received through a Validating Port other than the one address to which it is currently bound. This implies that a host is performing the DAD procedure for that source address through a different port. This may be due to an attack, the fact that the host
测试VP：当通过验证端口（而不是当前绑定到的地址）接收到重复地址检测邻居请求或数据包时，源地址的绑定进入此状态。这意味着主机正在通过不同的端口为该源地址执行DAD过程。这可能是由于受到攻击，主机
may have moved, or just because another host tries to configure an address already used. The binding in this state is then being tested to determine which is the situation.
可能已移动，或者只是因为另一台主机试图配置已使用的地址。然后，将测试此状态下的绑定以确定哪种情况。
Next, we describe how the different inputs are processed depending on the state of the binding of the IP address (IPAddr).
接下来，我们将描述如何根据IP地址（IPAddr）绑定的状态处理不同的输入。
A simplified figure of the state machine is included in Figure 2 below.
下面的图2中包含了状态机的简化图。
NO_BIND
不受约束
o Upon the reception through a Validating Port (VP) of a Neighbor Solicitation (NS) generated by the Duplicate Address Detection (DAD) procedure (hereafter named DAD_NS) containing Target Address IPAddr, the FCFS SAVI device MUST forward the NS, and T_WAIT milliseconds later, it MUST send a copy of the same message. These DAD_NS messages are not sent through any of the ports configured as Validating Ports. The DAD_NS messages are sent through the Trusted Ports (but, of course, subject to usual switch behavior and possible Multicast Listener Discovery (MLD) snooping optimizations). The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT:=TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and the Creation time is set to the current value of the local clock.
o 当通过验证端口（VP）接收到由包含目标地址IPAddr的重复地址检测（DAD）过程（以下称为DAD_NS）生成的邻居请求（NS）时，FCFS SAVI设备必须转发NS，等待毫秒后，它必须发送同一消息的副本。这些数据消息不会通过任何配置为验证端口的端口发送。DAD消息通过受信任的端口发送（当然，这取决于通常的交换机行为和可能的多播侦听器发现（MLD）窥探优化）。该状态被移动到暂定状态。生存期设置为TENT_LT（即LT:=TENT_LT），绑定锚点设置为VP（即P:=VP），创建时间设置为本地时钟的当前值。
o Upon the reception through a Validating Port (VP) of a DATA packet containing IPAddr as the source address, the SAVI device SHOULD execute the process of sending Neighbor Solicitation messages of the Duplicate Address Detection process as described in Section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e., 2 Neighbor Solicitation messages for that address will be sent by the SAVI device) and RetransTimer set to T_WAIT milliseconds (i.e., the time between two Neighbor Solicitation messages is T_WAIT milliseconds). The implications of not following the recommended behavior are described in Appendix A. The DAD_NS messages are not sent through any of the ports configured as Validating Ports. The DAD_NSOL messages are sent through Trusted Ports (but, of course, subject to usual switch behavior and possible MLD snooping optimizations). The SAVI device MAY discard the data packets while the DAD procedure is being executed, or it MAY store them until the binding is created. In any case, it MUST NOT forward the data packets until the binding has been verified. The state is moved to TENTATIVE. The LIFETIME is set to TENT_LT (i.e., LT: =TENT_LT), the BINDING ANCHOR is set to VP (i.e., P:=VP), and the Creation time is set to the current value of the local clock.
o 当通过验证端口（VP）接收到包含IPAddr作为源地址的数据包时，SAVI设备应执行[RFC4862]第5.4.2节所述的发送重复地址检测过程的邻居请求消息的过程对于使用以下默认参数的IPAddr：DupAddrDetectTransmissions设置为2（即，该地址的2条邻居请求消息将由SAVI设备发送），Renstimer设置为T_WAIT毫秒（即，两条邻居请求消息之间的时间为T_WAIT毫秒）。附录A中描述了不遵循建议行为的含义。DAD消息不会通过任何配置为验证端口的端口发送。DAD_NSOL消息通过受信任的端口发送（当然，这取决于通常的交换机行为和可能的MLD窥探优化）。SAVI设备可以在执行DAD过程时丢弃数据包，或者可以存储它们，直到创建绑定为止。在任何情况下，在验证绑定之前，它都不得转发数据包。该状态被移动到暂定状态。生存期设置为TENT_LT（即LT:=TENT_LT），绑定锚点设置为VP（即P:=VP），创建时间设置为本地时钟的当前值。
o Data packets containing IPAddr as the source address received through Trusted Ports are processed and forwarded as usual (i.e., no special SAVI processing).
o 通过受信任端口接收的包含IPAddr作为源地址的数据包将按常规进行处理和转发（即，无特殊SAVI处理）。
o DAD_NS packets containing IPAddr as the Target Address that are received through a Trusted Port MUST NOT be forwarded through any of the Validating Ports, but they are sent through the Trusted Ports (but, of course, subject to usual switch behavior and possible MLD snooping optimizations).
o 通过受信任端口接收的包含IPAddr作为目标地址的数据包不得通过任何验证端口转发，而是通过受信任端口发送（当然，要遵守通常的交换机行为和可能的MLD窥探优化）。
o Neighbor Advertisement packets sent to all nodes as a reply to the DAD_NS (hereafter called DAD_NA) containing IPAddr as the Target Address coming through a Validating Port are discarded.
o 通过验证端口发送到所有节点作为对包含IPAddr作为目标地址的DAD_NS（以下称为DAD_NA）的应答的邻居播发数据包将被丢弃。
o Other signaling packets are processed and forwarded as usual (i.e., no SAVI processing).
o 其他信令分组照常处理和转发（即，无SAVI处理）。
TENTATIVE
实验性的
o If the LIFETIME times out, the state is moved to VALID. The LIFETIME is set to DEFAULT_LT (i.e., LT:= DEFAULT_LT). Stored data packets (if any) are forwarded.
o 如果生存期超时，则状态将移到“有效”。生存期设置为默认值（即LT:=默认值）。转发存储的数据包（如果有）。
o If a Neighbor Advertisement (NA) is received through a Trusted Port with the Target Address set to IPAddr, then the message is forwarded through port P, the state is set to NO_BIND, and the BINDING ANCHOR and the LIFETIME are cleared. Data packets stored corresponding to this binding are discarded.
o 如果通过受信任端口接收到邻居播发（NA），目标地址设置为IPAddr，则消息通过端口P转发，状态设置为NO_BIND，绑定锚和生存期被清除。与此绑定对应的存储数据包将被丢弃。
o If an NA is received through a Validating Port with the Target Address set to IPAddr, the NA packet is discarded
o 如果通过验证端口接收到目标地址设置为IPAddr的NA，则会丢弃NA数据包
o If a data packet with source address IPAddr is received with binding anchor equal to P, then the packet is either stored or discarded.
o 如果在绑定锚等于P的情况下接收到源地址为IPAddr的数据包，则该数据包要么被存储，要么被丢弃。
o If a data packet with source address IPAddr is received through a Trusted Port, the data packet is forwarded. The state is unchanged.
o 如果通过受信任端口接收到源地址为IPAddr的数据包，则会转发该数据包。国家没有改变。
o If a data packet with source address IPAddr is received through a Validating Port other than P, the data packet is discarded.
o 如果通过P以外的验证端口接收到源地址为IPAddr的数据包，则丢弃该数据包。
o If a DAD_NS is received from a Trusted Port, with the Target Address set to IPAddr, then the message is forwarded to the Validating Port P, the state is set to NO_BIND, and the BINDING ANCHOR and LIFETIME are cleared. Data packets stored corresponding to this binding are discarded.
o 如果从受信任端口接收到DAD，且目标地址设置为IPAddr，则消息将转发到验证端口P，状态设置为“无绑定”，绑定锚和生存期将被清除。与此绑定对应的存储数据包将被丢弃。
o If a DAD_NS with the Target Address set to IPAddr is received from a Validating Port P' other than P, the message is forwarded to the Validating Port P and to the Trusted Ports, and the state remains in TENTATIVE; however, the BINDING ANCHOR is changed from P to P', and LIFETIME is set to TENT_LT. Data packets stored corresponding to the binding with P are discarded.
o 如果从P以外的验证端口P'接收到目标地址设置为IPAddr的数据，则消息将转发到验证端口P和受信任端口，并且状态保持为暂定状态；但是，绑定锚点从P更改为P'，生存期设置为TENT_LT。与P绑定对应的存储数据包将被丢弃。
o Other signaling packets are processed and forwarded as usual (i.e., no SAVI processing).
o 其他信令分组照常处理和转发（即，无SAVI处理）。
VALID
有效的
o If a data packet containing IPAddr as the source address arrives from Validating Port P, then the LIFETIME is set to DEFAULT_LT and the packet is forwarded as usual.
o 如果包含IPAddr作为源地址的数据包从验证端口P到达，则生存期设置为默认值，并且数据包照常转发。
o If a DAD_NS is received from a Trusted Port, then the DAD_NS message is forwarded to port P and is also forwarded to the Trusted Ports (but, of course, subject to usual switch behavior and possible MLD snooping optimizations). The state is changed to TESTING_TP-LT. The LIFETIME is set to TENT_LT.
o 如果从受信任的端口接收到DAD\n，则DAD\n消息将转发到端口P，并转发到受信任的端口（当然，这取决于通常的交换机行为和可能的MLD窥探优化）。状态更改为TESTING_TP-LT。生存期设置为TENT_LT。
o If a data packet containing source address IPAddr or a DAD_NA packet with the Target Address set to IPAddr is received through a Validating Port P' other than P, then the SAVI device will execute the process of sending DAD_NS messages as described in Section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e., two NS messages for that address will be sent by the SAVI device) and RetransTimer set to T_WAIT milliseconds (i.e., the time between two NS messages is T_WAIT milliseconds). The DAD_NS message will be forwarded to the port P. The state is moved to TESTING_VP. The LIFETIME is set to TENT_LT. The SAVI device MAY discard the data packet while the DAD procedure is being executed, or it MAY store them until the binding is created. In any case, it MUST NOT forward the data packets until the binding has been verified.
o 如果通过P以外的验证端口P'接收到包含源地址IPAddr的数据包或目标地址设置为IPAddr的数据包，则SAVI设备将执行[RFC4862]第5.4.2节所述的发送数据包消息的过程对于使用以下默认参数的IPAddr：DupAddrDetectTransmissions设置为2（即，该地址的两条NS消息将由SAVI设备发送），Renstimer设置为T_WAIT毫秒（即，两条NS消息之间的时间为T_WAIT毫秒）。DAD_n s消息将转发到端口P。状态移动到测试VP。生存期设置为TENT_LT。SAVI设备可以在执行DAD过程时丢弃数据包，也可以存储数据包，直到创建绑定为止。在任何情况下，在验证绑定之前，它都不得转发数据包。
o If a DAD_NS packet with the Target Address set to IPAddr is received through a Validating Port P' other than P, then the SAVI device will forward the DAD_NS packet, and T_WAIT milliseconds later, it will execute the process of sending DAD_NS messages as described in Section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 1 and RetransTimer set to T_WAIT milliseconds. The DAD_NS messages will be forwarded to the port P. The state is moved to TESTING_VP. The LIFETIME is set to TENT_LT. The SAVI device MAY discard the data packets while the DAD procedure is being executed, or it MAY
o 如果通过P以外的验证端口P'接收到目标地址设置为IPAddr的DAD_NS数据包，则SAVI设备将转发该DAD_NS数据包，并在几毫秒后等待，它将执行[RFC4862]第5.4.2节所述的发送DAD_NS消息的过程对于IPAddr，使用以下默认参数：DupAddrDetectTransmissions设置为1，Renstimer设置为T_WAIT毫秒。DAD消息将转发到端口P。状态将移动到测试VP。生存期设置为TENT_LT。SAVI设备可以在执行DAD过程时丢弃数据包，也可以
store them until the binding is created. In any case, it MUST NOT forward the data packets until the binding has been verified.
存储它们，直到创建绑定为止。在任何情况下，在验证绑定之前，它都不得转发数据包。
o If the LIFETIME expires, then the SAVI device will execute the process of sending DAD_NS messages as described in Section 5.4.2 of [RFC4862] for the IPAddr using the following default parameters: DupAddrDetectTransmits set to 2 (i.e., two NS messages for that address will be sent by the SAVI device) and RetransTimer set to T_WAIT milliseconds (i.e., the time between two NS messages is T_WAIT milliseconds). The DAD_NS messages will be forwarded to the port P. The state is changed to TESTING_TP-LT, and the LIFETIME is set to TENT_LT.
o 如果生存期到期，则SAVI设备将按照[RFC4862]第5.4.2节所述，使用以下默认参数为IPAddr执行发送DAD_NS消息的过程：DupAddrDetectTransmissions设置为2（即，SAVI设备将发送该地址的两条NS消息）和Retrantimer设置为T_WAIT毫秒（即，两条NS消息之间的时间为T_等待毫秒）。DAD_NS消息将转发到端口P。状态更改为TESTING_TP-LT，生存期设置为TENT_LT。
o If a data packet containing IPAddr as a source address arrives from Trusted Port, the packet MAY be discarded. The event MAY be logged.
o 如果包含IPAddr作为源地址的数据包从受信任端口到达，则该数据包可能会被丢弃。可能会记录该事件。
o Other signaling packets are processed and forwarded as usual (i.e., no SAVI processing). In particular, a DAD_NA coming from port P and containing IPAddr as the Target Address is forwarded as usual.
o 其他信令分组照常处理和转发（即，无SAVI处理）。特别是，来自端口P并包含IPAddr作为目标地址的DAD_NA将照常转发。
TESTING_TP-LT
测试\u TP-LT
o If the LIFETIME expires, the BINDING ANCHOR is cleared, and the state is changed to NO_BIND.
o 如果生存期到期，则清除绑定锚，并将状态更改为NO_BIND。
o If an NA message containing the IPAddr as the Target Address is received through the Validating Port P as a reply to the DAD_NS message, then the NA is forwarded as usual, and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT
o 如果通过验证端口P接收到包含IPAddr作为目标地址的NA消息作为对DAD_n s消息的答复，则NA将照常转发，并且状态更改为有效。生存期设置为默认值\u LT
o If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT.
o 如果通过端口P接收到包含IPAddr作为源地址的数据包，则该数据包被转发，并且状态更改为有效。生存期设置为默认值。
o If a DAD_NS is received from a Trusted Port, the DAD_NS is forwarded as usual.
o 如果从受信任的端口接收到数据，则会像往常一样转发数据。
o If a DAD_NS is received from a Validating Port P' other than P, the DAD_NS is forwarded as usual, and the state is moved to TESTING_VP.
o 如果从P以外的验证端口P'接收到数据，则数据将照常转发，并且状态将移动到测试VP。
o If a data packet is received through a Validating Port P' that is other than port P, then the packet is discarded.
o 如果通过端口P以外的验证端口P'接收到数据包，则丢弃该数据包。
o If a data packet is received through a Trusted Port, then the packet MAY be discarded. The event MAY be logged.
o 如果通过可信端口接收到数据分组，则该分组可能被丢弃。可能会记录该事件。
TESTING_VP
测试
o If the LIFETIME expires, the BINDING ANCHOR is modified from P to P', the LIFETIME is set to DEFAULT_LT, and the state is changed to VALID. Stored data packet coming from P' are forwarded.
o 如果生存期到期，绑定锚将从P修改为P'，生存期设置为默认值，状态更改为有效。来自P'的存储数据包被转发。
o If an NA message containing the IPAddr as the Target Address is received through the Validating Port P as a reply to the DAD_NS message, then the NA is forwarded as usual and the state is changed to VALID. The LIFETIME is set to DEFAULT_LT.
o 如果通过验证端口P接收到包含IPAddr作为目标地址的NA消息，作为对DAD_NS消息的回复，则NA将照常转发，状态更改为有效。生存期设置为默认值。
o If a data packet containing IPAddr as the source address is received through port P, then the packet is forwarded.
o 如果通过端口P接收到包含IPAddr作为源地址的数据包，则该数据包将被转发。
o If a data packet containing IPAddr as the source address is received through a Validating Port P'' that is other than port P or P', then the packet is discarded.
o 如果通过端口P或P'以外的验证端口P''接收到包含IPAddr作为源地址的数据包，则丢弃该数据包。
o If a data packet containing IPAddr as the source address is received through a Trusted Port (i.e., other than port P), the state is moved to TESTING_TP-LT, and the packet MAY be discarded.
o 如果通过受信任的端口（即，端口P以外的端口）接收到包含IPAddr作为源地址的数据包，则状态移动到测试_TP-LT，并且该数据包可能被丢弃。
o If a DAD_NS is received through a Trusted Port, the packet is forwarded as usual, and the state is moved to TESTING_TP-LT.
o 如果通过受信任的端口接收到数据包，则数据包将照常转发，并且状态将移动到TESTING_TP-LT。
o If a DAD_NS is received through Validating Port P'' other than P or P', the packet is forwarded as usual, and P'' is stored as the tentative port, i.e., P':=P''. The state remains the same.
o 如果通过验证端口P''而不是P或P'接收到数据，则数据包将照常转发，P''存储为暂定端口，即P':=P''。国家依然如此。
+---------+ VP_NS, VP_DATA/2xNS +-----------+
| |---------------------------------------->| |
| NO_BIND | | TENTATIVE |
| |<----------------------------------------| |
+---------+ TP_NA, TP_NS/- +-----------+
^ |
| | TimeOut
Timeout| |
| v
+---------+ VP_NA/- +-----------+
| |---------------------------------------->| |
| TESTING | TP_NS/- | |
| TP-LT |<----------------------------------------| VALID |
| | TimeOut/2xNS | |
| |<----------------------------------------| |
+---------+ +-----------+
^ | ^ |
| | | |
| +--------------------- ---------------------+ |
| VP_NS/- | | NP_NA, TimeOut/- |
| v | |
| +-----------+ |
| | | |
+---------------------| TESTING |<----------------------+
VP_NS, VP_DATA/- | VP | VP_DATA, VP_NS,
+-----------+ VP_NA/2xNS
+---------+ VP_NS, VP_DATA/2xNS +-----------+
| |---------------------------------------->| |
| NO_BIND | | TENTATIVE |
| |<----------------------------------------| |
+---------+ TP_NA, TP_NS/- +-----------+
^ |
| | TimeOut
Timeout| |
| v
+---------+ VP_NA/- +-----------+
| |---------------------------------------->| |
| TESTING | TP_NS/- | |
| TP-LT |<----------------------------------------| VALID |
| | TimeOut/2xNS | |
| |<----------------------------------------| |
+---------+ +-----------+
^ | ^ |
| | | |
| +--------------------- ---------------------+ |
| VP_NS/- | | NP_NA, TimeOut/- |
| v | |
| +-----------+ |
| | | |
+---------------------| TESTING |<----------------------+
VP_NS, VP_DATA/- | VP | VP_DATA, VP_NS,
+-----------+ VP_NA/2xNS
Figure 2: Simplified State Machine
图2：简化状态机
MLD Considerations
MLD注意事项
The FCFS SAVI device MUST join the solicited node multicast group for all the addresses with a state other than NO_BIND. This is needed to make sure that the FCFS SAVI device will receive the DAD_NS for those addresses. Please note that it may not be enough to rely on the host behind the Validating Port to do so, since the node may move, and after a while, the packets for that particular solicited node multicast group will no longer be forwarded to the FCFS SAVI device. Therefore, the FCFS SAVI device MUST join the solicited node multicast groups for all the addresses that are in a state other than NO_BIND.
FCFS SAVI设备必须加入请求节点多播组，以获得除“无绑定”以外状态的所有地址。这是为了确保FCFS SAVI设备将接收这些地址的数据。请注意，仅依靠验证端口后面的主机来执行此操作可能不够，因为节点可能会移动，并且在一段时间后，该特定请求节点多播组的数据包将不再转发到FCFS SAVI设备。因此，FCFS SAVI设备必须为处于非NOU BIND状态的所有地址加入请求节点多播组。
The guidelines for port configuration in FCFS SAVI devices are as follows:
FCFS SAVI设备中的端口配置指南如下：
o The FCFS SAVI realm (i.e., the realm that is inside the FCFS SAVI protection perimeter) MUST be connected. If this is not the case, legitimate transit traffic may be dropped.
o 必须连接FCFS SAVI领域（即FCFS SAVI保护周界内的领域）。如果不是这样，合法的过境交通可能会中断。
o Ports that are connected to another FCFS SAVI device MUST be configured as Trusted Ports. Not doing so will significantly increase the memory consumption in the FCFS SAVI devices and may result in legitimate transit traffic being dropped.
o 连接到其他FCFS SAVI设备的端口必须配置为受信任端口。不这样做将显著增加FCFS SAVI设备中的内存消耗，并可能导致合法传输流量被丢弃。
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 spoofed source addresses. A valid exception is the case of a trusted host (e.g., a server) that could be connected to a Trusted Port, but untrusted hosts MUST be connected to Validating Ports.
o 连接到主机的端口应配置为验证端口。不这样做将允许连接到该端口的主机发送带有伪造源地址的数据包。有效的例外情况是，受信任的主机（例如服务器）可以连接到受信任的端口，但不受信任的主机必须连接到验证端口。
o Ports connected to routers MUST be configured as Trusted Ports. Configuring them as Validating Ports should result in transit traffic being dropped.
o 连接到路由器的端口必须配置为受信任端口。将它们配置为验证端口将导致传输流量被丢弃。
o Ports connected to a chain of one or more legacy switches that have hosts connected SHOULD be configured as Validating Ports. Not doing so will allow the host connected to any of these switches to send packets with spoofed source addresses. A valid exception is the case where the legacy switch only has trusted hosts attached, in which case it could be connected to a Trusted Port, but if there is at least one untrusted hosts connected to the legacy switch, then it MUST be connected to Validating Ports.
o 连接到一个或多个已连接主机的旧交换机链的端口应配置为验证端口。不这样做将允许连接到这些交换机的主机发送带有伪造源地址的数据包。有效的例外情况是，旧交换机仅连接了受信任的主机，在这种情况下，它可以连接到受信任的端口，但如果至少有一个不受信任的主机连接到旧交换机，则它必须连接到验证端口。
o Ports connected to a chain of one or more legacy switches that have other FCFS SAVI devices and/or routers connected but had no hosts attached to them MUST be configured as Trusted Ports. Not doing so will at least significantly increase the memory consumption in the FCFS SAVI devices, increase the signaling traffic due to FCFS SAVI validation, and may result in legitimate transit traffic being dropped.
o 连接到一个或多个旧交换机链的端口（已连接其他FCFS SAVI设备和/或路由器，但未连接主机）必须配置为受信任端口。不这样做将至少显著增加FCFS SAVI设备中的内存消耗，增加由于FCFS SAVI验证而产生的信令流量，并且可能导致合法的传输流量被丢弃。
If the FCFS SAVI device is a switch that supports customer VLANs [IEEE.802-1Q.2005], the FCFS SAVI implementation MUST behave as if there was one FCFS SAVI process per customer VLAN. The FCFS SAVI process of each customer VLAN will store the binding information corresponding to the nodes attached to that particular customer VLAN.
如果FCFS SAVI设备是支持客户VLAN的交换机[IEEE.802-1Q.2005]，则FCFS SAVI实现的行为必须如同每个客户VLAN有一个FCFS SAVI进程一样。每个客户VLAN的FCFS SAVI进程将存储与连接到该特定客户VLAN的节点对应的绑定信息。
Following are the default values used in the FCFS SAVI specification.
以下是FCFS SAVI规范中使用的默认值。
TENT_LT is 500 milliseconds
这是500毫秒
DEFAULT_LT is 5 minutes
默认值为5分钟
T_WAIT is 250 milliseconds
等待时间为250毫秒
An implementation MAY allow these values to be modified, but tuning them precisely is considered out of the scope of this document.
一个实现可能允许修改这些值，但是精确地调整它们不在本文档的范围之内。
There are two types of Denial-of-Service (DoS) attacks [RFC4732] that can be envisaged in an FCFS SAVI environment. On one hand, we can envision attacks against the FCFS SAVI device resources. On the other hand, we can envision DoS attacks against the hosts connected to the network where FCFS SAVI is running.
在FCFS SAVI环境中，可以设想两种类型的拒绝服务（DoS）攻击[RFC4732]。一方面，我们可以设想针对FCFS SAVI设备资源的攻击。另一方面，我们可以设想对连接到运行FCFS SAVI的网络的主机的DoS攻击。
The attacks against the FCFS SAVI device basically consist of making the FCFS 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 FCFS SAVI device create state for each of the addresses and waste memory. At some point, the FCFS 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 FCFS SAVI device runs out of the memory allocated for the FCFS SAVI DB, it is RECOMMENDED that it create 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 LIFETIME, which is updated using data packets. The result is that in order for an attacker to actually fill the FCFS SAVI DB
对FCFS SAVI设备的攻击基本上包括使FCFS SAVI设备消耗其资源，直到资源耗尽为止。例如，可能的攻击是发送具有不同源地址的数据包，使FCFS SAVI设备为每个地址创建状态并浪费内存。在某些情况下，FCFS SAVI设备内存不足，需要决定如何反应。结果是需要某种形式的垃圾收集来修剪条目。当FCFS SAVI设备耗尽为FCFS SAVI DB分配的内存时，建议通过删除创建时间较长的条目来创建新条目。这意味着旧条目将被保留，而新条目将相互覆盖。在攻击者发送具有不同源地址的一批数据包的攻击场景中，每个新的源地址都可能重写攻击本身创建的另一个源地址。应该注意的是，条目也是使用生存期（使用数据包更新）进行垃圾收集的。结果是，为了让攻击者实际填充FCFS SAVI DB
with false source addresses, it needs to continuously send data packets for all the different source 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 RECOMMENDED that an FCFS 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 recommended minimum is the memory needed to store four bindings associated with the port. The motivation for this recommendation is as follows. An attacker attached to a given port of an FCFS SAVI device may attempt to launch a DoS attack towards the FCFS SAVI device by creating many bindings for different addresses. It can do so by sending DAD_NS for different addresses. The result is that the attack will consume all the memory available in the FCFS SAVI device. The above recommendation aims to reserve a minimum amount of memory per port, so that hosts 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.
此外，建议FCFS SAVI设备为每个可用端口保留最小内存量（如果端口用作L2锚的一部分）。建议的最小内存是存储与端口关联的四个绑定所需的内存。这项建议的动机如下。连接到FCFS SAVI设备的给定端口的攻击者可能试图通过为不同地址创建多个绑定来对FCFS SAVI设备发起DoS攻击。它可以通过发送不同地址的数据来实现。结果是，攻击将消耗FCFS SAVI设备中的所有可用内存。上述建议旨在为每个端口保留最小数量的内存，以便位于不同端口的主机可以利用其端口的保留内存，即使在不同端口发生DoS攻击。
As the FCFS SAVI device may store data packets while the address is being verified, the memory for data packet storage may also be a target of DoS attacks. The effects of such attacks may be limited to the lack of capacity to store new data packets. The effect of such attacks will be that data packets will be dropped during the verification period. An FCFS SAVI device MUST limit the amount of memory used to store data packets, allowing the other functions to have available memory even in the case of attacks such those described above.
由于FCFS SAVI设备可能在验证地址时存储数据分组，因此用于数据分组存储的存储器也可能是DoS攻击的目标。此类攻击的影响可能仅限于缺乏存储新数据包的能力。此类攻击的效果将是在验证期间丢弃数据包。FCFS SAVI设备必须限制用于存储数据包的内存量，允许其他功能具有可用内存，即使在发生上述攻击的情况下也是如此。
The FCFS SAVI device generates two DAD_NS packets upon the reception of a DAD_NS or a data packet. As such, the FCFS SAVI device can be used as an amplifier by attackers. In order to limit this type of attack, the FCFS SAVI device MUST perform rate limiting of the messages it generates. Rate limiting is performed on a per-port basis, since having an attack on a given port should not prevent the FCFS SAVI device from functioning normally in the rest of the ports.
FCFS SAVI设备在接收到数据包或数据包时生成两个数据包。因此，FCFS SAVI设备可被攻击者用作放大器。为了限制此类攻击，FCFS SAVI设备必须对其生成的消息执行速率限制。速率限制是基于每个端口执行的，因为对给定端口进行攻击不应阻止FCFS SAVI设备在其余端口中正常工作。
FCFS SAVI performs its function by binding an IP source address to a binding anchor. If the attacker manages to send packets using the binding anchor associated to a given IP address, FCFS SAVI validation will be successful, and the FCFS SAVI device will allow the packet through. This can be achieved by spoofing the binding anchor or by sharing of the binding anchor between the legitimate owner of the address and the attacker. An example of the latter is the case where the binding anchor is a port of a switched network and a legacy
FCFS SAVI通过将IP源地址绑定到绑定锚来执行其功能。如果攻击者使用与给定IP地址关联的绑定锚发送数据包，则FCFS SAVI验证将成功，FCFS SAVI设备将允许数据包通过。这可以通过欺骗绑定锚或在地址的合法所有者和攻击者之间共享绑定锚来实现。后者的一个示例是绑定锚是交换网络的端口和遗留端口的情况
switch (i.e., not a SAVI-capable switch) is connected to that port. All the source addresses of the hosts connected to the legacy switch will share the same binding anchor (i.e., the switch port). This means that hosts connected to the legacy switch can spoof each other's IP address and will not be detected by the FCFS SAVI device. This can be prevented by not sharing binding anchors among hosts.
交换机（即，不支持SAVI的交换机）连接到该端口。连接到传统交换机的主机的所有源地址将共享同一绑定锚（即交换机端口）。这意味着连接到传统交换机的主机可以欺骗对方的IP地址，FCFS SAVI设备不会检测到这些主机。这可以通过不在主机之间共享绑定锚来防止。
FCFS SAVI assumes that a host will be able to defend its address when the DAD procedure is executed for its addresses. 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). So, when a DAD_NS is issued for a given IP address for which a binding exists in an FCFS SAVI device, the FCFS SAVI device expects to see a DAD_NA coming from the binding anchor associated to that IP address in order to preserve the binding. If the FCFS SAVI device does not see the DAD_NA, 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 intercepting the DAD_NA or launching a DoS attack to the host that will prevent it from issuing proper DAD replies.
FCFS SAVI假设当为主机地址执行DAD过程时，主机将能够保护其地址。除其他外，这需要支持链路内的移动性（即，允许主机在不更改其IP地址的情况下分离并重新连接到同一IP子网的不同第2层锚）。因此，当为FCFS SAVI设备中存在绑定的给定IP地址发出DAD时，FCFS SAVI设备期望看到来自与该IP地址相关联的绑定锚的DAD以保留绑定。如果FCFS SAVI设备看不到DAD_NA，它可能会将绑定授予其他绑定锚。这意味着，如果攻击者成功阻止主机保护其源地址，它将能够破坏现有绑定并使用不同的绑定锚创建新绑定。攻击者可以这样做，例如，通过拦截DAD_NA或对主机发起DoS攻击来阻止主机发出正确的DAD回复。
Even if routers are considered trusted, nothing can prevent a router from being compromised and sending traffic with spoofed IP source addresses. Such traffic would be allowed with the present FCFS SAVI specification. A way to mitigate this issue could be to specify a new port type (e.g., Router Port (RP)) that would act as Trusted Port for the transit traffic and as Validating Port for the local traffic. A detailed solution about this issue is outside the scope of this document.
即使路由器被认为是受信任的，也没有什么可以阻止路由器被破坏并使用伪造的IP源地址发送流量。目前的FCFS SAVI规范允许此类流量。缓解此问题的一种方法是指定一种新的端口类型（例如，路由器端口（RP）），该端口将充当传输流量的受信任端口和本地流量的验证端口。有关此问题的详细解决方案不在本文档范围内。
Personally identifying information MUST NOT be included in the FCFS SAVI DB with the MAC address as the canonical example, except when there is an attack attempt involved. Moreover, compliant implementations MUST NOT log binding anchor information except where there is an identified reason why that information is likely to be involved in detection, prevention, or tracing of actual source address spoofing. Information that is not logged MUST be deleted as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND). Information about the majority of hosts that never spoof SHOULD NOT be logged.
个人识别信息不得包含在FCFS SAVI DB中，MAC地址作为典型示例，除非涉及攻击企图。此外，兼容实现不得记录绑定锚信息，除非有确定的原因说明该信息可能涉及实际源地址欺骗的检测、预防或跟踪。必须尽快删除未记录的信息（即，一旦给定地址的状态恢复到无绑定状态）。不应记录绝大多数从不欺骗的主机的信息。
Even if the FCFS SAVI could get information from ND messages secured with Secure Neighbor Discovery (SEND) [RFC3971], in some case, the FCFS SAVI device must spoof DAD_NS messages but doesn't know the security credentials associated with the IPAddr (i.e., the private key used to sign the DAD_NS messages). So, when SEND is deployed, it is recommended to use SEND SAVI [SAVI-SEND] rather than FCFS SAVI.
即使FCFS SAVI可以从受安全邻居发现（SEND）[RFC3971]保护的ND消息中获取信息，在某些情况下，FCFS SAVI设备必须伪造数据消息，但不知道与IPAddr关联的安全凭据（即，用于签署数据消息的私钥）。因此，在部署SEND时，建议使用SEND SAVI[SAVI-SEND]，而不是FCFS SAVI。
Jun Bi CERNET Network Research Center, Tsinghua University Beijing 100084 China EMail: junbi@cernet.edu.cn
清华大学CERNET网络研究中心北京100084中国电子邮件：junbi@cernet.edu.cn
Guang Yao CERNET Network Research Center, Tsinghua University Beijing 100084 China EMail: yaog@netarchlab.tsinghua.edu.cn
清华大学光耀CERNET网络研究中心北京100084中国电子邮件：yaog@netarchlab.tsinghua.edu.cn
Fred Baker Cisco Systems EMail: fred@cisco.com
Fred Baker Cisco Systems电子邮件：fred@cisco.com
Alberto Garcia Martinez University Carlos III of Madrid EMail: alberto@it.uc3m.es
阿尔贝托·加西亚·马丁内斯大学马德里卡洛斯三世电子邮件：alberto@it.uc3m.es
This document benefited from the input of the following individuals: Joel Halpern, Christian Vogt, Dong Zhang, Frank Xia, Jean-Michel Combes, Jari Arkko, Stephen Farrel, Dan Romascanu, Russ Housley, Pete Resnick, Ralph Droms, Wesley Eddy, Dave Harrington, and Lin Tao.
本文件得益于以下个人的投入：Joel Halpern、Christian Vogt、Dong Zhang、Frank Xia、Jean-Michel Combs、Jari Arkko、Stephen Farrel、Dan Romascanu、Russ Housley、Pete Resnick、Ralph Droms、Wesley Eddy、Dave Harrington和林涛。
Marcelo Bagnulo is partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
Marcelo Bagnulo的部分资金来自Trilogy，这是一个由欧盟委员会第七个框架计划支持的研究项目。
[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月。
[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月。
[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月。
[SAVI-FRAMEWORK] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, "Source Address Validation Improvement Framework", Work in Progress, December 2011.
[SAVI-FRAMEWORK]Wu，J.，Bi，J.，Bagnulo，M.，Baker，F.，和C.Vogt，“源地址验证改进框架”，正在进行的工作，2011年12月。
[SAVI-DHCP] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for DHCP", Work in Progress, February 2012.
[SAVI-DHCP]Bi，J.，Wu，J.，Yao，G.，和F.Baker，“DHCP的SAVI解决方案”，正在进行的工作，2012年2月。
[SAVI-SEND] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-Address Validation Implementation", Work in Progress, March 2012.
[SAVI-SEND]Bagnulo，M.和A.Garcia Martinez，“基于发送的源地址验证实施”，正在进行的工作，2012年3月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]Carpenter，B.，“互联网的建筑原理”，RFC19581996年6月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[RFC4732]Handley，M.，Rescorla，E.，和IAB，“互联网拒绝服务注意事项”，RFC 4732，2006年12月。
[IEEE.802-1D.1998] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks Media Access Control (MAC) Bridges", IEEE Standard 802.1D, 1998.
[IEEE.802-1D.1998]电气和电子工程师协会，“局域网和城域网媒体访问控制（MAC）网桥的IEEE标准”，IEEE标准802.1D，1998年。
[IEEE.802-1D.2004] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks Media Access Control (MAC) Bridges", IEEE Standard 802.1D, 2004.
[IEEE.802-1D.2004]电气和电子工程师协会，“局域网和城域网媒体访问控制（MAC）网桥的IEEE标准”，IEEE标准802.1D，2004年。
[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月。
[IEEE.802-1X.2004] Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control", IEEE Standard 802.1X, 2004.
[IEEE.802-1X.2004]电气和电子工程师协会，“局域网和城域网IEEE标准-基于端口的网络访问控制”，IEEE标准802.1X，2004年。
This section qualifies some of the SHOULDs that are included in this specification by explaining the implications of not following the recommended behavior. We start by describing the implication of not following the recommendation of generating DAD_NS upon the reception of a data packet for which there is no binding, and then we describe the implications of not discarding the non-compliant packets.
本节通过解释不遵循推荐行为的含义，限定了本规范中包含的一些应遵守项。我们首先描述在接收到没有绑定的数据包时不遵循生成数据的建议的含义，然后描述不丢弃不兼容数据包的含义。
A.1. Implications of Not Generating DAD_NS Packets upon the Reception of Non-Compliant Data Packets
A.1. 接收不符合要求的数据包时不生成数据包的影响
This specification recommends that SAVI implementations generate a DAD_NS message upon the reception of a data packet for which they have no binding. In this section, we describe the implications of not doing so and simply discarding the data packet instead.
本规范建议SAVI实现在接收到数据包时生成一条没有绑定的数据包消息。在本节中，我们将描述不这样做而只是丢弃数据包的含义。
The main argument against discarding the data packet is the overall robustness of the resulting network. The main concern that has been stated is that a network running SAVI that discards data packets in this case may end up disconnecting legitimate users from the network, by filtering packets coming from them. The net result would be a degraded robustness of the network as a whole, since legitimate users would perceive this as a network failure. There are three different causes that resulted in the lack of state in the binding device for a legitimate address, namely, packet loss, state loss, and topology change. We will next perform an analysis for each of them.
反对丢弃数据包的主要理由是所产生的网络的整体健壮性。所述的主要问题是，在这种情况下丢弃数据包的运行SAVI的网络可能会通过过滤来自合法用户的数据包而最终断开合法用户与网络的连接。最终结果将是整个网络的健壮性降低，因为合法用户会将其视为网络故障。有三种不同的原因导致绑定设备中缺少合法地址的状态，即数据包丢失、状态丢失和拓扑更改。接下来，我们将对它们中的每一个进行分析。
The DAD procedure is inherently unreliable. It consists of sending an NS packet, and if no NA packet is received back, success is assumed, and the host starts using the address. In general, the lack of response is because no other host has that particular address configured in its interface, but it may also be the case that the NS packet or the NA packet has been lost. From the perspective of the sending host, there is no difference, and the host assumes that it can use the address. In other words, the default action is to allow the host to obtain network connectivity.
DAD程序本质上是不可靠的。它包括发送一个NS数据包，如果没有收到任何NA数据包，则假定成功，主机开始使用该地址。通常，缺少响应是因为没有其他主机在其接口中配置了该特定地址，但也可能是NS分组或NA分组丢失的情况。从发送主机的角度来看，没有区别，并且主机假定它可以使用该地址。换句话说，默认操作是允许主机获得网络连接。
It should be noted that the loss of a DAD packet has little impact on the network performance, since address collision is very rare, and the host assumes success in that case. By designing a SAVI solution that would discard packets for which there is no binding, we are diametrically changing the default behavior in this respect, since the default would be that if the DAD packets are lost, then the node is disconnected from the network (as its packets are filtered). What is worse, the node has little clue of what is going wrong, since it
应该注意的是，由于地址冲突非常罕见，因此DAD数据包的丢失对网络性能几乎没有影响，并且主机假定在这种情况下会成功。通过设计一个SAVI解决方案来丢弃没有绑定的数据包，我们彻底改变了这方面的默认行为，因为默认情况下，如果DAD数据包丢失，那么节点将与网络断开连接（因为其数据包被过滤）。更糟糕的是，节点几乎不知道出了什么问题，因为它
has successfully configured an address, but it has no connectivity. The net result is that the overall reliability of the network has significantly decreased as the loss of a single packet would imply that a host is disconnected from the network.
已成功配置地址，但它没有连接。最终结果是，网络的整体可靠性显著降低，因为单个数据包的丢失意味着主机与网络断开连接。
The only mechanism that the DAD has to improve its reliability is sending multiple NSs. However, [RFC4862] defines a default value of 1 NS message for the DAD procedure, so requiring any higher value would imply manual configuration of all the hosts connected to the SAVI domain.
DAD必须提高其可靠性的唯一机制是发送多个NSs。但是，[RFC4862]为DAD过程定义了1 NS message的默认值，因此要求任何更高的值都意味着手动配置连接到SAVI域的所有主机。
The Case of LANs
局域网的情况
Devices connecting to a network may experience periods of packet loss after the link-layer becomes available for two reasons: Invalid Authentication state and incomplete topology assessment. In both cases, physical-layer connection occurs initially and presents a medium where packets are transmissible, but frame forwarding is not available across the LAN.
连接到网络的设备在链路层可用后可能会经历一段时间的数据包丢失，原因有两个：无效的身份验证状态和不完整的拓扑评估。在这两种情况下，物理层连接最初都会发生，并且提供了一种数据包可传输的介质，但无法通过LAN进行帧转发。
For the authentication system, devices on a controlled port are forced to complete 802.1X authentication, which may take multiple round trips and many milliseconds to complete (see [IEEE.802-1X.2004]). In this time, initial DHCP, IPv6 Neighbor Discovery, Multicast Listener, or Duplicate Address Detection messages may be transmitted. However, it has also been noted that some devices have the ability for the IP stack to not see the port as up until 802.1X has completed. Hence, that issue needs investigation to determine how common it is now.
对于认证系统，受控端口上的设备被迫完成802.1X认证，这可能需要多次往返和许多毫秒才能完成（参见[IEEE.802-1X.2004]）。此时，可以传输初始DHCP、IPv6邻居发现、多播侦听器或重复地址检测消息。但是，还注意到，一些设备在802.1X完成之前，IP堆栈无法看到端口。因此，这个问题需要调查，以确定它现在有多普遍。
Additionally, any system that requires user input at this stage can extend the authentication time and thus the outage. This is problematic where hosts relying upon DHCP for address configuration time out.
此外，在此阶段需要用户输入的任何系统都可以延长身份验证时间，从而延长中断时间。当主机依赖DHCP进行地址配置超时时，这是一个问题。
Upon completion of authentication, it is feasible to signal upper-layer protocols as to LAN forwarding availability. This is not typical today, so it is necessary to assume that protocols are not aware of the preceding loss period.
认证完成后，可以向上层协议发送LAN转发可用性的信号。这在今天并不常见，因此有必要假设协议不知道之前的丢失周期。
For environments that do not require authentication, addition of a new link can cause loops where LAN frames are forwarded continually. In order to prevent loops, all LANs today run a spanning tree protocol, which selectively disables redundant ports. Devices that perform spanning tree calculations are either traditional Spanning Tree Protocol (STP) (see [IEEE.802-1D.1998]) or rapidly converging
对于不需要身份验证的环境，添加新链路可能会导致LAN帧不断转发的循环。为了防止环路，目前所有局域网都运行生成树协议，该协议选择性地禁用冗余端口。执行生成树计算的设备要么是传统的生成树协议（STP）（参见[IEEE.802-1D.1998]），要么是快速收敛的
versions of the same (Rapid Spanning Tree Protocol (RSTP) / Multiple Spanning Tree Protocol (RSTP)) (see [IEEE.802-1D.2004] and [IEEE.802-1Q.2005]).
相同版本（快速生成树协议（RSTP）/多生成树协议（RSTP））（参见[IEEE.802-1D.2004]和[IEEE.802-1Q.2005]）。
Until a port is determined to be an edge port (RSTP/MSTP), the rapid protocol speaker has identified its position within the spanning tree (RSTP/MSTP) or completed a Listening phase (STP), its packets are discarded.
在一个端口被确定为边缘端口（RSTP/MSTP）之前，快速协议说话人已在生成树（RSTP/MSTP）中确定其位置或完成监听阶段（STP），其数据包将被丢弃。
For ports that are not connected to rapid protocol switches, it takes a minimum of three seconds to perform edge port determination (see [IEEE.802-1D.2004]). Alternatively, completion of the Listening phase takes 15 seconds (see [IEEE.802-1D.1998]). During this period, the link-layer appears available, but initial packet transmissions into and out of this port will fail.
对于未连接到快速协议交换机的端口，执行边缘端口确定至少需要三秒（请参见[IEEE.802-1D.2004]）。或者，完成监听阶段需要15秒（参见[IEEE.802-1D.1998]）。在此期间，链路层似乎可用，但进出此端口的初始数据包传输将失败。
It is possible to pre-assess ports as edge ports using manual configuration of all the involved devices and thus make them immediately transmissible. This is never default behavior though.
可以使用所有相关设备的手动配置将端口预先评估为边缘端口，从而使其立即可传输。但这绝不是默认行为。
The Case of Fixed Access Networks
固定接入网的情况
In fixed access networks such as DSL and cable, the end hosts are usually connected to the access network through a residential gateway (RG). If the host interface is initialized prior to the RG getting authenticated and connected to the access network, the access network is not aware of the DAD packets that the host sent out. As an example, in DSL networks, the Access Node (Digital Subscriber Link Access Multiplexer (DSLAM)) that needs to create and maintain binding state will never see the DAD message that is required to create such a state.
在DSL和电缆等固定接入网络中，终端主机通常通过住宅网关（RG）连接到接入网络。如果主机接口在RG获得认证并连接到接入网络之前初始化，则接入网络不知道主机发送的DAD数据包。例如，在DSL网络中，需要创建和维护绑定状态的接入节点（数字用户链路接入多路复用器（DSLAM））将永远看不到创建这种状态所需的DAD消息。
A particular sub-case is the one where the SAVI device itself "drops" ND packets. In order to protect itself against DoS attacks and flash-crowds, the SAVI device will have to rate limit the processing of packets triggering the state-creation process (which requires processing from the SAVI device). This implies that the SAVI device may not process all the ND packets if it is under heavy conditions. The result is that the SAVI device will fail to create a binding for a given DAD_NS packet, which implies that the data packets coming from the host that sent the DAD_NS packet will be filtered if this approach is adopted. The problem is that the host will assume that the DAD procedure was successful and will not perform the DAD procedure again, which in turn will imply that the host will be disconnected from the network. While it is true that the SAVI device will also have to rate limit the processing of the data packets, the
特定的子情况是SAVI设备本身“丢弃”ND包的情况。为了保护自身免受DoS攻击和flash群组攻击，SAVI设备必须对触发状态创建过程（需要从SAVI设备进行处理）的数据包的处理进行速率限制。这意味着，如果SAVI设备处于恶劣条件下，它可能不会处理所有ND分组。结果是SAVI设备将无法为给定的DAD_NS数据包创建绑定，这意味着如果采用这种方法，将过滤来自发送DAD_NS数据包的主机的数据包。问题是主机将假定DAD过程成功，并且不会再次执行DAD过程，这反过来意味着主机将断开与网络的连接。虽然SAVI设备也必须对数据包的处理进行速率限制，但是
host will keep on sending data packets, so it is possible to recover from the alternative approach where data packets trigger the binding-creation procedure.
主机将继续发送数据包，因此可以从数据包触发绑定创建过程的替代方法中恢复。
If SAVI is deployed in a switched Ethernet network, topology changes may result in a SAVI device receiving packets from a legitimate user for which the SAVI device does not have a binding. Consider the following example:
如果SAVI部署在交换以太网中，则拓扑更改可能导致SAVI设备从合法用户接收SAVI设备没有绑定的数据包。考虑下面的例子：
+------+ +--------+ +---------------+
|SAVI I|-------------|SWITCH I|-------|rest of the net|
+------+ +--------+ +---------------+
| |
| +--------+
| | SAVI II|
| +--------+
| +----------+ |
+---|SWITCH II |-----+
+----------+
|
+-----+
| Host|
+-----+
+------+ +--------+ +---------------+
|SAVI I|-------------|SWITCH I|-------|rest of the net|
+------+ +--------+ +---------------+
| |
| +--------+
| | SAVI II|
| +--------+
| +----------+ |
+---|SWITCH II |-----+
+----------+
|
+-----+
| Host|
+-----+
Figure 3: Topology Example
图3：拓扑示例
Suppose that after bootstrapping, all the elements are working properly and the spanning tree is rooted in the router and includes one branch that follows the path SWITCH I - SAVI I - SWITCH II, and another branch that follows SWITCH I-SAVI II.
假设自举后，所有元素都正常工作，生成树扎根于路由器中，包括路径交换机I-SAVI I-SWITCH II后面的一个分支和交换机I-SAVI II后面的另一个分支。
Suppose that the host boots at this moment and sends the DAD_NS. The message is propagated through the spanning tree and is received by SAVI I but not by SAVI II. SAVI I creates the binding.
假设主机此时启动并发送“爸爸”。消息通过生成树传播，由SAVI I接收，但不由SAVI II接收。萨维一世创建了绑定。
Suppose that SAVI I fails and the spanning tree reconverges to SWITCH I - SAVI II - SWITCH II. Now, data packets coming from the host will be coursed through SAVI II, which does not have binding state and will drop the packets.
假设SAVI I失败，生成树重新收敛到SWITCH I-SAVI II-SWITCH II。现在，来自主机的数据包将经过SAVI II，它没有绑定状态，将丢弃数据包。
The other reason a SAVI device may not have state for a legitimate address is simply because it lost it. State can be lost due to a reboot of the SAVI device or other reasons such as memory corruption. So, the situation would be as follows. The host performs the DAD
SAVI设备可能没有合法地址的状态的另一个原因仅仅是因为它丢失了合法地址。由于SAVI设备重新启动或内存损坏等其他原因，状态可能会丢失。因此，情况如下。主持人扮演爸爸
procedure, and the SAVI device creates a binding for the host's address. The host successfully communicates for a while. The SAVI device reboots and loses the binding state. The packets coming from the host are now discarded as there is no binding state for that address. It should be noted that in this case, the host has been able to use the address successfully for a certain period of time.
过程，SAVI设备为主机地址创建绑定。主机成功通信一段时间。SAVI设备重新启动并失去绑定状态。来自主机的数据包现在被丢弃，因为该地址没有绑定状态。应该注意的是，在这种情况下，主机已经能够成功地使用地址一段时间了。
Architecturally, the degradation of the network robustness in this case can be easily explained by observing that this approach to SAVI implementation breaks the fate-sharing principle. [RFC1958] reads:
从架构上讲，这种情况下网络健壮性的降低可以通过观察到这种SAVI实现方法违反了命运共享原则来解释。[RFC1958]内容如下：
An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing).
端到端协议设计不应依赖于网络内部状态的维护（即关于端到端通信状态的信息）。这样的状态应该只在端点中维护，这样的状态只有在端点本身中断时才能被破坏（称为命运共享）。
By binding the fate of the host's connectivity to the state in the SAVI device, we are breaking this principle, and the result is degraded network resilience.
通过将主机连接的命运绑定到SAVI设备中的状态，我们打破了这一原则，其结果是网络弹性降低。
Moving on to more practical matters, we can dig deeper into the actual behavior by considering two scenarios, namely, the case where the host is directly connected to the SAVI device and the case where there is an intermediate device between the two.
继续讨论更实际的问题，我们可以通过考虑两种情况来更深入地了解实际行为，即主机直接连接到SAVI设备的情况和两者之间存在中间设备的情况。
The considered scenario is depicted in the following diagram:
所考虑的场景如下图所示：
+------+ +-----------+ +---------------+
| Host |-------------|SAVI device|-------|rest of the net|
+------+ +-----------+ +---------------+
+------+ +-----------+ +---------------+
| Host |-------------|SAVI device|-------|rest of the net|
+------+ +-----------+ +---------------+
Figure 4: Host Attached Directly to SAVI Device
图4：直接连接到SAVI设备的主机
The key distinguishing element of this scenario is that the host is directly connected to the SAVI device. As a result, if the SAVI device reboots, the host will see the carrier disappear and appear again.
此场景的关键区别在于主机直接连接到SAVI设备。因此，如果SAVI设备重新启动，主机将看到运营商消失并再次出现。
[RFC4862] requires that the DAD procedure is performed when the IP address is assigned to the interface (see [RFC4862], Section 5.4):
[RFC4862]要求在将IP地址分配给接口时执行DAD程序（见[RFC4862]，第5.4节）：
Duplicate Address Detection:
重复地址检测：
Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, with the following exceptions: ...
在将所有单播地址分配给接口之前，必须对其执行重复地址检测，无论这些地址是通过无状态自动配置、DHCPv6还是手动配置获得的，但以下情况除外：。。。
However, it has been stated that some of the widely used OSs actually do perform DAD each time the link is up, but further data would be required for this to be taken for granted. Assuming that behavior, this implies that if the loss of state in the SAVI device also results in the link to the host going down, then the host using the tested OSs would redo the DAD procedure allowing the recreation of the binding state in the SAVI device and preserving the connectivity of the host. This would be the case if the SAVI device reboots. It should be noted, however, that it is also possible that the binding state is lost because of an error in the SAVI process and that the SAVI link does not goes down. In this case, the host would not redo the DAD procedure. However, it has been pointed out that it would be possible to require the SAVI process to flap the links of the device it is running, in order to make sure that the link goes down each time the SAVI process restarts and to improve the chances the host will redo the DAD procedure when the SAVI process is rebooted.
然而，有人指出，一些广泛使用的OSs实际上在每次链接打开时都执行DAD，但需要进一步的数据才能认为这是理所当然的。假设该行为，这意味着如果SAVI设备中的状态丢失也导致到主机的链接中断，那么使用测试OSs的主机将重做DAD过程，从而允许在SAVI设备中重新创建绑定状态并保持主机的连接。如果SAVI设备重新启动，就会出现这种情况。然而，应该注意的是，绑定状态也可能由于SAVI过程中的错误而丢失，并且SAVI链接没有断开。在这种情况下，主机不会重做DAD过程。但是，有人指出，可以要求SAVI进程调整它正在运行的设备的链路，以确保每次SAVI进程重新启动时链路都会断开，并提高主机在SAVI进程重新启动时重做DAD过程的机会。
A.1.3.2. The Case of a Host Connected to the SAVI Device through One or More Legacy Devices
A.1.3.2. 主机通过一个或多个传统设备连接到SAVI设备的情况
The considered scenario is depicted in the following diagram:
所考虑的场景如下图所示：
+------+ +-------------+ +-----------+ +---------------+
| Host |----|Legacy device|-----|SAVI device|----|rest of the net|
+------+ +-------------+ +-----------+ +---------------+
+------+ +-------------+ +-----------+ +---------------+
| Host |----|Legacy device|-----|SAVI device|----|rest of the net|
+------+ +-------------+ +-----------+ +---------------+
Figure 5: Host Attached to a Legacy Device
图5：连接到旧设备的主机
The key distinguishing element of this scenario is that the host is not directly connected to the SAVI device. As a result, if the SAVI device reboots, the host will not see any changes.
此场景的关键区别在于主机未直接连接到SAVI设备。因此，如果SAVI设备重新启动，主机将看不到任何更改。
In this case, the host would get disconnected from the rest of the network since the SAVI device would filter all its packets once the state has gone. As the node will not perform the DAD procedure again, it will remain disconnected until it reboots.
在这种情况下，主机将与网络的其余部分断开连接，因为一旦状态消失，SAVI设备将过滤其所有数据包。由于节点不会再次执行DAD过程，因此它将保持断开状态，直到重新启动。
As a final comment, it should be noted that it may not be obvious to the network admin which scenario its network is running. Consider the case of a campus network where all the switches in the network are SAVI capable. A small hub connected in the office would turn this into the scenario where the host is not directly connected to the SAVI device. Moreover, consider the case of a host running multiple virtual machines connected through a virtual hub. Depending on the implementation of such a virtual hub, this may turn a directly connected host scenario to the scenario where the multiple (virtual) hosts are connected through a legacy (virtual) hub.
作为最后的评论，应该注意的是，对于网络管理员来说，其网络正在运行的场景可能并不明显。考虑一个校园网络的情况，其中网络中的所有交换机都具有SAVI能力。办公室中连接的小型集线器将使主机不直接连接到SAVI设备。此外，考虑主机通过虚拟集线器连接多个虚拟机的情况。根据这种虚拟集线器的实现情况，这可能会将直接连接的主机场景转变为多个（虚拟）主机通过传统（虚拟）集线器连接的场景。
A.1.3.2.1. Enforcing Direct Connectivity between the SAVI Device and the Host
A.1.3.2.1. 强制SAVI设备与主机之间的直接连接
It has been argued that enforcing direct connectivity between the SAVI device and the end host is actually a benefit. There are several comments that can be made in this respect:
有人认为，在SAVI设备和终端主机之间实施直接连接实际上是一种好处。在这方面可以提出几点意见：
o First, it may well be the case in some scenarios that this is desirable, but it is certainly not the case in most scenarios. Because of that, the issue of enforcing direct connectivity must be treated as orthogonal to how data packets for which there is no binding are treated, since a general solution must support directly connected nodes and nodes connected through legacy switches.
o 首先，在某些情况下这可能是可取的，但在大多数情况下肯定不是这样。因此，强制直接连接的问题必须被视为与不存在绑定的数据包的处理方式正交，因为通用解决方案必须支持直接连接的节点和通过传统交换机连接的节点。
o Second, as a matter of fact, the resulting behavior described above would not actually enforce direct connectivity between the end host and the SAVI device as it would work as long as the SAVI device does not reboot. So, the argument being made is that this approach is not good enough to provide a robust network service, but it is not bad enough to enforce the direct connectivity of the host to the SAVI switch.
o 其次，事实上，上面描述的结果行为实际上不会强制终端主机和SAVI设备之间的直接连接，因为只要SAVI设备不重新启动，它就可以工作。因此，提出的论点是，这种方法不足以提供强健的网络服务，但也不足以强制主机直接连接到SAVI交换机。
o Third, it should be noted that topology enforcement is not part of the SAVI problem space and that the SAVI problem by itself is complex enough without adding additional requirements.
o 第三，应该注意的是，拓扑强制不是SAVI问题空间的一部分，SAVI问题本身就足够复杂，无需增加额外的需求。
The FCFS SAVI mechanism is composed of two main functions, namely, the mechanisms for tracking compliant and non-compliant data packets and the actions to be performed upon the detection of a non-compliant packet. Throughout this specification, we recommend discarding non-compliant data packets. This is because forwarding non-compliant data packets is essentially allowing packets with spoofed source addresses to flow throughout the network. However, there are alternative actions that can be taken with respect to these packets.
FCFS SAVI机制由两个主要功能组成，即跟踪兼容和不兼容数据包的机制以及在检测到不兼容数据包时要执行的操作。在本规范中，我们建议丢弃不符合要求的数据包。这是因为转发不符合要求的数据包本质上是允许具有伪造源地址的数据包在整个网络中流动。但是，可以针对这些数据包采取其他操作。
For instance, it would be possible to forward the packets and trigger an alarm to network administrators to make them aware of the situation. Similarly, it would be possible to log these events and allow the tracking down cases where packets with spoofed addresses were used for malicious purposes. The reason a site deploying SAVI may not want to take milder actions like the ones mentioned above instead of discarding packets is because there may be cases where the non-compliant packets may be legitimate packets (for example, in the case that the SAVI device is malfunctioning and has failed to create the appropriate bindings upon the reception of a DAD packet).
例如，可以转发数据包并向网络管理员触发警报，使他们了解情况。类似地，可以记录这些事件，并允许跟踪带有伪造地址的数据包被用于恶意目的的情况。部署SAVI的站点可能不希望采取上述较温和的措施而不是丢弃数据包，这是因为可能存在不符合要求的数据包可能是合法数据包的情况（例如，如果SAVI设备出现故障，并且在接收到DAD数据包时未能创建适当的绑定）。
Authors' Addresses
作者地址
Erik Nordmark Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 United States
埃里克诺德马克思科系统公司，麦卡锡大道510号。美国加利福尼亚州米尔皮塔斯95035
EMail: nordmark@acm.org
EMail: nordmark@acm.org
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
Eric Levy-Abegnoli Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot-Sophia Antipolis - 06410 France
Eric Levy Abegnoli Cisco Systems Village d'Enterprises Green Side-法国索菲亚安提波利斯市鲁马尼尔大道400号-06410
EMail: elevyabe@cisco.com
EMail: elevyabe@cisco.com