INTERNET DRAFT Tri T. Nguyen Gerard Gastaud Dirk Ooms Jeremy De Clercq Alcatel Marco Carugi France Telecom R&D June 2001 Expires December, 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/1id-abstracts.html 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 Virtual Private Networks for its IPv6 customers. This proposal makes use of the method to build network based VPNs described in the Internet draft "BGP/MPLS VPN" [2547bis]. In BGP/MPLS VPN, MPLS is used to forward packets over the backbone, and "Multiprotocol BGP" is used for distributing VPN routes over the service provider backbone. This document defines an IPv6 VPN address family and describes the route distribution and the MPLS tunnel selection. Nguyen, et al. Expires December 2001 [Page 1] Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn June 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 SP backbone via a Provider Edge device (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-capable. The logical interface on which packets arrive at the PE may determine the version, but alternatively a per-packet header lookup may determine the version. 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 possible implications of this feature are not within the scope of this document. BGP and its extensions are 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 Nguyen, et al. Expires December 2001 [Page 2] Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn June 2001 A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte "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 and 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. As it is the case in [2547bis], two encodings can be used: - TYPE field = 0 : the VALUE field consists of the following two subfields: * Administrator subfield: 2 bytes, it contains an Autonomous System Number * Assigned Number subfield: 4 bytes - TYPE field = 1 : the VALUE field consists of the following two Nguyen, et al. Expires December 2001 [Page 3] Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn June 2001 subfields: * Administrator subfield: 4 bytes, it contains a global IPv4 address * Assigned Number subfield: 2 bytes 3. VPN-IPv6 route distribution 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 described in [2547bis]. These considered PE routers are Dual Stack MP-BGP-speaking edge routers (DS-BGP routers) that are located at the border of the IPv4 backbone. A DS-BGP router has at least one IPv4 address and one IPv6 address. The IPv4 address must be routable in the IPv4 backbone network. The DS-BGP routers: (i) exchange, via MP-BGP [MP-BGP], IPv6 reachability information over the IPv4 backbone with their BGP-peers. (ii) announce themselves as the BGP Next Hop. MP-BGP has the constraint that the "BGP Next Hop" needs to be of the same address family as the distributed NLRI. The NLRI consists of VPN IPv6 addresses, while we would like the BGP Next Hop to be a routable (in the SP's core) IPv4 address. For that reason, the DS-BGP router will construct an IPv6 address that contains its routable IPv4 address. The precise format of this IPv6 address is open and the various possibilities are discussed in Appenix A. We will abreviate such an IPv6 address as a v6[v4]address. The DS-BGP router will use this v6[v4]address, prepended with a RD of 0 as the BGP Next Hop when it distributes IPv6 VPN addresses with BGP. The DS-BGP router also assigns and distributes MPLS labels with the IPv6 VPN routes. (Essentially, PE routers do not distribute VPN routes, but Labeled VPN routes [MPLS-BGP]). When the PE processes a received MPLS frame that has this particular label, the PE will pop the stack, and process the packet appropriately (i.e. in the corresponding VPN context). Nguyen, et al. Expires December 2001 [Page 4] Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn June 2001 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. Encoding the "BGP next hop" as a routable IPv4 address encoded into a v6[v4]address allows the remote DS-BGP routers to automatically find the routable IPv4 address of the destination PE and thus to select the correct MPLS tunnel. This requires only one IPv4 address (and a derived v6[v4]address) per DS-BGP PE router. No extra routes will be injected in the SP's IPv4 core. 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]. 4. How VPN IPv6 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 - 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]. In the context of this extension, 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 Nguyen, et al. Expires December 2001 [Page 5] Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn June 2001 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. Appendix A : v6[v4]addresses The initial version of this draft specified that the v6[v4]address had to be a "v4-compatible v6 address" (in analogy to the automatic tunenls in [TRANS]). There is however the intention of at least part of the ngtrans cummunity to deprecate v4-compatible addresses. Another 'rumor' is that one would forbid v4-compatible addresses to carry private IPv4 addresses (since these wouldn't be globally routable). Recently also a new type of v6 address containing a v4 address was defined: ISATAP addresses [ISATAP]. Until the above points have been clarified we want to keep the precise format of the v6[v4]address as an open point (we even want to keep the option open that the precise format shouldn't be defined and that it would be a matter of configuration). The requirements posed by the method in this draft on the v6[v4]address are: - a v6[v4]address is an IPv6 address that somehow contains an IPv4 address. - there is NO need for the v6[v4]addresses to be routable - the IPv4 cloud (= the SP backbone) could use private addresses, so it should be legal for a v6[v4]address to carry private v4 addresses 9. References [2547bis] Rosen et al., draft-rosen-rfc2547bis-03.txt, July 2000 [BGP-EXTCOMM] Ramachandra, Tappan, "BGP Extended Communities Attribute", February 2000, work in progress Nguyen, et al. Expires December 2001 [Page 6] Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn June 2001 [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions for BGP4", February 1998, RFC2283 [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460. [ISATAP] F. Templin, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), draft-ietf-ngtrans-isatap-01.txt, work in progress. [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label Switching Architecture", RFC3031 [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4", RFC3107 [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and Conta, "MPLS Label Stack Encoding", RFC3032 [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP Specification", RFC3036 [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC2893. 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 December 2001 [Page 7] Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn June 2001 Marco Carugi France Telecom R&D Technopole Anticipa, 2 av. P. Marzin 22307 Lannion cedex - France E-mail: marco.carugi@francetelecom.fr Nguyen, et al. Expires December 2001 [Page 8]