diff options
Diffstat (limited to 'doc/rfc/rfc4576.txt')
| -rw-r--r-- | doc/rfc/rfc4576.txt | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc4576.txt b/doc/rfc/rfc4576.txt new file mode 100644 index 0000000..bccf066 --- /dev/null +++ b/doc/rfc/rfc4576.txt @@ -0,0 +1,395 @@ + + + + + + +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) + +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. + +Copyright Notice + + Copyright (C) The Internet Society (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. + + + + + + + + + + + +Rosen, et al. Standards Track [Page 1] + +RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006 + + +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 + + [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. + + 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: + + - Each address prefix in the set can be reached via that 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). + + 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. + + 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 + + + + +Rosen, et al. Standards Track [Page 2] + +RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006 + + + redistributes it to the routing protocol that is running on the link + to that 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. + + 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. + + 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]. + + 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]. + + 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. + +2. Specification of Requirements + + 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. + +3. Information Loss and Loops + + 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 + + + +Rosen, et al. Standards Track [Page 3] + +RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006 + + + then be distributed throughout a particular OSPF area, reaching + another CE, say CE2. CE2 may then distribute the LSA to another PE, + say 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. + + 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. + + 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. + +4. Using the LSA Options to Prevent Loops + + 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. + + + + + + + + + +Rosen, et al. Standards Track [Page 4] + +RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006 + + + +-------------------------------------+ + | DN | * | DC | EA | N/P | MC | E | * | + +-------------------------------------+ + + Options Field with DN Bit + (RFC 2328, Section 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. + + 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.) + + 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. + +5. Security Considerations + + 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. + + These possibilities may be eliminated by using cryptographic + authentication as specified in Section D of [OSPFv2]. + +6. Acknowledgements + + 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. + + + + + + + + + + + + +Rosen, et al. Standards Track [Page 5] + +RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006 + + +7. Normative References + + [OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328, + April 1972. + + [VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private + Networks (VPNs)", RFC 4364, February 2006. + + [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. + +Authors' Addresses + + Eric C. Rosen + Cisco Systems, Inc. + 1414 Massachusetts Avenue + Boxborough, MA 01719 + + EMail: erosen@cisco.com + + + Peter Psenak + Cisco Systems + BA Business Center, 9th Floor + Plynarenska 1 + Bratislava 82109 + Slovakia + + EMail: ppsenak@cisco.com + + + Padma Pillay-Esnault + Cisco Systems + 3750 Cisco Way + San Jose, CA 95134 + + EMail: ppe@cisco.com + + + + + + + + + + + + + +Rosen, et al. Standards Track [Page 6] + +RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (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. + + 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. + + 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. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Rosen, et al. Standards Track [Page 7] + |