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