idnits 2.17.1 draft-xie-bier-ipv6-encapsulation-05.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 (January 14, 2020) is 1535 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 218, but not defined ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) == Outdated reference: A later version (-09) exists of draft-ietf-bier-ipv6-requirements-03 == 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-07 Summary: 2 errors (**), 0 flaws (~~), 5 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: July 17, 2020 China Mobile 6 M. McBride 7 Futurewei 8 R. Asati 9 Cisco 10 S. Dhanaraj 11 Huawei 12 January 14, 2020 14 Encapsulation for BIER in Non-MPLS IPv6 Networks 15 draft-xie-bier-ipv6-encapsulation-05 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 July 17, 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 . . . . . . . . . . . . . . . . . . . 11 72 5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 12 73 5.2. Inter Domain Deployment . . . . . . . . . . . . . . . . . 13 74 5.3. ICMP Error Processing . . . . . . . . . . . . . . . . . . 13 75 5.4. Security caused by BIER option . . . . . . . . . . . . . 14 76 5.5. Applicability of IPsec . . . . . . . . . . . . . . . . . 14 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 15 79 6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15 80 6.3. BIER Next Protocol Identifiers . . . . . . . . . . . . . 16 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 82 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 85 9.2. Informative References . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 88 1. Introduction 90 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 91 that provides optimal multicast forwarding without requiring 92 intermediate routers to maintain any per-flow state by using a 93 multicast-specific BIER header. 95 [RFC8296] defines a common BIER Header format for MPLS and Non-MPLS 96 networks. It has defined two types of encapsulation methods using 97 the common BIER Header, (1) BIER encapsulation in MPLS networks, 98 here-in after referred as MPLS BIER Header in this document and (2) 99 BIER encapsulation in Non-MPLS networks, here-in after referred as 100 Non-MPLS BIER Header in this document. [RFC8296] also assigned 101 Ethertype=0xAB37 for Non-MPLS BIER Header packets to be directly 102 carried over the Ethernet links. 104 This document proposes a BIER IPv6 encapsulation for Non-MPLS IPv6 105 Networks, defining a method to carry the standard Non-MPLS BIER 106 header (as defined in [RFC8296]) in the native IPv6 header. A new 107 IPv6 Option type - BIER Option is defined to encode the standard Non- 108 MPLS BIER header and this newly defined BIER Option is carried under 109 the Destination Options header of the native IPv6 Header [RFC8200]. 111 This document details one of the proposed solutions for transporting 112 BIER packets in an IPv6 network. To better understand the overall 113 BIER IPv6 problem space, use cases and proposed solutions, refer to 114 [I-D.ietf-bier-ipv6-requirements]. 116 2. Terminology 118 Readers of this document are assumed to be familiar with the 119 terminology and concepts of the documents listed as Normative 120 References. 122 The following new terms are used throughout this document: 124 o BIERv6 - BIER IPv6. 126 o BIER Option - An Option type carried in IPv6 Destination Options 127 Header which includes the standard Non-MPLS BIER Header. 129 o BIERv6 Header - An IPv6 Header with BIER Option. 131 o BIERv6 Packet - An IPv6 packet with BIERv6 Header. Such an IPv6 132 packet typically carries the user multicast payload and is 133 forwarded by BFRs in the BIERv6 network towards the multicast 134 receivers. 136 3. BIER IPv6 Encapsulation 138 3.1. BIER Option in IPv6 Destination Options Header 140 Destination Options Header and the Options that can be carried under 141 this extension header is defined in [RFC8200]. This document defines 142 a new Option type - BIER Option, to encode the Non-MPLS BIER header. 144 As specified in Section 4.2 [RFC8200], the BIER Option follows type- 145 length-value (TLV) encoding format and the standard Non-MPLS BIER 146 header [RFC8296] is encoded in the value portion of the BIER Option 147 TLV. 149 This BIER Option MUST be carried only inside the IPv6 Destination 150 Options header and MUST NOT be carried under the Hop-by-Hop Options 151 header. 153 Co-existence of Destination Options Header with BIER option TLV and 154 other IPv6 extension headers MUST confirm to the general requirements 155 defined in [RFC8200]. In addition to the requirements defined in 156 [RFC8200], this document requires that the Destination Options Header 157 with a BIER Option TLV MUST appear only after the Routing Header if 158 the Routing Header is present in the IPv6 Header. 160 The BIER Option is encoded in type-length-value (TLV) format as 161 follows: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Next Header | Hdr Ext Len | Option Type | Option Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | | 169 ~ Non-MPLS BIER Header (defined in RFC8296) ~ 170 | | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Next Header 8-bit selector. Identifies the type of header 174 immediately following the Destination Options header. 176 Hdr Ext Len 8-bit unsigned integer. Length of the Destination 177 Options header in 8-octet units, not including the first 8 octets. 179 Option Type To be allocated by IANA. See section 6. 181 Option Length 8-bit unsigned integer. Length of the option, in 182 octets, excluding the Option Type and Option Length fields. 184 Non-MPLS BIER Header The Non-MPLS BIER Header defined in RFC8296. 185 Fields in the Non-MPLS BIER Header MUST be encoded as below. 187 BIFT-id: The BIFT-id is a domain-wide unique value in Non-MPLS 188 IPv6 encapsulation. See Section 2.2 of RFC 8296. 190 TC: SHOULD be set to binary value 000 upon transmission and MUST 191 be ignored upon. See Section 2.2 of RFC 8296. 193 S bit: SHOULD be set to 1 upon transmission, and MUST be ignored 194 upon reception. See Section 2.2 of RFC 8296. 196 TTL: MUST be set to a value larger than 0 upon encapsulation, 197 and SHOULD decrease by 1 by a BFR when forwarding a BIERv6 198 packet to a BFR adjacency. If the incoming TTL is 0, the packet 199 is considered to be "expired". See Section 2.1.1.2 of RFC 8296. 201 Nibble: SHOULD be set to 0000 upon transmission, and MUST be 202 ignored upon reception. See Section 2.2 of RFC 8296. 204 Ver: MUST be set to 0 upon transmission, and MUST be discarded 205 when it is not 0 upon reception. See Section 2.2 of RFC 8296. 207 BSL: See Section 2.1.2 of RFC 8296. 209 Entropy: See Section 2.1.2 of RFC 8296. 211 OAM: See Section 2.1.2 of RFC 8296. 213 Rsv: See Section 2.1.2 of RFC 8296. 215 DSCP: SHOULD be set to binary value 000000 upon transmission and 216 MUST be ignored upon reception. In IPv6 BIER encapsulation, 217 uses highest 6-bit of Traffic Class field of IPv6 header to hold 218 a Differentiated Services Codepoint [RFC2474]. 220 Proto: This fileld is used for two functions. The first is to 221 identify the BIER Payload following the BIER header, and the 222 second is to deliver the packet to a proper overlay module by 223 BIER layer, with VRF lookup in case of BIER data process, or 224 without VRF lookup in case of BIER OAM process. In BIER IPv6 225 encapsulation, the first function of Proto is compromised by a 226 proper Next Header value combination, and the second function of 227 Proto should be kept with the semantic unique and consistent for 228 BIER demultiplexing. This updates section 2.1.2 of [RFC8296] 229 about Proto defination. This document support the following 230 combination of BIER Proto and Next Header: 232 Use Next Header value 4, 41 and TBD0 for IPv4 packet, IPv6 233 packet and Ethernet packet respectively, and use Proto value 234 TBD1 indicating "Delivering the data packet with VRF lookup 235 in IPv6 source address". 237 Use Next Header value 59 for private packet format, and use 238 Proto value 5 indicating "Delivering the BIER OAM packet 239 without VRF lookup". The BIER-PING [I-D.ietf-bier-ping] 240 works equally in BIER IPv6 encapsulation as well as in BIER 241 MPLS or BIER Ethernet encapsulation. 243 Allocation of Next Header value TBD0 for Ethernet packet is 244 applying in [I-D.ietf-spring-srv6-network-programming] and 245 will not be listed in the IANA considerations section of this 246 document. 248 Allocation of BIER Proto value TBD1 is listed in the IANA 249 considerations section of this document. 251 BFIR-id: See Section 2.1.2 of RFC 8296. 253 BitString: See Section 2.1.2 of RFC 8296. 255 3.2. Multicast and Unicast Destination Address 257 BIER is generally a hop-by-hop and one-to-many architecture, and thus 258 the IPv6 Destination Address (DA) being a Multicast Address is a way 259 one may think of as an approach for both the two paradigms in BIERv6 260 encapsulation. 262 However using a unicast address has the following benefits: 264 1. Tunneling a BIERv6 packet over a non-BIER capable router. 266 2. Fast rerouting a BIERv6 packet using a unicast by-pass tunnel. 268 3. Forwarding a BIERv6 packet to one of the many BFR neighbors 269 connected on a LAN. 271 4. Connecting BIER domains, for example Data Center domains, in an 272 overlay manner. 274 Some of the above functions are assumed very basic requirements and 275 part of BIER architecture as described in [RFC8279]. This document 276 uses unicast address for both one-hop replication and multi-hop 277 replication. 279 The unicast address used in BIERv6 packet targeting a BFR SHOULD be 280 advertised as part of the BIER IPv6 Encapsulation. When a BFR 281 advertises the BIER information with BIERv6 encapsulation capability, 282 an IPv6 unicast address of this BFR MUST be selected specifically for 283 BIERv6 packet forwarding. Locally this "BIER Specific" IPv6 address 284 is initialized in FIB with a flag of "BIER specific handling", 285 represented as End.BIER function. 287 If a BFR belongs to more than one sub-domain, it may (though it need 288 not) have a different End.BIER in each sub-domain. If different 289 End.BIER is used for each sub-domain, implementation SHOULD support 290 verifying the DA of a BIERv6 packet is the End.BIER address bound by 291 the sub-domain of the packet. See section 5.2 for such use case. 293 The following is an example of configuring a sub-domain using BIER 294 IPv6 encapsualation: 296 # Config an IPv6 block for End.BIER IPv6 address allocation 297 ipv6-block blk1 2001:DB8:A1:: 96 static 32 299 # Config BIER Sub-domain using End.BIER allocated from blk1 300 bier sub-domain 6 ipv6-underlay 301 bfr-prefix interface loopback0 302 end-bier ipv6-block blk1 opcode ::1 303 encapsulation ipv6 bsl 256 max-si 0 305 The co-existance of BIERv6 and SRv6 is allowed. The following is an 306 example of configuring a sub-domain using BIERv6 when SRv6 is already 307 deployed with a locator 'loc1' configured: 309 # Config BIER Sub-domain using End.BIER allocated from loc1 310 bier sub-domain 6 ipv6-underlay 311 bfr-prefix interface loopback0 312 end-bier locator loc1 opcode ::1 313 encapsulation ipv6 bsl 256 max-si 0 315 For the convenience of such co-existence of BIERv6 and SRv6, the 316 indication of End.BIER or "BIER specific handling" in FIB shares the 317 same space as SRv6 Endpoints Behaviors defined in 318 [I-D.ietf-spring-srv6-network-programming]. Apart from this sharing 319 of code space, there is nothing dependent on SRv6. 321 The following is an example pseudo-code of the End.BIER function: 323 1. IF NH = 60 and HopLimit > 0 ;;Ref1 324 2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2 325 3. Lookup the BIER Header inside the BIER option TLV. 326 4. Forward via the matched entry. 327 5. ELSE ;;Ref3 328 6. Drop the packet and end the process. 329 7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4 330 8. Send to CPU. 331 9. ELSE ;;Ref5 332 10. Drop the packet. 334 Ref1: Destination options header follows the IPv6 header directly and 335 HopLimit is bigger than zero. 337 Ref2: The first TLV is BIER type and is the only TLV present in 338 Destination options header. 340 Ref3/Ref5: Undesired packet is droped because the destination address 341 is the BIER specific IPv6 address (End.BIER function). 343 Ref4: An ICMPv6 packet using End.BIER as destination address. 345 3.3. BIERv6 Packet Format 347 As a multicast packet enters the BIER domain in a Non-MPLS IPv6 348 network, the multicast packet will be encapsulated with BIERv6 349 Header. 351 Typically a BIERv6 header would contain the Destination Options 352 Header as the only Extensions Header besides IPv6 Header. However, 353 it is allowed and possible for other extension headers to appear 354 along with the Destination Options Header as long as the requirements 355 listed in section 3.1 of this document is met. 357 Format of the multicast packet with BIERv6 encapsulation carrying 358 only the Destination Options header is depicted in the below figure. 360 +---------------+--------------+------------ 361 | IPv6 header | Dest Options | X type of 362 | | Header with | multicast 363 | | BIER Option | packet 364 | | | 365 | Next Hdr = 60 | Nxt Hdr = X | 366 +---------------+--------------+------------ 368 Format of the multicast packet with BIERv6 encapsulation carrying 369 other extension headers along with Destination Options extension 370 header is required to follow general recommendations of [RFC8200] and 371 examples in other RFCs. [RFC6275] introduces how the order should be 372 when other extension headers carries along with Home address option 373 in a destination options header. Similar to this example, this 374 document requires the Destination Options Header carrying the BIER 375 option MUST be placed as follows: 377 o After the routing header, if that header is present 379 o Before the Fragment Header, if that header is present 381 o Before the AH Header or ESP Header, if either one of those headers 382 is present 384 Source Address field in the IPv6 header MUST be a routable IPv6 385 unicast address of the BFIR in any case. 387 BFIR encodes the Non-MPLS BIER header in the above mentioned 388 encapsulation format and forwards the BIERv6 packet to the nexthop 389 BFR following the local BIFT table. 391 BFRs in the IPv6 network, processes and replicates the packets 392 towards the BFERs using the local BIFT table. The bit-string field 393 in the Non-MPLS BIER header may be changed by the BFRs as they 394 replicate the packet. BFRs MUST follow the procedures defined in 395 section 3.1 as they modify the other fields in the Non-MPLS BIER 396 header. The source address in the IPv6 header MUST NOT be modified 397 by the BFRs. 399 4. BIERv6 Packet Processing 401 There is no BIER-specific processing, and all the 8 steps in section 402 6.5 of RFC8279 apply to BIERv6 packet processing. However, there are 403 some IPv6-specific processing procedures due to the base and general 404 procedures of IPv6. 406 On the overlay layer, when a multicast packet enters the BIER domain 407 in a Non-MPLS IPv6 network, the Ingress BFR (BFIR) encapsulates the 408 multicast packet with a BIERv6 Header, transforming it to a BIERv6 409 packet. The BIERv6 header includes an IPv6 header and IPv6 410 Destination Options Header within a standard Non-MPLS BIER header. 411 Source Address field in the IPv6 header MUST be set to a routable 412 IPv6 unicast address of the BFIR. Destination Address field in the 413 IPv6 header is set to the End.BIER address of the next-hop BFR the 414 BIERv6 packet replicating to, no matter next-hop BFR is directly 415 connected (one-hop) or not directly connected (multi-hop). 417 On the BIER layer, upon receiving an BIERv6 packet, the BFR processes 418 the IPv6 header first. This is the general procedure of IPv6. 420 If the IPv6 Destination address is an End.BIER IPv6 unicast address 421 of this BFR, a 'BIER Specific Handling' indication will be obtained 422 by the preceding Unicast DA lookup (FIB lookup). The BIER option, if 423 exists, will be checked to decide which neighbor(s) to replicate the 424 BIERv6 packet to. 426 It is a local behavior to handle the combination of extension 427 headers, options and the BIER option(s) in destination options header 428 when a 'BIER Specific Handling' indication is got by the preceding 429 FIB lookup. Early deployment of BIERv6 may require there is only one 430 BIER option TLV in the destination options header followed the IPv6 431 header. How other extension headers or more BIER option TLVs in a 432 BIERv6 packet is handled is outside the scope of this document. 434 A packet having a 'BIER Specific Handling' indication but not having 435 a BIER option is supposed to be a wrong packet or an ICMPv6 packet, 436 and the process can be refered to the example in section 3.2. 438 A packet not having a 'BIER Specific Handling' indication but having 439 a BIER option SHOULD be processed normally as unicast forwarding 440 procedures, which may be a behavior of drop, or send to CPU, or other 441 behaviors in existing implementations. 443 The Destination Address field in the IPv6 Header MUST change to the 444 nexthop BFR's End.BIER Unicast address in BIERv6. 446 The Hop Limit field of IPv6 header MUST decrease by 1 when sending 447 packets to a BFR neighbor, while the TTL in the BIER header MUST be 448 unchanged on a Non-BIER router, or decrease by 1 on a BFR. 450 The BitString in the BIER header in the Destination Options Header 451 may change when sending packets to a neighbor. Such change of 452 BitString MUST be aligned with the procedure defined in RFC8279. 453 Because of the requirement to change the content of the option when 454 forwarding BIERv6 packet, the BIER option type should have chg flag 1 455 per section 4.2 of RFC8200. 457 The procedures applies normally if a bit corresponding to the self 458 bfr-id is set in the bit-string field of the Non-MPLS BIER header of 459 the BIERv6 packet. The node is considered to be an Egress BFR (BFER) 460 in this case. The BFER removes the BIERv6 header, including the IPv6 461 header and the Destination Options header, and copies the packet to 462 the multicast flow overlay. The egress VRF of a packet may be 463 determined by a further lookup on the IPv6 source address instead of 464 the upstream-assigned MPLS Label as described in [RFC8556]. 466 The Fragment Header, AH Header or ESP Header, if exists after the 467 BIER options header, can be processed on BFER only as part of the 468 multicast flow overlay process. 470 5. Security Considerations 472 BIER IPv6 encapsulation provides a new encapsulation based on IPv6 473 and BIER to transport multicast data packet in a BIER domain. The 474 BIER domain can be a single IGP area, an anonymous system (AS) with 475 multiple IGP areas, or multiple anonymous systems (ASes) operated by 476 a network operator. This section reviews security considerations 477 related to the BIER IPv6 encapsulation, based on security 478 considerations of [RFC8279], [RFC8296], and other documents related 479 to IPv6 extension. 481 BIER-encapsulated packets should generally not be accepted from 482 untrusted interfaces or tunnels. For example, an operator may wish 483 to have a policy of accepting BIER-encapsulated packets only from 484 interfaces to trusted routers, and not from customer-facing 485 interfaces. See section 5.1 for normal Intra domain deployment. 487 There may be applications that require a BFR to accept a BIER- 488 encapsulated packet from an interface to a system that is not 489 controlled by the network operator. See section 5.2 for inter domain 490 deployment. 492 BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause 493 security problems. See section 5.3 for ICMP related problems. 495 This document introduces a new option used in IPv6 Destination 496 Options Header, together with the special-use IPv6 address called 497 End.BIER in IPv6 destination address for BIER IPv6 forwarding. 498 However the option newly introduced may be wrongly used with normal 499 IPv6 destination address. See section 5.4 for problems introduced by 500 the new IPv6 option with normal IPv6 destination address. 502 If a BIER packet is altered, either the BIER header, or the multicast 503 data packet, by an intermediate router, packets may be lost, stolen, 504 or otherwise misdelivered. BIER IPv6 encapsulation provides the 505 ability of IPsec to ensure the confidentiality or integrity. See 506 section 5.5 for this security problem. 508 A BIER router accepts and uses the End.BIER IPv6 address to construct 509 BIFT only when the IPv6 address is configured explicitly, or received 510 from a router via control-plane protocols. The received information 511 is validated using existing authentication and security mechanisms of 512 the control-plane protocols. BIER IPv6 encapsulation does not define 513 any additional security mechanism in existing control-plane 514 protocols, and it inherits any security considerations that apply to 515 the control-plane protocols. 517 5.1. Intra Domain Deployment 519 Generally nodes outside the BIER Domain are not trusted: they cannot 520 directly use the End.BIER of the domain. This is enforced by two 521 levels of access control lists: 523 1. Any packet entering the BIER Domain and destined to an End.BIER 524 IPv6 Address within the BIER Domain is dropped. This may be realized 525 with the following logic. Other methods with equivalent outcome are 526 considered compliant: 528 * allocate all the End.BIER IPv6 Address from a block S/s 530 * configure each external interface of each edge node of the domain 531 with an inbound infrastructure access list (IACL) which drops any 532 incoming packet with a destination address in S/s 534 * Failure to implement this method of ingress filtering exposes the 535 BIER Domain to BIER attacks as described and referenced in [RFC8296]. 537 2. The distributed protection in #1 is complemented with per node 538 protection, dropping packets to End.BIER IPv6 Address from source 539 addresses outside the BIER Domain. This may be realized with the 540 following logic. Other methods with equivalent outcome are 541 considered compliant: 543 * assign all interface addresses from prefix A/a 545 * assign all the IPv6 addresses used as source address of BIER IPv6 546 packets from a block B/b 548 * at node k, all End.BIER IPv6 addresses local to k are assigned from 549 prefix Sk/sk 551 * configure each internal interface of each BIER node k in the BIER 552 Domain with an inbound IACL which drops any incoming packet with a 553 destination address in Sk/sk if the source address is not in A/a or 554 B/b. 556 For simplicity of deployment, a configuration of IACL effective for 557 all interfaces can be provided by a router. Such IACL can be 558 referred to as global IACL(GIACL) .Each BIER node k then simply 559 configs a GIACL which drops any incoming packet with a destination 560 address in Sk/sk if the source address is not in A/a or B/b for the 561 inter-domain deployment mode. 563 5.2. Inter Domain Deployment 565 There may be applications that require a BFR to accept a BIER- 566 encapsulated packet from an interface to a system that is not 567 controlled by the network operator. For instance, there may be an 568 application in which a virtual machine in a data center submits BIER- 569 encapsulated packets to a router. In such a case, it is desirable to 570 verify that the packet is from a legitimate source and that its 571 BitString denotes only systems to which that source is allowed to 572 send. Using BIER IPv6 encapsulation, IACL can be configured on each 573 internal interface of each BIER node k to allow packet with a 574 destination address in Sk/sk and the source address is in an allowed 575 list of IPv6 address. However, the BIER IPv6 encapsulation itself 576 does not provide a way to verify that the source is legitimate or the 577 source is allowed to set any particular set of bits in the BitString. 579 The IACL allowing specific IPv6 address outside the domain of a 580 network operator can be more strict by the following method: 582 * configure one sub-domain using only one bit string length, and a 583 seperate End.BIER for this sub-domain as a service opened to agreed 584 source(s) outside the domain of the operator's network. 586 * configure on BIER node to check if the End.BIER address of a packet 587 is the correct one bound to the sub-domain of a packet. 589 * configure IACL on each interface of each BIER node k (or simply 590 configure GIACL on each BIER node k) to allow packet with an End.BIER 591 as destination address and the allowed source(s) as source address. 593 This provides a way to ensure that the inter-domain source is allowed 594 to access only the BIER IPv6 transport service bound to a sub-domain 595 with a specific bit string length. 597 5.3. ICMP Error Processing 599 ICMP error packets generated within the BIER Domain are sent to 600 source nodes within the BIER Domain. 602 A large number of ICMP may be elicited and sent to a BFIR router, in 603 case when a BIER IPv6 packet is filled with wrong TTL, either error 604 or malfeasance. A rate-limiting of ICMP packet should be implemented 605 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 OAM functions of PING and TRACE for BIER IPv6 encapsulation may also 615 need ICMP based on BIER IPv6 encapsulation and cause ICMP response 616 message containing BIER option. The ability of seperating such OAM 617 ICMP packets from error ICMP packets caused by error is necessary for 618 the availability of OAM, otherwise the OAM function may fail due to 619 the rate-limiting of ICMP error packets. 621 5.4. Security caused by BIER option 623 This document introduces a new option used in IPv6 Destination 624 Options Header. An IPv6 packet with a normal IPv6 address of a 625 router (e.g. loopback IPv6 address of the router) as destination 626 address will possibly carry a BIER option. 628 For a router incapable of BIERv6, such BIERv6 packet will not be 629 processed by the procedure described in this document, but be 630 processed as normal IPv6 packet with unknown option, and the existing 631 security considerations for handling IPv6 options apply. Possible 632 way of handling IPv6 packets with BIER option may be send to CPU for 633 slow path processing, with rate-limiting, or be discarded according 634 to the local policy. 636 For a router capable of BIERv6, such BIERv6 packet MUST NOT be 637 forwarded, but should be processed as a normal IPv6 packet with 638 unknown option, or additionally and optionally be countered and 639 logged if the router is capable of doing so. 641 5.5. Applicability of IPsec 643 IPsec [RFC4301] uses two protocols to provide traffic security 644 services -- Authentication Header (AH) [RFC4302] and Encapsulating 645 Security Payload (ESP) [RFC4303]. Each protocol supports two modes 646 of use: transport mode and tunnel mode. IPsec support both unicast 647 and multicast. IPsec implementations MUST support ESP and MAY 648 support AH. 650 This document assume IPsec working in tunnel mode with inner IPv4 or 651 IPv6 multicast packet encapsulated in outer BIERv6 header and IPsec 652 header(s). 654 IPsec used with BIER IPv6 encapsulation to ensure that a BIER payload 655 is not altered while in transit between BFIR and BFERs. If a BFR in 656 between BFIR and BFERs is compromised, there is no way to prevent the 657 compromised BFR from making illegitimate modifications to the BIER 658 payload or to prevent it from misforwarding or misdelivering the 659 BIER-encapsulated packet, but the BFERs will detect the illegitimate 660 modifications to the BIER Payload (or the inner multicast data 661 packet). This could provide cryptographic integrity protection for 662 multicast data transport. This capability of IPsec comes from the 663 design that, the destination options header carrying the BIER header 664 is located before the AH or ESP and the BFR routers in between BFIR 665 and BFERs can process the BIER header without aware of AH or ESP. 667 For ESP, the Integrity Check Value (ICV) is computed over the ESP 668 header, Payload, and ESP trailer fields. It doesn't require the IP 669 or extension header for ICV calculating, and thus the change of DA 670 and BIER option data does not affect the function of ESP. 672 For AH, the Integrity Check Value (ICV) is computed over the IP or 673 extension header fields before the AH header, the AH header, and the 674 Payload. The IPv6 DA is immutable for unicast traffic in AH, and the 675 change of DA in BIER IPv6 forwarding for multicast traffic is 676 incompatible to this rule. How AH is extended to support multicast 677 traffic transporting through BIER IPv6 encapsulation is outside the 678 scope of this document. 680 The detailed control-plane for BIER IPv6 encapsulation IPsec function 681 is outside the scope of the document. Internet Key Exchange Protocol 682 Version 2 (IKEv2) [RFC5996] and Group Security Association (GSA) 683 [RFC5374] can be referred to for further studying. 685 6. IANA Considerations 687 6.1. BIER Option Type 689 Allocation is expected from IANA for a BIER Option Type codepoint 690 from the "Destination Options and Hop-by-Hop Options" sub-registry of 691 the "Internet Protocol Version 6 (IPv6) Parameters" registry. The 692 value 0x70 is suggested. 694 +-----------+-----+-----+-------+-------------+------------+ 695 | Hex Value | act | chg | rest | Description | Reference | 696 +-----------+-----+-----+-------+-------------+------------+ 697 | 0x70 | 01 | 1 | 10000 | BIER Option | This draft | 698 +-----------+-----+-----+-------+-------------+------------+ 700 6.2. End.BIER Function 702 Allocation is expected from IANA for an End.BIER function codepoint 703 from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is 704 suggested. 706 +-------+--------+--------------------------+------------+ 707 | Value | Hex | Endpoint function | Reference | 708 +-------+--------+--------------------------+------------+ 709 | TBD | TBD | End.BIER | This draft | 710 +-------+--------+--------------------------+------------+ 712 6.3. BIER Next Protocol Identifiers 714 Allocation is expected from IANA for a BIER Proto codepoint from the 715 "BIER Next Protocol Identifiers" sub-registry. 717 TBD1: Delivering the packet with VRF lookup in IPv6 source address 719 7. Acknowledgements 721 The authors would like to thank Stig Venaas for his valuable 722 comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda, 723 Toerless Eckert, Jeffrey Zhang for the helpful comments to improve 724 this document. 726 Thanks Aijun Wang for comments about BIER OAM function in BIER IPv6 727 encapsulation. 729 Thanks Mach Chen for review and suggestions about BIER-PING function 730 in BIER IPv6 encapsulation. 732 8. Contributors 734 Gang Yan 736 Huawei Technologies 738 China 740 Email: yangang@huawei.com 742 Yang(Yolanda) Xia 744 Huawei Technologies 746 China 748 Email: yolanda.xia@huawei.com 750 9. References 752 9.1. Normative References 754 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 755 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 756 December 2005, . 758 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 759 DOI 10.17487/RFC4302, December 2005, 760 . 762 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 763 RFC 4303, DOI 10.17487/RFC4303, December 2005, 764 . 766 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 767 Extensions to the Security Architecture for the Internet 768 Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, 769 . 771 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 772 "Internet Key Exchange Protocol Version 2 (IKEv2)", 773 RFC 5996, DOI 10.17487/RFC5996, September 2010, 774 . 776 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 777 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 778 2011, . 780 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 781 (IPv6) Specification", STD 86, RFC 8200, 782 DOI 10.17487/RFC8200, July 2017, 783 . 785 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 786 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 787 Explicit Replication (BIER)", RFC 8279, 788 DOI 10.17487/RFC8279, November 2017, 789 . 791 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 792 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 793 for Bit Index Explicit Replication (BIER) in MPLS and Non- 794 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 795 2018, . 797 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 798 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 799 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 800 2019, . 802 9.2. Informative References 804 [I-D.ietf-bier-ipv6-requirements] 805 McBride, M., Xie, J., Dhanaraj, S., and R. Asati, "BIER 806 IPv6 Requirements", draft-ietf-bier-ipv6-requirements-03 807 (work in progress), November 2019. 809 [I-D.ietf-bier-ping] 810 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 811 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 812 ping-06 (work in progress), October 2019. 814 [I-D.ietf-spring-srv6-network-programming] 815 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 816 Matsushima, S., and Z. Li, "SRv6 Network Programming", 817 draft-ietf-spring-srv6-network-programming-07 (work in 818 progress), December 2019. 820 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 821 Requirement Levels", BCP 14, RFC 2119, 822 DOI 10.17487/RFC2119, March 1997, 823 . 825 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 826 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 827 May 2017, . 829 Authors' Addresses 831 Jingrong Xie 832 Huawei Technologies 834 Email: xiejingrong@huawei.com 836 Liang Geng 837 China Mobile 838 Beijing 10053 840 Email: gengliang@chinamobile.com 841 Mike McBride 842 Futurewei 844 Email: mmcbride7@gmail.com 846 Rajiv Asati 847 Cisco 849 Email: rajiva@cisco.com 851 Senthil Dhanaraj 852 Huawei 854 Email: senthil.dhanaraj@huawei.com