INTERNET DRAFT J. De Clercq, G. Gastaud T. Nguyen, D. Ooms Alcatel S. Prevost BT F. Le Faucheur Cisco June, 2001 Expires December, 2001 Connecting IPv6 Domains 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 specifies a mechanism for IPv6 islands to communicate with each other over an IPv4 cloud without explicit tunnel setup, requiring only one IPv4 address (and a derived IPv6 address containing this IPv4 address) per IPv6 island. Each IPv6 island needs a Dual Stack MP-BGP-speaking edge router. The hosts in the IPv6 islands can use native IPv6 addresses. The method uses MP-BGP in the edge routers to exchange IPv6 reachability information between the IPv6 islands. Table of Contents Ooms Expires December 2001 [Page 1] Internet Draft draft-ietf-ngtrans-bgp-tunnel-02.txt June 2001 1. Introduction 2. Terminology 3. Overview 4. A reference architecture 5. IPv6 Site Prefix Distribution 6. Tunneling 6.1. Tunneling over IPv4/GRE tunnels 6.2. Tunneling over IPv4 MPLS LSPs 7. Comparison to MPLS/BGP VPNs 8. Security considerations Appendix A v6[v4]address 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 1. Introduction [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. This document specifies a mechanism for IPv6 islands to communicate with each other over an IPv4 cloud without explicit tunnel set-up, requiring only one IPv4 address per IPv6 island. The method in this document 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. The method in this document can make use of any tunneling technology available over the IPv4 backbone. This includes IPv4 tunnels, GRE tunnels and IPv4 MPLS Label Switched Paths (LSPs). 2. Terminology The terminology of [IPV6] and [TRANS] applies to this document. We also use some of the terminology of [VPN]. Ooms Expires December 2001 [Page 2] Internet Draft draft-ietf-ngtrans-bgp-tunnel-02.txt June 2001 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 Dual Stack Provider Edge (PE) router. 3. Overview Each IPv6 island has at least one Dual Stack MP-BGP-speaking edge router (DS-BGP router) that is located on the border with the IPv4 cloud. The hosts in the IPv6 islands have native IPv6 addresses. 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. The DS-BGP routers: (i) exchange, via MP-BGP [MP-BGP], IPv6 reachability information over the IPv4 cloud with their peers in the other IPv6 islands. (ii) announce themselves as the BGP Next Hop. MP-BGP has the constraint that the Next Hop needs to be of the same address family as the NLRI. 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 appendix A, we will abbreviate it as a v6[v4]address. Encoding the routable v4 address into a v6[v4]address allows the remote DS-BGP router to automatically tunnel data over the IPv4 cloud to the destination IPv6 island. This method requires only one IPv4 address (and a derived v6[v4]address) per IPv6 island. No extra routes will be injected in the IPv4 cloud. The hosts in the IPv6 island 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. This method can also be looked at as an instantiation of the solution proposed for IPv6 VPNs over an IPv4 backbone [V6VPN] which is: - simplified since it omits the VPN specific parts as discussed in section 7 below. - generalized since it can also operate with other tunneling Ooms Expires December 2001 [Page 3] Internet Draft draft-ietf-ngtrans-bgp-tunnel-02.txt June 2001 techniques than MPLS. 4. 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 also has 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. Note also that one IPv6 island can contain multiple IPv6 sites. The method in this document can be used for customers that have already an IPv4 service from the network provider and require an upgrade to an IPv6 service, as well as for customers that require only IPv6 connectivity. In both cases the network provider allocates global IPv6 addresses to the site. It is assumed that all nodes in the IPv6 island have a global IPv6 address. 5. IPv6 Prefix Distribution Between a CE router and a PE router, routing protocols can be used to convey IPv6 site prefixes to the ISP and vice versa. For the mechanism described here, there is no specific requirement towards these protocols. Following the IPv6 addressing for global unicast aggregatable address [GUCST], the ISP is likely to have delegated some of its address space to the customer. Outbound traffic of an Ooms Expires December 2001 [Page 4] Internet Draft draft-ietf-ngtrans-bgp-tunnel-02.txt June 2001 IPv6 site is sent to one of the CE routers (and therefore to the associated PE routers). The distribution of IPv6 island prefixes to the other IPv6 islands happens via [MP-BGP] in which the Next Hop address is the v6[v4]addresses of the advertising DS-BGP router. The session between IBGP peers is transported over IPv4. The MP-BGP AFI will be IPv6 (value 2). The SAFI depends on the specific details of the tunneling technique used. This is discussed below in tunnel technique specific sections. When the number of PEs is not too high, it is possible for PEs to peer in a mesh fashion. Otherwise Route Reflectors are used and the PEs are configured with some Route Reflector identity. 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 of the IPv6 islands in its domain and regular IPv6 routing will take place in between the two domains. 6. Tunneling The use of v6[v4]addresses allows 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. If this transition method 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 since those are automatic tunnels and thus require no configuration. Considerations on 'common tunneling techniques' and 'automatic Ooms Expires December 2001 [Page 5] Internet Draft draft-ietf-ngtrans-bgp-tunnel-02.txt June 2001 tunneling techniques' in [TRANS] are valid for the mechanism described in this document. 6.1. Tunneling over IPv4/GRE tunnels When tunneling is done using IPv4/GRE Tunnels, the SAFI used in MP- BGP will be one of the basic values: unicast, multicast or both (1,2 or 3). 6.2. Tunneling over IPv4 MPLS LSPs When the IPv4 backbone supports MPLS, IPv4 MPLS LSPs can be used as the tunneling technique. While the method defined in this document can operate using a single level of label, there are advantages in using a second level of label 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; 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 label is used and no label are 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 label 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. 7. Comparison to MPLS/BGP VPNs The described mechanism can be looked at as an instantiation of the solution for MPLS/BGP VPNs [VPN, V6VPN]. The method in this draft aims at enabling connections to the public IPv6 Internet, which could be viewed as one large 'public' VPN. Since there is only one VPN connecting hosts with globally unique addresses that do not need island-to-island security, things are much simplified: - Since the IPv6 addresses are globally unique, there is no need for a Route Distinguisher (RD). - No need for VPN Routing and Forwarding (VRF) tables, the route info is in the normal routing table and when the BGP Next Hop is a Ooms Expires December 2001 [Page 6] Internet Draft draft-ietf-ngtrans-bgp-tunnel-02.txt June 2001 v6[v4]address the data is tunneled to this Next Hop. - 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 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. Appendix A v6[v4]address 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 tunnels in [TRANS]). There is however the intention of at least part of the ngtrans community 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 requirement posed by the method in this draft on the v6[v4]address are: - there is NO need for the v6[v4]address to be routable - the IPv4 cloud could use private addresses, so it should be legal for a v6[v4]address to carry private v4 addresses Using ISATAP addresses would require an additional /64 prefix per island (the latest ISATAP draft states that one has to use a different /64 prefix for ISATAP addresses and native v6 addresses). Using 6to4 addresses require that the embedded IPv4 address is a global address (which is a too strict requirement for the approach in this draft). Ooms Expires December 2001 [Page 7] Internet Draft draft-ietf-ngtrans-bgp-tunnel-02.txt June 2001 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. [GUCST] Deering, S., R. Hinden, and M. O'dell, "An IPv6 Aggregatable Global Unicast Address Format" , RFC2374. [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- rosen-rfc2547bis-02.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-02.txt (work in progress). [V6VPN] Nguyen T., Gastaud G., Ooms D.,"BGP-MPLS VPN extension for IPv6 VPN over an IPv4 infrastructure", draft-nguyen-bgp-ipv6-vpn- 00.txt (work in progress). Ooms Expires December 2001 [Page 8] Internet Draft draft-ietf-ngtrans-bgp-tunnel-02.txt June 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 Futures Testbed, B29 Room 136, BT Adastral Park, 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 December 2001 [Page 9]