INTERNET DRAFT Tri T. Nguyen Gerard Gastaud Dirk Ooms Jeremy De Clercq Alcatel February 2001 Expires August, 2001 BGP-MPLS VPN extension for IPv6 VPN over an IPv4 infrastructure Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This document describes a method by which a Service Provider may use an MPLS enabled IPv4 backbone to provide VPNs for its IPv6 customers. This proposal makes use of the method to build network based VPNs described in the RFC2547-Bis Internet draft [2547Bis]. In BGP/MPLS VPN, MPLS is used for forwarding packets over the backbone, and BGP is used for distributing VPN routes over the service provider backbone. This document proposes to use one of the defined encodings for the Route Distinguisher to support an IPv6 VPN address family. It defines an encoding for the SAFI-field in the case of labeled VPN- IPv6 routes. Nguyen, et al. Expires August 2001 [Page 1] Internet Draft draft-nguyen-bgp-ipv6-vpn February 2001 This document assumes that the reader is familiar with [2547Bis]. Unless explicitly documented herein, [2547Bis] applies. 1. Introduction This document adopts the definitions, acronyms and mechanisms described in [2547bis]. Unless otherwise stated, the mechanisms of [2547bis] apply and will not be re-described here. A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6 capable and is natively connected over an interface or sub-interface to the ISP backbone via a PE. A site belonging to an IPv6 VPN may have access to the 6Internet, but this is outside the scope of this document. A site may be both IPv4 and IPv6, but the logical interface on which the packet arrives determines the version (without looking necessarily inside a received packet). The PE being dual stack has full IPv4 capabilities, must maintain IPv6 VRFs for its IPv6 sites and must be able to encapsulate IPv6 datagrams in MPLS frames to be sent into the MPLS core network. The other backbone Network Elements are assumed to be IPv4 only. In principle the backbone network could be IPv6-capable, but this is not within the scope of this document. BGP is used to cause routes from IPv6 VPN sites to be distributed over the backbone to each other PE router connected to a site of the same IPv6 VPN. As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have its own IPv6 address space, which means that a given address may denote different systems in different VPNs (site-local addresses). This requires the definition of a new address family, the VPN-IPv6 Address Family, in a fashion similar to the VPN-IPv4 address family definition given by [2547bis]. 2. The VPN Address Family The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes from multiple "address families". We introduce the notion of the "VPN-IPv6 address family", that is similar to the VPN-IPv4 address family in [2547bis]. 2.1 The VPN-IPv6 Address Family A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte Nguyen, et al. Expires August 2001 [Page 2] Internet Draft draft-nguyen-bgp-ipv6-vpn February 2001 "Route Distinguisher(RD)" and ending with a 16-byte IPv6 address. If two VPNs use the same IPv6 address prefix (effectively denoting different physical systems), the PEs translate these into unique VPN-IPv6 address prefixes using different RDs. This ensures that if the same address is used in two different VPNs, it is possible to install two completely different routes to that address, one for each VPN. The purpose of the RD is solely to allow one to create distinct routes to a common IPv6 address prefix, similarly to the RD defined in [2547bis]. As it is possible per [2547bis], the RD can also be used to create multiple different routes to the very same system. This can be achieved by creating two different VPN-IPv6 routes that have the same IPv6 part, but different RDs. This allows BGP to install multiple different routes to the same system, and allows policy to be used to decide which packets use which route. Note that VPN-IPv6 addresses and IPv6 addresses are always considered by BGP to be incomparable. A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6 address prefix. When a packet's destination address is matched against a VPN-IPv6 route, only the IPv6 part is actually matched. When a site is IPv4- and IPv6-capable, the same RD can be used for the advertisement of IPv6 addresses or IPv4 addresses. 2.2. Encoding of Route Distinguishers The RDs are encoded as per [2547bis]: - Type Field: 2 bytes - Value Field: 6 bytes The interpretation of the Value field depends on the value of the Type field. At the present time, [2547bis] defines 2 values of the type field. Type 0 is recommended for use with IPv6. - Type 0: The Value field consists of two subfields: * Administrator subfield: 2 bytes, it contains an ASN * Assigned Number subfield: 4 bytes 3. VPN-IPv6 route distribution Nguyen, et al. Expires August 2001 [Page 3] Internet Draft draft-nguyen-bgp-ipv6-vpn February 2001 3.1. Route Distribution Among PEs by BGP If two sites of a VPN attach to PEs which are in the same Autonomous System, the PEs can distribute VPN routes to each other by means of an IBGP connection between them. Alternatively, each can have an IBGP connection to a route reflector. For an IPv6 VPN, this is done as mandated by [2547bis]. A PE being dual stack has at least one IPv6 and one IPv4 address. It may have more, and in particular it must have an IPv4-compatible IPv6 address (that address is based on its existing IPv4 address) as one of its IPv6 addresses. When a PE router distributes a VPN route via BGP, it must use its IPv4-compatible IPv6 address as the "BGP next hop". This address is encoded as a VPN address with a RD of 0. ([BGP-MP] requires that the next hop address be in the same address family as the NLRI.) It also assigns and distributes an MPLS label with the IPv6 VPN route. (Essentially, PE routers distribute not VPN routes, but Labeled VPN routes [MPLS-BGP]). When the PE processes a received MPLS frame that has this label at the top of the stack, the PE will pop the stack, and process the packet appropriately (i.e. in the corresponding VPN context). Note that the use of BGP-distributed MPLS labels is only possible if there is a label switched path between the PE router that installs the BGP-distributed route and the PE router which is the BGP next hop of that route. An MPLS label-switched path can carry IPv4 and IPv6 packets. The top LSP terminates at the PE and the bottom label directs the packet to the proper forwarding table or outgoing customer interface. 3.2. Route Target The use of route target is specified in [2547bis]. Encoding of the extended community attribute is defined in [BGP-EXTCOM]. The encoding recommended for IPv6 VPN is: Type : 0x0002, administrator field = 2-byte ASN, assigned number field is 4 octets. 4. How VPN NLRI is carried in BGP The BGP Multiprotocol Extensions [BGP-MP] are used to encode the NLRI. The AFI and SAFI fields are set as follows: - AFI: 2; for IPv6 Nguyen, et al. Expires August 2001 [Page 4] Internet Draft draft-nguyen-bgp-ipv6-vpn February 2001 - SAFI: 129; for MPLS labeled VPN-IPv6 In order for two BGP speakers to exchange labeled VPN NLRI, they must use BGP Capabilities Negotiation to ensure that they both are capable of properly processing such NLRI. This is done as specified in [BGP-MP], by using capability code 1 (multiprotocol BGP), with AFI and SAFI fields according to above. The labeled VPN-IPv6 NLRI itself is encoded as specified in [MPLS- BGP], but where the prefix consists of an 8-byte RD followed by an IPv6 prefix. 5. Inter-Provider Backbones The same mechanisms described in [2547bis] can be used and have the same scalability properties. 6. Accessing the Internet from a VPN The methods proposed by [2547bis] to access the global Internet can be used in the context of IPv6 VPNs and the global IPv6 Internet. Note however that if the IPv6 packets destined for the global IPv6 Internet need to traverse the SP's IPv4 backbone, they must be tunnelled through the IPv4 backbone. 7. Security The same security concerns as in [2547bis] are applicable. 8. Quality of Service [2547bis] is applicable. 9. References [2547Bis] Rosen et al., draft-rosen-rfc2547bis-02.txt, July 2000 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", February 1998, RFC 2283 [BGP-EXTCOMM] Ramachandra, Tappan, "BGP Extended Communities Attribute", February 2000, work in progress [BGP-ORF] Chen, Rekhter, "Cooperative Route Filtering Capability for BGP-4", March 2000, work in progress [BGP-RFSH] Chen, "Route Refresh Capability for BGP-4", March 2000, work in progress Nguyen, et al. Expires August 2001 [Page 5] Internet Draft draft-nguyen-bgp-ipv6-vpn February 2001 [BGP-RR] Bates and Chandrasekaran, "BGP Route Reflection: An alternative to full mesh IBGP", RFC 2796, April 2000 [IPSEC] Kent and Atkinson, "Security Architecture for the Internet Protocol", November 1998, RFC 2401 [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", August 1999, work in progress [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", January 2000, work in progress [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP Specification", October 1999, work in progress [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", October 1999, work in progress 10. Authors' Addresses Tri T. Nguyen Alcatel Level 20 North Point Tower, 100 Miller Street, North Sydney NSW 2060, Australia E-mail: tri.t.nguyen@alcatel.com Gerard Gastaud Alcatel 10 rue Latecoere, BP 57, 78141 Velizy Cedex, France E-mail: gerard.gastaud@alcatel.fr Dirk Ooms Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: dirk.ooms@alcatel.be Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerpen, Belgium E-mail: jeremy.de_clercq@alcatel.be Nguyen, et al. Expires August 2001 [Page 6]