idnits 2.17.1 draft-ooms-v6ops-bgp-tunnel-02.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 162: '... router MUST have at least one IPv4 ...' RFC 2119 keyword, line 163: '... The IPv4 address MUST be routable in...' RFC 2119 keyword, line 200: '...e DS-BGP routers MUST run MP-BGP over ...' RFC 2119 keyword, line 214: '... MP-BGP next hop MUST be encoded as an...' RFC 2119 keyword, line 217: '...ss DS-BGP Router MUST tunnel IPv6 data...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 308 has weird spacing: '...of LSPs acros...' -- 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: 'KEYWRD' is mentioned on line 95, but not defined == Missing Reference: 'MP-BGP' is mentioned on line 188, but not defined == Missing Reference: 'V6ADDR' is mentioned on line 205, but not defined == Missing Reference: 'MPLS-STACK' is mentioned on line 272, but not defined == Unused Reference: 'ISATAP' is defined on line 358, but no explicit reference was found in the text == Unused Reference: 'V6VPN' is defined on line 365, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3107 (ref. 'LABEL') (Obsoleted by RFC 8277) == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-02 -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. 'TRANS') (Obsoleted by RFC 4213) -- No information found for draft-ietf-ppvpn-bgp-ipv6-vpn - is the name correct? -- No information found for draft-ietf-ppvpn-rfc2547bis - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT J. De Clercq, D. Ooms 3 Alcatel 4 S. Prevost 5 BTexact 6 F. Le Faucheur 7 Cisco 8 March, 2004 9 Expires September, 2004 11 Connecting IPv6 Islands across IPv4 MPLS 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. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document explains how to interconnect IPv6 islands over an 37 MPLS-enabled IPv4 cloud, including the exchange of IPv6 reachability 38 information using BGP. The approach requires the edge routers that 39 are connected to IPv6 islands to be Dual Stack MP-BGP-speaking 40 routers while the core routers are only required to run IPv4 MPLS. 41 The hosts in the IPv6 islands can use native IPv6 addresses. The 42 approach uses MP-BGP over IPv4, relies on identification of the MP- 43 BGP-speaking edge routers by their IPv4 address and uses IPv4- 44 signaled MPLS LSPs that don't require any explicit tunnel 45 configuration. 47 Table of Contents 49 1. Introduction 50 2. Terminology 51 3. Applicability 52 4. Description 53 5. Tunneling 54 6. Crossing multiple IPv4 domains 55 7. Security considerations 57 Changes 58 ngtrans history (draft-ietf-ngtrans-bgp-tunnel-0x.txt) 59 00->01: editorial changes 60 extended section 4 61 01->02: editorial changes 62 added tunnel-specific considerations 63 added case of multiple IPv4 domains between IPv6 islands 64 added discussion on v6[v4]addresses in appendix A 65 02->03: complete rewrite: it turned out that two interpretations of the 66 previous drafts existed, the two different interpretations are 67 described explicitly in this version 68 03->04: renaming of the two approaches 69 editorial changes 70 clearly indicate which part requires standards track 71 04->05: added 5.1.3 to clarify how DS-BGP routers agree on tunnel type 73 v6ops history (draft-ooms-v6ops-bgp-tunnel-0x.txt) 74 05->00 individual submission: no changes. The document passed ngtrans 75 last call early 2002, but the transfer to the IESG was postponed because 76 of the reorg and closing down of ngtrans. 77 00->01 no changes 78 01->02 according to v6ops mailing list discussion, the scope of the 79 document was restricted to the "MP-BGP over IPv4 using LSPs" approach. 81 1. Introduction 83 This document explains how to interconnect IPv6 islands over an IPv4 84 cloud, including the exchange of IPv6 reachability information using 85 BGP. The approach requires the edge routers that are connected to 86 IPv6 islands to be Dual Stack MP-BGP-speaking routers while the core 87 routers are only required to run IPv4 MPLS. The hosts in the IPv6 88 islands can use native IPv6 addresses. The approach uses MP-BGP over 89 IPv4, relies on identification of the MP-BGP-speaking edge routers by 90 their IPv4 address and uses IPv4-signaled MPLS LSPs that don't 91 require any explicit tunnel configuration. 93 The use of the keywords "MUST", "MAY", etc. is in accordance with 95 [KEYWRD]. 97 2. Terminology 99 The terminology of [IPV6] and [TRANS] applies to this document. We 100 also use some of the terminology of [VPN]. 102 In this document an 'IPv6 island' is an IPv6-upgraded network (which 103 can be cross-AS). A typical example of an island would be a Customer 104 IPv6 site connected via its IPv6 Customer Edge (CE) router to one (or 105 more) Dual Stack Provider Edge (PE) router(s) of a Service Provider. 107 +--------+ 108 |site A CE---+ +------------+ 109 +--------+ | | | +--------+ 110 PE-+ IPv4 core +-PE---CE site C | 111 +--------+ | | | +--------+ 112 |site B CE---+ +------------+ 113 +--------+ 115 IPv6 island IPv4 cloud IPv6 island 116 <-------------><----------------><-------------> 118 3. Applicability 120 The interconnection method described in this document typically 121 applies to an ISP that has an MPLS network and is familiar with BGP 122 (possibly already offering BGP/MPLS VPN services) and that wants to 123 offer IPv6 services to some of its customers. However, the ISP may 124 not (yet) want to upgrade its network core to native IPv6. With the 125 mechanisms described here, the provider only has to upgrade some 126 Provider Edge (PE) routers in some POPs to Dual Stack MP-BGP routers. 127 These Dual Stack MP-BGP routers provide connectivity to IPv6 islands. 128 They may also provide other services simultaneously (IPv4 129 connectivity, IPv4 L3VPN services, L2VPN services, etc.) 131 The ISP may also have access to the global IPv6 Internet. The ISP 132 provides global IPv6 connectivity through its peering relationship 133 with an upstream ISP, or by peering relationships with other IPv6 134 ISPs in the default free routing zone (DFZ). 136 A Dual Stack MP-BGP router in the provider's network is connected to 137 an upstream IPv6 ISP or forms part of the IPv6 backbone network, such 138 as the 6bone. The ISP advertises IPv6 reachability of its IPv6 139 allocated prefix using MP-BGP to its IPv6 upstream provider or into 140 the IPv6 DFZ. The IPv6 prefixes received from the upstream provider 141 or from the DFZ can be redistributed within the ISP using MP-BGP. 143 The interface between the edge router of the IPv6 island (Customer 144 Edge router or CE) and the PE router is a native IPv6 interface which 145 can be physical or logical. A routing protocol (IGP or EGP) may run 146 between the CE router and the PE router for the distribution of IPv6 147 reachability information. Alternatively, static routes and/or a 148 default route may be used on PE and CE to control reachability. An 149 IPv6 island may connect to the provider network over more than one 150 interface. 152 The methods in this document can be used for customers that already 153 have an IPv4 service from the network provider and additionally 154 require an IPv6 service, as well as for customers that require only 155 IPv6 connectivity. 157 4. Description 159 Each IPv6 site is connected to at least one Dual Stack MP-BGP- 160 speaking edge router that is located on the border with the IPv4 161 cloud. We refer to such a router as a DS-BGP router. The DS-BGP 162 router MUST have at least one IPv4 address on the IPv4 side and one 163 IPv6 address on the IPv6 side. The IPv4 address MUST be routable in 164 the IPv4 cloud. 166 The PE routers that are attached to IPv6 islands need to insert a 167 route (normally a /32 IPv4 address prefix) providing reachability to 168 themselves (i.e. to their "IPv4 address") into the IGP routing tables 169 of the IPv4 backbone. This enables MPLS, at each node in the backbone 170 network, to assign an MPLS label corresponding to the route to each 171 PE router. As a result of this, every considered PE router knows 172 which MPLS label to use to send packets to any other PE router. Note 173 that an MPLS network offering BGP/MPLS IP VPN services already 174 fulfills these requirements. 176 No extra routes will be injected in the IPv4 cloud. 178 We refer to the DS-BGP router receiving IPv6 packets from an IPv6 179 site as an Ingress DS-BGP router (relative to these IPv6 packets). We 180 refer to a DS-BGP router sending IPv6 packets to an IPv6 site as an 181 Egress DS-BGP router (relative to these IPv6 packets). 183 Interconnecting IPv6 islands over an IPv4 cloud requires following 184 steps: 186 (1) Exchange IPv6 reachability information among DS-BGP Routers: 188 (1.a) The DS-BGP routers exchange, via MP-BGP [MP-BGP], IPv6 189 reachability information over the IPv4 cloud with their peers. 191 (1.b) In doing so, the Egress DS-BGP routers announce themselves 192 as the BGP Next Hop. The Egress DS-BGP router conveys to its peer 193 its IPv4 address as the BGP Next Hop. 195 (2) Tunnel IPv6 packets from Ingress DS-BGP Router to Egress DS-BGP 196 Router: the Ingress DS-BGP router tunnels an IPv6 packet over the 197 MPLS IPv4 cloud towards the Egress DS-BGP router identified as the 198 BGP Next Hop in step (1.b) for the packet's destination IPv6 address. 200 With this approach, the DS-BGP routers MUST run MP-BGP over an IPv4 201 stack (MP-BGP/TCP/IPv4). 203 Since MP-BGP assumes that the BGP Next Hop is of the same address 204 family as the NLRI, this IPv4 address needs to be embedded in an IPv6 205 format. The IPv4-mapped IPv6 address is defined in [V6ADDR] as an 206 "address type used to represent the addresses of IPv4 nodes as IPv6 207 addresses", thus this precisely fits for the above purpose. Encoding 208 the routable IPv4 address into a IPv4-mapped IPv6 address allows the 209 remote DS-BGP router to automatically tunnel data over the IPv4 cloud 210 to the destination IPv6 island. Indeed, the IPv4 address contained in 211 the IPv4-mapped IPv6 BGP Next Hop identifies an MPLS LSP that leads 212 from the ingress PE router to the egress PE router. 214 The IPv4 address of the MP-BGP next hop MUST be encoded as an IPv4- 215 mapped IPv6 address. 217 The ingress DS-BGP Router MUST tunnel IPv6 data over the IPv4 LSP 218 towards the Egress DS-BGP router identified by the IPv4 address 219 advertised in the IPv4-mapped IPv6 address of the BGP Next Hop for 220 the corresponding IPv6 prefix. 222 The MP-BGP AFI MUST be IPv6 (value 2). The MP-BGP SAFI is discussed 223 below in the tunneling section. 225 When the number of PEs is not too high, PEs MAY peer in a meshed 226 fashion. Otherwise Route Reflectors MAY be used. 228 The hosts in the IPv6 island MAY have native IPv6 addresses. This is 229 different from e.g. 6to4 [6TO4], which requires that special 230 addresses (6to4 addresses) are allocated to the IPv6 hosts. 232 5. Tunneling over MPLS LSPs 234 In this approach, the IPv4-mapped IPv6 addresses allow a DS-BGP 235 router that has to forward a packet to automatically determine the 236 IPv4 endpoint of the tunnel by looking at the MP-BGP routing 237 information. 239 Note that even when the number of peers is high, the number of 240 tunnels is not a scalability concern from an operational viewpoint 241 since those are automatic tunnels and thus require no configuration. 243 Considerations on 'common tunneling techniques' in [TRANS] are valid 244 for this approach. 246 The IPv4 MPLS LSPs can be established using any existing technique 247 (LDP, RSVP-TE, ...). 249 When tunneling IPv6 packets over the IPv4 MPLS backbone, rather than 250 successively prepend an IPv4 header and then perform label imposition 251 based on the IPv4 header, the ingress DS-BGP Router MUST directly 252 perform label imposition of the IPv6 header without prepending any 253 IPv4 header. The (outer) label imposed corresponds to the IPv4 LSP 254 starting on the ingress DS-BGP Router and ending on the egress DS-BGP 255 Router. 257 While this approach could operate in some situations using a single 258 level of labels, there are significant advantages in using a second 259 level of labels which are bound to IPv6 prefixes via MP-BGP 260 advertisements in accordance with [LABEL]. For instance, use of a 261 second level label allows Penultimate Hop Popping (PHP) on the Label 262 Switch Router (LSR) upstream of the egress DS-BGP router without any 263 IPv6 capabilities/upgrade on the penultimate router even when the 264 IPv6 packet is directly encapsulated in MPLS (without an IPv4 265 header); since it still transmits MPLS packets even after the PHP 266 (instead of having to transmit IPv6 packets and encapsulate them 267 appropriately). Also, an existing IPv4 LSP which is using "IPv4 268 Explicit NULL label" over the last hop (say because that LSP is 269 already used to transport IPv4 traffic with the Pipe Diff-Serv 270 Tunneling Model as defined in [MPLS-DS]) could not be used to carry 271 IPv6 with a single label since the "IPv4 Explicit NULL label" can not 272 be used to carry native IPv6 traffic (see [MPLS-STACK]), while it 273 could be used to carry labeled IPv6 traffic (see [EXP-NULL]). Thus, 274 this approach MUST be used with a second label, advertised with BGP 275 in accordance with [LABEL]. 277 The SAFI used in MP-BGP MUST be the "label" SAFI (4) or the "VPN" 278 SAFI (128) depending on the procedures for allocating these labels. 279 The 'bottom label' (i.e. the second label when no PHP is used, or the 280 only remaining label when PHP is used) indicates to the Egress DS-BGP 281 Router that the packet is an IPv6 packet. The bottom label advertised 282 by the Egress DS-BGP Router with MP-BGP MAY be an arbitrary label 283 value and MAY identify an IPv6 routing context or outgoing interface 284 to send the packet to, or MAY be the IPv6 Explicit Null Label. An 285 Ingress DS-BGP Router MUST be able to accept any such advertised 286 label. 288 6. Crossing multiple IPv4 domains 290 When the IPv6 islands are separated by multiple IPv4 domains, two 291 cases can be distinguished: 293 1. The border routers between the IPv4 domains are not DS-BGP 294 routers, i.e they are IPv4-only BGP routers. The DS-BGP routers of 295 the IPv6 islands from the different IPv4 domains will be configured 296 as multi-hop MP-EBGP peers for the exchange of IPv6 reachability. 297 Alternatively, where the total number of such DS-BGP routers is high, 298 IPv6 reachability across domains can be achieved via MP-BGP 299 connection of Route Reflectors in different domains. One direct 300 inter-domain LSP per pair of such DS-BGP routers will effectively be 301 created. Note that the exchange of IPv6 routes can only start after 302 BGP has created IPv4 connectivity between the domains. 304 2. The border routers between the IPv4 domains are DS-BGP routers. 305 Each of these border DS-BGP routers will peer with the DS-BGP routers 306 in its domain and regular IPv6 routing will take place between the 307 two domains. No inter-domain LSPs are used. There is effectively a 308 separate mesh of LSPs across the DS-BGP Routers of each domain. 310 7. Security considerations 312 The extensions defined in this document allow BGP to propagate 313 reachability information about IPv6 routes over an IPv4 core. As 314 such, no new security issues are raised beyond those that already 315 exist in BGP-4 and use of MP-BGP for IPv6. 317 The security features of BGP and corresponding security policy 318 defined in the ISP domain are applicable. 320 Acknowledgement 322 We like to thank G. Gastaud who contributed to this document, and we 323 like to thank Tri T. Nguyen, who was the first to come up with the 324 idea described in this document, but who unfortunately passed away 325 much too soon. 327 Normative References 329 [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 330 (IPv6) Specification", RFC2460. 332 [KEYWRD]S. Bradner, Key words for use in RFCs to Indicate Requirement 333 Levels, RFC2119, March 1997. 335 [LABEL] Rekhter Y., E. Rosen, "Carrying Label Information in BGP-4", 336 RFC 3107, May 2001. 338 [MP-BGP]T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol 339 Extensions for BGP-4", RFC2858. 341 [V6ADDR]Deering, S., and R. Hinden, "IP Version 6 Addressing Archi- 342 tecture", draft-ietf-ipngwg-addr-arch-v3-07.txt (work in pro- 343 gress). 345 Informative References 347 [EXP-NULL] Rosen, E., et al., "Removing a Restriction on the use of 348 MPLS Explicit NULL", draft-rosen-mpls-explicit-null- 349 01.txt, work in progress 351 [6TO4] B. Carpenter, K. Moore, "Connection of IPv6 domains via 352 IPv4 Clouds", RFC3056, February 2001. 354 [MPLS-DS] Le Faucheur et al., "MPLS Support for DiffServ", RFC 3270 356 [MPLS-STACK]Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032 358 [ISATAP] F. Templin, "Intra-Site Automatic Tunnel Addressing Pro- 359 tocol (ISATAP), draft-ietf-ngtrans-isatap-02.txt (work in 360 progress). 362 [TRANS] R. Gilligan & E. Nordmark, "Transition Mechanisms for 363 IPv6 Hosts and Routers", RFC2893. 365 [V6VPN] Nguyen T., Gastaud G., De Clercq J., Ooms D.,"BGP-MPLS 366 VPN extension for IPv6 VPN over an IPv4 infrastructure", 367 draft-ietf-ppvpn-bgp-ipv6-vpn-01.txt> (work in progress). 369 [VPN] Rosen E., Rekhter Y., Brannon S., Chase C., De Clercq J., 370 Hitchin P., Marshall , Srinivasan V., "BGP/MPLS VPNs", 371 draft-ietf-ppvpn-rfc2547bis-00.txt (work in progress). 373 Authors' Addresses 375 Dirk Ooms 376 Alcatel 377 Fr. Wellesplein 1, 2018 Antwerp, Belgium 378 E-mail: dirk.ooms@alcatel.be 380 Jeremy De Clercq 381 Alcatel 382 Fr. Wellesplein 1, 2018 Antwerp, Belgium 383 E-mail: jeremy.de_clercq@alcatel.be 385 Stuart Prevost 386 BTexact Technologies 387 Room 136 Polaris House, Adastral Park, 388 Martlesham Heath, Ipswich, Suffolk IP5 3RE, England 389 E-mail: stuart.prevost@bt.com 391 Francois Le Faucheur 392 Cisco Systems 393 Domaine Green Side, 400, Avenue de Roumanille, Batiment T3 394 06 410 BIOT, SOPHIA ANTIPOLIS, FRANCE 395 E-mail: flefauch@cisco.com