idnits 2.17.00 (12 Aug 2021) /tmp/idnits21465/draft-ietf-bier-ipv6-requirements-05.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 10, 2020) is 679 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 489, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 498, 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: draft-ietf-spring-srv6-network-programming has been published as RFC 8986 == Outdated reference: A later version (-10) exists of draft-xie-bier-ipv6-encapsulation-07 == Outdated reference: A later version (-09) exists of draft-zhang-bier-bierin6-04 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 11, 2021 S. Dhanaraj 6 Huawei 7 R. Asati 8 Cisco 9 Y. Zhu 10 China Telecom 11 G. Mishra 12 Verizon Inc. 13 July 10, 2020 15 BIER IPv6 Requirements 16 draft-ietf-bier-ipv6-requirements-05 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 11, 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 and it is likewise expected to have BIER IPv6 deployments which 139 depend on these same unicast technologies. 141 One such case involves supporting a non-BFR router in a network as 142 described in section 6.9 of RFC8279. In the context of this 143 document, an IPv6 based unicast tunnel is needed to support such 144 deployment where a non-BFR exists. Another case is to support inter- 145 AS multicast deployment as illustrated in 146 [I-D.geng-bier-ipv6-inter-domain]. In such deployment, there are 147 non-BFR routers, or even an entire non-BIER network, that needs the 148 ability to traverse from one BFR to another. 149 [I-D.ietf-bier-use-cases] shows it is possible there are other cases 150 where inter-AS multicast deployment is required. 152 As with IPv6, another problem of BIER IPv6 technology may be 153 "Transition Mechanisms and Partial Deployments" which is listed as 154 the No.1 charter item of BIER WG. Therefore, a basic requirement of 155 BIER IPv6 is to leverage IPv6 reachability for incremental and inter- 156 AS BIER deployment. 158 Below is a simple scenario that needs BIER IPv6 encapsulation and 159 forwarding: 161 +--------------------------------------------+ 162 | | 163 | +------+ 164 | | BFER | 165 +------+ +-------+ +-----+ +------+ 166 | BFIR | |Non-BFR| | BFR | | 167 +------+ +-------+ +-----+ +------+ 168 | | BFER | 169 | IPv6 Network +------+ 170 | (intra-AS or inter-AS) | 171 +--------------------------------------------+ 173 This scenario depicts the need to replicate bier packets from a BFIR 174 to BFERs across an IPv6 core. The IPv6 environment may include a 175 variety of link types, may be entirely IPv6, may be dual stack or any 176 type of combination which includes IPv6. Regardless of the 177 environment, there are times when a BIER header, including the BIER 178 BitString used to determine the set of BIER forwarding egress 179 routers, will need to traverse a IPv6 domain. The ways in which BIER 180 will function in an IPv6 environment is the problem that needs to be 181 solved. 183 3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding 185 This analysis introduces two conceptual models for BIER IPv6 186 encapsulation and forwarding based on the experience and examples 187 that have been seen in the IETF community. 189 3.1. Transport-Independent Model 191 The first conceptual model is a Transport-Independent Model that 192 views IP tunnels as links of BIER, and views BIER as an independent 193 "Layer-2.5". 195 |<----------(L2.5 BIER(P2MP) Tunnel)-------->| 196 | | 197 | +~~~~~~~~~~~~~~~~~~+ +~~~~+ | 198 | / \ / \ | 199 +------+ +-------+ +-----+ +------+ 200 | BFIR |-------|Non-BFR|-------| BFR |--------| BFER | 201 +------+ +-------+ +-----+ +------+ 203 ------- physical link 205 ~~~~~~~ IPv6(P2P) tunnel 207 <-----> BIER(P2MP) tunnel 209 In this model, an IPv6 tunnel works as a link-layer of BIER, and BIER 210 works as a transport-independent layer (or layer-2.5) over a virtual- 211 link (IPv6 tunnel). On each BFR, the IPv6 tunnel of the receiving 212 packet is decapsulated, and a new IPv6 tunnel is encapsulated before 213 sending the packet to the next-hop BFR neighbour. 215 From the view of the IPv6 layer, the BIER header is a kind of Upper- 216 layer header (Layer-4). From the view of the BIER layer, the IPv6 217 encapsulation is a tunnel working as a "link" of BIER. With an End- 218 to-End view, the tunnel from BFIR to BFERs is a Layer-2.5 BIER (P2MP) 219 tunnel, and the BFIR-id is the BIER packet source-origin identifier, 220 and is unchanged through the BIER domain from BFIR to BFERs. 222 This model is similar to the "MPLS over IP" [RFC4023] or "MPLS over 223 UDP" [RFC7510] approach. A more general output of such approach in 224 IETF is "MPLS Segment Routing over IP" [RFC8663]. It makes use of 225 IPv4/IPv6 tunnel, IPv4/IPv6 UDP tunnel and IPv4/IPv6 GRE tunnel to 226 encapsulate the MPLS-based instructions. In fact, BIER-MPLS could 227 use this approach directly since BIER-MPLS is based on MPLS. 229 There may be, however, in certain cases some difficulty with 230 allocation of an MPLS label and advertisement through the control- 231 plane. For example, a simple inter-AS BIER deployment may want to 232 use the auto-configuration of BIFT-id using Non-MPLS BIER 233 encapsulation [RFC8296] as illustrated in 234 [I-D.geng-bier-ipv6-inter-domain]. This brings the need of a new 235 "Next Header" value to indicate the "Non-MPLS" BIER header. 237 For IPv4/IPv6 GRE, the "Next Header" is the 16-bit "Protocol Type" 238 field, and has adequate space for such requirement. 240 For IPv4/IPv6 UDP, the "Next Header" is the 16-bit "Destination Port" 241 field, and has adequate space for such requirement. 243 For IPv4/IPv6, the "Next Header" is a 8-bit value and needs to be 244 allocated from the "Assigned Internet Protocol Numbers" registry. 246 Reassembly/Re-fragmentation of a packet has to be executed on each 247 BFR in such case. This may be common and even friendly for a 248 protocol stack in a BFR software implementation, but it may impose 249 cost for a BFR hardware implementation. 251 IPv6 functions that are expected to be executed from BFIR to BFER are 252 assumed to be broken on the BFRs, for example, IPv6 Fragmentation/ 253 Assembly or IPSEC ESP. This is because the "IPv6 tunnel" and all its 254 functions is "terminated" on the BFRs. These functions, if desired, 255 may need to be re-designed in the "Layer-2.5" BIER mode. 257 For deployment security, it is necessary to ensure the "BIER" packet 258 is only using the allowed IPv6 tunnel. 260 3.2. Native IPv6 Model 262 The second conceptual model is a Native IPv6 Model that integrates 263 BIER as part of the IPv6 data plane, making it a "Layer-3 BIER" 264 approach. 266 |<----------(L3 BIER(P2MP) tunnel)--------->| 267 | | 268 +------+ +-------+ +-----+ +------+ 269 | BFIR |-------|Non-BFR|-------| BFR |--------| BFER | 270 +------+ +-------+ +-----+ +------+ 272 ------- physical link 274 <-----> BIER(P2MP) tunnel 276 In this model, BIER works as part of the IPv6 data plane. BFIR and 277 BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6 278 segment endpoints. On each BFR, the segment endpoint behaviour of 279 IPv6 data plane is executed, and there is no decapsulation of 280 receiving IPv6 tunnel and encapsulation of new IPv6 tunnel for 281 sending. 283 In this mode, BIER is integrated into the IPv6 data plane. The IPv6 284 source address is the BIER packet source-origin identifier, and is 285 unchanged through the BIER domain from BFIR to BFERs. 287 This model is similar to many examples emerging in the IETF community 288 which soley use the IPv6 data plane. SRv6 introduced in [RFC8754] 289 and [I-D.ietf-spring-srv6-network-programming] is an example. The 290 benefits of such approach includes reducing the number of 291 encapsulation layers, capability of deployment with non-capable 292 routers in a network, extending the technology in a wider inter-AS 293 scope using IP reachability, and capability of integrating the 294 functions of the IPv6 data plane. 296 This model typically needs an extension to IPv6 data plane, with an 297 IPv6 extension header or Option introduced. 299 IPv6 functions that are expected to be executed from BFIR to BFER is 300 supported if correctly designed, for example, IPv6 Fragmentation/ 301 Assembly or IPSEC ESP. 303 For deployment security, it is necessary to ensure the "BIER" packet 304 is in a trusted IPv6-based domain. 306 3.3. Encapsulation Approaches Considered 308 A number of approaches to the design of BIER-IPv6 encapsulation were 309 investigated by the BIER Working Group and were discussed in IETF 310 meetings and on the BIER list. This section divides these approaches 311 into the two conceptual models. 313 Transport-Independent Model approaches include: 315 Transport-Independent BIER [I-D.xu-bier-encapsulation]. 317 BIERin6 [I-D.zhang-bier-bierin6]. 319 Native IPv6 Model approaches include: 321 BIER-over-IPv6 [I-D.pfister-bier-over-ipv6]. 323 BIERv6 [I-D.xie-bier-ipv6-encapsulation]. 325 4. Requirements 327 There have been several suggested requirements, on the BIER email 328 list and in meetings, which have been used to form BIER IPv6 329 requirements used to help the wg evaluate against the proposed 330 solutions. There is also many further discussions on the list about 331 BIER IPv6 requirements from different scenarios. 333 Considering that the importance of requirement for BIER IPv6 solution 334 is different, in this document, the requirements are divided into two 335 groups: mandatory and optional. The requirements in the mandatory 336 group are considered necessary for any BIER IPv6 solution, while the 337 requirements in the optional group should be considered but are not 338 mandatory. 340 4.1. Mandatory Requirements 342 4.1.1. L2 Agnostic 344 The solution must be agnostic to the underlying L2 data link type. 345 The solution needs to support P2P ethernet links as well as shared 346 media ethernet links without requiring the LAN switch to perform BIER 347 snooping. 349 4.1.2. Support BIER architecture 351 The solution must support the BIER architecture. 353 Multiple sub-domains bound to one or many topologies or algorithms, 354 multiple sets for more BFERs, multiple Bit String Lengths for 355 different forwarding capabilities, and multiple BIFTs for ECMP are 356 considered essential functions of BIER and need to be supported. 358 4.1.3. Conform to existing IPv6 Spec 360 The proposed encapsulation must conform to the IPv6 specification and 361 guidelines as described in RFC8200. If new extensions to existing 362 IPv6 specification are required, it needs to be discussed and 363 reviewed by the 6man working-group. 365 4.1.4. Support deployment with Non-BFR routers 367 The solution must support deployments with Non-BFR routers. This is 368 beneficial to the deployment of BIER, especially in early deployments 369 when some routers do not support BIER forwarding but support IPv6 370 forwarding. This is also the No.1 charter item, "Transition 371 Mechanisms and Partial Deployments" of the BIER WG. 373 4.1.5. Support inter-AS multicast deployment 375 Inter-AS multicast support is needed for ease of provisioning the 376 P2MP transport service to enterprises. This could greatly increase 377 the scalability of BIER, as it is usually considered to be suitable 378 only for small intra-AS scenarios. 380 4.1.6. Support Simple Encapsulation 382 The solution must avoid requiring different encapsulation types. A 383 solution needs to do careful trade-off analysis and select one 384 encapsulation as its proposal for best coverage of various scenarios. 386 4.1.7. Support Deployment Security 388 The proposed solution must include careful security considerations, 389 including all that is already considered in BIER architecture RFC8279 390 and RFC8296, and other security concerns that may raise due to the 391 addition of IPv6. 393 4.2. Optional Requirements 395 4.2.1. Support MVPN 397 The solution MAY support MVPN services that is defined in [RFC6513]. 398 When MVPN is supported, it should work in a "tunnel" mode, 399 encapsulating IP or IPv6 multicast packet in an outer IPv6 header. 400 When MVPN is supported, it is suggested to think about both intra-AS 401 and inter-AS deployment. 403 4.2.2. Support OAM 405 BIER OAM MAY be supported, either directly using existing method, or 406 specify some variant method for the same function. It may be 407 considered essential as part of the BIER architecture in some cases. 409 4.2.3. Support IPSEC 411 IPSEC is optional to IPv6 and multicast. It is preferred to support 412 IPSEC, including AH/ESP. If IPSEC is to be supported, it shouldn't 413 require hop-by-hop encryption/decryption. 415 4.2.4. Support Fragmentation 417 As part of IPv6 specification [RFC8200], BIER IPv6 may support 418 fragmentation on BFIR and assembly on BFER. Support of Fragmentation 419 can enhance the capability of BIER leveraging the BIER-MTU as 420 introduced in section 3 of [RFC8296]. If Fragmentation is to be 421 supported, it shouldn't require fragmentation and re-assembly at each 422 hop. 424 4.2.5. Support hardware fast path 426 If a proposed solution is intended for some scenarios like service- 427 provider networks, it should enable the processing and forwarding of 428 BIER packets in hardware fast path. 430 5. IANA Considerations 432 Some BIERv6 encapsulation proposals do not require any action from 433 IANA while other proposals require new BIER Destination Option 434 codepoints from IPv6 sub-registries, new "Next header" values, or 435 require new IP Protocol codes. This document, however, does not 436 require anything from IANA. 438 6. Security Considerations 440 There are no security issues introduced by this draft. 442 7. Acknowledgement 444 Thank you to Eric Rosen for his listed set of requirements on the 445 bier wg list. 447 8. Normative References 449 [I-D.geng-bier-ipv6-inter-domain] 450 Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain 451 Multicast Deployment using BIERv6", draft-geng-bier-ipv6- 452 inter-domain-01 (work in progress), January 2020. 454 [I-D.ietf-bier-use-cases] 455 Nainar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 456 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 457 Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-11 458 (work in progress), March 2020. 460 [I-D.ietf-spring-srv6-network-programming] 461 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 462 Matsushima, S., and Z. Li, "SRv6 Network Programming", 463 draft-ietf-spring-srv6-network-programming-16 (work in 464 progress), June 2020. 466 [I-D.pfister-bier-over-ipv6] 467 Pfister, P. and I. Wijnands, "An IPv6 based BIER 468 Encapsulation and Encoding", draft-pfister-bier-over- 469 ipv6-01 (work in progress), October 2016. 471 [I-D.xie-bier-ipv6-encapsulation] 472 Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., 473 Zhu, Y., Qin, Z., Shin, M., and X. Geng, "Encapsulation 474 for BIER in Non-MPLS IPv6 Networks", draft-xie-bier- 475 ipv6-encapsulation-07 (work in progress), June 2020. 477 [I-D.xu-bier-encapsulation] 478 Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet, 479 C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit 480 Index Explicit Replication (BIER) Encapsulation Header", 481 draft-xu-bier-encapsulation-06 (work in progress), 482 September 2016. 484 [I-D.zhang-bier-bierin6] 485 Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and 486 M. McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier- 487 bierin6-04 (work in progress), January 2020. 489 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 490 RFC 1112, DOI 10.17487/RFC1112, August 1989, 491 . 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, 495 DOI 10.17487/RFC2119, March 1997, 496 . 498 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 499 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 500 December 1998, . 502 [RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., 503 "Encapsulating MPLS in IP or Generic Routing Encapsulation 504 (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, 505 . 507 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 508 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 509 2012, . 511 [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, 512 "Encapsulating MPLS in UDP", RFC 7510, 513 DOI 10.17487/RFC7510, April 2015, 514 . 516 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 517 (IPv6) Specification", STD 86, RFC 8200, 518 DOI 10.17487/RFC8200, July 2017, 519 . 521 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 522 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 523 Explicit Replication (BIER)", RFC 8279, 524 DOI 10.17487/RFC8279, November 2017, 525 . 527 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 528 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 529 for Bit Index Explicit Replication (BIER) in MPLS and Non- 530 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 531 2018, . 533 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 534 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 535 DOI 10.17487/RFC8663, December 2019, 536 . 538 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 539 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 540 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 541 . 543 Appendix A. Solutions Evaluation 545 The following are solutions that have been proposed to solve BIER in 546 IPv6 environments. Some solutions propose encoding while others 547 propose encapsulation. It is recommended for the wg to evaluate 548 these solutions against the requirements listed previously in order 549 to make informed decisions on solution readiness. 551 As illustrated in these examples, the BIER header, or the BitString, 552 may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload, 553 or IPv6 Tunnel Packet: 555 A.1. BIER-ETH encapsulation in IPv6 networks 557 +---------------+-----------------+------------------- 558 | Ethernet | BIER header | payload 559 | (ethType = | (BIFT-id, ...) | 560 | 0xAB37) | | 561 | | Next Header | 562 +---------------+-----------------+------------------- 564 BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined 565 in [RFC8296]) can be used to transport the multicast data in the IPv6 566 network by encapsulating the multicast user data payload within the 567 BIER-ETH header. However, BIER-ETH in IPv6 networks is not 568 considered to be a "BIER natively in IPv6" solution which utilizes 569 the IPv6 header to forward the packet. 571 Mixed use of BIER-ETH in a native IPv6 solution is up to the solution 572 and is outside the scope of this document. 574 A.2. Encode Bitstring in IPv6 destination address 576 +---------------+------------------- 577 | IPv6 header | payload 578 | (BitString in | 579 | DA lower bits)| 580 | Next Header | 581 +---------------+------------------- 583 As described in [I-D.pfister-bier-over-ipv6], The information 584 required by BIER is stored in the destination IPv6 address. The BIER 585 BitString is encoded in the low-order bits of the IPv6 destination 586 address of each packet. The high-order bits of the IPv6 destination 587 address are used by intermediate routers for unicast forwarding, 588 deciding whether a packet is a BIER packet, and if so, to identify 589 the BIER Sub-Domain, Set Identifier and BitString length. No 590 additional extension or encapsulation header is required. Instead of 591 encapsulating the packet in IPv6, the payload is attached to the BIER 592 IPv6 header and the IPv6 protocol number is set to the type of the 593 payload. If the payload is UDP, the UDP checksum needs to change 594 when the BitString in the IPv6 destination address changes. 596 A.3. Add BIER header into IPv6 Extension Header 598 +---------------+-----------------+------------------- 599 | IPv6 header | IPv6 Ext header | payload 600 | | (BIER header in | 601 | | TLV Type = X) | 602 | Next Header | Next Header | 603 +---------------+-----------------+------------------- 605 According to [RFC8200] In IPv6, optional internet-layer information 606 is encoded in separate headers that may be placed between the IPv6 607 header and the upper- layer header in a packet. There is a small 608 number of such extension headers, each one identified by a distinct 609 Next Header value. An IPv6 packet may carry zero, one, or more 610 extension headers, each identified by the Next Header field of the 611 preceding header. Extension headers (except for the Hop-by-Hop 612 Options header) are not processed, inserted, or deleted by any node 613 along a packet's delivery path, until the packet reaches the node (or 614 each of the set of nodes, in the case of multicast) identified in the 615 Destination Address field of the IPv6 header. The Hop-by-Hop Options 616 header is not inserted or deleted, but may be examined or processed 617 by any node along a packet's delivery path, until the packet reaches 618 the node (or each of the set of nodes, in the case of multicast) 619 identified in the Destination Address field of the IPv6 header. The 620 Hop-by-Hop Options header, when present, must immediately follow the 621 IPv6 header. Its presence is indicated by the value zero in the Next 622 Header field of the IPv6 header. 624 Two of the currently-defined extension headers are the Hop-by-Hop 625 Options header and the Destination Options header which carry a 626 variable number of type-length-value (TLV) encoded "options". 628 In [I-D.xie-bier-ipv6-encapsulation] an IPv6 BIER Destination Option 629 is carried by the IPv6 Destination Option Header (indicated by a Next 630 Header value 60). It is initialized in a packet sent by an IPv6 BFIR 631 router to inform the following BFR routers in an IPv6 BIER domain to 632 replicate to destination BFER routers hop-by-hop. BIER is generally 633 a hop-by-hop and one-to-many architecture and it is required for a 634 BIER IPv6 encapsulation to include the BIER Header ([RFC8296]) as an 635 IPv6 Extension Header, to pilot the hop-by-hop BIER replication. 637 Hop by hop Options Headers may be considered. The Hop-by-Hop Options 638 header is used to carry optional information that may be examined and 639 processed by every node along a packet's delivery path. The Hop-by- 640 Hop Options header is identified by a Next Header value of 0 in the 641 IPv6 header. 643 Defining New Extension Headers and Options may also be considered, if 644 the IPv6 Destination Option Header is not good enough and new 645 extension headers can solve the problem better. 647 Such proposals may include requests to IANA to allocate a "BIER 648 Option" code from "Destination Options and Hop-by-Hop Options", and/ 649 or a "BIER Option Header" code from "IPv6 Extension Header Types". 651 A.4. Transport BIER as IPv6 payload 653 +---------------+-----------------+------------------- 654 | IPv6 header | IPv6 Ext header | BIER Hdr + payload 655 | | (optional) | as IPv6 payload 656 | | | 657 | Next Header | Next Header = X | 658 +---------------+-----------------+------------------- 660 There is a proposal for a transport-independent BIER encapsulation 661 header which is applicable regardless of the underlying transport 662 technology. As described in [I-D.xu-bier-encapsulation] and 663 [I-D.zhang-bier-bierin6], the BIER header, and the payload following 664 it, can be combined as an IPv6 payload, and be indicated by a new 665 Upper-layer IPv6 Next-Header value. A unicast IPv6 destination 666 address is used for the replication and changes when replicating a 667 packet out to a neighbor. 669 Such proposals may include a request to IANA to allocate an IPv6 670 Next-Header code from "Assigned Internet Protocol Numbers". 672 A.5. Tunnelling BIER in a IPv6 tunnel 674 +---------------+-----------------+------------+---------------- 675 | IPv6 header | IPv6 Ext header | GRE header | 676 | | (optional) | | BIER Hdr + 677 | | | | payload as GRE 678 | Next Header | Next Header | Proto = X | Payload 679 +---------------+-----------------+------------+---------------- 681 A generic IPv6 Tunnel could be used to encapsulate the bier packet 682 within an IPv6 domain. 684 GRE is a mechanism by which any ethernet payload can be carried by an 685 IP GRE tunnel due to the 16-bits 'Protocol Type' field. Both IPv4 686 and IPv6 can be used to carry GRE. The Ethernet type codepoint 687 0xAB37, defined for BIER, can be used in a GRE header to indicate the 688 subsequent BIER header and payload in an IPv6 network. 690 +---------------+-----------------+------------+---------------- 691 | IPv6 header | IPv6 Ext header | UDP header | 692 | | (optional) | | BIER Hdr + 693 | | | | payload as UDP 694 | Next Header | Next Header | DPort = X | Payload 695 +---------------+-----------------+------------+---------------- 697 UDP-based tunnelling is another mechanism which uses a specific UDP 698 port to indicate a UDP payload format. Both IPv4 and IPv6 can 699 support UDP. Such UDP-based tunnels can be used for BIER in a IPv6 700 network by defining a new UDP port to indicate the BIER header and 701 payload. 703 Authors' Addresses 704 Mike McBride 705 Futurewei 707 Email: michael.mcbride@futurewei.com 709 Jingrong Xie 710 Huawei 712 Email: xiejingrong@huawei.com 714 Senthil Dhanaraj 715 Huawei 717 Email: senthil.dhanaraj@huawei.com 719 Rajiv Asati 720 Cisco 722 Email: rajiva@cisco.com 724 Yongqing Zhu 725 China Telecom 727 Email: zhuyq8@chinatelecom.cn 728 Gyan S. Mishra 729 Verizon Inc. 731 13101 Columbia Pike 733 Silver Spring 734 , 736 MD 20904 738 United States of America 740 Phone: 741 301 502-1347 743 Email: 744 gyan.s.mishra@verizon.com