Internet Draft INTERNET DRAFT Tri T. Nguyen <draft-nguyen-bgp-ipv6-vpn-00.txt> Gerard Gastaud Dirk Ooms Jeremy De Clercq Alcatel October 2000 Expires April, 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 codings for the Router Distinguisher to support an IPv6 VPN address family. It defines a coding for the SAFI-field in the case of labeled VPN- IPv6 routes. Nguyen, et al. Expires April 2001 [Page 1] Internet Draft draft-nguyen-bgp-ipv6-vpn October 2000 This document assumes that the reader is familiar with draft-rosen- rfc2547bis-02. 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 the MPLS core network. The rest of the backbone is assumed to be IPv4 only. In principle it could be IPv6, but this is not in the scope considered. BGP is used to cause IPv6 VPN site routes 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 VPN [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 defining a new address family, the VPN-IPv6 Address Family, in a fashion similar to the VPN-Ipv4 address family definition of [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", similarly to the VPN-IPv4 address 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 April 2001 [Page 2] Internet Draft draft-nguyen-bgp-ipv6-vpn October 2000 "Route Distinguisher(RD)" and ending with a 16-byte IPv6 address. If two VPNs use the same IPv6 address prefix, the PEs translate these into unique VPN-IPv6 address prefixes. 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 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 v4 and v6, the same RD can be used for 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 3.1. Route Distribution Among PEs by BGP Nguyen, et al. Expires April 2001 [Page 3] Internet Draft draft-nguyen-bgp-ipv6-vpn October 2000 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 has 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 uses 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. (Essentially, PE routers distribute not VPN routes, but Labeled VPN routes [MPLS- BGP]). When the PE processes a received packet that has this label at the top of the stack, the PE will pop the stack, and process the packet appropriately. 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 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. 3.2. Route Target The use of route target is specified in [2547bis]. Coding of the extended community attribute is defined in [BGP-EXTCOM]. The coding recommended for IPv6 VPN is: Type : higher octet = x'00, administrator field = 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 - SAFI: 129; for MPLS labeled VPN-IPv6 Nguyen, et al. Expires April 2001 [Page 4] Internet Draft draft-nguyen-bgp-ipv6-vpn October 2000 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 ways proposed by [2547bis] apply with the following difference: PE needs to tunnel IPv6 packets over the SP backbone when [2547bis] forwards them natively. 7. Security [2547bis] is applicable with labeled VPN IPv6 routes. 8. Quality of Service [2547bis] is applicable. 9. Intellectual Property Considerations Alcatel may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Alcatel, Alcatel intends to disclose those patents and license them on reasonable and non-discriminatory terms. 10. 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 Nguyen, et al. Expires April 2001 [Page 5] Internet Draft draft-nguyen-bgp-ipv6-vpn October 2000 [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 [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 11. 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 April 2001 [Page 6]