idnits 2.17.1 draft-xie-bier-ipv6-encapsulation-06.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8296]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The abstract seems to indicate that this document updates RFC8296, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2020) is 1502 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) == Missing Reference: 'RFC2474' is mentioned on line 217, but not defined ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == 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-06 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-10 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 Intended status: Standards Track L. Geng 5 Expires: September 10, 2020 China Mobile 6 M. McBride 7 Futurewei 8 R. Asati 9 Cisco 10 S. Dhanaraj 11 Huawei 12 March 9, 2020 14 Encapsulation for BIER in Non-MPLS IPv6 Networks 15 draft-xie-bier-ipv6-encapsulation-06 17 Abstract 19 This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- 20 MPLS IPv6 Networks using the IPv6 Destination Option extension 21 header. This document updates [RFC8296]. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119] and 28 [RFC8174]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 10, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 3 67 3.1. BIER Option in IPv6 Destination Options Header . . . . . 3 68 3.2. Multicast and Unicast Destination Address . . . . . . . . 6 69 3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8 70 4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 11 73 5.2. ICMP Error Processing . . . . . . . . . . . . . . . . . . 12 74 5.3. Security caused by BIER option . . . . . . . . . . . . . 13 75 5.4. Applicability of IPsec . . . . . . . . . . . . . . . . . 13 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 77 6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 14 78 6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15 79 6.3. BIER Next Protocol Identifiers . . . . . . . . . . . . . 15 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 84 9.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 90 that provides optimal multicast forwarding without requiring 91 intermediate routers to maintain any per-flow state by using a 92 multicast-specific BIER header. 94 [RFC8296] defines a common BIER Header format for MPLS and Non-MPLS 95 networks. It has defined two types of encapsulation methods using 96 the common BIER Header, (1) BIER encapsulation in MPLS networks, 97 here-in after referred as MPLS BIER Header in this document and (2) 98 BIER encapsulation in Non-MPLS networks, here-in after referred as 99 Non-MPLS BIER Header in this document. [RFC8296] also assigned 100 Ethertype=0xAB37 for Non-MPLS BIER Header packets to be directly 101 carried over the Ethernet links. 103 This document proposes a BIER IPv6 encapsulation for Non-MPLS IPv6 104 Networks, defining a method to carry the standard Non-MPLS BIER 105 header (as defined in [RFC8296]) in the native IPv6 header. A new 106 IPv6 Option type - BIER Option is defined to encode the standard Non- 107 MPLS BIER header and this newly defined BIER Option is carried under 108 the Destination Options header of the native IPv6 Header [RFC8200]. 110 This document details one of the proposed solutions for transporting 111 BIER packets in an IPv6 network. To better understand the overall 112 BIER IPv6 problem space, use cases and proposed solutions, refer to 113 [I-D.ietf-bier-ipv6-requirements]. 115 2. Terminology 117 Readers of this document are assumed to be familiar with the 118 terminology and concepts of the documents listed as Normative 119 References. 121 The following new terms are used throughout this document: 123 o BIERv6 - BIER IPv6. 125 o BIER Option - An Option type carried in IPv6 Destination Options 126 Header which includes the standard Non-MPLS BIER Header. 128 o BIERv6 Header - An IPv6 Header with BIER Option. 130 o BIERv6 Packet - An IPv6 packet with BIERv6 Header. Such an IPv6 131 packet typically carries the user multicast payload and is 132 forwarded by BFRs in the BIERv6 network towards the multicast 133 receivers. 135 3. BIER IPv6 Encapsulation 137 3.1. BIER Option in IPv6 Destination Options Header 139 Destination Options Header and the Options that can be carried under 140 this extension header is defined in [RFC8200]. This document defines 141 a new Option type - BIER Option, to encode the Non-MPLS BIER header. 143 As specified in Section 4.2 [RFC8200], the BIER Option follows type- 144 length-value (TLV) encoding format and the standard Non-MPLS BIER 145 header [RFC8296] is encoded in the value portion of the BIER Option 146 TLV. 148 This BIER Option MUST be carried only inside the IPv6 Destination 149 Options header and MUST NOT be carried under the Hop-by-Hop Options 150 header. 152 Co-existence of Destination Options Header with BIER option TLV and 153 other IPv6 extension headers MUST confirm to the general requirements 154 defined in [RFC8200]. In addition to the requirements defined in 155 [RFC8200], this document requires that the Destination Options Header 156 with a BIER Option TLV MUST appear only after the Routing Header if 157 the Routing Header is present in the IPv6 Header. 159 The BIER Option is encoded in type-length-value (TLV) format as 160 follows: 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Next Header | Hdr Ext Len | Option Type | Option Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | | 168 ~ Non-MPLS BIER Header (defined in RFC8296) ~ 169 | | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Next Header 8-bit selector. Identifies the type of header 173 immediately following the Destination Options header. 175 Hdr Ext Len 8-bit unsigned integer. Length of the Destination 176 Options header in 8-octet units, not including the first 8 octets. 178 Option Type To be allocated by IANA. See section 6. 180 Option Length 8-bit unsigned integer. Length of the option, in 181 octets, excluding the Option Type and Option Length fields. 183 Non-MPLS BIER Header The Non-MPLS BIER Header defined in RFC8296. 184 Fields in the Non-MPLS BIER Header MUST be encoded as below. 186 BIFT-id: The BIFT-id is a domain-wide unique value in Non-MPLS 187 IPv6 encapsulation. See Section 2.2 of RFC 8296. 189 TC: SHOULD be set to binary value 000 upon transmission and MUST 190 be ignored upon. See Section 2.2 of RFC 8296. 192 S bit: SHOULD be set to 1 upon transmission, and MUST be ignored 193 upon reception. See Section 2.2 of RFC 8296. 195 TTL: MUST be set to a value larger than 0 upon encapsulation, 196 and SHOULD decrease by 1 by a BFR when forwarding a BIERv6 197 packet to a BFR adjacency. If the incoming TTL is 0, the packet 198 is considered to be "expired". See Section 2.1.1.2 of RFC 8296. 200 Nibble: SHOULD be set to 0000 upon transmission, and MUST be 201 ignored upon reception. See Section 2.2 of RFC 8296. 203 Ver: MUST be set to 0 upon transmission, and MUST be discarded 204 when it is not 0 upon reception. See Section 2.2 of RFC 8296. 206 BSL: See Section 2.1.2 of RFC 8296. 208 Entropy: See Section 2.1.2 of RFC 8296. 210 OAM: See Section 2.1.2 of RFC 8296. 212 Rsv: See Section 2.1.2 of RFC 8296. 214 DSCP: SHOULD be set to binary value 000000 upon transmission and 215 MUST be ignored upon reception. In IPv6 BIER encapsulation, 216 uses highest 6-bit of Traffic Class field of IPv6 header to hold 217 a Differentiated Services Codepoint [RFC2474]. 219 Proto: This fileld is used for two functions. The first is to 220 identify the BIER Payload following the BIER header, and the 221 second is to deliver the packet to a proper overlay module by 222 BIER layer, with VRF lookup in case of BIER data process, or 223 without VRF lookup in case of BIER OAM process. In BIER IPv6 224 encapsulation, the first function of Proto is compromised by a 225 proper Next Header value combination, and the second function of 226 Proto should be kept with the semantic unique and consistent for 227 BIER demultiplexing. This updates section 2.1.2 of [RFC8296] 228 about Proto defination. This document support the following 229 combination of BIER Proto and Next Header: 231 Use Next Header value 4, 41 and 143 for IPv4 packet, IPv6 232 packet and Ethernet packet respectively, and use Proto value 233 TBD1 indicating "Delivering the data packet with VRF lookup 234 in IPv6 source address". 236 Use Next Header value 59 for private packet format, and use 237 Proto value 5 indicating "Delivering the BIER OAM packet 238 without VRF lookup". The BIER-PING [I-D.ietf-bier-ping] 239 works equally in BIER IPv6 encapsulation as well as in BIER 240 MPLS or BIER Ethernet encapsulation. 242 Allocation of BIER Proto value TBD1 is listed in the IANA 243 considerations section of this document. 245 BFIR-id: See Section 2.1.2 of RFC 8296. 247 BitString: See Section 2.1.2 of RFC 8296. 249 3.2. Multicast and Unicast Destination Address 251 BIER is generally a hop-by-hop and one-to-many architecture, and thus 252 the IPv6 Destination Address (DA) being a Multicast Address is a way 253 one may think of as an approach for both the two paradigms in BIERv6 254 encapsulation. 256 However using a unicast address has the following benefits: 258 1. Tunneling a BIERv6 packet over a non-BIER capable router. 260 2. Fast rerouting a BIERv6 packet using a unicast by-pass tunnel. 262 3. Forwarding a BIERv6 packet to one of the many BFR neighbors 263 connected on a LAN. 265 4. Connecting BIER domains, for example Data Center domains, in an 266 overlay manner. 268 Some of the above functions are assumed very basic requirements and 269 part of BIER architecture as described in [RFC8279]. This document 270 uses unicast address for both one-hop replication and multi-hop 271 replication. 273 The unicast address used in BIERv6 packet targeting a BFR SHOULD be 274 advertised as part of the BIER IPv6 Encapsulation. When a BFR 275 advertises the BIER information with BIERv6 encapsulation capability, 276 an IPv6 unicast address of this BFR MUST be selected specifically for 277 BIERv6 packet forwarding. Locally this "BIER Specific" IPv6 address 278 is initialized in FIB with a flag of "BIER specific handling", 279 represented as End.BIER function. 281 If a BFR belongs to more than one sub-domain, it may (though it need 282 not) have a different End.BIER in each sub-domain. If different 283 End.BIER is used for each sub-domain, implementation SHOULD support 284 verifying the DA of a BIERv6 packet is the End.BIER address bound by 285 the sub-domain of the packet. See section 5.2 for such use case. 287 The following is an example of configuring a sub-domain using BIER 288 IPv6 encapsualation: 290 # Config an IPv6 block for End.BIER IPv6 address allocation 291 ipv6-block blk1 2001:DB8:A1:: 96 static 32 293 # Config BIER Sub-domain using End.BIER allocated from blk1 294 bier sub-domain 6 ipv6-underlay 295 bfr-prefix interface loopback0 296 end-bier ipv6-block blk1 opcode ::1 297 encapsulation ipv6 bsl 256 max-si 0 299 The co-existance of BIERv6 and SRv6 is allowed. The following is an 300 example of configuring a sub-domain using BIERv6 when SRv6 is already 301 deployed with a locator 'loc1' configured: 303 # Config BIER Sub-domain using End.BIER allocated from loc1 304 bier sub-domain 6 ipv6-underlay 305 bfr-prefix interface loopback0 306 end-bier locator loc1 opcode ::1 307 encapsulation ipv6 bsl 256 max-si 0 309 For the convenience of such co-existence of BIERv6 and SRv6, the 310 indication of End.BIER or "BIER specific handling" in FIB shares the 311 same space as SRv6 Endpoints Behaviors defined in 312 [I-D.ietf-spring-srv6-network-programming]. Apart from this sharing 313 of code space, there is nothing dependent on SRv6. 315 The following is an example pseudo-code of the End.BIER function: 317 1. IF NH = 60 and HopLimit > 0 ;;Ref1 318 2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2 319 3. Lookup the BIER Header inside the BIER option TLV. 320 4. Forward via the matched entry. 321 5. ELSE ;;Ref3 322 6. Drop the packet and end the process. 323 7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4 324 8. Send to CPU. 325 9. ELSE ;;Ref5 326 10. Drop the packet. 328 Ref1: Destination options header follows the IPv6 header directly and 329 HopLimit is bigger than zero. 331 Ref2: The first TLV is BIER type and is the only TLV present in 332 Destination options header. 334 Ref3/Ref5: Undesired packet is droped because the destination address 335 is the BIER specific IPv6 address (End.BIER function). 337 Ref4: An ICMPv6 packet using End.BIER as destination address. 339 3.3. BIERv6 Packet Format 341 As a multicast packet enters the BIER domain in a Non-MPLS IPv6 342 network, the multicast packet will be encapsulated with BIERv6 343 Header. 345 Typically a BIERv6 header would contain the Destination Options 346 Header as the only Extensions Header besides IPv6 Header. However, 347 it is allowed and possible for other extension headers to appear 348 along with the Destination Options Header as long as the requirements 349 listed in section 3.1 of this document is met. 351 Format of the multicast packet with BIERv6 encapsulation carrying 352 only the Destination Options header is depicted in the below figure. 354 +---------------+--------------+------------ 355 | IPv6 header | Dest Options | X type of 356 | | Header with | multicast 357 | | BIER Option | packet 358 | | | 359 | Next Hdr = 60 | Nxt Hdr = X | 360 +---------------+--------------+------------ 362 Format of the multicast packet with BIERv6 encapsulation carrying 363 other extension headers along with Destination Options extension 364 header is required to follow general recommendations of [RFC8200] and 365 examples in other RFCs. [RFC6275] introduces how the order should be 366 when other extension headers carries along with Home address option 367 in a destination options header. Similar to this example, this 368 document requires the Destination Options Header carrying the BIER 369 option MUST be placed as follows: 371 o After the routing header, if that header is present 373 o Before the Fragment Header, if that header is present 375 o Before the AH Header or ESP Header, if either one of those headers 376 is present 378 Source Address field in the IPv6 header MUST be a routable IPv6 379 unicast address of the BFIR in any case. 381 BFIR encodes the Non-MPLS BIER header in the above mentioned 382 encapsulation format and forwards the BIERv6 packet to the nexthop 383 BFR following the local BIFT table. 385 BFRs in the IPv6 network, processes and replicates the packets 386 towards the BFERs using the local BIFT table. The bit-string field 387 in the Non-MPLS BIER header may be changed by the BFRs as they 388 replicate the packet. BFRs MUST follow the procedures defined in 389 section 3.1 as they modify the other fields in the Non-MPLS BIER 390 header. The source address in the IPv6 header MUST NOT be modified 391 by the BFRs. 393 4. BIERv6 Packet Processing 395 There is no BIER-specific processing, and all the 8 steps in section 396 6.5 of RFC8279 apply to BIERv6 packet processing. However, there are 397 some IPv6-specific processing procedures due to the base and general 398 procedures of IPv6. 400 On the overlay layer, when a multicast packet enters the BIER domain 401 in a Non-MPLS IPv6 network, the Ingress BFR (BFIR) encapsulates the 402 multicast packet with a BIERv6 Header, transforming it to a BIERv6 403 packet. The BIERv6 header includes an IPv6 header and IPv6 404 Destination Options Header within a standard Non-MPLS BIER header. 405 Source Address field in the IPv6 header MUST be set to a routable 406 IPv6 unicast address of the BFIR. Destination Address field in the 407 IPv6 header is set to the End.BIER address of the next-hop BFR the 408 BIERv6 packet replicating to, no matter next-hop BFR is directly 409 connected (one-hop) or not directly connected (multi-hop). 411 On the BIER layer, upon receiving an BIERv6 packet, the BFR processes 412 the IPv6 header first. This is the general procedure of IPv6. 414 If the IPv6 Destination address is an End.BIER IPv6 unicast address 415 of this BFR, a 'BIER Specific Handling' indication will be obtained 416 by the preceding Unicast DA lookup (FIB lookup). The BIER option, if 417 exists, will be checked to decide which neighbor(s) to replicate the 418 BIERv6 packet to. 420 It is a local behavior to handle the combination of extension 421 headers, options and the BIER option(s) in destination options header 422 when a 'BIER Specific Handling' indication is got by the preceding 423 FIB lookup. Early deployment of BIERv6 may require there is only one 424 BIER option TLV in the destination options header followed the IPv6 425 header. How other extension headers or more BIER option TLVs in a 426 BIERv6 packet is handled is outside the scope of this document. 428 A packet having a 'BIER Specific Handling' indication but not having 429 a BIER option is supposed to be a wrong packet or an ICMPv6 packet, 430 and the process can be refered to the example in section 3.2. 432 A packet not having a 'BIER Specific Handling' indication but having 433 a BIER option SHOULD be processed normally as unicast forwarding 434 procedures, which may be a behavior of drop, or send to CPU, or other 435 behaviors in existing implementations. 437 The Destination Address field in the IPv6 Header MUST change to the 438 nexthop BFR's End.BIER Unicast address in BIERv6. 440 The Hop Limit field of IPv6 header MUST decrease by 1 when sending 441 packets to a BFR neighbor, while the TTL in the BIER header MUST be 442 unchanged on a Non-BIER router, or decrease by 1 on a BFR. 444 The BitString in the BIER header in the Destination Options Header 445 may change when sending packets to a neighbor. Such change of 446 BitString MUST be aligned with the procedure defined in RFC8279. 447 Because of the requirement to change the content of the option when 448 forwarding BIERv6 packet, the BIER option type should have chg flag 1 449 per section 4.2 of RFC8200. 451 The procedures applies normally if a bit corresponding to the self 452 bfr-id is set in the bit-string field of the Non-MPLS BIER header of 453 the BIERv6 packet. The node is considered to be an Egress BFR (BFER) 454 in this case. The BFER removes the BIERv6 header, including the IPv6 455 header and the Destination Options header, and copies the packet to 456 the multicast flow overlay. The egress VRF of a packet may be 457 determined by a further lookup on the IPv6 source address instead of 458 the upstream-assigned MPLS Label as described in [RFC8556]. 460 The Fragment Header, AH Header or ESP Header, if exists after the 461 BIER options header, can be processed on BFER only as part of the 462 multicast flow overlay process. 464 5. Security Considerations 466 BIER IPv6 encapsulation provides a new encapsulation based on IPv6 467 and BIER to transport multicast data packet in a BIER domain. The 468 BIER domain can be a single IGP area, an anonymous system (AS) with 469 multiple IGP areas, or multiple anonymous systems (ASes) operated by 470 a network operator. A single BIER Sub-domain may be deployed through 471 the whole BIER Domain, as illustrated in 472 [I-D.geng-bier-ipv6-inter-domain]. 474 This section reviews security considerations related to the BIER IPv6 475 encapsulation, based on security considerations of [RFC8279], 476 [RFC8296], and other documents related to IPv6 extension. 478 It is expected that all nodes in a BIER IPv6 domain are managed by 479 the same administrative entity. BIER-encapsulated packets should 480 generally not be accepted from untrusted interfaces or tunnels. For 481 example, an operator may wish to have a policy of accepting BIER- 482 encapsulated packets only from interfaces to trusted routers, and not 483 from customer-facing interfaces. See section 5.1 for normal Intra 484 domain deployment. 486 For applications that require a BFR to accept a BIER-encapsulated 487 packet from an interface to a system that is not controlled by the 488 network operator, the security considerations of [RFC8296] apply. 490 BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause 491 security problems. See section 5.2 for ICMP related problems. 493 This document introduces a new option used in IPv6 Destination 494 Options Header, together with the special-use IPv6 address called 495 End.BIER in IPv6 destination address for BIER IPv6 forwarding. 496 However the option newly introduced may be wrongly used with normal 497 IPv6 destination address. See section 5.3 for problems introduced by 498 the new IPv6 option with normal IPv6 destination address. 500 If a BIER packet is altered, either the BIER header, or the multicast 501 data packet, by an intermediate router, packets may be lost, stolen, 502 or otherwise misdelivered. BIER IPv6 encapsulation provides the 503 ability of IPsec to ensure the confidentiality or integrity. See 504 section 5.4 for this security problem. 506 A BIER router accepts and uses the End.BIER IPv6 address to construct 507 BIFT only when the IPv6 address is configured explicitly, or received 508 from a router via control-plane protocols. The received information 509 is validated using existing authentication and security mechanisms of 510 the control-plane protocols. BIER IPv6 encapsulation does not define 511 any additional security mechanism in existing control-plane 512 protocols, and it inherits any security considerations that apply to 513 the control-plane protocols. 515 5.1. Intra Domain Deployment 517 Generally nodes outside the BIER Domain are not trusted: they cannot 518 directly use the End.BIER of the domain. This is enforced by two 519 levels of access control lists: 521 1. Any packet entering the BIER Domain and destined to an End.BIER 522 IPv6 Address within the BIER Domain is dropped. This may be realized 523 with the following logic. Other methods with equivalent outcome are 524 considered compliant: 526 * allocate all the End.BIER IPv6 Address from a block S/s 528 * configure each external interface of each edge node of the domain 529 with an inbound infrastructure access list (IACL) which drops any 530 incoming packet with a destination address in S/s 532 * Failure to implement this method of ingress filtering exposes the 533 BIER Domain to BIER attacks as described and referenced in [RFC8296]. 535 2. The distributed protection in #1 is complemented with per node 536 protection, dropping packets to End.BIER IPv6 Address from source 537 addresses outside the BIER Domain. This may be realized with the 538 following logic. Other methods with equivalent outcome are 539 considered compliant: 541 * assign all interface addresses from prefix A/a 543 * assign all the IPv6 addresses used as source address of BIER IPv6 544 packets from a block B/b 546 * at node k, all End.BIER IPv6 addresses local to k are assigned from 547 prefix Sk/sk 549 * configure each internal interface of each BIER node k in the BIER 550 Domain with an inbound IACL which drops any incoming packet with a 551 destination address in Sk/sk if the source address is not in A/a or 552 B/b. 554 For simplicity of deployment, a configuration of IACL effective for 555 all interfaces can be provided by a router. Such IACL can be 556 referred to as global IACL(GIACL) .Each BIER node k then simply 557 configs a GIACL which drops any incoming packet with a destination 558 address in Sk/sk if the source address is not in A/a or B/b for the 559 intra-domain deployment mode. 561 5.2. ICMP Error Processing 563 ICMP error packets generated within the BIER Domain are sent to 564 source nodes within the BIER Domain. 566 A large number of ICMP may be elicited and sent to a BFIR router, in 567 case when a BIER IPv6 packet is filled with wrong TTL, either error 568 or malfeasance. A rate-limiting of ICMP packet should be implemented 569 on each BFR. 571 The ingress node can take note of the fact that it is getting, in 572 response to BIER IPv6 packet, one or more ICMP error packets. By 573 default, the reception of such a packets MUST be countered and 574 logged. However, it is possible for such log entries to be "false 575 positives" that generate a lot of "noise" in the log; therefore, 576 implementations SHOULD have a knob to disable this logging. 578 OAM functions of PING and TRACE for BIER IPv6 encapsulation may also 579 need ICMP based on BIER IPv6 encapsulation and cause ICMP response 580 message containing BIER option. The ability of seperating such OAM 581 ICMP packets from error ICMP packets caused by error is necessary for 582 the availability of OAM, otherwise the OAM function may fail due to 583 the rate-limiting of ICMP error packets. 585 5.3. Security caused by BIER option 587 This document introduces a new option used in IPv6 Destination 588 Options Header. An IPv6 packet with a normal IPv6 address of a 589 router (e.g. loopback IPv6 address of the router) as destination 590 address will possibly carry a BIER option. 592 For a router incapable of BIERv6, such BIERv6 packet will not be 593 processed by the procedure described in this document, but be 594 processed as normal IPv6 packet with unknown option, and the existing 595 security considerations for handling IPv6 options apply. Possible 596 way of handling IPv6 packets with BIER option may be send to CPU for 597 slow path processing, with rate-limiting, or be discarded according 598 to the local policy. 600 For a router capable of BIERv6, such BIERv6 packet MUST NOT be 601 forwarded, but should be processed as a normal IPv6 packet with 602 unknown option, or additionally and optionally be countered and 603 logged if the router is capable of doing so. 605 5.4. Applicability of IPsec 607 IPsec [RFC4301] uses two protocols to provide traffic security 608 services -- Authentication Header (AH) [RFC4302] and Encapsulating 609 Security Payload (ESP) [RFC4303]. Each protocol supports two modes 610 of use: transport mode and tunnel mode. IPsec support both unicast 611 and multicast. IPsec implementations MUST support ESP and MAY 612 support AH. 614 This document assume IPsec working in tunnel mode with inner IPv4 or 615 IPv6 multicast packet encapsulated in outer BIERv6 header and IPsec 616 header(s). 618 IPsec used with BIER IPv6 encapsulation to ensure that a BIER payload 619 is not altered while in transit between BFIR and BFERs. If a BFR in 620 between BFIR and BFERs is compromised, there is no way to prevent the 621 compromised BFR from making illegitimate modifications to the BIER 622 payload or to prevent it from misforwarding or misdelivering the 623 BIER-encapsulated packet, but the BFERs will detect the illegitimate 624 modifications to the BIER Payload (or the inner multicast data 625 packet). This could provide cryptographic integrity protection for 626 multicast data transport. This capability of IPsec comes from the 627 design that, the destination options header carrying the BIER header 628 is located before the AH or ESP and the BFR routers in between BFIR 629 and BFERs can process the BIER header without aware of AH or ESP. 631 For ESP, the Integrity Check Value (ICV) is computed over the ESP 632 header, Payload, and ESP trailer fields. It doesn't require the IP 633 or extension header for ICV calculating, and thus the change of DA 634 and BIER option data does not affect the function of ESP. 636 For AH, the Integrity Check Value (ICV) is computed over the IP or 637 extension header fields before the AH header, the AH header, and the 638 Payload. The IPv6 DA is immutable for unicast traffic in AH, and the 639 change of DA in BIER IPv6 forwarding for multicast traffic is 640 incompatible to this rule. How AH is extended to support multicast 641 traffic transporting through BIER IPv6 encapsulation is outside the 642 scope of this document. 644 The detailed control-plane for BIER IPv6 encapsulation IPsec function 645 is outside the scope of the document. Internet Key Exchange Protocol 646 Version 2 (IKEv2) [RFC5996] and Group Security Association (GSA) 647 [RFC5374] can be referred to for further studying. 649 6. IANA Considerations 651 6.1. BIER Option Type 653 Allocation is expected from IANA for a BIER Option Type codepoint 654 from the "Destination Options and Hop-by-Hop Options" sub-registry of 655 the "Internet Protocol Version 6 (IPv6) Parameters" registry. The 656 value 0x70 is suggested. 658 +-----------+-----+-----+-------+-------------+------------+ 659 | Hex Value | act | chg | rest | Description | Reference | 660 +-----------+-----+-----+-------+-------------+------------+ 661 | 0x70 | 01 | 1 | 10000 | BIER Option | This draft | 662 +-----------+-----+-----+-------+-------------+------------+ 664 6.2. End.BIER Function 666 Allocation is expected from IANA for an End.BIER function codepoint 667 from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is 668 suggested. 670 +-------+--------+--------------------------+------------+ 671 | Value | Hex | Endpoint function | Reference | 672 +-------+--------+--------------------------+------------+ 673 | TBD | TBD | End.BIER | This draft | 674 +-------+--------+--------------------------+------------+ 676 6.3. BIER Next Protocol Identifiers 678 Allocation is expected from IANA for a BIER Proto codepoint from the 679 "BIER Next Protocol Identifiers" sub-registry. 681 TBD1: Delivering the packet with VRF lookup in IPv6 source address 683 7. Acknowledgements 685 The authors would like to thank Stig Venaas for his valuable 686 comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda, 687 Toerless Eckert, Jeffrey Zhang for the helpful comments to improve 688 this document. 690 Thanks Aijun Wang for comments about BIER OAM function in BIER IPv6 691 encapsulation. 693 Thanks Mach Chen for review and suggestions about BIER-PING function 694 in BIER IPv6 encapsulation. 696 8. Contributors 698 Gang Yan 700 Huawei Technologies 702 China 704 Email: yangang@huawei.com 705 Yang(Yolanda) Xia 707 Huawei Technologies 709 China 711 Email: yolanda.xia@huawei.com 713 9. References 715 9.1. Normative References 717 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 718 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 719 December 2005, . 721 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 722 DOI 10.17487/RFC4302, December 2005, 723 . 725 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 726 RFC 4303, DOI 10.17487/RFC4303, December 2005, 727 . 729 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 730 Extensions to the Security Architecture for the Internet 731 Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, 732 . 734 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 735 "Internet Key Exchange Protocol Version 2 (IKEv2)", 736 RFC 5996, DOI 10.17487/RFC5996, September 2010, 737 . 739 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 740 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 741 2011, . 743 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 744 (IPv6) Specification", STD 86, RFC 8200, 745 DOI 10.17487/RFC8200, July 2017, 746 . 748 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 749 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 750 Explicit Replication (BIER)", RFC 8279, 751 DOI 10.17487/RFC8279, November 2017, 752 . 754 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 755 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 756 for Bit Index Explicit Replication (BIER) in MPLS and Non- 757 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 758 2018, . 760 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 761 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 762 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 763 2019, . 765 9.2. Informative References 767 [I-D.geng-bier-ipv6-inter-domain] 768 Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain 769 Multicast Deployment using BIERv6", draft-geng-bier-ipv6- 770 inter-domain-01 (work in progress), January 2020. 772 [I-D.ietf-bier-ipv6-requirements] 773 McBride, M., Xie, J., Dhanaraj, S., Asati, R., and Y. Zhu, 774 "BIER IPv6 Requirements", draft-ietf-bier- 775 ipv6-requirements-04 (work in progress), January 2020. 777 [I-D.ietf-bier-ping] 778 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 779 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 780 ping-06 (work in progress), October 2019. 782 [I-D.ietf-spring-srv6-network-programming] 783 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 784 Matsushima, S., and Z. Li, "SRv6 Network Programming", 785 draft-ietf-spring-srv6-network-programming-10 (work in 786 progress), February 2020. 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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 794 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 795 May 2017, . 797 Authors' Addresses 798 Jingrong Xie 799 Huawei Technologies 801 Email: xiejingrong@huawei.com 803 Liang Geng 804 China Mobile 805 Beijing 10053 807 Email: gengliang@chinamobile.com 809 Mike McBride 810 Futurewei 812 Email: mmcbride7@gmail.com 814 Rajiv Asati 815 Cisco 817 Email: rajiva@cisco.com 819 Senthil Dhanaraj 820 Huawei 822 Email: senthil.dhanaraj@huawei.com