INTERNET DRAFT J. De Clercq, G. Gastaud T. Nguyen, D. Ooms Alcatel S. Prevost BT F. Le Faucheur Cisco November, 2001 Expires May, 2002 Connecting IPv6 Islands across IPv4 Clouds with BGP 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 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 This document explains how to interconnect IPv6 islands over an IPv4 cloud, including the exchange of IPv6 reachability information using BGP. Two approaches will be explained, both requiring a Dual Stack MP-BGP-speaking edge router per IPv6 island. The hosts in the IPv6 islands can use native IPv6 addresses. The first approach relies on identification of the MP-BGP-speaking edge routers via an IPv6 address and on existing ngtrans tunneling mechanisms to tunnel packets. The second approach relies on identification of the MP-BGP-speaking edge routers via an IPv4 address only and can then use a trivial tunneling mechanism without Ooms Expires May 2002 [Page 1] Internet Draft draft-ietf-ngtrans-bgp-tunnel-03.txt November 2001 any explicit tunnel configuration. Table of Contents 1. Introduction 2. Terminology 3. A reference architecture 4. Description 5. Tunneling 5.1. "IPv4 BGP Next Hop" approach 5.1.1. Tunneling over IPv4/GRE tunnels 5.1.2. Tunneling over MPLS LSPs 5.2. "IPv6 BGP Next Hop" approach 6. Crossing multiple IPv4 domains 7. Comparison 7.1. "IPv4 BGP Next Hop" approach versus "IPv6 BGP Next Hop" approach 7.2. "IPv6 BGP Next Hop" and "IPv4 BGP Next Hop" approaches versus other ngtrans mechanisms 7.3. "IPv4 BGP Next Hop" approach versus MPLS/BGP VPNs 8. Security considerations Changes 00->01: editorial changes extended section 4 01->02: editorial changes added tunnel-specific considerations added case of multiple IPv4 domains between IPv6 islands added discussion on v6[v4]addresses in appendix A 02->03: complete rewrite: it turned out that two interpretations of the previous drafts existed, the two different interpretations are described explicitly in this version 1. Introduction This document explains how to interconnect IPv6 islands over an IPv4 cloud, including the exchange of IPv6 reachability information using BGP. Two approaches will be explained, both requiring a Dual Stack MP-BGP-speaking edge router per IPv6 island. The hosts in the IPv6 islands can use native IPv6 addresses. The first approach relies on identification of the MP-BGP-speaking edge routers via an IPv6 address and on existing ngtrans tunneling mechanisms to tunnel packets. The second approach relies on identification of the MP-BGP-speaking edge routers via an IPv4 address only and can then use a trivial tunneling mechanism without any explicit tunnel configuration. Ooms Expires May 2002 [Page 2] Internet Draft draft-ietf-ngtrans-bgp-tunnel-03.txt November 2001 2. Terminology The terminology of [IPV6] and [TRANS] applies to this document. We also use some of the terminology of [VPN]. In this document an 'IPv6 island' is an IPv6-upgraded network (which can be cross-AS). A typical example of one island would be one or more Customer IPv6 sites connected via their Customer Edge (CE) router to one (or more) Dual Stack Provider Edge (PE) router(s) of an IPv6 Service Provider. 3. A reference architecture An ISP provides IPv6 services to some of its customers. However, its network core has not been upgraded to IPv6. The provider has upgraded some PE routers in some POPs to be DS-BGP routers. The DS-BGP routers provide access to IPv6 customers and may provide access to IPv4 customers in addition. The ISP may also have access to the global IPv6 Internet. The ISP provides global IPv6 connectivity through its peering relationship with an upstream ISP, or by peering relationships with other IPv6 ISPs in the default free routing zone (DFZ). A DS-BGP router in the provider's network is connected to an upstream IPv6 ISP or forms part of the IPv6 backbone network, such as the 6bone. The ISP advertises IPv6 reachability of its IPv6 allocated prefix using MP-BGP to its IPv6 upstream provider or into the IPv6 DFZ. The IPv6 prefixes received from the upstream provider or from the DFZ can be redistributed within the ISP using MP-BGP. The interface between the CE router and the PE router is a native IPv6 interface which can be physical or logical. A routing protocol (IGP or EGP) may run between the CE router and the PE router for a customer IPv6 site to exchange its reachability. Alternatively, static routes and/or a default route may be used on PE and CE to control reachability. A customer site may connect to the provider network over more than one interface. The methods in this document can be used for customers that already have an IPv4 service from the network provider and additionally require an IPv6 service, as well as for customers that require only IPv6 connectivity. In both cases the network provider allocates IPv6 addresses to the site. 4. Description Ooms Expires May 2002 [Page 3] Internet Draft draft-ietf-ngtrans-bgp-tunnel-03.txt November 2001 Each IPv6 island is connected to at least one Dual Stack MP-BGP- speaking edge router that is located on the border with the IPv4 cloud. We refer to such a router as a DS-BGP router. The DS-BGP router has at least an IPv4 address on the IPv4 side and an IPv6 address at the IPv6 island side. The IPv4 address must be routable in the IPv4 cloud. We refer to the DS-BGP router receiving IPv6 packets from an IPv6 island as an Ingress DS-BGP router (relative to these IPv6 packets). We refer to a DS-BGP router sending IPv6 packets to an IPv6 island as an Egress DS-BGP router (relative to these IPv6 packets). No extra routes will be injected in the IPv4 cloud. Interconnecting IPv6 islands over an IPv4 cloud requires following steps: (1) Exchange IPv6 reachability information among DS-BGP Routers: (1.a) The DS-BGP routers exchange, via MP-BGP [MP-BGP], IPv6 reachability information over the IPv4 cloud with their peers. (1.b) In doing so, the Egress DS-BGP routers announce themselves as the BGP Next Hop. (2) Tunnel IPv6 packets from Ingress DS-BGP Router to Egress DS-BGP Router: the Ingress DS-BGP router tunnels an IPv6 packet over the IPv4 cloud towards the Egress DS-BGP router identified as the BGP Next Hop in step (1.b) for the packet's destination IPv6 address. We distinguish two approaches for connecting IPv6 islands across IPv4 clouds via BGP, which are respectively referred to as the "IPv6 BGP Next Hop" approach and the "IPv4 BGP Next Hop" approach. Step (1.a) is identical for both approaches. Steps (1.b) and (2) differ between the two approaches: "IPv4 BGP Next Hop" approach: This approach assumes that the DS-BGP routers run MP-BGP over an IPv4 stack (MP-BGP/TCP/IPv4). The DS-BGP router conveys to its peer its IPv4 address as the BGP Next Hop. Since MP-BGP requires that the BGP Next Hop is of the same address family as the NLRI, this IPv4 address needs to be embedded in an IPv6 format. The IPv4-mapped IPv6 address is defined in [V6ADDR] as an "address type used to represent the addresses of IPv4 nodes as IPv6 Ooms Expires May 2002 [Page 4] Internet Draft draft-ietf-ngtrans-bgp-tunnel-03.txt November 2001 addresses", thus this precisely fits for the above purpose. Encoding the routable IPv4 address into a IPv4-mapped IPv6 address allows the remote DS-BGP router to automatically tunnel data over the IPv4 cloud to the destination IPv6 island. Any type of encapsulation can be used (IPv4, MPLS, GRE). "IPv6 BGP Next Hop" approach: This approach assumes that the DS-BGP routers run MP-BGP over an IPv6 stack (MP-BGP/TCP/IPv6). The DS-BGP router conveys to its peer its IPv6 address as the BGP Next Hop. The transport of MP-BGP messages as well as IPv6 packets over the IPv4 cloud relies on any existing ngtrans tunneling technique ([6TO4], [ISATAP], ...). Thus, the IPv6 address of the BGP Next Hop must match the actual ngtrans tunneling technique used. For example, if ISATAP is used as the IPv6 over IPv4 tunneling technique, then the IPv6 address of the BGP Next Hop must be an ISATAP address. For both approaches, the MP-BGP AFI will be IPv6 (value 2). The SAFI depends on the details of the tunneling technique used. This is discussed below in the tunnel technique specific section. When the number of PEs is not too high, it is possible for PEs to peer in a mesh fashion. Otherwise Route Reflectors may be used. The hosts in the IPv6 island can have native IPv6 addresses. This is different from e.g. 6to4 [6TO4], which requires that special addresses (6to4 addresses) are allocated to the IPv6 hosts. 5. Tunneling 5.1. "IPv4 BGP Next Hop" approach In the "IPv4 BGP Next Hop" approach, the IPv4-mapped IPv6 addresses allow a DS-BGP router that has to forward a packet to automatically determine the IPv4 endpoint of the tunnel by looking at the MP-BGP routing info. The Ingress DS-BGP Router simply uses this IPv4 address as the destination address of the prepended tunneling header. It uses one of its IPv4 reachable address as the source address of the prepended tunneling header. If this approach is used to connect to the public IPv6 Internet, tunnels without special security mechanisms can be used (e.g. IPv4 tunnels [TUNNEL], GRE tunnels [GRE] or MPLS LSPs without IPSec). Note that even when the number of peers is high, the number of tunnels is not a scalability concern from an operational viewpoint Ooms Expires May 2002 [Page 5] Internet Draft draft-ietf-ngtrans-bgp-tunnel-03.txt November 2001 since those are automatic tunnels and thus require no configuration. Considerations on 'common tunneling techniques' in [TRANS] are valid for this approach. 5.1.1. Tunneling over IPv4/GRE tunnels When tunneling is done using IPv4 or GRE Tunnels, the SAFI used in MP-BGP will be one of the basic values: unicast, multicast or both (1, 2 or 3). 5.1.2. Tunneling over MPLS LSPs When the IPv4 backbone supports MPLS, MPLS LSPs can be used as the tunneling technique. These LSPs can be established using any existing technique (LDP, RSVP, ...). When MPLS LSPs are used with the "IPv4 BGP Next Hop" approach, rather than successively prepend an IPv4 header and then perform label imposition based on the IPv4 header, the ingress DS-BGP Router can directly perform label imposition of the IPv6 header without prepending any IPv4 header. The (outer) label imposed corresponds to an LSP starting on the ingress DS-BGP Router and ending on the egress DS-BGP Router. While the "IPv4 BGP Next Hop" approach can operate using a single level of labels, there are advantages in using a second level of labels which are bound to IPv6 prefixes via MP-BGP advertisements in accordance with [LABEL]. For instance, use of a second level label allows Penultimate Hop Popping (PHP) on the Label Switch Router (LSR) upstream of the egress DS-BGP router without any IPv6 capabilities/upgrade on the penultimate router even when the IPv6 packet is directly encapsulated in MPLS (without an IPv4 header); since it still transmits MPLS packets even after the PHP (instead of having to transmit IPv6 packets and encapsulate them appropriately). Where a single level of labels is used and no label is advertised by MP-BGP, the SAFI used in MP-BGP will be one of the basic values: unicast, multicast or both (1,2 or 3). Where two levels of labels are used and labels are advertised by MP- BGP, the SAFI used in MP-BGP will be the "label" SAFI (4) or the "VPN" SAFI (128) depending on the procedures for allocating these labels. 5.2. "IPv6 BGP Next Hop" approach Ooms Expires May 2002 [Page 6] Internet Draft draft-ietf-ngtrans-bgp-tunnel-03.txt November 2001 As said before, the "IPv6 BGP Next Hop" approach relies on any existing ngtrans mechanism to carry the IPv6 packets over the IPv4 cloud. To determine the IPv4 endpoint of the tunnel, the DS-BGP Router applies the relevant ngtrans mechanism over the v6 address of the Egress DS-BGP Router. Thus, as said before, the IPv6 address of the Egress DS-BGP Router advertised in MP-BGP as the BGP Next Hop must be compatible with the ngtrans mechanism used. The SAFI used in MP-BGP will be one of the basic values: unicast, multicast or both (1,2 or 3). 6. Crossing multiple IPv4 domains When the IPv6 islands are separated by multiple IPv4 domains, two cases can be distinguished: 1. The border routers between the IPv4 domains are not DS-BGP routers. The DS-BGP routers of the IPv6 islands (connected to different IPv4 domains) will be configured as peers, yielding one direct inter-domain tunnel per pair of such DS-BGP routers. Note that the exchange of IPv6 routes can only start after BGP has created IPv4 connectivity between the domains. 2. The border routers between the IPv4 domains are DS-BGP routers. Each of these border DS-BGP routers will peer with the DS-BGP routers in its domain and regular IPv6 routing will take place in between the two domains. 7. Comparison 7.1. "IPv4 BGP Next Hop" approach versus "IPv6 BGP Next Hop" approach The "IPv6 BGP Next Hop" approach requires that an ngtrans tunneling mechanism (eg. ISATAP, 6to4, ...) be supported and activated on the DS-BGP Router ahead of time and that IPv6 addresses compatible with this tunneling mechanism be allocated to the DS-BGP Routers. In contrast, the "IPv4 BGP Next Hop" approach requires that no other ngtrans mechanism be used. Because it allows direct label imposition of IPv6 packets (i.e. without prepending an IPv4 header), the "IPv4 BGP Next Hop" approach can result in less overhead if applied in an MPLS backbone. However it must be noted that, in that case, if for some reason, the LSP Ooms Expires May 2002 [Page 7] Internet Draft draft-ietf-ngtrans-bgp-tunnel-03.txt November 2001 fails, forwarding of IPv6 packets towards the corresponding Egress DS-BGP Router will be interrupted. Forwarding of IPv6 packets is not interrupted in case of LSP failure with the "IPv6 BGP Next Hop" approach or with the "IPv4 BGP Next Hop" approach when an IPv4 header is prepended before label imposition, since forwarding can fall back to IPv4 forwarding. 7.2. "IPv6 BGP Next Hop" and "IPv4 BGP Next Hop" approaches versus other ngtrans mechanisms [TRANS] specifies a method to create automatic tunnels by using IPv4-compatible IPv6 addresses. This method is restricted to the case in which the destination coincides with the endpoint of the tunnel (host-to-host or router-to-host tunnels). It has the disadvantage that it requires an IPv4 address per host. "IPv6 BGP Next Hop" and "IPv4 BGP Next Hop" approaches require only one IPv4 address per island and enables automatic tunnels for the router-to- router case in contrast to the automatic tunneling described in [TRANS] where the tunnel end-point is the final destination. With "IPv6 BGP Next Hop" and "IPv4 BGP Next Hop" approaches , the hosts in the IPv6 island can have native IPv6 addresses. This is different from e.g. 6to4 [6TO4], which requires that special addresses (6to4 addresses) are allocated to the IPv6 hosts. 7.3. "IPv4 BGP Next Hop" approach versus MPLS/BGP VPNs "IPv4 BGP Next Hop" approach can also be viewed as an instantiation of the solution proposed for IPv6 VPNs over an IPv4 backbone [V6VPN] (the IPv6 Internet is considered as one large 'public' VPN) which is: (i) generalized since it can also operate with other tunneling techniques than MPLS. (ii) simplified since it omits the VPN specific parts: - No need for a Route Distinguisher (RD). - VPN Routing and Forwarding (VRF) tables are not required. - No need for a Route Target. - Except when two (or more) levels of label are used, the basic SAFI values (1, 2, 3) suffice. - Except when two (or more) levels of label are used, there is no Ooms Expires May 2002 [Page 8] Internet Draft draft-ietf-ngtrans-bgp-tunnel-03.txt November 2001 need to carry labels in MP-BGP. 8. Security considerations This proposal can use the security features of BGP and any policy defined in the ISP domain. References [6TO4] B. Carpenter, K. Moore, "Connection of IPv6 domains via IPv4 Clouds", RFC3056, February 2001. [GRE] Farinacci D., T. Li, S. Hanks, D. Meyer, P. Traina, "Generic Routing Encapsulation (GRE)", RFC2784. [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). [LABEL] Rekhter Y., E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001. [MP-BGP]T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol Exten- sions for BGP-4", RFC2858. [VPN] Rosen E., Rekhter Y., Brannon S., Chase C., De Clercq J., Hitchin P., Marshall , Srinivasan V., "BGP/MPLS VPNs", draft- ietf-ppvpn-rfc2547bis-00.txt (work in progress). [TRANS] R. Gilligan & E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC2893. [TUNNEL]W. Simpson, "IP in IP Tunneling", RFC1853. [V6ADDR]Deering, S., and R. Hinden, "IP Version 6 Addressing Architec- ture", draft-ietf-ipngwg-addr-arch-v3-06.txt (work in progress). [V6VPN] Nguyen T., Gastaud G., De Clercq J., Ooms D.,"BGP-MPLS VPN extension for IPv6 VPN over an IPv4 infrastructure", draft- ietf-ppvpn-bgp-ipv6-vpn-01.txt> (work in progress). Ooms Expires May 2002 [Page 9] Internet Draft draft-ietf-ngtrans-bgp-tunnel-03.txt November 2001 Authors' Addresses Tri T. Nguyen Alcatel Level 20 Noth Point Tower, 100 Miller Street, North Sydney NSW 2060, Australia E-mail: tri.t.nguyen@alcatel.com Dirk Ooms Alcatel Fr. Wellesplein 1, 2018 Antwerp, Belgium E-mail: dirk.ooms@alcatel.be Gerard Gastaud Alcatel 10 rue Latecoere, BP 57, 78141 Velizy Cedex, France E-mail: gerard.gastaud@alcatel.fr Jeremy De Clercq Alcatel Fr. Wellesplein 1, 2018 Antwerp, Belgium E-mail: jeremy.de_clercq@alcatel.be Stuart Prevost BT Room 136 Polaris House, Adastral Park, Martlesham Heath, Ipswich, Suffolk IP5 3RE, England E-mail: stuart.prevost@bt.com Francois Le Faucheur Cisco Systems Domaine Green Side, 400, Avenue de Roumanille, Batiment T3 06 410 BIOT, SOPHIA ANTIPOLIS, FRANCE E-mail: flefauch@cisco.com Ooms Expires May 2002 [Page 10]