idnits 2.17.1 draft-ietf-bier-ipv6-requirements-04.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 15, 2020) is 1563 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: 'RFC2473' is defined on line 397, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-xie-bier-ipv6-encapsulation-04 == Outdated reference: A later version (-09) exists of draft-zhang-bier-bierin6-04 ** Downref: Normative reference to an Informational RFC: RFC 8354 Summary: 1 error (**), 0 flaws (~~), 5 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: July 18, 2020 S. Dhanaraj 6 Huawei 7 R. Asati 8 Cisco 9 Y. Zhu 10 China Telecom 11 January 15, 2020 13 BIER IPv6 Requirements 14 draft-ietf-bier-ipv6-requirements-04 16 Abstract 18 The BIER WG includes, in its charter, work on developing mechanisms 19 to transport BIER natively in IPv6. This document is intended to 20 help the WG with this effort by specifying requirements for 21 transporting packets, with Bit Index Explicit Replication (BIER) 22 headers, in an IPv6 environment. There will be a need to send IPv6 23 payloads, to multiple IPv6 destinations, using BIER. There have been 24 several proposed solutions in this area. But there hasn't been a 25 document which describes the problem and lists the requirements. The 26 goal of this document is to describe the BIER IPv6 requirements, 27 summarize the proposed solutions, and guide the working group in 28 understanding the benefits, and drawbacks, of the various solutions 29 and to help in the development of acceptable solutions. 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 July 18, 2020. 48 Copyright Notice 50 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 69 3. BIER IPv6 Scenario's . . . . . . . . . . . . . . . . . . . . 4 70 3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4 71 3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4 72 3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 5 73 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . . 5 75 4.2. Hop by hop SA or DA modification . . . . . . . . . . . . 5 76 4.3. L4 Inspection . . . . . . . . . . . . . . . . . . . . . . 6 77 4.4. Multicast address in SA field . . . . . . . . . . . . . . 6 78 4.5. Incorrect bits . . . . . . . . . . . . . . . . . . . . . 6 79 4.6. SA filtering . . . . . . . . . . . . . . . . . . . . . . 7 80 4.7. BIER architecture support . . . . . . . . . . . . . . . . 7 81 4.8. Simple Encapsulation . . . . . . . . . . . . . . . . . . 7 82 4.9. Hardware fast path . . . . . . . . . . . . . . . . . . . 7 83 4.10. Conform to existing IPv6 Spec . . . . . . . . . . . . . . 7 84 4.11. Support Fragmentation . . . . . . . . . . . . . . . . . . 8 85 4.12. Support IPv6 Security . . . . . . . . . . . . . . . . . . 8 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 88 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 89 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 90 Appendix A. Solutions Evaluation . . . . . . . . . . . . . . . . 9 91 A.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 10 92 A.2. Encode Bitstring in IPv6 destination address . . . . . . 11 93 A.3. Add BIER header into IPv6 Extension Header . . . . . . . 11 94 A.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 13 95 A.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 13 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 99 1. Introduction 101 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 102 that provides optimal multicast forwarding, without requiring 103 intermediate routers to maintain per-flow state, through the use of a 104 multicast-specific BIER header. [RFC8296] defines two types of BIER 105 encapsulation to run on physical links: one is BIER MPLS 106 encapsulation to run on various physical links that support MPLS, the 107 other is non-MPLS BIER Ethernet encapsulation to run on ethernet 108 links, with an ethertype 0xAB37. This document describes using BIER 109 in non-MPLS IPv6 environments. We explain the requirements of 110 transporting IPv4/IPv6 multicast payloads, from an IPv6 router (BFIR) 111 to multicast IPv6 destinations (BFERs), using BIER. This can include 112 native IPv6 encapsulation and generic tunneling. Native IPv6, in 113 this document, is defined as BIER not encapsulated in mpls or 114 ethernet. The goal of this document is to help the BIER WG evaluate 115 the BIER v6 requirements and solutions in order to begin adopting 116 solution drafts. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 1.2. Terminology 126 o BIER: Bit Index Explicit Replication. Provides optimal multicast 127 forwarding through adding a BIER header and removing state in 128 intermediate routers. 130 o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe 131 the three types of Ethernet modes that will be forwarded to 132 multiple destinations 134 2. Problem Statement 136 The problem is the ability of the network to transport BUM packets, 137 with BIER headers, in an IPv6 environment. In IPv6 networks, many 138 deployments use non-MPLS encapsulation for unicast as the data-plane. 139 In such case, it may be expected to have a BIER IPv6 encapsulation 140 which is compliant with various kinds of physical links, perhaps in a 141 hop-by-hop manner, and maintain the benefit of "fast reroute" of an 142 IPv6 tunnel. Evaluating the BIER IPv6 requirements will help 143 determine the best solutions to address these problems. 145 3. BIER IPv6 Scenario's 147 +--------------------------------------------+ 148 | | 149 | +------+ 150 | | BFER | 151 +------+ IPv6 +------+ 152 | BFIR | | 153 +------+ Network +------+ 154 | | BFER | 155 | +------+ 156 | | 157 +--------------------------------------------+ 159 This basic scenario depicts the need to replicate bier packets from a 160 BFIR to BFERs across an IPv6 core. The IPv6 environment may include 161 a variety of link types, may be entirely IPv6, may be dual stack or 162 any type of combination which includes IPv6. Regardless of the 163 environment, there are times when a BIER header, including the BIER 164 bitstring used to determine the set of BIER forwarding egress 165 routers, will need to traverse a IPv6 domain. The ways in which BIER 166 will function in an IPv6 environment is the problem that needs to be 167 solved. [RFC8354] lists some good IPv6 related use cases which we 168 will similarly reference in this document. 170 3.1. BIERv6 for Access Network 172 Access networks deliver a variety of types of multicast video traffic 173 from the service provider's network to the home (or Enterprise) 174 environment and from the home towards the service provider's network. 176 There will be a need to send traffic from the IPv4 access towards the 177 service provider's IPv6 network and vice versa. A packet could be 178 mapped into a providers IPv6 network through the use of a BIERv6 179 header. The access devices would not need to know specific details 180 about the packet to perform this mapping; instead the access device 181 would only need to know how to process a BIER header unless there is 182 end to end IPv6. 184 3.2. BIERv6 for Data Center 186 Some Data Center operators are transitioning their Data Center 187 infrastructure from IPv4 to native IPv6 only, in order to cope with 188 IPv4 address depletion and to achieve larger scale. In such 189 environment, BIERv6, can be used to natively steer multicast data 190 across an IPv6 data center. 192 3.3. BIERv6 for Core Networks 194 While the overall amount of traffic offered to the network continues 195 to grow and considering that multiple types of traffic with different 196 characteristics and requirements are quickly converging over single 197 network architecture, the network operators are starting to face new 198 challenges. 200 Some operators are currently building, or plan to build in the near 201 future, an IPv6 only native infrastructure for their core network. 202 Having a native BIERv6 infrastructure will help maintain simplicity 203 of the network and reduce state versus traditional IP Multicast. 205 4. Requirements 207 There have been several suggested requirements, on the BIER email 208 list and in meetings, which have been used to form BIER IPv6 209 requirements used to help the wg evaluate against the proposed 210 solutions: 212 4.1. L2 Agnostic 214 The solution should be agnostic to the underlying L2 data link type. 216 4.2. Hop by hop SA or DA modification 218 The solution should not require hop-by-hop modification of the IP 219 source address field. 221 Solutions that do not require Hop-by-hop SA modification are 222 preferred. Solutions which maintain the SA will help fast-path 223 forwarding (req 4.9 in this doc), are beneficial for receiving 224 notices from the BFIR for functions like BIER PING, TRACE and MTU 225 notification, are beneficial for identifying an MVPN instance to help 226 remove more encapsulation such as Service Label, are beneficial for 227 SA filtering (req 4.6 in this doc), and are beneficial for data 228 origin authentication if IPSEC is desired (req 4.12 in this doc). 230 The solution should use a IPv6 unicast address in the DA to satisfy 231 the BIER architecture without introducing additional tunnel 232 encapsulation, and thus may require DA modification by each BFR hop. 234 It is commonly thought that BIERv6 could use a multicast address, as 235 BIER is one-hop replication on each BFR in normal cases. However, as 236 described in section 6.9 of [RFC8279], it is useful to support non- 237 BIER routers within a BIER domain. From the wg discussion about this 238 document, focus is on the advantages of using unicast addresses that 239 otherwise could not be possible by using a multicast address or 240 anycast address for two cases: replication from a BFR to other BFR(s) 241 connected by Layer-3 Non-BFR router(s) without using tunneling 242 techniques, and replication from a BFR to other BFR(s) connected by 243 Layer-2 switch(es) without broadcasting or snooping on Layer-2 244 switch(es) in between. Based on the natural reachability of an IPv6 245 unicast address, it can support the multi-hop replication cases as 246 well as the one-hop replication case using one encapsulation. 248 4.3. L4 Inspection 250 The solution should not require the BFRs to inspect layer 4 or 251 require any changes to layer 4. 253 The proposals requiring BIER header encapsulated as part of the 254 payload may conflict with the layers of IP protocol stack. On the 255 one hand, fast-path BIER forwarding has to be based on the L4 256 inspection of the BIER header within the payload, and on the other 257 hand, the BIER forwarding needs to change the BitString in the BIER 258 header of the payload, which in turn conflicts with other L3 259 functions. Following are some examples. 261 One example is in IP fragmentation case, where a packet may need to 262 be fragmented by a BFIR, according to the BIER-MTU defined in 263 RFC8296, into one packet with BIER header and 1500 bytes of payload, 264 and another packet with the remaining 500 bytes of payload. When BFR 265 B receives the second fragmentation packet from BFR A, BFR B can't 266 forward this packet because BFR B doesn't have the BIER header in the 267 second fragmentation packet. Section 4.11 describes the 268 fragmentation requirements. 270 The second example is in IPSEC case, where the BIER header is part of 271 the payload for confidentiality or integrity. The need to change the 272 BitString in the BIER Header, when forwarding BIER packets, makes it 273 incompatible with IPSEC. Section 4.12 describes the IPSEC 274 requirements. 276 4.4. Multicast address in SA field 278 The solution should not allow a multicast address to be put in the IP 279 source address field. According to [RFC1112] "A host group address 280 must never be placed in the source address field or anywhere in a 281 source route or record route option of an outgoing IP datagram." 283 4.5. Incorrect bits 285 The solution should not assume that bits never get set incorrectly. 287 If a packet with incorrect bits is set, it should not damage BIERv6 288 functionality or any other functions such as Unicast Reverse Path 289 Forwarding (URPF), nor should it cause loops or duplicates as 290 described in section 6.8 of [RFC8279]. 292 4.6. SA filtering 294 The solution should not require changes in source address filtering 295 procedures. For instance if a host uses a "BIER address" as its 296 source address in a given packet, and the packet doesn't get dropped 297 according to existing SA filtering procedures, the packet may elicit 298 responses that put the BIER address in their destination address 299 fields. This could be a security issue, as it creates an attack 300 vector that can create 64 responses to a single probe. 302 4.7. BIER architecture support 304 It should be possible to use the solution to support the entire BIER 305 architecture. The ability to bypass Non-BIER routers and L2 switches 306 is part of the BIER architecture and having this ability is a 307 mandatory requirement. 309 Multiple sub-domains bound to one or many topologies or algorithms, 310 multiple sets for more BFERs, multiple Bit String Length for 311 different forwarding capability, and multiple BIFTs for ECMP should 312 be supported. 314 4.8. Simple Encapsulation 316 The solution should avoid requiring different encapsulation types, or 317 complex tunneling techniques, to support BIER as an E2E multicast 318 transport. 320 A single encapsulation should support Layer-2 switches within BFRs, 321 or non-BFR within a BIER domain, or inter-domain deployment of BIER. 323 4.9. Hardware fast path 325 The solution should enable the processing and forwarding of BIER 326 packets in hardware fast path. 328 4.10. Conform to existing IPv6 Spec 330 The proposed encapsulation must conform to the IPv6 specification and 331 guidelines as described in RFC8200. It should not require any new 332 modifications to the IPv6 specification aside from extensions to 333 existing mechanisms such as IPv6 Options. 335 4.11. Support Fragmentation 337 The proposed encapsulation must support fragmentation. It shouldn't 338 require fragmentation and re-assembly at each hop. 340 4.12. Support IPv6 Security 342 The proposed encapsulation should support IPv6 security including AH/ 343 ESP extension headers. It shouldn't require hop-by-hop encryption/ 344 decryption. 346 5. IANA Considerations 348 Some BIERv6 encapsulation proposals do not require any action from 349 IANA while other proposals require new BIER Destination Option 350 codepoints from IPv6 sub-registries, new "Next header" values, or 351 require new IP Protocol codes. This document, however, does not 352 require anything from IANA. 354 6. Security Considerations 356 There are no security issues introduced by this draft. 358 7. Acknowledgement 360 Thank you to Eric Rosen for his listed set of requirements on the 361 bier wg list. 363 8. Normative References 365 [I-D.pfister-bier-over-ipv6] 366 Pfister, P. and I. Wijnands, "An IPv6 based BIER 367 Encapsulation and Encoding", draft-pfister-bier-over- 368 ipv6-01 (work in progress), October 2016. 370 [I-D.xie-bier-ipv6-encapsulation] 371 Xie, J., Geng, L., McBride, M., Asati, R., and S. 372 Dhanaraj, "Encapsulation for BIER in Non-MPLS IPv6 373 Networks", draft-xie-bier-ipv6-encapsulation-04 (work in 374 progress), December 2019. 376 [I-D.xu-bier-encapsulation] 377 Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet, 378 C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit 379 Index Explicit Replication (BIER) Encapsulation Header", 380 draft-xu-bier-encapsulation-06 (work in progress), 381 September 2016. 383 [I-D.zhang-bier-bierin6] 384 Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and 385 M. McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier- 386 bierin6-04 (work in progress), January 2020. 388 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 389 RFC 1112, DOI 10.17487/RFC1112, August 1989, 390 . 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, 394 DOI 10.17487/RFC2119, March 1997, 395 . 397 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 398 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 399 December 1998, . 401 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 402 (IPv6) Specification", STD 86, RFC 8200, 403 DOI 10.17487/RFC8200, July 2017, 404 . 406 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 407 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 408 Explicit Replication (BIER)", RFC 8279, 409 DOI 10.17487/RFC8279, November 2017, 410 . 412 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 413 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 414 for Bit Index Explicit Replication (BIER) in MPLS and Non- 415 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 416 2018, . 418 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 419 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 420 Routing in Networking (SPRING)", RFC 8354, 421 DOI 10.17487/RFC8354, March 2018, 422 . 424 Appendix A. Solutions Evaluation 426 The following are solutions that have been proposed to solve BIER in 427 IPv6 environments. Some solutions propose encoding while others 428 propose encapsulation. It is recommended for the wg to evaluate 429 these solutions against the requirements listed previously in order 430 to make informed decisions on solution readiness. 432 As illustrated in these examples, the BIER header, or the BitString, 433 may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload, 434 or IPv6 Tunnel Packet: 436 A.1. BIER-ETH encapsulation in IPv6 networks 438 +---------------+-----------------+------------------- 439 | Ethernet | BIER header | payload 440 | (ethType = | (BIFT-id, ...) | 441 | 0xAB37) | | 442 | | Next Header | 443 +---------------+-----------------+------------------- 445 BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined 446 in [RFC8296]) can be used to transport the multicast data in the IPv6 447 network by encapsulating the multicast user data payload within the 448 BIER-ETH header. However, using BIER-ETH in IPv6 networks is not 449 considered to be a native IPv6 solution which utilizes the IPv6 450 header to forward the packet. Below listed are some of the 451 properties of BIER-ETH encapsulation which could be seen as the 452 reasons for the same, 454 o BIER-ETH is not agnostic to the underlying (L2) data link type. 455 It can be deployed only in the networks with Ethernet data link 456 and cannot be deployed in an network which deploys any other data 457 link types. Use of BIER-ETH in IPv6 networks might also result in 458 using different BIER encapsulations, when BIER is used as a E2E 459 multicast transport across a larger heterogeneous IPv6 networks 460 with different data link types used in different layers of the 461 network. 463 o BIER-ETH in IPv6 networks is considered similar to 6PE solution 464 where-in the multicast user data packet is encapsulated with-in 465 the BIER-MPLS header. 467 * It is worth noting that the only major difference between BIER- 468 MPLS and BIER-Non-MPLS header is that BIER-MPLS uses downstream 469 assigned MPLS label while BIER-Non-MPLS header uses a domain- 470 wide-unique BIFT-id. While the use of domain-wide-unique BIFT- 471 id in BIER-ETH header takes away the complexity of allocation 472 and state maintenance from the network, it still requires some 473 sort of ID (similar to label) to identify the application 474 context after the decapsulation of BIER header (example: MVPN 475 VRF Label). Encoding of such an ID/LABEL before encapsulating 476 the multicast user data payload with BIER-ETH header cannot be 477 avoided. 479 * The absence of an IPv6 header, and the optional IPv6 extension 480 headers, deprives BIER of some of the useful cases (ex: Use of 481 IPv6 address for identification of network function or service 482 mapping) that is otherwise possible in native IPv6 483 encapsulation which utilizes a IPv6 header. 485 * Tunneling of BIER packets is one common technique used for FRR, 486 to tunnel over BIER incapable nodes etc. While it is possible 487 for the BIER-ETH encapsulated packet to be further encapsulated 488 within a GRE6, etc tunnel, it might not be possible to parse 489 and decapsulate different types of tunnel headers and forward 490 the BIER packet completely in hardware fast path similar to the 491 label stack processing in BIER-MPLS networks. It would be 492 useful to select an encapsulation which could help in 493 processing the tunnel and BIER header and make the forwarding 494 decision completely in hardware fast path, which is lacking in 495 BIER-ETH encapsulation if chosen to be deployed in pure IPv6 496 networks. 498 A.2. Encode Bitstring in IPv6 destination address 500 +---------------+------------------- 501 | IPv6 header | payload 502 | (BitString in | 503 | DA lower bits)| 504 | Next Header | 505 +---------------+------------------- 507 As described in [I-D.pfister-bier-over-ipv6], The information 508 required by BIER is stored in the destination IPv6 address. The BIER 509 BitString is encoded in the low-order bits of the IPv6 destination 510 address of each packet. The high-order bits of the IPv6 destination 511 address are used by intermediate routers for unicast forwarding, 512 deciding whether a packet is a BIER packet, and if so, to identify 513 the BIER Sub-Domain, Set Identifier and BitString length. No 514 additional extension or encapsulation header is required. Instead of 515 encapsulating the packet in IPv6, the payload is attached to the BIER 516 IPv6 header and the IPv6 protocol number is set to the type of the 517 payload. If the payload is UDP, the UDP checksum needs to change 518 when the BitString in the IPv6 destination address changes. 520 A.3. Add BIER header into IPv6 Extension Header 521 +---------------+-----------------+------------------- 522 | IPv6 header | IPv6 Ext header | payload 523 | | (BIER header in | 524 | | TLV Type = X) | 525 | Next Header | Next Header | 526 +---------------+-----------------+------------------- 528 According to [RFC8200] In IPv6, optional internet-layer information 529 is encoded in separate headers that may be placed between the IPv6 530 header and the upper- layer header in a packet. There is a small 531 number of such extension headers, each one identified by a distinct 532 Next Header value. An IPv6 packet may carry zero, one, or more 533 extension headers, each identified by the Next Header field of the 534 preceding header. Extension headers (except for the Hop-by-Hop 535 Options header) are not processed, inserted, or deleted by any node 536 along a packet's delivery path, until the packet reaches the node (or 537 each of the set of nodes, in the case of multicast) identified in the 538 Destination Address field of the IPv6 header. The Hop-by-Hop Options 539 header is not inserted or deleted, but may be examined or processed 540 by any node along a packet's delivery path, until the packet reaches 541 the node (or each of the set of nodes, in the case of multicast) 542 identified in the Destination Address field of the IPv6 header. The 543 Hop-by-Hop Options header, when present, must immediately follow the 544 IPv6 header. Its presence is indicated by the value zero in the Next 545 Header field of the IPv6 header. 547 Two of the currently-defined extension headers are the Hop-by-Hop 548 Options header and the Destination Options header which carry a 549 variable number of type-length-value (TLV) encoded "options". 551 In [I-D.xie-bier-ipv6-encapsulation] an IPv6 BIER Destination Option 552 is carried by the IPv6 Destination Option Header (indicated by a Next 553 Header value 60). It is initialized in a packet sent by an IPv6 BFIR 554 router to inform the following BFR routers in an IPv6 BIER domain to 555 replicate to destination BFER routers hop-by-hop. BIER is generally 556 a hop-by-hop and one-to-many architecture and it is required for a 557 BIER IPv6 encapsulation to include the BIER Header ([RFC8296]) as an 558 IPv6 Extension Header, to pilot the hop-by-hop BIER replication. 560 Hop by hop Options Headers may be considered. The Hop-by-Hop Options 561 header is used to carry optional information that may be examined and 562 processed by every node along a packet's delivery path. The Hop-by- 563 Hop Options header is identified by a Next Header value of 0 in the 564 IPv6 header. 566 Defining New Extension Headers and Options may also be considered, if 567 the IPv6 Destination Option Header is not good enough and new 568 extension headers can solve the problem better. 570 Such proposals may include requests to IANA to allocate a "BIER 571 Option" code from "Destination Options and Hop-by-Hop Options", and/ 572 or a "BIER Option Header" code from "IPv6 Extension Header Types". 574 A.4. Transport BIER as IPv6 payload 576 +---------------+-----------------+------------------- 577 | IPv6 header | IPv6 Ext header | BIER Hdr + payload 578 | | (optional) | as IPv6 payload 579 | | | 580 | Next Header | Next Header = X | 581 +---------------+-----------------+------------------- 583 There is a proposal for a transport-independent BIER encapsulation 584 header which is applicable regardless of the underlying transport 585 technology. As described in [I-D.xu-bier-encapsulation] and 586 [I-D.zhang-bier-bierin6], the BIER header, and the payload following 587 it, can be combined as an IPv6 payload, and be indicated by a new 588 Upper-layer IPv6 Next-Header value. A unicast IPv6 destination 589 address is used for the replication and changes when replicating a 590 packet out to a neighbor. 592 Such proposals may include a request to IANA to allocate an IPv6 593 Next-Header code from "Assigned Internet Protocol Numbers". 595 A.5. Tunneling BIER in a IPv6 tunnel 597 +---------------+-----------------+------------+---------------- 598 | IPv6 header | IPv6 Ext header | GRE header | 599 | | (optional) | | BIER Hdr + 600 | | | | payload as GRE 601 | Next Header | Next Header | Proto = X | Payload 602 +---------------+-----------------+------------+---------------- 604 A generic IPv6 Tunnel could be used to encapsulate the bier packet 605 within an IPv6 domain. 607 GRE is a mechanism by which any ethernet payload can be carried by an 608 IP GRE tunnel due to the 16-bits 'Protocol Type' field. Both IPv4 609 and IPv6 can be used to carry GRE. The Ethernet type codepoint 610 0xAB37, defined for BIER, can be used in a GRE header to indicate the 611 subsequent BIER header and payload in an IPv6 network. 613 +---------------+-----------------+------------+---------------- 614 | IPv6 header | IPv6 Ext header | UDP header | 615 | | (optional) | | BIER Hdr + 616 | | | | payload as UDP 617 | Next Header | Next Header | DPort = X | Payload 618 +---------------+-----------------+------------+---------------- 620 UDP-based tunneling is another mechanism which uses a specific UDP 621 port to indicate a UDP payload format. Both IPv4 and IPv6 can 622 support UDP. Such UDP-based tunnels can be used for BIER in a IPv6 623 network by defining a new UDP port to indicate the BIER header and 624 payload. 626 Authors' Addresses 628 Mike McBride 629 Futurewei 631 Email: michael.mcbride@futurewei.com 633 Jingrong Xie 634 Huawei 636 Email: xiejingrong@huawei.com 638 Senthil Dhanaraj 639 Huawei 641 Email: senthil.dhanaraj@huawei.com 643 Rajiv Asati 644 Cisco 646 Email: rajiva@cisco.com 648 Yongqing Zhu 649 China Telecom 651 Email: zhuyq8@chinatelecom.cn