Francois Le Faucheur, Cisco Systems, Inc. IETF Internet Draft Expires: December, 2002 Document: draft-lefaucheur-bgp-tunnel-transition-00.txt June, 2002 Operational Environments and Transition Scenarios for "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 describes the common operational environments of IPv4 Service Providers wanting to add IPv6 services to their service portfolio but not wanting (yet) to upgrade their IPv4 backbone to IPv6 routing. Two main transition scenarios are identified. We recommend that the "MP-BGP over IPv6" and "MP-BGP over IPv4" approaches defined in [BGP-TUNNEL] be respectively used for each of the two transition scenarios. 1. Introduction Le Faucheur 1 BGP Tunnel Transition June 2002 Many IPv4 Service Providers are considering/willing to complement their service portfolio by some IPv6 services. We first describe such operational environments in more details and then discuss the two main transition scenarios identified for such operational environments. 2. Operational Environments A Service Provider (SP) runs an IPv4 backbone and offers IPv4 services. This Service Providers makes extensive use of BGP for exchange of IPv4 reachability information: - IPv4 connection with upstream/peer Internet Service Providers (eBGP) - IPv4 connection with some end-users IPv4 sites (eBGP) - Distribution of IPv4 reachability information inside the SP's backbone (iBGP over TCP/IPv4). The Service Provider is obviously very familiar with BGP. The Service Provider may also be very familiar with MP-BGP (e.g. support of inter-domain IPv4 Multicast service or support of MPLS VPN service [MPLS-VPN]). This environment can be illustrated in the following way: +------------+ +----------+ +-----------------+ |IPv4 site A |--eBGP--| |--eBGP--|IPv4 Upstream ISP| +------------+ | SP's | +-----------------+ | IPv4 | +------------+ | Backbone | +----------------+ |IPv4 site B |--------| |--eBGP---| IPv4 Peer ISP | +------------+ | iBGP | +----------------+ +----------+ Now, the SP wants to broaden his/her service offering by adding some IPv6 services such as IPv6 connectivity across multiple IPv6 sites of an end user, and/or global IPv6 connectivity (i.e. access to the IPv6 Internet). All the exchange of IPv6 routing information at the edge of the SP backbone uses standardized native IPv6 routing: - the SP provides global IPv6 connectivity through his/her IPv6 customer relationship with an upstream ISP, or by peering relationships with other IPv6 ISPs in the default free routing zone (DFZ). Such peering uses MP-eBGP ([MP-BGP], [IPv6-MP-BGP)] for IPv6. It is used by the Service Provider to advertise IPv6 reachability of its IPv6 allocated prefix and to receive reachability for the IPv6 internet. - An IPv6 routing protocol (IGPv6 or MP-eBGP for IPv6) may run between IPv6 Site and the SP's network so that the IPv6 Site advertises its IPv6 reachability and receives IPv6 Le Faucheur 2 BGP Tunnel Transition June 2002 reachability information from the SP. Alternatively, static IPv6 routes and/or a default IPv6 route may be used to control such reachability. But the SP does not yet want to upgrade his/her backbone to IPv6. So native IPv6 routing is NOT used inside the SP's backbone. The new environment can be illustrated in the following way: +------------+ +----------+ +-----------------+ |IPv4 site A |--eBGP--| |--eBGP--|IPv4 Upstream ISP| +------------+ | SP's | +-----------------+ | IPv4 | +------------+ | Backbone | +----------------+ |IPv4 site B |--------| |--eBGP---| IPv4 Peer ISP | +------------+ | | +----------------+ | | +------------+ | iBGP | +-----------------+ |IPv6 site C |MP-eBGP-| |-MP-eBGP-|IPv6 Upstream ISP| +------------+ | | +-----------------+ | | +------------+ | | +----------------+ |IPv6 site D |--------| |-MP-eBGP-| IPv6 Peer ISP | +------------+ | | +----------------+ +----------+ In such an environment, the SP needs to find a transition solution until he/she is ready to upgrade the backbone to native IPv6 routing. The transition solution needs to: - distribute IPv6 reachability information over his/her non- IPv6 backbone - tunnel IPv6 traffic inside his/her IPv4 backbone. We feel such operational environments are very common and require clearly documented transition approaches. 3. Transition Scenarios We identify two main transition scenarios for such environments. 3.1. Use of existing IPv6 Tunneling Techniques In this scenario, the SP's operational constraints are such that: - it is acceptable/desirable to establish a set of MP-iBGP peerings (MP-iBGP mesh or MP-iBGP Route Reflector structure) over TCP/IPv6, in addition to the existing set of iBGP peerings (iBGP mesh or iBGP Route Reflector structure) over TCP/IPv4. AND, Le Faucheur 3 BGP Tunnel Transition June 2002 - it is acceptable/desirable to use one of the existing NGTRANS tunneling techniques ([6to4], [ISATAP],...) to achieve IPv6 reachability of the MP-BGP Next Hops over the IPv4 backbone. Note that this tunneling technique is ONLY needed for IPv6 reachability of the MP-BGP Next Hops at the edge of the SP network and is NOT needed for IPv6 reachability of the IPv6 Internet or IPv6 end user sites. The latter can be achieved via native IPv6 MP-iBGP routing among the MP-BGP Next Hops once those are granted IPv6 reachability. Note that this means that the inherent characteristics of such existing methods (e.g. use of special IPv6 addresses as with ISATAP, need for some configuration,...) are acceptable/desirable. AND, - The potential optimization of tunneling overhead achievable in some situations is not acceptable/desirable for tunneling of all the IPv6 traffic. For example, if the IPv4 backbone is also running MPLS, use of existing NGTRANS tunneling results in every IPv6 packets being effectively prepanded with both an IPv4 and an MPLS header. In this scenario, transition can be supported using purely existing IPNG and NGTRANS techniques combined in the following manner: - one existing NGTRANS tunneling technique ([6to4], [ISATAP],...) is used to provide IPv6 reachability among MP- iBGP Next Hops at the edge of the SPs' network - this reachability is used to build a set TCP/IPv6 connections for MP-iBGP peering among these MP-iBGP Next Hops (and possibly Route Reflectors), in addition to the existing set of TCP/IPv4 connections for the iBGP peerings. - existing MP-iBGP ([MP-BGP], [IPv6-MP-BGP])is used among those MP-iBGP Next Hops at the edge of the SP's network to establish MP-IBGP peerings and to exchange all the IPv6 reachability information. This is in addition to the existing iBGP peerings. - IPv6 packets are tunneled between the MP-iBGP routers at the edge of the IPv4 backbone using the selected existing NGTRANS tunneling technique and by performing this tunneling as if the packet was addressed to the MP-iBGP Next Hop Router advertised for the relevant IPv6 prefix. In other words, the tunnel IPv4 destination and the IPv4 tunnel header are not selected directly based on the destination IPv6 address but selected based on the IPv6 address of the MP-iBGP Next Hop router advertised in MP-iBGP for the relevant IPv6 prefix. This transition approach is referred to as the "MP-BGP over IPv6" approach and is further documented in [BGP-TUNNEL]. 3.2. "Auto tunneling" In this scenario, the SP's operational constraints are such that: - it is desirable to use the existing set of iBGP peerings (iBGP mesh or iBGP Route Reflector structure) over TCP/IPv4 Le Faucheur 4 BGP Tunnel Transition June 2002 to distribute reachability of all services (IPv4, IPv6 , and VPN-IPV4 if MPLS VPN services is also supported). OR, - a form of transparent automatic tunneling into IPv4 is desirable so that no configuration is required on the MP-BGP Next Hop routers at the edge of the SP network to activate/control tunneling, nor any constraints imposed on the IPv6 addresses used for these MP-BGP Next Hops. OR, - The potential optimization of tunneling overhead achievable in some situations is desirable for tunneling of all the IPv6 traffic. For example, if the IPv4 backbone is also running MPLS, IPv6 packets should only be prepanded by an MPLS header and not by an IPv4 header plus an MPLS header. In this scenario, transition can be supported using existing IPNG and NGTRANS techniques combined in the following manner: - The existing set of TCP/IPv4 connections and iBGP peering is used to also advertise IPv6 reachability via MP-iBGP ([MP- BGP], [IPv6-MP-BGP]) among the MP-iBGP Next Hops at the edge of the network (and possibly Route Reflectors) - An MP-iBGP Next Hop advertising IPv6 reachability information uses the IPv4-mapped IPv6 address format ([V6ADDR]} to convey its IPv4 address as the Next Hop Address. - The MP-iBGP Next Hops receiving IPv6 reachability information, use the IPv4 address contained in this IPv4- mapped address, as the destination address of the IPv4 tunnel to tunnel the corresponding IPv6 packets into, thus achieving automatic tunneling. This transition approach is referred to as the "MP-BGP over IPv4" approach and is further documented in [BGP-TUNNEL]. 4. Recommendation on Transition We recommend that the "MP-BGP over IPv6" and "MP-BGP over IPv4" approaches defined in [BGP-TUNNEL] be respectively used for each of the two main transition scenarios described above. We also observe that these approaches could also naturally accommodate a possible additional transition step which would be to complement the SP's service offering by an IPv6 MPLS VPN service [IPv6-MPLS-VPN] by simply supporting the IPv6-VPN address family in addition to the IPv6 address family in the same MP-iBGP peerings. 5. Security Considerations No new security considerations are raised by this document. Those are the same as the ones of BGP and can be addressed through the corresponding mechanisms. Le Faucheur 5 BGP Tunnel Transition June 2002 6. Acknowledgments We thank Jeremy De Clercq and Benoit Lourdelet for their review and suggestions. References [MP-BGP] T. Bates et al, "Multiprotocol Extensions for BGP-4", RFC2858. [IPv6-MP-BGP] Marques, P., and et.al , Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, RFC 2545, March 1999. [BGP-TUNNEL]. Ooms et al, Connecting IPv6 Islands across IPv4 Clouds with BGP, draft-ietf-ngtrans-bgp-tunnel-04.txt, January 2002. [6TO4] B. Carpenter, K. Moore, "Connection of IPv6 domains via IPv4 Clouds", RFC3056, February 2001. [ISATAP] F. Templin, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), draft-ietf-ngtrans-isatap-02.txt (work in progress). [V6ADDR] Deering, S., and R. Hinden, "IP Version 6 Addressing Architecture", draft-ietf-ipngwg-addr-arch-v3-07.txt (work in progress). [MPLS-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). [IPv6-MPLS-VPN] 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). Author's Address: Francois Le Faucheur Cisco Systems, Inc. Village d'Entreprise Green Side - Batiment T3 400, Avenue de Roumanille 06410 Biot-Sophia Antipolis France Phone: +33 4 97 23 26 19 Email: flefauch@cisco.com Le Faucheur 6