idnits 2.17.1 draft-xie-bier-ipv6-encapsulation-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 11, 2019) is 1592 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 216, 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 (-28) exists of draft-ietf-spring-srv6-network-programming-05 Summary: 2 errors (**), 0 flaws (~~), 4 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 Intended status: Standards Track L. Geng 5 Expires: June 13, 2020 China Mobile 6 M. McBride 7 Futurewei 8 R. Asati 9 Cisco 10 S. Dhanaraj 11 Huawei 12 December 11, 2019 14 Encapsulation for BIER in Non-MPLS IPv6 Networks 15 draft-xie-bier-ipv6-encapsulation-04 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. 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 June 13, 2020. 47 Copyright Notice 49 Copyright (c) 2019 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 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 84 9.2. Informative References . . . . . . . . . . . . . . . . . 17 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 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 0 upon transmission, and MUST be ignored 196 upon reception. The function of TTL is replaced by the Hop 197 Limit field in IPv6 header. 199 Nibble: SHOULD be set to 0000 upon transmission, and MUST be 200 ignored upon reception. See Section 2.2 of RFC 8296. 202 Ver: MUST be set to 0 upon transmission, and MUST be discarded 203 when it is not 0 upon reception. See Section 2.2 of RFC 8296. 205 BSL: See Section 2.1.2 of RFC 8296. 207 Entropy: See Section 2.1.2 of RFC 8296. 209 OAM: See Section 2.1.2 of RFC 8296. 211 Rsv: See Section 2.1.2 of RFC 8296. 213 DSCP: SHOULD be set to binary value 000000 upon transmission and 214 MUST be ignored upon reception. In IPv6 BIER encapsulation, 215 uses highest 6-bit of Traffic Class field of IPv6 header to hold 216 a Differentiated Services Codepoint [RFC2474]. 218 Proto: SHOULD be set to 0 upon transmission and MUST be ignored 219 upon reception. In IPv6 BIER encapsulation, the functionality 220 of this 6-bit Proto field is replaced by the Next Header field 221 in Destination Options header, which is the last IPv6 extension 222 header, to indicate the BIER payload, which is also IPv6 223 payload. 225 For BIER Proto 1, indicating a Downstream-assigned MPLS 226 payload, use Next Header value 137. 228 For BIER Proto 2, indicating an Upstream-assigned MPLS 229 payload, there is no Next Header code currently. An 230 upstream-assigned MPLS label within the context of special 231 BFIR router, which in turn is represented by the BFIR-id and 232 the Sub-domain indirectly indicated by the BIFT-id in a BIER- 233 MPLS or BIER-ETH packet, can be replaced by an IPv6 source 234 address in a BIER IPv6 encapsulation packet in a direct 235 manner. In this case, use Next Header value 4 for IPv4 236 payload, or value 41 for IPv6 payload. 238 For BIER Proto 3, indicating an Ethernet payload, use Next 239 Header value 97. 241 For BIER Proto 4, indicating an IPv4 payload, use Next Header 242 value 4. 244 For BIER Proto 5, indicating a BIER-OAM payload, use Next 245 Header value 58. How the BIER-PING is supported with BIER 246 IPv6 encapsulation is outside the scope of this document. 248 For BIER Proto 6, indicating an IPv6 payload, use Next Header 249 value 41. 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 the IPv6 BFR-Prefix advertised from this BFR. When a BFR advertises 281 the BIER information with BIERv6 encapsulation capability, the IPv6 282 BFR-prefix of this BFR MUST be selected specifically for BIERv6 283 packet forwarding. Locally this "BIER Specific" IPv6 address is 284 initialized in FIB with a flag of "BIER specific handling", 285 represented as End.BIER function. For convenience, the indication in 286 FIB share the same space as SRv6 Endpoints Behaviors defined in 287 [I-D.ietf-spring-srv6-network-programming]. Apart from this sharing 288 of code space, there is nothing dependent on SRv6. The co-existance 289 of BIERv6 and SRv6 is outside the scope of this document. 291 BFR Prefix is used only in control plane in BIER MPLS encapsulation 292 but not used in data plane. While in BIERv6, BFR prefix is used in 293 both control plane and data plane. For the convinence of migration 294 to BIERv6, it is RECOMMENDED to use an "exclusive" IPv6 address as 295 BFR prefix when deploying BIER-MPLS in IPv6 networks. The 296 "exclusive" IPv6 address should not be used for general purpose like 297 BGP session establishment, but for "BIER specific" function. For 298 Non-BIER IPv6 routers, the IPv6 address is a regular IPv6 prefix 299 reachable through IPv6 unicast routing. 301 The following is an example of configuring a BIER specific IPv6 302 address and using this address as BFR prefix: 304 # Config a BIER specific IPv6 address with 128-bit mask on loopback0. 305 interface loopback0 306 ipv6 address 2001:DB8::AB37 128 End.BIER 308 # Config the BIER-specific IPv6 address on loopback0 as BFR Prefix. 309 bier sub-domain 6 ipv6-underlay 310 bfr-prefix interface loopback0 312 The address used as "BIER specific" IPv6 address can be from inside 313 the scope of an SRv6 Locator or outside the scope of the SRv6 314 Locator(s) since it is a host prefix (128-bit prefix-length prefix). 316 Each "BIER specific" address can be used in one or many sub-domains 317 as BFR-prefix, such that it can be associated with one or many Multi- 318 Topologies (MTs) or algorithms. 320 More than one "BIER specific" address are also allowed as different 321 BFR-prefix of more than one sub-domain, as described in section 2 of 322 [RFC8279]. 324 The following is an example pseudo-code of the End.BIER function: 326 1. IF NH = 60 and HopLimit > 0 ;;Ref1 327 2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2 328 3. Lookup the BIER Header inside the BIER option TLV. 329 4. Forward via the matched entry. 330 5. ELSE ;;Ref3 331 6. Drop the packet and end the process. 332 7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4 333 8. Send to CPU. 334 9. ELSE ;;Ref5 335 10. Drop the packet. 337 Ref1: Destination options header follows the IPv6 header directly and 338 HopLimit is bigger than zero. 340 Ref2: The first TLV is BIER type and is the only TLV present in 341 Destination options header. 343 Ref3/Ref5: Undesired packet is droped because the destination address 344 is the BIER specific IPv6 address (End.BIER function). 346 Ref4: An ICMPv6 packet using End.BIER as destination address. 348 3.3. BIERv6 Packet Format 350 As a multicast packet enters the BIER domain in a Non-MPLS IPv6 351 network, the multicast packet will be encapsulated with BIERv6 352 Header. 354 Typically a BIERv6 header would contain the Destination Options 355 Header as the only Extensions Header besides IPv6 Header. However, 356 it is allowed and possible for other extension headers to appear 357 along with the Destination Options Header as long as the requirements 358 listed in section 3.1 of this document is met. 360 Format of the multicast packet with BIERv6 encapsulation carrying 361 only the Destination Options header is depicted in the below figure. 363 +---------------+--------------+------------ 364 | IPv6 header | Dest Options | X type of 365 | | Header with | multicast 366 | | BIER Option | packet 367 | | | 368 | Next Hdr = 60 | Nxt Hdr = X | 369 +---------------+--------------+------------ 371 Format of the multicast packet with BIERv6 encapsulation carrying 372 other extension headers along with Destination Options extension 373 header is required to follow general recommendations of [RFC8200] and 374 examples in other RFCs. [RFC6275] introduces how the order should be 375 when other extension headers carries along with Home address option 376 in a destination options header. Similar to this example, this 377 document requires the Destination Options Header carrying the BIER 378 option MUST be placed as follows: 380 o After the routing header, if that header is present 382 o Before the Fragment Header, if that header is present 384 o Before the AH Header or ESP Header, if either one of those headers 385 is present 387 Source Address field in the IPv6 header MUST be a routable IPv6 388 unicast address of the BFIR in any case. 390 BFIR encodes the Non-MPLS BIER header in the above mentioned 391 encapsulation format and forwards the BIERv6 packet to the nexthop 392 BFR following the local BIFT table. 394 BFRs in the IPv6 network, processes and replicates the packets 395 towards the BFERs using the local BIFT table. The bit-string field 396 in the Non-MPLS BIER header may be changed by the BFRs as they 397 replicate the packet. BFRs MUST follow the procedures defined in 398 section 3.1 as they modify the other fields in the Non-MPLS BIER 399 header. The source address in the IPv6 header MUST NOT be modified 400 by the BFRs. 402 4. BIERv6 Packet Processing 404 There is no BIER-specific processing, and all the 8 steps in section 405 6.5 of RFC8279 apply to BIERv6 packet processing. However, there are 406 some IPv6-specific processing procedures due to the base and general 407 procedures of IPv6. 409 On the overlay layer, when a multicast packet enters the BIER domain 410 in a Non-MPLS IPv6 network, the Ingress BFR (BFIR) encapsulates the 411 multicast packet with a BIERv6 Header, transforming it to a BIERv6 412 packet. The BIERv6 header includes an IPv6 header and IPv6 413 Destination Options Header within a standard Non-MPLS BIER header. 414 Source Address field in the IPv6 header MUST be set to a routable 415 IPv6 unicast address of the BFIR. Destination Address field in the 416 IPv6 header is set to the BFR prefix of the next-hop BFR the BIERv6 417 packet replicating to, no matter next-hop BFR is directly connected 418 (one-hop) or not directly connected (multi-hop). 420 On the BIER layer, upon receiving an BIERv6 packet, the BFR processes 421 the IPv6 header first. This is the general procedure of IPv6. 423 If the IPv6 Destination address is an IPv6 BFR-Prefix unicast address 424 of this BFR, a 'BIER Specific Handling' indication will be obtained 425 by the preceding Unicast DA lookup (FIB lookup). The BIER option, if 426 exists, will be checked to decide which neighbor(s) to replicate the 427 BIERv6 packet to. 429 It is a local behavior to handle the combination of extension 430 headers, options and the BIER option(s) in destination options header 431 when a 'BIER Specific Handling' indication is got by the preceding 432 FIB lookup. Early deployment of BIERv6 may require there is only one 433 BIER option TLV in the destination options header followed the IPv6 434 header. How other extension headers or more BIER option TLVs in a 435 BIERv6 packet is handled is outside the scope of this document. 437 A packet having a 'BIER Specific Handling' indication but not having 438 a BIER option is supposed to be a wrong packet or an ICMPv6 packet, 439 and the process can be refered to the example in section 3.2. 441 A packet not having a 'BIER Specific Handling' indication but having 442 a BIER option SHOULD be processed normally as unicast forwarding 443 procedures, which may be a behavior of drop, or send to CPU, or other 444 behaviors in existing implementations. 446 The Destination Address field in the IPv6 Header MUST change to the 447 nexthop BFR's BFR Prefix if Unicast address is used in BIERv6. 449 The Hop Limit field of IPv6 header MUST decrease by 1 when sending 450 packets to a BFR neighbor, while the TTL in the BIER header MUST be 451 unchanged. 453 The BitString in the BIER header in the Destination Options Header 454 may change when sending packets to a neighbor. Such change of 455 BitString MUST be aligned with the procedure defined in RFC8279. 456 Because of the requirement to change the content of the option when 457 forwarding BIERv6 packet, the BIER option type should have chg flag 1 458 per section 4.2 of RFC8200. 460 The procedures applies normally if a bit corresponding to the self 461 bfr-id is set in the bit-string field of the Non-MPLS BIER header of 462 the BIERv6 packet. The node is considered to be an Egress BFR (BFER) 463 in this case. The BFER removes the BIERv6 header, including the IPv6 464 header and the Destination Options header, and copies the packet to 465 the multicast flow overlay. The egress VRF of a packet may be 466 determined by a further lookup on the IPv6 source address instead of 467 the upstream-assigned MPLS Label as described in [RFC8556]. 469 The Fragment Header, AH Header or ESP Header, if exists after the 470 BIER options header, can be processed on BFER only as part of the 471 multicast flow overlay process. 473 5. Security Considerations 475 BIER IPv6 encapsulation provides a new encapsulation based on IPv6 476 and BIER to transport multicast data packet in a BIER domain. The 477 BIER domain can be a single IGP area, an anonymous system (AS) with 478 multiple IGP areas, or multiple anonymous systems (ASes) operated by 479 a network operator. This section reviews security considerations 480 related to the BIER IPv6 encapsulation, based on security 481 considerations of [RFC8279], [RFC8296], and other documents related 482 to IPv6 extension. 484 BIER-encapsulated packets should generally not be accepted from 485 untrusted interfaces or tunnels. For example, an operator may wish 486 to have a policy of accepting BIER-encapsulated packets only from 487 interfaces to trusted routers, and not from customer-facing 488 interfaces. See section 5.1 for normal Intra domain deployment. 490 There may be applications that require a BFR to accept a BIER- 491 encapsulated packet from an interface to a system that is not 492 controlled by the network operator. See section 5.2 for inter domain 493 deployment. 495 BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause 496 security problems. See section 5.3 for ICMP related problems. 498 This document introduces a new option used in IPv6 Destination 499 Options Header, together with the special-use IPv6 address called 500 End.BIER in IPv6 destination address for BIER IPv6 forwarding. 501 However the option newly introduced may be wrongly used with normal 502 IPv6 destination address. See section 5.4 for problems introduced by 503 the new IPv6 option with normal IPv6 destination address. 505 If a BIER packet is altered, either the BIER header, or the multicast 506 data packet, by an intermediate router, packets may be lost, stolen, 507 or otherwise misdelivered. BIER IPv6 encapsulation provides the 508 ability of IPsec to ensure the confidentiality or integrity. See 509 section 5.5 for this security problem. 511 A BIER router accepts and uses the End.BIER IPv6 address to construct 512 BIFT only when the IPv6 address is configured explicitly, or received 513 from a router via control-plane protocols. The received information 514 is validated using existing authentication and security mechanisms of 515 the control-plane protocols. BIER IPv6 encapsulation does not define 516 any additional security mechanism in existing control-plane 517 protocols, and it inherits any security considerations that apply to 518 the control-plane protocols. 520 5.1. Intra Domain Deployment 522 Generally nodes outside the BIER Domain are not trusted: they cannot 523 directly use the End.BIER of the domain. This is enforced by two 524 levels of access control lists: 526 1. Any packet entering the BIER Domain and destined to an End.BIER 527 IPv6 Address within the BIER Domain is dropped. This may be realized 528 with the following logic. Other methods with equivalent outcome are 529 considered compliant: 531 * allocate all the End.BIER IPv6 Address from a block S/s 533 * configure each external interface of each edge node of the domain 534 with an inbound infrastructure access list (IACL) which drops any 535 incoming packet with a destination address in S/s 537 * Failure to implement this method of ingress filtering exposes the 538 BIER Domain to BIER attacks as described and referenced in [RFC8296]. 540 2. The distributed protection in #1 is complemented with per node 541 protection, dropping packets to End.BIER IPv6 Address from source 542 addresses outside the BIER Domain. This may be realized with the 543 following logic. Other methods with equivalent outcome are 544 considered compliant: 546 * assign all interface addresses from prefix A/a 548 * assign all the IPv6 addresses used as source address of BIER IPv6 549 packets from a block B/b 551 * at node k, all End.BIER IPv6 addresses local to k are assigned from 552 prefix Sk/sk 554 * configure each internal interface of each BIER node k in the BIER 555 Domain with an inbound IACL which drops any incoming packet with a 556 destination address in Sk/sk if the source address is not in A/a or 557 B/b. 559 For simplicity of deployment, a configuration of IACL effective for 560 all interfaces can be provided by a router. Such IACL can be 561 referred to as global IACL(GIACL) .Each BIER node k then simply 562 configs a GIACL which drops any incoming packet with a destination 563 address in Sk/sk if the source address is not in A/a or B/b for the 564 inter-domain deployment mode. 566 5.2. Inter Domain Deployment 568 There may be applications that require a BFR to accept a BIER- 569 encapsulated packet from an interface to a system that is not 570 controlled by the network operator. For instance, there may be an 571 application in which a virtual machine in a data center submits BIER- 572 encapsulated packets to a router. In such a case, it is desirable to 573 verify that the packet is from a legitimate source and that its 574 BitString denotes only systems to which that source is allowed to 575 send. Using BIER IPv6 encapsulation, IACL can be configured on each 576 internal interface of each BIER node k to allow packet with a 577 destination address in Sk/sk and the source address is in an allowed 578 list of IPv6 address. However, the BIER IPv6 encapsulation itself 579 does not provide a way to verify that the source is legitimate or the 580 source is allowed to set any particular set of bits in the BitString. 582 The IACL allowing specific IPv6 address outside the domain of a 583 network operator can be more strict by the following method: 585 * configure one sub-domain using only one bit string length, and a 586 seperate End.BIER for this sub-domain as a service opened to agreed 587 source(s) outside the domain of the operator's network. 589 * configure on BIER node to check if the End.BIER address of a packet 590 is the correct one bound to the sub-domain of a packet. 592 * configure IACL on each interface of each BIER node k (or simply 593 configure GIACL on each BIER node k) to allow packet with an End.BIER 594 as destination address and the allowed source(s) as source address. 596 This provides a way to ensure that the inter-domain source is allowed 597 to access only the BIER IPv6 transport service bound to a sub-domain 598 with a specific bit string length. 600 5.3. ICMP Error Processing 602 ICMP error packets generated within the BIER Domain are sent to 603 source nodes within the BIER Domain. 605 A large number of ICMP may be elicited and sent to a BFIR router, in 606 case when a BIER IPv6 packet is filled with wrong TTL, either error 607 or malfeasance. A rate-limiting of ICMP packet should be implemented 608 on each BFR. 610 The ingress node can take note of the fact that it is getting, in 611 response to BIER IPv6 packet, one or more ICMP error packets. By 612 default, the reception of such a packets MUST be countered and 613 logged. However, it is possible for such log entries to be "false 614 positives" that generate a lot of "noise" in the log; therefore, 615 implementations SHOULD have a knob to disable this logging. 617 OAM functions of PING and TRACE for BIER IPv6 encapsulation may also 618 need ICMP based on BIER IPv6 encapsulation and cause ICMP response 619 message containing BIER option. The ability of seperating such OAM 620 ICMP packets from error ICMP packets caused by error is necessary for 621 the availability of OAM, otherwise the OAM function may fail due to 622 the rate-limiting of ICMP error packets. 624 5.4. Security caused by BIER option 626 This document introduces a new option used in IPv6 Destination 627 Options Header. An IPv6 packet with a normal IPv6 address of a 628 router (e.g. loopback IPv6 address of the router) as destination 629 address will possibly carry a BIER option. 631 For a router incapable of BIERv6, such BIERv6 packet will not be 632 processed by the procedure described in this document, but be 633 processed as normal IPv6 packet with unknown option, and the existing 634 security considerations for handling IPv6 options apply. Possible 635 way of handling IPv6 packets with BIER option may be send to CPU for 636 slow path processing, with rate-limiting, or be discarded according 637 to the local policy. 639 For a router capable of BIERv6, such BIERv6 packet MUST NOT be 640 forwarded, but should be processed as a normal IPv6 packet with 641 unknown option, or additionally and optionally be countered and 642 logged if the router is capable of doing so. 644 5.5. Applicability of IPsec 646 IPsec [RFC4301] uses two protocols to provide traffic security 647 services -- Authentication Header (AH) [RFC4302] and Encapsulating 648 Security Payload (ESP) [RFC4303]. Each protocol supports two modes 649 of use: transport mode and tunnel mode. IPsec support both unicast 650 and multicast. IPsec implementations MUST support ESP and MAY 651 support AH. 653 This document assume IPsec working in tunnel mode with inner IPv4 or 654 IPv6 multicast packet encapsulated in outer BIERv6 header and IPsec 655 header(s). 657 IPsec used with BIER IPv6 encapsulation to ensure that a BIER payload 658 is not altered while in transit between BFIR and BFERs. If a BFR in 659 between BFIR and BFERs is compromised, there is no way to prevent the 660 compromised BFR from making illegitimate modifications to the BIER 661 payload or to prevent it from misforwarding or misdelivering the 662 BIER-encapsulated packet, but the BFERs will detect the illegitimate 663 modifications to the BIER Payload (or the inner multicast data 664 packet). This could provide cryptographic integrity protection for 665 multicast data transport. This capability of IPsec comes from the 666 design that, the destination options header carrying the BIER header 667 is located before the AH or ESP and the BFR routers in between BFIR 668 and BFERs can process the BIER header without aware of AH or ESP. 670 For ESP, the Integrity Check Value (ICV) is computed over the ESP 671 header, Payload, and ESP trailer fields. It doesn't require the IP 672 or extension header for ICV calculating, and thus the change of DA 673 and BIER option data does not affect the function of ESP. 675 For AH, the Integrity Check Value (ICV) is computed over the IP or 676 extension header fields before the AH header, the AH header, and the 677 Payload. The IPv6 DA is immutable for unicast traffic in AH, and the 678 change of DA in BIER IPv6 forwarding for multicast traffic is 679 incompatible to this rule. How AH is extended to support multicast 680 traffic transporting through BIER IPv6 encapsulation is outside the 681 scope of this document. 683 The detailed control-plane for BIER IPv6 encapsulation IPsec function 684 is outside the scope of the document. Internet Key Exchange Protocol 685 Version 2 (IKEv2) [RFC5996] and Group Security Association (GSA) 686 [RFC5374] can be referred to for further studying. 688 6. IANA Considerations 690 6.1. BIER Option Type 692 Allocation is expected from IANA for a BIER Option Type codepoint 693 from the "Destination Options and Hop-by-Hop Options" sub-registry of 694 the "Internet Protocol Version 6 (IPv6) Parameters" registry. The 695 value 0x70 is suggested. 697 +-----------+-----+-----+-------+-------------+------------+ 698 | Hex Value | act | chg | rest | Description | Reference | 699 +-----------+-----+-----+-------+-------------+------------+ 700 | 0x70 | 01 | 1 | 10000 | BIER Option | This draft | 701 +-----------+-----+-----+-------+-------------+------------+ 703 6.2. End.BIER Function 705 Allocation is expected from IANA for an End.BIER function codepoint 706 from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is 707 suggested. 709 +-------+--------+--------------------------+------------+ 710 | Value | Hex | Endpoint function | Reference | 711 +-------+--------+--------------------------+------------+ 712 | TBD | TBD | End.BIER | This draft | 713 +-------+--------+--------------------------+------------+ 715 7. Acknowledgements 717 The authors would like to thank Stig Venaas for his valuable 718 comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda, 719 Toerless Eckert, Jeffrey Zhang for the helpful comments to improve 720 this document. 722 8. Contributors 724 Gang Yan 726 Huawei Technologies 728 China 730 Email: yangang@huawei.com 732 Yang(Yolanda) Xia 734 Huawei Technologies 736 China 738 Email: yolanda.xia@huawei.com 740 9. References 742 9.1. Normative References 744 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 745 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 746 December 2005, . 748 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 749 DOI 10.17487/RFC4302, December 2005, 750 . 752 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 753 RFC 4303, DOI 10.17487/RFC4303, December 2005, 754 . 756 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 757 Extensions to the Security Architecture for the Internet 758 Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, 759 . 761 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 762 "Internet Key Exchange Protocol Version 2 (IKEv2)", 763 RFC 5996, DOI 10.17487/RFC5996, September 2010, 764 . 766 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 767 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 768 2011, . 770 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 771 (IPv6) Specification", STD 86, RFC 8200, 772 DOI 10.17487/RFC8200, July 2017, 773 . 775 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 776 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 777 Explicit Replication (BIER)", RFC 8279, 778 DOI 10.17487/RFC8279, November 2017, 779 . 781 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 782 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 783 for Bit Index Explicit Replication (BIER) in MPLS and Non- 784 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 785 2018, . 787 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 788 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 789 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 790 2019, . 792 9.2. Informative References 794 [I-D.ietf-bier-ipv6-requirements] 795 McBride, M., Xie, J., Dhanaraj, S., and R. Asati, "BIER 796 IPv6 Requirements", draft-ietf-bier-ipv6-requirements-03 797 (work in progress), November 2019. 799 [I-D.ietf-spring-srv6-network-programming] 800 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 801 Matsushima, S., and Z. Li, "SRv6 Network Programming", 802 draft-ietf-spring-srv6-network-programming-05 (work in 803 progress), October 2019. 805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 806 Requirement Levels", BCP 14, RFC 2119, 807 DOI 10.17487/RFC2119, March 1997, 808 . 810 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 811 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 812 May 2017, . 814 Authors' Addresses 816 Jingrong Xie 817 Huawei Technologies 819 Email: xiejingrong@huawei.com 821 Liang Geng 822 China Mobile 823 Beijing 10053 825 Email: gengliang@chinamobile.com 827 Mike McBride 828 Futurewei 830 Email: mmcbride7@gmail.com 832 Rajiv Asati 833 Cisco 835 Email: rajiva@cisco.com 837 Senthil Dhanaraj 838 Huawei 840 Email: senthil.dhanaraj@huawei.com