idnits 2.17.00 (12 Aug 2021) /tmp/idnits22186/draft-mcbride-bier-ipv6-problem-statement-01.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 (March 8, 2019) is 1169 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 480, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-xie-bier-ipv6-encapsulation-00 == Outdated reference: A later version (-09) exists of draft-zhang-bier-bierin6-02 ** 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 BIER M. McBride 3 Internet-Draft J. Xie 4 Intended status: Standards Track S. Dhanaraj 5 Expires: September 9, 2019 Huawei 6 March 8, 2019 8 Problem Statement of BIER IPv6 Encapsulation 9 draft-mcbride-bier-ipv6-problem-statement-01 11 Abstract 13 The BIER WG has a charter item to work on mechanisms which use BIER 14 natively in IPv6. This document is intended to help the WG with this 15 effort by describing the problem space of transporting packets, with 16 Bit Index Explicit Replication (BIER) headers, in an IPv6 17 environment. There will be a need to send IPv6 payloads, to multiple 18 IPv6 destinations, using BIER. There have been several proposed 19 solutions in this area. But there hasn't been a document which 20 describes the problem and why this may be necessary. The goal of 21 this document is to describe the BIER IPv6 problem space, basic use 22 cases, why new solutions may be needed and briefly summarize some of 23 the proposed solutions. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 9, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 63 3. BIER IPv6 encapsulation Scenario's . . . . . . . . . . . . . 3 64 3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4 65 3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4 66 3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 4 67 3.4. Implications for BIER in SRv6 . . . . . . . . . . . . . . 5 68 4. Example Proposed Solutions . . . . . . . . . . . . . . . . . 5 69 4.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 5 70 4.2. Encode Bitstring in IPv6 destination address . . . . . . 6 71 4.3. Add BIER header into IPv6 Extension Header . . . . . . . 7 72 4.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 8 73 4.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 8 74 5. Suggested Requirements . . . . . . . . . . . . . . . . . . . 9 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 78 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 84 that provides optimal multicast forwarding, without requiring 85 intermediate routers to maintain per-flow state, through the use of a 86 multicast-specific BIER header. [RFC8296] defines two types of BIER 87 encapsulation to run on physical links: one is BIER MPLS 88 encapsulation to run on various physical links that support MPLS, the 89 other is BIER Ethernet encapsulation to run on ethernet links, with 90 an ethertype 0xAB37. This document describes using BIER in non-MPLS 91 IPv6 environments. We explain the problem space of transporting 92 IPv4/IPv6 multicast payloads, from an IPv6 router (BFIR) to multicast 93 IPv6 destinations (BFERs), using BIER. This can include native IPv6 94 encapsulation and generic tunneling. There have been several 95 proposed solutions in this area. But there hasn't been a document 96 which describes the problem and why this may be necessary. The goal 97 of this document is to describe the BIER v6 problem space, use cases, 98 encapsulations, existing solutions and why new solutions may be 99 needed. This draft is intended to help the BIER WG evaluate the need 100 for an encapsulation that is IPv6-specific through describing the 101 problem and summarizing BIERV6 related solutions. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 1.2. Terminology 111 o BIER: Bit Index Explicit Replication. Provides optimal multicast 112 forwarding through adding a BIER header and removing state in 113 intermediate routers. 115 o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe 116 the three types of Ethernet modes that will be forwarded to 117 multiple destinations 119 2. Problem Statement 121 The problem is the ability of the network to transport BUM packets, 122 with BIER headers, in an IPv6 environment. In an IPv6 network, many 123 deployments consider using a non-MPLS encapsulation for unicast as 124 the data-plane. In such case, it may be expected to have a BIER IPv6 125 encapsulation which is compliant with various kinds of physical 126 links, perhaps in a hop-by-hop manner, and maintain the benefit of 127 "fast reroute" of an IPv6 tunnel. 129 3. BIER IPv6 encapsulation Scenario's 131 +--------------------------------------------+ 132 | | 133 | +------+ 134 | | BFER | 135 +------+ IPv6 +------+ 136 | BFIR | | 137 +------+ Network +------+ 138 | | BFER | 139 | +------+ 140 | | 141 +--------------------------------------------+ 143 This basic scenario depicts the need to replicate bier packets from a 144 BFIR to BFERs across an IPv6 core. The IPv6 environment may include 145 a variety of link types, may be entirely IPv6, may be dual stack or 146 any type of combination which includes IPv6. Regardless of the 147 environment, there are times when a BIER header, including the BIER 148 bitstring used to determine the set of BIER forwarding egress 149 routers, will need to traverse a IPv6 domain. The ways in which BIER 150 will function in an IPv6 environment is the problem that needs to be 151 solved. [RFC8354] lists some good IPv6 related use cases which we 152 will similarly reference in this document. 154 3.1. BIERv6 for Access Network 156 Access networks deliver a variety of types of multicast video traffic 157 from the service provider's network to the home (or Enterprise) 158 environment and from the home towards the service provider's network. 160 There will be a need to send traffic from the IPv4 access towards the 161 service provider's IPv6 network and vice versa. A packet could be 162 mapped into a providers IPv6 network through the use of a BIERv6 163 header. The access devices would not need to know specific details 164 about the packet to perform this mapping; instead the access device 165 would only need to know how to process a BIER header unless there is 166 end to end IPv6. 168 3.2. BIERv6 for Data Center 170 Some Data Center operators are transitioning their Data Center 171 infrastructure from IPv4 to native IPv6 only, in order to cope with 172 IPv4 address depletion and to achieve larger scale. In such 173 environment, BIERv6, can be used to natively steer multicast data 174 across an IPv6 data center. 176 3.3. BIERv6 for Core Networks 178 While the overall amount of traffic offered to the network continues 179 to grow and considering that multiple types of traffic with different 180 characteristics and requirements are quickly converging over single 181 network architecture, the network operators are starting to face new 182 challenges. 184 Some operators are currently building, or plan to build in the near 185 future, an IPv6 only native infrastructure for their core network. 186 Having a native BIERv6 infrastructure will help maintain simplicity 187 of the network and reduce state versus traditional IP Multicast. 189 3.4. Implications for BIER in SRv6 191 The Source Packet Routing in Networking (SPRING) architecture 192 describes how Segment Routing can be used to steer packets through an 193 IPv6 or MPLS network using the source routing paradigm. [RFC8354] 194 focuses on use cases for Segment Routing in an IPv6 only environment, 195 something which is equially important for BIER in an IPv6 only 196 environment. 198 4. Example Proposed Solutions 200 Although this is not a solutions document it should be helpful to 201 list the various proposed solutions, without addressing the benefits 202 of one over another, to help understand the problem more clearly. 203 The following are solutions that have been proposed to solve BIER in 204 v6 environments. 206 As illustrated in these examples, the BIER header, or the BitString, 207 may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload, 208 or IPv6 Tunnel Packet: 210 4.1. BIER-ETH encapsulation in IPv6 networks 212 +---------------+-----------------+------------------- 213 | Ethernet | BIER header | payload 214 | (ethType = | (BIFT-id, ...) | 215 | 0xAB37) | | 216 | | Next Header | 217 +---------------+-----------------+------------------- 219 BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined 220 in [RFC8296]) can be used to transport the multicast data in the IPv6 221 network by encapsulating the multicast user data payload within the 222 BIER-ETH header. However, using BIER-ETH in IPv6 networks is not 223 considered to be a native IPv6 solution which utilizes the IPv6 224 header to forward the packet. Below listed are some of the 225 properties of BIER-ETH encapsulation which could be seen as the 226 reasons for the same, 228 o BIER-ETH is not agnostic to the underlying (L2) data link type. 229 It can be deployed only in the networks with Ethernet data link 230 and cannot be deployed in an network which deploys any other data 231 link types. Use of BIER-ETH in IPv6 networks might also result in 232 using different BIER encapsulations, when BIER is used as a E2E 233 multicast transport across a larger heterogeneous IPv6 networks 234 with different data link types used in different layers of the 235 network. 237 o BIER-ETH in IPv6 networks is considered similar to 6PE solution 238 where-in the multicast user data packet is encapsulated with-in 239 the BIER-MPLS header. 241 * It is worth noting that the only major difference between BIER- 242 MPLS and BIER-Non-MPLS header is that BIER-MPLS uses downstream 243 assigned MPLS label while BIER-Non-MPLS header uses a domain- 244 wide-unique BIFT-id. While the use of domain-wide-unique BIFT- 245 id in BIER-ETH header takes away the complexity of allocation 246 and state maintenance from the network, it still requires some 247 sort of ID (similar to label) to identify the application 248 context after the decapsulation of BIER header (example: MVPN 249 VRF Label). Encoding of such an ID/LABEL before encapsulating 250 the multicast user data payload with BIER-ETH header cannot be 251 avoided. 253 * The absence of an IPv6 header, and the optional IPv6 extension 254 headers, deprives BIER of some of the useful cases (ex: Use of 255 IPv6 address for identification of network function or service 256 mapping) that is otherwise possible in native IPv6 257 encapsulation which utilizes a IPv6 header. 259 * Tunneling of BIER packets is one common technique used for FRR, 260 to tunnel over BIER incapable nodes etc. While it is possible 261 for the BIER-ETH encapsulated packet to be further encapsulated 262 within a GRE6 or SRv6, etc tunnel, it might not be possible to 263 parse and decapsulate different types of tunnel headers and 264 forward the BIER packet completely in hardware fast path 265 similar to the label stack processing in BIER-MPLS networks. 266 It would be useful to select an encapsulation which could help 267 in processing the tunnel and BIER header and make the 268 forwarding decision completely in hardware fast path, which is 269 lacking in BIER-ETH encapsulation if chosen to be deployed in 270 pure IPv6 networks. 272 4.2. Encode Bitstring in IPv6 destination address 274 +---------------+------------------- 275 | IPv6 header | payload 276 | (BitString in | 277 | DA lower bits)| 278 | Next Header | 279 +---------------+------------------- 281 As described in [I-D.pfister-bier-over-ipv6], The information 282 required by BIER is stored in the destination IPv6 address. The BIER 283 BitString is encoded in the low-order bits of the IPv6 destination 284 address of each packet. The high-order bits of the IPv6 destination 285 address are used by intermediate routers for unicast forwarding, 286 deciding whether a packet is a BIER packet, and if so, to identify 287 the BIER Sub-Domain, Set Identifier and BitString length. No 288 additional extension or encapsulation header is required. Instead of 289 encapsulating the packet in IPv6, the payload is attached to the BIER 290 IPv6 header and the IPv6 protocol number is set to the type of the 291 payload. If the payload is UDP, the UDP checksum needs to change 292 when the BitString in the IPv6 destination address changes. 294 4.3. Add BIER header into IPv6 Extension Header 296 +---------------+-----------------+------------------- 297 | IPv6 header | IPv6 Ext header | payload 298 |(Multicast DA) | (BIER header in | 299 | | TLV Type = X) | 300 | Next Header | Next Header | 301 +---------------+-----------------+------------------- 303 According to [RFC8200] In IPv6, optional internet-layer information 304 is encoded in separate headers that may be placed between the IPv6 305 header and the upper- layer header in a packet. There is a small 306 number of such extension headers, each one identified by a distinct 307 Next Header value. An IPv6 packet may carry zero, one, or more 308 extension headers, each identified by the Next Header field of the 309 preceding header. Extension headers (except for the Hop-by-Hop 310 Options header) are not processed, inserted, or deleted by any node 311 along a packet's delivery path, until the packet reaches the node (or 312 each of the set of nodes, in the case of multicast) identified in the 313 Destination Address field of the IPv6 header. The Hop-by-Hop Options 314 header is not inserted or deleted, but may be examined or processed 315 by any node along a packet's delivery path, until the packet reaches 316 the node (or each of the set of nodes, in the case of multicast) 317 identified in the Destination Address field of the IPv6 header. The 318 Hop-by-Hop Options header, when present, must immediately follow the 319 IPv6 header. Its presence is indicated by the value zero in the Next 320 Header field of the IPv6 header. 322 Two of the currently-defined extension headers are the Hop-by-Hop 323 Options header and the Destination Options header which carry a 324 variable number of type-length-value (TLV) encoded "options". 326 In [I-D.xie-bier-ipv6-encapsulation] an IPv6 BIER Destination Option 327 is carried by the IPv6 Destination Option Header (indicated by a Next 328 Header value 60). It is initialized in a packet sent by an IPv6 BFIR 329 router to inform the following BFR routers in an IPv6 BIER domain to 330 replicate to destination BFER routers hop-by-hop. BIER is generally 331 a hop-by-hop and one-to-many architecture and it is required for a 332 BIER IPv6 encapsulation to include the BIER Header ([RFC8296]) as an 333 IPv6 Extension Header, to pilot the hop-by-hop BIER replication. 335 Hop by hop Options Headers may be considered. The Hop-by-Hop Options 336 header is used to carry optional information that may be examined and 337 processed by every node along a packet's delivery path. The Hop-by- 338 Hop Options header is identified by a Next Header value of 0 in the 339 IPv6 header. 341 Defining New Extension Headers and Options may also be considered, if 342 the IPv6 Destination Option Header is not good enough and new 343 extension headers can solve the problem better. 345 Such proposals may include requests to IANA to allocate a "BIER 346 Option" code from "Destination Options and Hop-by-Hop Options", and/ 347 or a "BIER Option Header" code from "IPv6 Extension Header Types". 349 4.4. Transport BIER as IPv6 payload 351 +---------------+-----------------+------------------- 352 | IPv6 header | IPv6 Ext header | BIER Hdr + payload 353 | | (optional) | as IPv6 payload 354 | | | 355 | Next Header | Next Header = X | 356 +---------------+-----------------+------------------- 358 There is a proposal for a transport-independent BIER encapsulation 359 header which is applicable regardless of the underlying transport 360 technology. As described in [I-D.xu-bier-encapsulation] and 361 [I-D.zhang-bier-bierin6], the BIER header, and the payload following 362 it, can be combined as an IPv6 payload, and be indicated by a new 363 Upper-layer IPv6 Next-Header value. A unicast IPv6 destination 364 address is used for the replication and changes when replicating a 365 packet out to a neighbor. 367 Such proposals may include a request to IANA to allocate an IPv6 368 Next-Header code from "Assigned Internet Protocol Numbers". 370 4.5. Tunneling BIER in a IPv6 tunnel 372 +---------------+-----------------+------------+---------------- 373 | IPv6 header | IPv6 Ext header | GRE header | 374 | | (optional) | | BIER Hdr + 375 | | | | payload as GRE 376 | Next Header | Next Header | Proto = X | Payload 377 +---------------+-----------------+------------+---------------- 379 A generic IPv6 Tunnel could be used to encapsulate the bier packet 380 within an IPv6 domain. 382 GRE is a mechanism by which any ethernet payload can be carried by an 383 IP GRE tunnel due to the 16-bits 'Protocol Type' field. Both IPv4 384 and IPv6 can be used to carry GRE. The Ethernet type codepoint 385 0xAB37, defined for BIER, can be used in a GRE header to indicate the 386 subsequent BIER header and payload in an IPv6 network. 388 +---------------+-----------------+------------+---------------- 389 | IPv6 header | IPv6 Ext header | UDP header | 390 | | (optional) | | BIER Hdr + 391 | | | | payload as UDP 392 | Next Header | Next Header | DPort = X | Payload 393 +---------------+-----------------+------------+---------------- 395 UDP-based tunneling is another mechanism which uses a specific UDP 396 port to indicate a UDP payload format. Both IPv4 and IPv6 can 397 support UDP. Such UDP-based tunnels can be used for BIER in a IPv6 398 network by defining a new UDP port to indicate the BIER header and 399 payload. 401 5. Suggested Requirements 403 This is not a requirements document and we may eventually remove this 404 section. We will, however, summarize some of the "requirements", 405 that have been suggested on the BIER email list, to help further 406 understand the problem. At a minimum, this may serve as a kick start 407 to a requirements draft if one is deemed necessary by the WG: 409 The solution should be agnostic to the underlying L2 data link type. 411 The solution should not require hop-by-hop modification of the IP 412 destination address field. 414 The solution should not require the BFRs to inspect layer 4 or 415 require any changes to layer 4. 417 The solution should not allow a multicast address to be put in the IP 418 source address field. 420 The solution should not assume that bits never get set incorrectly. 422 The solution should not require changes in source address filtering 423 procedures. 425 The solution should be possible to be used to support the entire BIER 426 architecture. 428 The solution should avoid having to use different encapsulation 429 types, or use complex tunneling techniques, to support BIER as a E2E 430 multicast transport. 432 The solution should enable the processing and forwarding of BIER 433 packets in hardware fast path. 435 6. IANA Considerations 437 Some BIERv6 encapsulation proposals do not require any action from 438 IANA while other proposals require new BIER Destination Option 439 codepoints from IPv6 sub-registries or require new IP Protocol codes. 440 This document, however, does not require anything from IANA. 442 7. Security Considerations 444 There are no security issues introduced by this draft. 446 8. Acknowledgement 448 Thank you to Eric Rosen for his listed set of requirements on the 449 bier wg list. 451 9. Normative References 453 [I-D.pfister-bier-over-ipv6] 454 Pfister, P. and I. Wijnands, "An IPv6 based BIER 455 Encapsulation and Encoding", draft-pfister-bier-over- 456 ipv6-01 (work in progress), October 2016. 458 [I-D.xie-bier-ipv6-encapsulation] 459 Xie, J., Geng, L., McBride, M., Dhanaraj, S., Yan, G., and 460 Y. Xia, "Encapsulation for BIER in Non-MPLS IPv6 461 Networks", draft-xie-bier-ipv6-encapsulation-00 (work in 462 progress), March 2019. 464 [I-D.xu-bier-encapsulation] 465 Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet, 466 C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit 467 Index Explicit Replication (BIER) Encapsulation Header", 468 draft-xu-bier-encapsulation-06 (work in progress), 469 September 2016. 471 [I-D.zhang-bier-bierin6] 472 Zhang, Z. and T. Przygienda, "BIER in IPv6", draft-zhang- 473 bier-bierin6-02 (work in progress), October 2018. 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, 477 DOI 10.17487/RFC2119, March 1997, 478 . 480 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 481 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 482 December 1998, . 484 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 485 (IPv6) Specification", STD 86, RFC 8200, 486 DOI 10.17487/RFC8200, July 2017, 487 . 489 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 490 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 491 Explicit Replication (BIER)", RFC 8279, 492 DOI 10.17487/RFC8279, November 2017, 493 . 495 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 496 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 497 for Bit Index Explicit Replication (BIER) in MPLS and Non- 498 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 499 2018, . 501 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 502 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 503 Routing in Networking (SPRING)", RFC 8354, 504 DOI 10.17487/RFC8354, March 2018, 505 . 507 Authors' Addresses 509 Mike McBride 510 Huawei 512 Email: michael.mcbride@huawei.com 514 Jingrong Xie 515 Huawei 517 Email: xiejingrong@huawei.com 518 Senthil Dhanaraj 519 Huawei 521 Email: senthil.dhanaraj@huawei.com