idnits 2.17.1 draft-xie-bier-ipv6-encapsulation-10.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 (February 22, 2021) is 1159 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) == Outdated reference: A later version (-13) exists of draft-ietf-bier-ping-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei Technologies 4 Updates: 8296 (if approved) L. Geng 5 Intended status: Standards Track China Mobile 6 Expires: August 26, 2021 M. McBride 7 Futurewei 8 R. Asati 9 Cisco 10 S. Dhanaraj 11 Huawei 12 Y. Zhu 13 China Telecom 14 Z. Qin 15 China Unicom 16 M. Shin 17 LG Uplus 18 G. Mishra 19 Verizon Inc. 20 X. Geng 21 Huawei 22 February 22, 2021 24 Encapsulation for BIER in Non-MPLS IPv6 Networks 25 draft-xie-bier-ipv6-encapsulation-10 27 Abstract 29 This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- 30 MPLS IPv6 Networks using the IPv6 Destination Option extension 31 header. This document updates RFC 8296. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in [RFC2119] and 38 [RFC8174]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on August 26, 2021. 57 Copyright Notice 59 Copyright (c) 2021 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 4 77 3.1. BIER Option in IPv6 Destination Options Header . . . . . 4 78 3.2. Destination Address in BIERv6 Encapsulation . . . . . . . 6 79 3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8 80 4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 12 83 5.2. ICMP Error Processing . . . . . . . . . . . . . . . . . . 13 84 5.3. Security caused by BIER option . . . . . . . . . . . . . 13 85 5.4. Applicability of IPsec . . . . . . . . . . . . . . . . . 14 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 15 88 6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15 89 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 91 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 94 10.2. Informative References . . . . . . . . . . . . . . . . . 18 95 Appendix A. Relationship to BIER Core Standards . . . . . . . . 19 96 Appendix B. Extensions to BIER Control-plane Standards . . . . . 20 97 Appendix C. Considerations of Using Unicast Address . . . . . . 20 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 100 1. Introduction 102 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 103 that provides optimal multicast forwarding without requiring 104 intermediate routers to maintain any per-flow state by using a 105 multicast-specific BIER header. 107 [RFC8296] defines a common BIER Header format for MPLS and Non-MPLS 108 networks. It has defined two types of encapsulation methods using 109 the common BIER Header, (1) BIER encapsulation in MPLS networks, 110 here-in after referred as MPLS BIER Header in this document and (2) 111 BIER encapsulation in Non-MPLS networks, here-in after referred as 112 Non-MPLS BIER Header in this document. [RFC8296] also assigned 113 Ethertype=0xAB37 for Non-MPLS BIER Header packets to be directly 114 carried over the Ethernet links. 116 This document proposes a BIER IPv6 encapsulation for Non-MPLS IPv6 117 Networks, defining a method to carry the standard Non-MPLS BIER 118 header (as defined in [RFC8296]) in the native IPv6 header. A new 119 IPv6 Option type - BIER Option is defined to encode the standard Non- 120 MPLS BIER header and this newly defined BIER Option is carried under 121 the Destination Options header of the native IPv6 Header [RFC8200]. 123 The relationship of this document to BIER core standards is listed in 124 Appendix A. 126 The relevant extensions to BIER Control-plane Standards are listed in 127 Appendix B. 129 2. Terminology 131 Readers of this document are assumed to be familiar with the 132 terminology and concepts of the documents listed as Normative 133 References. 135 The following new terms are used throughout this document: 137 o BIERv6 - Bit indexed explicit replication using IPv6 data plane. 139 o BIERv6 Domain - A limited-domain using BIERv6 encapsulation as 140 specified in this document for transporting customer multicast 141 packets from one router to multiple destination routers. It is 142 usually managed by a single administrative entity, e.g., a 143 service-provider. It could be a single AS network or a large- 144 scale network that includes multiple ASes. BIER Domain is also 145 used for the same meaning as BIERv6 domain in this document. 147 o BIERv6 Option - An Option type carried in IPv6 Destination Options 148 Header (DO header, DOH) which includes the standard Non-MPLS BIER 149 Header. It is in type-length-value (TLV) format. The value 150 portion of the BIERv6 Option TLV, or the BIERv6 Option Data, is in 151 the format of the standard Non-MPLS BIER header. BIER option is 152 also used for the same meaning as BIERv6 option in this document. 154 o BIERv6 Header - An IPv6 Header with BIER Option. 156 o BIERv6 Packet - An IPv6 packet with BIERv6 Header. An IP/IPv6/ 157 Ethernet multicast packet is encapsulated with an outside BIERv6 158 header and transformed to a BIERv6 packet on the ingress PE 159 (BFIR). BIERv6 packet is transported by the transit routers 160 (BFRs) through a BIERv6 domain towards egress PEs(BFERs). BIERv6 161 packet is decapsulated by the BFERs, with the original IP/IPv6/ 162 Ethernet multicast packet being obtained and forwarded towards the 163 multicast receivers . 165 3. BIER IPv6 Encapsulation 167 3.1. BIER Option in IPv6 Destination Options Header 169 Destination Options Header and the Options that can be carried under 170 this extension header is defined in [RFC8200]. This document defines 171 a new Option type - BIER Option, to encode the Non-MPLS BIER header. 172 As specified in Section 4.2 [RFC8200], the BIER Option follows type- 173 length-value (TLV) encoding format and the standard Non-MPLS BIER 174 header [RFC8296] is encoded in the value portion of the BIER Option 175 TLV. 177 This BIER Option MUST be carried only inside the IPv6 Destination 178 Options header and MUST NOT be carried under the Hop-by-Hop Options 179 header. 181 The BIER Option is encoded in type-length-value (TLV) format as 182 follows: 184 0 1 2 3 185 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Next Header | Hdr Ext Len | Option Type | Option Length | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 ~ BIERv6 Option Data (Non-MPLS BIER Header defined in RFC8296) ~ 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Next Header 8-bit selector. Identifies the type of header 195 immediately following the Destination Options header. 197 Hdr Ext Len 8-bit unsigned integer. Length of the Destination 198 Options header in 8-octet units, not including the first 8 octets. 200 Option Type To be allocated by IANA. See section 6. 202 Option Length 8-bit unsigned integer. Length of the option, in 203 octets, excluding the Option Type and Option Length fields. 205 BIERv6 Option Data The BIERv6 Option Data contains the Non-MPLS BIER 206 Header defined in RFC8296. Fields in the Non-MPLS BIER Header 207 MUST be encoded as below. 209 BIFT-id: The BIFT-id is a domain-wide unique value in Non-MPLS 210 IPv6 encapsulation. See Section 2.2 of RFC 8296. 212 TC: SHOULD be set to binary value 000 upon transmission and MUST 213 be ignored upon. See Section 2.2 of RFC 8296. 215 S bit: SHOULD be set to 1 upon transmission, and MUST be ignored 216 upon reception. See Section 2.2 of RFC 8296. 218 TTL: MUST be set to a value larger than 0 upon encapsulation, 219 and SHOULD decrease by 1 by a BFR when forwarding a BIERv6 220 packet to a BFR adjacency. If the incoming TTL is 0, the packet 221 is considered to be "expired". See Section 2.1.1.2 of RFC 8296. 223 Nibble: SHOULD be set to 0000 upon transmission, and MUST be 224 ignored upon reception. See Section 2.2 of RFC 8296. 226 Ver: MUST be set to 0 upon transmission, and MUST be discarded 227 when it is not 0 upon reception. See Section 2.2 of RFC 8296. 229 BSL: See Section 2.1.2 of RFC 8296. 231 Entropy: See Section 2.1.2 of RFC 8296. 233 OAM: See Section 2.1.2 of RFC 8296. 235 Rsv: See Section 2.1.2 of RFC 8296. 237 DSCP: SHOULD be set to binary value 000000 upon transmission and 238 MUST be ignored upon reception. In BIERv6 encapsulation, uses 239 Traffic Class field of IPv6 header instead. 241 Proto: SHOULD be set to 0 upon transmission and be ignored upon 242 reception. In BIERv6 encapsulation, the functionality of this 243 6-bit Proto field is replaced by the Next Header field in 244 Destination Options header or the last IPv6 extension header to 245 indicate the type of the payload. This updates section 2.1.2 of 246 [RFC8296] about Proto definition. Next Header value in BIERv6 247 encapsulation for common usage includes: 249 Value 4 for IPv4 packet as BIERv6 payload. 251 Value 41 for IPv6 packet as BIERv6 payload. 253 Value 143 for Ethernet packet as BIERv6 payload. 255 Multicast VPN (MVPN) service is considered as part of the BIER 256 layering mode defined in [RFC8279], and should be supported by 257 BIERv6 encapsulation. [I-D.xie-bier-ipv6-mvpn] illustrates how 258 MVPN is supported in BIERv6 encapsulation without using this 259 Proto field. 261 BIER-PING [I-D.ietf-bier-ping] is considered a useful function 262 of the BIER architecture, and should be supported by BIERv6 263 encapsulation. How BIER-PING is supported in BIERv6 264 encapsulation without using this Proto field is outside the 265 scope of this document. 267 BFIR-id: See Section 2.1.2 of RFC 8296. 269 BitString: See Section 2.1.2 of RFC 8296. 271 3.2. Destination Address in BIERv6 Encapsulation 273 When a BIERv6 packet is replicated to a next hop BFR, an unicast 274 address of the next hop BFR is used as the destination address of the 275 BIERv6 packet. Considerations of using unicast (or multicast) 276 address is listed in Appendix C. 278 The unicast address used in BIERv6 packet targeting a BFR SHOULD be 279 advertised as part of the BIER IPv6 Encapsulation. When a BFR 280 advertises the BIER information with BIERv6 encapsulation capability, 281 an IPv6 unicast address of this BFR MUST be selected specifically for 282 BIERv6 packet forwarding. Locally this "BIER Specific" IPv6 address 283 is initialized in FIB with a flag of "BIER specific handling", 284 represented as End.BIER function. 286 If a BFR belongs to more than one sub-domain, it may (though it need 287 not) have a different End.BIER in each sub-domain. If different 288 End.BIER is used for each sub-domain, implementation SHOULD support 289 verifying the DA of a BIERv6 packet is the End.BIER address bound by 290 the sub-domain of the packet. 292 For security deployment of BIERv6, the End.BIER address(es) is 293 required to be allocated from an IPv6 address block, and the IPv6 294 address block is used for domain boundary security policy. See 295 section 5.1 of this document for such security policy. Such kind of 296 security policy using IPv6 address block follows the paradigm settled 297 by the [RFC8754] section 5. 299 Deployment of BIERv6 in SRv6 network is allowed. In this case, the 300 BIERv6 domain is the same as SRv6 domain, and the End.BIER address is 301 allocated from the locator of SRv6. 303 To better understand the configuration mode of End.BIER address in 304 BIERv6, [I-D.geng-bier-bierv6-yang] could be referenced. 306 For the convenience of such co-existence of BIERv6 and SRv6, the 307 indication of End.BIER or "BIER specific handling" in FIB shares the 308 same space as SRv6 Endpoints Behaviors defined in 309 [I-D.ietf-spring-srv6-network-programming]. 311 The following is an example pseudo-code of the End.BIER function: 313 1. IF NH = 60 and HopLimit > 0 ;;Ref1 314 2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2 315 3. Lookup the BIER Header inside the BIER option TLV. 316 4. Forward via the matched entry. 317 5. ELSE ;;Ref3 318 6. Drop the packet and end the process. 319 7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4 320 8. Send to CPU. 321 9. ELSE ;;Ref5 322 10. Drop the packet. 324 Ref1: Destination options header follows the IPv6 header directly and 325 HopLimit is bigger than zero. 327 Ref2: The first TLV is BIER type and is the only TLV present in 328 Destination options header. 330 Ref3/Ref5: Undesired packet is droped because the destination address 331 is the BIER specific IPv6 address (End.BIER function). 333 Ref4: An ICMPv6 packet using End.BIER as destination address. 335 3.3. BIERv6 Packet Format 337 As a multicast packet enters the BIER domain in a Non-MPLS IPv6 338 network, the multicast packet will be encapsulated with BIERv6 Header 339 by the Ingress BFR (BFIR). 341 Typically a BIERv6 header would contain the Destination Options 342 Header as the only Extensions Header besides IPv6 Header, as depicted 343 in the below figure. 345 +---------------+------------------+----------------------+ 346 | IPv6 header | IPv6 DO Header | X type of | 347 | | with BIER Option | C-multicast packet | 348 | | | | 349 | Next Hdr = 60 | Nxt Hdr = X | (IPv4/IPv6/Ethernet) | 350 +---------------+------------------+----------------------+ 351 | | | 352 |<----------BIERv6 header--------->|<---BIERv6 payload--->| 354 Format of the multicast packet with BIERv6 encapsulation carrying 355 other extension headers along with Destination Options extension 356 header is required to follow general recommendations of [RFC8200] and 357 examples in other RFCs. [RFC6275] introduces how the order should be 358 when other extension headers carries along with Home address option 359 in a destination options header. Similar to this example, this 360 document requires the Destination Options Header carrying the BIER 361 option MUST be placed as follows: 363 o After the routing header, if that header is present 365 o Before the Fragment Header, if that header is present 367 o Before the AH Header or ESP Header, if either one of those headers 368 is present 370 Source Address field in the IPv6 header MUST be a routable IPv6 371 unicast address of the BFIR in any case. 373 BFIR encodes the BIERv6 header in the above mentioned encapsulation 374 format and forwards the BIERv6 packet to the nexthop BFR following 375 the local BIFT table. 377 BFRs in the IPv6 network, processes and replicates the packets 378 towards the BFERs using the local BIFT table. The BitString field in 379 the BIERv6 Option Data may be changed by the BFRs as they replicate 380 the packet. BFRs MUST follow the procedures defined in section 3.1 381 as they modify the other fields in the BIERv6 Option Data. The 382 source address in the IPv6 header MUST NOT be modified by the BFRs. 384 4. BIERv6 Packet Processing 386 When a multicast packet enters the BIER domain, the Ingress BFR 387 (BFIR) encapsulates the multicast packet with a BIERv6 Header, 388 transforming it to a BIERv6 packet. The BIERv6 header includes an 389 IPv6 header and a BIERv6 Option in IPv6 Destination Options Header. 390 Source Address field in the IPv6 header MUST be set to a routable 391 IPv6 unicast address of the BFIR. Destination Address field in the 392 IPv6 header is set to the End.BIER address of the next-hop BFR the 393 BIERv6 packet replicating to, no matter next-hop BFR is directly 394 connected (one-hop) or not directly connected (multi-hop). 396 Upon receiving an BIERv6 packet, the BFR processes the IPv6 header 397 first. This is the general procedure of IPv6. 399 If the IPv6 Destination address is an End.BIER IPv6 unicast address 400 of this BFR, a 'BIER Specific Handling' indication will be obtained 401 by the preceding Unicast DA lookup (FIB lookup). The BIER option, if 402 exists, will be checked to decide which neighbor(s) to replicate the 403 BIERv6 packet to. 405 It is a local behavior to handle the combination of extension 406 headers, options and the BIER option(s) in destination options header 407 when a 'BIER Specific Handling' indication is got by the preceding 408 FIB lookup. Early deployment of BIERv6 may require there is only one 409 BIER option TLV in the destination options header followed the IPv6 410 header. How other extension headers or more BIER option TLVs in a 411 BIERv6 packet is handled is outside the scope of this document. 413 A packet having a 'BIER Specific Handling' indication but not having 414 a BIER option is supposed to be a wrong packet or an ICMPv6 packet, 415 and the process can be referred to the example in section 3.2. 417 A packet not having a 'BIER Specific Handling' indication but having 418 a BIER option SHOULD be processed normally as unicast forwarding 419 procedures, which may be a behavior of drop, or send to CPU, or other 420 behaviors in existing implementations. 422 The Destination Address field in the IPv6 Header MUST change to the 423 nexthop BFR's End.BIER Unicast address in BIERv6. 425 The Hop Limit field of IPv6 header MUST decrease by 1 when sending 426 packets to a BFR neighbor, while the TTL in the BIER header MUST be 427 unchanged on a Non-BIER router, or decrease by 1 on a BFR. 429 The BitString in the BIER header in the Destination Options Header 430 may change when sending packets to a neighbor. Such change of 431 BitString MUST be aligned with the procedure defined in RFC8279. 433 Because of the requirement to change the content of the option when 434 forwarding BIERv6 packet, the BIER option type should have chg flag 1 435 per section 4.2 of RFC8200. 437 The procedures applies normally if a bit corresponding to the self 438 bfr-id is set in the BitString field of the BIERv6 Option Data of the 439 BIERv6 packet. The node is considered to be an Egress BFR (BFER) in 440 this case. The BFER removes the BIERv6 header, including the IPv6 441 header and the Destination Options header, and copies the packet to 442 the multicast flow overlay. The egress VRF of a packet may be 443 determined by a further lookup on the IPv6 source address instead of 444 the upstream-assigned MPLS Label as described in [RFC8556]. 446 The Fragment Header, AH Header or ESP Header, if exists after the 447 BIER options header, can be processed on BFER only as part of the 448 multicast flow overlay process. 450 The following diagram shows the whole progression of the multicast 451 packet as it enters the BIERv6 domain on PE1, and leaves the BIERv6 452 domain on PE2 and PE3. 454 +-------------+ +-------------+ 455 |{S=PE1,D=P2} | |{S=PE1,D=PE2}| 456 +-------------+ +-------------+ 457 |[BitStr=0110]| |[BitStr=0010]| 458 +==========+ +=============+ +=============+ +==========+ 459 |(C-MC Pkt)| >> | (C-MC Pkt) | >> | (C-MC Pkt) | >> |(C-MC Pkt)| 460 +==========+ +=============+ +=============+ +==========+ 461 CE1-----------PE1------[P1]------P2----------------PE2------------CE2 462 (BFIR) /(BFR) (BFER, BFR-id=2) 463 / 464 / +-------------+ 465 | |{S=PE1,D=PE3}| 466 | +-------------+ 467 | |[BitStr=0100]| 468 \ +=============+ +==========+ 469 \ >> | (C-MC Pkt) | >> |(C-MC Pkt)| 470 \ +=============+ +==========+ 471 +------[P3]-------PE3------------CE3 472 (BFER, BFR-id=3) 474 {S=PE1,D=PE2}: Source address and Destination address in IPv6 header. 475 [BitStr=0110]: BitString value in IPv6 DO Header. 476 (C-MC Pkt): Customer MultiCast packet. 478 o PE1 is Provider Edge router, acting as BFIR. 480 o P2 is Provider Core router, acting as BFR. 482 o P1 and P3 are IPv6 routers, acting as Non-BFR. 484 o PE2 and PE3 are Provider Edge routers, acting as BFER. 486 o CE1 and CE2 are Customer Edge routers. 488 5. Security Considerations 490 BIER IPv6 encapsulation provides a new encapsulation based on IPv6 491 and BIER to transport multicast data packet in a BIER domain. The 492 BIER domain can be a single IGP area, an anonymous system (AS) with 493 multiple IGP areas, or multiple anonymous systems (ASes) operated by 494 a network operator. A single BIER Sub-domain may be deployed through 495 the whole BIER Domain, as illustrated in 496 [I-D.geng-bier-ipv6-inter-domain]. 498 This section reviews security considerations related to the BIER IPv6 499 encapsulation, based on security considerations of [RFC8279], 500 [RFC8296], and other documents related to IPv6 extension. 502 It is expected that all nodes in a BIER IPv6 domain are managed by 503 the same administrative entity. BIER-encapsulated packets should 504 generally not be accepted from untrusted interfaces or tunnels. For 505 example, an operator may wish to have a policy of accepting BIER- 506 encapsulated packets only from interfaces to trusted routers, and not 507 from customer-facing interfaces. See section 5.1 for normal Intra 508 domain deployment. 510 For applications that require a BFR to accept a BIER-encapsulated 511 packet from an interface to a system that is not controlled by the 512 network operator, the security considerations of [RFC8296] apply. 514 BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause 515 security problems. See section 5.2 for ICMP related problems. 517 This document introduces a new option used in IPv6 Destination 518 Options Header, together with the special-use IPv6 address called 519 End.BIER in IPv6 destination address for BIER IPv6 forwarding. 520 However the option newly introduced may be wrongly used with normal 521 IPv6 destination address. See section 5.3 for problems introduced by 522 the new IPv6 option with normal IPv6 destination address. 524 If the multicast data packet of a BIERv6 packet is altered by an 525 intermediate router, contents of the multicast data packet will be 526 damaged. BIER IPv6 encapsulation provides the ability of IPsec to 527 ensure the confidentiality or integrity for multicast data packet. 528 See section 5.4 for this security problem. 530 If the BIERv6 encapsulation of a particular packet specifies a 531 BitString (together with SI) other than the one intended by the BFIR, 532 the packet is likely to be misdelivered. Some modifications of the 533 BIER encapsulation, e.g., setting every bit in the BitString, may 534 result in denial-of-service (DoS) attacks. This kind of DoS attack 535 is a challenge not only in BIERv6 but also in BIER as specified in 536 [RFC8279] and [RFC8296], as the BitString is required to change on 537 BFR per the BIER forwarding procedures. This document does not 538 provide new mechanisms to improve this kind of weakness. 540 A BIER router accepts and uses the End.BIER IPv6 address to construct 541 BIFT only when the IPv6 address is configured explicitly, or received 542 from a router via control-plane protocols. The received information 543 is validated using existing authentication and security mechanisms of 544 the control-plane protocols. BIER IPv6 encapsulation does not define 545 any additional security mechanism in existing control-plane 546 protocols, and it inherits any security considerations that apply to 547 the control-plane protocols. 549 5.1. Intra Domain Deployment 551 Generally nodes outside the BIER Domain are not trusted: they cannot 552 directly use the End.BIER of the domain. This is enforced by two 553 levels of access control lists: 555 1. Any packet entering the BIER Domain and destined to an End.BIER 556 IPv6 Address within the BIER Domain is dropped. This may be realized 557 with the following logic. Other methods with equivalent outcome are 558 considered compliant: 560 * allocate all the End.BIER IPv6 Address from a block S/s 562 * configure each external interface of each edge node of the domain 563 with an inbound infrastructure access list (IACL) which drops any 564 incoming packet with a destination address in S/s 566 * Failure to implement this method of ingress filtering exposes the 567 BIER Domain to BIER attacks as described and referenced in [RFC8296]. 569 2. The distributed protection in #1 is complemented with per node 570 protection, dropping packets to End.BIER IPv6 Address from source 571 addresses outside the BIER Domain. This may be realized with the 572 following logic. Other methods with equivalent outcome are 573 considered compliant: 575 * assign all interface addresses from prefix A/a 577 * assign all the IPv6 addresses used as source address of BIER IPv6 578 packets from a block B/b 580 * at node k, all End.BIER IPv6 addresses local to k are assigned from 581 prefix Sk/sk 583 * configure each internal interface of each BIER node k in the BIER 584 Domain with an inbound IACL which drops any incoming packet with a 585 destination address in Sk/sk if the source address is not in A/a or 586 B/b. 588 For simplicity of deployment, a configuration of IACL effective for 589 all interfaces can be provided by a router. Such IACL can be 590 referred to as global IACL(GIACL) .Each BIER node k then simply 591 configs a GIACL which drops any incoming packet with a destination 592 address in Sk/sk if the source address is not in A/a or B/b for the 593 intra-domain deployment mode. 595 5.2. ICMP Error Processing 597 The BIERv6 BFR does not send ICMP error messages to the source 598 address of a BIERv6 packet, there is still chance that Non-BFR 599 routers send ICMP error messages to source nodes within the BIER 600 Domain. 602 A large number of ICMP may be elicited and sent to a BFIR router, in 603 case when a BIERv6 packet is filled with wrong Hop Limit, either 604 error or malfeasance. A rate-limiting of ICMP packet should be 605 implemented on each BFR. 607 The ingress node can take note of the fact that it is getting, in 608 response to BIER IPv6 packet, one or more ICMP error packets. By 609 default, the reception of such a packets MUST be countered and 610 logged. However, it is possible for such log entries to be "false 611 positives" that generate a lot of "noise" in the log; therefore, 612 implementations SHOULD have a knob to disable this logging. 614 5.3. Security caused by BIER option 616 This document introduces a new option used in IPv6 Destination 617 Options Header. An IPv6 packet with a normal IPv6 address of a 618 router (e.g. loopback IPv6 address of the router) as destination 619 address will possibly carry a BIER option. 621 For a router incapable of BIERv6, such BIERv6 packet will not be 622 processed by the procedure described in this document, but be 623 processed as normal IPv6 packet with unknown option, and the existing 624 security considerations for handling IPv6 options apply. Possible 625 way of handling IPv6 packets with BIER option may be send to CPU for 626 slow path processing, with rate-limiting, or be discarded according 627 to the local policy. 629 For a router capable of BIERv6, such BIERv6 packet MUST NOT be 630 forwarded, but should be processed as a normal IPv6 packet with 631 unknown option, or additionally and optionally be countered and 632 logged if the router is capable of doing so. 634 5.4. Applicability of IPsec 636 IPsec [RFC4301] uses two protocols to provide traffic security 637 services -- Authentication Header (AH) [RFC4302] and Encapsulating 638 Security Payload (ESP) [RFC4303]. Each protocol supports two modes 639 of use: transport mode and tunnel mode. IPsec support both unicast 640 and multicast. IPsec implementations MUST support ESP and MAY 641 support AH. 643 This document assume IPsec working in tunnel mode with inner IPv4 or 644 IPv6 multicast packet encapsulated in outer BIERv6 header and IPsec 645 header(s). 647 IPsec used with BIER IPv6 encapsulation to ensure that a BIER payload 648 is not altered while in transit between BFIR and BFERs. If a BFR in 649 between BFIR and BFERs is compromised, there is no way to prevent the 650 compromised BFR from making illegitimate modifications to the BIER 651 payload or to prevent it from misforwarding or misdelivering the 652 BIER-encapsulated packet, but the BFERs will detect the illegitimate 653 modifications to the BIER Payload (or the inner multicast data 654 packet). This could provide cryptographic integrity protection for 655 multicast data transport. This capability of IPsec comes from the 656 design that, the destination options header carrying the BIER header 657 is located before the AH or ESP and the BFR routers in between BFIR 658 and BFERs can process the BIER header without aware of AH or ESP. 660 For ESP, the Integrity Check Value (ICV) is computed over the ESP 661 header, Payload, and ESP trailer fields. It doesn't require the IP 662 or extension header for ICV calculating, and thus the change of DA 663 and BIER option data does not affect the function of ESP. 665 For AH, the Integrity Check Value (ICV) is computed over the IP or 666 extension header fields before the AH header, the AH header, and the 667 Payload. The IPv6 DA is immutable for unicast traffic in AH, and the 668 change of DA in BIER IPv6 forwarding for multicast traffic is 669 incompatible to this rule. How AH is extended to support multicast 670 traffic transporting through BIER IPv6 encapsulation is outside the 671 scope of this document. 673 The detailed control-plane for BIER IPv6 encapsulation IPsec function 674 is outside the scope of the document. Internet Key Exchange Protocol 675 Version 2 (IKEv2) [RFC7296] and Group Security Association (GSA) 676 [RFC5374] can be referred to for further studying. 678 6. IANA Considerations 680 6.1. BIER Option Type 682 Allocation is expected from IANA for a BIER Option Type codepoint 683 from the "Destination Options and Hop-by-Hop Options" sub-registry of 684 the "Internet Protocol Version 6 (IPv6) Parameters" registry. 686 +-----------+-----+-----+-------+-------------+------------+ 687 | Hex Value | act | chg | rest | Description | Reference | 688 +-----------+-----+-----+-------+-------------+------------+ 689 | TBD | 01 | 1 | TBD | BIER Option | This draft | 690 +-----------+-----+-----+-------+-------------+------------+ 692 6.2. End.BIER Function 694 Allocation is expected from IANA for an End.BIER function codepoint 695 from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is 696 suggested. 698 +-------+--------+--------------------------+------------+ 699 | Value | Hex | Endpoint function | Reference | 700 +-------+--------+--------------------------+------------+ 701 | TBD | TBD | End.BIER | This draft | 702 +-------+--------+--------------------------+------------+ 704 7. Implementation Status 706 Implementation of BIERv6 as described in this document and related 707 drafts defined in appendix B has been operational. 709 In February 2021, China Unicom successfully validated this BIERv6 710 solution over its Beijing Metro network. 712 The BIERv6 test network contains the following network devices: 714 STB, ONT, OLT, BFER,non-BFR, BFR, BFIR, Switch, CR (Core Router, 715 video flow input node) 717 where BIERv6 capable nodes include: 719 o BFER: Huawei ATN980C 721 o BFR&BFIR: Huawei NE40E 723 and IPv6 capable nodes include: 725 o non-BFR: Cisco ASR 9006 727 BIERv6 test is composed of the following scenarios: 729 o Intra-AS BIERv6: mechanisms defined in this document and 730 [I-D.xie-bier-ipv6-isis-extension] are validated. 732 o Inter-AS BIERv6: mechanisms defined in 733 [I-D.geng-bier-ipv6-inter-domain] are validated. 735 o IPv4 multicast traffic over BIERv6 MVPN. Mechanisms defined in 736 [I-D.xie-bier-ipv6-mvpn] are validated. 738 o Deployment of Intra-AS and Inter-AS BIERv6 with non-BIERv6 capable 739 intermediate nodes, where these nodes only need to be IPv6 740 capable. 742 o BIERv6 Ping 744 o Deterministic convergence as indicated in [RFC8279], where 745 intermediate link or BFR node fails. 747 o Service reliability where BIERv6 source side link or BFIR node 748 fails. 750 o Service reliability where BIERv6 receiver side link or BFER node 751 fails. 753 8. Acknowledgements 755 The authors would like to thank Stig Venaas for his valuable 756 comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda, 757 Toerless Eckert, Jeffrey Zhang, Pascal Thubert for the helpful 758 comments to improve this document. 760 Thanks Aijun Wang for comments about BIER OAM function in BIER IPv6 761 encapsulation. 763 Thanks Mach Chen for review and suggestions about BIER-PING function 764 in BIER IPv6 encapsulation. 766 9. Contributors 768 Gang Yan 770 Huawei Technologies 772 China 774 Email: yangang@huawei.com 776 Yang(Yolanda) Xia 778 Huawei Technologies 780 China 782 Email: yolanda.xia@huawei.com 784 10. References 786 10.1. Normative References 788 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 789 Requirement Levels", BCP 14, RFC 2119, 790 DOI 10.17487/RFC2119, March 1997, 791 . 793 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 794 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 795 December 2005, . 797 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 798 DOI 10.17487/RFC4302, December 2005, 799 . 801 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 802 RFC 4303, DOI 10.17487/RFC4303, December 2005, 803 . 805 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 806 Extensions to the Security Architecture for the Internet 807 Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, 808 . 810 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 811 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 812 2011, . 814 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 815 Kivinen, "Internet Key Exchange Protocol Version 2 816 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 817 2014, . 819 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 820 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 821 May 2017, . 823 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 824 (IPv6) Specification", STD 86, RFC 8200, 825 DOI 10.17487/RFC8200, July 2017, 826 . 828 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 829 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 830 Explicit Replication (BIER)", RFC 8279, 831 DOI 10.17487/RFC8279, November 2017, 832 . 834 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 835 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 836 for Bit Index Explicit Replication (BIER) in MPLS and Non- 837 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 838 2018, . 840 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 841 Zhang, "Bit Index Explicit Replication (BIER) Support via 842 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 843 . 845 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 846 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 847 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 848 2019, . 850 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 851 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 852 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 853 . 855 10.2. Informative References 857 [I-D.geng-bier-bierv6-yang] 858 Geng, X., Qin, Z., and F. Zheng, "YANG Data Model for 859 Bierv6", draft-geng-bier-bierv6-yang-00 (work in 860 progress), June 2020. 862 [I-D.geng-bier-ipv6-inter-domain] 863 Geng, L., Xie, J., McBride, M., Yan, G., and X. Geng, 864 "Inter-Domain Multicast Deployment using BIERv6", draft- 865 geng-bier-ipv6-inter-domain-02 (work in progress), October 866 2020. 868 [I-D.ietf-bier-ipv6-requirements] 869 McBride, M., Xie, J., Geng, X., Dhanaraj, S., Asati, R., 870 Zhu, Y., Mishra, G., and Z. Zhang, "BIER IPv6 871 Requirements", draft-ietf-bier-ipv6-requirements-09 (work 872 in progress), September 2020. 874 [I-D.ietf-bier-ping] 875 Nainar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 876 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 877 ping-07 (work in progress), May 2020. 879 [I-D.ietf-spring-srv6-network-programming] 880 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 881 Matsushima, S., and Z. Li, "SRv6 Network Programming", 882 draft-ietf-spring-srv6-network-programming-28 (work in 883 progress), December 2020. 885 [I-D.xie-bier-ipv6-isis-extension] 886 Xie, J., Wang, A., Yan, G., Dhanaraj, S., and X. Geng, 887 "BIER IPv6 Encapsulation (BIERv6) Support via IS-IS", 888 draft-xie-bier-ipv6-isis-extension-02 (work in progress), 889 October 2020. 891 [I-D.xie-bier-ipv6-mvpn] 892 Xie, J., McBride, M., Dhanaraj, S., Geng, L., and G. 893 Mishra, "Use of BIER IPv6 Encapsulation (BIERv6) for 894 Multicast VPN in IPv6 networks", draft-xie-bier- 895 ipv6-mvpn-03 (work in progress), October 2020. 897 Appendix A. Relationship to BIER Core Standards 899 The BIER architecture [RFC8279] is inherited in this BIERv6 proposal, 900 and the layering mode of BIER architecture is fully supported with 901 some necessary extension to the data plane as well as the control 902 plane standards. 904 The focus of this document is BIERv6 data plane, including the BIERv6 905 encapsulation and packet forwarding procedures. The common BIER 906 header encoding [RFC8296] is maximum reused in this BIERv6 proposal. 908 To better understand the overall BIER IPv6 problem space and 909 requirements, refer to [I-D.ietf-bier-ipv6-requirements]. 911 Appendix B. Extensions to BIER Control-plane Standards 913 The relevant control-plane documents that have done or still to be 914 done are listed below. 916 o Based on [RFC8401], IS-IS extension is defined in 917 [I-D.xie-bier-ipv6-isis-extension] for intra-AS BIERv6 information 918 advertisement and BIRT/BIFT building. 920 o OSPFv3 extension for intra-AS BIERv6 information advertisement and 921 BIRT/BIFT building is to be defined. 923 o Based on this BIERv6 encapsulation, 924 [I-D.geng-bier-ipv6-inter-domain] illustrates how inter-AS BIRT/ 925 BIFT are built and how inter-AS multicast deployment is supported. 927 o BGP extension for inter-AS BIERv6 information advertisement and 928 BIRT/BIFT building is to be defined. 930 o Based on [RFC8556], BGP-MVPN using BIERv6 encapsulation is defined 931 in [I-D.xie-bier-ipv6-mvpn] for multicast service deployment. 933 Appendix C. Considerations of Using Unicast Address 935 BIER is generally a hop-by-hop and one-to-many architecture, and thus 936 the IPv6 Destination Address (DA) being a Multicast Address is a way 937 one may think of as an approach for both the two paradigms in BIERv6 938 encapsulation. 940 However using a unicast address has the following benefits: 942 1. Replicating a BIERv6 packet over a non-BIER capable router. 944 2. Fast rerouting a BIERv6 packet using a unicast by-pass tunnel. 946 3. Forwarding a BIERv6 packet to one of the many BFR neighbors 947 connected on a LAN without imposing new requirements of snooping 948 on switches. 950 4. Replicating a BIERv6 packet through an anonymous system(AS) to 951 BFERs in other ASes, as illustrated in 952 [I-D.geng-bier-ipv6-inter-domain]. 954 Some of the above scenarios are assumed part of BIER architecture as 955 described in [RFC8279], and some of them are the scalability aspects 956 for inter-AS stateless multicast this document intends to support. 957 This document intends to fulfil all these requirements (categorized 958 as multi-hop replication), and proposes to use unicast address for 959 both one-hop replication and multi-hop replication. 961 Authors' Addresses 963 Jingrong Xie 964 Huawei Technologies 966 Email: xiejingrong@huawei.com 968 Liang Geng 969 China Mobile 970 Beijing 10053 972 Email: gengliang@chinamobile.com 974 Mike McBride 975 Futurewei 977 Email: mmcbride7@gmail.com 979 Rajiv Asati 980 Cisco 982 Email: rajiva@cisco.com 984 Senthil Dhanaraj 985 Huawei 987 Email: senthil.dhanaraj@huawei.com 989 Yongqing Zhu 990 China Telecom 992 Email: zhuyq8@chinatelecom.cn 994 Zhuangzhuang Qin 995 China Unicom 997 Email: qinzhuangzhuang@chinaunicom.cn 998 MooChang Shin 999 LG Uplus 1001 Email: himzzang@lguplus.co.kr 1003 Gyan Mishra 1004 Verizon Inc. 1006 Email: gyan.s.mishra@verizon.com 1008 Xuesong Geng 1009 Huawei 1011 Email: gengxuesong@huawei.com