Internet Engineering Task Force (IETF) J. Bi
Request for Comments: 8074 Tsinghua University
Category: Standards Track G. Yao
ISSN: 2070-1721 Tsinghua University/Baidu
J. Halpern
Ericsson
E. Levy-Abegnoli, Ed.
Cisco
February 2017
Internet Engineering Task Force (IETF) J. Bi
Request for Comments: 8074 Tsinghua University
Category: Standards Track G. Yao
ISSN: 2070-1721 Tsinghua University/Baidu
J. Halpern
Ericsson
E. Levy-Abegnoli, Ed.
Cisco
February 2017
Source Address Validation Improvement (SAVI) for Mixed Address Assignment Methods Scenario
混合地址分配方法场景的源地址验证改进（SAVI）
Abstract
摘要
In networks that use multiple techniques for address assignment, the spoofing of addresses assigned by each technique can be prevented using the appropriate Source Address Validation Improvement (SAVI) methods. This document reviews how multiple SAVI methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods.
在使用多种地址分配技术的网络中，可以使用适当的源地址验证改进（SAVI）方法防止对每种技术分配的地址进行欺骗。本文档回顾了多个SAVI方法如何在单个SAVI设备中共存，以及当两个或多个方法发现相同的绑定条目时，如何解决冲突。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8074.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8074.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Recommendations for Assignment Separation . . . . . . . . . . 6
6. Resolving Binding Collisions . . . . . . . . . . . . . . . . 6
6.1. Same Address on Different Binding Anchors . . . . . . . . 6
6.1.1. Basic Preference . . . . . . . . . . . . . . . . . . 7
6.1.2. Exceptions . . . . . . . . . . . . . . . . . . . . . 7
6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 8
6.2. Same Address on the Same Binding Anchor . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Recommendations for Assignment Separation . . . . . . . . . . 6
6. Resolving Binding Collisions . . . . . . . . . . . . . . . . 6
6.1. Same Address on Different Binding Anchors . . . . . . . . 6
6.1.1. Basic Preference . . . . . . . . . . . . . . . . . . 7
6.1.2. Exceptions . . . . . . . . . . . . . . . . . . . . . 7
6.1.3. Multiple SAVI Device Scenario . . . . . . . . . . . . 8
6.2. Same Address on the Same Binding Anchor . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
There are currently several Source Address Validation Improvement (SAVI) documents ([RFC6620], [RFC7513], and [RFC7219]) that describe the different methods by which a switch can discover and record bindings between a node's IP address and a binding anchor and use that binding to perform source address validation. Each of these documents specifies how to learn on-link addresses, based on the technique used for their assignment: StateLess Address Autoconfiguration (SLAAC), the Dynamic Host Control Protocol (DHCP), and Secure Neighbor Discovery (SEND), respectively. Each of these documents describes separately how one particular SAVI method deals with address collisions (same address but different binding anchor).
目前有几个源地址验证改进（SAVI）文档（[RFC6620]、[RFC7513]和[RFC7219]）描述了交换机可以发现和记录节点IP地址和绑定锚之间的绑定并使用该绑定执行源地址验证的不同方法。这些文档中的每一个都指定了如何根据用于分配的技术了解链路地址：无状态地址自动配置（SLAAC）、动态主机控制协议（DHCP）和安全邻居发现（SEND）。这些文档中的每一个都分别描述了一个特定的SAVI方法如何处理地址冲突（相同的地址但不同的绑定锚）。
While multiple IP assignment techniques can be used in the same layer 2 domain, this means that a single SAVI device might have to deal with a combination or mix of SAVI methods. The purpose of this document is to provide recommendations to avoid collisions and to review collision handling when two or more such methods come up with competing bindings.
虽然在同一层2域中可以使用多个IP分配技术，但这意味着单个SAVI设备可能必须处理SAVI方法的组合或混合。本文档的目的是提供避免冲突的建议，并在两个或多个此类方法出现竞争绑定时检查冲突处理。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Three different IP address assignment techniques have been analyzed for SAVI:
针对SAVI分析了三种不同的IP地址分配技术：
1. StateLess Address Autoconfiguration (SLAAC) -- analyzed in FCFS SAVI (First-Come, First-Served) [RFC6620]
1. 无状态地址自动配置（SLAAC）——在FCFS SAVI中分析（先到先得）[RFC6620]
2. Dynamic Host Control Protocol address assignment (DHCP) -- analyzed in SAVI-DHCP [RFC7513]
2. 动态主机控制协议地址分配（DHCP）——在SAVI-DHCP[RFC7513]中分析
3. Secure Neighbor Discovery (SEND) address assignment -- analyzed in SEND SAVI [RFC7219]
3. 安全邻居发现（SEND）地址分配——在SEND SAVI[RFC7219]中分析
In addition, there is a fourth technique for managing (i.e., creation, management, and deletion) a binding on the switch, referred to as "manual". It is based on manual binding configuration. How to manage manual bindings is determined by operators, so there is not a new SAVI method for manual addresses.
此外，还有第四种技术用于管理交换机上的绑定（即创建、管理和删除），称为“手动”。它基于手动绑定配置。如何管理手动绑定由操作员决定，因此没有针对手动地址的新SAVI方法。
All combinations of address assignment techniques can coexist within a layer 2 domain. A SAVI device MUST implement the corresponding binding setup methods (referred to as "SAVI methods") for each such technique that is in use if it is to provide source address validation.
地址分配技术的所有组合都可以在第2层域中共存。如果要提供源地址验证，SAVI设备必须为正在使用的每种此类技术实现相应的绑定设置方法（称为“SAVI方法”）。
SAVI methods are normally viewed as independent from each other, each one handling its own entries. If multiple methods are used in the same device without coordination, each method will attempt to reject packets sourced with any addresses that method did not discover. To prevent addresses discovered by one SAVI method from being filtered out by another method, the SAVI binding table SHOULD be shared by all the SAVI methods in use in the device. This in turn could create some conflict when the same entry is discovered by two different methods. The purpose of this document is twofold: to provide recommendations and methods to avoid conflicts and to resolve conflicts when they happen. Collisions happening within a given method are outside the scope of this document.
SAVI方法通常被视为相互独立，每个方法处理自己的条目。如果在同一设备中使用多个方法而不进行协调，则每个方法将尝试拒绝使用该方法未发现的任何地址来源的数据包。为了防止一个SAVI方法发现的地址被另一个方法过滤掉，设备中使用的所有SAVI方法都应该共享SAVI绑定表。当使用两种不同的方法发现同一条目时，这反过来可能会产生一些冲突。本文件的目的有两个：提供避免冲突的建议和方法，以及在冲突发生时解决冲突。在给定方法中发生的冲突不在本文档的范围内。
A SAVI device may implement and use multiple SAVI methods. This mechanism, called "SAVI-MIX", is proposed as an arbiter of the binding generation algorithms from these multiple methods, generating the final binding entries as illustrated in Figure 1. Once a SAVI method generates a candidate binding, it will request that SAVI-MIX set up a corresponding entry in the binding table. Then, SAVI-MIX will check if there is any conflict in the binding table. A new binding will be generated if there is no conflict. If there is a conflict, SAVI-MIX will determine whether to replace the existing binding or reject the candidate binding based on the policies specified in Section 6.
SAVI设备可以实现和使用多个SAVI方法。这一机制被称为“SAVI-MIX”，被提议作为来自这些多个方法的绑定生成算法的仲裁者，生成最终的绑定条目，如图1所示。一旦SAVI方法生成候选绑定，它将请求SAVI-MIX在绑定表中设置相应的条目。然后，SAVI-MIX将检查绑定表中是否存在任何冲突。如果没有冲突，将生成新绑定。如果存在冲突，SAVI-MIX将根据第6节中指定的策略确定是替换现有绑定还是拒绝候选绑定。
As a result of this, the packet filtering in the SAVI device will not be performed by each SAVI method separately. Instead, the table resulting from applying SAVI-MIX will be used to perform filtering. Thus, the filtering is based on the combined results of the different SAVI mechanisms. It is beyond the scope of this document to describe the details of the filtering mechanism and its use of the combined SAVI binding table.
因此，SAVI设备中的分组过滤将不会由每个SAVI方法单独执行。相反，应用SAVI-MIX产生的表格将用于执行过滤。因此，过滤基于不同SAVI机制的组合结果。描述过滤机制的细节及其对组合SAVI绑定表的使用超出了本文档的范围。
+--------------------------------------------------------+
| |
| SAVI Device |
| |
| |
| +------+ +------+ +------+ |
| | SAVI | | SAVI | | SAVI | |
| | | | | | | |
| | FCFS | | DHCP | | SEND | |
| +------+ +------+ +------+ |
| | | | Binding |
| | | | setup |
| v v v requests |
| +------------------------------+ |
| | | |
| | SAVI-MIX | |
| | | |
| +------------------------------+ |
| | |
| v Final Binding |
| +--------------+ |
| | Binding | |
| | | |
| | Table | |
| +--------------+ |
| |
+--------------------------------------------------------+
+--------------------------------------------------------+
| |
| SAVI Device |
| |
| |
| +------+ +------+ +------+ |
| | SAVI | | SAVI | | SAVI | |
| | | | | | | |
| | FCFS | | DHCP | | SEND | |
| +------+ +------+ +------+ |
| | | | Binding |
| | | | setup |
| v v v requests |
| +------------------------------+ |
| | | |
| | SAVI-MIX | |
| | | |
| +------------------------------+ |
| | |
| v Final Binding |
| +--------------+ |
| | Binding | |
| | | |
| | Table | |
| +--------------+ |
| |
+--------------------------------------------------------+
Figure 1: SAVI-MIX Architecture
图1:SAVI-MIX体系结构
Each entry in the binding table will contain the following fields:
绑定表中的每个条目将包含以下字段：
1. IP source address
1. IP源地址
2. Binding anchor [RFC7039]
2. 绑定锚[RFC7039]
3. Lifetime
3. 一生
4. Creation time
4. 创建时间
5. Binding methods: the SAVI method used for this entry
5. 绑定方法：用于此项的SAVI方法
If each address assignment technique uses a separate portion of the IP address space, collisions won't happen. Using non-overlapping address space across address assignment techniques, and thus across SAVI methods, is therefore recommended. To that end, one should:
如果每个地址分配技术使用IP地址空间的单独部分，则不会发生冲突。因此，建议跨地址分配技术以及跨SAVI方法使用非重叠地址空间。为此，应：
1. DHCP and SLAAC: use a non-overlapping prefix for DHCP and SLAAC. Set the A bit in the Prefix Information option of the Router Advertisement for the SLAAC prefix, and set the M bit in the Router Advertisement for the DHCP prefix. For detailed explanations of these bits, refer to [RFC4861] and [RFC4862].
1. DHCP和SLAAC：为DHCP和SLAAC使用不重叠的前缀。在路由器公告的前缀信息选项中为SLAAC前缀设置A位，并在路由器公告中为DHCP前缀设置M位。有关这些位的详细说明，请参阅[RFC4861]和[RFC4862]。
2. SEND and non-SEND: avoid mixed environments (where SEND and non-SEND nodes are deployed) or separate the prefixes announced to SEND and non-SEND nodes. One way to separate the prefixes is to have the router(s) announcing different (non-overlapping) prefixes to SEND and to non-SEND nodes, using unicast Router Advertisements [RFC6085], in response to SEND/non-SEND Router Solicit.
2. 发送和非发送：避免混合环境（在部署发送和非发送节点的环境中），或将宣布发送和非发送节点的前缀分开。分离前缀的一种方法是让路由器使用单播路由器广告[RFC6085]来通知要发送和非发送节点的不同（非重叠）前缀，以响应发送/非发送路由器请求。
In situations where collisions cannot be avoided by assignment separation, two cases should be considered:
在分配分离无法避免冲突的情况下，应考虑两种情况：
1. The same address is bound on two different binding anchors by different SAVI methods.
1. 同一地址通过不同的SAVI方法绑定到两个不同的绑定锚上。
2. The same address is bound on the same binding anchor by different SAVI methods.
2. 同一地址通过不同的SAVI方法绑定到同一绑定锚上。
This would typically occur if assignment address spaces could not be separated. For instance, an address is assigned by SLAAC on node X, installed in the binding table using FCFS SAVI, and anchored to "anchor-X". Later, the same address is assigned by DHCP to node Y, and SAVI-DHCP will generate a candidate binding entry, anchored to "anchor-Y".
如果无法分隔分配地址空间，则通常会发生这种情况。例如，地址由SLAAC在节点X上分配，使用FCFS SAVI安装在绑定表中，并锚定到“anchor-X”。稍后，DHCP将相同的地址分配给节点Y，SAVI-DHCP将生成一个候选绑定条目，锚定到“anchor-Y”。
If there is any manually configured binding, the SAVI device SHOULD choose the manually configured binding anchor.
如果存在任何手动配置的绑定，SAVI设备应选择手动配置的绑定锚。
For an address not covered by any manual bindings, the SAVI device must decide to which binding anchor the address should be bound (anchor-X or anchor-Y in this example). Current standard documents of address assignment methods have implied the prioritization relationship based on order in time, i.e., First-Come, First-Served.
对于未被任何手动绑定覆盖的地址，SAVI设备必须决定该地址应绑定到哪个绑定锚（本例中为锚-X或锚-Y）。当前地址分配方法的标准文件暗示了基于时间顺序的优先级关系，即先到先得。
o SLAAC: Section 5.4.5 of [RFC4862]
o SLAAC:RFC4862第5.4.5节
o DHCPv4: Section 3.1, Point 5 of [RFC2131]
o DHCPv4:RFC2131第3.1节第5点
o DHCPv6: Section 18.1.8 of [RFC3315]
o DHCPv6:RFC3315第18.1.8节
o SEND: Section 8 of [RFC3971]
o 发送：第8节[RFC3971]
In the absence of any configuration or protocol hint (see Section 6.1.2), the SAVI device SHOULD choose the first-come binding anchor, whether it was learned from SLAAC, SEND, or DHCP.
在没有任何配置或协议提示的情况下（见第6.1.2节），SAVI设备应选择先到绑定锚，无论它是从SLAAC、SEND还是DHCP学习的。
There are two identified exceptions to the general prioritization model, one being Cryptographically Generated Addresses (CGA) [RFC3971] and the other controlled by the configuration of the switch.
一般优先级模型有两个确定的例外，一个是加密生成地址（CGA）[RFC3971]，另一个由交换机的配置控制。
When CGA addresses are used and a collision is detected, preference should be given to the anchor that carries the CGA credentials once they are verified, in particular, the CGA parameters and the RSA options. Note that if an attacker was trying to replay CGA credentials, he would then compete on the base of the "First-Come, First-Served" (FCFS) principle.
当使用CGA地址并检测到冲突时，应优先考虑在验证CGA凭据后承载CGA凭据的锚，特别是CGA参数和RSA选项。请注意，如果攻击者试图重播CGA凭据，他将根据“先到先得”（FCFS）原则进行竞争。
For configuration-driven exceptions, the SAVI device may allow the configuration of a triplet ("prefix", "anchor", "method") or ("address", "anchor", "method"). The "prefix" or "address" represents the address or address prefix to which this preference entry applies. The "anchor" is the value of a known binding anchor that this device expects to see using this address or addresses from this prefix. The "method" is the SAVI method that this device
对于配置驱动的异常，SAVI设备可允许配置三元组（“前缀”、“锚定”、“方法”）或（“地址”、“锚定”、“方法”）。“前缀”或“地址”表示此首选项适用的地址或地址前缀。“锚定”是一个已知绑定锚定的值，该设备希望使用此地址或来自此前缀的地址看到该绑定锚定。“方法”是指该设备使用的SAVI方法
expects to use in validating address binding entries from the address or prefix. At least one of "anchor" and "method" MUST be specified. Later, if a Duplicate Address Detection (DAD) message [RFC4861] is received with the following conditions verified:
用于验证地址或前缀中的地址绑定条目。必须至少指定“锚定”和“方法”中的一种。稍后，如果接收到重复地址检测（DAD）消息[RFC4861]，并验证以下条件：
1. The target in the DAD message does not exist in the binding table,
1. 绑定表中不存在DAD消息中的目标，
2. The target is within the configured "prefix" (or equal to "address"),
2. 目标在配置的“前缀”内（或等于“地址”），
3. The anchor bound to the target is different from the configured anchor, when specified, and
3. 当指定时，绑定到目标的锚与配置的锚不同，并且
4. The configured method, if any, is different from FCFS SAVI,
4. 配置的方法（如果有）不同于FCFS SAVI，
then the switch SHOULD defend the address by responding to the DAD message, with a Neighbor Advertisement (NA) message, on behalf of the target node. It SHOULD NOT install the entry into the binding table. The DAD message SHOULD be discarded and not forwarded. Forwarding it may cause other SAVI devices to send additional defense NAs. SEND nodes in the network MUST disable the option to ignore unsecured advertisements (see Section 8 of [RFC3971]). If the option is enabled, the case is outside the scope of this document. It is suggested to limit the rate of defense NAs to reduce security threats to the switch. Otherwise, a malicious host could consume the resource of the switch heavily with flooding DAD messages.
然后，交换机应代表目标节点响应DAD消息，并使用邻居公告（NA）消息来保护地址。它不应该将条目安装到绑定表中。应该丢弃DAD消息，而不是转发该消息。转发它可能会导致其他SAVI设备发送额外的防御NAs。网络中的发送节点必须禁用忽略不安全播发的选项（请参阅[RFC3971]第8节）。如果启用该选项，则案例不在本文档范围内。建议限制防御NAs的速率，以减少对交换机的安全威胁。否则，恶意主机可能会通过泛滥的DAD消息严重消耗交换机的资源。
This will simply prevent the node from assigning the address and will de facto prioritize the configured anchor. It is especially useful to protect well-known bindings (such as a static address of a server) against any other host, even when the server is down. It is also a way to give priority to a binding learned from SAVI-DHCP over a binding for the same address, learned from FCFS SAVI.
这将简单地阻止节点分配地址，并且事实上会对配置的锚点进行优先级排序。保护已知绑定（例如服务器的静态地址）免受任何其他主机的攻击尤其有用，即使在服务器关闭时也是如此。这也是一种将从SAVI-DHCP学习的绑定优先于从FCFS SAVI学习的相同地址的绑定的方法。
A single SAVI device doesn't have the information of all bound addresses on the perimeter. Therefore, it is not enough to look up local bindings to identify a collision. However, assuming DAD is performed throughout the security perimeter for all addresses regardless of the assignment method, then the DAD response will inform all SAVI devices about any collision. In that case, "First-Come, First-Served" will apply the same way as in a single switch scenario. If the admin configured a prefix (or a single static binding) on one of the switches to defend, the DAD response generated by this switch will also prevent the binding from being installed on
单个SAVI设备不具备周界上所有绑定地址的信息。因此，仅查找本地绑定来识别冲突是不够的。但是，假设在整个安全范围内对所有地址执行DAD，而不考虑分配方法，则DAD响应将通知所有SAVI设备任何冲突。在这种情况下，“先到先得”的应用方式与单交换机场景中的应用方式相同。如果管理员在其中一个交换机上配置了前缀（或单个静态绑定）进行防御，则此交换机生成的DAD响应也将阻止在上安装绑定
other switches on the perimeter. The SAVI-MIX preferences of all the SAVI devices in the same layer 2 domain should be consistent. Inconsistent configurations may cause network breaks.
周边的其他开关。同一第2层域中所有SAVI设备的SAVI-MIX首选项应一致。配置不一致可能导致网络中断。
A binding may be set up on the same binding anchor by multiple methods, typically FCFS SAVI and SAVI-DHCP. If the binding lifetimes obtained from the two methods are different, priority should be given to 1) manual configuration, 2) SAVI-DHCP, 3) and FCFS SAVI as the least authoritative. The binding will be removed when the prioritized lifetime expires, even if a less authoritative method had a longer lifetime.
可以通过多种方法在同一绑定锚上设置绑定，通常是FCFS SAVI和SAVI-DHCP。如果从这两种方法获得的绑定生存期不同，则应优先考虑1）手动配置，2）SAVI-DHCP，3）和FCFS SAVI作为最不权威的。当优先生存期到期时，绑定将被删除，即使不太权威的方法的生存期更长。
Combining SAVI methods (as in SAVI-MIX) does not improve or eliminate the security considerations associated with each individual SAVI method. Therefore, security considerations for each enabled SAVI method should be addressed as described in that method's associated RFC. Moreover, combining methods (as in SAVI-MIX) has two additional implications for security. First, it may increase susceptibility to DoS attacks, because the SAVI binding setup rate will be the sum of the rates of all enabled SAVI methods. Implementers must take these added resource requirements into account. Second, because SAVI-MIX supports multiple binding mechanisms, it potentially reduces the security level to that of the weakest supported method, unless additional steps (e.g., requiring non-overlapping address spaces for different methods) are taken.
结合SAVI方法（如在SAVI-MIX中）不会改善或消除与每个SAVI方法相关的安全考虑。因此，每个启用的SAVI方法的安全注意事项应按照该方法的相关RFC中所述进行处理。此外，组合方法（如SAVI-MIX）对安全性还有两个额外的影响。首先，它可能会增加DoS攻击的易感性，因为SAVI绑定设置速率将是所有启用的SAVI方法的速率之和。实施者必须考虑这些增加的资源需求。其次，由于SAVI-MIX支持多种绑定机制，因此它可能会将安全级别降低到支持的最差方法的级别，除非采取其他步骤（例如，不同方法需要不重叠的地址空间）。
When implementing multiple SAVI methods, privacy considerations of all methods apply cumulatively.
在实现多个SAVI方法时，所有方法的隐私考虑因素都会累积应用。
This document does not require any IANA registrations.
本文件不需要任何IANA注册。
[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>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <http://www.rfc-editor.org/info/rfc3971>.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 3971，DOI 10.17487/RFC3971，2005年3月<http://www.rfc-editor.org/info/rfc3971>.
[RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, "Address Mapping of IPv6 Multicast Packets on Ethernet", RFC 6085, DOI 10.17487/RFC6085, January 2011, <http://www.rfc-editor.org/info/rfc6085>.
[RFC6085]Gundavelli，S.，Townsley，M.，Troan，O.，和W.Dec，“以太网上IPv6多播数据包的地址映射”，RFC 6085，DOI 10.17487/RFC6085，2011年1月<http://www.rfc-editor.org/info/rfc6085>.
[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>.
[RFC7219] Bagnulo, M. and A. Garcia-Martinez, "SEcure Neighbor Discovery (SEND) Source Address Validation Improvement (SAVI)", RFC 7219, DOI 10.17487/RFC7219, May 2014, <http://www.rfc-editor.org/info/rfc7219>.
[RFC7219]Bagnulo，M.和A.Garcia Martinez，“安全邻居发现（发送）源地址验证改进（SAVI）”，RFC 7219，DOI 10.17487/RFC7219，2014年5月<http://www.rfc-editor.org/info/rfc7219>.
[RFC7513] Bi, J., Wu, J., Yao, G., and F. Baker, "Source Address Validation Improvement (SAVI) Solution for DHCP", RFC 7513, DOI 10.17487/RFC7513, May 2015, <http://www.rfc-editor.org/info/rfc7513>.
[RFC7513]Bi，J.，Wu，J.，Yao，G.，和F.Baker，“DHCP源地址验证改进（SAVI）解决方案”，RFC 7513，DOI 10.17487/RFC7513，2015年5月<http://www.rfc-editor.org/info/rfc7513>.
[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>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[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>.
Acknowledgments
致谢
Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun, David Lamparter, Scott G. Kelly, and Jari Arkko for their valuable contributions.
感谢Christian Vogt、Eric Nordmark、Marcelo Bagnulo Braun、David Lamparter、Scott G.Kelly和Jari Arkko的宝贵贡献。
Authors' Addresses
作者地址
Jun Bi Tsinghua University Institute for Network Sciences and Cyberspace, Tsinghua University Beijing 100084 China
清华大学网络科学与网络空间研究所，清华大学北京100084
Email: junbi@tsinghua.edu.cn
Email: junbi@tsinghua.edu.cn
Guang Yao Tsinghua University/Baidu Baidu Science and Technology Park, Building 1 Beijing 100193 China
光耀清华大学/百度科技园，中国北京100193号楼1号楼
Email: yaoguang.china@gmail.com
Email: yaoguang.china@gmail.com
Joel M. Halpern Ericsson
乔尔·M·哈珀·爱立信
Email: joel.halpern@ericsson.com
Email: joel.halpern@ericsson.com
Eric Levy-Abegnoli (editor) Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot-Sophia Antipolis 06410 France
Eric Levy Abegnoli（编辑）思科系统公司绿边村-法国索菲亚安提波利斯市鲁马尼尔大道400号，邮编：06410
Email: elevyabe@cisco.com
Email: elevyabe@cisco.com