Internet Draft Network Working Group Hamid Ould-Brahim Internet Draft Gregory Wright draft-ouldbrahim-bgp-vpn-00.txt Bryan Gleeson Expiration Date: January 2001 Nortel Networks July 2000 BGP/VPN: VPN Information Discovery for Network-based VPNs Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC-2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract VPN information can be piggybacked into BGP to allow a network-based VPN to auto-discover its membership and adequate information needed before any data exchange between private sites takes place across the backbone. Other drafts (e.g.[VPN-RFC2547]) also piggyback VPN information onto the backbone instance of BGP. However, [VPN- RFC2547] implicitly allows only for a single reachability mechanism (also BGP piggybacking) and a single tunneling mechanism (MPLS). This draft allows for the explicit indication of the reachability modes supported (e.g. piggybacking or virtual router) and the tunneling mechanisms supported, by a VPN device. The purpose of this Ould-Brahim, et. al [Page 1] Internet-Draft BGP/VPN: VPN Information Discovery January 2001 draft is to define a common VPN information protocol that can be used for both piggybacking and virtual router schemes. It allows for the auto-discovery of the nodes in a particular VPN, the selection of the reachability mechanism to use, and the selection of the tunneling protocol to use. 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. 1. Introduction VPN information can be piggybacked into BGP to allow a network-based VPN to auto-discover its membership and adequate information needed before any data exchange between private sites takes place across the backbone. Other drafts (e.g.[VPN-RFC2547]) also piggyback VPN information onto the backbone instance of BGP. However [VPN-RFC2547] draft implicitly allows only for a single reachability mechanism (also BGP piggybacking) and a single tunneling mechanism (MPLS). This draft allows for the explicit indication of the reachability mechanisms supported (e.g. piggybacking or virtual router) and the tunneling mechanisms supported, by a VPN device. The purpose of this draft is to define a common VPN information protocol that can be used for both piggybacking and virtual router schemes. It allows for the auto-discovery of the nodes in a particular VPN, the selection of the reachability mechanism to use, and the selection of the tunneling protocol to use. BGP is used to carry different type of VPN information (e.g., the list of VPN identifiers, the tunnel mechanisms, the VPN reachability information). The BGP UPDATE message carrying the VPN information will include, the set of VPN identifiers associated with each edge router, and adequate information to allow other edge routers to learn relevant VPN information. The edge routers would examine received VPN information and determine if any contained information was relevant to a supported (i.e., configured) VPN. The proposed VPN extensions allow different VPN topologies to be constructed (hub and spoke, a full mesh VPN, and arbitrary topologies). 2. Reachability Distribution Schemes There are two different schemes for distributing VPN reachability information, the virtual router and the piggybacking reachability schemes. In the VR model [VPN-VR], each VR in the VPN domain is running an instance of routing protocol responsible to disseminate VPN reachability information between VRs. Therefore, VPN reachability is carried out by a per-VPN instance of routing. In the reachability piggybacking model the VPN network layer is terminated at the edge of the backbone, and a backbone routing protocol (i.e. Ould-Brahim, et al. July 2000 [Page 2] Internet-Draft BGP/VPN: VPN Information Discovery January 2001 BGP-4) is responsible for disseminating the VPN reachability information between provider edge routers (PE) for all the VPNs configured on the PE. 3. Network Based VPNs Reference Model The network based VPNs reference model addressed in this draft is illustrated in figure 1. PE PE +--------------+ +--------------+ +--------+ | +----------+ | | +----------+ | +--------+ | VPN-A | | | VPN-A | | | | VPN-A | | | VPN-A | | Sites |--| |Database /| | BGP peers | | Database/| |-| sites | +--------+ | |Processing| |<---------->| |Processing| | +--------+ | +----------+ | | +----------+ | | | | | +--------+ | +----------+ | | +----------+ | +--------+ | VPN-B | | | VPN-B | | -------- | | VPN-B | | | VPN-B | | Sites |--| |Database /| |-(Backbone)-| | Database/| |-| sites | +--------+ | |Processing| | -------- | |Processing| | +--------+ | +----------+ | | +----------+ | | | | | +--------+ | +----------+ | | +----------+ | +--------+ | VPN-C | | | VPN-C | | | | VPN-C | | | VPN-C | | Sites |--| |Database /| | | | Database/| |-| sites | +--------+ | |Processing| | | |Processing| | +--------+ | +----------+ | | +----------+ | +--------------+ +--------------+ Figure 1: Network based VPN Reference Model It is assumed that BGP peers are configured over each backbone where the PE is attached. Each PE can store, and process information for multiple VPNs. 4. Carrying VPN information in BGP BGP-4 multiprotocol extension attributes can be used to carry various information about VPNs. Other possible alternative is to use new BGP attributes specifically for carrying VPN information (as long as the VPN information entries are explicitly identified). SAFI value of 129 indicates that the information carried in the NLRI field is a VPN information. Ould-Brahim, et al. July 2000 [Page 3] Internet-Draft BGP/VPN: VPN Information Discovery January 2001 5. NLRI encoding To support VPN information in the NLRI, the Network Layer Reachability information in the MP_REACH_NLRI is encoded are described below: +---------------------------------------------------------+ | Length of the NLRI (2 octets) | +---------------------------------------------------------+ | Number of VPN-IDs (2 octets) | +---------------------------------------------------------+ | First VPN-ID (7 octets) | +---------------------------------------------------------+ | Second VPN-ID (7 octets) | +---------------------------------------------------------+ ..... +---------------------------------------------------------+ | N-th VPN-ID (7 octets) | +---------------------------------------------------------+ | VPN Topology Attribute (2 octets) | +---------------------------------------------------------+ | VPN Reachability Mode (1 octets) | +---------------------------------------------------------+ | Length of VPN Reachability Entries (2 octets) | +---------------------------------------------------------+ | First VPN Reachability Entry (variable) | +---------------------------------------------------------+ | Second VPN Reachability Entry (variable) | +---------------------------------------------------------+ ..... +---------------------------------------------------------+ | N-th VPN Reachability Entry (variable) | +---------------------------------------------------------+ | Length of VPN Tunnel Entries (2 octets) | +---------------------------------------------------------+ | First VPN Tunnel Entry (variable) | +---------------------------------------------------------+ | Second VPN Tunnel Entry (variable) | +---------------------------------------------------------+ ..... +---------------------------------------------------------+ | N-th VPN Tunnel Entry (variable) | +---------------------------------------------------------+ | Other VPN information (variable) | +---------------------------------------------------------+ Figure 2. VPN Information within the NLRI field The use and the meaning of these fields are as follows: Ould-Brahim, et al. July 2000 [Page 4] Internet-Draft BGP/VPN: VPN Information Discovery January 2001 a) Length of the NLRI: The Length field indicates the length in bits of the NLRI tuple. b) Number of VPN-IDs (2 octets): The number of VPN-IDs carried in this NLRI. c) VPN-ID field: The VPN-ID format is defined in RFC2685: VPN OUI: Identifies VPN Authority (3 octets) VPN Index: Identifies a VPN within the Authority (4 octets) d) VPN Topology Attribute Two octets field used to indicate the nature of VPN topology. e) VPN Reachability Mode: A one octet number describing the reachability mode related to the VPN model used. f) Length of VPN Reachability Entries: The Length of VPN entries contains the length (in octets) of the VPN reachability entries. g) Length of VPN Tunnel Entries: contains the length (in octets) of the VPN tunnel entries. h) Other VPN information: will be used for passing specific VPN information. This field is optional. 5.1 VPN Membership Discovery using VPN-ID The IETF [VPN-RFC2685] and the ATM Forum [VPN-ATM] have standardized on a single format for a globally unique identifier used to identify a VPN - a VPN-ID. Only the format of the VPN-ID has been defined, not its semantics or usage. The aim is to allow its use for a wide variety of purposes, and to allow the same identifier to be used with different technologies and mechanisms. For example a VPN-ID can be bound to a tunnel. All packets that traverse the tunnel are then implicitly associated with the identified VPN. The same identifier can be used to identify the VPN across different technologies. Also if a VPN spans multiple administrative domains the same identifier can be used everywhere. Ould-Brahim, et al. July 2000 [Page 5] Internet-Draft BGP/VPN: VPN Information Discovery January 2001 5.2 VPN Reachability Discovery BGP can also be used to carry VPN reachability information. Indeed, once an edge router has determined/learnt the set of prefixes associated with each of attached VPNs, then this information is disseminated to each other edge router in the network. The VPN reachability entry is described as follows: +--------------------------------------------------------------+ | VPN Reachability Type (2 octets) | +--------------------------------------------------------------+ | Length (1 octets) | +--------------------------------------------------------------+ | VPN Reachability Value Field (variable) | +--------------------------------------------------------------+ Figure 3. VPN Reachability Entry The use and the meaning of these fields are as follows: a) VPN Reachability type: is the type of the VPN reachability information. b) Length: The length field indicates the length in bits of the VPN reachability value. c) VPN Reachability value field: contains the actual VPN route. 5.3 Tunnel Mechanisms Discovery Network-based VPNs must be implemented through some form of tunneling mechanism, where the packet formats and/or the addressing used within the VPN can be unrelated to that used to route the tunneled packets across the backbone [VPN-RFC2764]. There are numerous tunneling mechanisms that can be used by a network based VPN (e.g., IP/IP [RFC-2003], GRE tunnels [RFC-1701], IPSec [RFC- 2401], and MPLS tunnels [MPLS-ARCH]). Each of these tunnels allows for opaque transport of frames as packet payload across the backbone, with forwarding disjoint from the address fields of the encapsulated packets [VPN-RFC2764]. A tunnel connecting two endpoints is a basic building block from which a variety of different VPN services can be constructed. A tunnel operates as an overlay across the backbone, and the traffic sent through the tunnel is opaque to the underlying backbone. A provider edge router may terminate multiple type of tunnels and forward packets between these tunnels and other network interfaces in different ways. Ould-Brahim, et al. July 2000 [Page 6] Internet-Draft BGP/VPN: VPN Information Discovery January 2001 BGP can be used to inform the other edge routers of the nature of the tunnel mechanism used (e.g., MPLS, IPSec, etc.) with adequate information about the actual tunnel endpoints. The tunnel entries are described as below: +--------------------------------------------------------------+ | Tunnel Type Field (2 octets) | +--------------------------------------------------------------+ | Length (1 octets) | +--------------------------------------------------------------+ | Tunnel Value Field (variable) | +--------------------------------------------------------------+ Figure 4. VPN Tunnel Entry The use and the meaning of all the fields described above are: a) Tunnel Type field: Defines the type of tunneling mechanism (IPSec, IP in IP, MPLS, GRE, etc.). b) Length: length in bits of the Tunnel value. c) Tunnel Value Field: This field of variable size contains information about the tunnel endpoint values. 6. VPN Topology Information The proposed extensions allow different types of VPN topologies to be constructed. As an example, a hub and spoke VPN topology or an arbitrary topology can be constructed using different codes assigned to the topology attribute field. 7. Multiprotocol Unreachable NLRI for VPN: MP_UNREACH_NLRI can be used with a SAFI value of 129 for the purpose of withdrawing multiple unfeasible VPN NLRIs from service. 8. Use of BGP Capability Advertisement A BGP speaker that uses VPN information as described in this document with multiprotocol extensions should use the Capability Advertisement procedures to determine whether the speaker could use Multiprotocol Extensions with a particular peer. Ould-Brahim, et al. July 2000 [Page 7] Internet-Draft BGP/VPN: VPN Information Discovery January 2001 The Capability Code field is set to 1 (which indicates Multiprotocol Extensions capabilities). The SAFI field is 129 for VPN information. 9. Security Considerations The VPN extensions described in this draft do not change the underlying security issues. 10. References [BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities Attribute", February 2000, work in progress [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", February 1998, RFC 2283 [BGP-MPLS] Rekhter Y, Rosen E., "Carrying Label Information in BGP4", January 2000, work in progress [BGP-RR] Bates and Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 2796, April 2000 [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", August 1999, work in progress [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", October 1999,work in progress [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP Specification", October 1999, work in progress [RFC-1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC-2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC2026, October 1996. [RFC-2401] Kent S., Atkinson R., "Security Architecture for the Internet Protocol", RFC2401, November 1998. [RFC-2411] Thayer, R., et al, "IP Security Document Roadmap", RFC 2411, November 1998. [RFC-2661] Townsley, W., et al, "Layer Two Tunneling Protocol L2TP", RFC2661, August 1999. Ould-Brahim, et al. July 2000 [Page 8] Internet-Draft BGP/VPN: VPN Information Discovery January 2001 [RFC-2685] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [VPN-ATM] Petri, B. (editor) "MPOA v1.1 Addendum on VPN support", ATM Forum, af-mpoa-0129.000. [VPN-ITU] "Draft Recommendation Y.IPVPN", Study Group 13, Q20/13, May 2000. [VPN-RFC2547] Rosen E., et al, "BGP/MPLS VPNs", work in progress. [VPN-RFC2685] Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. [VPN-RFC2764] Gleeson, B., et al., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. [VPN-VR] Ould-Brahim H., et al., "Network based IP VPN Architecture using Virtual Routers", work in progress. 11. Intellectual Property Consideration The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 12. Acknowledgments The authors would like to acknowledge the following individuals for their helpful comments and suggestions: Bilel Jamoussi, Don Fedyk, and Ahmad Khalid from Nortel Networks. 13. Author's Addresses Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 Ould-Brahim, et al. July 2000 [Page 9] BGP/VPN: VPN Information Discovery January 2001 Gregory Wright Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 765 7912 Email: gwright@nortelnetworks.com Bryan Gleeson Nortel Networks 2305 Mission College Blvd Santa Clara CA 95054 USA Phone: +1 (505) 565 2625 Email: bgleeson@shastanets.com Ould-Brahim, et al. July 2000 [Page 10] BGP/VPN: VPN Information Discovery January 2001 Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Ould-Brahim, et al. July 2000 [Page 11]