Internet Engineering Task Force (IETF) J. Wu
Request for Comments: 7039 J. Bi
Category: Informational Tsinghua Univ.
ISSN: 2070-1721 M. Bagnulo
UC3M
F. Baker
Cisco
C. Vogt, Ed.
October 2013
Internet Engineering Task Force (IETF) J. Wu
Request for Comments: 7039 J. Bi
Category: Informational Tsinghua Univ.
ISSN: 2070-1721 M. Bagnulo
UC3M
F. Baker
Cisco
C. Vogt, Ed.
October 2013
Source Address Validation Improvement (SAVI) Framework
源地址验证改进（SAVI）框架
Abstract
摘要
Source Address Validation Improvement (SAVI) methods were developed to prevent nodes attached to the same IP link from spoofing each other's IP addresses, so as to complement ingress filtering with finer-grained, standardized IP source address validation. This document is a framework document that describes and motivates the design of the SAVI methods. Particular SAVI methods are described in other documents.
开发了源地址验证改进（SAVI）方法，以防止连接到同一IP链路的节点欺骗彼此的IP地址，从而用更细粒度、标准化的IP源地址验证来补充入口过滤。本文档是一个框架文档，描述并激励SAVI方法的设计。其他文件中描述了特定的SAVI方法。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7039.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7039.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Options . . . . . . . . . . . . . . . . . . . . . 5
3.1. IP Address Assignment Methods . . . . . . . . . . . . . . 6
3.2. Binding Anchors . . . . . . . . . . . . . . . . . . . . . 6
4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 7
5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 9
6. Scenario with Multiple Assignment Methods . . . . . . . . . . 10
7. Prefix Configuration . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Deployment Options . . . . . . . . . . . . . . . . . . . . . 5
3.1. IP Address Assignment Methods . . . . . . . . . . . . . . 6
3.2. Binding Anchors . . . . . . . . . . . . . . . . . . . . . 6
4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 7
5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 9
6. Scenario with Multiple Assignment Methods . . . . . . . . . . 10
7. Prefix Configuration . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Since IP source addresses are used by hosts and network entities to determine the origin of a packet and as a destination for return data, spoofing of IP source addresses can enable impersonation, concealment, and malicious traffic redirection. Unfortunately, the Internet architecture does not prevent IP source address spoofing [RFC6959]. Since the IP source address of a packet generally takes no role in forwarding the packet, it can be selected arbitrarily by the sending host without jeopardizing packet delivery. Extra methods are necessary for IP source address validation to augment packet forwarding with an explicit check of whether a given packet's IP source address is legitimate.
由于主机和网络实体使用IP源地址来确定数据包的来源以及作为返回数据的目的地，因此IP源地址的欺骗可以实现模拟、隐藏和恶意流量重定向。不幸的是，互联网体系结构不能防止IP源地址欺骗[RFC6959]。由于数据包的IP源地址通常在转发数据包时不起作用，因此发送主机可以任意选择它，而不会影响数据包的交付。IP源地址验证需要额外的方法，通过显式检查给定数据包的IP源地址是否合法来增强数据包转发。
IP source address validation can happen at different granularity. Ingress filtering [BCP38] [BCP84], a widely deployed standard for IP source address validation, functions at the coarse granularity of networks. It verifies that the prefix of an IP source address routes to the network from which the packet was received. An advantage of ingress filtering is simplicity: the decision of whether to accept or to reject an IP source address can be made solely based on the information available from routing protocols. However, the simplicity comes at the cost of not being able to validate IP source addresses at a finer granularity, due to the aggregated nature of the information available from routing protocols. Finer-grained IP source address validation would ensure that source address information is accurate, reduce the ability to launch denial-of-service attacks, and help with localizing hosts and identifying misbehaving hosts. Partial solutions [BA2007] exist for finer-grained IP source address validation but are proprietary and hence often unsuitable for corporate procurement.
IP源地址验证可以在不同的粒度上进行。入口过滤[BCP38][BCP84]，一种广泛部署的IP源地址验证标准，在网络的粗粒度上运行。它验证IP源地址的前缀是否路由到接收数据包的网络。入口过滤的一个优点是简单：可以仅根据路由协议提供的信息来决定是否接受或拒绝IP源地址。然而，由于路由协议中可用信息的聚合性质，这种简单性的代价是无法以更精细的粒度验证IP源地址。更细粒度的IP源地址验证将确保源地址信息准确，降低发起拒绝服务攻击的能力，并有助于定位主机和识别行为异常的主机。部分解决方案[BA2007]用于更细粒度的IP源地址验证，但属于专有解决方案，因此通常不适合公司采购。
The Source Address Validation Improvement (SAVI) method was developed to complement ingress filtering with standardized IP source address validation at the maximally fine granularity of individual IP addresses. It prevents hosts attached to the same link from spoofing each other's IP addresses. To facilitate deployment in networks of various kinds, the SAVI method was designed to be modular and extensible. This document describes and motivates the design of the SAVI method.
源地址验证改进（SAVI）方法的开发是为了在单个IP地址的最大细粒度下，通过标准化IP源地址验证来补充入口过滤。它防止连接到同一链路的主机欺骗彼此的IP地址。为了便于在各种网络中部署，SAVI方法被设计为模块化和可扩展的。本文件描述并激励了SAVI方法的设计。
Note that SAVI raises a number of important privacy considerations that are discussed more fully in [RFC6959]. SAVI implementers must take those privacy considerations into account when designing solutions that match this framework and follow the recommendations given in [RFC6959].
请注意，SAVI提出了许多重要的隐私注意事项，这些事项在[RFC6959]中进行了更全面的讨论。SAVI实施者在设计与此框架相匹配的解决方案时，必须考虑这些隐私因素，并遵循[RFC6959]中给出的建议。
To enable network operators to deploy fine-grained IP source address validation without a dependency on supportive functionality on hosts, the SAVI method was designed to be purely network based. A SAVI instance enforces the hosts' use of legitimate IP source addresses according to the following three-step model:
为了使网络运营商能够部署细粒度IP源地址验证，而不依赖于主机上的支持功能，SAVI方法被设计为完全基于网络的。SAVI实例根据以下三步模型强制主机使用合法的IP源地址：
1. Identify which IP source addresses are legitimate for a host, based on monitoring packets exchanged by the host.
1. 根据主机交换的监控数据包，确定哪些IP源地址对于主机是合法的。
2. Bind a legitimate IP address to a link-layer property of the host's network attachment. This property, called a "binding anchor", must be verifiable in every packet that the host sends and harder to spoof than the host's IP source address itself.
2. 将合法IP地址绑定到主机网络附件的链路层属性。此属性称为“绑定锚”，必须在主机发送的每个数据包中都可验证，并且比主机的IP源地址本身更难欺骗。
3. Enforce that the IP source addresses in packets match the binding anchors to which they were bound.
3. 强制确保数据包中的IP源地址与它们绑定到的绑定锚匹配。
This model allows SAVI functionality (a SAVI instance) to be located anywhere on the link to which the hosts attach, hence enabling different locations for a SAVI instance. One way to locate a SAVI instance is in the hosts' default router. IP source addresses are then validated in packets traversing the default router, yet the IP source addresses in packets exchanged locally on the link may bypass validation. Another way to locate a SAVI instance is in a switch between the hosts and their default router. Thus, packets may undergo IP source address validation even if exchanged locally on the link.
此模型允许SAVI功能（SAVI实例）位于主机连接到的链路上的任何位置，从而为SAVI实例启用不同的位置。定位SAVI实例的一种方法是在主机的默认路由器中。然后在通过默认路由器的数据包中验证IP源地址，然而在链路上本地交换的数据包中的IP源地址可能会绕过验证。另一种定位SAVI实例的方法是在主机与其默认路由器之间的交换机中。因此，即使在链路上本地交换数据包，也可以进行IP源地址验证。
The closer a SAVI instance is located to the host, the more effective the SAVI method is. This is because each of the three steps of the SAVI model can best be accomplished in a position close to the host:
SAVI实例越靠近主机，SAVI方法就越有效。这是因为SAVI模型的三个步骤中的每一个都可以在靠近主机的位置完成：
o Identifying a host's legitimate IP source addresses is most efficient close to the host because the likelihood that the host's packets bypass a SAVI instance, and hence cannot be monitored, increases with the topological distance between the SAVI instance and the host.
o 识别主机的合法IP源地址在靠近主机时最有效，因为主机的数据包绕过SAVI实例从而无法被监控的可能性随着SAVI实例与主机之间的拓扑距离而增加。
o Selecting a binding anchor for a host's IP source address is easiest close to the host because many link-layer properties are unique for a given host only on a link segment directly attached to the host.
o 为主机的IP源地址选择绑定锚最容易接近主机，因为许多链路层属性对于给定主机来说是唯一的，仅在直接连接到主机的链路段上。
o Enforcing a host's use of a legitimate IP source address is most reliable when pursued close to the host because the likelihood that the host's packets bypass a SAVI instance, and hence do not undergo IP source address validation, increases with the topological distance between the SAVI instance and the host.
o 当靠近主机时，强制主机使用合法的IP源地址是最可靠的，因为主机的数据包绕过SAVI实例，因此不进行IP源地址验证的可能性随着SAVI实例与主机之间的拓扑距离而增加。
The preferred location of SAVI instances is therefore close to hosts, such as in switches that directly attach to the hosts whose IP source addresses are being validated.
因此，SAVI实例的首选位置靠近主机，例如在直接连接到其IP源地址正在验证的主机的交换机中。
Nevertheless, it is useful for SAVI mechanisms to be able to handle situations where hosts are not directly attached to the SAVI-capable device. For instance, deployments with both SAVI-capable and legacy switches could be supported. In general, a SAVI solution needs to specify how it deals with a number of deployment scenarios and exceptional situations, including interaction with legacy devices, hosts moving between wireless attachment points, network partitions, and so on.
然而，SAVI机制能够处理主机未直接连接到支持SAVI的设备的情况是有用的。例如，可以支持同时使用支持SAVI和传统交换机的部署。通常，SAVI解决方案需要指定如何处理许多部署场景和异常情况，包括与传统设备的交互、在无线连接点之间移动的主机、网络分区等。
Besides, in the case of legacy switches, the security level is lower, as there is no full protection for the hosts connected to the legacy server.
此外，对于旧式交换机，安全级别较低，因为连接到旧式服务器的主机没有完全保护。
The model of the SAVI method, as explained in Section 2, is deployment specific in two ways:
如第2节所述，SAVI方法的模型在两个方面是特定于部署的：
o The identification of legitimate IP source addresses is dependent on the IP address assignment method in use on a link, since it is through assignment that a host becomes the legitimate user of an IP source address.
o 合法IP源地址的标识取决于链路上使用的IP地址分配方法，因为主机通过分配成为IP源地址的合法用户。
o Binding anchors are dependent on the technology used to build the link on which they are used, as binding anchors are link-layer properties of a host's network attachment.
o 绑定锚取决于用于构建使用它们的链接的技术，因为绑定锚是主机网络附件的链接层属性。
To facilitate the deployment of the SAVI method in networks of various kinds, the SAVI method is designed to support different IP address assignment methods and to function with different binding anchors. Naturally, both the IP address assignment methods in use on a link and the available binding anchors have an impact on the functioning and the strength of IP source address validation. The following two subsections explain this impact and describe how the SAVI method accommodates this.
为了便于在各种网络中部署SAVI方法，SAVI方法被设计为支持不同的IP地址分配方法，并与不同的绑定锚一起工作。当然，链路上使用的IP地址分配方法和可用的绑定锚都会对IP源地址验证的功能和强度产生影响。以下两小节解释了这种影响，并描述了SAVI方法如何适应这种影响。
Since the SAVI method traces IP address assignment packets, it necessarily needs to incorporate logic that is specific to particular IP address assignment methods. However, developing SAVI method variants for each IP address assignment method is alone not sufficient since multiple IP address assignment methods may coexist on a given link. The SAVI method hence comes in multiple variants, e.g., for links with DHCP [RFC2131] [RFC3315], Stateless Address Autoconfiguration (SLAAC) [RFC4862] with or without Secure Neighbor Discovery (SEND) [RFC3971], Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5996] [RFC5739] [RFC5026], and combinations thereof.
由于SAVI方法跟踪IP地址分配数据包，因此它必须包含特定于特定IP地址分配方法的逻辑。但是，仅为每个IP地址分配方法开发SAVI方法变体是不够的，因为在给定链路上可能同时存在多个IP地址分配方法。因此，SAVI方法有多种变体，例如，用于与DHCP[RFC2131][RFC3315]的链路、具有或不具有安全邻居发现（SEND）[RFC3971]的无状态地址自动配置（SLAAC）[RFC4862]、因特网密钥交换协议版本2（IKEv2）[RFC5996][RFC5739][RFC5026]及其组合。
The reason to develop SAVI method variants for each single IP address configuration method, in addition to the variant that handles all IP address assignment methods, is to minimize the complexity of the common case. Many link deployments today either are constrained to a single IP address assignment method or, equivalently from the perspective of the SAVI method, use different IP address assignment methods within different IP address prefixes. The SAVI method for such links can be simpler than the SAVI method for links with multiple IP address assignment methods per IP address prefix.
除了处理所有IP地址分配方法的变体之外，为每个单一IP地址配置方法开发SAVI方法变体的原因是为了最小化常见情况的复杂性。今天的许多链路部署要么局限于单个IP地址分配方法，要么从SAVI方法的角度来看，在不同的IP地址前缀中使用不同的IP地址分配方法。针对此类链路的SAVI方法可以比针对每个IP地址前缀具有多个IP地址分配方法的链路的SAVI方法更简单。
The SAVI method supports a range of binding anchors:
SAVI方法支持一系列绑定锚定：
o The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's interface.
o 主机接口的IEEE扩展唯一标识符EUI-48或EUI-64。
o The port on an Ethernet switch to which a host attaches.
o 以太网交换机上主机连接的端口。
o The security association between a host and the base station on wireless links.
o 在无线链路上主机和基站之间的安全关联。
o The combination of a host interface's link-layer address and a customer relationship in cable modem networks.
o 在有线调制解调器网络中，主机接口的链路层地址和客户关系的组合。
o An ATM virtual channel, a PPP session identifier, or a Layer 2 Tunneling Protocol (L2TP) session identifier in a DSL network.
o DSL网络中的ATM虚拟信道、PPP会话标识符或第二层隧道协议（L2TP）会话标识符。
o A tunnel that connects to a single host, such as an IP-in-IP tunnel, a Generic Routing Encapsulation (GRE) tunnel, or an MPLS label-switched path.
o 连接到单个主机的隧道，例如IP-in-IP隧道、通用路由封装（GRE）隧道或MPLS标签交换路径。
The various binding anchors differ significantly in the security they provide. IEEE extended unique identifiers, for example, fail to render a secure binding anchor because they can be spoofed with little effort. Switch ports alone may be insufficient because they may connect to more than a single host, such as in the case of concatenated switches.
不同的绑定锚在提供的安全性方面存在显著差异。例如，IEEE扩展的唯一标识符无法呈现安全绑定锚，因为它们可以被轻易伪造。交换机端口本身可能不够，因为它们可能连接到多个主机，例如在级联交换机的情况下。
Given this diversity in the security provided, one could define a set of possible binding anchors and leave it up to the administrator to choose one or more of them. Such a selection of binding anchors would, of course, have to be accompanied by an explanation of the pros and cons of the different binding anchors. In addition, SAVI devices may have a default binding anchor depending on the lower layers. Such a default could be to use switch ports when available and MAC addresses otherwise or to use MAC addresses and switch ports in addition if available.
鉴于所提供的安全性的多样性，可以定义一组可能的绑定锚，并由管理员选择其中的一个或多个。当然，选择这样的绑定锚必须同时解释不同绑定锚的优缺点。此外，根据较低层，SAVI设备可能具有默认绑定锚。默认情况下，可以在可用时使用交换机端口，否则使用MAC地址，或者在可用时另外使用MAC地址和交换机端口。
The preference to locate a SAVI instance close to hosts implies that multiple SAVI instances must be able to coexist in order to support large links. Although the model of the SAVI method is independent of the number of SAVI instances per link, coexistence of multiple SAVI instances without further measures can lead to higher-than-necessary memory requirements. Since a SAVI instance creates bindings for the IP source addresses of all hosts on a link, bindings are replicated if multiple SAVI instances coexist on the link. High memory requirements, in turn, increase the cost of a SAVI instance. This is problematic in particular for SAVI instances that are located on a switch since it may significantly increase the cost of such a switch.
首选将SAVI实例定位在主机附近，这意味着多个SAVI实例必须能够共存，才能支持大型链接。尽管SAVI方法的模型与每条链路的SAVI实例数量无关，但如果多个SAVI实例共存而不采取进一步措施，则可能会导致超出必要的内存需求。由于SAVI实例为链路上所有主机的IP源地址创建绑定，因此如果链路上同时存在多个SAVI实例，则会复制绑定。高内存需求反过来会增加SAVI实例的成本。这尤其对于位于交换机上的SAVI实例是有问题的，因为它可能会显著增加此类交换机的成本。
To reduce memory requirements for SAVI instances that are located on a switch, the SAVI method enables the suppression of binding replication on links with multiple SAVI instances. This requires manual disabling of IP source address validation on switch ports that connect to other switches running a SAVI instance. Each SAVI instance is then responsible for validating IP source addresses only on those ports to which hosts attach either directly or via switches without a SAVI instance. On ports towards other switches running a SAVI instance, IP source addresses are not validated. The switches running SAVI instances thus form a "protection perimeter". The IP source addresses in packets passing the protection perimeter are validated by the ingress SAVI instance, but no further validation takes place as long as the packets remain within or leave the protection perimeter.
为了减少位于交换机上的SAVI实例的内存需求，SAVI方法可以抑制具有多个SAVI实例的链路上的绑定复制。这需要在连接到运行SAVI实例的其他交换机的交换机端口上手动禁用IP源地址验证。然后，每个SAVI实例只负责验证主机直接连接或通过没有SAVI实例的交换机连接到的端口上的IP源地址。在指向运行SAVI实例的其他交换机的端口上，不会验证IP源地址。因此，运行SAVI实例的交换机形成了“保护周界”。通过保护周界的数据包中的IP源地址由ingress SAVI实例验证，但只要数据包保持在保护周界内或离开保护周界，就不会进行进一步的验证。
..............
protection perimeter --> : +--------+ :
+---+ +---+ : | SAVI | :
| A | | B | <-- hosts : | switch | :
+---+ +---+ : +--------+ :
...|......|.............................: | :
: +--------+ +--------+ +--------+ :
: | SAVI |----------| legacy | | SAVI | :
: | switch | | switch |----------| switch | :
: +--------+ +--------+ +--------+ :
: | ...............................|........:
: +--------+ : +--------+
: | SAVI | : | legacy |
: | switch | : | switch |
: +--------+ : +--------+
:............: | |
+---+ +---+
hosts --> | C | | D |
+---+ +---+
..............
protection perimeter --> : +--------+ :
+---+ +---+ : | SAVI | :
| A | | B | <-- hosts : | switch | :
+---+ +---+ : +--------+ :
...|......|.............................: | :
: +--------+ +--------+ +--------+ :
: | SAVI |----------| legacy | | SAVI | :
: | switch | | switch |----------| switch | :
: +--------+ +--------+ +--------+ :
: | ...............................|........:
: +--------+ : +--------+
: | SAVI | : | legacy |
: | switch | : | switch |
: +--------+ : +--------+
:............: | |
+---+ +---+
hosts --> | C | | D |
+---+ +---+
Figure 1: Protection Perimeter Concept
图1：保护周界概念
Figure 1 illustrates the concept of the protection perimeter. The figure shows a link with six switches, of which four, denoted "SAVI switch", run a SAVI instance. The protection perimeter created by the four SAVI instances is shown as a dotted line in the figure. IP source address validation is enabled on all switch ports on the protection perimeter, and it is disabled on all other switch ports. Four hosts, denoted A through D in the figure, attach to the protection perimeter.
图1说明了保护周界的概念。该图显示了具有六个交换机的链路，其中四个表示为“SAVI交换机”，运行SAVI实例。由四个SAVI实例创建的保护周界如图中的虚线所示。IP源地址验证在保护周界上的所有交换机端口上启用，在所有其他交换机端口上禁用。图中表示为A到D的四台主机连接到保护周界。
In the example in Figure 1, the protection perimeter encompasses one of the legacy switches, located in the middle of the depicted link topology. This enables a single, unpartitioned protection perimeter. A single protection perimeter minimizes memory requirements for the SAVI instances because every binding is kept only once, namely, by the SAVI instance that attaches to the host being validated. Excluding the legacy switch from the protection perimeter would result in two smaller protection perimeters to the left and to the right of the depicted link topology. The memory requirements for the SAVI instances would then be higher: since IP source address validation would be activated on the two ports connecting to the legacy switch, the SAVI instances adjacent to the legacy switch would replicate all bindings from the other protection perimeter, respectively. The reason why it is possible to include the legacy switch in the protection perimeter is because the depicted link topology guarantees that packets cannot enter the protection perimeter via this legacy switch. Without this guarantee, the legacy
在图1中的示例中，保护周界包含位于所描述的链路拓扑的中间的传统交换机之一。这将启用单一的、无分区的保护周界。单个保护周界可最大限度地减少SAVI实例的内存需求，因为每个绑定只保留一次，即由连接到被验证主机的SAVI实例保留。从保护周界中排除传统交换机将导致所示链路拓扑左侧和右侧的两个较小的保护周界。SAVI实例的内存需求将更高：由于IP源地址验证将在连接到旧交换机的两个端口上激活，因此与旧交换机相邻的SAVI实例将分别复制来自其他保护周界的所有绑定。可以将传统交换机包括在保护周界中的原因是，所描述的链路拓扑保证数据包不能通过该传统交换机进入保护周界。没有这一保证，遗产
switch would have to be excluded from the protection perimeter in order to ensure that packets entering the protection perimeter undergo IP source address validation.
必须将交换机从保护周界中排除，以确保进入保护周界的数据包经过IP源地址验证。
Note that if such configuration is used, care must be taken as any hosts on subnets attached to non-enforcing ports will be able to use spoofed source addresses.
注意，如果使用这种配置，必须小心，因为连接到非强制端口的子网上的任何主机都将能够使用伪造的源地址。
The explicit storage of legitimate IP addresses in the form of bindings implies that failure to create a binding, or the premature removal of bindings, can lead to loss of legitimate packets. There are three situations in which this can happen:
以绑定形式显式存储合法IP地址意味着未能创建绑定或过早删除绑定可能导致合法数据包丢失。有三种情况可能发生这种情况：
o Legitimate IP address configuration packets, which should trigger the creation of a binding in a SAVI instance, are lost before reaching the SAVI instance.
o 在到达SAVI实例之前，应触发在SAVI实例中创建绑定的合法IP地址配置数据包丢失。
o A SAVI instance loses a binding, for example, due to a restart.
o 例如，由于重新启动，SAVI实例会丢失绑定。
o The link topology changes, resulting in hosts to communicate through SAVI instances that do not have a binding for those hosts' IP addresses.
o 链路拓扑更改，导致主机通过SAVI实例进行通信，这些实例没有绑定这些主机的IP地址。
To limit the disruption that missing bindings for legitimate IP addresses can have, the SAVI method includes a mechanism for reactive binding creation based on regular packets. This mechanism supplements the proactive binding creation based on IP address configuration packets. Reactive binding creation occurs when a SAVI instance recognizes excessive drops of regular packets originating from the same IP address. The SAVI instance then verifies whether said IP address is unique on the link. How the verification is carried out depends on the IP address configuration method that the SAVI instance supports. The SAVI method variant for Stateless Address Autoconfiguration and for Secure Neighbor Discovery verifies an IP address through the Duplicate Address Detection procedure. The SAVI method variant for DHCP verifies an IP address through a DHCP Lease Query message exchange with the DHCP server. If verification indicates that the IP address is unique on the link, the SAVI instance creates a binding for the IP address. Otherwise, no binding is created, and packets sent from the IP address continue to be dropped. These reliability issues should be addressed in all the SAVI protocols describing particular SAVI methods.
为了限制合法IP地址丢失绑定可能造成的中断，SAVI方法包括一种基于常规数据包的反应式绑定创建机制。此机制补充了基于IP地址配置数据包的主动绑定创建。当SAVI实例识别来自同一IP地址的常规数据包的过多丢弃时，就会发生反应性绑定创建。然后，SAVI实例验证所述IP地址在链路上是否唯一。如何执行验证取决于SAVI实例支持的IP地址配置方法。无状态地址自动配置和安全邻居发现的SAVI方法变体通过重复地址检测过程验证IP地址。DHCP的SAVI方法变体通过与DHCP服务器交换DHCP租约查询消息来验证IP地址。如果验证表明该IP地址在链路上是唯一的，则SAVI实例将为该IP地址创建绑定。否则，不会创建绑定，从IP地址发送的数据包将继续被丢弃。这些可靠性问题应在描述特定SAVI方法的所有SAVI协议中解决。
While multiple assignment methods can be used on the same link, the SAVI device may have to deal with a mix of binding discovery methods. If the address prefix used for each assignment method is different, the "mix scenario" behaves the same as with the scenario with only one assignment method. If different address assignment methods are used to assign addresses from the same prefix, additional considerations are needed because one binding mechanism may create a binding violating an existing binding from another binding mechanism, e.g., binding from First-Come, First-Served (FCFS) SAVI [RFC6620] may violate a binding from SAVI-DHCP [SAVI-DHCP]. Thus, the collision between different SAVI mechanisms in the mix scenario must be handled in case more than one address assignment method is used to assign addresses from the same prefix.
虽然可以在同一链路上使用多个分配方法，但是SAVI设备可能必须处理绑定发现方法的混合。如果每个分配方法使用的地址前缀不同，“混合方案”的行为与只有一种分配方法的方案相同。如果使用不同的地址分配方法从同一前缀分配地址，则需要额外考虑，因为一个绑定机制可能会创建一个违反另一个绑定机制的现有绑定的绑定，例如，来自先到先服务（FCFS）的绑定SAVI[RFC6620]可能会违反来自SAVI-DHCP的绑定[SAVI-DHCP]。因此，如果使用多个地址分配方法从同一前缀分配地址，则必须处理混合场景中不同SAVI机制之间的冲突。
The prioritization of relationships between different address assignment methods is used as the basis to solve possible collisions. Current standard documents of address assignment methods (DHCP [RFC2131], DHCPv6 [RFC3315], SLAAC [RFC4862], and SEND [RFC3971]) have implied the prioritization relationship in general cases. However, in some scenarios, the default prioritization level may not be quite suitable. A configurable prioritization level should be supported in the SAVI solution for the mix scenario [SAVI-MIX].
不同地址分配方法之间关系的优先级被用作解决可能冲突的基础。当前的地址分配方法标准文件（DHCP[RFC2131]、DHCPv6[RFC3315]、SLAAC[RFC4862]和SEND[RFC3971]）暗示了一般情况下的优先级关系。但是，在某些情况下，默认优先级可能不太合适。混合方案的SAVI解决方案[SAVI-mix]应支持可配置的优先级级别。
Before setting up a host-level granularity binding, it is important to configure correct prefixes on the SAVI device. This document suggests a set of 3 prefix configuration mechanisms at a SAVI device:
在设置主机级粒度绑定之前，必须在SAVI设备上配置正确的前缀。本文件建议在SAVI设备上采用一组3种前缀配置机制：
o Manual Prefix Configuration: The allowed prefix scope of IPv4 addresses, IPv6 static addresses, IPv6 addresses assigned by Stateless Address Autoconfiguration (SLAAC), and IPv6 addresses assigned by DHCPv6 can be set manually at the SAVI device. FE80::/64 is always a feasible prefix in IPv6.
o 手动前缀配置：可以在SAVI设备上手动设置IPv4地址、IPv6静态地址、无状态地址自动配置（SLAAC）分配的IPv6地址和DHCPv6分配的IPv6地址的允许前缀范围。FE80:：/64在IPv6中始终是可行的前缀。
o Prefix Configuration by Router Advertisement (RA) Snooping: The allowed prefix scope of IPv6 static addresses and IPv6 addresses assigned by SLAAC can be set at the SAVI device through snooping an RA message at the SAVI device.
o 路由器广告（RA）窥探前缀配置：可以通过窥探SAVI设备上的RA消息在SAVI设备上设置IPv6静态地址和SLAAC分配的IPv6地址的允许前缀范围。
o Prefix Configuration by DHCP Prefix Delegation (DHCP-PD) Snooping: The allowed prefix scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC, and IPv6 addresses assigned by DHCPv6 can be set through snooping a DHCP-PD message at the SAVI device.
o 通过DHCP前缀委派（DHCP-PD）侦听进行前缀配置：可以通过在SAVI设备上侦听DHCP-PD消息来设置IPv6静态地址、SLAAC分配的IPv6地址和DHCPv6分配的IPv6地址的允许前缀范围。
If some of the prefix scopes are set to have no prefix, the implication is that the corresponding address assignment method is not allowed in the network.
如果某些前缀作用域被设置为没有前缀，则意味着网络中不允许使用相应的地址分配方法。
There is no need to explicitly present these prefix scopes, but these restrictions should be used as the premier check in binding setup.
不需要显式显示这些前缀作用域，但这些限制应用作首选签入绑定设置。
When SAVI is partially deployed, binding may fail as RA messages and DHCP-PD can be spoofed. So, it is recommended that Manual Prefix Configuration be used unless SAVI gets fully deployed.
当部分部署SAVI时，绑定可能会失败，因为RA消息和DHCP-PD可能被欺骗。因此，建议使用手动前缀配置，除非完全部署SAVI。
The authors would like to thank the SAVI working group for a thorough technical discussion on the design and the framework of the SAVI method as captured in this document, in particular Erik Nordmark, Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to Torben Melsen for reviewing this document.
作者要感谢SAVI工作组对本文件中所述SAVI方法的设计和框架进行了深入的技术讨论，特别是Erik Nordmark、Guang Yao、Eric Levy Abegnoli和Alberto Garcia。还感谢Torben Melsen审阅本文件。
This document only discusses the possible methods to mitigate the usage of forged IP addresses. Some such methods may rely on cryptographic methods, but not all do. As a result, it is generally not possible to prove address ownership in any strong sense. If a binding anchor is not exclusive for each IP address, or is without strong security, addresses can still be forged. Besides, the binding may not accord with the address management requirement, which can be more specified for each client. However, given no new protocol is introduced, the improvements are still acceptable. If strong security is required when using IP addresses, then cryptographic-based authentication must be used as it is the only way to provide strong security.
本文档仅讨论减少伪造IP地址使用的可能方法。有些方法可能依赖于加密方法，但并非所有方法都依赖于加密方法。因此，通常不可能在任何强烈意义上证明地址所有权。如果绑定锚对每个IP地址不是独占的，或者没有很强的安全性，则仍然可以伪造地址。此外，绑定可能不符合地址管理要求，可以针对每个客户端进行更多指定。然而，由于没有引入新的协议，改进仍然是可以接受的。如果在使用IP地址时需要强安全性，则必须使用基于加密的身份验证，因为这是提供强安全性的唯一方法。
Section 2 explains how the preferred location of SAVI instances is close to hosts. However, in some cases, this makes the SAVI instances themselves vulnerable and may defeat the purpose of deploying a SAVI solution. For instance, deployments should not place SAVI functionality in devices that are physically exposed. Even if the device correctly monitors the source address usage of hosts, an attacker could replace the device with one that does not check or hook up to a trusted interface from the device to the rest of the network. Similarly, deployments where SAVI instances are distributed across administrative boundaries are not recommended. For instance, in most cases, it would be undesirable to deploy a distributed SAVI solution on both sides of a customer-provider interface if the solution required trusting the correct operation of the SAVI devices on the other side of the interface.
第2节解释了SAVI实例的首选位置如何靠近主机。但是，在某些情况下，这会使SAVI实例本身易受攻击，并且可能会破坏部署SAVI解决方案的目的。例如，部署不应将SAVI功能放置在物理公开的设备中。即使该设备正确监控主机的源地址使用情况，攻击者也可以将该设备替换为不检查或连接到从该设备到网络其余部分的受信任接口的设备。类似地，不建议跨管理边界分布SAVI实例的部署。例如，在大多数情况下，如果解决方案需要信任接口另一侧的SAVI设备的正确操作，则不希望在客户-提供商接口的两侧部署分布式SAVI解决方案。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
[RFC5026]Giaretta，G.，Kempf，J.，和V.Devarapalli，“拆分场景中的移动IPv6引导”，RFC 5026，2007年10月。
[RFC5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, February 2010.
[RFC5739]Eronen，P.，Laganier，J.，和C.Madson，“互联网密钥交换协议版本2（IKEv2）中的IPv6配置”，RFC 5739，2010年2月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, May 2012.
[RFC6620]Nordmark，E.，Bagnulo，M.和E.Levy Abegnoli，“FCFS SAVI：本地分配IPv6地址的先到先得源地址验证改进”，RFC 6620，2012年5月。
[RFC6959] McPherson, D., Baker, F., and J. Halpern, "Source Address Validation Improvement (SAVI) Threat Scope", RFC 6959, May 2013.
[RFC6959]McPherson，D.，Baker，F.，和J.Halpern，“源地址验证改进（SAVI）威胁范围”，RFC 69592013年5月。
[BA2007] Baker, F., "Cisco IP Version 4 Source Guard", Work in Progress, November 2007.
[BA2007]Baker，F.，“Cisco IP版本4源代码保护”，正在进行的工作，2007年11月。
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[BCP38]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[BCP84]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[SAVI-DHCP] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for DHCP", Work in Progress, June 2013.
[SAVI-DHCP]Bi，J.，Wu，J.，Yao，G.，和F.Baker，“DHCP的SAVI解决方案”，正在进行的工作，2013年6月。
[SAVI-MIX] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI for Mixed Address Assignment Methods Scenario", Work in Progress, May 2013.
[SAVI-MIX]Bi，J.，Yao，G.，Halpern，J.，和E.Levy Abegnoli，“混合地址分配方法场景的SAVI”，正在进行的工作，2013年5月。
Authors' Addresses
作者地址
Jianping Wu Tsinghua University Computer Science, Tsinghua University Beijing 100084 China
吴建平清华大学计算机科学，清华大学北京100084
EMail: jianping@cernet.edu.cn
EMail: jianping@cernet.edu.cn
Jun Bi Tsinghua University Network Research Center, Tsinghua University Beijing 100084 China
清华大学网络研究中心，北京100084
EMail: junbi@tsinghua.edu.cn
EMail: junbi@tsinghua.edu.cn
Marcelo Bagnulo Universidad Carlos III de Madrid Avenida de la Universidad 30 Leganes, Madrid 28911 Spain
马塞洛·巴格鲁卡洛斯三世大学马德里大学大道30号，马德里28911西班牙
EMail: marcelo@it.uc3m.es
EMail: marcelo@it.uc3m.es
Fred Baker Cisco Systems Santa Barbara, CA 93117 United States
美国加利福尼亚州圣巴巴拉市弗雷德·贝克思科系统公司，邮编：93117
EMail: fred@cisco.com
EMail: fred@cisco.com
Christian Vogt (editor) 3507 Palmilla Drive San Jose, CA 95134 United States
克里斯蒂安·沃格特（编辑）美国加利福尼亚州圣何塞市帕尔米拉大道3507号，邮编95134
EMail: mail@christianvogt.net
EMail: mail@christianvogt.net