Internet Engineering Task Force (IETF) J. Bi
Request for Comments: 7513 J. Wu
Category: Standards Track G. Yao
ISSN: 2070-1721 Tsinghua Univ.
F. Baker
Cisco
May 2015
Internet Engineering Task Force (IETF) J. Bi
Request for Comments: 7513 J. Wu
Category: Standards Track G. Yao
ISSN: 2070-1721 Tsinghua Univ.
F. Baker
Cisco
May 2015
Source Address Validation Improvement (SAVI) Solution for DHCP
DHCP源地址验证改进（SAVI）解决方案
Abstract
摘要
This document specifies the procedure for creating a binding between a DHCPv4/DHCPv6-assigned IP address and a binding anchor on a Source Address Validation Improvement (SAVI) device. The bindings set up by this procedure are used to filter packets with forged source IP addresses. This mechanism complements BCP 38 (RFC 2827) ingress filtering, providing finer-grained source IP address validation.
本文档规定了在DHCPv4/DHCPv6分配的IP地址和源地址验证改进（SAVI）设备上的绑定锚之间创建绑定的过程。此过程设置的绑定用于过滤具有伪造源IP地址的数据包。该机制补充了BCP 38（RFC 2827）入口过滤，提供了更细粒度的源IP地址验证。
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/rfc7513.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7513.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Deployment Scenario and Configuration . . . . . . . . . . . . 8
4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8
4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 10
4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10
4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 11
4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 12
4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 13
4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13
4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 14
4.3.3. On the Placement of the DHCP Server and Relay . . . . 15
4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 15
4.3.5. Considerations regarding Binding Anchors . . . . . . 16
4.4. Other Device Configuration . . . . . . . . . . . . . . . 17
5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17
6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18
6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Binding States Description . . . . . . . . . . . . . . . 19
6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19
6.3.2. Control Message Arriving Events . . . . . . . . . . . 19
6.4. The State Machine of DHCP Snooping Process . . . . . . . 21
6.4.1. Initial State: NO_BIND . . . . . . . . . . . . . . . 21
6.4.2. Initial State: INIT_BIND . . . . . . . . . . . . . . 24
6.4.3. Initial State: BOUND . . . . . . . . . . . . . . . . 27
6.4.4. Table of State Machine . . . . . . . . . . . . . . . 30
7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 31
7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 32
7.3. Additional Binding States Description . . . . . . . . . . 33
7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.5. Message Sender Functions . . . . . . . . . . . . . . . . 35
7.5.1. Duplicate Detection Message Sender . . . . . . . . . 35
7.5.2. Leasequery Message Sender . . . . . . . . . . . . . . 36
7.5.3. Address Verification Message Sender . . . . . . . . . 36
7.6. Initial State: NO_BIND . . . . . . . . . . . . . . . . . 37
7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a
matched binding is received . . . . . . . . . . . . . 37
7.6.2. Events Not Observed in NO_BIND for Data Snooping . . 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Deployment Scenario and Configuration . . . . . . . . . . . . 8
4.1. Elements and Scenario . . . . . . . . . . . . . . . . . . 8
4.2. SAVI Binding Type Attributes . . . . . . . . . . . . . . 10
4.2.1. Trust Attribute . . . . . . . . . . . . . . . . . . . 10
4.2.2. DHCP-Trust Attribute . . . . . . . . . . . . . . . . 11
4.2.3. DHCP-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.4. Data-Snooping Attribute . . . . . . . . . . . . . . . 11
4.2.5. Validating Attribute . . . . . . . . . . . . . . . . 12
4.2.6. Table of Mutual Exclusions . . . . . . . . . . . . . 13
4.3. Perimeter . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.1. SAVI-DHCP Perimeter Overview . . . . . . . . . . . . 13
4.3.2. SAVI-DHCP Perimeter Configuration Guideline . . . . . 14
4.3.3. On the Placement of the DHCP Server and Relay . . . . 15
4.3.4. An Alternative Deployment . . . . . . . . . . . . . . 15
4.3.5. Considerations regarding Binding Anchors . . . . . . 16
4.4. Other Device Configuration . . . . . . . . . . . . . . . 17
5. Binding State Table (BST) . . . . . . . . . . . . . . . . . . 17
6. DHCP Snooping Process . . . . . . . . . . . . . . . . . . . . 18
6.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Binding States Description . . . . . . . . . . . . . . . 19
6.3. Events . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3.1. Timer Expiration Event . . . . . . . . . . . . . . . 19
6.3.2. Control Message Arriving Events . . . . . . . . . . . 19
6.4. The State Machine of DHCP Snooping Process . . . . . . . 21
6.4.1. Initial State: NO_BIND . . . . . . . . . . . . . . . 21
6.4.2. Initial State: INIT_BIND . . . . . . . . . . . . . . 24
6.4.3. Initial State: BOUND . . . . . . . . . . . . . . . . 27
6.4.4. Table of State Machine . . . . . . . . . . . . . . . 30
7. Data Snooping Process . . . . . . . . . . . . . . . . . . . . 31
7.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 32
7.3. Additional Binding States Description . . . . . . . . . . 33
7.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 33
7.5. Message Sender Functions . . . . . . . . . . . . . . . . 35
7.5.1. Duplicate Detection Message Sender . . . . . . . . . 35
7.5.2. Leasequery Message Sender . . . . . . . . . . . . . . 36
7.5.3. Address Verification Message Sender . . . . . . . . . 36
7.6. Initial State: NO_BIND . . . . . . . . . . . . . . . . . 37
7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a
matched binding is received . . . . . . . . . . . . . 37
7.6.2. Events Not Observed in NO_BIND for Data Snooping . . 38
7.7. Initial State: DETECTION . . . . . . . . . . . . . . . . 39
7.7.1. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 39
7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply / NA Message
Received from Unexpected System . . . . . . . . . . . 39
7.7.3. Events Not Observed in DETECTION . . . . . . . . . . 39
7.8. Initial State: RECOVERY . . . . . . . . . . . . . . . . . 40
7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
or successful LEASEQUERY-REPLY is received . . . . . 40
7.8.2. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 41
7.8.3. Events Not Observed in RECOVERY . . . . . . . . . . . 41
7.9. Initial State: VERIFY . . . . . . . . . . . . . . . . . . 41
7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
or successful LEASEQUERY-REPLY is received . . . . . 41
7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is
received from the device attached via the binding
anchor . . . . . . . . . . . . . . . . . . . . . . . 42
7.9.3. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 42
7.9.4. Event: EVE_DATA_EXPIRE . . . . . . . . . . . . . . . 43
7.9.5. Events Not Observed in VERIFY . . . . . . . . . . . . 43
7.10. Initial State: BOUND . . . . . . . . . . . . . . . . . . 43
7.11. Table of State Machine . . . . . . . . . . . . . . . . . 44
8. Filtering Specification . . . . . . . . . . . . . . . . . . . 45
8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 46
8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 46
9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 47
9.1. Attribute Configuration Restoration . . . . . . . . . . . 47
9.2. Binding State Restoration . . . . . . . . . . . . . . . . 47
10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
11.1. Security Problems with the Data Snooping Process . . . . 48
11.2. Securing Leasequery Operations . . . . . . . . . . . . . 49
11.3. Client Departure Issues . . . . . . . . . . . . . . . . 49
11.4. Compatibility with Detecting Network Attachment (DNA) . 50
11.5. Binding Number Limitation . . . . . . . . . . . . . . . 51
11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 51
11.7. Fragmented DHCP Messages . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Normative References . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . 53
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
7.7. Initial State: DETECTION . . . . . . . . . . . . . . . . 39
7.7.1. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 39
7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply / NA Message
Received from Unexpected System . . . . . . . . . . . 39
7.7.3. Events Not Observed in DETECTION . . . . . . . . . . 39
7.8. Initial State: RECOVERY . . . . . . . . . . . . . . . . . 40
7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
or successful LEASEQUERY-REPLY is received . . . . . 40
7.8.2. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 41
7.8.3. Events Not Observed in RECOVERY . . . . . . . . . . . 41
7.9. Initial State: VERIFY . . . . . . . . . . . . . . . . . . 41
7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE
or successful LEASEQUERY-REPLY is received . . . . . 41
7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is
received from the device attached via the binding
anchor . . . . . . . . . . . . . . . . . . . . . . . 42
7.9.3. Event: EVE_ENTRY_EXPIRE . . . . . . . . . . . . . . . 42
7.9.4. Event: EVE_DATA_EXPIRE . . . . . . . . . . . . . . . 43
7.9.5. Events Not Observed in VERIFY . . . . . . . . . . . . 43
7.10. Initial State: BOUND . . . . . . . . . . . . . . . . . . 43
7.11. Table of State Machine . . . . . . . . . . . . . . . . . 44
8. Filtering Specification . . . . . . . . . . . . . . . . . . . 45
8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 46
8.2. Control Packet Filtering . . . . . . . . . . . . . . . . 46
9. State Restoration . . . . . . . . . . . . . . . . . . . . . . 47
9.1. Attribute Configuration Restoration . . . . . . . . . . . 47
9.2. Binding State Restoration . . . . . . . . . . . . . . . . 47
10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
11.1. Security Problems with the Data Snooping Process . . . . 48
11.2. Securing Leasequery Operations . . . . . . . . . . . . . 49
11.3. Client Departure Issues . . . . . . . . . . . . . . . . 49
11.4. Compatibility with Detecting Network Attachment (DNA) . 50
11.5. Binding Number Limitation . . . . . . . . . . . . . . . 51
11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 51
11.7. Fragmented DHCP Messages . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Normative References . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . 53
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
This document describes a fine-grained source address validation mechanism for IPv4 and IPv6 packets. This mechanism creates bindings between IP addresses assigned to network interfaces by DHCP and suitable binding anchors (Section 4.3.5). As discussed in Section 3 and [RFC7039], a "binding anchor" is an attribute that is immutable or difficult to change that may be used to identify the system an IP address has been assigned to; common examples include a Media Access Control (MAC) address found on an Ethernet switch port or Wi-Fi security association. The bindings are used to identify and filter packets originated by these interfaces using forged source IP addresses. In this way, this mechanism can prevent hosts from using IP addresses assigned to any other attachment point in or not associated with the network. This behavior is referred to as "spoofing" and is key to amplification attacks, in which a set of systems send messages to another set of systems claiming to be from a third set of systems, and sending the replies to systems that don't expect them. Whereas BCP 38 [RFC2827] protects a network from a neighboring network by providing prefix granularity source IP address validity, this mechanism protects a network, including a Local Area Network, from itself by providing address granularity source IP validity when DHCP/DHCPv6 is used to assign IPv4/IPv6 addresses. Both provide a certain level of traceability, in that packet drops indicate the presence of a system that is producing packets with spoofed IP addresses.
本文档描述了IPv4和IPv6数据包的细粒度源地址验证机制。该机制在DHCP分配给网络接口的IP地址和合适的绑定锚之间创建绑定（第4.3.5节）。如第3节和[RFC7039]中所述，“绑定锚定”是一个不可变或难以更改的属性，可用于标识已分配IP地址的系统；常见示例包括在以太网交换机端口或Wi-Fi安全关联上找到的媒体访问控制（MAC）地址。绑定用于使用伪造的源IP地址识别和过滤由这些接口发起的数据包。通过这种方式，该机制可以防止主机使用分配给网络中任何其他连接点或与网络无关的任何其他连接点的IP地址。这种行为被称为“欺骗”，是放大攻击的关键，在放大攻击中，一组系统向另一组声称来自第三组系统的系统发送消息，并向不希望收到回复的系统发送回复。尽管BCP 38[RFC2827]通过提供前缀粒度源IP地址有效性来保护网络不受相邻网络的影响，但当使用DHCP/DHCPv6分配IPv4/IPv6地址时，该机制通过提供地址粒度源IP有效性来保护网络（包括局域网）不受自身的影响。两者都提供了一定程度的可追溯性，因为数据包丢失表示存在一个系统，该系统正在生成具有伪造IP地址的数据包。
SAVI-DHCP snoops DHCP address assignments to set up bindings between IP addresses assigned by DHCP and corresponding binding anchors. It includes the DHCPv4 and DHCPv6 Snooping Process (Section 6) and the Data Snooping Process (Section 7), as well as a number of other technical details. The Data Snooping Process is a data-triggered procedure that snoops the IP header of data packets to set up bindings. It is designed to avoid a permanent blockage of valid addresses in the case that DHCP snooping is insufficient to set up all the valid bindings.
SAVI-DHCP嗅探DHCP地址分配，以在DHCP分配的IP地址和相应的绑定锚之间建立绑定。它包括DHCPv4和DHCPv6监听过程（第6节）和数据监听过程（第7节），以及许多其他技术细节。数据窥探过程是一个数据触发过程，用于窥探数据包的IP头以设置绑定。它旨在避免在DHCP侦听不足以设置所有有效绑定的情况下永久阻塞有效地址。
This mechanism is designed for the stateful DHCP scenario [RFC2131] [RFC3315]. Stateless DHCP [RFC3736] is out of scope for this document, as it has nothing to do with IP address allocation. An alternative SAVI method would have be used in those cases. For hosts using Stateless Address Autoconfiguration (SLAAC) to allocate addresses, First-Come, First-Served Source Address Validation Improvement (FCFS SAVI) [RFC6620] should be enabled. SAVI-DHCP is primarily designed for pure DHCP scenarios in which only addresses assigned through DHCP are allowed. However, it does not block link-
此机制是为有状态DHCP方案[RFC2131][RFC3315]设计的。无状态DHCP[RFC3736]不在本文档的范围内，因为它与IP地址分配无关。在这些情况下，将使用另一种SAVI方法。对于使用无状态地址自动配置（SLAAC）分配地址的主机，应启用先到先得的源地址验证改进（FCFS SAVI）[RFC6620]。SAVI-DHCP主要设计用于纯DHCP场景，其中仅允许通过DHCP分配地址。但是，它不会阻止链接-
local addresses, as they are not assigned using DHCP. It is RECOMMENDED that the administration deploy a SAVI solution for link-local addresses, e.g., FCFS SAVI [RFC6620].
本地地址，因为它们不是使用DHCP分配的。建议管理部门为链路本地地址部署SAVI解决方案，例如FCFS SAVI[RFC6620]。
This mechanism works for networks that use DHCPv4 only, DHCPv6 only, or both DHCPv4 and DHCPv6. However, the DHCP address assignment mechanism in IPv4/IPv6 transition scenarios, e.g., [RFC7341], are beyond the scope of this document.
此机制适用于仅使用DHCPv4、仅使用DHCPv6或同时使用DHCPv4和DHCPv6的网络。但是，IPv4/IPv6转换场景中的DHCP地址分配机制（例如[RFC7341]）超出了本文档的范围。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Binding anchor: A "binding anchor" is defined to be a physical and/or link-layer property of an attached device, as in [RFC7039]. A list of sample binding anchors can be found in Section 3.2 of that document. To the degree possible, a binding anchor associates an IP address with something unspoofable that identifies a single-client system or one of its interfaces. See Section 4.3.5 for more detail.
绑定锚：“绑定锚”定义为连接设备的物理和/或链路层属性，如[RFC7039]所示。可在该文件第3.2节中找到样本绑定锚的列表。在可能的程度上，绑定锚将IP地址与标识单个客户端系统或其某个接口的不可预知的内容相关联。详见第4.3.5节。
Attribute: A configurable property of each binding anchor (port, MAC address, or other information) that indicates the actions to be performed on packets received from the attached network device.
属性：每个绑定锚（端口、MAC地址或其他信息）的可配置属性，指示对从连接的网络设备接收的数据包执行的操作。
DHCP address: An IP address assigned via DHCP.
DHCP地址：通过DHCP分配的IP地址。
SAVI-DHCP: The name of this SAVI function for DHCP-assigned addresses.
SAVI-DHCP：DHCP分配地址的此SAVI函数的名称。
SAVI device: A network device on which SAVI-DHCP is enabled.
SAVI设备：启用SAVI-DHCP的网络设备。
Non-SAVI device: A network device on which SAVI-DHCP is not enabled.
非SAVI设备：未启用SAVI-DHCP的网络设备。
DHCP Client-to-Server message: A message that is sent from a DHCP client to a DHCP server or DHCP servers and is one of the following types:
DHCP客户端到服务器消息：从DHCP客户端发送到DHCP服务器或DHCP服务器的消息，属于以下类型之一：
o DHCPv4 Discover: DHCPDISCOVER [RFC2131].
o DHCPv4 Discover:DHCPDISCOVER[RFC2131]。
o DHCPv4 Request: DHCPREQUEST generated during SELECTING state [RFC2131].
o DHCPv4请求：在选择状态[RFC2131]期间生成的DHCPREQUEST。
o DHCPv4 Renew: DHCPREQUEST generated during RENEWING state [RFC2131].
o DHCPv4续订：在续订状态[RFC2131]期间生成的DHCPREQUEST。
o DHCPv4 Rebind: DHCPREQUEST generated during REBINDING state [RFC2131].
o DHCPv4重新绑定：在重新绑定状态[RFC2131]期间生成的DHCPREQUEST。
o DHCPv4 Reboot: DHCPREQUEST generated during INIT-REBOOT state [RFC2131].
o DHCPv4重新启动：在初始重新启动状态[RFC2131]期间生成的DHCPREQUEST。
o Note: DHCPv4 Request/Renew/Rebind/Reboot messages can be identified based on Table 4 of [RFC2131].
o 注：DHCPv4请求/续订/重新绑定/重新启动消息可根据[RFC2131]的表4识别。
o DHCPv4 Decline: DHCPDECLINE [RFC2131].
o DHCPv4下降：DHCPDecept[RFC2131]。
o DHCPv4 Release: DHCPRELEASE [RFC2131].
o DHCPv4发行版：DHCPRELEASE[RFC2131]。
o DHCPv4 Inform: DHCPINFORM [RFC2131].
o DHCPv4通知：DHCPINFORM[RFC2131]。
o DHCPv4 DHCPLEASEQUERY: A message sent to inquire about the lease that might exist for an IPv4 address [RFC4388].
o DHCPv4 DHCPLEASEQUERY：发送的消息用于查询IPv4地址[RFC4388]可能存在的租约。
o DHCPv6 Request: REQUEST [RFC3315].
o DHCPv6请求：请求[RFC3315]。
o DHCPv6 Solicit: SOLICIT [RFC3315].
o DHCPv6请求：请求[RFC3315]。
o DHCPv6 Confirm: CONFIRM [RFC3315].
o DHCPv6确认：确认[RFC3315]。
o DHCPv6 Decline: DECLINE [RFC3315].
o DHCPv6下降：下降[RFC3315]。
o DHCPv6 Release: RELEASE [RFC3315].
o DHCPv6发布：发布[RFC3315]。
o DHCPv6 Rebind: REBIND [RFC3315].
o DHCPv6重新绑定：重新绑定[RFC3315]。
o DHCPv6 Renew: RENEW [RFC3315].
o DHCPv6续订：续订[RFC3315]。
o DHCPv6 Information-Request: INFORMATION-REQUEST [RFC3315].
o DHCPv6信息请求：信息请求[RFC3315]。
o DHCPv6 LEASEQUERY: A message sent to inquire about the lease that might exist for an IPv6 address [RFC5007].
o DHCPv6租约：发送的消息，用于查询IPv6地址[RFC5007]可能存在的租约。
DHCP Server-to-Client message: A message that is sent from a DHCP server to a DHCP client and is one of the following types:
DHCP服务器到客户端消息：从DHCP服务器发送到DHCP客户端的消息，属于以下类型之一：
o DHCPv4 ACK: DHCPACK [RFC2131].
o DHCPv4确认：DHCPACK[RFC2131]。
o DHCPv4 NAK: DHCPNAK [RFC2131].
o DHCPv4-NAK:DHCPNAK[RFC2131]。
o DHCPv4 Offer: DHCPOFFER [RFC2131].
o DHCPv4报价：DHCPOFFER[RFC2131]。
o DHCPv4 DHCPLEASEACTIVE: A response to a DHCPLEASEQUERY request containing lease information [RFC4388].
o DHCPv4 DHCPLEASEACTIVE：对包含租赁信息的DHCPLEASEQUERY请求的响应[RFC4388]。
o DHCPv4 DHCPLEASEUNKNOWN: A response to a DHCPLEASEQUERY request indicating that the server does not manage the address [RFC4388].
o DHCPv4 DHCPLEASEUNKNOWN：对DHCPLEASEQUERY请求的响应，该请求指示服务器不管理地址[RFC4388]。
o DHCPv4 DHCPLEASEUNASSIGNED: A response to a DHCPLEASEQUERY request indicating that the server manages the address and there is no current lease [RFC4388].
o DHCPv4 DHCPLEASEUNASSIGNED：对DHCPLEASEQUERY请求的响应，该请求指示服务器管理地址，并且没有当前租约[RFC4388]。
o DHCPv6 Reply: REPLY [RFC3315].
o DHCPv6回复：回复[RFC3315]。
o DHCPv6 Advertise: ADVERTISE [RFC3315].
o DHCPv6播发：播发[RFC3315]。
o DHCPv6 Reconfigure: RECONFIGURE [RFC3315].
o DHCPv6重新配置：重新配置[RFC3315]。
o DHCPv6 LEASEQUERY-REPLY: A response to a LEASEQUERY request [RFC5007].
o DHCPv6租赁请求回复：对租赁请求的响应[RFC5007]。
Lease time: The lease time in IPv4 [RFC2131] or the valid lifetime in IPv6 [RFC3315].
租约时间：IPv4[RFC2131]中的租约时间或IPv6[RFC3315]中的有效生存期。
Binding entry: A rule that associates an IP address with a binding anchor.
绑定条目：将IP地址与绑定锚关联的规则。
Binding State Table (BST): The data structure that contains the binding entries.
绑定状态表（BST）：包含绑定项的数据结构。
Binding entry limit: The maximum number of binding entries that may be associated with a binding anchor. Limiting the number of binding entries per binding anchor prevents a malicious or malfunctioning node from overloading the binding table on a SAVI device.
绑定条目限制：可能与绑定锚关联的最大绑定条目数。限制每个绑定锚点的绑定条目数可防止恶意或故障节点在SAVI设备上过载绑定表。
Direct attachment: Ideally, a SAVI device is an access device that hosts are attached to directly. In such a case, the hosts are direct attachments (i.e., they attach directly) to the SAVI device.
直接连接：理想情况下，SAVI设备是主机直接连接到的访问设备。在这种情况下，主机是SAVI设备的直接附件（即，它们直接连接）。
Indirect attachment: A SAVI device MAY be an aggregation device that other access devices are attached to and that hosts in turn attach to. In such a case, the hosts are indirect attachments (i.e., they attach indirectly) to the SAVI device.
间接连接：SAVI设备可能是一个聚合设备，其他访问设备连接到该设备，而主机又连接到该设备。在这种情况下，主机是SAVI设备的间接附件（即，它们间接连接）。
Unprotected link: Unprotected links are links that connect to hosts or networks of hosts that receive their DHCP traffic by another path and are therefore outside the SAVI perimeter.
未保护链路：未保护链路是连接到主机或主机网络的链路，这些主机或主机网络通过另一条路径接收DHCP流量，因此位于SAVI外围。
Unprotected device: An unprotected device is a device associated with an unprotected link. One example might be the gateway router of a network.
未受保护的设备：未受保护的设备是与未受保护的链接关联的设备。一个例子可能是网络的网关路由器。
Protected link: If DHCP messages for a given attached device always use a given link, the link is considered to be "protected" by the SAVI device and is therefore within the SAVI perimeter.
受保护链路：如果给定连接设备的DHCP消息始终使用给定链路，则该链路被视为受SAVI设备“保护”，因此在SAVI周界内。
Protected device: A protected device is a device associated with a protected link. One example might be a desktop switch in the network, or a host.
受保护设备：受保护设备是与受保护链接关联的设备。例如，网络中的桌面交换机或主机。
Cut vertex: A cut vertex is any vertex whose removal increases the number of connected components in a (network) graph. This is a concept in graph theory. This term is used in Section 6.1 to accurately specify the required deployment location of SAVI devices when they only perform the DHCP Snooping Process.
割点：割点是指其移除会增加（网络）图中连接组件数量的任何顶点。这是图论中的一个概念。该术语在第6.1节中用于准确指定SAVI设备在仅执行DHCP窥探过程时所需的部署位置。
Identity Association (IA): "A collection of addresses assigned to a client" [RFC3315].
身份关联（IA）：“分配给客户端的地址集合”[RFC3315]。
Detection message: A Neighbor Solicitation or ARP message intended by the Data Snooping Process to detect a duplicate address.
检测消息：数据窥探过程用于检测重复地址的邻居请求或ARP消息。
DHCP_DEFAULT_LEASE: Default lifetime for a DHCPv6 address when the binding is triggered by a DHCPv6 Confirm message but a DHCPv6 Leasequery exchange [RFC5007] cannot be performed by the SAVI device to fetch the lease.
DHCP_DEFAULT_LEASE：当绑定由DHCPv6确认消息触发，但SAVI设备无法执行DHCPv6租赁交换[RFC5007]以获取租赁时，DHCPv6地址的默认生存期。
The essential elements in a SAVI-DHCP deployment scenario include at least one DHCP server (which may or may not be assigned an address using DHCP and therefore may or may not be protected), zero or more protected DHCP clients, and one or more SAVI devices. It may also include DHCP relays, when the DHCP server is not co-located with a set of clients, and zero or more protected non-SAVI devices. Outside the perimeter, via unprotected links, there may be many unprotected devices.
SAVI-DHCP部署场景中的基本元素包括至少一个DHCP服务器（可以使用DHCP为其分配地址，也可以不使用DHCP为其分配地址，因此可以不受保护）、零个或多个受保护的DHCP客户端以及一个或多个SAVI设备。当DHCP服务器与一组客户端不在同一位置时，它还可以包括DHCP中继，以及零个或多个受保护的非SAVI设备。在外围之外，通过未受保护的链路，可能存在许多未受保护的设备。
+-------------+
| Unprotected |
| Device |
+------+------+
|
+--------+ +-----+------+ +----------+
|DHCP +-----+ Non-SAVI +----+Bogus DHCP|
|Server A| | Device 1 | |Server |
+--------+ +-----+------+ +----------+
|trusted, unprotected link
. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
. | .
. Protection +---+------+ trusted link .
. Perimeter | SAVI +--------------+ .
. | Device C | | .
. +---+------+ | .
. | | .
. untrusted, +----------+ +---+------+ +------+---+ .
. protected | SAVI | | Non-SAVI | | SAVI | .
. link+------+ Device A +----+ Device 3 +-------+ Device B | .
. | +----+--+--+ +----------+ +-+---+----+ .
. | | +----------+ . . . . . | | .
. | . . . . . . | . . | | .
. | . | . | . +--------+ | .
. +----+-----+. +--+---+ . +----+-+ . +--+---+ . +---+----+ .
. | Non-SAVI |. |Client| . |DHCP | . |Client| . |DHCP | .
. | Device 2 |. |A | . |Relay | . |B | . |Server B| .
. +----------+. +------+ . +------+ . +------+ . +--------+ .
. . . . . . . . . . . . . . . . . . .
+-------------+
| Unprotected |
| Device |
+------+------+
|
+--------+ +-----+------+ +----------+
|DHCP +-----+ Non-SAVI +----+Bogus DHCP|
|Server A| | Device 1 | |Server |
+--------+ +-----+------+ +----------+
|trusted, unprotected link
. . . . . . . . . . . . . . . . .|. . . . . . . . . . . . . .
. | .
. Protection +---+------+ trusted link .
. Perimeter | SAVI +--------------+ .
. | Device C | | .
. +---+------+ | .
. | | .
. untrusted, +----------+ +---+------+ +------+---+ .
. protected | SAVI | | Non-SAVI | | SAVI | .
. link+------+ Device A +----+ Device 3 +-------+ Device B | .
. | +----+--+--+ +----------+ +-+---+----+ .
. | | +----------+ . . . . . | | .
. | . . . . . . | . . | | .
. | . | . | . +--------+ | .
. +----+-----+. +--+---+ . +----+-+ . +--+---+ . +---+----+ .
. | Non-SAVI |. |Client| . |DHCP | . |Client| . |DHCP | .
. | Device 2 |. |A | . |Relay | . |B | . |Server B| .
. +----------+. +------+ . +------+ . +------+ . +--------+ .
. . . . . . . . . . . . . . . . . . .
Figure 1: SAVI-DHCP Scenario
图1:SAVI-DHCP场景
Figure 1 shows a deployment scenario that contains these elements. Note that a physical device can instantiate multiple elements, e.g., a switch can be both a SAVI device and a DHCP relay, or in a cloud-computing environment, a physical host may contain a virtual switch plus some number of virtual hosts. In such cases, the links are logical links rather than physical links.
图1显示了包含这些元素的部署场景。请注意，物理设备可以实例化多个元素，例如，交换机可以是SAVI设备和DHCP中继，或者在云计算环境中，物理主机可以包含虚拟交换机加上一些虚拟主机。在这种情况下，链接是逻辑链接而不是物理链接。
Networks are not usually isolated. As a result, traffic from other networks, including transit traffic as specified in [RFC6620] (e.g., traffic from another SAVI switch or a router) may enter a SAVI-DHCP network through the unprotected links. Since SAVI solutions are limited to validating traffic generated from a local link, SAVI-DHCP does not set up bindings for addresses assigned in other networks and cannot validate them. Traffic from unprotected links should be checked by an unprotected device or mechanisms described in
网络通常不是孤立的。因此，来自其他网络的流量，包括[RFC6620]中规定的传输流量（例如，来自另一个SAVI交换机或路由器的流量），可以通过未受保护的链路进入SAVI-DHCP网络。由于SAVI解决方案仅限于验证从本地链路生成的通信量，因此SAVI-DHCP不会为在其他网络中分配的地址设置绑定，并且无法验证它们。来自未受保护链路的流量应由中描述的未受保护设备或机制进行检查
[RFC2827]. The generation and deployment of such a mechanism is beyond the scope of this document.
[RFC2827]。这种机制的产生和部署超出了本文件的范围。
Traffic from protected links is, however, locally generated and should have its source addresses validated by SAVI-DHCP if possible. In the event that there is an intervening protected non-SAVI device between the host and the SAVI device, however, use of the physical attachment point alone as a binding anchor is insufficiently secure, as several devices on a port or other point of attachment can spoof each other. Hence, additional information such as a MAC address SHOULD be used to disambiguate them.
但是，来自受保护链路的流量是本地生成的，如果可能，应通过SAVI-DHCP验证其源地址。然而，在主机和SAVI设备之间存在中间受保护的非SAVI设备的情况下，仅使用物理连接点作为绑定锚是不够安全的，因为端口或其他连接点上的多个设备可以相互欺骗。因此，应该使用诸如MAC地址之类的附加信息来消除歧义。
As illustrated in Figure 1, a system attached to a SAVI device can be a DHCP client, a DHCP relay/server, a SAVI device, or a non-SAVI device. Different actions are performed on traffic originated from different elements. To distinguish among their requirements, several properties are associated with their point of attachment on the SAVI device.
如图1所示，连接到SAVI设备的系统可以是DHCP客户端、DHCP中继/服务器、SAVI设备或非SAVI设备。对来自不同元素的流量执行不同的操作。为了区分它们的要求，几个属性与它们在SAVI设备上的连接点相关联。
When a binding association is uninstantiated, e.g., when no host is attached to the SAVI device using a given port or other binding anchor, the binding port attributes take default values unless overridden by configuration. By default, a SAVI switch does not filter DHCP messages, nor does it attempt to validate source addresses, which is to say that the binding attributes are ignored until SAVI-DHCP is itself enabled. This is because a SAVI switch that depends on DHCP cannot tell, a priori, which ports have valid DHCP servers attached, or which have routers or other equipment that would validly appear to use an arbitrary set of source addresses. When SAVI has been enabled, the attributes take effect.
当绑定关联未实例化时，例如，当没有主机使用给定端口或其他绑定锚连接到SAVI设备时，绑定端口属性采用默认值，除非配置覆盖。默认情况下，SAVI交换机不会过滤DHCP消息，也不会尝试验证源地址，也就是说，在SAVI-DHCP自身启用之前，将忽略绑定属性。这是因为依赖于DHCP的SAVI交换机无法预先判断哪些端口连接了有效的DHCP服务器，或者哪些端口具有路由器或其他设备，这些设备将有效地使用任意一组源地址。启用SAVI后，属性生效。
The "Trust Attribute" is a Boolean value. If TRUE, it indicates that the packets from the corresponding attached device need not have their source addresses validated. Examples of a trusted attachment would be a port to another SAVI device, or to an IP router, as shown in Figure 1. In both cases, traffic using many source IP addresses will be seen. By default, the Trust attribute is FALSE, indicating that any device found on that port will seek an address using DHCP and be limited to using such addresses.
“信任属性”是一个布尔值。如果为TRUE，则表示来自相应连接设备的数据包不需要验证其源地址。可信附件的示例是另一个SAVI设备或IP路由器的端口，如图1所示。在这两种情况下，都会看到使用多个源IP地址的流量。默认情况下，Trust属性为FALSE，表示在该端口上找到的任何设备都将使用DHCP查找地址，并且仅限于使用此类地址。
SAVI devices will not set up bindings for points of attachment with the Trust attribute set TRUE; no packets, including DHCP messages, from devices with this attribute on their attachments will be validated. However, DHCP Server-to-Client messages will be snooped
SAVI设备不会为信任属性设置为TRUE的连接点设置绑定；不会验证来自附件上具有此属性的设备的数据包（包括DHCP消息）。但是，将监视DHCP服务器到客户端的消息
on attachment points with the Trust attribute set TRUE in the same way as if they had the DHCP-Trust attribute set (see Section 4.2.2).
在信任属性设置为TRUE的连接点上，其方式与设置DHCP信任属性的方式相同（参见第4.2.2节）。
The "DHCP-Trust Attribute" is similarly a Boolean attribute. It indicates whether the attached device is permitted to initiate DHCP Server-to-Client messages. In Figure 1, the points of attachment of the DHCP server and the DHCP relay would have this attribute set TRUE, and attachment points that have Trust set TRUE are implicitly treated as if DHCP-Trust is TRUE.
“DHCP信任属性”类似于布尔属性。它指示是否允许连接的设备启动DHCP服务器到客户端的消息。在图1中，DHCP服务器和DHCP中继的连接点将此属性设置为TRUE，并且将信任设置为TRUE的连接点隐式地视为DHCP信任为TRUE。
If the DHCP-Trust attribute is TRUE, SAVI devices will forward DHCP Server-to-Client messages from the points of attachment with this attribute. If the DHCP Server-to-Client messages can trigger the state transitions, the binding setup processes specified in Sections 6 and 7 will handle them. By default, the DHCP-Trust attribute is FALSE, indicating that the attached system is not a DHCP server.
如果DHCP信任属性为TRUE，SAVI设备将使用此属性从连接点向客户端转发DHCP服务器消息。如果DHCP服务器到客户端消息可以触发状态转换，则第6节和第7节中指定的绑定设置过程将处理这些状态转换。默认情况下，DHCP信任属性为FALSE，表示连接的系统不是DHCP服务器。
A DHCPv6 implementor can refer to [DHCPv6-SHIELD] for more details.
DHCPv6实现者可以参考[DHCPv6 SHIELD]了解更多详细信息。
The "DHCP-Snooping Attribute" is similarly a Boolean attribute. It indicates whether bindings will be set up based on DHCP snooping.
“DHCP窥探属性”类似于布尔属性。它指示是否将基于DHCP侦听设置绑定。
If this attribute is TRUE, DHCP Client-to-Server messages to points of attachment with this attribute will trigger creation of bindings based on the DHCP Snooping Process described in Section 6. If it is FALSE, either the Trust attribute must be TRUE (so that bindings become irrelevant) or another SAVI mechanism such as FCFS SAVI must be used on the point of attachment.
如果此属性为TRUE，则指向具有此属性的连接点的DHCP客户端到服务器消息将根据第6节中描述的DHCP侦听过程触发绑定的创建。如果为FALSE，则Trust属性必须为TRUE（以便绑定变得无关），或者必须在连接点上使用另一种SAVI机制，如FCFS SAVI。
The DHCP-Snooping attribute is configured on the DHCP client's point of attachment. This attribute can be also used on the attachments to protected non-SAVI devices that are used by DHCP clients. In Figure 1, the attachment from Client A to SAVI Device A, the attachment from Client B to SAVI Device B, and the attachment from Non-SAVI Device 2 to SAVI Device A can be configured with this attribute.
DHCP侦听属性在DHCP客户端的连接点上配置。此属性也可用于DHCP客户端使用的受保护非SAVI设备的附件。在图1中，可以使用此属性配置从客户端A到SAVI设备A的附件、从客户端B到SAVI设备B的附件以及从非SAVI设备2到SAVI设备A的附件。
The "Data-Snooping Attribute" is a Boolean attribute. It indicates whether data packets from the corresponding point of attachment may trigger the binding setup procedure.
“数据窥探属性”是一个布尔属性。它指示来自相应连接点的数据包是否会触发绑定设置过程。
Data packets from points of attachment with this attribute may trigger the setup of bindings. SAVI devices will set up bindings on points of attachment with this attribute based on the data-triggered process described in Section 7.
来自具有此属性的连接点的数据包可能会触发绑定设置。SAVI设备将根据第7节中描述的数据触发过程，在具有此属性的连接点上设置绑定。
If the DHCP-Snooping attribute is configured on a point of attachment, the bindings on this attachment are set up based on DHCP message snooping. However, in some scenarios, a DHCP client may use a DHCP address without the DHCP address assignment procedure being performed on its current attachment. For such attached devices, the Data Snooping Process, which is described in Section 7, is necessary. This attribute is configured on such attachments. The usage of this attribute is further discussed in Section 7.
如果在附件点上配置了DHCP侦听属性，则此附件上的绑定将基于DHCP消息侦听进行设置。但是，在某些情况下，DHCP客户端可能会使用DHCP地址，而不会对其当前附件执行DHCP地址分配过程。对于此类连接设备，第7节中描述的数据窥探过程是必要的。此属性是在此类附件上配置的。第7节将进一步讨论此属性的用法。
Since some networks require DHCP deployment and others avoid it, there is no obvious universal default value for the Data-Snooping attribute. Hence, the Data-Snooping attribute should default to FALSE, and a mechanism should be implemented to conveniently set it to TRUE on all points of attachment for which the Trust attribute is FALSE.
由于某些网络需要部署DHCP，而其他网络则避免部署DHCP，因此数据窥探属性没有明显的通用默认值。因此，数据窥探属性应该默认为FALSE，并且应该实现一种机制，以便在信任属性为FALSE的所有连接点上将其方便地设置为TRUE。
The "Validating Attribute" is a Boolean attribute. It indicates whether packets from the corresponding attachment will have their IP source addresses validated based on binding entries on the attachment.
“验证属性”是一个布尔属性。它指示来自相应附件的数据包是否将根据附件上的绑定条目验证其IP源地址。
If it is TRUE, packets coming from attachments with this attribute will be validated based on binding entries on the attachment as specified in Section 8. If it is FALSE, they will not. Since the binding table is used in common with other SAVI algorithms, it merely signifies whether the check will be done, not whether it will be done for SAVI-DHCP originated bindings.
如果为TRUE，则将根据第8节中指定的附件上的绑定条目验证来自具有此属性的附件的数据包。如果这是错误的，他们不会。由于绑定表与其他SAVI算法共同使用，因此它仅表示是否将执行检查，而不是是否将对源自SAVI-DHCP的绑定执行检查。
This attribute is by default the inverse of the Trust attribute; source addresses on untrusted links are validated by default. It MAY be set FALSE by the administration.
默认情况下，该属性与信任属性相反；默认情况下，验证不受信任链接上的源地址。政府当局可能会将其设定为虚假。
The expected use case is when SAVI is used to monitor but not block forged transmissions. The network manager, in that case, may set the DHCP-Snooping and/or Data-Snooping attribute TRUE but the Validating attribute FALSE.
预期的使用情况是SAVI用于监控但不阻止伪造的传输。在这种情况下，网络管理器可以将DHCP侦听和/或数据侦听属性设置为TRUE，但验证属性设置为FALSE。
Different types of attributes may indicate mutually exclusive actions on a packet. Mutually exclusive attributes MUST NOT be set TRUE on the same attachment. The compatibility of different attributes is listed in Figure 2. Note that although Trust and DHCP-Trust are compatible, there is no need to configure DHCP-Trust to TRUE on an attachment with Trust attribute TRUE.
不同类型的属性可指示数据包上的互斥操作。不能在同一附件上将互斥属性设置为TRUE。不同属性的兼容性如图2所示。请注意，尽管信任和DHCP信任是兼容的，但对于具有信任属性TRUE的附件，不需要将DHCP信任配置为TRUE。
+----------+----------+----------+----------+----------+----------+
| | | | DHCP- | Data- | |
| | Trust |DHCP-Trust| Snooping | Snooping |Validating|
+----------+----------+----------+----------+----------+----------+
| | | | mutually | mutually | mutually |
| Trust | - |compatible| exclusive| exclusive| exclusive|
+----------+----------+----------+----------+----------+----------+
| | | | | | |
|DHCP-Trust|compatible| - |compatible|compatible|compatible|
+----------+----------+----------+----------+----------+----------+
|DHCP- |mutually | | | | |
|Snooping |exclusive |compatible| - |compatible|compatible|
+----------+----------+----------+----------+----------+----------+
|Data- |mutually | | | | |
|Snooping |exclusive |compatible|compatible| - |compatible|
+----------+----------+----------+----------+----------+----------+
| |mutually | | | | |
|Validating|exclusive |compatible|compatible|compatible| - |
+----------+----------+----------+----------+----------+----------+
+----------+----------+----------+----------+----------+----------+
| | | | DHCP- | Data- | |
| | Trust |DHCP-Trust| Snooping | Snooping |Validating|
+----------+----------+----------+----------+----------+----------+
| | | | mutually | mutually | mutually |
| Trust | - |compatible| exclusive| exclusive| exclusive|
+----------+----------+----------+----------+----------+----------+
| | | | | | |
|DHCP-Trust|compatible| - |compatible|compatible|compatible|
+----------+----------+----------+----------+----------+----------+
|DHCP- |mutually | | | | |
|Snooping |exclusive |compatible| - |compatible|compatible|
+----------+----------+----------+----------+----------+----------+
|Data- |mutually | | | | |
|Snooping |exclusive |compatible|compatible| - |compatible|
+----------+----------+----------+----------+----------+----------+
| |mutually | | | | |
|Validating|exclusive |compatible|compatible|compatible| - |
+----------+----------+----------+----------+----------+----------+
Figure 2: Table of Mutual Exclusions
图2：相互排除表
SAVI devices form a perimeter separating trusted and untrusted regions of a network, as FCFS SAVI does (Section 2.5 of [RFC6620]). The perimeter is primarily designed for scalability. It has two implications.
与FCFS SAVI一样，（RFC6620）第2.5节），SAVI设备形成了一个周界，将网络的受信任区域和不受信任区域分开。周界主要是为可扩展性而设计的。它有两个含义。
o SAVI devices only need to establish bindings for directly attached clients, or clients indirectly attached through a non-SAVI protected device, rather than all of the clients in the network.
o SAVI设备只需要为直接连接的客户端或通过非SAVI保护设备间接连接的客户端建立绑定，而不需要为网络中的所有客户端建立绑定。
o Each SAVI device only needs to validate the source addresses in traffic from clients attached to it, without checking all the traffic passing by.
o 每个SAVI设备只需要验证连接到它的客户端的流量中的源地址，而不检查经过的所有流量。
Consider the example in Figure 1. The protection perimeter is formed by SAVI Devices A, B, and C. In this case, SAVI Device B does not create a binding for Client A. However, because SAVI Device A filters spoofed traffic from Client A, SAVI Device B can avoid receiving spoofed traffic from Client A.
考虑图1中的示例。保护周界由SAVI设备A、B和C构成。在这种情况下，SAVI设备B不会为客户端A创建绑定。但是，由于SAVI设备A过滤来自客户端A的伪造流量，因此SAVI设备B可以避免接收来自客户端A的伪造流量。
The perimeter in SAVI-DHCP is not only a perimeter for data packets but also a perimeter for DHCP messages. DHCP server response messages incoming across the perimeter will be dropped (Section 8). The placement of the DHCP relay and DHCP server, which are not involved in [RFC6620], is related to the construction of the perimeter. The requirement on the placement and configuration of the DHCP relay and DHCP server is discussed in Section 4.3.3.
SAVI-DHCP中的周界不仅是数据包的周界，也是DHCP消息的周界。将丢弃通过外围传入的DHCP服务器响应消息（第8节）。[RFC6620]中未涉及的DHCP中继和DHCP服务器的位置与周界的构造有关。第4.3.3节讨论了DHCP中继和DHCP服务器的放置和配置要求。
A perimeter separating trusted and untrusted regions of the network is formed as follows:
将网络的受信任区域和不受信任区域分开的周界如下所示：
(1) Configure the Validating and DHCP-Snooping attributes TRUE on the direct attachments of all DHCP clients.
(1) 在所有DHCP客户端的直接附件上配置验证和DHCP侦听属性TRUE。
(2) Configure the Validating and DHCP-Snooping attributes TRUE on the indirect attachments of all DHCP clients (i.e., DHCP clients on protected links).
(2) 在所有DHCP客户端（即受保护链路上的DHCP客户端）的间接附件上配置验证和DHCP侦听属性TRUE。
(3) Configure the Trust attribute TRUE on the attachments to other SAVI devices.
(3) 在其他SAVI设备的附件上配置Trust属性TRUE。
(4) If a non-SAVI device, or a number of connected non-SAVI devices, are attached only to SAVI devices, set the Trust attribute TRUE on their attachments.
(4) 如果一个非SAVI设备或多个已连接的非SAVI设备仅连接到SAVI设备，请将其附件上的信任属性设置为TRUE。
(5) Configure the DHCP-Trust attribute TRUE on the direct attachments to trusted DHCP relays and servers.
(5) 在受信任的DHCP中继和服务器的直接附件上配置DHCP信任属性TRUE。
In this way, the points of attachments with the Validating attribute TRUE (and generally together with attachments of unprotected devices) on SAVI devices can form a perimeter separating DHCP clients and trusted devices. Data packet checks are only performed on the perimeter. The perimeter is also a perimeter for DHCP messages. The DHCP-Trust attribute is only TRUE on links inside the perimeter. Only DHCP Server-to-Client messages originated within the perimeter are trusted.
这样，SAVI设备上具有验证属性TRUE的附件点（通常与未受保护设备的附件一起）可以形成一个周界，将DHCP客户端和受信任设备分隔开来。数据包检查仅在外围执行。周界也是DHCP消息的周界。DHCP信任属性仅在周界内的链接上为真。仅信任周界内发起的DHCP服务器到客户端消息。
As a result of the configuration guidelines, SAVI devices only trust DHCP Server-to-Client messages originated inside the perimeter. Thus, the trusted DHCP relays and DHCP servers must be placed within the perimeter. DHCP Server-to-Client messages will be filtered on the perimeter. Server-to-Relay messages will not be filtered, as they are within the perimeter. In this way, DHCP Server-to-Client messages from bogus DHCP servers are filtered on the perimeter, having entered through untrusted points of attachment. The SAVI devices are protected from forged DHCP messages.
根据配置指导原则，SAVI设备仅将DHCP服务器信任给源自周边的客户端消息。因此，受信任的DHCP中继和DHCP服务器必须放置在外围内。DHCP服务器到客户端的消息将在外围进行筛选。服务器到中继消息不会被筛选，因为它们位于外围范围内。通过这种方式，来自伪造DHCP服务器的DHCP服务器到客户端消息在外围进行过滤，通过不受信任的连接点输入。SAVI设备受伪造DHCP消息的保护。
DHCP Server-to-Client messages arriving at the perimeter from outside the perimeter are not trusted. There is no distinction between a DHCP server owned and operated by the correct administration but outside the SAVI perimeter and a bogus DHCP server. For example, in Figure 1, DHCP Server A is valid, but it is attached to Non-SAVI Device 1. A bogus DHCP server is also attached to Non-SAVI Device 1. While one could imagine a scenario in which the valid one had a statistically configured port number and MAC address, and therefore a binding, by default SAVI-DHCP cannot distinguish whether a message received from the port of Non-SAVI Device 1 is from DHCP Server A or the bogus DHCP server. If DHCP Server A is contained in the perimeter, Non-SAVI Device 1 will also be contained in the perimeter. Thus, DHCP Server A cannot be contained within the perimeter apart from manual configuration of the binding anchor.
从外围设备外部到达外围设备的DHCP服务器到客户端消息不受信任。由正确的管理部门拥有和操作但在SAVI外围之外的DHCP服务器与伪造的DHCP服务器之间没有区别。例如，在图1中，DHCP服务器A是有效的，但它连接到非SAVI设备1。伪DHCP服务器也连接到非SAVI设备1。虽然可以想象一种场景，其中有效的具有统计配置的端口号和MAC地址，因此具有绑定，但默认情况下，SAVI-DHCP无法区分从非SAVI设备1的端口接收的消息是来自DHCP服务器a还是来自伪造的DHCP服务器。如果DHCP服务器A包含在外围中，则非SAVI设备1也将包含在外围中。因此，除了手动配置绑定锚之外，DHCP服务器A不能包含在外围中。
Another consideration on the placement is that if the DHCP server/ relay is not inside the perimeter, the SAVI devices may not be able to set up bindings correctly because the SAVI devices may not be on the path between the clients and the server/relay, or the DHCP messages are encapsulated (e.g., Relay-reply and Relay-forward).
关于放置的另一个考虑因素是，如果DHCP服务器/中继不在周界内，则SAVI设备可能无法正确设置绑定，因为SAVI设备可能不在客户端和服务器/中继之间的路径上，或者DHCP消息被封装（例如，中继回复和中继转发）。
In common deployment practice, the traffic from the unprotected network is treated as trustworthy, which is to say that it is not filtered. In such a case, the Trust attribute can be set TRUE on the unprotected link. If non-SAVI devices, or a number of connected non-SAVI devices, are only attached to SAVI devices and unprotected devices, their attachment to SAVI devices can have the Trust attribute set TRUE. Then an unclosed perimeter will be formed, as illustrated in Figure 3.
在通常的部署实践中，来自未受保护的网络的流量被视为可信的，也就是说，它没有被过滤。在这种情况下，可以在未受保护的链接上将Trust属性设置为TRUE。如果非SAVI设备或许多已连接的非SAVI设备仅连接到SAVI设备和未受保护的设备，则它们与SAVI设备的连接可以将Trust属性设置为TRUE。然后将形成一个未闭合的周界，如图3所示。
| . . Protection |
| | | Perimeter |
| | | |
| Unprotected | | Unprotected |
| Link | | Link |
| | | |
| | | |
| +----+---+ +----+---+ +--------+ |
| |SAVI +----+Non-SAVI+----+SAVI | |
| |Device | |Device | |Device | |
| +----+---+ +--------+ +----+---+ |
| | | |
\_____________+___________________________+________/
| |
| |
+--------+ +--------+
|DHCP | |DHCP |
|Client | |Client |
+--------+ +--------+
| . . Protection |
| | | Perimeter |
| | | |
| Unprotected | | Unprotected |
| Link | | Link |
| | | |
| | | |
| +----+---+ +----+---+ +--------+ |
| |SAVI +----+Non-SAVI+----+SAVI | |
| |Device | |Device | |Device | |
| +----+---+ +--------+ +----+---+ |
| | | |
\_____________+___________________________+________/
| |
| |
+--------+ +--------+
|DHCP | |DHCP |
|Client | |Client |
+--------+ +--------+
Figure 3: Alternative Perimeter Configuration
图3：备选周界配置
The strength of this binding-based mechanism depends on the strength of the binding anchor. The sample binding anchors in [RFC7039] have the property in which they associate an IP address with a direct physical or secure virtual interface such as a switch port, a subscriber association, or a security association. In addition, especially in the case where a protected non-SAVI device such as a desktop switch or a hub is between the client and SAVI devices, they MAY be extended to also include a MAC address or other link-layer attribute. In short, a binding anchor is intended to associate an IP address with something unspoofable that identifies a single-client system or one of its interfaces; this may be a physical or virtual interface or that plus disambiguating link-layer information.
这种基于绑定的机制的强度取决于绑定锚的强度。[RFC7039]中的示例绑定锚具有将IP地址与直接物理或安全虚拟接口（如交换机端口、订户关联或安全关联）关联的属性。此外，特别是在诸如桌面交换机或集线器之类的受保护的非SAVI设备位于客户端和SAVI设备之间的情况下，它们可以被扩展以还包括MAC地址或其他链路层属性。简言之，绑定锚旨在将IP地址与标识单个客户端系统或其接口之一的不可预测的内容相关联；这可能是一个物理或虚拟接口，或者加上消除歧义的链路层信息。
If the binding anchor is spoofable, such as a plain MAC address, or non-exclusive, such as a switch port extended using a non-SAVI device, an attacker can use a forged binding anchor to evade validation. Indeed, using a binding anchor that can be easily spoofed can lead to worse outcomes than allowing spoofed IP traffic. Thus, a SAVI device MUST use a non-spoofable and exclusive binding anchor.
如果绑定锚是伪造的（如普通MAC地址），或非独占的（如使用非SAVI设备扩展的交换机端口），则攻击者可以使用伪造的绑定锚来逃避验证。事实上，使用易于欺骗的绑定锚可能会导致比允许欺骗IP流量更糟糕的结果。因此，SAVI设备必须使用非欺骗和独占绑定锚。
In addition to a possible binding anchor configuration specified in Section 4.2, an implementation has the following configuration requirements:
除了第4.2节中规定的可能的绑定锚配置外，实施还具有以下配置要求：
(1) Address configuration. For DHCPv4: the SAVI device MUST have an IPv4 address. For DHCPv6: the client of a SAVI device MUST have a link-local address; when the DHCPv6 server is not on the same link as the SAVI device, the SAVI device MUST also have an IPv6 address of at least the same scope as the DHCPv6 Server.
(1) 地址配置。对于DHCPv4：SAVI设备必须具有IPv4地址。对于DHCPv6：SAVI设备的客户端必须具有链路本地地址；当DHCPv6服务器与SAVI设备不在同一链路上时，SAVI设备的IPv6地址必须至少与DHCPv6服务器的作用域相同。
(2) DHCP server address configuration: a SAVI device MUST store the list of the DHCP server addresses that it could contact during a leasequery process.
(2) DHCP服务器地址配置：SAVI设备必须存储在租赁过程中可以联系的DHCP服务器地址列表。
(3) A SAVI device may also require security parameters, such as preconfigured keys to establish a secure connection for the leasequery process [RFC4388] [RFC5007] connection.
(3) SAVI设备还可能需要安全参数，例如预配置的密钥，以便为租赁过程[RFC4388][RFC5007]连接建立安全连接。
The Binding State Table, which may be implemented centrally in the switch or distributed among its ports, is used to contain the bindings between the IP addresses assigned to the attachments and the corresponding binding anchors of the attachments. Note that in this description, there is a binding entry for each IPv4 or IPv6 address associated with each binding anchor, and there may be several of each such address, especially if the port is extended using a protected non-SAVI device. Each binding entry has six fields:
绑定状态表可在交换机中集中实现或分布在其端口之间，用于包含分配给附件的IP地址与附件的相应绑定锚之间的绑定。请注意，在本说明中，与每个绑定锚关联的每个IPv4或IPv6地址都有一个绑定条目，并且每个此类地址中可能有多个，尤其是在使用受保护的非SAVI设备扩展端口的情况下。每个绑定条目有六个字段：
o Binding Anchor (listed as "Anchor" in subsequent figures): the binding anchor, i.e., one or more physical and/or link-layer properties of the attachment.
o 绑定锚（在后续图中列为“锚”）：绑定锚，即附件的一个或多个物理和/或链接层属性。
o IP Address (listed as "Address" in subsequent figures): the IPv4 or IPv6 address assigned to the attachment by DHCP.
o IP地址（在后面的图中列为“地址”）：DHCP分配给附件的IPv4或IPv6地址。
o State: the state of the binding. Possible values of this field are listed in Sections 6.2 and 7.3.
o 状态：绑定的状态。第6.2节和第7.3节列出了该字段的可能值。
o Lifetime: the remaining seconds of the binding. Internally, this MAY be stored as the timestamp value at which the lifetime expires.
o 生存期：绑定的剩余秒数。在内部，这可以存储为生存期到期时的时间戳值。
o Transaction ID (TID): the Transaction ID [RFC2131] [RFC3315] of the corresponding DHCP transaction. The TID field is used to
o 事务ID（TID）：对应DHCP事务的事务ID[RFC2131][RFC3315]。TID字段用于
associate DHCP Server-to-Client messages with corresponding binding entries.
将DHCP服务器与客户端消息与相应的绑定项相关联。
o Timeouts: the number of timeouts that expired in the current state (only used in the Data Snooping Process; see Section 7).
o 超时：在当前状态下过期的超时数（仅用于数据监听过程；请参阅第7节）。
The IA is not present in the BST for three reasons:
IA不在BST中，原因有三：
o The lease of each address in one IA is assigned separately.
o 一个IA中每个地址的租约都是单独分配的。
o When the binding is set up based on data snooping, the IA cannot be recovered from the leasequery protocol.
o 基于数据窥探设置绑定时，IA无法从leasequery协议恢复。
o DHCPv4 does not define an IA.
o DHCPv4未定义IA。
An example of such a table is shown in Figure 4.
图4显示了这样一个表的示例。
+---------+----------+-----------+-----------+--------+----------+
| Anchor | Address | State | Lifetime | TID | Timeouts |
+---------+----------+-----------+-----------+--------+----------+
| Port_1 | IP_1 | BOUND | 65535 | TID_1 | 0 |
+---------+----------+-----------+-----------+--------+----------+
| Port_1 | IP_2 | BOUND | 10000 | TID_2 | 0 |
+---------+----------+-----------+-----------+--------+----------+
| Port_2 | IP_3 | INIT_BIND | 1 | TID_3 | 0 |
+---------+----------+-----------+-----------+--------+----------+
+---------+----------+-----------+-----------+--------+----------+
| Anchor | Address | State | Lifetime | TID | Timeouts |
+---------+----------+-----------+-----------+--------+----------+
| Port_1 | IP_1 | BOUND | 65535 | TID_1 | 0 |
+---------+----------+-----------+-----------+--------+----------+
| Port_1 | IP_2 | BOUND | 10000 | TID_2 | 0 |
+---------+----------+-----------+-----------+--------+----------+
| Port_2 | IP_3 | INIT_BIND | 1 | TID_3 | 0 |
+---------+----------+-----------+-----------+--------+----------+
Figure 4: Example Binding State Table
图4：绑定状态表示例
This section specifies the process of setting up bindings based on DHCP snooping. This process is illustrated using a state machine.
本节指定基于DHCP侦听设置绑定的过程。这个过程用状态机来说明。
The rationale of the DHCP Snooping Process is that if a DHCP client is legitimately using a DHCP-assigned address, the DHCP address assignment procedure that assigns the IP address to the client must have been performed via the client's point of attachment. This assumption works when the SAVI device is always on the path(s) from the DHCP client to the DHCP server(s)/relay(s). Without considering the movement of DHCP clients, the SAVI device should be the cut vertex whose removal will separate the DHCP client and the remaining network containing the DHCP server(s)/relay(s). For most of the networks whose topologies are simple, it is possible to deploy this SAVI function at proper devices to meet this requirement.
DHCP窥探过程的基本原理是，如果DHCP客户端合法使用DHCP分配的地址，则必须通过客户端的连接点执行将IP地址分配给客户端的DHCP地址分配过程。当SAVI设备始终位于从DHCP客户端到DHCP服务器/中继的路径上时，此假设有效。在不考虑DHCP客户端移动的情况下，SAVI设备应为切割顶点，其移除将分离DHCP客户端和包含DHCP服务器/中继的剩余网络。对于大多数拓扑结构简单的网络，可以在适当的设备上部署此SAVI功能以满足此要求。
However, if there are multiple paths from a DHCP client to the DHCP server and the SAVI device is only on one of them, there is an obvious failure case: the SAVI device may not be able to snoop the DHCP procedure. Host movement may also make this requirement difficult to meet. For example, when a DHCP client moves from one attachment to another attachment in the same network, it may fail to reinitialize its interface or send a Confirm message because of incomplete protocol implementation. Thus, there can be scenarios in which only performing this DHCP Snooping Process is insufficient to set up bindings for all the valid DHCP addresses. These exceptions and the solutions are discussed in Section 7.
但是，如果存在从DHCP客户端到DHCP服务器的多条路径，并且SAVI设备仅位于其中一条路径上，则存在明显的故障情况：SAVI设备可能无法窥探DHCP过程。主机移动也可能使此要求难以满足。例如，当DHCP客户端在同一网络中从一个附件移动到另一个附件时，由于协议实现不完整，它可能无法重新初始化其接口或发送确认消息。因此，在某些情况下，仅执行此DHCP侦听过程不足以为所有有效的DHCP地址设置绑定。第7节讨论了这些例外情况和解决方案。
The following binding states are present in this process and the corresponding state machine:
此进程和相应的状态机中存在以下绑定状态：
NO_BIND: No binding has been set up.
无绑定：未设置任何绑定。
INIT_BIND: A potential binding has been set up.
INIT_BIND：已经设置了一个潜在的绑定。
BOUND: The binding has been set up.
绑定：已设置绑定。
This section describes events in this process and the corresponding state machine transitions. The DHCP message categories (e.g., DHCPv4 Discover) defined in Section 3 are used extensively in the definitions of events and elsewhere in the state machine definition. If an event will trigger the creation of a new binding entry, the binding entry limit on the binding anchor MUST NOT be exceeded.
本节描述此过程中的事件以及相应的状态机转换。第3节中定义的DHCP消息类别（如DHCPv4 Discover）广泛用于事件定义和状态机定义的其他地方。如果事件将触发新绑定项的创建，则不得超过绑定锚上的绑定项限制。
EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires.
EVE\u ENTRY\u EXPIRE：绑定项的生存期到期。
EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is received.
EVE_DHCP_请求：收到DHCPv4请求或DHCPv6请求消息。
EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received.
EVE_DHCP_确认：收到DHCPv6确认消息。
EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received.
EVE\u DHCP\u重新启动：收到DHCPv4重新启动消息。
EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received.
EVE_DHCP_重新绑定：收到DHCPv4重新绑定或DHCPv6重新绑定消息。
EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received.
EVE_DHCP_续订：收到DHCPv4续订或DHCPv6续订消息。
EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid Commit option is received.
EVE_DHCP_request_RC：接收到带有快速提交选项的DHCPv6请求消息。
EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received.
EVE_DHCP_回复：收到DHCPv4 ACK或DHCPv6回复消息。
EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is received.
EVE_DHCP_拒绝：收到DHCPv4拒绝或DHCPv6拒绝消息。
EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is received.
EVE_DHCP_发布：收到DHCPv4发布或DHCPv6发布消息。
EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY (refer to Section 4.3.3 of [RFC5007]) is received.
EVE_DHCP_租赁：收到成功的DHCPv6租赁回复（参考[RFC5007]第4.3.3节）。
Note: the events listed here do not cover all the DHCP messages in Section 3. The messages that do not really determine address usage (DHCPv4 Discover, DHCPv4 Inform, DHCPv6 Solicit without Rapid Commit, DHCPv6 Information-Request, DHCPv4 Offer, DHCPv6 Advertise, and DHCPv6 Reconfigure) and that are not necessary to snoop (DHCPv4 Negative Acknowledgment (NAK); refer to Section 6.4.2.3) are not included. Note also that DHCPv4 DHCPLEASEQUERY is not used in the DHCP Snooping Process to avoid confusion with Section 7. Also, since the LEASEQUERY should have been originated by the SAVI device itself, the destination check should verify that the message is directed to this SAVI device, and it should not be forwarded once it has been processed here.
注意：此处列出的事件不包括第3节中的所有DHCP消息。不包括不能真正确定地址使用情况的消息（DHCPv4 Discover、DHCPv4 Inform、DHCPv6 Request without Rapid Commit、DHCPv6 Information Request、DHCPv4 Offer、DHCPv6 advertive和DHCPv6 configuration）以及不需要窥探的消息（DHCPv4否定确认（NAK）；参考第6.4.2.3节）。还要注意的是，DHCPv4 DHCPLEASEQUERY未在DHCP侦听过程中使用，以避免与第7节混淆。此外，由于LEASEQUERY应该是由SAVI设备本身发起的，因此目的地检查应该验证消息是否定向到此SAVI设备，并且在此处处理后不应转发消息。
Moreover, only if a DHCP message can pass the following checks, the corresponding event is regarded as a valid event:
此外，仅当DHCP消息可以通过以下检查时，相应的事件才被视为有效事件：
o Attribute check: the DHCP Server-to-Client messages and LEASEQUERY-REPLY should be from attachments with the DHCP-Trust attribute; the DHCP Client-to-Server messages should be from attachments with the DHCP-Snooping attribute.
o 属性检查：DHCP服务器到客户端的消息和LEASEQUERY-REPLY应该来自具有DHCP信任属性的附件；DHCP客户端到服务器的消息应来自具有DHCP侦听属性的附件。
o Destination check: the DHCP Server-to-Client messages should be destined to attachments with the DHCP-Snooping attribute. This check is performed to ensure the binding is set up on the SAVI device that is nearest to the destination client.
o 目标检查：DHCP服务器到客户端消息应发送到具有DHCP侦听属性的附件。执行此检查以确保在距离目标客户端最近的SAVI设备上设置绑定。
o Binding anchor check: the DHCP Client-to-Server messages that may trigger modification or removal of an existing binding entry must have a matching binding anchor with the corresponding entry.
o 绑定锚检查：可能触发修改或删除现有绑定条目的DHCP客户端到服务器消息必须具有与相应条目匹配的绑定锚。
o TID check: the DHCP Server-to-Client/Client-to-Server messages that may cause modification of existing binding entries must have a matched TID with the corresponding entry. Note that this check is not performed on LEASEQUERY and LEASEQUERY-REPLY messages as they are exchanged between the SAVI devices and the DHCP servers. Besides, this check is not performed on DHCP Renew/Rebind messages.
o TID检查：可能导致修改现有绑定项的DHCP服务器到客户端/客户端到服务器消息必须具有与相应项匹配的TID。请注意，由于LEASEQUERY和LEASEQUERY-REPLY消息在SAVI设备和DHCP服务器之间交换，因此不会对它们执行此检查。此外，不会对DHCP续订/重新绑定消息执行此检查。
o Binding limitation check: the DHCP messages must not cause new binding setup on an attachment whose binding entry limitation has been reached (refer to Section 11.5).
o 绑定限制检查：DHCP消息不得在已达到绑定条目限制的附件上导致新的绑定设置（请参阅第11.5节）。
o Address check: the source address of the DHCP messages should pass the check specified in Section 8.2.
o 地址检查：DHCP消息的源地址应通过第8.2节规定的检查。
On receiving a DHCP message without triggering a valid event, the state will not change, and the actions will not be performed. Note that if a message does not trigger a valid event but it can pass the checks in Section 8.2, it MUST be forwarded.
在未触发有效事件的情况下接收DHCP消息时，状态不会更改，并且不会执行操作。请注意，如果消息未触发有效事件，但可以通过第8.2节中的检查，则必须转发该消息。
This section specifies state transitions and their corresponding actions.
本节指定状态转换及其相应的操作。
6.4.1.1. Event: EVE_DHCP_REQUEST - A DHCPv4 Request or a DHCPv6 Request message is received
6.4.1.1. 事件：EVE_DHCP_请求-收到DHCPv4请求或DHCPv6请求消息
The SAVI device MUST forward the message.
SAVI设备必须转发消息。
The SAVI device will generate an entry in the BST. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. If the message is DHCPv4 Request, the Address field can be set to the address to request, i.e., the 'requested IP address'. An example of the entry is illustrated in Figure 5.
SAVI设备将在BST中生成一个条目。绑定锚字段设置为接收消息的附件的绑定锚。状态字段设置为INIT_BIND。寿命字段设置为最大DHCP响应时间。TID字段设置为消息的TID。如果消息是DHCPv4请求，则可以将地址字段设置为要请求的地址，即“请求的IP地址”。该条目的示例如图5所示。
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+--------+-------+---------+-----------------------+-----+----------+
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+--------+-------+---------+-----------------------+-----+----------+
Figure 5: Binding Entry in BST on Initialization Triggered by Request/Rapid Commit/Reboot Messages
图5：请求/快速提交/重新启动消息触发初始化时BST中的绑定项
Resulting state: INIT_BIND - A potential binding has been set up.
结果状态：INIT_BIND-已设置潜在绑定。
The SAVI device MUST forward the message.
SAVI设备必须转发消息。
The SAVI device will generate an entry in the BST. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. If the message is DHCPv4 Reboot, the Address field can be set to the address to request, i.e., the 'requested IP address'. An example of the entry is illustrated in Figure 5.
SAVI设备将在BST中生成一个条目。绑定锚字段设置为接收消息的附件的绑定锚。状态字段设置为INIT_BIND。寿命字段设置为最大DHCP响应时间。TID字段设置为消息的TID。如果消息为DHCPv4 Reboot，则可以将地址字段设置为要请求的地址，即“请求的IP地址”。该条目的示例如图5所示。
Resulting state: INIT_BIND - A potential binding has been set up.
结果状态：INIT_BIND-已设置潜在绑定。
6.4.1.3. Event: EVE_DHCP_SOLICIT_RC - A DHCPv6 Solicitation message with the Rapid Commit option is received
6.4.1.3. 事件：EVE_DHCP_request_RC-收到带有快速提交选项的DHCPv6请求消息
The SAVI device MUST forward the message.
SAVI设备必须转发消息。
The SAVI device will generate an entry in the BST. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. An example of the entry is illustrated in Figure 5.
SAVI设备将在BST中生成一个条目。绑定锚字段设置为接收消息的附件的绑定锚。状态字段设置为INIT_BIND。寿命字段设置为最大DHCP响应时间。TID字段设置为消息的TID。该条目的示例如图5所示。
Resulting state: INIT_BIND - A potential binding has been set up.
结果状态：INIT_BIND-已设置潜在绑定。
The SAVI device MUST forward the message.
SAVI设备必须转发消息。
The SAVI device will generate corresponding entries in the BST for each address in each Identity Association (IA) option of the Confirm message. The Binding Anchor field is set to the binding anchor of the attachment from which the message is received. The State field
SAVI设备将在BST中为确认消息的每个身份关联（IA）选项中的每个地址生成相应的条目。Binding Anchor字段设置为从中接收消息的附件的绑定锚。州域
is set to INIT_BIND. The Lifetime field is set to be MAX_DHCP_RESPONSE_TIME. The TID field is set to the TID of the message. The Address field is set to the address(es) to confirm. An example of the entries is illustrated in Figure 6.
设置为INIT_BIND。寿命字段设置为最大DHCP响应时间。TID字段设置为消息的TID。地址字段设置为要确认的地址。图6显示了一个条目示例。
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+--------+-------+---------+-----------------------+-----+----------+
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr1 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr2 |INIT_BIND|MAX_DHCP_RESPONSE_TIME | TID | 0 |
+--------+-------+---------+-----------------------+-----+----------+
Figure 6: Binding Entry in BST on Confirm-Triggered Initialization
图6：确认触发初始化时BST中的绑定条目
Resulting state: INIT_BIND - A potential binding has been set up.
结果状态：INIT_BIND-已设置潜在绑定。
o EVE_ENTRY_EXPIRE: The lifetime of a binding entry expires
o EVE\u ENTRY\u EXPIRE：绑定项的生存期到期
o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received
o EVE_DHCP_重新绑定：收到DHCPv4重新绑定或DHCPv6重新绑定消息
o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received
o EVE_DHCP_续订：收到DHCPv4续订或DHCPv6续订消息
o EVE_DHCP_REPLY: A DHCPv4 ACK or a DHCPv6 Reply message is received
o EVE_DHCP_回复：收到DHCPv4 ACK或DHCPv6回复消息
o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is received
o EVE_DHCP_拒绝：收到DHCPv4拒绝或DHCPv6拒绝消息
o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is received
o EVE_DHCP_发布：收到DHCPv4发布或DHCPv6发布消息
o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is received
o EVE_DHCP_租赁：收到成功的DHCPv6租赁回复
These cannot happen because they are each something that happens AFTER a binding has been created.
这些不可能发生，因为它们都是在创建绑定后发生的。
6.4.2.1. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message is received
6.4.2.1. 事件：EVE_DHCP_应答-收到DHCPv4 ACK或DHCPv6应答消息
The message MUST be forwarded to the corresponding client.
消息必须转发到相应的客户端。
If the message is DHCPv4 ACK, the Address field of the corresponding entry (i.e., the binding entry whose TID is the same as the message) is set to the address in the message (i.e., 'yiaddr' in DHCPv4 ACK). The Lifetime field is set to the sum of the lease time in the ACK message and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND.
如果消息是DHCPv4 ACK，则相应条目（即TID与消息相同的绑定条目）的地址字段设置为消息中的地址（即DHCPv4 ACK中的“yiaddr”）。“生存期”字段设置为ACK消息中的租用时间和最大DHCP响应时间之和。状态字段更改为绑定。
If the message is DHCPv6 Reply, note the following cases:
如果消息为DHCPv6 Reply，请注意以下情况：
1. If the status code is not "Success", no modification of corresponding entries will be made. Corresponding entries will expire automatically if no "Success" Reply is received during the lifetime. The entries are not removed immediately because the client may be able to use the addresses whenever a "Success" Reply is received ("If the client receives any Reply messages that do not indicate a NotOnLink status, the client can use the addresses in the IA and ignore any messages that indicate a NotOnLink status" [RFC3315]).
1. 如果状态代码不是“成功”，则不会修改相应的条目。如果在生存期内未收到“成功”回复，则相应条目将自动过期。不会立即删除这些条目，因为每当收到“成功”回复时，客户机可能能够使用这些地址（“如果客户机收到任何不指示NotOnLink状态的回复消息，则客户机可以使用IA中的地址并忽略任何指示NotOnLink状态的消息”[RFC3315]）。
2. If the status code is "Success", the SAVI device checks the IA options in the Reply message.
2. 如果状态代码为“成功”，SAVI设备将检查回复消息中的IA选项。
A. If there are IA options in the Reply message, the SAVI device checks each IA option. When the first assigned address is found, the Address field of the binding entry with a matched TID is set to the address. The Lifetime field is set to the sum of the lease time in the Reply message and MAX_DHCP_RESPONSE_TIME. The State field is changed to BOUND. If there is more than one address assigned in the message, new binding entries are set up for the remaining address assigned in the IA options. An example of the entries is illustrated in Figure 8. SAVI devices do not specially process IA options with a NoAddrsAvail status because there should be no address contained in such IA options.
A.如果回复消息中有IA选项，SAVI设备将检查每个IA选项。当找到第一个分配的地址时，具有匹配TID的绑定条目的地址字段将设置为该地址。“生存期”字段设置为回复消息中的租用时间和最大\u DHCP\u响应\u时间之和。状态字段更改为绑定。如果消息中分配了多个地址，则会为IA选项中分配的剩余地址设置新的绑定条目。图8显示了条目的示例。SAVI设备不专门处理NoAddrsAvail状态的IA选项，因为此类IA选项中不应包含地址。
B. Otherwise, the DHCP Reply message is in response to a Confirm message. The state of the binding entries with a matched TID is changed to BOUND. Because [RFC3315] does not require the lease time of addresses to be contained in the Reply message, the SAVI device SHOULD send a LEASEQUERY [RFC5007] message querying by IP address to the All_DHCP_Servers multicast
B.否则，DHCP回复消息是对确认消息的响应。具有匹配TID的绑定项的状态更改为绑定。由于[RFC3315]不要求在回复消息中包含地址的租赁时间，因此SAVI设备应向所有DHCP_多播服务器发送按IP地址查询的租赁[RFC5007]消息
address [RFC3315] or a list of configured DHCP server addresses. The LEASEQUERY message is generated for each IP address if multiple addresses are confirmed. The lifetime of corresponding entries is set to 2*MAX_LEASEQUERY_DELAY. If there is no response message after MAX_LEASEQUERY_DELAY, send the LEASEQUERY message again. An example of the entries is illustrated in Figure 7. If the SAVI device does not send the LEASEQUERY message, a preconfigured lifetime DHCP_DEFAULT_LEASE MUST be set on the corresponding entry. (Note: it is RECOMMENDED to use T1 configured on DHCP servers as the DHCP_DEFAULT_LEASE.)
地址[RFC3315]或配置的DHCP服务器地址列表。如果确认了多个地址，将为每个IP地址生成LEASEQUERY消息。相应条目的生存期设置为2*MAX\u LEASEQUERY\u DELAY。如果在MAX_LEASEQUERY_延迟后没有响应消息，请再次发送LEASEQUERY消息。图7显示了条目的示例。如果SAVI设备不发送LEASEQUERY消息，则必须在相应条目上设置预配置的终身DHCP_DEFAULT_LEASE。（注意：建议使用DHCP服务器上配置的T1作为DHCP_默认_租约。）
Note: the SAVI devices do not check if the assigned addresses are duplicated because in SAVI-DHCP scenarios, the DHCP servers are the only source of valid addresses. However, the DHCP servers should be configured to make sure no duplicated addresses are assigned.
注意：SAVI设备不会检查分配的地址是否重复，因为在SAVI-DHCP方案中，DHCP服务器是唯一有效地址的来源。但是，应将DHCP服务器配置为确保未分配重复的地址。
+--------+-------+-------+------------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+-------+------------------------+-----+----------+
+--------+-------+-------+------------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr1 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr2 | BOUND | 2*MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+-------+------------------------+-----+----------+
Figure 7: From INIT_BIND to BOUND on DHCP Reply in Response to Confirm
图7:DHCP应答确认时从INIT_BIND到BIND
Transition
+--------+-------+-------+------------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr1 | BOUND |Lease time+ | TID | 0 |
| | | |MAX_DHCP_RESPONSE_TIME | | |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr2 | BOUND |Lease time+ | TID | 0 |
| | | |MAX_DHCP_RESPONSE_TIME | | |
+--------+-------+-------+------------------------+-----+----------+
Transition
+--------+-------+-------+------------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr1 | BOUND |Lease time+ | TID | 0 |
| | | |MAX_DHCP_RESPONSE_TIME | | |
+--------+-------+-------+------------------------+-----+----------+
| Port_1 | Addr2 | BOUND |Lease time+ | TID | 0 |
| | | |MAX_DHCP_RESPONSE_TIME | | |
+--------+-------+-------+------------------------+-----+----------+
Figure 8: From INIT_BIND to BOUND on DHCP Reply in Response to Request
图8：在响应请求的DHCP应答中从INIT_绑定到绑定
Resulting state: BOUND - The binding has been set up.
结果状态：绑定-已设置绑定。
6.4.2.2. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry expires
6.4.2.2. Event:EVE\u ENTRY\u EXPIRE-绑定项的生存期到期
The entry MUST be deleted from the BST.
必须从BST中删除该条目。
Resulting state: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
结果状态：从BST中删除的条目可能被视为处于“无绑定”状态-未设置绑定。
If no DHCP Server-to-Client messages that assign addresses or confirm addresses are received, corresponding entries will expire automatically. Thus, other DHCP Server-to-Client messages (e.g., DHCPv4 NAK) are not specially processed.
如果没有收到分配地址或确认地址的DHCP服务器到客户端消息，相应的条目将自动过期。因此，其他DHCP服务器到客户端消息（例如，DHCPv4 NAK）没有经过特殊处理。
As a result, the following events, should they occur, are ignored until either a DHCPv4 ACK or a DHCPv6 Reply message is received or the lifetime of the binding entry expires.
因此，以下事件（如果发生）将被忽略，直到收到DHCPv4 ACK或DHCPv6回复消息或绑定项的生存期到期。
o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is received
o EVE_DHCP_请求：收到DHCPv4请求或DHCPv6请求消息
o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received
o EVE_DHCP_确认：收到DHCPv6确认消息
o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received
o EVE\u DHCP\u重新启动：收到DHCPv4重新启动消息
o EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received
o EVE_DHCP_重新绑定：收到DHCPv4重新绑定或DHCPv6重新绑定消息
o EVE_DHCP_RENEW: A DHCPv4 Renew or a DHCPv6 Renew message is received
o EVE_DHCP_续订：收到DHCPv4续订或DHCPv6续订消息
o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid Commit option is received
o EVE\U DHCP\U请求\U RC：收到带有快速提交选项的DHCPv6请求消息
o EVE_DHCP_DECLINE: A DHCPv4 Decline or a DHCPv6 Decline message is received
o EVE_DHCP_拒绝：收到DHCPv4拒绝或DHCPv6拒绝消息
o EVE_DHCP_RELEASE: A DHCPv4 Release or a DHCPv6 Release message is received
o EVE_DHCP_发布：收到DHCPv4发布或DHCPv6发布消息
o EVE_DHCP_LEASEQUERY: A successful DHCPv6 LEASEQUERY-REPLY is received
o EVE_DHCP_租赁：收到成功的DHCPv6租赁回复
In each case, the message MUST be forwarded.
在每种情况下，都必须转发消息。
Resulting state: INIT_BIND - A potential binding has been set up.
结果状态：INIT_BIND-已设置潜在绑定。
6.4.3.1. Event: EVE_ENTRY_EXPIRE - The lifetime of a binding entry expires
6.4.3.1. Event:EVE\u ENTRY\u EXPIRE-绑定项的生存期到期
The entry MUST be deleted from the BST.
必须从BST中删除该条目。
Resulting state: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
结果状态：从BST中删除的条目可能被视为处于“无绑定”状态-未设置绑定。
6.4.3.2. Event: EVE_DHCP_DECLINE - A DHCPv4 Decline or a DHCPv6 Decline message is received
6.4.3.2. 事件：EVE_DHCP_拒绝-收到DHCPv4拒绝或DHCPv6拒绝消息
The message MUST be forwarded.
消息必须转发。
First, the SAVI device gets all the addresses ("Requested IP address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, and addresses in all the IA options of DHCPv6 Decline/Release) to decline/release in the message. Then, the corresponding entries MUST be removed.
首先，SAVI设备在消息中获取要拒绝/释放的所有地址（“DHCPv4拒绝中的请求IP地址”、“DHCPv4版本中的ciaddr”以及DHCPv6拒绝/释放的所有IA选项中的地址）。然后，必须删除相应的条目。
Resulting state in each relevant BST entry: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
每个相关BST条目中的结果状态：从BST中删除的条目可能被视为处于“无绑定”状态-未设置绑定。
6.4.3.3. Event: EVE_DHCP_RELEASE - A DHCPv4 Release or a DHCPv6 Release message is received
6.4.3.3. 事件：EVE_DHCP_释放-收到DHCPv4释放或DHCPv6释放消息
The message MUST be forwarded.
消息必须转发。
First, the SAVI device gets all the addresses ("Requested IP address" in DHCPv4 Decline, "ciaddr" in DHCPv4 Release, and addresses in all the IA options of DHCPv6 Decline/Release) to decline/release in the message. Then, the corresponding entries MUST be removed.
首先，SAVI设备在消息中获取要拒绝/释放的所有地址（“DHCPv4拒绝中的请求IP地址”、“DHCPv4版本中的ciaddr”以及DHCPv6拒绝/释放的所有IA选项中的地址）。然后，必须删除相应的条目。
Resulting state in each relevant BST entry: An entry that has been deleted from the BST may be considered to be in the "NO_BIND" state - No binding has been set up.
每个相关BST条目中的结果状态：从BST中删除的条目可能被视为处于“无绑定”状态-未设置绑定。
6.4.3.4. Event: EVE_DHCP_REBIND - A DHCPv4 Rebind or a DHCPv6 Rebind message is received
6.4.3.4. 事件：EVE_DHCP_重新绑定-收到DHCPv4重新绑定或DHCPv6重新绑定消息
The message MUST be forwarded.
消息必须转发。
In such a case, a new TID will be used by the client. The TID field of the corresponding entries MUST be set to the new TID. Note that the TID check will not be performed on such messages.
在这种情况下，客户将使用新的TID。相应条目的TID字段必须设置为新TID。请注意，不会对此类消息执行TID检查。
Resulting state: BOUND: The binding has been set up.
结果状态：绑定：绑定已设置。
6.4.3.5. Event: EVE_DHCP_RENEW - A DHCPv4 Renew or a DHCPv6 Renew message is received
6.4.3.5. 事件：EVE_DHCP_续订-收到DHCPv4续订或DHCPv6续订消息
The message MUST be forwarded.
消息必须转发。
In such a case, a new TID will be used by the client. The TID field of the corresponding entries MUST be set to the new TID. Note that the TID check will not be performed on such messages.
在这种情况下，客户将使用新的TID。相应条目的TID字段必须设置为新TID。请注意，不会对此类消息执行TID检查。
Resulting state: BOUND: The binding has been set up.
结果状态：绑定：绑定已设置。
6.4.3.6. Event: EVE_DHCP_REPLY - A DHCPv4 ACK or a DHCPv6 Reply message is received
6.4.3.6. 事件：EVE_DHCP_应答-收到DHCPv4 ACK或DHCPv6应答消息
The message MUST be forwarded.
消息必须转发。
The DHCP Reply messages received in current states should be in response to DHCP Renew/Rebind.
在当前状态下接收的DHCP回复消息应响应DHCP续订/重新绑定。
If the message is DHCPv4 ACK, the SAVI device updates the binding entry with a matched TID, with the Lifetime field set to be the sum of the new lease time and MAX_DHCP_RESPONSE_TIME, leaving the entry in the BOUND state.
如果消息为DHCPv4 ACK，则SAVI设备将使用匹配的TID更新绑定条目，并将生存期字段设置为新租约时间和最大DHCP响应时间之和，使条目处于绑定状态。
If the message is DHCPv6 Reply, the SAVI device checks each IA Address option in each IA option. For each:
如果消息为DHCPv6 Reply，则SAVI设备将检查每个IA选项中的每个IA地址选项。对于每个：
1. If the IA entry in the REPLY message has the status "NoBinding", there is no address in the option, and no operation on an address is performed.
1. 如果回复消息中的IA条目的状态为“NoBinding”，则选项中没有地址，并且不会对地址执行任何操作。
2. If the valid lifetime of an IA Address option is 0, the binding entry with a matched TID and address is removed, leaving it effectively in the NO_BIND state.
2. 如果IA Address选项的有效生存期为0，则删除具有匹配TID和地址的绑定项，使其有效地处于无绑定状态。
3. Otherwise, set the Lifetime field of the binding entry with the matched TID and address to be the sum of the new valid lifetime and MAX_DHCP_RESPONSE_TIME, leaving the entry in the BOUND state.
3. 否则，将具有匹配TID和地址的绑定项的生存期字段设置为新的有效生存期和最大\u DHCP\u响应\u时间之和，使该项处于绑定状态。
Resulting state: NO_BIND or BOUND, as specified.
结果状态：没有指定的绑定或绑定。
6.4.3.7. Event: EVE_DHCP_LEASEQUERY - A successful DHCPv6 LEASEQUERY_REPLY is received
6.4.3.7. 事件：EVE_DHCP_租赁-收到成功的DHCPv6租赁_回复
The message MUST be forwarded.
消息必须转发。
The message should be in response to the LEASEQUERY message sent in Section 6.4.2. The related binding entry can be determined based on the address in the IA Address option in the LEASEQUERY-REPLY message. The Lifetime field of the corresponding binding entry is set to the sum of the lease time in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME.
该信息应响应第6.4.2节中发送的租赁信息。可以根据LEASQUERY-REPLY消息中IA address选项中的地址确定相关绑定条目。相应绑定项的生存期字段设置为LEASEQUERY-REPLY消息中的租约时间和MAX_DHCP_RESPONSE_时间之和。
Resulting state: BOUND: The binding has been set up.
结果状态：绑定：绑定已设置。
The following events are ignored if received while the indicated entry is in the BOUND state. Any required action will be the result of the next message in the client/server exchange.
如果在指示的条目处于绑定状态时收到，则忽略以下事件。任何必需的操作都将是客户端/服务器交换中的下一条消息的结果。
o EVE_DHCP_REQUEST: A DHCPv4 Request or a DHCPv6 Request message is received
o EVE_DHCP_请求：收到DHCPv4请求或DHCPv6请求消息
o EVE_DHCP_CONFIRM: A DHCPv6 Confirm message is received
o EVE_DHCP_确认：收到DHCPv6确认消息
o EVE_DHCP_REBOOT: A DHCPv4 Reboot message is received
o EVE\u DHCP\u重新启动：收到DHCPv4重新启动消息
o EVE_DHCP_SOLICIT_RC: A DHCPv6 Solicitation message with the Rapid Commit option is received
o EVE\U DHCP\U请求\U RC：收到带有快速提交选项的DHCPv6请求消息
The main state transits are listed as follows. Note that not all the details are specified in the table and the diagram.
主要状态转换如下所示。请注意，并非所有细节都在表和图表中指定。
State Event Action Next State
---------------------------------------------------------------------
NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND
State Event Action Next State
---------------------------------------------------------------------
NO_BIND RQ/RC/CF/RE Generate entry INIT_BIND
INIT_BIND RPL Record lease time BOUND (send leasequery if no lease)
INIT_BIND RPL记录租赁时间限制（如果没有租赁，则发送租赁请求）
INIT_BIND EVE_ENTRY_EXPIRE Remove entry NO_BIND
初始绑定EVE\u条目到期删除条目无绑定
BOUND RLS/DCL Remove entry NO_BIND
绑定RLS/DCL删除条目无绑定
BOUND EVE_ENTRY_EXPIRE Remove entry NO_BIND
绑定EVE\u条目\u过期删除条目否\u绑定
BOUND RPL Set new lifetime BOUND
绑定RPL设置新的生存期绑定
BOUND LQR Record lease time BOUND
绑定LQR记录租赁时间绑定
Figure 9: State Transition Table
图9：状态转换表
RQ: EVE_DHCP_REQUEST RC: EVE_DHCP_SOLICIT_RC CF: EVE_DHCP_CONFIRM RE: EVE_DHCP_REBOOT RPL: EVE_DHCP_REPLY RLS: EVE_DHCP_RELEASE DCL: EVE_DHCP_DECLINE LQR: EVE_DHCP_LEASEQUERY
RQ:EVE_DHCP_请求RC:EVE_DHCP_请求RC:EVE_DHCP_确认RE:EVE_DHCP_重新启动RPL:EVE_DHCP_回复RLS:EVE_DHCP_释放DCL:EVE_DHCP_拒绝LQR:EVE_DHCP_租赁
+-------------+
| |
/--------+ NO_BIND |<--------\
| ----->| | |
| | +-------------+ |EVE_DHCP_RELEASE
EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE
EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE
EVE_DHCP_SOLICIT_RC| | |
EVE_DHCP_REBOOT | | |
| | |
| | |
v | |
+-------------+ +------------+
| | EVE_DHCP_REPLY | |
| INIT_BIND --------------------->| BOUND |<-\
| | | | |
+-------------+ +------------+ |
| |
\--------/
EVE_DHCP_REPLY
EVE_DHCP_LEASEQUERY
+-------------+
| |
/--------+ NO_BIND |<--------\
| ----->| | |
| | +-------------+ |EVE_DHCP_RELEASE
EVE_DHCP_REQUEST | | |EVE_DHCP_DECLINE
EVE_DHCP_CONFIRM | |EVE_ENTRY_EXPIRE |EVE_ENTRY_EXPIRE
EVE_DHCP_SOLICIT_RC| | |
EVE_DHCP_REBOOT | | |
| | |
| | |
v | |
+-------------+ +------------+
| | EVE_DHCP_REPLY | |
| INIT_BIND --------------------->| BOUND |<-\
| | | | |
+-------------+ +------------+ |
| |
\--------/
EVE_DHCP_REPLY
EVE_DHCP_LEASEQUERY
Figure 10: Diagram of Transit
图10：运输路线图
The rationale of the DHCP Snooping Process specified in Section 6 is that if a DHCP client's use of a DHCP address is legitimate, the corresponding DHCP address assignment procedure must have been finished during the attachment of the DHCP client. This is the case when the SAVI device is continuously on the path(s) from the DHCP client to the DHCP server(s)/relay(s). However, there are two cases in which this does not work:
第6节中规定的DHCP窥探过程的基本原理是，如果DHCP客户端对DHCP地址的使用是合法的，则相应的DHCP地址分配过程必须在连接DHCP客户端期间完成。当SAVI设备持续位于从DHCP客户端到DHCP服务器/中继的路径上时，会出现这种情况。但是，有两种情况下，这不起作用：
o Multiple paths: there is more than one feasible link-layer path from the client to the DHCP server/relay, and the SAVI device is not on every one of them. The client may get its address through one of the paths that does not pass through the SAVI device, but packets from the client can travel on paths that pass through the SAVI device, such as when the path through the link-layer network changes. Because the SAVI device could not snoop the DHCP packet exchange procedure, the DHCP Snooping Process cannot set up the corresponding binding.
o 多路径：从客户端到DHCP服务器/中继有多个可行的链路层路径，并且SAVI设备不在每个路径上。客户端可以通过不通过SAVI设备的路径之一获得其地址，但是来自客户端的分组可以在通过SAVI设备的路径上移动，例如当通过链路层网络的路径改变时。由于SAVI设备无法嗅探DHCP数据包交换过程，DHCP嗅探过程无法设置相应的绑定。
o Dynamic path: there is only one feasible link-layer path from the client to the DHCP server/relay, but the path is dynamic due to topology change (for example, some link becomes broken due to failure or some planned change) or link-layer path change. This situation also covers the local-link movement of clients without the address confirm/reconfiguration process. For example, a host changes its attached switch port in a very short time. In such cases, the DHCP Snooping Process will not set up the corresponding binding.
o 动态路径：从客户端到DHCP服务器/中继只有一个可行的链路层路径，但由于拓扑更改（例如，某些链路因故障或某些计划更改而断开）或链路层路径更改，该路径是动态的。这种情况还包括在没有地址确认/重新配置过程的情况下客户端的本地链路移动。例如，主机在很短的时间内更改其连接的交换机端口。在这种情况下，DHCP侦听进程将不会设置相应的绑定。
The Data Snooping Process can avoid the permanent blocking of legitimate traffic in case one of these two exceptions occurs. This process is performed on attachments with the Data-Snooping attribute. Data packets without a matching binding entry may trigger this process to set up bindings.
如果发生这两种异常中的一种，数据窥探过程可以避免对合法流量的永久阻塞。此过程在具有数据窥探属性的附件上执行。没有匹配绑定条目的数据包可能会触发此过程以设置绑定。
Snooping data traffic introduces a considerable burden on the processor and ASIC-to-Processor bandwidth of SAVI devices. Because of the overhead of this process, the implementation of this process is OPTIONAL. This function SHOULD be enabled unless the implementation is known to be used in the scenarios without the above exceptions. For example, if the implementation is to be used in networks with tree topology and without host local-link movement, there is no need to implement this process in such scenarios.
窥探数据流量给SAVI设备的处理器和ASIC到处理器带宽带来了相当大的负担。由于此过程的开销，此过程的实现是可选的。应启用此功能，除非已知在没有上述例外情况的场景中使用该实现。例如，如果要在具有树拓扑且没有主机本地链路移动的网络中使用该实现，则在此类场景中不需要实现该过程。
This process is not intended to set up a binding whenever a data packet without a matched binding entry is received. Instead, unmatched data packets trigger this process probabilistically, and generally a number of unmatched packets will be discarded before the binding is set up. The parameter(s) of this probabilistic process SHOULD be configurable, defaulting to a situation where data snooping is disabled.
当接收到没有匹配绑定条目的数据包时，此过程并不打算设置绑定。相反，不匹配的数据包可能会触发此过程，并且通常会在设置绑定之前丢弃许多不匹配的数据包。此概率过程的参数应该是可配置的，默认为禁用数据窥探的情况。
This process makes use of NS/ARP and DHCP Leasequery to set up bindings. If an address is not used by another client in the network, and the address has been assigned in the network, the address can be bound with the binding anchor of the attachment from which the unmatched packet is received.
此过程使用NS/ARP和DHCP请求来设置绑定。如果网络中的另一个客户端未使用地址，并且该地址已在网络中分配，则该地址可与接收不匹配数据包的附件的绑定锚绑定。
The Data Snooping Process provides an alternative path for binding entries to reach the BOUND state in the exceptional cases explained in Section 7.1 when there are no DHCP messages that can be snooped by the SAVI device.
在第7.1节所述的例外情况下，当SAVI设备无法窥探DHCP消息时，数据窥探过程为绑定条目提供了一条替代路径，以达到绑定状态。
In some of the exceptional cases (especially the dynamic topology case), by the time the binding has reached the BOUND state, the DHCP messages may be passing through the SAVI device. In this case, the events driven by DHCP messages that are expected in the BOUND state in the DHCP Snooping Process may occur, and the binding can be handled by the DHCP Snooping Process state machine.
在某些例外情况下（尤其是动态拓扑情况），当绑定达到绑定状态时，DHCP消息可能正在通过SAVI设备。在这种情况下，可能会发生DHCP侦听进程中预期处于绑定状态的DHCP消息驱动的事件，并且可以由DHCP侦听进程状态机处理绑定。
In any event, the lease expiry timeout event will occur even if no others do. This will cause the binding to be deleted and the state to logically return to NO_BIND state. Either the DHCP or the Data Snooping Process will be reinvoked if the lease is still in place. If DHCP messages are still not passing through the SAVI device, there will be a brief disconnection during which data packets passing through the SAVI device will be dropped. The probabilistic initiation of the Data Snooping Process can then take over again and return the binding state to BOUND in due course.
在任何情况下，租约到期超时事件都会发生，即使没有其他人会发生。这将导致绑定被删除，并且状态逻辑上返回到无绑定状态。如果租约仍然有效，DHCP或数据窥探过程将被重新调用。如果DHCP消息仍然没有通过SAVI设备，则会发生短暂的断开，在此期间，通过SAVI设备的数据包将被丢弃。然后，数据窥探过程的概率启动可以再次接管，并在适当的时候将绑定状态返回到绑定。
The security issues concerning this process are discussed in Section 11.1.
第11.1节讨论了与此过程有关的安全问题。
In addition to NO_BIND and BOUND from Section 6.2, three new states used in this process are listed here. The INIT_BIND state is not used, as it is entered by observing a DHCP message.
除了第6.2节中的“无约束”和“约束”外，此处还列出了此过程中使用的三种新状态。未使用INIT_BIND状态，因为它是通过观察DHCP消息输入的。
DETECTION: The address in the entry is undergoing local duplication detection.
检测：条目中的地址正在进行本地重复检测。
RECOVERY: The SAVI device is querying the assignment and lease time of the address in the entry through DHCP Leasequery.
恢复：SAVI设备正在通过DHCP租赁查询条目中地址的分配和租赁时间。
VERIFY: The SAVI device is verifying that the device connected to the attachment point has a hardware address that matches the one returned in the DHCP Leasequery.
验证：SAVI设备正在验证连接到连接点的设备是否具有与DHCP请求中返回的硬件地址匹配的硬件地址。
Because the mechanisms used for the operations carried out while the binding is in these three states operate over unreliable protocols, each operation is carried out twice with a timeout that is triggered if no response is received.
由于绑定处于这三种状态时执行的操作所使用的机制在不可靠的协议上运行，因此每个操作都会执行两次，并在未收到响应时触发超时。
To handle the Data Snooping Process, six extra events, described here, are needed in addition to those used by the DHCP Snooping Process (see Section 6.3). If an event will trigger the creation of a new binding entry, the binding entry limit on the binding anchor MUST NOT be exceeded.
为了处理数据窥探过程，除了DHCP窥探过程所使用的事件外，还需要六个额外的事件（参见第6.3节）。如果事件将触发新绑定项的创建，则不得超过绑定锚上的绑定项限制。
EVE_DATA_UNMATCH: A data packet without a matched binding is received.
EVE_DATA_UNMATCH：接收到没有匹配绑定的数据包。
EVE_DATA_CONFLICT: An ARP Reply / Neighbor Advertisement (NA) message against an address in the DETECTION state is received from a host other than the one for which the entry was added (i.e., a host attached at a point other than the one on which the triggering data packet was received).
EVE_数据_冲突：针对处于检测状态的地址的ARP回复/邻居公告（NA）消息从添加条目的主机以外的主机（即，连接在接收触发数据包的主机以外的主机）接收。
EVE_DATA_LEASEQUERY:
EVE\u数据\u租赁：
o IPv4: A DHCPLEASEACTIVE message with the IP Address Lease Time option is received. Note that the DHCPLEASEUNKNOWN and DHCPLEASEUNASSIGNED replies are ignored.
o IPv4:接收到具有IP地址租用时间选项的DHCPLEASEACTIVE消息。请注意，DHCPLEASEUNKNOWN和DHCPLEASEUNASSIGNED回复将被忽略。
o IPv6: A successful LEASEQUERY-REPLY is received.
o IPv6:收到成功的LEASEQUERY-REPLY。
EVE_DATA_VERIFY: An ARP Reply / NA message has been received in the VERIFY state from the device connected to the attachment point on which the data packet was received.
EVE_DATA_VERIFY：在验证状态下，已从连接到接收数据包的连接点的设备接收到ARP回复/NA消息。
The triggering packet should pass the following checks to trigger a valid event:
触发数据包应通过以下检查以触发有效事件：
o Attribute check: the data packet should be from attachments with the Data-Snooping attribute; the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages should be from attachments with the DHCP-Snooping attribute.
o 属性检查：数据包应来自具有数据窥探属性的附件；DHCPLEASEACTIVE/LEASEQUERY-REPLY消息应来自具有DHCP窥探属性的附件。
o Binding limitation check: the data messages must not cause new binding setup on an attachment whose binding entry limitation has been reached (refer to Section 11.5).
o 绑定限制检查：数据消息不得在已达到绑定条目限制的附件上导致新的绑定设置（请参阅第11.5节）。
o Address check: For EVE_DATA_LEASEQUERY, the source address of the DHCPLEASEQUERY messages must pass the check specified in Section 8.2. For EVE_DATA_CONFLICT and EVE_DATA_VERIFY, the source address and target address of the ARP or NA messages must pass the check specified in Section 8.2.
o 地址检查：对于EVE_DATA_LEASEQUERY，DHCPLEASEQUERY消息的源地址必须通过第8.2节规定的检查。对于EVE_数据_冲突和EVE_数据_验证，ARP或NA消息的源地址和目标地址必须通过第8.2节规定的检查。
o Interval check: the interval between two successive EVE_DATA_UNMATCH events triggered by an attachment MUST be no smaller than DATA_SNOOPING_INTERVAL.
o 间隔检查：附件触发的两个连续EVE\u数据\u不匹配事件之间的间隔不得小于数据\u窥探\u间隔。
o TID check: the DHCPLEASEACTIVE/LEASEQUERY-REPLY messages must have a matched TID with the corresponding entry.
o TID检查：DHCPLEASEACTIVE/LEASEQUERY-REPLY消息必须具有与相应条目匹配的TID。
o Prefix check: the source address of the data packet should be of a valid local prefix, as specified in Section 7 of [RFC7039].
o 前缀检查：数据包的源地址应为有效的本地前缀，如[RFC7039]第7节所述。
EVE_DATA_EXPIRE: A timer expires indicating that a response to a hardware address verification message sent in the VERIFY state has not been received within the specified DETECTION_TIMEOUT period.
EVE_DATA_EXPIRE：计时器过期，表示在指定的检测超时期间内未收到对在验证状态下发送的硬件地址验证消息的响应。
EVE_ENTRY_EXPIRE: A timer expires after the Lifetime indicated in the relevant BST entry has elapsed. This is identical to the usage in the DHCP Snooping Process.
EVE_ENTRY_EXPIRE：计时器在相关BST条目中指示的生存期结束后过期。这与DHCP侦听过程中的用法相同。
The Data Snooping Process involves sending three different messages to other network devices. Each message may be sent up to two times since they are sent over unreliable transports and are sent in different states. The functions defined in this section specify the messages to be sent in the three cases. In each case, the message to be sent depends on whether the triggering data packet is an IPv4 or an IPv6 packet.
数据窥探过程包括向其他网络设备发送三条不同的消息。每个消息最多可发送两次，因为它们通过不可靠的传输发送，并且以不同的状态发送。本节中定义的函数指定三种情况下要发送的消息。在每种情况下，要发送的消息取决于触发数据包是IPv4还是IPv6数据包。
Send a message to check if the source address in the data packet that triggered the Data Snooping Process has a local conflict (that is, it uses an address that is being used by another node):
发送消息以检查触发数据窥探过程的数据包中的源地址是否存在本地冲突（即，它使用另一个节点正在使用的地址）：
IPv4 address: Broadcast an Address Resolution Protocol (ARP) Request [RFC826] or an ARP Probe [RFC5227] for the address to the local network. An ARP Response will be expected from the device on the attachment point on which the triggering data packet was received. An ARP Reply received on any other port indicates a duplicate address.
IPv4地址：向本地网络广播地址解析协议（ARP）请求[RFC826]或ARP探测[RFC5227]。在接收到触发数据包的连接点上的设备预计会有ARP响应。在任何其他端口上接收到的ARP应答表示地址重复。
IPv6 address: Send a Duplicate Address Detection (DAD) message (Neighbor Solicitation message) to the solicited-node multicast address [RFC4861] targeting the address. Ideally, only the host on that point of attachment responds with a Neighbor Advertisement. A Neighbor Advertisement received on any other port indicates a duplicate address.
IPv6地址：向目标地址的请求节点多播地址[RFC4861]发送重复地址检测（DAD）消息（邻居请求消息）。理想情况下，只有该连接点上的主机响应邻居播发。在任何其他端口上接收到的邻居播发指示重复的地址。
As both the ARP and DAD processes are unreliable (the packet either to or from the other system may be lost in transit; see [RFC6620]), if there is no response after the DETECTION_TIMEOUT, an EVE_ENTRY_EXPIRE is generated.
由于ARP和DAD进程都不可靠（往返于另一个系统的数据包可能在传输过程中丢失；请参阅[RFC6620]），如果检测超时后没有响应，则会生成EVE条目。
Send a DHCPLEASEQUERY message to the DHCP server(s) to determine if it has given out a lease for the source address in the triggering data packet. A list of authorized DHCP servers is kept by the SAVI device. The list should be either preconfigured with the IPv4 and/or IPv6 addresses or dynamically discovered: For networks using IPv4, this can be done by sending DHCPv4 Discover messages and parsing the returned DHCPv4 Offer messages; for networks using IPv6, discovery can be done by sending DHCPv6 SOLICIT messages and parsing the returned ADVERTISE messages. The same TID should be used for all LEASEQUERY messages sent in response to a triggering data message on an attachment point. The TID is generated if the TID field in the BST entry is empty and recorded in the TID field of the BST entry when the first message is sent. Subsequent messages use the TID from the BST entry.
向DHCP服务器发送DHCPLEASEQUERY消息，以确定其是否已为触发数据包中的源地址发出租约。授权DHCP服务器的列表由SAVI设备保存。该列表应预先配置IPv4和/或IPv6地址或动态发现：对于使用IPv4的网络，可通过发送DHCPv4发现消息和解析返回的DHCPv4提供消息来实现；对于使用IPv6的网络，可以通过发送DHCPv6请求消息并解析返回的播发消息来完成发现。为响应附件点上的触发数据消息而发送的所有LEASEQUERY消息应使用相同的TID。如果发送第一条消息时，BST条目中的TID字段为空并记录在BST条目的TID字段中，则生成TID。后续消息使用来自BST条目的TID。
(1) IPv4 address: Send a DHCPLEASEQUERY [RFC4388] message querying by IP address to each DHCPv4 server in the list of authorized servers with an IP Address Lease Time option (option 51). If the server has a valid lease for the address, the requested information will be returned in a DHCPLEASEACTIVE message.
(1) IPv4地址：通过IP地址向具有IP地址租用时间选项（选项51）的授权服务器列表中的每个DHCPv4服务器发送DHCPLEASEQUERY[RFC4388]消息查询。如果服务器具有该地址的有效租约，则请求的信息将在DHCPLEASEACTIVE消息中返回。
(2) IPv6 address: Send a LEASEQUERY [RFC5007] message querying by IP address to each DHCPv6 server in the list of authorized servers using the server address as the link-address in the LEASEQUERY message. If the server has a valid lease for the address, the requested information will be returned in a LEASEQUERY-REPLY message marked as successful (i.e., without an OPTION_STATUS_CODE in the reply). The IA Address option(s) returned contains any IPv6 addresses bound to the same link together with the lease validity time.
(2) IPv6地址：使用服务器地址作为LEASEQUERY消息中的链接地址，向授权服务器列表中的每个DHCPv6服务器发送按IP地址查询的LEASEQUERY[RFC5007]消息。如果服务器拥有该地址的有效租约，则请求的信息将在标记为成功的LEASEQUERY-REPLY消息中返回（即，答复中没有选项\状态\代码）。返回的IA地址选项包含绑定到同一链路的所有IPv6地址以及租约有效期。
As DHCP Leasequeries are an unreliable process (the packet either to or from the server may be lost in transit), if there is no response after the MAX_LEASEQUERY_DELAY, an EVE_DATA_EXPIRE is generated. Note that multiple response messages may be received if the list of authorized servers contains more than one address of the appropriate type and, in the case of DHCPv6, the responses may contain additional addresses for which leases have been allocated.
由于DHCP LEASEQUERY是一个不可靠的进程（进出服务器的数据包可能在传输过程中丢失），如果在MAX_LEASEQUERY_延迟后没有响应，则会生成EVE_DATA_EXPIRE。请注意，如果授权服务器列表包含多个适当类型的地址，并且在DHCPv6的情况下，响应可能包含已分配租约的其他地址，则可能会收到多个响应消息。
Send a message to verify that the link-layer address in the attached device that sent the triggering data packet matches the link-layer address contained in the leasequery response:
发送消息以验证发送触发数据包的连接设备中的链路层地址是否与leasequery响应中包含的链路层地址匹配：
IPv4 address: Send an ARP Request with the Target Protocol Address set to the IP address in the BST entry. The ARP Request is only sent to the attachment that triggered the binding. If the attached device has the IP address bound to the interface attached to the SAVI device, an ARP Reply should be received containing the hardware address of the interface on the attached device that can be compared with the leasequery value.
IPv4地址：发送ARP请求，目标协议地址设置为BST条目中的IP地址。ARP请求只发送到触发绑定的附件。如果连接的设备的IP地址绑定到连接到SAVI设备的接口，则应接收ARP回复，其中包含连接设备上接口的硬件地址，该地址可与leasequery值进行比较。
IPv6 address: Send a Neighbor Solicitation (NS) message with the target address set to the IP address in the BST entry. The NS is only sent to the attachment that triggered the binding. If the attached device has the IP address bound to the interface attached to the SAVI device, an NA should be received indicating that the attached device has the IP address configured on the interface.
IPv6地址：发送邻居请求（NS）消息，目标地址设置为BST条目中的IP地址。NS仅发送到触发绑定的附件。如果连接的设备具有绑定到连接到SAVI设备的接口的IP地址，则应接收NA，指示连接的设备具有在接口上配置的IP地址。
As both the ARP and NS/NA processes are unreliable (the packet either to or from the other system may be lost in transit; see [RFC6620]), if there is no response after the DETECTION_TIMEOUT, an EVE_DATA_EXPIRE is generated.
由于ARP和NS/NA进程都不可靠（往返于其他系统的数据包可能在传输过程中丢失；请参阅[RFC6620]），如果检测超时后没有响应，则会生成EVE数据过期。
7.6.1. Event: EVE_DATA_UNMATCH: A data packet without a matched binding is received
7.6.1. 事件：EVE_DATA_UNMATCH：接收到没有匹配绑定的数据包
Make a probabilistic determination as to whether to act on this event. The probability may be configured or calculated based on the state of the SAVI device. This probability should be low enough to mitigate the damage from DoS attacks against this process.
对是否对此事件采取行动做出概率决定。可基于SAVI设备的状态来配置或计算概率。此概率应足够低，以减轻针对此进程的DoS攻击造成的损害。
Create a new entry in the BST. Set the Binding Anchor field to the corresponding binding anchor of the attachment. Set the Address field to the source address of the packet.
在BST中创建一个新条目。将绑定锚字段设置为附件的相应绑定锚。将地址字段设置为数据包的源地址。
Address conflicts MUST be detected and prevented.
必须检测并防止地址冲突。
If local address detection is performed: Set the State field to DETECTION. Set the Lifetime of the created entry to DETECTION_TIMEOUT. Set the Timeouts field to 0. Start the detection of any local address conflicts by sending a Duplicate Address Detection Message (Section 7.5.1). Transition to DETECTION state.
如果执行本地地址检测：将状态字段设置为检测。将创建项的生存期设置为检测超时。将超时字段设置为0。通过发送重复地址检测消息（第7.5.1节），开始检测任何本地地址冲突。转换到检测状态。
If local address detection is not performed: Set the State field to RECOVERY. Set the Lifetime of the created entry to LEASEQUERY_DELAY. Set the Timeouts field to 0. Start the recovery of any DHCP lease associated with the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2). Transition to RECOVERY state.
如果未执行本地地址检测：将状态字段设置为RECOVERY。将创建项的生存期设置为LEASEQUERY\u DELAY。将超时字段设置为0。通过发送一条或多条LEASEQUERY消息（第7.5.2节），开始恢复与源IP地址关联的任何DHCP租约。过渡到恢复状态。
The packet that triggers this event SHOULD be discarded.
应丢弃触发此事件的数据包。
An example of the BST entry during duplicate address detection is illustrated in Figure 11.
图11显示了重复地址检测期间的BST条目示例。
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr1 |DETECTION| DETECTION_TIMEOUT | | 0 |
+--------+-------+---------+-----------------------+-----+----------+
+--------+-------+---------+-----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+---------+-----------------------+-----+----------+
| Port_1 | Addr1 |DETECTION| DETECTION_TIMEOUT | | 0 |
+--------+-------+---------+-----------------------+-----+----------+
Figure 11: Binding Entry in BST on Data-Triggered Initialization
图11：数据触发初始化时BST中的绑定条目
Resulting state: DETECTION - The address in the entry is undergoing local duplication detection - or RECOVERY - The DHCP lease(s) associated with the address is being queried.
结果状态：检测-条目中的地址正在进行本地重复检测-或恢复-正在查询与该地址关联的DHCP租约。
EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system.
EVE_数据_冲突：从意外系统接收到ARP回复/NA消息。
EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or LEASEQUERY-REPLY is received.
EVE\U DATA\U LEASEQUERY：收到有效的DHCPLEASACTIVE或LEASEQUERY-REPLY。
EVE_DATA_VERIFY: A valid ARP Reply or NA message is received from the attached device.
EVE_数据_验证：从连接的设备接收到有效的ARP回复或NA消息。
All EVE_DHCP_* events defined in Section 6.3.2 are treated as described in the DHCP Snooping Process (Section 6.4.1) and may result in that process being triggered.
第6.3.2节中定义的所有EVE_DHCP_*事件按照DHCP窥探过程（第6.4.1节）中的描述进行处理，并可能导致触发该过程。
EVE_ENTRY_EXPIRE: Expiration of the DECTECTION_TIMEOUT
EVE\u条目\u过期：检测超时过期
EVE_DATA_EXPIRE: Expiration of the DECTECTION_TIMEOUT
EVE\u数据\u过期：检测超时过期
When this event occurs, no address conflict has been detected during the previous DETECTION_TIMEOUT period.
发生此事件时，在上一个检测超时期间未检测到地址冲突。
If the Timeouts field in the BST entry is 0: Set the Lifetime of the BST entry to DETECTION_TIMEOUT. Set the Timeouts field to 1. Restart the detection of any local address conflicts by sending a second Duplicate Address Detection Message (Section 7.5.1). Remain in DETECTION state.
如果BST项中的超时字段为0：将BST项的生存期设置为检测超时。将超时字段设置为1。通过发送第二条重复地址检测消息（第7.5.1节），重新开始检测任何本地地址冲突。保持在检测状态。
If the Timeouts field in the BST entry is 1:
如果BST条目中的超时字段为1：
Assume that there is no local address conflict. Set the State field to RECOVERY. Set the Lifetime of the BST entry to LEASEQUERY_DELAY. Set the Timeouts field to 0. Start the recovery of any DHCP lease associated with the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2). Transition to RECOVERY state.
假设没有本地地址冲突。将“状态”字段设置为“恢复”。将BST项的生存期设置为LEASEQUERY\u DELAY。将超时字段设置为0。通过发送一条或多条LEASEQUERY消息（第7.5.2节），开始恢复与源IP地址关联的任何DHCP租约。过渡到恢复状态。
An example of the entry is illustrated in Figure 12.
图12中显示了一个条目示例。
+--------+-------+----------+----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+----------+----------------------+-----+----------+
| Port_1 | Addr1 | RECOVERY | MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+----------+----------------------+-----+----------+
+--------+-------+----------+----------------------+-----+----------+
| Anchor |Address| State | Lifetime | TID | Timeouts |
+--------+-------+----------+----------------------+-----+----------+
| Port_1 | Addr1 | RECOVERY | MAX_LEASEQUERY_DELAY | TID | 0 |
+--------+-------+----------+----------------------+-----+----------+
Figure 12: Binding Entry in BST on Leasequery
图12:Leasequery上BST中的绑定条目
Resulting state: DETECTION - If a second local conflict period is required - or RECOVERY - The SAVI device is querying the assignment and lease time of the address in the entry through DHCP Leasequery.
结果状态：检测-如果需要第二个本地冲突周期-或恢复-SAVI设备通过DHCP Leasequery查询条目中地址的分配和租赁时间。
7.7.2. Event: EVE_DATA_CONFLICT: ARP Reply / NA Message Received from Unexpected System
7.7.2. 事件：EVE_数据_冲突：从意外系统接收到ARP回复/NA消息
Remove the entry.
删除条目。
Resulting state: NO_BIND - No binding has been set up.
结果状态：无绑定-未设置绑定。
EVE_DATA_UNMATCH: A data packet without a matched binding is received
EVE_DATA_UNMATCH：接收到没有匹配绑定的数据包
All EVE_DHCP_* events defined in Section 6.3.2
第6.3.2节中定义的所有EVE_DHCP_*事件
EVE_DHCP_REBIND: A DHCPv4 Rebind or a DHCPv6 Rebind message is received
EVE_DHCP_重新绑定：收到DHCPv4重新绑定或DHCPv6重新绑定消息
7.8.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or successful LEASEQUERY-REPLY is received
7.8.1. 事件：EVE\U DATA\U LEASEQUERY:收到有效的DHCPLEASACTIVE或SUCCESS LEASEQUERY-REPLY
Set the State in the BST entry to VERIFY. Depending on the type of triggering source IP address, process the received DHCP Leasequery response:
在BST条目中设置要验证的状态。根据触发源IP地址的类型，处理收到的DHCP请求响应：
IPv4 address: Update the Lifetime field in the BST entry to the sum of the value encoded in the IP Address Lease Time option of the DHCPLEASEACTIVE message and MAX_DHCP_RESPONSE_TIME. Record the value of the "chaddr" field (hardware address) in the message for checking against the hardware address received during verification in the next state. Set the Timeouts field to 0. Start the verification process by sending an Address Verification Message (see Section 7.5.3). Transition to VERIFY state. Start an additional verification timer with a duration of DETECTION_TIMEOUT. When this expires, an EVE_DATA_EXPIRE event will be generated.
IPv4地址：将BST条目中的生存期字段更新为DHCPLEASEACTIVE消息的IP地址租用时间选项中编码的值与最大DHCP\U响应时间之和。在消息中记录“chaddr”字段（硬件地址）的值，以便对照下一状态下验证期间接收到的硬件地址进行检查。将超时字段设置为0。通过发送地址验证消息启动验证过程（见第7.5.3节）。转换到验证状态。启动额外的验证计时器，持续时间为检测超时。当此过期时，将生成EVE\u DATA\u EXPIRE事件。
IPv6 address: Update the Lifetime field in the BST entry to the sum of the valid lifetime extracted from the OPTION_CLIENT_DATA option in the LEASEQUERY-REPLY message and MAX_DHCP_RESPONSE_TIME. Set the Timeouts field to 0. Start the verification process by sending an Address Verification Message (see Section 7.5.3). Transition to VERIFY state. Start an additional verification timer with a duration of DETECTION_TIMEOUT. When this expires, an EVE_DATA_EXPIRE event will be generated.
IPv6地址：将BST条目中的生存期字段更新为从LEASEQUERY-REPLY消息中的选项\u CLIENT\u DATA选项提取的有效生存期与最大\u DHCP\u响应\u时间之和。将超时字段设置为0。通过发送地址验证消息启动验证过程（见第7.5.3节）。转换到验证状态。启动额外的验证计时器，持续时间为检测超时。当此过期时，将生成EVE\u DATA\u EXPIRE事件。
If multiple addresses are received in the LEASEQUERY-REPLY, new BST entries MUST be created for the additional addresses using the same binding anchor. The entries are created with state set to VERIFY and the other fields set as described in this section for the triggering source IP address. Also, start the verification process and start verification timers for each additional address.
如果在LEASEQUERY-REPLY中接收到多个地址，则必须使用相同的绑定锚为其他地址创建新的BST条目。创建条目时，状态设置为验证，其他字段设置为触发源IP地址，如本节所述。另外，启动验证过程，并为每个附加地址启动验证计时器。
Resulting state: VERIFY - Awaiting verification or otherwise of the association of the IP address with the connected interface.
结果状态：验证-等待验证或以其他方式验证IP地址与连接接口的关联。
Depending on the value of the Timeouts field in the BST entry, either send repeat LEASEQUERY messages or discard the binding:
根据BST条目中超时字段的值，发送重复请求消息或放弃绑定：
If the Timeouts field in the BST entry is 0: No responses to the LEASEQUERY message(s) sent have been received during the first LEASEQUERY_DELAY period. Set the Lifetime of the BST entry to LEASEQUERY_DELAY. Set the Timeouts field to 1. Restart the recovery of any DHCP lease associated with the source IP address by sending one or more LEASEQUERY messages (Section 7.5.2). Remain in RECOVERY state.
如果BST条目中的超时字段为0：在第一个LEASEQUERY\u延迟期间未收到对发送的LEASEQUERY消息的响应。将BST项的生存期设置为LEASEQUERY\u DELAY。将超时字段设置为1。通过发送一条或多条LEASEQUERY消息（第7.5.2节），重新启动与源IP地址关联的任何DHCP租约的恢复。保持恢复状态。
If the Timeouts field in the BST entry is 1: No responses to the LEASEQUERY messages sent during two LEASEQUERY_DELAY periods were received. Assume that no leases exist and hence that the source IP address is bogus. Delete the BST entry. Transition to NO_BIND state.
如果BST条目中的超时字段为1：未收到对两个LEASEQUERY_延迟期间发送的LEASEQUERY消息的响应。假设不存在租约，因此源IP地址是伪造的。删除BST条目。转换到无绑定状态。
Resulting state: RECOVERY - If repeat leasequeries are sent - or NO_BIND - If no successful responses to LEASEQUERY messages have been received.
结果状态：恢复-如果发送了重复的LEASEQUERY-或者没有绑定-如果没有收到对LEASEQUERY消息的成功响应。
EVE_DATA_UNMATCH: A data packet without a matched binding is received
EVE_DATA_UNMATCH：接收到没有匹配绑定的数据包
EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system
EVE_数据_冲突：接收到来自意外系统的ARP回复/NA消息
EVE_DATA_VERIFY: A valid ARP Reply or NA message is received from the attached device
EVE_数据_验证：从连接的设备接收到有效的ARP回复或NA消息
All EVE_DHCP_* events defined in Section 6.3.2
第6.3.2节中定义的所有EVE_DHCP_*事件
EVE_DATA_EXPIRE: Expiration of the DECTECTION_TIMEOUT
EVE\u数据\u过期：检测超时过期
7.9.1. Event: EVE_DATA_LEASEQUERY: A valid DHCPLEASEACTIVE or successful LEASEQUERY-REPLY is received
7.9.1. 事件：EVE\U DATA\U LEASEQUERY:收到有效的DHCPLEASACTIVE或SUCCESS LEASEQUERY-REPLY
If LEASEQUERY messages were sent to more than one DHCP server during RECOVERY state, additional successful leasequery responses may be received relating to the source IP address. The conflict resolution mechanisms specified in Section 6.8 of [RFC4388] and Section 4.3.4 of [RFC5007] can be used to determine the message from which values are used to update the BST Lifetime entry and the hardware address
如果在恢复状态期间向多个DHCP服务器发送了LEASEQUERY消息，则可能会收到与源IP地址相关的其他成功LEASEQUERY响应。[RFC4388]第6.8节和[RFC5007]第4.3.4节中规定的冲突解决机制可用于确定用于更新BST生存期条目和硬件地址的值的消息
obtained from DHCP, as described in Section 7.8.1. In the case of DHCPv6 queries, the LEASEQUERY-REPLY may contain additional addresses as described in Section 7.8.1. If so, additional BST entries MUST be created or ones previously created updated as described in that section.
从DHCP获得，如第7.8.1节所述。在DHCPv6查询的情况下，LEASEQUERY-REPLY可能包含第7.8.1节所述的其他地址。如果是这样，则必须创建其他BST条目，或者按照该节中的说明更新以前创建的条目。
Resulting state: VERIFY (no change).
结果状态：验证（无更改）。
7.9.2. Event: EVE_DATA_VERIFY: A valid ARP Reply or NA is received from the device attached via the binding anchor
7.9.2. 事件：EVE_DATA_VERIFY：从通过绑定锚连接的设备接收到有效的ARP回复或NA
Depending on the type of triggering source IP address, this event may indicate that the device attached via the binding anchor in the BST entry is configured by DHCP using the IP address:
根据触发源IP地址的类型，此事件可能表示通过BST条目中的绑定锚连接的设备由DHCP使用IP地址配置：
IPv4 address: Check that the value of the sender hardware address in the ARP Reply matches the saved "chaddr" field (hardware address) from the previously received DHCPLEASEACTIVE message. If not, ignore this event; a subsequent retry may provide verification. If the hardware addresses match, the binding entry has been verified.
IPv4地址：检查ARP回复中发送方硬件地址的值是否与先前收到的DHCPLEASEACTIVE消息中保存的“chaddr”字段（硬件地址）匹配。如果没有，则忽略此事件；随后的重试可能会提供验证。如果硬件地址匹配，则已验证绑定条目。
IPv6 address: Simple receipt of a valid NA from the triggering source IP address at the binding anchor port provides verification for the binding entry.
IPv6地址：从绑定锚端口的触发源IP地址简单接收有效NA，即可验证绑定条目。
If the binding entry has been verified, set the state in the BST entry to BOUND. Clear the TID field. Cancel the verification timer.
如果已验证绑定项，请将BST项中的状态设置为绑定。清除TID字段。取消验证计时器。
Resulting state: VERIFY (no change) - If the IPv4 DHCPLEASEQUERY "chaddr" address does not match the ARP Reply hardware address. Otherwise, the resulting state is BOUND.
结果状态：验证（无更改）-如果IPv4 DHCPLEASEQUERY“chaddr”地址与ARP应答硬件地址不匹配。否则，结果状态将被绑定。
The DHCP lease lifetime has expired before the entry could be verified. Remove the entry. Transition to NO_BIND state.
在验证条目之前，DHCP租约生存期已过期。删除条目。转换到无绑定状态。
Resulting state: NO_BIND - No binding has been set up.
结果状态：无绑定-未设置绑定。
Depending on the value of the Timeouts field in the BST entry, either send a repeat validation message or discard the binding:
根据BST条目中超时字段的值，发送重复验证消息或放弃绑定：
If the Timeouts field in the BST entry is 0: No response to the verification message sent has been received during the first DETECTION_TIMEOUT period. Set the Timeouts field to 1. Restart the verification process by sending an Address Verification Message (see Section 7.5.3). Start a verification timer with a duration of DETECTION_TIMEOUT. When this expires, an EVE_DATA_EXPIRE event will be generated. Remain in VERIFY state.
如果BST条目中的超时字段为0：在第一个检测超时期间未收到对发送的验证消息的响应。将超时字段设置为1。通过发送地址验证消息重新启动验证过程（见第7.5.3节）。启动一个持续时间为检测超时的验证计时器。当此过期时，将生成EVE\u DATA\u EXPIRE事件。保持在验证状态。
If the Timeouts field in the BST entry is 1: No responses to the verification messages sent during two DETECTION_TIMEOUT periods were received. Assume that the configuration of the triggering source IP address cannot be verified and hence that the source IP address is bogus. Delete the BST entry. Transition to NO_BIND state.
如果BST条目中的超时字段为1：未收到对两个检测超时期间发送的验证消息的响应。假设无法验证触发源IP地址的配置，因此源IP地址是假的。删除BST条目。转换到无绑定状态。
Resulting state: VERIFY - Additional verification message sent - or NO_BIND - No binding has been set up.
结果状态：验证-已发送其他验证消息-或没有绑定-未设置绑定。
EVE_DATA_UNMATCH: A data packet without a matched binding is received
EVE_DATA_UNMATCH：接收到没有匹配绑定的数据包
EVE_DATA_CONFLICT: An ARP Reply / NA message is received from an unexpected system
EVE_数据_冲突：接收到来自意外系统的ARP回复/NA消息
All EVE_DHCP_* events defined in Section 6.3.2
第6.3.2节中定义的所有EVE_DHCP_*事件
Upon entry to the BOUND state, control of the system continues as if a DHCP message assigning the address has been observed, as in Section 6.4.3. The BST entry has been restored.
进入绑定状态后，系统的控制将继续进行，就像观察到分配地址的DHCP消息一样，如第6.4.3节所示。BST条目已恢复。
Note that the TID field contains no value after the binding state changes to BOUND. The TID field is recovered from snooping DHCP Renew/Rebind messages if these are observed as described in the DHCP Snooping Process. Because TID is used to associate binding entries with messages from DHCP servers, it must be recovered or else a number of state transitions of this mechanism will not be executed normally.
请注意，绑定状态更改为绑定后，TID字段不包含任何值。如果按照DHCP侦听过程中的描述观察到DHCP续订/重新绑定消息，则会从侦听DHCP续订/重新绑定消息中恢复TID字段。由于TID用于将绑定条目与来自DHCP服务器的消息相关联，因此必须将其恢复，否则此机制的许多状态转换将无法正常执行。
The main state transitions are listed as follows.
主要状态转换如下所示。
State Event Action Next State
---------------------------------------------------------------------
NO_BIND EVE_DATA_UNMATCH Start duplicate detect DETECTION
State Event Action Next State
---------------------------------------------------------------------
NO_BIND EVE_DATA_UNMATCH Start duplicate detect DETECTION
DETECTION EVE_ENTRY_EXPIRE 1 Repeat duplicate detect DETECTION
检测EVE\u条目\u过期1重复重复检测重复检测
DETECTION EVE_ENTRY_EXPIRE 2 Start leasequery RECOVERY
检测EVE\u条目\u过期2开始租赁恢复
DETECTION EVE_DATA_CONFLICT Remove entry NO_BIND
检测EVE\u数据\u冲突删除条目无\u绑定
RECOVERY EVE_ENTRY_EXPIRE 1 Repeat leasequery RECOVERY
恢复前夕\u条目\u过期1重复租赁请求恢复
RECOVERY EVE_ENTRY_EXPIRE 2 No lease found; remove entry NO_BIND
恢复前夕\u条目\u到期2未找到租约；删除条目NO_BIND
RECOVERY EVE_DATA_LEASEQUERY Set lease time; start verify VERIFY
恢复EVE\u数据\u租赁设置租赁时间；启动验证验证
VERIFY EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND
核实EVE\u条目\u到期租赁到期；删除条目NO_BIND
VERIFY EVE_DATA_LEASEQUERY Resolve lease conflict(s) VERIFY
验证EVE\u数据\u租赁请求解决租赁冲突验证
VERIFY EVE_DATA_VERIFY Finish validation BOUND or NO_BIND
验证EVE\u数据\u验证完成验证绑定或无绑定
VERIFY EVE_DATA_EXPIRE 1 Repeat verify VERIFY
验证EVE\u数据\u过期1重复验证验证
VERIFY EVE_DATA_EXPIRE 2 Verify failed; remove entry NO_BIND
验证EVE_数据_EXPIRE 2验证失败；删除条目NO_BIND
BOUND EVE_ENTRY_EXPIRE Lease expiry; remove entry NO_BIND
绑定EVE\u条目\u到期租赁到期；删除条目NO_BIND
BOUND RENEW/REBIND Record TID BOUND
绑定续订/重新绑定记录TID绑定
Figure 13: State Transition Table
图13：状态转换表
+-------------+ EVE_ENTRY_EXPIRE
/---------+ |<------------------------\
| | NO_BIND | EVE_DATA_EXPIRE |
EVE_DATA_UNMATCH | /----->| |<----\ (2nd VRF_DELAY) |
| | +-------------+ | |
| | EVE_ENTRY_EXPIRE | |
| | (2nd LQ_DELAY) | |
EVE_ENTRY_EXPIRE | | | EVE_ENTRY_EXPIRE |
(1st DAD_DELAY) | | | (1st LQ_DELAY) |
/------\ | | | /--------\ |
| | | | EVE_DATA_CONFLICT \---\ | | |
| v v | | v | |
| +-------------+ EVE_ENTRY_EXPIRE +------------+ | |
| | | (2nd DAD_DELAY) | | | |
\----+ DETECTION ------------------------>| RECOVERY +--/ |
| | | | |
+-------------+ (To NO_BIND) +------------+ |
^ | |
| EVE_DATA_LEASEQUERY | |
/----------\ | | |
| | | EVE_ENTRY_EXPIRE | |
EVE_DHCP_RENEW| v | v |
EVE_DHCP_REBIND| +-------------+ +-------------+ |
| | | | +--/
\----+ BOUND |<---------------+ VERIFY |
| | EVE_DATA_VERIFY| |<-\
+-------------+ +-------------+ |
| |
\----------/
EVE_DATA_LEASEQUERY
EVE_DATA_EXPIRE
(1st VRF_DELAY)
+-------------+ EVE_ENTRY_EXPIRE
/---------+ |<------------------------\
| | NO_BIND | EVE_DATA_EXPIRE |
EVE_DATA_UNMATCH | /----->| |<----\ (2nd VRF_DELAY) |
| | +-------------+ | |
| | EVE_ENTRY_EXPIRE | |
| | (2nd LQ_DELAY) | |
EVE_ENTRY_EXPIRE | | | EVE_ENTRY_EXPIRE |
(1st DAD_DELAY) | | | (1st LQ_DELAY) |
/------\ | | | /--------\ |
| | | | EVE_DATA_CONFLICT \---\ | | |
| v v | | v | |
| +-------------+ EVE_ENTRY_EXPIRE +------------+ | |
| | | (2nd DAD_DELAY) | | | |
\----+ DETECTION ------------------------>| RECOVERY +--/ |
| | | | |
+-------------+ (To NO_BIND) +------------+ |
^ | |
| EVE_DATA_LEASEQUERY | |
/----------\ | | |
| | | EVE_ENTRY_EXPIRE | |
EVE_DHCP_RENEW| v | v |
EVE_DHCP_REBIND| +-------------+ +-------------+ |
| | | | +--/
\----+ BOUND |<---------------+ VERIFY |
| | EVE_DATA_VERIFY| |<-\
+-------------+ +-------------+ |
| |
\----------/
EVE_DATA_LEASEQUERY
EVE_DATA_EXPIRE
(1st VRF_DELAY)
Figure 14: Diagram of Transit
图14：运输路线图
LQ_DELAY: MAX_LEASEQUERY_DELAY VRF_DELAY: DETECTION_TIMEOUT
LQ\u延迟：最大\u请求\u延迟VRF\u延迟：检测\u超时
This section specifies how to use bindings to filter out packets with spoofed source addresses.
本节指定如何使用绑定过滤具有伪造源地址的数据包。
Filtering policies are different for data packets and control packets. DHCP, ARP, and Neighbor Discovery Protocol (NDP) [RFC4861] messages are classified as control packets. All other packets are classified as data packets.
数据包和控制包的过滤策略不同。DHCP、ARP和邻居发现协议（NDP）[RFC4861]消息被分类为控制数据包。所有其他数据包被分类为数据包。
Data packets from attachments with the Validating attribute TRUE MUST have their source addresses validated. There is one exception to this rule.
来自Validating属性为TRUE的附件的数据包的源地址必须经过验证。这条规则有一个例外。
A packet whose source IP address is a link-local address cannot be checked against DHCP assignments, as it is not assigned using DHCP. Note: as explained in Section 1, a SAVI solution for link-local addresses, e.g., FCFS SAVI [RFC6620], can be enabled to check packets with a link-local source address.
无法根据DHCP分配检查源IP地址为链路本地地址的数据包，因为它不是使用DHCP分配的。注：如第1节所述，可启用链路本地地址的SAVI解决方案，例如FCFS SAVI[RFC6620]，以检查具有链路本地源地址的数据包。
If the source IP address of a packet is not a link-local address, but there is not a matching entry in the BST with BOUND state, this packet MUST be discarded. However, the packet may trigger the Data Snooping Process (Section 7) if the Data-Snooping attribute is set on the attachment.
如果数据包的源IP地址不是链路本地地址，但BST中没有绑定状态的匹配条目，则必须丢弃该数据包。然而，如果在附件上设置了数据窥探属性，则分组可以触发数据窥探过程（第7部分）。
Data packets from an attachment with the Validating attribute set FALSE will be forwarded without having their source addresses validated.
来自验证属性设置为FALSE的附件的数据包将在未验证其源地址的情况下转发。
The SAVI device MAY log packets that fail source address validation.
SAVI设备可以记录源地址验证失败的数据包。
For attachments with the Validating attribute:
对于具有验证属性的附件：
DHCPv4 Client-to-Server messages in which the source IP address is neither all zeros nor bound with the corresponding binding anchor in the BST MUST be discarded.
必须丢弃源IP地址既不全零也不与BST中相应绑定锚绑定的DHCPv4客户端到服务器消息。
DHCPv6 Client-to-Server messages in which the source IP address is neither a link-local address nor bound with the corresponding binding anchor in the BST MUST be discarded.
必须丢弃源IP地址既不是链接本地地址也不是与BST中相应绑定锚绑定的DHCPv6客户端到服务器消息。
NDP messages in which the source IP address is neither a link-local address nor bound with the corresponding binding anchor MUST be discarded.
必须丢弃源IP地址既不是链路本地地址也不是与相应绑定锚绑定的NDP消息。
NA messages in which the target address is neither a link-local address nor bound with the corresponding binding anchor MUST be discarded.
必须丢弃目标地址既不是链接本地地址也不是与相应绑定锚绑定的NA消息。
ARP messages in which the protocol is IP and the sender protocol address is neither all zeros nor bound with the corresponding binding anchor MUST be discarded.
协议为IP且发送方协议地址既不全零也不与相应绑定锚绑定的ARP消息必须丢弃。
ARP Reply messages in which the target protocol address is not bound with the corresponding binding anchor MUST be discarded.
必须丢弃其中目标协议地址未与相应绑定锚绑定的ARP应答消息。
For attachments with other attributes:
对于具有其他属性的附件：
DHCP Server-to-Client messages not from attachments with the DHCP-Trust attribute or Trust attribute MUST be discarded.
必须丢弃非来自具有DHCP信任属性或信任属性的附件的DHCP服务器到客户端消息。
For attachments with no attribute:
对于没有属性的附件：
DHCP Server-to-Client messages from such attachments MUST be discarded.
必须丢弃来自此类附件的DHCP服务器到客户端消息。
The SAVI device MAY record any messages that are discarded.
SAVI设备可以记录被丢弃的任何消息。
If a SAVI device reboots, the information kept in volatile memory will be lost. This section specifies the restoration of attribute configuration and the BST.
如果SAVI设备重新启动，保存在易失性存储器中的信息将丢失。本节规定了属性配置和BST的恢复。
The loss of attribute configuration will not break the network: no action will be performed on traffic from attachments with no attribute. However, the loss of attribute configuration makes this SAVI function unable to work.
属性配置丢失不会中断网络：不会对来自无属性附件的流量执行任何操作。但是，属性配置的丢失使此SAVI功能无法工作。
To avoid the loss of binding anchor attribute configuration, the configuration MUST be able to be stored in non-volatile storage. After the reboot of the SAVI device, if the configuration of binding anchor attributes is found in non-volatile storage, the configuration MUST be used.
为了避免丢失绑定锚属性配置，配置必须能够存储在非易失性存储器中。重新启动SAVI设备后，如果在非易失性存储器中找到绑定锚属性的配置，则必须使用该配置。
The loss of binding state will cause the SAVI devices to discard legitimate traffic. Simply using the Data Snooping Process to recover a large number of bindings is a heavy overhead and may cause considerable delay. Thus, recovering bindings from non-volatile storage, as specified below, is RECOMMENDED.
绑定状态的丢失将导致SAVI设备放弃合法通信。简单地使用数据窥探过程来恢复大量绑定是一项巨大的开销，可能会导致相当大的延迟。因此，建议从非易失性存储恢复绑定，如下所述。
Binding entries MAY be saved into non-volatile storage whenever a new binding entry changes to BOUND state. If a binding with BOUND state is removed, the saved entry MUST be removed correspondingly. The time when each binding entry is established is also saved.
每当新绑定项更改为绑定状态时，可以将绑定项保存到非易失性存储器中。如果删除了具有绑定状态的绑定，则必须相应地删除保存的条目。每个绑定条目建立的时间也会被保存。
If the BST is stored in non-volatile storage, the SAVI device SHOULD restore binding state from the non-volatile storage immediately after reboot. Using the time when each binding entry was saved, the SAVI device should check whether the entry has become obsolete by comparing the saved lifetime and the difference between the current time and time when the binding entry was established. Obsolete entries that would have expired before the reboot MUST be removed.
如果BST存储在非易失性存储器中，则SAVI设备应在重新启动后立即从非易失性存储器恢复绑定状态。使用保存每个绑定条目的时间，SAVI设备应通过比较保存的生存期和当前时间与建立绑定条目的时间之间的差异来检查条目是否已过时。必须删除在重新启动之前过期的过时条目。
The following constants are recommended for use in this context:
建议在此上下文中使用以下常量：
o MAX_DHCP_RESPONSE_TIME (120s): Maximum Solicit timeout value (SOL_MAX_RT from [RFC3315])
o 最大DHCP响应时间（120s）：最大请求超时值（来自[RFC3315]的SOL\u MAX\u RT）
o MAX_LEASEQUERY_DELAY (10s): Maximum LEASEQUERY timeout value (LQ_MAX_RT from [RFC5007])
o 最大租赁延迟（10s）：最大租赁超时值（LQ\U最大租赁时间从[RFC5007]）
o DETECTION_TIMEOUT (0.5s): Maximum duration of a hardware address verification step in the VERIFY state (TENT_LT from [RFC6620])
o 检测超时（0.5s）：验证状态下硬件地址验证步骤的最长持续时间（从[RFC6620]开始）
o DATA_SNOOPING_INTERVAL: Minimum interval between two successive EVE_DATA_UNMATCH events triggered by an attachment. Recommended interval: 60s and configurable
o 数据窥探间隔：由附件触发的两个连续EVE数据不匹配事件之间的最小间隔。建议间隔：60秒，可配置
o OFFLINK_DELAY: Period after a client is last detected before the binding anchor is being removed. Recommended delay: 30s
o OFFLINK_DELAY：上次检测到客户端后的一段时间，在移除绑定锚之前。建议延迟：30秒
There are two security problems with the Data Snooping Process (Section 7):
数据窥探过程存在两个安全问题（第7节）：
(1) The Data Snooping Process is costly, but an attacker can trigger it simply through sending a number of data packets. To avoid Denial-of-Service attacks against the SAVI device itself, the Data Snooping Process MUST be rate limited. A constant DATA_SNOOPING_INTERVAL is used to control the frequency. Two Data Snooping Processes on one attachment MUST be separated by a minimum interval time of DATA_SNOOPING_INTERVAL. If this value is changed, the value needs to be large enough to minimize DoS attacks.
(1) 数据窥探过程代价高昂，但攻击者只需发送大量数据包即可触发该过程。为避免针对SAVI设备本身的拒绝服务攻击，数据窥探过程必须具有速率限制。使用恒定的数据窥探间隔来控制频率。一个附件上的两个数据窥探过程必须以数据窥探间隔的最小间隔时间分隔。如果更改此值，则该值需要足够大，以最小化DoS攻击。
(2) The Data Snooping Process may set up incorrect bindings if the clients do not reply to the detection probes (Section 7.6.1). An attack will pass the duplicate detection if the client
(2) 如果客户端不回复检测探测，数据窥探过程可能会设置不正确的绑定（第7.6.1节）。如果客户端
assigned the target address does not reply to the detection probes. The DHCP Leasequery procedure performed by the SAVI device just tells whether or not the address is assigned in the network. However, the SAVI device cannot determine whether the address is just assigned to the triggering attachment from the DHCPLEASEQUERY Reply.
分配的目标地址不响应检测探测。SAVI设备执行的DHCP Leasequery过程只是告诉您是否在网络中分配了地址。但是，SAVI设备无法确定地址是否刚刚从DHCPLEASEQUERY应答分配给触发附件。
In [RFC4388] and [RFC5007], the specific case of DHCP Leasequeries originated by "access concentrators" is addressed extensively. SAVI devices are very similar to access concentrators in that they snoop on DHCP traffic and seek to validate source addresses based on the results. Accordingly, the recommendations for securing leasequery operations for access concentrators in Section 7 of [RFC4388] and Section 5 of [RFC5007] MUST be followed when leasequeries are made from SAVI devices. [RFC5007] RECOMMENDS that communications between the querier and the DHCP server are protected with IPsec. It is pointed out that there are relatively few devices involved in a given administrative domain (SAVI devices, DHCP relays, and DHCP servers) so that manual configuration of keying material would not be overly burdensome.
在[RFC4388]和[RFC5007]中，广泛讨论了由“访问集中器”发起的DHCP租赁的具体情况。SAVI设备与访问集中器非常相似，它们窥探DHCP流量并根据结果验证源地址。因此，当使用SAVI设备进行租赁时，必须遵守[RFC4388]第7节和[RFC5007]第5节中关于确保接入集中器租赁操作的建议。[RFC5007]建议使用IPsec保护查询器和DHCP服务器之间的通信。需要指出的是，在给定的管理域中涉及的设备相对较少（SAVI设备、DHCP中继和DHCP服务器），因此手动配置键控材料不会过于繁重。
After a binding is set up, the corresponding client may leave its attachment point. It may depart temporarily due to signal fade or permanently by moving to a new attachment point or leaving the network. In the signal fade case, since the client may return shortly, the binding should be kept momentarily, lest legitimate traffic from the client be blocked. However, if the client leaves permanently, keeping the binding can be a security issue. If the binding anchor is a property of the attachment point rather than the client, e.g., the switch port but not incorporating the MAC address, an attacker using the same binding anchor can send packets using IP addresses assigned to the client. Even if the binding anchor is a property of the client, retaining binding state for a departed client for a long time is a waste of resources.
设置绑定后，相应的客户端可以离开其连接点。它可能由于信号衰减而暂时离开，也可能由于移动到新的连接点或离开网络而永久离开。在信号衰减的情况下，由于客户端可能很快返回，因此绑定应暂时保持，以免来自客户端的合法通信被阻塞。但是，如果客户端永久离开，则保留绑定可能是一个安全问题。如果绑定锚是连接点而不是客户端的属性，例如交换机端口但未包含MAC地址，则使用相同绑定锚的攻击者可以使用分配给客户端的IP地址发送数据包。即使绑定锚是客户机的一个属性，长期保留离开的客户机的绑定状态也是一种资源浪费。
Whenever a direct client departs from the network, a link-down event associated with the binding anchor will be triggered. SAVI-DHCP monitors such events and performs the following mechanism.
只要直接客户端离开网络，就会触发与绑定锚关联的链路断开事件。SAVI-DHCP监视此类事件并执行以下机制。
(1) Whenever a client with the Validating attribute leaves, a timer of duration OFFLINK_DELAY is set on the corresponding binding entries.
(1) 每当具有Validating属性的客户机离开时，就会在相应的绑定条目上设置一个持续时间为OFFLINK\u DELAY的计时器。
(2) If a DAD Neighbor Solicitation / Gratuitous ARP request is received that targets the address during OFFLINK_DELAY, the entry MAY be removed.
(2) 如果在断开链路延迟期间接收到以地址为目标的DAD邻居请求/免费ARP请求，则可以删除该条目。
(3) If the client returns on-link during OFFLINK_DELAY, cancel the timer.
(3) 如果客户端在OFFLINK_延迟期间返回链路，请取消计时器。
In this way, the bindings of a departing client are kept for OFFLINK_DELAY. In cases of link flapping, the client will not be blocked. If the client leaves permanently, the bindings will be removed after OFFLINK_DELAY.
通过这种方式，离开客户机的绑定将保留为OFFLINK_延迟。在链接摆动的情况下，客户端将不会被阻止。如果客户端永久离开，则在断开链接延迟后将删除绑定。
SAVI-DHCP does not handle the departure of indirect clients because it will not be notified of such events. Switches supporting indirect attachment (e.g., through a separate non-SAVI switch) SHOULD use information specific to the client such as its MAC address as part of the binding anchor.
SAVI-DHCP不处理间接客户端的离开，因为它不会收到此类事件的通知。支持间接连接的交换机（例如，通过单独的非SAVI交换机）应使用特定于客户端的信息，例如其MAC地址，作为绑定锚的一部分。
DNA [RFC4436] [RFC6059] is designed to decrease the handover latency after reattachment to the same network. DNA mainly relies on performing a reachability test by sending unicast Neighbor Solicitation / Router Solicitation / ARP Request messages to determine whether a previously configured address is still valid.
DNA[RFC4436][RFC6059]旨在减少重新连接到同一网络后的切换延迟。DNA主要依赖于通过发送单播邻居请求/路由器请求/ARP请求消息来执行可达性测试，以确定先前配置的地址是否仍然有效。
Although DNA provides optimization for clients, there is insufficient information for this mechanism to migrate the previous binding or establish a new binding. If a binding is set up only by snooping the reachability test message, the binding may be invalid. For example, an attacker can perform the reachability test with an address bound to another client. If a binding is migrated to the attacker, the attacker can successfully obtain the binding from the victim. Because this mechanism wouldn't set up a binding based on snooping the DNA procedure, it cannot achieve perfect compatibility with DNA. However, it only means the reconfiguration of the interface is slowed but not prevented. Details are discussed as follows.
虽然DNA为客户机提供了优化，但没有足够的信息支持此机制迁移以前的绑定或建立新的绑定。如果仅通过窥探可达性测试消息来设置绑定，则绑定可能无效。例如，攻击者可以使用绑定到其他客户端的地址执行可达性测试。如果将绑定迁移到攻击者，则攻击者可以成功地从受害者处获得绑定。因为这种机制不会建立一个基于窥探DNA程序的绑定，所以它无法实现与DNA的完美兼容性。然而，这只意味着接口的重新配置速度变慢，而不是被阻止。具体讨论如下。
In Simple DNAv6 [RFC6059], the probe is sent with the source address set to a link-local address, and such messages will not be discarded by the policy specified in Section 8.2. If a client is reattached to a previous network, the detection will be completed, and the address will be regarded as valid by the client. However, the candidate address is not contained in the probe. Thus, the binding cannot be recovered through snooping the probe. As the client will perform DHCP exchange at the same time, the binding will be recovered from the DHCP Snooping Process. The DHCP Request messages will not be filtered out in this case because they have link-local source
在Simple DNAv6[RFC6059]中，发送探测器时，源地址设置为链路本地地址，并且此类消息不会被第8.2节中指定的策略丢弃。如果客户端重新连接到以前的网络，则检测将完成，并且该地址将被客户端视为有效。但是，候选地址不包含在探测中。因此，无法通过窥探探针来恢复绑定。由于客户端将同时执行DHCP交换，绑定将从DHCP侦听过程中恢复。在这种情况下，DHCP请求消息不会被过滤掉，因为它们具有链接本地源
addresses. Before the DHCP procedure is completed, packets will be filtered out by the SAVI device. In other words, if this SAVI function is enabled, Simple DNAv6 will not help reduce the handover latency. If the Data-Snooping attribute is configured on the new attachment of the client, the data-triggered procedure may reduce latency.
地址。在DHCP过程完成之前，SAVI设备将过滤掉数据包。换句话说，如果启用此SAVI功能，简单的DNAv6将无助于减少切换延迟。如果在客户端的新附件上配置了数据窥探属性，则数据触发过程可能会减少延迟。
In DNAv4 [RFC4436], the ARP Probe will be discarded because an unbound address is used as the sender protocol address. As a result, the client will regard the address under detection as valid. However, the data traffic will be filtered. The DHCP Request message sent by the client will not be discarded because the source IP address field should be all zeros as required by [RFC2131]. Thus, if the address is still valid, the binding will be recovered from the DHCP Snooping Process.
在DNAv4[RFC4436]中，ARP探测将被丢弃，因为未绑定的地址被用作发送方协议地址。因此，客户端将认为检测到的地址有效。但是，数据流量将被过滤。客户端发送的DHCP请求消息不会被丢弃，因为源IP地址字段应为[RFC2131]要求的全零。因此，如果地址仍然有效，绑定将从DHCP窥探过程中恢复。
A binding entry will consume certain high-speed memory resources. In general, a SAVI device can afford only a quite limited number of binding entries. In order to prevent an attacker from overloading the resources of the SAVI device, a binding entry limit is set on each attachment. The binding entry limit is the maximum number of bindings supported on each attachment with the Validating attribute. No new binding should be set up after the limit has been reached. If a DHCP Reply assigns more addresses than the remaining binding entry quota of each client, the message will be discarded and no binding will be set up.
绑定条目将消耗某些高速内存资源。一般来说，SAVI设备只能提供数量相当有限的绑定条目。为了防止攻击者过载SAVI设备的资源，在每个附件上设置了绑定条目限制。binding entry limit是具有Validating属性的每个附件上支持的最大绑定数。达到限制后，不应设置新绑定。如果DHCP应答分配的地址超过每个客户端的剩余绑定条目配额，则消息将被丢弃，并且不会设置绑定。
A SAVI device MUST delete binding anchor information as soon as possible (i.e., as soon as the state for a given address is back to NO_BIND), except where there is an identified reason why that information is likely to be involved in the detection, prevention, or tracing of actual source-address spoofing. Information about hosts that never spoof (probably the majority of hosts) SHOULD NOT be logged.
SAVI设备必须尽快删除绑定锚信息（即，一旦给定地址的状态恢复为无绑定），除非有确定的原因说明该信息可能涉及实际源地址欺骗的检测、预防或跟踪。不应记录有关从不欺骗的主机（可能是大多数主机）的信息。
This specification does not preclude reassembly of fragmented DHCP messages, but it also does not require it. If DHCP fragmentation proves to be an issue, the issue will need to be specified and addressed. (This topic is beyond the scope of this document.)
本规范不排除重新组装分段的DHCP消息，但也不要求重新组装。如果DHCP碎片被证明是一个问题，则需要指定并解决该问题。（本主题超出了本文档的范围。）
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，DOI 10.17487/RFC0826，1982年11月<http://www.rfc-editor.org/info/rfc826>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, DOI 10.17487/RFC4388, February 2006, <http://www.rfc-editor.org/info/rfc4388>.
[RFC4388]Woundy，R.和K.Kinnear，“动态主机配置协议（DHCP）租赁”，RFC 4388，DOI 10.17487/RFC4388，2006年2月<http://www.rfc-editor.org/info/rfc4388>.
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, DOI 10.17487/RFC4436, March 2006, <http://www.rfc-editor.org/info/rfc4436>.
[RFC4436]Aboba，B.，Carlson，J.，和S.Cheshire，“检测IPv4中的网络连接（DNAv4）”，RFC 4436，DOI 10.17487/RFC4436，2006年3月<http://www.rfc-editor.org/info/rfc4436>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, September 2007, <http://www.rfc-editor.org/info/rfc5007>.
[RFC5007]Brzowski，J.，Kinnear，K.，Volz，B.，和S.Zeng，“DHCPv6租赁”，RFC 5007，DOI 10.17487/RFC5007，2007年9月<http://www.rfc-editor.org/info/rfc5007>.
[RFC5227] Cheshire, S., "IPv4 Address Conflict Detection", RFC 5227, DOI 10.17487/RFC5227, July 2008, <http://www.rfc-editor.org/info/rfc5227>.
[RFC5227]南柴郡，“IPv4地址冲突检测”，RFC 5227，DOI 10.17487/RFC5227，2008年7月<http://www.rfc-editor.org/info/rfc5227>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, <http://www.rfc-editor.org/info/rfc6059>.
[RFC6059]Krishnan，S.和G.Daley，“IPv6中检测网络连接的简单程序”，RFC 6059，DOI 10.17487/RFC6059，2010年11月<http://www.rfc-editor.org/info/rfc6059>.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, DOI 10.17487/RFC6620, May 2012, <http://www.rfc-editor.org/info/rfc6620>.
[RFC6620]Nordmark，E.，Bagnulo，M.和E.Levy Abegnoli，“FCFS SAVI：本地分配IPv6地址的先到先得源地址验证改进”，RFC 6620，DOI 10.17487/RFC6620，2012年5月<http://www.rfc-editor.org/info/rfc6620>.
[DHCPv6-SHIELD] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers", Work in Progress, draft-ietf-opsec-dhcpv6-shield-07, May 2015.
[DHCPv6 SHIELD]Gont，F.，Liu，W.，和G.Van de Velde，“DHCPv6 SHIELD:防范恶意DHCPv6服务器”，正在进行的工作，草稿-ietf-opsec-DHCPv6-SHIELD-07，2015年5月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，DOI 10.17487/RFC2827，2000年5月<http://www.rfc-editor.org/info/rfc2827>.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, April 2004, <http://www.rfc-editor.org/info/rfc3736>.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，DOI 10.17487/RFC3736，2004年4月<http://www.rfc-editor.org/info/rfc3736>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, <http://www.rfc-editor.org/info/rfc7039>.
[RFC7039]Wu，J.，Bi，J.，Bagnulo，M.，Baker，F.，和C.Vogt，Ed.，“源地址验证改进（SAVI）框架”，RFC 7039，DOI 10.17487/RFC7039，2013年10月<http://www.rfc-editor.org/info/rfc7039>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014, <http://www.rfc-editor.org/info/rfc7341>.
[RFC7341]Sun，Q.，Cui，Y.，Siodelski，M.，Krishnan，S.，和I.Farrer，“DHCPv4-over-DHCPv6（DHCP 4o6）传输”，RFC 7341，DOI 10.17487/RFC73412014年8月<http://www.rfc-editor.org/info/rfc7341>.
Acknowledgments
致谢
Special thanks to Jean-Michel Combes, Christian Vogt, Joel M. Halpern, Eric Levy-Abegnoli, Marcelo Bagnulo Braun, Jari Arkko, Elwyn Davies, Barry Leiba, Ted Lemon, Leaf Yeh, Ralph Droms, and Alberto Garcia for careful review and evaluation comments on the mechanism and text.
特别感谢Jean-Michel Combs、Christian Vogt、Joel M.Halpern、Eric Levy Abegnoli、Marcelo Bagnulo Braun、Jari Arkko、Elwyn Davies、Barry Leiba、Ted Lemon、Leaf Yeh、Ralph Droms和Alberto Garcia对机制和文本的仔细审查和评估意见。
Thanks to Mark Williams, Erik Nordmark, Mikael Abrahamsson, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Bingyang Liu, Duanqi Zhou, Robert Raszuk, Greg Daley, John Kaippallimalil, and Tao Lin for their valuable contributions.
感谢马克·威廉姆斯、埃里克·诺德马克、米凯尔·艾布拉姆松、大卫·哈林顿、佩卡·萨沃拉、邢莉、张丽霞、刘秉阳、周端琪、罗伯特·拉祖克、格雷格·戴利、约翰·凯帕利马利尔和陶琳的宝贵贡献。
Authors' Addresses
作者地址
Jun Bi Network Research Center, Tsinghua University Beijing 100084 China
清华大学骏碧网络研究中心北京100084
EMail: junbi@tsinghua.edu.cn
EMail: junbi@tsinghua.edu.cn
Jianping Wu Dept. of Computer Science, Tsinghua University Beijing 100084 China
清华大学计算机科学系吴建平北京100084
EMail: jianping@cernet.edu.cn
EMail: jianping@cernet.edu.cn
Guang Yao Network Research Center, Tsinghua University Beijing 100084 China
清华大学光耀网络研究中心北京100084
EMail: yaoguang@cernet.edu.cn
EMail: yaoguang@cernet.edu.cn
Fred Baker Cisco Systems Santa Barbara, CA 93117 United States
美国加利福尼亚州圣巴巴拉市弗雷德·贝克思科系统公司，邮编：93117
EMail: fred@cisco.com
EMail: fred@cisco.com