idnits 2.17.1 draft-ietf-bier-ipv6-requirements-06.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 (July 28, 2020) is 1367 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) == Unused Reference: 'RFC1112' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 502, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-geng-bier-ipv6-inter-domain-01 == Outdated reference: A later version (-12) exists of draft-ietf-bier-use-cases-11 ** Downref: Normative reference to an Informational draft: draft-ietf-bier-use-cases (ref. 'I-D.ietf-bier-use-cases') == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 == Outdated reference: A later version (-10) exists of draft-xie-bier-ipv6-encapsulation-08 == Outdated reference: A later version (-09) exists of draft-zhang-bier-bierin6-06 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. McBride 3 Internet-Draft Futurewei 4 Intended status: Standards Track J. Xie 5 Expires: January 29, 2021 S. Dhanaraj 6 Huawei 7 R. Asati 8 Cisco 9 Y. Zhu 10 China Telecom 11 G. Mishra 12 Verizon Inc. 13 July 28, 2020 15 BIER IPv6 Requirements 16 draft-ietf-bier-ipv6-requirements-06 18 Abstract 20 The BIER WG charter includes work on developing "a mechanism to use 21 BIER natively in IPv6". There have been several proposed solutions 22 in this area. But there hasn't been a document which describes the 23 problem and lists the requirements. The goal of this document is to 24 describe the BIER IPv6 requirements, summarize the encapsulation 25 modes of the proposed solutions, guide the working group in 26 understanding the benefits and drawbacks of the various solutions, 27 and help in the development of acceptable solutions. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 29, 2021. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding 4 68 3.1. Transport-Independent Model . . . . . . . . . . . . . . . 5 69 3.2. Native IPv6 Model . . . . . . . . . . . . . . . . . . . . 6 70 3.3. Encapsulation Approaches Considered . . . . . . . . . . . 7 71 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4.1. Mandatory Requirements . . . . . . . . . . . . . . . . . 8 73 4.1.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . 8 74 4.1.2. Support BIER architecture . . . . . . . . . . . . . . 8 75 4.1.3. Conform to existing IPv6 Spec . . . . . . . . . . . . 8 76 4.1.4. Support deployment with Non-BFR routers . . . . . . . 8 77 4.1.5. Support inter-AS multicast deployment . . . . . . . . 8 78 4.1.6. Support Simple Encapsulation . . . . . . . . . . . . 9 79 4.1.7. Support Deployment Security . . . . . . . . . . . . . 9 80 4.2. Optional Requirements . . . . . . . . . . . . . . . . . . 9 81 4.2.1. Support MVPN . . . . . . . . . . . . . . . . . . . . 9 82 4.2.2. Support OAM . . . . . . . . . . . . . . . . . . . . . 9 83 4.2.3. Support IPSEC . . . . . . . . . . . . . . . . . . . . 9 84 4.2.4. Support Fragmentation . . . . . . . . . . . . . . . . 9 85 4.2.5. Support hardware fast path . . . . . . . . . . . . . 10 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 88 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 89 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 90 Appendix A. Solutions Evaluation . . . . . . . . . . . . . . . . 12 91 A.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 12 92 A.2. Encode Bitstring in IPv6 destination address . . . . . . 13 93 A.3. Add BIER header into IPv6 Extension Header . . . . . . . 13 94 A.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 14 95 A.5. Tunnelling BIER in a IPv6 tunnel . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 98 1. Introduction 100 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 101 that provides optimal multicast forwarding, without requiring 102 intermediate routers to maintain per-flow state, through the use of a 103 multicast-specific BIER header. [RFC8296] defines two types of BIER 104 encapsulation to run on physical links: one is BIER MPLS 105 encapsulation to run on various physical links that support MPLS, the 106 other is non-MPLS BIER Ethernet encapsulation to run on ethernet 107 links, with an ethertype 0xAB37. This document describes using BIER 108 in non-MPLS IPv6 environments. We explain the requirements of 109 transporting IPv4/IPv6 multicast payloads through an IPv6 network 110 using "BIER natively in IPv6". As clarified in the working-group, 111 "BIER natively in IPv6" means BIER not encapsulated in MPLS or 112 Ethernet. This may include native IPv6 encapsulation and generic 113 IPv6 tunnelling. The goal of this document is to help the BIER WG 114 evaluate the BIER v6 requirements and solutions in order to begin 115 adopting solution drafts. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 1.2. Terminology 125 o BIER: Bit Index Explicit Replication. Provides optimal multicast 126 forwarding through adding a BIER header and removing state in 127 intermediate routers. 129 o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe 130 the three types of Ethernet modes that will be forwarded to 131 multiple destinations 133 2. Problem Statement 135 The problem is the ability of the network to transport BUM packets, 136 with BIER headers, in an IPv6 environment. In many IPv6 network 137 deployments, non-MPLS encapsulation is used for unicast as the data- 138 plane. It is likewise expected to have BIER IPv6 deployments which 139 depend on these same unicast technologies to traverse through non-BFR 140 routers. 142 One such case involves supporting a non-BFR router in a network as 143 described in section 6.9 of RFC8279. In the context of this 144 document, an IPv6 based unicast tunnel is needed to support such 145 deployment where a non-BFR exists. Another case is to support inter- 146 AS multicast deployment as illustrated in 147 [I-D.geng-bier-ipv6-inter-domain]. In such deployment, there are 148 non-BFR routers, or even an entire non-BIER network, that needs the 149 ability to traverse from one BFR to another. 150 [I-D.ietf-bier-use-cases] shows it is possible there are other cases 151 where inter-AS multicast deployment is required. 153 As with IPv6, another problem of BIER IPv6 technology may be 154 "Transition Mechanisms and Partial Deployments" which is listed as 155 the No.1 charter item of BIER WG. Therefore, a basic requirement of 156 BIER IPv6 is to leverage IPv6 reachability for incremental and inter- 157 AS BIER deployment. 159 Below is a simple scenario that needs BIER IPv6 encapsulation and 160 forwarding: 162 +--------------------------------------------+ 163 | | 164 | +------+ 165 | | BFER | 166 +------+ +-------+ +-----+ +------+ 167 | BFIR | |Non-BFR| | BFR | | 168 +------+ +-------+ +-----+ +------+ 169 | | BFER | 170 | IPv6 Network +------+ 171 | (intra-AS or inter-AS) | 172 +--------------------------------------------+ 174 This scenario depicts the need to replicate bier packets from a BFIR 175 to BFERs across an IPv6 core. The IPv6 environment may include a 176 variety of link types, may be entirely IPv6, may be dual stack or any 177 type of combination which includes IPv6. Regardless of the 178 environment, there are times when a BIER header, including the BIER 179 BitString used to determine the set of BIER forwarding egress 180 routers, will need to traverse a IPv6 domain. The ways in which BIER 181 will function in an IPv6 environment is the problem that needs to be 182 solved. 184 3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding 186 This analysis introduces two conceptual models for BIER IPv6 187 encapsulation and forwarding based on the experience and examples 188 that have been seen in the IETF community. 190 3.1. Transport-Independent Model 192 The first conceptual model is a Transport-Independent Model that 193 views IP tunnels as links of BIER, and views BIER as an independent 194 "Layer-2.5". 196 |<----------(L2.5 BIER(P2MP) Tunnel)-------->| 197 | | 198 | +~~~~~~~~~~~~~~~~~~+ +~~~~+ | 199 | / \ / \ | 200 +------+ +-------+ +-----+ +------+ 201 | BFIR |-------|Non-BFR|-------| BFR |--------| BFER | 202 +------+ +-------+ +-----+ +------+ 204 ------- physical link 206 ~~~~~~~ IPv6(P2P) tunnel 208 <-----> BIER(P2MP) tunnel 210 In this model, an IPv6 tunnel works as a link-layer of BIER, and BIER 211 works as a transport-independent layer (or layer-2.5) over a virtual- 212 link (IPv6 tunnel). On each BFR, the IPv6 tunnel of the receiving 213 packet is decapsulated, and a new IPv6 tunnel is encapsulated before 214 sending the packet to the next-hop BFR neighbour. 216 From the view of the IPv6 layer, the BIER header is a kind of Upper- 217 layer header (Layer-4). From the view of the BIER layer, the IPv6 218 encapsulation is a tunnel working as a "link" of BIER. With an End- 219 to-End view, the tunnel from BFIR to BFERs is a Layer-2.5 BIER (P2MP) 220 tunnel, and the BFIR-id is the BIER packet source-origin identifier, 221 and is unchanged through the BIER domain from BFIR to BFERs. 223 This model is similar to the "MPLS over IP" [RFC4023] or "MPLS over 224 UDP" [RFC7510] approach. A more general output of such approach in 225 IETF is "MPLS Segment Routing over IP" [RFC8663]. It makes use of 226 IPv4/IPv6 tunnel, IPv4/IPv6 UDP tunnel and IPv4/IPv6 GRE tunnel to 227 encapsulate the MPLS-based instructions. In fact, BIER-MPLS could 228 use this approach directly since BIER-MPLS is based on MPLS. 230 There may be, however, in certain cases some difficulty with 231 allocation of an MPLS label and advertisement through the control- 232 plane. For example, a simple inter-AS BIER deployment may want to 233 use the auto-configuration of BIFT-id using Non-MPLS BIER 234 encapsulation [RFC8296] as illustrated in 235 [I-D.geng-bier-ipv6-inter-domain]. This brings the need of a new 236 "Next Header" value to indicate the "Non-MPLS" BIER header. 238 For IPv4/IPv6 GRE, the "Next Header" is the 16-bit "Protocol Type" 239 field, and has adequate space for such requirement. 241 For IPv4/IPv6 UDP, the "Next Header" is the 16-bit "Destination Port" 242 field, and has adequate space for such requirement. 244 For IPv4/IPv6, the "Next Header" is a 8-bit value and needs to be 245 allocated from the "Assigned Internet Protocol Numbers" registry. 247 Reassembly/Re-fragmentation of a packet has to be executed on each 248 BFR in such case. This may be common and even friendly for a 249 protocol stack in a BFR software implementation, but it may impose 250 cost for a BFR hardware implementation. 252 IPv6 functions that are expected to be executed from BFIR to BFER are 253 assumed to be broken on the BFRs, for example, IPv6 Fragmentation/ 254 Assembly or IPSEC ESP. This is because the "IPv6 tunnel" and all its 255 functions is "terminated" on the BFRs. These functions, if desired, 256 may need to be re-designed in the "Layer-2.5" BIER mode. 258 For deployment security, it is necessary to ensure the "BIER" packet 259 is only using the allowed IPv6 tunnel. 261 3.2. Native IPv6 Model 263 The second conceptual model is a Native IPv6 Model that integrates 264 BIER as part of the IPv6 data plane, making it a "Layer-3 BIER" 265 approach. 267 |<----------(L3 BIER(P2MP) tunnel)--------->| 268 | | 269 +------+ +-------+ +-----+ +------+ 270 | BFIR |-------|Non-BFR|-------| BFR |--------| BFER | 271 +------+ +-------+ +-----+ +------+ 273 ------- physical link 275 <-----> BIER(P2MP) tunnel 277 In this model, BIER works as part of the IPv6 data plane. BFIR and 278 BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6 279 segment endpoints. On each BFR, the segment endpoint behaviour of 280 IPv6 data plane is executed, and there is no decapsulation of 281 receiving IPv6 tunnel and encapsulation of new IPv6 tunnel for 282 sending. 284 In this mode, the BIER header is integrated into the IPv6 extension 285 header and processing of the BIER header (e.g., the BitString) is 286 implemented as part of the IPv6 extension header processing. The 287 IPv6 source address is the BIER packet source-origin identifier, and 288 is unchanged through the BIER domain from BFIR to BFERs. 290 This model is similar to many examples emerging in the IETF community 291 which soley use the IPv6 data plane. SRv6 introduced in [RFC8754] 292 and [I-D.ietf-spring-srv6-network-programming] is an example. The 293 benefits of such approach includes reducing the number of 294 encapsulation layers, capability of deployment with non-capable 295 routers in a network, extending the technology in a wider inter-AS 296 scope using IP reachability, and capability of integrating the 297 functions of the IPv6 data plane. 299 This model typically needs an extension to IPv6 data plane, with an 300 IPv6 extension header or Option introduced. 302 IPv6 functions that are expected to be executed from BFIR to BFER is 303 supported if correctly designed, for example, IPv6 Fragmentation/ 304 Assembly or IPSEC ESP. 306 For deployment security, it is necessary to ensure the "BIER" packet 307 is in a trusted IPv6-based domain. 309 3.3. Encapsulation Approaches Considered 311 A number of approaches to the design of BIER-IPv6 encapsulation were 312 investigated by the BIER Working Group and were discussed in IETF 313 meetings and on the BIER list. This section divides these approaches 314 into the two conceptual models. 316 Transport-Independent Model approaches include: 318 Transport-Independent BIER [I-D.xu-bier-encapsulation]. 320 BIERin6 [I-D.zhang-bier-bierin6]. 322 Native IPv6 Model approaches include: 324 BIER-over-IPv6 [I-D.pfister-bier-over-ipv6]. 326 BIERv6 [I-D.xie-bier-ipv6-encapsulation]. 328 4. Requirements 330 There have been several suggested requirements, on the BIER email 331 list and in meetings, which have been used to form BIER IPv6 332 requirements used to help the wg evaluate against the proposed 333 solutions. There is also many further discussions on the list about 334 BIER IPv6 requirements from different scenarios. 336 Considering that the importance of requirement for BIER IPv6 solution 337 is different, in this document, the requirements are divided into two 338 groups: mandatory and optional. The requirements in the mandatory 339 group are considered necessary for any BIER IPv6 solution, while the 340 requirements in the optional group should be considered but are not 341 mandatory. 343 4.1. Mandatory Requirements 345 4.1.1. L2 Agnostic 347 The solution must be agnostic to the underlying L2 data link type. 348 The solution needs to support P2P ethernet links as well as shared 349 media ethernet links without requiring the LAN switch to perform BIER 350 snooping. 352 4.1.2. Support BIER architecture 354 The solution must support the BIER architecture. 356 Multiple sub-domains bound to one or many topologies or algorithms, 357 multiple sets for more BFERs, multiple Bit String Lengths for 358 different forwarding capabilities, and multiple BIFTs for ECMP are 359 considered essential functions of BIER and need to be supported. 361 4.1.3. Conform to existing IPv6 Spec 363 The proposed encapsulation must conform to the IPv6 specification and 364 guidelines as described in RFC8200. If new extensions to existing 365 IPv6 specification are required, it needs to be discussed and 366 reviewed by the 6man working-group. 368 4.1.4. Support deployment with Non-BFR routers 370 The solution must support deployments with Non-BFR routers. This is 371 beneficial to the deployment of BIER, especially in early deployments 372 when some routers do not support BIER forwarding but support IPv6 373 forwarding. This is also the No.1 charter item, "Transition 374 Mechanisms and Partial Deployments" of the BIER WG. 376 4.1.5. Support inter-AS multicast deployment 378 Inter-AS multicast support is needed for ease of provisioning the 379 P2MP transport service to enterprises. This could greatly increase 380 the scalability of BIER, as it is usually considered to be suitable 381 only for small intra-AS scenarios. 383 4.1.6. Support Simple Encapsulation 385 The solution must avoid requiring different encapsulation types. A 386 solution needs to do careful trade-off analysis and select one 387 encapsulation as its proposal for best coverage of various scenarios. 389 4.1.7. Support Deployment Security 391 The proposed solution must include careful security considerations, 392 including all that is already considered in BIER architecture RFC8279 393 and RFC8296, and other security concerns that may raise due to the 394 addition of IPv6. 396 4.2. Optional Requirements 398 4.2.1. Support MVPN 400 The solution MAY support MVPN services that is defined in [RFC6513]. 401 When MVPN is supported, it should work in a "tunnel" mode, 402 encapsulating IP or IPv6 multicast packet in an outer IPv6 header. 403 When MVPN is supported, it is suggested to think about both intra-AS 404 and inter-AS deployment. 406 4.2.2. Support OAM 408 BIER OAM MAY be supported, either directly using existing method, or 409 specify some variant method for the same function. It may be 410 considered essential as part of the BIER architecture in some cases. 412 4.2.3. Support IPSEC 414 IPSEC is optional to IPv6 and multicast. It is preferred to support 415 IPSEC, including AH/ESP. If IPSEC is to be supported, it shouldn't 416 require hop-by-hop encryption/decryption. 418 4.2.4. Support Fragmentation 420 As part of IPv6 specification [RFC8200], BIER IPv6 may support 421 fragmentation on BFIR and assembly on BFER. Support of Fragmentation 422 can enhance the capability of BIER leveraging the BIER-MTU as 423 introduced in section 3 of [RFC8296]. If Fragmentation is to be 424 supported, it shouldn't require fragmentation and re-assembly at each 425 hop. 427 4.2.5. Support hardware fast path 429 If a proposed solution is intended for some scenarios like service- 430 provider networks, it should enable the processing and forwarding of 431 BIER packets in hardware fast path. 433 5. IANA Considerations 435 Some BIERv6 encapsulation proposals do not require any action from 436 IANA while other proposals require new BIER Destination Option 437 codepoints from IPv6 sub-registries, new "Next header" values, or 438 require new IP Protocol codes. This document, however, does not 439 require anything from IANA. 441 6. Security Considerations 443 There are no security issues introduced by this draft. 445 7. Acknowledgement 447 Thank you to Eric Rosen for his listed set of requirements on the 448 bier wg list. 450 8. Normative References 452 [I-D.geng-bier-ipv6-inter-domain] 453 Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain 454 Multicast Deployment using BIERv6", draft-geng-bier-ipv6- 455 inter-domain-01 (work in progress), January 2020. 457 [I-D.ietf-bier-use-cases] 458 Nainar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 459 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 460 Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-11 461 (work in progress), March 2020. 463 [I-D.ietf-spring-srv6-network-programming] 464 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 465 Matsushima, S., and Z. Li, "SRv6 Network Programming", 466 draft-ietf-spring-srv6-network-programming-16 (work in 467 progress), June 2020. 469 [I-D.pfister-bier-over-ipv6] 470 Pfister, P. and I. Wijnands, "An IPv6 based BIER 471 Encapsulation and Encoding", draft-pfister-bier-over- 472 ipv6-01 (work in progress), October 2016. 474 [I-D.xie-bier-ipv6-encapsulation] 475 Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., 476 Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, 477 "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft- 478 xie-bier-ipv6-encapsulation-08 (work in progress), July 479 2020. 481 [I-D.xu-bier-encapsulation] 482 Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet, 483 C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit 484 Index Explicit Replication (BIER) Encapsulation Header", 485 draft-xu-bier-encapsulation-06 (work in progress), 486 September 2016. 488 [I-D.zhang-bier-bierin6] 489 Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and 490 M. McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier- 491 bierin6-06 (work in progress), July 2020. 493 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 494 RFC 1112, DOI 10.17487/RFC1112, August 1989, 495 . 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, 499 DOI 10.17487/RFC2119, March 1997, 500 . 502 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 503 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 504 December 1998, . 506 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 507 "Encapsulating MPLS in IP or Generic Routing Encapsulation 508 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 509 . 511 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 512 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 513 2012, . 515 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 516 "Encapsulating MPLS in UDP", RFC 7510, 517 DOI 10.17487/RFC7510, April 2015, 518 . 520 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 521 (IPv6) Specification", STD 86, RFC 8200, 522 DOI 10.17487/RFC8200, July 2017, 523 . 525 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 526 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 527 Explicit Replication (BIER)", RFC 8279, 528 DOI 10.17487/RFC8279, November 2017, 529 . 531 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 532 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 533 for Bit Index Explicit Replication (BIER) in MPLS and Non- 534 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 535 2018, . 537 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 538 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 539 DOI 10.17487/RFC8663, December 2019, 540 . 542 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 543 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 544 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 545 . 547 Appendix A. Solutions Evaluation 549 The following are solutions that have been proposed to solve BIER in 550 IPv6 environments. Some solutions propose encoding while others 551 propose encapsulation. It is recommended for the wg to evaluate 552 these solutions against the requirements listed previously in order 553 to make informed decisions on solution readiness. 555 As illustrated in these examples, the BIER header, or the BitString, 556 may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload, 557 or IPv6 Tunnel Packet: 559 A.1. BIER-ETH encapsulation in IPv6 networks 561 +---------------+-----------------+------------------- 562 | Ethernet | BIER header | payload 563 | (ethType = | (BIFT-id, ...) | 564 | 0xAB37) | | 565 | | Next Header | 566 +---------------+-----------------+------------------- 568 BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined 569 in [RFC8296]) can be used to transport the multicast data in the IPv6 570 network by encapsulating the multicast user data payload within the 571 BIER-ETH header. However, BIER-ETH in IPv6 networks is not 572 considered to be a "BIER natively in IPv6" solution which utilizes 573 the IPv6 header to forward the packet. 575 Mixed use of BIER-ETH in a native IPv6 solution is up to the solution 576 and is outside the scope of this document. 578 A.2. Encode Bitstring in IPv6 destination address 580 +---------------+------------------- 581 | IPv6 header | payload 582 | (BitString in | 583 | DA lower bits)| 584 | Next Header | 585 +---------------+------------------- 587 As described in [I-D.pfister-bier-over-ipv6], The information 588 required by BIER is stored in the destination IPv6 address. The BIER 589 BitString is encoded in the low-order bits of the IPv6 destination 590 address of each packet. The high-order bits of the IPv6 destination 591 address are used by intermediate routers for unicast forwarding, 592 deciding whether a packet is a BIER packet, and if so, to identify 593 the BIER Sub-Domain, Set Identifier and BitString length. No 594 additional extension or encapsulation header is required. Instead of 595 encapsulating the packet in IPv6, the payload is attached to the BIER 596 IPv6 header and the IPv6 protocol number is set to the type of the 597 payload. If the payload is UDP, the UDP checksum needs to change 598 when the BitString in the IPv6 destination address changes. 600 A.3. Add BIER header into IPv6 Extension Header 602 +---------------+-----------------+------------------- 603 | IPv6 header | IPv6 Ext header | payload 604 | | (BIER header in | 605 | | TLV Type = X) | 606 | Next Header | Next Header | 607 +---------------+-----------------+------------------- 609 According to [RFC8200] In IPv6, optional internet-layer information 610 is encoded in separate headers that may be placed between the IPv6 611 header and the upper- layer header in a packet. There is a small 612 number of such extension headers, each one identified by a distinct 613 Next Header value. An IPv6 packet may carry zero, one, or more 614 extension headers, each identified by the Next Header field of the 615 preceding header. Extension headers (except for the Hop-by-Hop 616 Options header) are not processed, inserted, or deleted by any node 617 along a packet's delivery path, until the packet reaches the node (or 618 each of the set of nodes, in the case of multicast) identified in the 619 Destination Address field of the IPv6 header. The Hop-by-Hop Options 620 header is not inserted or deleted, but may be examined or processed 621 by any node along a packet's delivery path, until the packet reaches 622 the node (or each of the set of nodes, in the case of multicast) 623 identified in the Destination Address field of the IPv6 header. The 624 Hop-by-Hop Options header, when present, must immediately follow the 625 IPv6 header. Its presence is indicated by the value zero in the Next 626 Header field of the IPv6 header. 628 Two of the currently-defined extension headers are the Hop-by-Hop 629 Options header and the Destination Options header which carry a 630 variable number of type-length-value (TLV) encoded "options". 632 In [I-D.xie-bier-ipv6-encapsulation] an IPv6 BIER Destination Option 633 is carried by the IPv6 Destination Option Header (indicated by a Next 634 Header value 60). It is initialized in a packet sent by an IPv6 BFIR 635 router to inform the following BFR routers in an IPv6 BIER domain to 636 replicate to destination BFER routers hop-by-hop. BIER is generally 637 a hop-by-hop and one-to-many architecture and it is required for a 638 BIER IPv6 encapsulation to include the BIER Header ([RFC8296]) as an 639 IPv6 Extension Header, to pilot the hop-by-hop BIER replication. 641 Hop by hop Options Headers may be considered. The Hop-by-Hop Options 642 header is used to carry optional information that may be examined and 643 processed by every node along a packet's delivery path. The Hop-by- 644 Hop Options header is identified by a Next Header value of 0 in the 645 IPv6 header. 647 Defining New Extension Headers and Options may also be considered, if 648 the IPv6 Destination Option Header is not good enough and new 649 extension headers can solve the problem better. 651 Such proposals may include requests to IANA to allocate a "BIER 652 Option" code from "Destination Options and Hop-by-Hop Options", and/ 653 or a "BIER Option Header" code from "IPv6 Extension Header Types". 655 A.4. Transport BIER as IPv6 payload 657 +---------------+-----------------+------------------- 658 | IPv6 header | IPv6 Ext header | BIER Hdr + payload 659 | | (optional) | as IPv6 payload 660 | | | 661 | Next Header | Next Header = X | 662 +---------------+-----------------+------------------- 664 There is a proposal for a transport-independent BIER encapsulation 665 header which is applicable regardless of the underlying transport 666 technology. As described in [I-D.xu-bier-encapsulation] and 667 [I-D.zhang-bier-bierin6], the BIER header, and the payload following 668 it, can be combined as an IPv6 payload, and be indicated by a new 669 Upper-layer IPv6 Next-Header value. A unicast IPv6 destination 670 address is used for the replication and changes when replicating a 671 packet out to a neighbor. 673 Such proposals may include a request to IANA to allocate an IPv6 674 Next-Header code from "Assigned Internet Protocol Numbers". 676 A.5. Tunnelling BIER in a IPv6 tunnel 678 +---------------+-----------------+------------+---------------- 679 | IPv6 header | IPv6 Ext header | GRE header | 680 | | (optional) | | BIER Hdr + 681 | | | | payload as GRE 682 | Next Header | Next Header | Proto = X | Payload 683 +---------------+-----------------+------------+---------------- 685 A generic IPv6 Tunnel could be used to encapsulate the bier packet 686 within an IPv6 domain. 688 GRE is a mechanism by which any ethernet payload can be carried by an 689 IP GRE tunnel due to the 16-bits 'Protocol Type' field. Both IPv4 690 and IPv6 can be used to carry GRE. The Ethernet type codepoint 691 0xAB37, defined for BIER, can be used in a GRE header to indicate the 692 subsequent BIER header and payload in an IPv6 network. 694 +---------------+-----------------+------------+---------------- 695 | IPv6 header | IPv6 Ext header | UDP header | 696 | | (optional) | | BIER Hdr + 697 | | | | payload as UDP 698 | Next Header | Next Header | DPort = X | Payload 699 +---------------+-----------------+------------+---------------- 701 UDP-based tunnelling is another mechanism which uses a specific UDP 702 port to indicate a UDP payload format. Both IPv4 and IPv6 can 703 support UDP. Such UDP-based tunnels can be used for BIER in a IPv6 704 network by defining a new UDP port to indicate the BIER header and 705 payload. 707 Authors' Addresses 708 Mike McBride 709 Futurewei 711 Email: michael.mcbride@futurewei.com 713 Jingrong Xie 714 Huawei 716 Email: xiejingrong@huawei.com 718 Senthil Dhanaraj 719 Huawei 721 Email: senthil.dhanaraj@huawei.com 723 Rajiv Asati 724 Cisco 726 Email: rajiva@cisco.com 728 Yongqing Zhu 729 China Telecom 731 Email: zhuyq8@chinatelecom.cn 732 Gyan S. Mishra 733 Verizon Inc. 735 13101 Columbia Pike 737 Silver Spring 738 , 740 MD 20904 742 United States of America 744 Phone: 745 301 502-1347 747 Email: 748 gyan.s.mishra@verizon.com