idnits 2.17.1 draft-lefaucheur-bgp-tunnel-transition-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 390 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([BGP-TUNNEL]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '6to4' is mentioned on line 181, but not defined == Unused Reference: '6TO4' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'V6ADDR' is defined on line 293, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2858 (ref. 'MP-BGP') (Obsoleted by RFC 4760) -- Possible downref: Normative reference to a draft: ref. 'BGP-TUNNEL' == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-02 ** Downref: Normative reference to an Experimental draft: draft-ietf-ngtrans-isatap (ref. 'ISATAP') == Outdated reference: A later version (-10) exists of draft-ietf-ipngwg-addr-arch-v3-07 -- No information found for draft-ietf-ppvpn-rfc2547bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MPLS-VPN' -- No information found for draft-ietf-ppvpn-bgp-ipv6-vpn - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IPv6-MPLS-VPN' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Francois Le Faucheur, 3 Cisco Systems, Inc. 5 IETF Internet Draft 6 Expires: December, 2002 7 Document: draft-lefaucheur-bgp-tunnel-transition-00.txt June, 2002 9 Operational Environments and Transition Scenarios 10 for 11 "Connecting IPv6 Islands across IPv4 Clouds with BGP" 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are 17 Working documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes the common operational environments of IPv4 34 Service Providers wanting to add IPv6 services to their service 35 portfolio but not wanting (yet) to upgrade their IPv4 backbone to 36 IPv6 routing. 38 Two main transition scenarios are identified. 40 We recommend that the "MP-BGP over IPv6" and "MP-BGP over IPv4" 41 approaches defined in [BGP-TUNNEL] be respectively used for each of 42 the two transition scenarios. 44 1. Introduction 46 Le Faucheur 1 48 BGP Tunnel Transition June 2002 50 Many IPv4 Service Providers are considering/willing to complement 51 their service portfolio by some IPv6 services. We first describe such 52 operational environments in more details and then discuss the two 53 main transition scenarios identified for such operational 54 environments. 56 2. Operational Environments 58 A Service Provider (SP) runs an IPv4 backbone and offers IPv4 59 services. This Service Providers makes extensive use of BGP for 60 exchange of IPv4 reachability information: 61 - IPv4 connection with upstream/peer Internet Service Providers 62 (eBGP) 63 - IPv4 connection with some end-users IPv4 sites (eBGP) 64 - Distribution of IPv4 reachability information inside the SP's 65 backbone (iBGP over TCP/IPv4). 67 The Service Provider is obviously very familiar with BGP. The Service 68 Provider may also be very familiar with MP-BGP (e.g. support of 69 inter-domain IPv4 Multicast service or support of MPLS VPN service 70 [MPLS-VPN]). 72 This environment can be illustrated in the following way: 74 +------------+ +----------+ +-----------------+ 75 |IPv4 site A |--eBGP--| |--eBGP--|IPv4 Upstream ISP| 76 +------------+ | SP's | +-----------------+ 77 | IPv4 | 78 +------------+ | Backbone | +----------------+ 79 |IPv4 site B |--------| |--eBGP---| IPv4 Peer ISP | 80 +------------+ | iBGP | +----------------+ 81 +----------+ 83 Now, the SP wants to broaden his/her service offering by adding some 84 IPv6 services such as IPv6 connectivity across multiple IPv6 sites of 85 an end user, and/or global IPv6 connectivity (i.e. access to the IPv6 86 Internet). 88 All the exchange of IPv6 routing information at the edge of the SP 89 backbone uses standardized native IPv6 routing: 90 - the SP provides global IPv6 connectivity through his/her IPv6 91 customer relationship with an upstream ISP, or by peering 92 relationships with other IPv6 ISPs in the default free 93 routing zone (DFZ). Such peering uses MP-eBGP ([MP-BGP], 94 [IPv6-MP-BGP)] for IPv6. It is used by the Service Provider 95 to advertise IPv6 reachability of its IPv6 allocated prefix 96 and to receive reachability for the IPv6 internet. 97 - An IPv6 routing protocol (IGPv6 or MP-eBGP for IPv6) may run 98 between IPv6 Site and the SP's network so that the IPv6 Site 99 advertises its IPv6 reachability and receives IPv6 101 Le Faucheur 2 103 BGP Tunnel Transition June 2002 105 reachability information from the SP. Alternatively, static 106 IPv6 routes and/or a default IPv6 route may be used to 107 control such reachability. 109 But the SP does not yet want to upgrade his/her backbone to IPv6. So 110 native IPv6 routing is NOT used inside the SP's backbone. 112 The new environment can be illustrated in the following way: 114 +------------+ +----------+ +-----------------+ 115 |IPv4 site A |--eBGP--| |--eBGP--|IPv4 Upstream ISP| 116 +------------+ | SP's | +-----------------+ 117 | IPv4 | 118 +------------+ | Backbone | +----------------+ 119 |IPv4 site B |--------| |--eBGP---| IPv4 Peer ISP | 120 +------------+ | | +----------------+ 121 | | 122 +------------+ | iBGP | +-----------------+ 123 |IPv6 site C |MP-eBGP-| |-MP-eBGP-|IPv6 Upstream ISP| 124 +------------+ | | +-----------------+ 125 | | 126 +------------+ | | +----------------+ 127 |IPv6 site D |--------| |-MP-eBGP-| IPv6 Peer ISP | 128 +------------+ | | +----------------+ 129 +----------+ 131 In such an environment, the SP needs to find a transition solution 132 until he/she is ready to upgrade the backbone to native IPv6 routing. 133 The transition solution needs to: 134 - distribute IPv6 reachability information over his/her non- 135 IPv6 backbone 136 - tunnel IPv6 traffic inside his/her IPv4 backbone. 138 We feel such operational environments are very common and require 139 clearly documented transition approaches. 141 3. Transition Scenarios 143 We identify two main transition scenarios for such environments. 145 3.1. Use of existing IPv6 Tunneling Techniques 147 In this scenario, the SP's operational constraints are such that: 148 - it is acceptable/desirable to establish a set of MP-iBGP 149 peerings (MP-iBGP mesh or MP-iBGP Route Reflector structure) 150 over TCP/IPv6, in addition to the existing set of iBGP 151 peerings (iBGP mesh or iBGP Route Reflector structure) over 152 TCP/IPv4. 153 AND, 155 Le Faucheur 3 157 BGP Tunnel Transition June 2002 159 - it is acceptable/desirable to use one of the existing NGTRANS 160 tunneling techniques ([6to4], [ISATAP],...) to achieve IPv6 161 reachability of the MP-BGP Next Hops over the IPv4 backbone. 162 Note that this tunneling technique is ONLY needed for IPv6 163 reachability of the MP-BGP Next Hops at the edge of the SP 164 network and is NOT needed for IPv6 reachability of the IPv6 165 Internet or IPv6 end user sites. The latter can be achieved 166 via native IPv6 MP-iBGP routing among the MP-BGP Next Hops 167 once those are granted IPv6 reachability. Note that this 168 means that the inherent characteristics of such existing 169 methods (e.g. use of special IPv6 addresses as with ISATAP, 170 need for some configuration,...) are acceptable/desirable. 171 AND, 172 - The potential optimization of tunneling overhead achievable 173 in some situations is not acceptable/desirable for tunneling 174 of all the IPv6 traffic. For example, if the IPv4 backbone is 175 also running MPLS, use of existing NGTRANS tunneling results 176 in every IPv6 packets being effectively prepanded with both 177 an IPv4 and an MPLS header. 179 In this scenario, transition can be supported using purely existing 180 IPNG and NGTRANS techniques combined in the following manner: 181 - one existing NGTRANS tunneling technique ([6to4], 182 [ISATAP],...) is used to provide IPv6 reachability among MP- 183 iBGP Next Hops at the edge of the SPs' network 184 - this reachability is used to build a set TCP/IPv6 connections 185 for MP-iBGP peering among these MP-iBGP Next Hops (and 186 possibly Route Reflectors), in addition to the existing set 187 of TCP/IPv4 connections for the iBGP peerings. 188 - existing MP-iBGP ([MP-BGP], [IPv6-MP-BGP])is used among those 189 MP-iBGP Next Hops at the edge of the SP's network to 190 establish MP-IBGP peerings and to exchange all the IPv6 191 reachability information. This is in addition to the existing 192 iBGP peerings. 193 - IPv6 packets are tunneled between the MP-iBGP routers at the 194 edge of the IPv4 backbone using the selected existing NGTRANS 195 tunneling technique and by performing this tunneling as if 196 the packet was addressed to the MP-iBGP Next Hop Router 197 advertised for the relevant IPv6 prefix. In other words, the 198 tunnel IPv4 destination and the IPv4 tunnel header are not 199 selected directly based on the destination IPv6 address but 200 selected based on the IPv6 address of the MP-iBGP Next Hop 201 router advertised in MP-iBGP for the relevant IPv6 prefix. 203 This transition approach is referred to as the "MP-BGP over IPv6" 204 approach and is further documented in [BGP-TUNNEL]. 206 3.2. "Auto tunneling" 208 In this scenario, the SP's operational constraints are such that: 209 - it is desirable to use the existing set of iBGP peerings 210 (iBGP mesh or iBGP Route Reflector structure) over TCP/IPv4 212 Le Faucheur 4 214 BGP Tunnel Transition June 2002 216 to distribute reachability of all services (IPv4, IPv6 , and 217 VPN-IPV4 if MPLS VPN services is also supported). 218 OR, 219 - a form of transparent automatic tunneling into IPv4 is 220 desirable so that no configuration is required on the MP-BGP 221 Next Hop routers at the edge of the SP network to 222 activate/control tunneling, nor any constraints imposed on 223 the IPv6 addresses used for these MP-BGP Next Hops. 224 OR, 225 - The potential optimization of tunneling overhead achievable 226 in some situations is desirable for tunneling of all the IPv6 227 traffic. For example, if the IPv4 backbone is also running 228 MPLS, IPv6 packets should only be prepanded by an MPLS header 229 and not by an IPv4 header plus an MPLS header. 231 In this scenario, transition can be supported using existing IPNG and 232 NGTRANS techniques combined in the following manner: 233 - The existing set of TCP/IPv4 connections and iBGP peering is 234 used to also advertise IPv6 reachability via MP-iBGP ([MP- 235 BGP], [IPv6-MP-BGP]) among the MP-iBGP Next Hops at the edge 236 of the network (and possibly Route Reflectors) 237 - An MP-iBGP Next Hop advertising IPv6 reachability information 238 uses the IPv4-mapped IPv6 address format ([V6ADDR]} to convey 239 its IPv4 address as the Next Hop Address. 240 - The MP-iBGP Next Hops receiving IPv6 reachability 241 information, use the IPv4 address contained in this IPv4- 242 mapped address, as the destination address of the IPv4 tunnel 243 to tunnel the corresponding IPv6 packets into, thus achieving 244 automatic tunneling. 246 This transition approach is referred to as the "MP-BGP over IPv4" 247 approach and is further documented in [BGP-TUNNEL]. 249 4. Recommendation on Transition 251 We recommend that the "MP-BGP over IPv6" and "MP-BGP over IPv4" 252 approaches defined in [BGP-TUNNEL] be respectively used for each of 253 the two main transition scenarios described above. 255 We also observe that these approaches could also naturally 256 accommodate a possible additional transition step which would be to 257 complement the SP's service offering by an IPv6 MPLS VPN service 258 [IPv6-MPLS-VPN] by simply supporting the IPv6-VPN address family in 259 addition to the IPv6 address family in the same MP-iBGP peerings. 261 5. Security Considerations 263 No new security considerations are raised by this document. Those are 264 the same as the ones of BGP and can be addressed through the 265 corresponding mechanisms. 267 Le Faucheur 5 269 BGP Tunnel Transition June 2002 271 6. Acknowledgments 273 We thank Jeremy De Clercq and Benoit Lourdelet for their review and 274 suggestions. 276 References 278 [MP-BGP] T. Bates et al, "Multiprotocol Extensions for BGP-4", 279 RFC2858. 281 [IPv6-MP-BGP] Marques, P., and et.al , Use of BGP-4 Multiprotocol 282 Extensions for IPv6 Inter-Domain Routing, RFC 2545, March 1999. 284 [BGP-TUNNEL]. Ooms et al, Connecting IPv6 Islands across IPv4 Clouds 285 with BGP, draft-ietf-ngtrans-bgp-tunnel-04.txt, January 2002. 287 [6TO4] B. Carpenter, K. Moore, "Connection of IPv6 domains via IPv4 288 Clouds", RFC3056, February 2001. 290 [ISATAP] F. Templin, "Intra-Site Automatic Tunnel Addressing Protocol 291 (ISATAP), draft-ietf-ngtrans-isatap-02.txt (work in progress). 293 [V6ADDR] Deering, S., and R. Hinden, "IP Version 6 Addressing 294 Architecture", draft-ietf-ipngwg-addr-arch-v3-07.txt (work in 295 progress). 297 [MPLS-VPN] Rosen E., Rekhter Y., Brannon S., Chase C., De Clercq J., 298 Hitchin P., Marshall , Srinivasan V., "BGP/MPLS VPNs", 299 draft-ietf-ppvpn-rfc2547bis-00.txt (work in progress). 301 [IPv6-MPLS-VPN] Nguyen T., Gastaud G., De Clercq J., Ooms D.,"BGP- 302 MPLS VPN extension for IPv6 VPN over an IPv4 infrastructure", 303 draft-ietf-ppvpn-bgp-ipv6-vpn-01.txt> (work in progress). 305 Author's Address: 307 Francois Le Faucheur 308 Cisco Systems, Inc. 309 Village d'Entreprise Green Side - Batiment T3 310 400, Avenue de Roumanille 311 06410 Biot-Sophia Antipolis 312 France 313 Phone: +33 4 97 23 26 19 314 Email: flefauch@cisco.com 316 Le Faucheur 6