idnits 2.17.00 (12 Aug 2021) /tmp/idnits37250/draft-xie-6man-bier-encapsulation-00.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 (June 28, 2018) is 1422 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 230, but not defined == Missing Reference: 'RFC6744' is mentioned on line 234, but not defined -- Looks like a reference, but probably isn't: '0' on line 315 == Missing Reference: 'SL' is mentioned on line 314, but not defined == Missing Reference: 'RFC2780' is mentioned on line 356, but not defined == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-04 == Outdated reference: draft-ietf-6man-segment-routing-header has been published as RFC 8754 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 G. Yan 4 Intended status: Standards Track M. McBride 5 Expires: December 30, 2018 Y. Xia 6 Huawei Technologies 7 June 28, 2018 9 Encapsulation for BIER in Non-MPLS IPv6 Networks 10 draft-xie-6man-bier-encapsulation-00 12 Abstract 14 Bit Index Explicit Replication (BIER) introduces a new multicast- 15 specific BIER Header. Currently BIER has two types of encapsulation 16 formats: one is MPLS encapsulation, the other is Ethernet 17 encapsulation. This document proposes a BIER IPv6 encapsulation for 18 Non-MPLS IPv6 Networks using an IPv6 Destination Option extension 19 header. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 30, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Problem Statement and Requirements . . . . . . . . . . . . . 3 64 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 66 4. IPv6 BIER Encapsulation . . . . . . . . . . . . . . . . . . . 4 67 4.1. Considerations . . . . . . . . . . . . . . . . . . . . . 4 68 4.2. IPv6 BIER Destination Option . . . . . . . . . . . . . . 4 69 4.3. The whole IPv6 header for BIER packets . . . . . . . . . 5 70 5. BIER Forwarding in Non-MPLS IPv6 Networks . . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 9.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 82 that provides optimal multicast forwarding without requiring 83 intermediate routers to maintain any per-flow state by using a 84 multicast-specific BIER header. [RFC8296] defines two types of BIER 85 encapsulation formats: one is MPLS encapsulation, the other is non- 86 MPLS encapsulation. The Non-MPLS encapsulation defined in [RFC8296] 87 is in fact an Ethernet encapsulation with an ethertype 0xAB37, and an 88 'Ethernet encapsulation' will be used to refer to such an 89 encapsulation in the following text. This document proposes a BIER 90 IPv6 encapsulation for Non-MPLS IPv6 Networks using an IPv6 91 Destination Option extension header. 93 2. Terminology 95 Readers of this document are assumed to be familiar with the 96 terminology and concepts of the documents listed as Normative 97 References. 99 3. Problem Statement and Requirements 101 3.1. Problem Statement 103 MPLS is a very popular and successful encapsulation. One of the 104 benefits of MPLS is its ability to easily stack a label onto another, 105 thus forming a label stack. This same label stacking benefit is also 106 available for BIER by using an MPLS encapsulation. For example, an 107 MPLS-encapsulated BIER packet can easily run over an MPLS tunnel, 108 either a legacy RSVP-TE/LDP LSP, or an MPLS Segment Routing tunnel. 109 Such a mechanism is the key to obtain the capability of "fast 110 reroute" or "bypass a Non-capable router". To quote [RFC8279]: 112 o In the event that unicast traffic to the BFR-NBR is being sent via 113 a "bypass tunnel" of some sort, the BIER-encapsulated multicast 114 traffic sent to the BFR-NBR SHOULD also be sent via that tunnel. 115 This allows any existing "fast reroute" schemes to be applied to 116 multicast traffic as well as to unicast traffic. 118 o Unicast tunnels are used to bypass non-BFRs. 120 Some other scenarios also need BIER to run on a tunnel, such as 121 transferring a BIER packet through a whole Non-BIER network or 122 domain. 124 The capability to run BIER on a tunnel, especially the widely 125 deployed mpls tunnel, can be obtained by using a BIER MPLS 126 encapsulation, but cannot be obtained by using a BIER Ethernet 127 encapsulation. It is not possible either, to run BIER on other links 128 such as POS, by using BIER Ethernet encapsulation. 130 The capability of running BIER on various kinds of links and tunnels, 131 by using an MPLS encapsulation, is beneficial to BIER deployments. 132 In an IPv6 network, however, there are considerations of using a non- 133 MPLS encapsulation for unicast as the data-plane, such as SRH defined 134 in [I-D.ietf-6man-segment-routing-header], where the function of a 135 bypass tunnel uses an SRH header, with one or many Segments (or 136 SIDs), instead of MPLS Labels. 138 3.2. Requirements 140 This chapter lists the BIER IPv6 encapsulation requirements needed to 141 make the deployment of BIER on IPv6 network with SRH data-plane the 142 same as on IPv4/IPv6 network with MPLS data-plane. These BIER IPv6 143 encapsulation requirements should provide similar benefits to MPLS 144 encapsulation such as "fast reroute" or "run on any link or 145 interface". 147 1. The listed requirements MUST be supported with any L1/L2 over 148 which BIER layer can be realized. 150 2. It SHOULD support a hop-by-hop replication to multiple 151 destinations in a BIER Domain. 153 3. It SHOULD support BIER on an "SRH tunnel". 155 4. It SHOULD align with the recommendations of the 6MAN working 156 group. 158 4. IPv6 BIER Encapsulation 160 4.1. Considerations 162 BIER is generally a hop-by-hop and one-to-many architecture, while 163 Segment Routing is a source-routing and one-to-one architecture. One 164 of the challenges of an BIER IPv6 Encapsulation is how to allow BIER 165 to run over a Segment Routing tunnel. A suitable method for such a 166 combination is to use a Multicast Address as the Last Segment (or 167 SID). After all the source-routing hops have been processed, the 168 remaining Multicast Address becomes the IPv6 Destination Address. A 169 hop-by-hop replicating diagram begins by using the Destination 170 Multicast Address. 172 We then need to decide where to place the BIER header. According to 173 [RFC8200], [RFC6564], and [RFC7045], a suitable place for a well- 174 known BIER header is an IPv6 Destination Option extension header. 175 Such a Destination Option carrying BIER header is only used for a 176 hop-by-hop Multicast Address destination, but not for the transit 177 router along the source-routing path. 179 4.2. IPv6 BIER Destination Option 181 The IPv6 BIER Destination Option is carried by the IPv6 Destination 182 Option Header (indicated by a Next Header value 60). It is used in a 183 packet sent by an IPv6 BFIR router to inform the routers in an IPv6 184 BIER domain to replicate to destination BFER routers. 186 The IPv6 BIER Destination Option is encoded in type-length-value 187 (TLV) format as follows: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Next Header | Hdr Ext Len | Option Type | Option Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | | 195 ~ Non-MPLS BIER Header (defined in RFC8296) ~ 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 1: IPv6 BIER Destination Option 201 Next Header 8-bit selector. Identifies the type of header 202 immediately following the Destination Options header. 204 Hdr Ext Len 8-bit unsigned integer. Length of the Destination 205 Options header in 8-octet units, not including the first 8 octets. 207 Option Type TBD. Need to be allocated by IANA. 209 Option Length 8-bit unsigned integer. Length of the option, in 210 octets, excluding the Option Type and Option Length fields. 212 Non-MPLS BIER Header The Non-MPLS BIER Header defined in RFC8296, 213 including the BIFT-id. 215 4.3. The whole IPv6 header for BIER packets 217 [RFC8200] specifies that the Destination Option Header can be located 218 either before the Routing Header or after the Routing Header. 219 However, this document requires that the Destination Option Header 220 with a BIER Destination Option TLV is always located after the 221 Routing Header if the Routing Header is present. 223 This is because the BIER header is always handled after the tunnels 224 (or bypass tunnels) have been handled. BIER MPLS encapsulation has 225 the same behavior. To quote [RFC8296]: 227 o It is crucial to understand that in an MPLS network the first four 228 octets of the BIER encapsulation header are also the last four 229 octets of the MPLS header. Therefore, any prior MPLS label stack 230 entries MUST have the S bit (see [RFC3032]) clear (i.e., the S bit 231 must be 0). 233 Other IPv6 extension headers are not commonly used in the current 234 Internet. For Example, [RFC6744] says that "IPv6 Destination Options 235 headers, and the options carried by such headers, are extremely 236 uncommon in the deployed Internet". [RFC6564] says that "Extension 237 headers, with the exception of the Hop-by-Hop Options header, are not 238 usually processed on intermediate nodes", and that "Reports from the 239 field indicate that some IP routers deployed within the global 240 Internet are configured either to ignore the presence of headers with 241 hop-by-hop behavior or to drop packets containing headers with hop- 242 by-hop behavior." 244 Such IPv6 extension headers will even be more uncommon when a BIER 245 encapsulation is used in data-plane forwarding. The entire IPv6 246 header, with BIER encapsulation and Routing Header, is expected to 247 look like this: 249 IPv6 header 251 Hop-by-Hop Options header [Not Used] 253 Destination Options header [Not Used] 255 Routing header [SRH Header with Multicast Address as last SID] 257 Fragment header [Not Used] 259 Authentication header [Not Used] 261 Encapsulating Security Payload header [Not Used] 263 Destination Options header [BIER header in BIER Option TLV] 265 Upper-layer header [Data-plane Data] 267 Once a packet is encapsulated with a BIER Destination Option, it is 268 basically assumed to be a data-plane multicast packet, so the 'OAM' 269 or similar functions in the SRH Header Optional TLV Objects field 270 should not exist. 272 The last Segment (SID) in the SRH header, or Segment List[0], should 273 be a Multicast Address to indicate a hop-by-hop behavior. Such a 274 Multicast Address can be reserved or unreserved as the Destination 275 Option Header can inform the routers to do the address check. A 276 reserved multicast address should be indicating a 'BIER specific' 277 address. 279 BIER header has a 'proto' field to identify the type of BIER packet 280 payload, and the IANA has created a registry called "BIER Next 281 Protocol Identifiers" to assign the value. That means the 'Upper- 282 layer header' of a BIER packet have already been identified by the 283 'proto' field of the BIER header in the Destination Option Header. 284 Thus the 'Next Header' in the Destination Option Header is not need 285 to identify the 'Upper-layer header' any more, and is recommended to 286 be set to 'No Next Header (value 59)'. 288 5. BIER Forwarding in Non-MPLS IPv6 Networks 290 In a Non-MPLS IPv6 Network, BIER may be deployed in a hop-by-hop 291 manner, or possibly be deployed through an SRH tunnel either for 292 "bypassing Non-capable BIER routers" or "fast rerouting". Here is an 293 example where a packet is first forwarded through an SRH tunnel and 294 then through a hop-by-hop manner. 296 When a router along the Segment Routing path receives an IPv6 BIER 297 packet with an SRH header, and if the IPv6 destination address is not 298 one of the router's address, then the packet is forwarded by an IPv6 299 FIB lookup of the destination address and none of the IPv6 extension 300 headers will be checked. If the IPv6 Destination Address is one of 301 the router's address, and also one of the router's Segment (or SID) 302 of some type, then the router will do a specific function indicated 303 by the Segment, as defined in 304 [I-D.filsfils-spring-srv6-network-programming]. If the IPv6 305 Destination Address is a specific type of Segment, called BIER 306 Segment or BIER SID, then the according function is called Endpoint 307 BIER function or 'End.BF' function for short. 309 When router receives a packet destined to X and X is a local End.BF 310 SID, the router does: 312 1. IF SL > 0 313 2. decrement SL 314 3. update IPv6 DA with SRH[SL] 315 4. IF SL = 0 & STATE(SRH[0]) = BIER 316 5. update IPv6 header NH with SRH NH 317 6. pop the SRH 318 7. forward the updated packet 319 8. ELSE 320 9. drop the packet 321 10. ELSE 322 11. drop the packet 324 Figure 2: End.BF Function 326 The End.BF function is used for the SRH tunnel destination router to 327 terminate the source-routing SRH forwarding while begining the hop- 328 by-hop BIER IPv6 forwarding. After the SRH header is popped, the 329 multicast address in the updated IPv6 Destination Address indicates 330 the BIER information of this 'host', and the packet will be forwarded 331 according to the BIER Header in the BIER Destination Option TLV in 332 the IPv6 Destination Option extension header. 334 In the following hop-by-hop forwarding procedure, the IPv6 335 Destination Address in an incoming packet indicates the BIER 336 information of this 'host', and the packet will be forwarded 337 according to the BIER Header in the BIER Destination Option TLV in 338 the IPv6 Destination Option extension header. A router is required 339 to ignore the IPv6 BIER Destination Option if the IPv6 Destination 340 Address of a packet is not a multicast address, or is a multicast 341 adddress without indicating the BIER information of this 'host'. 343 6. Security Considerations 345 An IPv6 BIER Destination Option with Multicast Address Destination 346 would be used only when an IPv6 BIER state with the specific 347 Multicast Address Destination has been built by the control-plane. 348 Otherwise the packet with an IPv6 BIER Destination Option will be 349 discarded. 351 7. IANA Considerations 353 Allocation is expected from IANA for a Destination Option Type 354 codepoint from the "Destination Options and Hop-by-Hop Options" sub- 355 registry of the "Internet Protocol Version 6 (IPv6) Parameters" 356 registry [RFC2780] at . 359 8. Acknowledgements 361 TBD. 363 9. References 365 9.1. Normative References 367 [I-D.filsfils-spring-srv6-network-programming] 368 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 369 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 370 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 371 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 372 M. Sharif, "SRv6 Network Programming", draft-filsfils- 373 spring-srv6-network-programming-04 (work in progress), 374 March 2018. 376 [I-D.ietf-6man-segment-routing-header] 377 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 378 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 379 (SRH)", draft-ietf-6man-segment-routing-header-13 (work in 380 progress), May 2018. 382 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 383 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 384 RFC 6564, DOI 10.17487/RFC6564, April 2012, 385 . 387 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 388 of IPv6 Extension Headers", RFC 7045, 389 DOI 10.17487/RFC7045, December 2013, 390 . 392 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 393 (IPv6) Specification", STD 86, RFC 8200, 394 DOI 10.17487/RFC8200, July 2017, 395 . 397 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 398 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 399 Explicit Replication (BIER)", RFC 8279, 400 DOI 10.17487/RFC8279, November 2017, 401 . 403 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 404 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 405 for Bit Index Explicit Replication (BIER) in MPLS and Non- 406 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 407 2018, . 409 9.2. Informative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, 413 DOI 10.17487/RFC2119, March 1997, 414 . 416 Authors' Addresses 418 Jingrong Xie 419 Huawei Technologies 421 Email: xiejingrong@huawei.com 422 Gang Yan 423 Huawei Technologies 425 Email: yangang@huawei.com 427 Mike McBride 428 Huawei Technologies 430 Email: mmcbride7@gmail.com 432 Yang Xia 433 Huawei Technologies 435 Email: yolanda.xia@huawei.com