idnits 2.17.1 draft-xie-6man-bier-encapsulation-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 6, 2018) is 2057 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) == Missing Reference: 'RFC3032' is mentioned on line 222, but not defined == Missing Reference: 'RFC6744' is mentioned on line 226, but not defined == Missing Reference: 'RFC2780' is mentioned on line 333, but not defined == Missing Reference: 'SL' is mentioned on line 371, but not defined -- Looks like a reference, but probably isn't: '0' on line 372 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-05 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-14 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track L. Geng 5 Expires: March 10, 2019 L. Wang 6 China Mobile 7 G. Yan 8 M. McBride 9 Y. Xia 10 Huawei 11 September 6, 2018 13 Encapsulation for BIER in Non-MPLS IPv6 Networks 14 draft-xie-6man-bier-encapsulation-02 16 Abstract 18 Bit Index Explicit Replication (BIER) introduces a new multicast- 19 specific BIER Header. Currently BIER has two types of encapsulation 20 formats: one is MPLS encapsulation, the other is Ethernet 21 encapsulation. This document proposes a BIER IPv6 encapsulation for 22 Non-MPLS IPv6 Networks using an IPv6 Destination Option extension 23 header. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 10, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Problem Statement and Requirements . . . . . . . . . . . . . 3 68 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 69 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 70 4. IPv6 BIER Encapsulation . . . . . . . . . . . . . . . . . . . 4 71 4.1. Considerations . . . . . . . . . . . . . . . . . . . . . 4 72 4.2. IPv6 BIER Destination Option . . . . . . . . . . . . . . 4 73 4.3. The whole IPv6 header for BIER packets . . . . . . . . . 5 74 5. IPv6 BIER Forwarding . . . . . . . . . . . . . . . . . . . . 6 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 9. Appendix A - BIER over IPv6 SRH Tunnel . . . . . . . . . . . 8 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 87 that provides optimal multicast forwarding without requiring 88 intermediate routers to maintain any per-flow state by using a 89 multicast-specific BIER header. [RFC8296] defines two types of BIER 90 encapsulation to run on physical links: one is BIER MPLS 91 encapsulation to run on various physical links that support MPLS, the 92 other is BIER Ethernet encapsulation to run on ethernet links, with 93 an ethertype 0xAB37. This document proposes a BIER IPv6 94 encapsulation for Non-MPLS IPv6 Networks using an IPv6 Destination 95 Option extension header. 97 2. Terminology 99 Readers of this document are assumed to be familiar with the 100 terminology and concepts of the documents listed as Normative 101 References. 103 3. Problem Statement and Requirements 105 3.1. Problem Statement 107 MPLS is a very popular and successful encapsulation. With MPLS 108 encapsulation, packets forwarding can not only run on various 109 physical links hop-by-hop, but also leverage the MPLS bypass tunnel 110 to gain the "fast reroute" capability. 112 This same label benefit is also available for BIER by using an MPLS 113 encapsulation. For example, an MPLS-encapsulated BIER packet can be 114 forwarding on various physical links hop-by-hop, as well as on any 115 MPLS bypass tunnels to support "fast reroute". 117 With a BIER Ethernet encapsulation, however, a packet can not be 118 forwarded on any other type of links except for ethernet links in 119 hop-by-hop case. It can not run on an MPLS bypass tunnel to support 120 "fast reroute" either. 122 In an IPv6 network, there are considerations of using a non-MPLS 123 encapsulation for unicast as the data-plane, such as SRH defined in 124 [I-D.ietf-6man-segment-routing-header], where the function of a 125 bypass tunnel uses an SRH header, with one or many Segments (or 126 SIDs), instead of MPLS Labels. In such case, it is expected to have 127 a BIER IPv6 encapsulation, which can run on IPv6 to be compliant with 128 various kind of physical link in hop-by-hop case, as well as on SRH 129 tunnel to have the significant benefit of "fast reroute" and so on. 131 3.2. Requirements 133 This chapter lists the BIER IPv6 encapsulation requirements needed to 134 make the deployment of BIER on IPv6 network with SRH data-plane the 135 same as on IPv4/IPv6 network with MPLS data-plane. These BIER IPv6 136 encapsulation requirements should provide similar benefits to MPLS 137 encapsulation such as "fast reroute" or "run on any link or 138 interface". 140 1. The listed requirements MUST be supported with any L1/L2 over 141 which BIER layer can be realized. 143 2. It SHOULD support a hop-by-hop replication to multiple 144 destinations in a BIER Domain. 146 3. It SHOULD support BIER on an "SRH tunnel". 148 4. It SHOULD align with the recommendations of the 6MAN working 149 group. 151 4. IPv6 BIER Encapsulation 153 4.1. Considerations 155 BIER is generally a hop-by-hop and one-to-many architecture, and thus 156 the IPv6 Destination Address (DA) being a Multicast Address is a 157 proper approach for both the two diagrams in BIER IPv6 encapsulation. 158 It is also required for a BIER IPv6 encapsulation to include the BIER 159 Header ([RFC8296]) as an IPv6 Extension Header, to pilot the hop-by- 160 hop BIER replication. 162 According to [RFC8200], [RFC6564], and [RFC7045], a new defined IPv6 163 extention header is not recommended, and an IPv6 Destination Option 164 extension header is suitable and recommended for such a well-known 165 BIER header as its Option. 167 4.2. IPv6 BIER Destination Option 169 The IPv6 BIER Destination Option is carried by the IPv6 Destination 170 Option Header (indicated by a Next Header value 60). It is 171 initialized in a packet sent by an IPv6 BFIR router to inform the 172 following BFR routers in an IPv6 BIER domain to replicate to 173 destination BFER routers hop-by-hop. 175 The IPv6 BIER Destination Option is encoded in type-length-value 176 (TLV) format as follows: 178 0 1 2 3 179 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Next Header | Hdr Ext Len | Option Type | Option Length | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | | 184 ~ Non-MPLS BIER Header (defined in RFC8296) ~ 185 | | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 1: IPv6 BIER Destination Option 190 Next Header 8-bit selector. Identifies the type of header 191 immediately following the Destination Options header. 193 Hdr Ext Len 8-bit unsigned integer. Length of the Destination 194 Options header in 8-octet units, not including the first 8 octets. 196 Option Type TBD. Need to be allocated by IANA. 198 Option Length 8-bit unsigned integer. Length of the option, in 199 octets, excluding the Option Type and Option Length fields. 201 Non-MPLS BIER Header The Non-MPLS BIER Header defined in RFC8296, 202 including the BIFT-id. The function of TTL field is replaced by 203 the Hop Limit field in IPv6 header and MUST be set to a non-zero 204 value. The function of Entropy field is replaced by the Flow 205 Label field in IPv6 header and MUST be set to zero value. 207 4.3. The whole IPv6 header for BIER packets 209 [RFC8200] specifies that the Destination Option Header can be located 210 either before the Routing Header or after the Routing Header. 211 However, this document requires that the Destination Option Header 212 with a BIER Destination Option TLV is always located after the 213 Routing Header if the Routing Header is present. 215 This is because the BIER header is always handled after the tunnels 216 (or bypass tunnels) have been handled. BIER MPLS encapsulation has 217 the same behavior. To quote [RFC8296]: 219 o It is crucial to understand that in an MPLS network the first four 220 octets of the BIER encapsulation header are also the last four 221 octets of the MPLS header. Therefore, any prior MPLS label stack 222 entries MUST have the S bit (see [RFC3032]) clear (i.e., the S bit 223 must be 0). 225 Other IPv6 extension headers are not commonly used in the current 226 Internet. For Example, [RFC6744] says that "IPv6 Destination Options 227 headers, and the options carried by such headers, are extremely 228 uncommon in the deployed Internet". [RFC6564] says that "Extension 229 headers, with the exception of the Hop-by-Hop Options header, are not 230 usually processed on intermediate nodes", and that "Reports from the 231 field indicate that some IP routers deployed within the global 232 Internet are configured either to ignore the presence of headers with 233 hop-by-hop behavior or to drop packets containing headers with hop- 234 by-hop behavior." 236 Such IPv6 extension headers will even be more uncommon when a BIER 237 encapsulation is used in data-plane forwarding. The entire IPv6 238 header, with BIER encapsulation and Routing Header, is expected to 239 look like this: 241 IPv6 header [Multicast Address in DA] 243 Hop-by-Hop Options header [No use] 245 Destination Options header [No use] 247 Routing header [SRH Header may be used, Appendix A] 249 Fragment header [No use ] 251 Authentication header [No use] 253 Encapsulating Security Payload header [No use] 255 Destination Options header [BIER header in BIER Option TLV] 257 Upper-layer header [BIER payload] 259 In a hop-by-hop BIER IPv6 replication scenario, there is only an IPv6 260 header with DA being a "BIER specific" Multicast address, and an IPv6 261 Destination Option header with a BIER destination option TLV. 263 BIER header has a 'proto' field to identify the type of BIER packet 264 payload, and the IANA has created a registry called "BIER Next 265 Protocol Identifiers" to assign the value. That means the 'Upper- 266 layer header' of a BIER packet have already been identified by the 267 'proto' field of the BIER header in the Destination Option Header. 268 Thus the 'Next Header' in the Destination Option Header is not need 269 to identify the 'Upper-layer header' any more, and is recommended to 270 be set to 'No Next Header (value 59)'. 272 Procedures for encapsulating a BIER IPv6 packet in SRH tunnel are 273 outside the scope of this document. 275 Procedures for encapsulating a BIER IPv6 packet in other types of 276 tunnels are outside the scope of this document. 278 5. IPv6 BIER Forwarding 280 In an IPv6 BIER domain, the Multicast Address of the IPv6 DA in an 281 incoming BIER IPv6 packet indicates the BIER information of this 282 'host', and the packet will be forwarded according to the BIER Header 283 in the BIER Destination Option TLV in the IPv6 Destination Option 284 extension header. A router is required to ignore the IPv6 BIER 285 Destination Option if the IPv6 Destination Address of a packet is not 286 a multicast address, or is a multicast adddress without indicating 287 the BIER information of this 'host'. 289 Below is the procedure that a BFR uses for forwarding a BIER IPv6 290 encapsulated packet. 292 1. Read the IPv6 header, get the the IPv6 DA, and get the indication 293 of the multicast address if the IPv6 DA is a multicast address. 294 The case when IPv6 DA not being a multicast address is outside 295 the scope of this document. 297 2. If the multicast address is interested by this router, and the 298 'Next Header' of the IPv6 header indicates a IPv6 Destination 299 Option Header, then read the IPv6 Destination Option Header, and 300 get the BIER Option (BIER Header). The case when the multicast 301 address not being interested by this router is outside the scope 302 of this document. 304 3. The following steps are the same as step 1 to 9 described in 305 chapter 6.5 in [RFC8279]. One difference need to point out is 306 that, the copied packet includes a IPv6 header, a IPv6 307 Destination Header and its BIER Destination Option Type and 308 Option Length before the BIER Header. If the copied packet is 309 forwarded to a BFR-NBR, the 'Hop Limit' field of the IPv6 header 310 MUST be decremented, whereas the TTL in the BIER header MUST be 311 unchanged. 313 Procedures for forwarding a BIER IPv6 packet in SRH tunnel, and hand- 314 off to a hop-by-hop replication, can refer to Appendix A. 316 Procedures for forwarding a BIER IPv6 packet in other types of 317 tunnels, and hand-off to a hop-by-hop replication, are outside the 318 scope of this document. 320 6. Security Considerations 322 An IPv6 BIER Destination Option with Multicast Address Destination 323 would be used only when an IPv6 BIER state with the specific 324 Multicast Address Destination has been built by the control-plane. 325 Otherwise the packet with an IPv6 BIER Destination Option will be 326 discarded. 328 7. IANA Considerations 330 Allocation is expected from IANA for a BIER Destination Option Type 331 codepoint from the "Destination Options and Hop-by-Hop Options" sub- 332 registry of the "Internet Protocol Version 6 (IPv6) Parameters" 333 registry [RFC2780] at . 336 Allocation is expected from IANA for a BIER Multicast Address from 337 the "Variable Scope Multicast Addresses" sub-registry of the "IPv6 338 Multicast Address Space Registry" registry at 339 . 341 8. Acknowledgements 343 TBD. 345 9. Appendix A - BIER over IPv6 SRH Tunnel 347 In a Non-MPLS IPv6 Network, BIER may be deployed in a hop-by-hop 348 manner, or possibly be deployed through an SRH tunnel either for 349 "bypassing Non-capable BIER routers" or "fast rerouting". Here is an 350 example where a packet is firstly forwarded through an SRH tunnel and 351 then through a hop-by-hop BIER domain. 353 When a router along the Segment Routing path receives an IPv6 BIER 354 packet with an SRH header, and if the IPv6 destination address is not 355 one of the router's address, then the packet is forwarded by an IPv6 356 FIB lookup of the destination address and none of the IPv6 extension 357 headers will be checked. If the IPv6 Destination Address is one of 358 the router's address, and also one of the router's Segment (or SID) 359 of some type, then the router will do a specific function indicated 360 by the Segment, as defined in 361 [I-D.filsfils-spring-srv6-network-programming]. If the IPv6 362 Destination Address is a specific type of Segment, called BIER 363 Segment or BIER SID, then the according function is called Endpoint 364 BIER function or 'End.BF' function for short. 366 When router receives a packet destined to X and X is a local End.BF 367 SID, the router does: 369 1. IF SL > 0 370 2. decrement SL 371 3. update IPv6 DA with SRH[SL] 372 4. IF SL = 0 & STATE(SRH[0]) = BIER 373 5. update IPv6 header NH with SRH NH 374 6. pop the SRH 375 7. forward the updated packet 376 8. ELSE 377 9. drop the packet 378 10. ELSE 379 11. drop the packet 381 Figure 2: End.BF Function 383 The End.BF function is used for the SRH tunnel destination router to 384 terminate the source-routing SRH forwarding and begin the hop-by-hop 385 BIER IPv6 forwarding. After the SRH header is popped, the multicast 386 address in the updated IPv6 Destination Address indicates the BIER 387 information of this 'host', and the packet will be forwarded 388 according to the BIER Header in the BIER Destination Option TLV in 389 the IPv6 Destination Option extension header of this 'host'. 391 In the following hop-by-hop forwarding procedure, the IPv6 392 Destination Address in an incoming packet indicates the BIER 393 information of this 'host', and the packet will be forwarded 394 according to the BIER Header in the BIER Destination Option TLV in 395 the IPv6 Destination Option extension header. A router is required 396 to ignore the IPv6 BIER Destination Option if the IPv6 Destination 397 Address of a packet is not a multicast address, or is a multicast 398 adddress without indicating the BIER information of this 'host'. 400 10. References 402 10.1. Normative References 404 [I-D.filsfils-spring-srv6-network-programming] 405 Filsfils, C., Camarillo, P., Leddy, J., 406 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 407 Network Programming", draft-filsfils-spring-srv6-network- 408 programming-05 (work in progress), July 2018. 410 [I-D.ietf-6man-segment-routing-header] 411 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 412 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 413 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 414 progress), June 2018. 416 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 417 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 418 RFC 6564, DOI 10.17487/RFC6564, April 2012, 419 . 421 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 422 of IPv6 Extension Headers", RFC 7045, 423 DOI 10.17487/RFC7045, December 2013, 424 . 426 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 427 (IPv6) Specification", STD 86, RFC 8200, 428 DOI 10.17487/RFC8200, July 2017, 429 . 431 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 432 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 433 Explicit Replication (BIER)", RFC 8279, 434 DOI 10.17487/RFC8279, November 2017, 435 . 437 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 438 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 439 for Bit Index Explicit Replication (BIER) in MPLS and Non- 440 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 441 2018, . 443 10.2. Informative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 Authors' Addresses 452 Jingrong Xie 453 Huawei Technologies 455 Email: xiejingrong@huawei.com 457 Liang Geng 458 China Mobile 459 Beijing 10053 461 Email: gengliang@chinamobile.com 463 Lei Wang 464 China Mobile 465 Beijing 10053 467 Email: wangleiyjy@chinamobile.com 469 Gang Yan 470 Huawei 472 Email: yangang@huawei.com 473 Mike McBride 474 Huawei 476 Email: mmcbride7@gmail.com 478 Yang Xia 479 Huawei 481 Email: yolanda.xia@huawei.com