idnits 2.17.1 draft-xie-bier-ipv6-encapsulation-07.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 (June 29, 2020) is 1368 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 (-02) exists of draft-geng-bier-ipv6-inter-domain-01 == Outdated reference: A later version (-09) exists of draft-ietf-bier-ipv6-requirements-04 == Outdated reference: A later version (-13) exists of draft-ietf-bier-ping-07 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-15 == Outdated reference: A later version (-03) exists of draft-xie-bier-ipv6-mvpn-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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: December 31, 2020 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 X. Geng 19 Huawei 20 June 29, 2020 22 Encapsulation for BIER in Non-MPLS IPv6 Networks 23 draft-xie-bier-ipv6-encapsulation-07 25 Abstract 27 This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- 28 MPLS IPv6 Networks using the IPv6 Destination Option extension 29 header. This document updates RFC 8296. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [RFC2119] and 36 [RFC8174]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on December 31, 2020. 55 Copyright Notice 57 Copyright (c) 2020 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 74 3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 4 75 3.1. BIER Option in IPv6 Destination Options Header . . . . . 4 76 3.2. Multicast and Unicast Destination Address . . . . . . . . 6 77 3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8 78 4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 12 81 5.2. ICMP Error Processing . . . . . . . . . . . . . . . . . . 13 82 5.3. Security caused by BIER option . . . . . . . . . . . . . 13 83 5.4. Applicability of IPsec . . . . . . . . . . . . . . . . . 14 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 15 86 6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 88 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 89 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 91 9.2. Informative References . . . . . . . . . . . . . . . . . 17 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 97 that provides optimal multicast forwarding without requiring 98 intermediate routers to maintain any per-flow state by using a 99 multicast-specific BIER header. 101 [RFC8296] defines a common BIER Header format for MPLS and Non-MPLS 102 networks. It has defined two types of encapsulation methods using 103 the common BIER Header, (1) BIER encapsulation in MPLS networks, 104 here-in after referred as MPLS BIER Header in this document and (2) 105 BIER encapsulation in Non-MPLS networks, here-in after referred as 106 Non-MPLS BIER Header in this document. [RFC8296] also assigned 107 Ethertype=0xAB37 for Non-MPLS BIER Header packets to be directly 108 carried over the Ethernet links. 110 This document proposes a BIER IPv6 encapsulation for Non-MPLS IPv6 111 Networks, defining a method to carry the standard Non-MPLS BIER 112 header (as defined in [RFC8296]) in the native IPv6 header. A new 113 IPv6 Option type - BIER Option is defined to encode the standard Non- 114 MPLS BIER header and this newly defined BIER Option is carried under 115 the Destination Options header of the native IPv6 Header [RFC8200]. 117 This document details one of the proposed solutions for transporting 118 BIER packets in an IPv6 network. To better understand the overall 119 BIER IPv6 problem space, use cases and proposed solutions, refer to 120 [I-D.ietf-bier-ipv6-requirements]. 122 2. Terminology 124 Readers of this document are assumed to be familiar with the 125 terminology and concepts of the documents listed as Normative 126 References. 128 The following new terms are used throughout this document: 130 o BIERv6 - Bit indexed explicit replication using IPv6 data plane. 132 o BIERv6 Domain - A limited-domain using BIERv6 encapsulation as 133 specified in this document for transporting customer multicast 134 packets from one router to multiple destination routers. It is 135 usually managed by a single administrative entity, e.g., a 136 service-provider. It could be a single AS network or a large- 137 scale network that includes multiple ASes. BIER Domain is also 138 used for the same meaning as BIERv6 domain in this document. 140 o BIERv6 Option - An Option type carried in IPv6 Destination Options 141 Header (DO header, DOH) which includes the standard Non-MPLS BIER 142 Header. It is in type-length-value (TLV) format. The value 143 portion of the BIERv6 Option TLV, or the BIERv6 Option Data, is in 144 the format of the standard Non-MPLS BIER header. BIER option is 145 also used for the same meaning as BIERv6 option in this document. 147 o BIERv6 Header - An IPv6 Header with BIER Option. 149 o BIERv6 Packet - An IPv6 packet with BIERv6 Header. An IP/IPv6/ 150 Ethernet multicast packet is encapsulated with an outside BIERv6 151 header and transformed to a BIERv6 packet on the ingress PE 152 (BFIR). BIERv6 packet is transported by the transit routers 153 (BFRs) through a BIERv6 domain towards egress PEs(BFERs). BIERv6 154 packet is decapsulated by the BFERs, with the original IP/IPv6/ 155 Enthernet multicast packet being obtained and forwarded towards 156 the multicast receivers . 158 3. BIER IPv6 Encapsulation 160 3.1. BIER Option in IPv6 Destination Options Header 162 Destination Options Header and the Options that can be carried under 163 this extension header is defined in [RFC8200]. This document defines 164 a new Option type - BIER Option, to encode the Non-MPLS BIER header. 165 As specified in Section 4.2 [RFC8200], the BIER Option follows type- 166 length-value (TLV) encoding format and the standard Non-MPLS BIER 167 header [RFC8296] is encoded in the value portion of the BIER Option 168 TLV. 170 This BIER Option MUST be carried only inside the IPv6 Destination 171 Options header and MUST NOT be carried under the Hop-by-Hop Options 172 header. 174 The BIER Option is encoded in type-length-value (TLV) format as 175 follows: 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Next Header | Hdr Ext Len | Option Type | Option Length | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | | 183 ~ BIERv6 Option Data (Non-MPLS BIER Header defined in RFC8296) ~ 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Next Header 8-bit selector. Identifies the type of header 188 immediately following the Destination Options header. 190 Hdr Ext Len 8-bit unsigned integer. Length of the Destination 191 Options header in 8-octet units, not including the first 8 octets. 193 Option Type To be allocated by IANA. See section 6. 195 Option Length 8-bit unsigned integer. Length of the option, in 196 octets, excluding the Option Type and Option Length fields. 198 BIERv6 Option Data The BIERv6 Option Data contains the Non-MPLS BIER 199 Header defined in RFC8296. Fields in the Non-MPLS BIER Header 200 MUST be encoded as below. 202 BIFT-id: The BIFT-id is a domain-wide unique value in Non-MPLS 203 IPv6 encapsulation. See Section 2.2 of RFC 8296. 205 TC: SHOULD be set to binary value 000 upon transmission and MUST 206 be ignored upon. See Section 2.2 of RFC 8296. 208 S bit: SHOULD be set to 1 upon transmission, and MUST be ignored 209 upon reception. See Section 2.2 of RFC 8296. 211 TTL: MUST be set to a value larger than 0 upon encapsulation, 212 and SHOULD decrease by 1 by a BFR when forwarding a BIERv6 213 packet to a BFR adjacency. If the incoming TTL is 0, the packet 214 is considered to be "expired". See Section 2.1.1.2 of RFC 8296. 216 Nibble: SHOULD be set to 0000 upon transmission, and MUST be 217 ignored upon reception. See Section 2.2 of RFC 8296. 219 Ver: MUST be set to 0 upon transmission, and MUST be discarded 220 when it is not 0 upon reception. See Section 2.2 of RFC 8296. 222 BSL: See Section 2.1.2 of RFC 8296. 224 Entropy: See Section 2.1.2 of RFC 8296. 226 OAM: See Section 2.1.2 of RFC 8296. 228 Rsv: See Section 2.1.2 of RFC 8296. 230 DSCP: SHOULD be set to binary value 000000 upon transmission and 231 MUST be ignored upon reception. In BIERv6 encapsulation, uses 232 Traffic Class field of IPv6 header instead. 234 Proto: SHOULD be set to 0 upon transmission and be ignored upon 235 reception. In BIERv6 encapsulation, the functionality of this 236 6-bit Proto field is replaced by the Next Header field in 237 Destination Options header or the last IPv6 extension header to 238 indicate the type of the payload. This updates section 2.1.2 of 239 [RFC8296] about Proto definition. Next Header value in BIERv6 240 encapsulation for common usage includes: 242 Value 4 for IPv4 packet as BIERv6 payload. 244 Value 41 for IPv6 packet as BIERv6 payload. 246 Value 143 for Ethernet packet as BIERv6 payload. 248 Multicast VPN (MVPN) service is considered as part of the BIER 249 layering mode defined in [RFC8279], and should be supported by 250 BIERv6 encapsulation. [I-D.xie-bier-ipv6-mvpn] illustrates how 251 MVPN is supported in BIERv6 encapsulation without using this 252 Proto field. 254 BIER-PING [I-D.ietf-bier-ping] is considered a useful function 255 of the BIER architecture, and should be supported by BIERv6 256 encapsulation. How BIER-PING is supported in BIERv6 257 encapsulation without using this Proto field is outside the 258 scope of this document. 260 BFIR-id: See Section 2.1.2 of RFC 8296. 262 BitString: See Section 2.1.2 of RFC 8296. 264 3.2. Multicast and Unicast Destination Address 266 BIER is generally a hop-by-hop and one-to-many architecture, and thus 267 the IPv6 Destination Address (DA) being a Multicast Address is a way 268 one may think of as an approach for both the two paradigms in BIERv6 269 encapsulation. 271 However using a unicast address has the following benefits: 273 1. Replicating a BIERv6 packet over a non-BIER capable router. 275 2. Fast rerouting a BIERv6 packet using a unicast by-pass tunnel. 277 3. Forwarding a BIERv6 packet to one of the many BFR neighbors 278 connected on a LAN without imposing new requirements of snooping 279 on switches. 281 4. Replicating a BIERv6 packet through an anonymous system(AS) to 282 BFERs in other ASes, as illustrated in 283 [I-D.geng-bier-ipv6-inter-domain]. 285 Some of the above scenarios are assumed part of BIER architecture as 286 described in [RFC8279], and some of them are the scalability aspects 287 for inter-AS stateless multicast this document intends to support. 288 This document intends to fulfil all these requirements (categorized 289 as multi-hop replication), and proposes to use unicast address for 290 both one-hop replication and multi-hop replication. 292 The unicast address used in BIERv6 packet targeting a BFR SHOULD be 293 advertised as part of the BIER IPv6 Encapsulation. When a BFR 294 advertises the BIER information with BIERv6 encapsulation capability, 295 an IPv6 unicast address of this BFR MUST be selected specifically for 296 BIERv6 packet forwarding. Locally this "BIER Specific" IPv6 address 297 is initialized in FIB with a flag of "BIER specific handling", 298 represented as End.BIER function. 300 If a BFR belongs to more than one sub-domain, it may (though it need 301 not) have a different End.BIER in each sub-domain. If different 302 End.BIER is used for each sub-domain, implementation SHOULD support 303 verifying the DA of a BIERv6 packet is the End.BIER address bound by 304 the sub-domain of the packet. 306 For security deployment of BIERv6, the End.BIER address(es) is 307 required to be allocated from an IPv6 address block, and the IPv6 308 address block is used for domain boundary security policy. See 309 section 5.1 of this document for such security policy. Such kind of 310 security policy using IPv6 address block follows the paradigm settled 311 by the [RFC8754] section 5. 313 The following is an example of configuring a sub-domain using BIER 314 IPv6 encapsualation: 316 # Config an IPv6 block for End.BIER IPv6 address allocation 317 ipv6-block blk1 2001:DB8:A1:: 96 static 32 319 # Config BIER Sub-domain using End.BIER allocated from blk1 320 bier sub-domain 6 ipv6-underlay 321 bfr-prefix interface loopback0 322 end-bier ipv6-block blk1 opcode ::1 323 encapsulation ipv6 bsl 256 max-si 0 325 Deployment of BIERv6 in SRv6 network is allowed. In this case, the 326 BIERv6 domain is the same as SRv6 domain, and the End.BIER address is 327 allocated from the locator of SRv6. The following is an example of 328 configuring a sub-domain using BIERv6 when SRv6 is already deployed 329 with a locator 'loc1' configured: 331 # Config BIER Sub-domain using End.BIER allocated from loc1 332 bier sub-domain 6 ipv6-underlay 333 bfr-prefix interface loopback0 334 end-bier locator loc1 opcode ::1 335 encapsulation ipv6 bsl 256 max-si 0 337 For the convenience of such co-existence of BIERv6 and SRv6, the 338 indication of End.BIER or "BIER specific handling" in FIB shares the 339 same space as SRv6 Endpoints Behaviors defined in 340 [I-D.ietf-spring-srv6-network-programming]. 342 The following is an example pseudo-code of the End.BIER function: 344 1. IF NH = 60 and HopLimit > 0 ;;Ref1 345 2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2 346 3. Lookup the BIER Header inside the BIER option TLV. 347 4. Forward via the matched entry. 348 5. ELSE ;;Ref3 349 6. Drop the packet and end the process. 350 7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4 351 8. Send to CPU. 352 9. ELSE ;;Ref5 353 10. Drop the packet. 355 Ref1: Destination options header follows the IPv6 header directly and 356 HopLimit is bigger than zero. 358 Ref2: The first TLV is BIER type and is the only TLV present in 359 Destination options header. 361 Ref3/Ref5: Undesired packet is droped because the destination address 362 is the BIER specific IPv6 address (End.BIER function). 364 Ref4: An ICMPv6 packet using End.BIER as destination address. 366 3.3. BIERv6 Packet Format 368 As a multicast packet enters the BIER domain in a Non-MPLS IPv6 369 network, the multicast packet will be encapsulated with BIERv6 Header 370 by the Ingress BFR (BFIR). 372 Typically a BIERv6 header would contain the Destination Options 373 Header as the only Extensions Header besides IPv6 Header, as depicted 374 in the below figure. 376 +---------------+--------------+------------ 377 | IPv6 header | Dest Options | X type of 378 | | Header with | multicast 379 | | BIER Option | packet 380 | | | 381 | Next Hdr = 60 | Nxt Hdr = X | 382 +---------------+--------------+------------ 384 Format of the multicast packet with BIERv6 encapsulation carrying 385 other extension headers along with Destination Options extension 386 header is required to follow general recommendations of [RFC8200] and 387 examples in other RFCs. [RFC6275] introduces how the order should be 388 when other extension headers carries along with Home address option 389 in a destination options header. Similar to this example, this 390 document requires the Destination Options Header carrying the BIER 391 option MUST be placed as follows: 393 o After the routing header, if that header is present 395 o Before the Fragment Header, if that header is present 397 o Before the AH Header or ESP Header, if either one of those headers 398 is present 400 Source Address field in the IPv6 header MUST be a routable IPv6 401 unicast address of the BFIR in any case. 403 BFIR encodes the BIERv6 header in the above mentioned encapsulation 404 format and forwards the BIERv6 packet to the nexthop BFR following 405 the local BIFT table. 407 BFRs in the IPv6 network, processes and replicates the packets 408 towards the BFERs using the local BIFT table. The BitString field in 409 the BIERv6 Option Data may be changed by the BFRs as they replicate 410 the packet. BFRs MUST follow the procedures defined in section 3.1 411 as they modify the other fields in the BIERv6 Option Data. The 412 source address in the IPv6 header MUST NOT be modified by the BFRs. 414 4. BIERv6 Packet Processing 416 When a multicast packet enters the BIER domain, the Ingress BFR 417 (BFIR) encapsulates the multicast packet with a BIERv6 Header, 418 transforming it to a BIERv6 packet. The BIERv6 header includes an 419 IPv6 header and a BIERv6 Option in IPv6 Destination Options Header. 420 Source Address field in the IPv6 header MUST be set to a routable 421 IPv6 unicast address of the BFIR. Destination Address field in the 422 IPv6 header is set to the End.BIER address of the next-hop BFR the 423 BIERv6 packet replicating to, no matter next-hop BFR is directly 424 connected (one-hop) or not directly connected (multi-hop). 426 Upon receiving an BIERv6 packet, the BFR processes the IPv6 header 427 first. This is the general procedure of IPv6. 429 If the IPv6 Destination address is an End.BIER IPv6 unicast address 430 of this BFR, a 'BIER Specific Handling' indication will be obtained 431 by the preceding Unicast DA lookup (FIB lookup). The BIER option, if 432 exists, will be checked to decide which neighbor(s) to replicate the 433 BIERv6 packet to. 435 It is a local behavior to handle the combination of extension 436 headers, options and the BIER option(s) in destination options header 437 when a 'BIER Specific Handling' indication is got by the preceding 438 FIB lookup. Early deployment of BIERv6 may require there is only one 439 BIER option TLV in the destination options header followed the IPv6 440 header. How other extension headers or more BIER option TLVs in a 441 BIERv6 packet is handled is outside the scope of this document. 443 A packet having a 'BIER Specific Handling' indication but not having 444 a BIER option is supposed to be a wrong packet or an ICMPv6 packet, 445 and the process can be referred to the example in section 3.2. 447 A packet not having a 'BIER Specific Handling' indication but having 448 a BIER option SHOULD be processed normally as unicast forwarding 449 procedures, which may be a behavior of drop, or send to CPU, or other 450 behaviors in existing implementations. 452 The Destination Address field in the IPv6 Header MUST change to the 453 nexthop BFR's End.BIER Unicast address in BIERv6. 455 The Hop Limit field of IPv6 header MUST decrease by 1 when sending 456 packets to a BFR neighbor, while the TTL in the BIER header MUST be 457 unchanged on a Non-BIER router, or decrease by 1 on a BFR. 459 The BitString in the BIER header in the Destination Options Header 460 may change when sending packets to a neighbor. Such change of 461 BitString MUST be aligned with the procedure defined in RFC8279. 462 Because of the requirement to change the content of the option when 463 forwarding BIERv6 packet, the BIER option type should have chg flag 1 464 per section 4.2 of RFC8200. 466 The procedures applies normally if a bit corresponding to the self 467 bfr-id is set in the BitString field of the BIERv6 Option Data of the 468 BIERv6 packet. The node is considered to be an Egress BFR (BFER) in 469 this case. The BFER removes the BIERv6 header, including the IPv6 470 header and the Destination Options header, and copies the packet to 471 the multicast flow overlay. The egress VRF of a packet may be 472 determined by a further lookup on the IPv6 source address instead of 473 the upstream-assigned MPLS Label as described in [RFC8556]. 475 The Fragment Header, AH Header or ESP Header, if exists after the 476 BIER options header, can be processed on BFER only as part of the 477 multicast flow overlay process. 479 5. Security Considerations 481 BIER IPv6 encapsulation provides a new encapsulation based on IPv6 482 and BIER to transport multicast data packet in a BIER domain. The 483 BIER domain can be a single IGP area, an anonymous system (AS) with 484 multiple IGP areas, or multiple anonymous systems (ASes) operated by 485 a network operator. A single BIER Sub-domain may be deployed through 486 the whole BIER Domain, as illustrated in 487 [I-D.geng-bier-ipv6-inter-domain]. 489 This section reviews security considerations related to the BIER IPv6 490 encapsulation, based on security considerations of [RFC8279], 491 [RFC8296], and other documents related to IPv6 extension. 493 It is expected that all nodes in a BIER IPv6 domain are managed by 494 the same administrative entity. BIER-encapsulated packets should 495 generally not be accepted from untrusted interfaces or tunnels. For 496 example, an operator may wish to have a policy of accepting BIER- 497 encapsulated packets only from interfaces to trusted routers, and not 498 from customer-facing interfaces. See section 5.1 for normal Intra 499 domain deployment. 501 For applications that require a BFR to accept a BIER-encapsulated 502 packet from an interface to a system that is not controlled by the 503 network operator, the security considerations of [RFC8296] apply. 505 BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause 506 security problems. See section 5.2 for ICMP related problems. 508 This document introduces a new option used in IPv6 Destination 509 Options Header, together with the special-use IPv6 address called 510 End.BIER in IPv6 destination address for BIER IPv6 forwarding. 511 However the option newly introduced may be wrongly used with normal 512 IPv6 destination address. See section 5.3 for problems introduced by 513 the new IPv6 option with normal IPv6 destination address. 515 If the multicast data packet of a BIERv6 packet is altered by an 516 intermediate router, contents of the multicast data packet will be 517 damaged. BIER IPv6 encapsulation provides the ability of IPsec to 518 ensure the confidentiality or integrity for multicast data packet. 519 See section 5.4 for this security problem. 521 If the BIERv6 encapsulation of a particular packet specifies a 522 BitString (together with SI) other than the one intended by the BFIR, 523 the packet is likely to be misdelivered. Some modifications of the 524 BIER encapsulation, e.g., setting every bit in the BitString, may 525 result in denial-of-service (DoS) attacks. This kind of DoS attack 526 is a challenge not only in BIERv6 but also in BIER as specified in 527 [RFC8279] and [RFC8296], as the BitString is required to change on 528 BFR per the BIER forwarding procedures. This document does not 529 provide new mechanisms to improve this kind of weakness. 531 A BIER router accepts and uses the End.BIER IPv6 address to construct 532 BIFT only when the IPv6 address is configured explicitly, or received 533 from a router via control-plane protocols. The received information 534 is validated using existing authentication and security mechanisms of 535 the control-plane protocols. BIER IPv6 encapsulation does not define 536 any additional security mechanism in existing control-plane 537 protocols, and it inherits any security considerations that apply to 538 the control-plane protocols. 540 5.1. Intra Domain Deployment 542 Generally nodes outside the BIER Domain are not trusted: they cannot 543 directly use the End.BIER of the domain. This is enforced by two 544 levels of access control lists: 546 1. Any packet entering the BIER Domain and destined to an End.BIER 547 IPv6 Address within the BIER Domain is dropped. This may be realized 548 with the following logic. Other methods with equivalent outcome are 549 considered compliant: 551 * allocate all the End.BIER IPv6 Address from a block S/s 553 * configure each external interface of each edge node of the domain 554 with an inbound infrastructure access list (IACL) which drops any 555 incoming packet with a destination address in S/s 557 * Failure to implement this method of ingress filtering exposes the 558 BIER Domain to BIER attacks as described and referenced in [RFC8296]. 560 2. The distributed protection in #1 is complemented with per node 561 protection, dropping packets to End.BIER IPv6 Address from source 562 addresses outside the BIER Domain. This may be realized with the 563 following logic. Other methods with equivalent outcome are 564 considered compliant: 566 * assign all interface addresses from prefix A/a 568 * assign all the IPv6 addresses used as source address of BIER IPv6 569 packets from a block B/b 571 * at node k, all End.BIER IPv6 addresses local to k are assigned from 572 prefix Sk/sk 574 * configure each internal interface of each BIER node k in the BIER 575 Domain with an inbound IACL which drops any incoming packet with a 576 destination address in Sk/sk if the source address is not in A/a or 577 B/b. 579 For simplicity of deployment, a configuration of IACL effective for 580 all interfaces can be provided by a router. Such IACL can be 581 referred to as global IACL(GIACL) .Each BIER node k then simply 582 configs a GIACL which drops any incoming packet with a destination 583 address in Sk/sk if the source address is not in A/a or B/b for the 584 intra-domain deployment mode. 586 5.2. ICMP Error Processing 588 The BIERv6 BFR does not send ICMP error messages to the source 589 address of a BIERv6 packet, there is still chance that Non-BFR 590 routers send ICMP error messages to source nodes within the BIER 591 Domain. 593 A large number of ICMP may be elicited and sent to a BFIR router, in 594 case when a BIERv6 packet is filled with wrong Hop Limit, either 595 error or malfeasance. A rate-limiting of ICMP packet should be 596 implemented on each BFR. 598 The ingress node can take note of the fact that it is getting, in 599 response to BIER IPv6 packet, one or more ICMP error packets. By 600 default, the reception of such a packets MUST be countered and 601 logged. However, it is possible for such log entries to be "false 602 positives" that generate a lot of "noise" in the log; therefore, 603 implementations SHOULD have a knob to disable this logging. 605 5.3. Security caused by BIER option 607 This document introduces a new option used in IPv6 Destination 608 Options Header. An IPv6 packet with a normal IPv6 address of a 609 router (e.g. loopback IPv6 address of the router) as destination 610 address will possibly carry a BIER option. 612 For a router incapable of BIERv6, such BIERv6 packet will not be 613 processed by the procedure described in this document, but be 614 processed as normal IPv6 packet with unknown option, and the existing 615 security considerations for handling IPv6 options apply. Possible 616 way of handling IPv6 packets with BIER option may be send to CPU for 617 slow path processing, with rate-limiting, or be discarded according 618 to the local policy. 620 For a router capable of BIERv6, such BIERv6 packet MUST NOT be 621 forwarded, but should be processed as a normal IPv6 packet with 622 unknown option, or additionally and optionally be countered and 623 logged if the router is capable of doing so. 625 5.4. Applicability of IPsec 627 IPsec [RFC4301] uses two protocols to provide traffic security 628 services -- Authentication Header (AH) [RFC4302] and Encapsulating 629 Security Payload (ESP) [RFC4303]. Each protocol supports two modes 630 of use: transport mode and tunnel mode. IPsec support both unicast 631 and multicast. IPsec implementations MUST support ESP and MAY 632 support AH. 634 This document assume IPsec working in tunnel mode with inner IPv4 or 635 IPv6 multicast packet encapsulated in outer BIERv6 header and IPsec 636 header(s). 638 IPsec used with BIER IPv6 encapsulation to ensure that a BIER payload 639 is not altered while in transit between BFIR and BFERs. If a BFR in 640 between BFIR and BFERs is compromised, there is no way to prevent the 641 compromised BFR from making illegitimate modifications to the BIER 642 payload or to prevent it from misforwarding or misdelivering the 643 BIER-encapsulated packet, but the BFERs will detect the illegitimate 644 modifications to the BIER Payload (or the inner multicast data 645 packet). This could provide cryptographic integrity protection for 646 multicast data transport. This capability of IPsec comes from the 647 design that, the destination options header carrying the BIER header 648 is located before the AH or ESP and the BFR routers in between BFIR 649 and BFERs can process the BIER header without aware of AH or ESP. 651 For ESP, the Integrity Check Value (ICV) is computed over the ESP 652 header, Payload, and ESP trailer fields. It doesn't require the IP 653 or extension header for ICV calculating, and thus the change of DA 654 and BIER option data does not affect the function of ESP. 656 For AH, the Integrity Check Value (ICV) is computed over the IP or 657 extension header fields before the AH header, the AH header, and the 658 Payload. The IPv6 DA is immutable for unicast traffic in AH, and the 659 change of DA in BIER IPv6 forwarding for multicast traffic is 660 incompatible to this rule. How AH is extended to support multicast 661 traffic transporting through BIER IPv6 encapsulation is outside the 662 scope of this document. 664 The detailed control-plane for BIER IPv6 encapsulation IPsec function 665 is outside the scope of the document. Internet Key Exchange Protocol 666 Version 2 (IKEv2) [RFC7296] and Group Security Association (GSA) 667 [RFC5374] can be referred to for further studying. 669 6. IANA Considerations 671 6.1. BIER Option Type 673 Allocation is expected from IANA for a BIER Option Type codepoint 674 from the "Destination Options and Hop-by-Hop Options" sub-registry of 675 the "Internet Protocol Version 6 (IPv6) Parameters" registry. The 676 value 0x70 is suggested. 678 +-----------+-----+-----+-------+-------------+------------+ 679 | Hex Value | act | chg | rest | Description | Reference | 680 +-----------+-----+-----+-------+-------------+------------+ 681 | 0x70 | 01 | 1 | 10000 | BIER Option | This draft | 682 +-----------+-----+-----+-------+-------------+------------+ 684 6.2. End.BIER Function 686 Allocation is expected from IANA for an End.BIER function codepoint 687 from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is 688 suggested. 690 +-------+--------+--------------------------+------------+ 691 | Value | Hex | Endpoint function | Reference | 692 +-------+--------+--------------------------+------------+ 693 | TBD | TBD | End.BIER | This draft | 694 +-------+--------+--------------------------+------------+ 696 7. Acknowledgements 698 The authors would like to thank Stig Venaas for his valuable 699 comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda, 700 Toerless Eckert, Jeffrey Zhang for the helpful comments to improve 701 this document. 703 Thanks Aijun Wang for comments about BIER OAM function in BIER IPv6 704 encapsulation. 706 Thanks Mach Chen for review and suggestions about BIER-PING function 707 in BIER IPv6 encapsulation. 709 8. Contributors 711 Gang Yan 713 Huawei Technologies 715 China 717 Email: yangang@huawei.com 719 Yang(Yolanda) Xia 721 Huawei Technologies 723 China 725 Email: yolanda.xia@huawei.com 727 9. References 729 9.1. Normative References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, 733 DOI 10.17487/RFC2119, March 1997, 734 . 736 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 737 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 738 December 2005, . 740 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 741 DOI 10.17487/RFC4302, December 2005, 742 . 744 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 745 RFC 4303, DOI 10.17487/RFC4303, December 2005, 746 . 748 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 749 Extensions to the Security Architecture for the Internet 750 Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, 751 . 753 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 754 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 755 2011, . 757 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 758 Kivinen, "Internet Key Exchange Protocol Version 2 759 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 760 2014, . 762 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 763 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 764 May 2017, . 766 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 767 (IPv6) Specification", STD 86, RFC 8200, 768 DOI 10.17487/RFC8200, July 2017, 769 . 771 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 772 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 773 Explicit Replication (BIER)", RFC 8279, 774 DOI 10.17487/RFC8279, November 2017, 775 . 777 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 778 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 779 for Bit Index Explicit Replication (BIER) in MPLS and Non- 780 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 781 2018, . 783 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 784 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 785 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 786 2019, . 788 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 789 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 790 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 791 . 793 9.2. Informative References 795 [I-D.geng-bier-ipv6-inter-domain] 796 Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain 797 Multicast Deployment using BIERv6", draft-geng-bier-ipv6- 798 inter-domain-01 (work in progress), January 2020. 800 [I-D.ietf-bier-ipv6-requirements] 801 McBride, M., Xie, J., Dhanaraj, S., Asati, R., and Y. Zhu, 802 "BIER IPv6 Requirements", draft-ietf-bier- 803 ipv6-requirements-04 (work in progress), January 2020. 805 [I-D.ietf-bier-ping] 806 Nainar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 807 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 808 ping-07 (work in progress), May 2020. 810 [I-D.ietf-spring-srv6-network-programming] 811 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 812 Matsushima, S., and Z. Li, "SRv6 Network Programming", 813 draft-ietf-spring-srv6-network-programming-15 (work in 814 progress), March 2020. 816 [I-D.xie-bier-ipv6-mvpn] 817 Xie, J., McBride, M., Dhanaraj, S., and L. Geng, "Use of 818 BIER IPv6 Encapsulation (BIERv6) for Multicast VPN in IPv6 819 networks", draft-xie-bier-ipv6-mvpn-02 (work in progress), 820 January 2020. 822 Authors' Addresses 824 Jingrong Xie 825 Huawei Technologies 827 Email: xiejingrong@huawei.com 829 Liang Geng 830 China Mobile 831 Beijing 10053 833 Email: gengliang@chinamobile.com 835 Mike McBride 836 Futurewei 838 Email: mmcbride7@gmail.com 840 Rajiv Asati 841 Cisco 843 Email: rajiva@cisco.com 845 Senthil Dhanaraj 846 Huawei 848 Email: senthil.dhanaraj@huawei.com 849 Yongqing Zhu 850 China Telecom 852 Email: zhuyq8@chinatelecom.cn 854 Zhuangzhuang Qin 855 China Unicom 857 Email: qinzhuangzhuang@chinaunicom.cn 859 MooChang Shin 860 LG Uplus 862 Email: himzzang@lguplus.co.kr 864 Xuesong Geng 865 Huawei 867 Email: gengxuesong@huawei.com