Network Working Group E. Rosen
Request for Comments: 4576 P. Psenak
Category: Standards Track P. Pillay-Esnault
Cisco Systems, Inc.
June 2006
Network Working Group E. Rosen
Request for Comments: 4576 P. Psenak
Category: Standards Track P. Pillay-Esnault
Cisco Systems, Inc.
June 2006
Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)
使用链路状态播发（LSA）选项位防止BGP/MPLS IP虚拟专用网络（VPN）中的循环
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it.
本文件规定了一个程序，用于处理服务提供商（SP）向客户提供“BGP/MPLS IP VPN”服务时可能出现的特定问题，客户使用OSPFv2向SP公布其路由。在这种情况下，客户边缘（CE）路由器和提供商边缘（PE）路由器是OSPF对等方，客户路由通过OSPFv2从CE发送到PE。客户路由转换为BGP路由，BGP将它们通过主干传输到其他PE路由器。然后，这些路由被转换回通过OSPF发送到其他CE路由器的OSPF路由。由于这种转换，防止循环所需的一些信息可能会丢失。需要一个过程来确保一旦路由从PE发送到CE，从CE接收路由的任何PE都将忽略该路由。本文件规定了必要的程序，使用LSA（链路状态播发）中的一个选项位指示LSA已由PE转发，任何其他看到它的PE都应忽略该LSA。
Table of Contents
目录
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Information Loss and Loops ......................................3
4. Using the LSA Options to Prevent Loops ..........................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................5
7. Normative References ............................................6
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Information Loss and Loops ......................................3
4. Using the LSA Options to Prevent Loops ..........................4
5. Security Considerations .........................................5
6. Acknowledgements ................................................5
7. Normative References ............................................6
[VPN] describes a method by which a Service Provider (SP) can use its IP backbone to provide an "IP VPN" service to customers. In that sort of service, a customer's edge devices (CE devices) are connected to the provider's edge routers (PE routers). Each CE device is in a single Virtual Private Network (VPN). Each PE device may attach to multiple CEs of the same or of different VPNs. A VPN thus consists of a set of "network segments" connected by the SP's backbone.
[VPN]描述了一种服务提供商（SP）可以使用其IP主干向客户提供“IP VPN”服务的方法。在这种服务中，客户的边缘设备（CE设备）连接到提供商的边缘路由器（PE路由器）。每个CE设备都位于单个虚拟专用网络（VPN）中。每个PE设备可以连接到相同或不同VPN的多个CE。因此，VPN由一组由SP主干连接的“网段”组成。
A CE exchanges routes with a PE, using a routing protocol to which the customer and the SP jointly agree. The PE runs that routing protocol's decision process (i.e., it performs the routing computation) to determine the set of IP address prefixes for which the following two conditions hold:
CE使用客户和SP共同同意的路由协议与PE交换路由。PE运行该路由协议的决策过程（即，它执行路由计算）以确定IP地址前缀集，其中以下两个条件适用：
- Each address prefix in the set can be reached via that CE.
- 集合中的每个地址前缀都可以通过该CE访问。
- The path from that CE to each such address prefix does NOT include the SP backbone (i.e., it does not include any PE routers).
- 从该CE到每个这样的地址前缀的路径不包括SP主干（即，它不包括任何PE路由器）。
The PE routers that attach to a particular VPN redistribute routes to these address prefixes into BGP, so that they can use BGP to distribute the VPN's routes to each other. BGP carries these routes in the "VPN-IPv4 address family", so that they are distinct from ordinary Internet routes. The VPN-IPv4 address family also extends the IP addresses on the left so that address prefixes from two different VPNs are always distinct to BGP, even if both VPNs use the same piece of the private RFC 1918 address space. Thus, routes from different VPNs can be carried by a single BGP instance and can be stored in a common BGP table without fear of conflict.
连接到特定VPN的PE路由器将这些地址前缀的路由重新分配到BGP中，以便它们可以使用BGP将VPN的路由分配给彼此。BGP在“VPN-IPv4地址系列”中承载这些路由，因此它们不同于普通互联网路由。VPN-IPv4地址系列还扩展了左侧的IP地址，以便来自两个不同VPN的地址前缀始终与BGP不同，即使两个VPN使用相同的专用RFC 1918地址空间。因此，来自不同VPN的路由可以由单个BGP实例承载，并且可以存储在公共BGP表中，而无需担心冲突。
If a PE router receives a particular VPN-IPv4 route via BGP, and if that PE is attached to a CE in the VPN to which the route belongs, then BGP's decision process may install that route in the BGP route table. If so, the PE translates the route back into an IP route and
如果PE路由器通过BGP接收特定的VPN-IPv4路由，并且如果该PE连接到该路由所属VPN中的CE，则BGP的决策过程可能会在BGP路由表中安装该路由。如果是这样，PE将路由转换回IP路由，然后
redistributes it to the routing protocol that is running on the link to that CE.
将其重新分发到该CE的链路上运行的路由协议。
This methodology provides a "peer model". CE routers peer with PE routers, but CE routers at different sites do not peer with each other.
这种方法提供了一种“对等模型”。CE路由器与PE路由器对等，但不同站点的CE路由器不相互对等。
If a VPN uses OSPFv2 as its internal routing protocol, it is not necessarily the case that the CE routers of that VPN use OSPFv2 to peer with the PE routers. Each site in a VPN can use OSPFv2 as its intra-site routing protocol while using BGP or RIP (for example) to distribute routes to a PE router. However, it is certainly convenient when OSPFv2 is being used intra-site to use it on the PE-CE link as well, and [VPN] explicitly allows this. In this case, a PE will run a separate instance of OSPFv2 for each VPN that is attached to the PE; the PE will in general have multiple VPN-specific OSPFv2 routing tables.
如果VPN使用OSPFv2作为其内部路由协议，则该VPN的CE路由器不一定使用OSPFv2与PE路由器对等。VPN中的每个站点都可以使用OSPFv2作为其站点内路由协议，同时使用BGP或RIP（例如）将路由分发到PE路由器。然而，当OSPFv2在站点内部使用时，在PE-CE链路上使用OSPFv2当然很方便，而且[VPN]明确允许这样做。在这种情况下，PE将为连接到PE的每个VPN运行单独的OSPFv2实例；PE通常会有多个特定于VPN的OSPFv2路由表。
When OSPFv2 is used on a PE-CE link that belongs to a particular VPN, the PE router must redistribute to that VPN's OSPFv2 instance certain routes that have been installed in the BGP routing table. Similarly, a PE router must redistribute to BGP routes that have been installed in the VPN-specific OSPF routing tables. Procedures for this are specified in [VPN-OSPF].
当在属于特定VPN的PE-CE链路上使用OSPFv2时，PE路由器必须将已安装在BGP路由表中的某些路由重新分配给该VPN的OSPFv2实例。同样，PE路由器必须重新分配到已安装在VPN特定OSPF路由表中的BGP路由。[VPN-OSPF]中规定了这方面的程序。
The routes that are redistributed from BGP to OSPFv2 are advertised in LSAs that are originated by the PE. The PE acts as an OSPF border router, advertising some of these routes in AS-external LSAs, and some in summary LSAs, as specified in [VPN-OSPF].
从BGP重新分配到OSPFv2的路由在PE发起的LSA中公布。PE充当OSPF边界路由器，按照[VPN-OSPF]中的规定，将这些路由中的一些作为外部LSA进行广告，将一些作为概要LSA进行广告。
Similarly, when a PE router receives an LSA from a CE router, it runs the OSPF routing computation. Any route that gets installed in the OSPF routing table must be translated into a VPN-IPv4 route and then redistributed into BGP. BGP will then distribute these routes to the other PE routers.
类似地，当PE路由器从CE路由器接收LSA时，它运行OSPF路由计算。任何安装在OSPF路由表中的路由都必须转换为VPN-IPv4路由，然后重新分发到BGP中。然后，BGP将这些路由分配给其他PE路由器。
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.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
A PE, say PE1, may learn a route to a particular VPN-IPv4 address prefix via BGP. This may cause it to generate a summary LSA or an AS-external LSA in which it reports that address prefix. This LSA may then be distributed to a particular CE, say CE1. The LSA may
PE，比如PE1，可以通过BGP学习到特定VPN-IPv4地址前缀的路由。这可能会导致它生成摘要LSA或AS外部LSA，并在其中报告该地址前缀。该LSA随后可被分发到特定CE，例如CE1。LSA可能会
then be distributed throughout a particular OSPF area, reaching another CE, say CE2. CE2 may then distribute the LSA to another PE, say PE2.
然后被分配到一个特定的OSPF区域，到达另一个CE，比如CE2。然后，CE2可以将LSA分配给另一个PE，例如PE2。
As stated in the previous section, PE2 must run the OSPF routing computation to determine whether a particular address prefix, reported in an LSA from CE2, is reachable from CE2 via a path that does not include any PE router. Unfortunately, there is no standard way to do this. The OSPFv2 LSAs do not necessarily carry the information needed to enable PE2 to determine that the path to address prefix X in a particular LSA from CE2 is actually a path that includes, say PE1. If PE2 then leaks X into BGP as a VPN-IPv4 route, then PE2 is violating one of the constraints for loop-freedom in BGP; viz., that routes learned from a particular BGP domain are not redistributed back into that BGP domain. This could cause a routing loop to be created.
如前一节所述，PE2必须运行OSPF路由计算，以确定从CE2的LSA中报告的特定地址前缀是否可通过不包括任何PE路由器的路径从CE2访问。不幸的是，没有标准的方法来做到这一点。OSPFv2 LSA不一定携带使PE2能够确定来自CE2的特定LSA中的地址前缀X的路径实际上是包括例如PE1的路径所需的信息。如果PE2随后将X作为VPN-IPv4路由泄漏到BGP中，则PE2违反了BGP中循环自由的约束之一；即，从特定BGP域学习的路由不会重新分配回该BGP域。这可能会导致创建路由循环。
It is therefore necessary to have a means by which an LSA may carry the information that a particular address prefix has been learned from a PE router. Any PE router that receives an LSA with this information would omit the information in this LSA from its OSPF routing computation, and thus it would not leak the information back into BGP.
因此，有必要具有LSA可携带特定地址前缀已从PE路由器学习的信息的手段。任何接收带有此信息的LSA的PE路由器都会从其OSPF路由计算中忽略此LSA中的信息，因此不会将信息泄漏回BGP。
When a PE generates an AS-external LSA, it could use a distinct tag value to indicate that the LSA is carrying information about an address prefix for whom the path includes a PE router. However, this method is not available in the case where the PE generates a Summary LSA. Per [VPN-OSPF], each PE router must function as an OSPF area 0 router. If the PE-CE link is an area 0 link, then it is possible for the PE to receive, over that link, a summary LSA that originated at another PE router. Thus, we need some way of marking a summary LSA to indicate that it is carrying information about a path via a PE router.
当一个PE生成一个AS外部LSA时，它可以使用一个不同的标记值来指示LSA正在承载一个地址前缀的信息，该地址前缀的路径包括一个PE路由器。但是，在PE生成汇总LSA的情况下，此方法不可用。根据[VPN-OSPF]，每个PE路由器必须作为OSPF区域0路由器运行。如果PE-CE链路是区域0链路，则PE可以通过该链路接收源自另一个PE路由器的摘要LSA。因此，我们需要某种方式来标记摘要LSA，以指示它通过PE路由器承载有关路径的信息。
The high-order bit of the LSA Options field (a previously unused bit) is used to solve the problem described in the previous section. We refer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear in all other LSA types.
LSA选项字段的高位（以前未使用的位）用于解决上一节中描述的问题。我们将此位称为DN位。从PE向CE发送类型3、5或7 LSA时，必须设置DN位。DN位必须在所有其他LSA类型中清除。
+-------------------------------------+
| DN | * | DC | EA | N/P | MC | E | * |
+-------------------------------------+
+-------------------------------------+
| DN | * | DC | EA | N/P | MC | E | * |
+-------------------------------------+
Options Field with DN Bit (RFC 2328, Section A.2)
带有DN位的选项字段（RFC 2328，第A.2节）
When the PE receives, from a CE router, a type 3, 5, or 7 LSA with the DN bit set, the information from that LSA MUST NOT be used during the OSPF route calculation. As a result, the LSA is not translated into a BGP route. The DN bit MUST be ignored in all other LSA types.
当PE从CE路由器接收到设置了DN位的类型3、5或7 LSA时，在OSPF路由计算期间不得使用来自该LSA的信息。因此，LSA不会转换为BGP路由。在所有其他LSA类型中，必须忽略DN位。
This prevents routes learned via BGP from being redistributed to BGP. (This restriction is analogous to the usual OSPF restriction that inter-area routes that are learned from area 0 are not passed back to area 0.)
这将防止通过BGP学习的路由被重新分配到BGP。（此限制类似于通常的OSPF限制，即从区域0学习的区域间路由不会传回区域0。）
Note that the DN bit has no other effect on LSA handling. In particular, an LSA with the DN bit set will be put in the topological database, aged, flooded, etc., just as if DN were not set.
请注意，DN位对LSA处理没有其他影响。特别是，设置了DN位的LSA将被放入拓扑数据库、老化、泛洪等，就像未设置DN一样。
An attacker may cause the DN bit to be set, in an LSA traveling from CE to PE, when the DN bit should really be clear. This may cause the address prefixes mentioned in that LSA to be unreachable from other sites of the VPN. Similarly, an attacker may cause the DN bit to be clear, in an LSA traveling in either direction, when the DN bit should really be set. This may cause routing loops for traffic that is destined to the address prefixes mentioned in that LSA.
在从CE到PE的LSA中，当DN位确实应该清除时，攻击者可能会导致设置DN位。这可能导致无法从VPN的其他站点访问该LSA中提到的地址前缀。类似地，当确实应该设置DN位时，攻击者可能会导致LSA中沿任意方向移动的DN位被清除。这可能会导致发送到该LSA中提到的地址前缀的流量的路由循环。
These possibilities may be eliminated by using cryptographic authentication as specified in Section D of [OSPFv2].
这些可能性可通过使用[OSPFv2]第D节规定的加密认证来消除。
The idea of using the high-order options bit for this purpose is due to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this work. We also wish to thank Acee Lindem for his helpful comments.
为此目的使用高阶选项位的想法是由Derek Yang提出的。感谢亚科夫·雷克特对这项工作的贡献。我们还要感谢Acee Lindem的有益评论。
[OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328, April 1972.
[OSPFv2]Postel，J.，“建议的Telnet协议变更”，RFC3281972年4月。
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[VPN]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, June 2006.
[VPN-OSPF]Rosen，E.，Psenak，P.，和P.Pillay Esnault，“OSPF作为BGP/MPLS IP虚拟专用网络（VPN）的提供商/客户边缘协议”，RFC 4577，2006年6月。
Authors' Addresses
作者地址
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719
EMail: erosen@cisco.com
EMail: erosen@cisco.com
Peter Psenak Cisco Systems BA Business Center, 9th Floor Plynarenska 1 Bratislava 82109 Slovakia
斯洛伐克布拉迪斯拉发Plynarenska 1号9楼Peter Psenak Cisco Systems BA商务中心82109
EMail: ppsenak@cisco.com
EMail: ppsenak@cisco.com
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose, CA 95134
帕德玛·皮莱·埃斯纳尔特思科系统公司，地址：加利福尼亚州圣何塞市思科路3750号，邮编：95134
EMail: ppe@cisco.com
EMail: ppe@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。