idnits 2.17.1 draft-li-bess-4pe-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1. Exchange IPv4 reachability information among 4PE routers with MP-BGP [RFC4760] The IPv4 routes MUST not be injected in the IPv6-only MPLS network. -- The document date (March 9, 2017) is 2605 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BGP Enabled Services Z. Li 3 Internet-Draft China Mobile 4 Intended status: Standards Track March 9, 2017 5 Expires: September 10, 2017 7 Connecting IPv4 Islands over IPv6 MPLS Using IPv4 Provider Edge Routers 8 (4PE) 9 draft-li-bess-4pe-02 11 Abstract 13 This document explains how to interconnect IPv4 islands over a 14 Multiprotocol Label Switching (MPLS)-enabled IPv6-only core. This 15 approach relies on IPv4 Provider Edge routers (4PE), which are Dual 16 Stacks in order to connect to IPv4 islands and to the MPLS core. The 17 4PE routers exchange the IPv4 reachability information transparently 18 over the core using the Multiprotocol Border Gateway Protocol (MP- 19 BGP). MP-BGP is extended to do this. A new Subsequence Address 20 Family Identifier (SAFI) with corresponding new format Network Layer 21 Reachability Information (NLRI), is introduced. The BGP Next Hop 22 field is used to convey the IPv4 address of the 4PE router, a field 23 is added in Network Layer Reachability Information (NLRI) to convey 24 the IPv6 address of the 4PE router, so that dynamically established 25 IPv6-signaled MPLS Label Switched Paths (LSPs) can be used without 26 explicit tunnel configuration. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 10, 2017. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 69 3. 4PE SAFI . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Exchange IPv4 reachability information among 4PE routers . . 6 71 5. Transport IPv4 packets among 4PE routers . . . . . . . . . . 7 72 6. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 8 73 7. Security Consideration . . . . . . . . . . . . . . . . . . . 8 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 8.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 After IPv6 [RFC2460] is widely deployed, IPv6-only networks and nodes 82 will become dominate. How to provide the connectivity for the 83 remaining IPv4-only islands through the IPv6-only MPLS network will 84 become a problem, as depicted in the following figure. 86 +--------------+ 87 | IPv4-only | 88 | island A CE--4PE----------------+ 89 | | | | 90 +--------------+ | | +----------------+ 91 | IPv6-only | | | 92 | MPLS network 4PE--CE IPv4-only | 93 | | | island C | 94 +--------------+ | | +----------------+ 95 | IPv4-only | | | 96 | island B CE--4PE----------------+ 97 | | 98 +--------------+ 100 IPv6 Provider Edge Routers (6PE), as specified in [RFC4798], are used 101 to connect IPv6 islands over IPv4 MPLS network. However, [RFC7439] 102 pointed out that there is no solution to address the above problem. 103 So, in this document, 4PE is proposed to meet this gap. 105 2. Protocol Overview 107 Each IPv4 island is connected to at least one Provider Edge router 108 that is located on the border of the IPv6-only MPLS network. We call 109 such a router a IPv4 Provider Edge router (4PE). The 4PE router MUST 110 be IPv4 and IPv6 dual stack. At least one IPv4 address MUST be 111 configured for the 4PE to connect the IPv4-only island. And at least 112 one IPv6 address on the IPv6-ony MPLS network side MUST be 113 configured. The configured IPv6 address needs to be routable in the 114 IPv6-only network, and there needs to be a label bound via an IPv6 115 label distribution protocol to this IPv6 route. The configured IPv4 116 address MUST be unique among the IPv4 islands. 118 As a result of this, every considered 4PE router knows which MPLS 119 label (we call it forwarding label) to use to send packets to any 120 other 4PE router. Note that [RFC5036] updated by [RFC7552] fulfills 121 these requirements. 123 We call the 4PE router receiving IPv4 packets from an IPv4 island an 124 ingress 4PE router (relative to these IPv4 packets). We call a 4PE 125 router forwarding IPv4 packets to an IPv4 island an egress 4PE router 126 (relative to these IPv4 packets). 128 Interconnecting IPv4 islands over an IPv6 MPLS network mainly 129 includes the following two steps: 131 1. Exchange IPv4 reachability information among 4PE routers with MP- 132 BGP [RFC4760] 133 The IPv4 routes MUST not be injected in the IPv6-only MPLS 134 network. 136 The 4PE routers MUST exchange the IPv4 routes over MP-BGP 137 sessions running over IPv6. To do so, a new Subsequence 138 Address Family Identifier (SAFI) with corresponding new format 139 Network Layer Reachability Information (NLRI), is introduced 140 in this document. We call this new SAFI 4PE SAFI, the detail 141 of which is illustrated in section 3. The MP-BGP Address 142 Family Identifier (AFI) used MUST be IPv4 (value 1). The MP- 143 BGP Network Address of Next Hop MUST be the 4PE IPv4 address 144 from which the 4PE receives the IPv4 routes of the IPv4 145 island. The IPv6 address of the 4PE, the IPv4 routes of the 146 IPv4 island, and the corresponding MPLS label for the IPv4 147 routes (we call it 4PE label) MUST be encoded in the NLRI. 149 The reason to allocate MPLS label for the IPv4 route is to 150 reduce the requirements for the IPv6-only MPLS network, as 151 explained in [RFC4798]. Here it is. While this approach 152 could theoretically operate in some situations using a single 153 level of labels, there are significant advantages in using a 154 second level of labels that are bound to IPv4 prefixes via MP- 155 BGP advertisements. 157 For instance, the use of a second level label allows 158 Penultimate Hop Popping (PHP) on the IPv6 Label Switch Router 159 (LSR) upstream of the egress 4PE router, without any IPv4 160 capabilities on the penultimate router. This is because it 161 still transmits MPLS packets even after the PHP (instead of 162 having to transmit IPv4 packets and encapsulate them 163 appropriately). 165 2. Transport IPv4 packets from the ingress 4PE router to the egress 166 4PE router over the IPv6-signaled LSPs 168 The ingress 4PE router MUST forward IPv4 data over the 169 IPv6-signaled LSP towards the egress 4PE router identified by 170 the IPv6 address advertised in the new introduced NLRI for the 171 corresponding IPv4 route. 173 3. 4PE SAFI 175 As depicted in the following figure, 4PE SAFI is proposed to carry 176 the IPv4 routes for the IPv4-only island, the MPLS label for the IPv4 177 routes, the IPv4 and IPv6 IP addresses of the 4PE router. 179 +---------------------------------------------------------+ 180 | Address Family Identifier (2 octets) | 181 +---------------------------------------------------------+ 182 | Subsequent Address Family Identifier (1 octet) | 183 +---------------------------------------------------------+ 184 | Length of Next Hop Network Address (1 octet) | 185 +---------------------------------------------------------+ 186 | Network Address of Next Hop (variable) | 187 +---------------------------------------------------------+ 188 | Reserved (1 octet) | 189 +---------------------------------------------------------+ 190 | Network Layer Reachability Information (variable) | 191 +---------------------------------------------------------+ 193 The use and meaning of these fields are as follows: 195 Address Family Identifier (AFI): 197 This field MUST be 1, to indicate IPv4 routes are carried in 198 the NLRI. This is in accordance with [RFC4760] 200 Subsequent Address Family Identifier (SAFI): 202 This field is used to indicate the new introduced 4PE SAFI. 203 The value for this field is be assigned by IANA. 205 Length of Next Hop Network Address: 207 This field MUST be 4, to indicate an IPv4 address is encoded in 208 the "Network Address of Next Hop" field. 210 Network Address of Next Hop: 212 This field MUST be one of the 4PE IPv4 address from which the 213 4PE receives the IPv4 routes of the IPv4 island. 215 Reserved: 217 A 1 octet field that MUST be set to 0, and SHOULD be ignored 218 upon receipt. 220 Network Layer Reachability Information (NLRI): 222 The format and meaning of this field is specified in the 223 following. 225 +---------------------------+ 226 | IPv6 Next Hop (16 octets) | 227 +---------------------------+ 228 | Length (1 octet) | 229 +---------------------------+ 230 | Label (3 octets) | 231 +---------------------------+ 232 ............................. 233 +---------------------------+ 234 | Prefix (variable) | 235 +---------------------------+ 237 The "IPv6 Next Hop" field MUST be the IPv6 address of the 4PE, 238 through which the corresponding 4PE can be reached in the 239 IPv6-only MPLS network. 241 The "Label" field MUST be the MPLS label allocated by the 4PE 242 for the IPv4 routes carried in the Prefix field. This label is 243 called 4PE label. 245 The "Prefix" field MUST be used to carry the IPv4 routes for 246 the IPv4-only island. 248 The "Length" field indicates the length in bits of the Prefix 249 plus the Label. 251 One or more triples of the form can be 252 encoded in this NLRI. The use and meaning of the fields in 253 this NLRI, except IPv6 Next Hop, are in accordance with 254 [RFC3107]. 256 4. Exchange IPv4 reachability information among 4PE routers 258 4PE routers MUST encode the IPv4 routes for the IPv4-only island in 259 the UPDATE message of [RFC4271]. MP_REACH_NLRI (Type Code 14) and 260 MP_UNREACH_NLRI (Type Code 15) defined in [RFC4760] MUST be used for 261 route advertisement and withdraw respectively. 4PE SAFI defined in 262 this document MUST be used in MP_REACH_NLRI or MP_UNREACH_NLRI to 263 complete the exchange of IPv4 routes. 265 For advertisement, the 4PE router sets the fields of MP_REACH_NLRI as 266 following, and then send the UPDATE message to its 4PE peers (or 267 Route Reflectors(RR) in the network where RRs are deployed) over the 268 MP-BGP session established on IPv6. 270 +--------------------------------------------------------------+ 271 | Address Family Identifier (2 octets, value = 1) | 272 +--------------------------------------------------------------+ 273 | Subsequent Address Family Identifier | 274 | (1 octet, value = 4PE SAFI ) | 275 +--------------------------------------------------------------+ 276 | Length of Next Hop Network Address (1 octet, value = 4) | 277 +--------------------------------------------------------------+ 278 | Network Address of Next Hop (variable, value = IPv4 address | 279 | of 4PE router, from which IPv4 routes are received) | 280 +--------------------------------------------------------------+ 281 | Reserved (1 octet, value = 0) | 282 +--------------------------------------------------------------+ 283 | IPv6 Next Hop (16 octets, value = IPv6 address of the 4PE | 284 | router, through which the 4PE can be reached in the | 285 | IPv6-only MPLS network) | 286 +--------------------------------------------------------------+ 287 | Length (1 octet, | 288 | value = the length in bits of the Prefix plus the Label) | 289 +--------------------------------------------------------------+ 290 | Label (3 octets, value = MPLS label allocated by the 4PE | 291 | router for the IPv4 routes carried in the Prefix field) | 292 +--------------------------------------------------------------+ 293 | Prefix (variable, | 294 | value = the IPv4 route to be carried to 4PE MP-BGP peers) | 295 +--------------------------------------------------------------+ 296 ......... (if needed, more triples of 297 ......... can be encoded here) 298 +--------------------------------------------------------------+ 300 When receiving the UPDATE message, the 4PE MP-BGP peer treats the 301 message as per [RFC4760] and [RFC3107]. Since the 4PE router can 302 learn IPv4 routes from other 4PE routers through 4PE SAFI defined in 303 this document, and from the IPv4-only island directly connected to 304 it, 4PE routers MUST distinguish those two kinds of IPv4 routes. 305 Further, the 4PE MP-BGP peer MUST establish the relation between 306 Network Address of Next Hop and IPv6 Next Hop carried in the 4PE 307 SAFI. Through this relation, 4PE routers can get IPv6 Next Hop using 308 Network Address of Next Hop. The method or data structure used to do 309 this is out of scope of this document. 311 5. Transport IPv4 packets among 4PE routers 313 When ingress 4PE router receives IPv4 packet, it treats the IPv4 314 packet as normal IPv4 router does except for the following steps. If 315 the matching IPv4 route for this packet is learned from other 4PE 316 routers through the 4PE SAFI defined in this document, the 4PE router 317 has further to get the IPv6 Next Hop using the IPv4 next hop of the 318 matching IPv4 route. Then, ingress 4PE router uses the IPv6 Next Hop 319 to lookup in its IPv6 routing table to get the IPv6-signaled LSP to 320 reach the egress 4PE router. Next, ingress 4PE router encapsulates 321 the received IPv4 packet using two labels as shown in the figure 322 below. Finally, ingress 4PE router forwards the encapsulated packet 323 to egress 4PE router through the IPv6-signaled LSP. 325 +------------------------+ 326 | Forwarding label | 327 +------------------------+ 328 | 4PE label | 329 +------------------------+ 330 | IPv4 packet | 331 +------------------------+ 333 When the packet reaches egress 4PE router, only 4PE label is left 334 since the forwarding label is popped up by the penultimate hop toward 335 egress 4PE router. Egress 4PE router pops up the 4PE label, looks up 336 in the IPv4 routing table using the destination address of the IPv4 337 packet, and then forwards the IPv4 packets to the IPv4-only island. 339 6. IANA Requirements 341 IANA is requested to assign a new SAFI for the 4PE SAFI from range 342 1-63, the registy of Subsequent Address Family Identifiers (SAFI) 343 Parameters. 4PE routers use this SAFI to transport IPv4 routes, the 344 corresponding MPLS label, IPv4 and IPv6 next hop addresses among 4PE 345 routers. 347 7. Security Consideration 349 This document raises no new security issues. 351 8. References 353 8.1. Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 361 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 362 December 1998, . 364 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 365 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 366 . 368 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 369 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 370 DOI 10.17487/RFC4271, January 2006, 371 . 373 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 374 "Multiprotocol Extensions for BGP-4", RFC 4760, 375 DOI 10.17487/RFC4760, January 2007, 376 . 378 8.2. Informative References 380 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 381 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 382 Provider Edge Routers (6PE)", RFC 4798, 383 DOI 10.17487/RFC4798, February 2007, 384 . 386 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 387 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 388 October 2007, . 390 [RFC7439] George, W., Ed. and C. Pignataro, Ed., "Gap Analysis for 391 Operating IPv6-Only MPLS Networks", RFC 7439, 392 DOI 10.17487/RFC7439, January 2015, 393 . 395 [RFC7552] Asati, R., Pignataro, C., Raza, K., Manral, V., and R. 396 Papneja, "Updates to LDP for IPv6", RFC 7552, 397 DOI 10.17487/RFC7552, June 2015, 398 . 400 Author's Address 402 Zhenqiang Li 403 China Mobile 404 No.32 Xuanwumenxi Ave., Xicheng District 405 Beijing 100032 406 P.R. China 408 Email: li_zhenqiang@hotmail.com