idnits 2.17.1 draft-xie-bier-ipv6-encapsulation-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2020) is 1381 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-geng-bier-ipv6-inter-domain-01 == Outdated reference: A later version (-09) exists of draft-ietf-bier-ipv6-requirements-05 == Outdated reference: A later version (-13) exists of draft-ietf-bier-ping-07 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-16 == Outdated reference: A later version (-02) exists of draft-xie-bier-ipv6-isis-extension-01 == Outdated reference: A later version (-03) exists of draft-xie-bier-ipv6-mvpn-02 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei Technologies 4 Updates: 8296 (if approved) L. Geng 5 Intended status: Standards Track China Mobile 6 Expires: January 14, 2021 M. McBride 7 Futurewei 8 R. Asati 9 Cisco 10 S. Dhanaraj 11 Huawei 12 Y. Zhu 13 China Telecom 14 Z. Qin 15 China Unicom 16 M. Shin 17 LG Uplus 18 G. Mishra 19 Verizon Inc. 20 X. Geng 21 Huawei 22 July 13, 2020 24 Encapsulation for BIER in Non-MPLS IPv6 Networks 25 draft-xie-bier-ipv6-encapsulation-08 27 Abstract 29 This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- 30 MPLS IPv6 Networks using the IPv6 Destination Option extension 31 header. This document updates RFC 8296. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in [RFC2119] and 38 [RFC8174]. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at https://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on January 14, 2021. 57 Copyright Notice 59 Copyright (c) 2020 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (https://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 4 77 3.1. BIER Option in IPv6 Destination Options Header . . . . . 4 78 3.2. Destination Address in BIERv6 Encapsulation . . . . . . . 6 79 3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8 80 4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 12 83 5.2. ICMP Error Processing . . . . . . . . . . . . . . . . . . 13 84 5.3. Security caused by BIER option . . . . . . . . . . . . . 13 85 5.4. Applicability of IPsec . . . . . . . . . . . . . . . . . 14 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 15 88 6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 90 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 93 9.2. Informative References . . . . . . . . . . . . . . . . . 17 94 Appendix A. Relationship to BIER Core Standards . . . . . . . . 18 95 Appendix B. Extensions to BIER Control-plane Standards . . . . . 19 96 Appendix C. Considerations of Using Unicast Address . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 102 that provides optimal multicast forwarding without requiring 103 intermediate routers to maintain any per-flow state by using a 104 multicast-specific BIER header. 106 [RFC8296] defines a common BIER Header format for MPLS and Non-MPLS 107 networks. It has defined two types of encapsulation methods using 108 the common BIER Header, (1) BIER encapsulation in MPLS networks, 109 here-in after referred as MPLS BIER Header in this document and (2) 110 BIER encapsulation in Non-MPLS networks, here-in after referred as 111 Non-MPLS BIER Header in this document. [RFC8296] also assigned 112 Ethertype=0xAB37 for Non-MPLS BIER Header packets to be directly 113 carried over the Ethernet links. 115 This document proposes a BIER IPv6 encapsulation for Non-MPLS IPv6 116 Networks, defining a method to carry the standard Non-MPLS BIER 117 header (as defined in [RFC8296]) in the native IPv6 header. A new 118 IPv6 Option type - BIER Option is defined to encode the standard Non- 119 MPLS BIER header and this newly defined BIER Option is carried under 120 the Destination Options header of the native IPv6 Header [RFC8200]. 122 The relationship of this document to BIER core standards is listed in 123 Appendix A. 125 The relevant extensions to BIER Control-plane Standards are listed in 126 Appendix B. 128 2. Terminology 130 Readers of this document are assumed to be familiar with the 131 terminology and concepts of the documents listed as Normative 132 References. 134 The following new terms are used throughout this document: 136 o BIERv6 - Bit indexed explicit replication using IPv6 data plane. 138 o BIERv6 Domain - A limited-domain using BIERv6 encapsulation as 139 specified in this document for transporting customer multicast 140 packets from one router to multiple destination routers. It is 141 usually managed by a single administrative entity, e.g., a 142 service-provider. It could be a single AS network or a large- 143 scale network that includes multiple ASes. BIER Domain is also 144 used for the same meaning as BIERv6 domain in this document. 146 o BIERv6 Option - An Option type carried in IPv6 Destination Options 147 Header (DO header, DOH) which includes the standard Non-MPLS BIER 148 Header. It is in type-length-value (TLV) format. The value 149 portion of the BIERv6 Option TLV, or the BIERv6 Option Data, is in 150 the format of the standard Non-MPLS BIER header. BIER option is 151 also used for the same meaning as BIERv6 option in this document. 153 o BIERv6 Header - An IPv6 Header with BIER Option. 155 o BIERv6 Packet - An IPv6 packet with BIERv6 Header. An IP/IPv6/ 156 Ethernet multicast packet is encapsulated with an outside BIERv6 157 header and transformed to a BIERv6 packet on the ingress PE 158 (BFIR). BIERv6 packet is transported by the transit routers 159 (BFRs) through a BIERv6 domain towards egress PEs(BFERs). BIERv6 160 packet is decapsulated by the BFERs, with the original IP/IPv6/ 161 Ethernet multicast packet being obtained and forwarded towards the 162 multicast receivers . 164 3. BIER IPv6 Encapsulation 166 3.1. BIER Option in IPv6 Destination Options Header 168 Destination Options Header and the Options that can be carried under 169 this extension header is defined in [RFC8200]. This document defines 170 a new Option type - BIER Option, to encode the Non-MPLS BIER header. 171 As specified in Section 4.2 [RFC8200], the BIER Option follows type- 172 length-value (TLV) encoding format and the standard Non-MPLS BIER 173 header [RFC8296] is encoded in the value portion of the BIER Option 174 TLV. 176 This BIER Option MUST be carried only inside the IPv6 Destination 177 Options header and MUST NOT be carried under the Hop-by-Hop Options 178 header. 180 The BIER Option is encoded in type-length-value (TLV) format as 181 follows: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Next Header | Hdr Ext Len | Option Type | Option Length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | | 189 ~ BIERv6 Option Data (Non-MPLS BIER Header defined in RFC8296) ~ 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Next Header 8-bit selector. Identifies the type of header 194 immediately following the Destination Options header. 196 Hdr Ext Len 8-bit unsigned integer. Length of the Destination 197 Options header in 8-octet units, not including the first 8 octets. 199 Option Type To be allocated by IANA. See section 6. 201 Option Length 8-bit unsigned integer. Length of the option, in 202 octets, excluding the Option Type and Option Length fields. 204 BIERv6 Option Data The BIERv6 Option Data contains the Non-MPLS BIER 205 Header defined in RFC8296. Fields in the Non-MPLS BIER Header 206 MUST be encoded as below. 208 BIFT-id: The BIFT-id is a domain-wide unique value in Non-MPLS 209 IPv6 encapsulation. See Section 2.2 of RFC 8296. 211 TC: SHOULD be set to binary value 000 upon transmission and MUST 212 be ignored upon. See Section 2.2 of RFC 8296. 214 S bit: SHOULD be set to 1 upon transmission, and MUST be ignored 215 upon reception. See Section 2.2 of RFC 8296. 217 TTL: MUST be set to a value larger than 0 upon encapsulation, 218 and SHOULD decrease by 1 by a BFR when forwarding a BIERv6 219 packet to a BFR adjacency. If the incoming TTL is 0, the packet 220 is considered to be "expired". See Section 2.1.1.2 of RFC 8296. 222 Nibble: SHOULD be set to 0000 upon transmission, and MUST be 223 ignored upon reception. See Section 2.2 of RFC 8296. 225 Ver: MUST be set to 0 upon transmission, and MUST be discarded 226 when it is not 0 upon reception. See Section 2.2 of RFC 8296. 228 BSL: See Section 2.1.2 of RFC 8296. 230 Entropy: See Section 2.1.2 of RFC 8296. 232 OAM: See Section 2.1.2 of RFC 8296. 234 Rsv: See Section 2.1.2 of RFC 8296. 236 DSCP: SHOULD be set to binary value 000000 upon transmission and 237 MUST be ignored upon reception. In BIERv6 encapsulation, uses 238 Traffic Class field of IPv6 header instead. 240 Proto: SHOULD be set to 0 upon transmission and be ignored upon 241 reception. In BIERv6 encapsulation, the functionality of this 242 6-bit Proto field is replaced by the Next Header field in 243 Destination Options header or the last IPv6 extension header to 244 indicate the type of the payload. This updates section 2.1.2 of 245 [RFC8296] about Proto definition. Next Header value in BIERv6 246 encapsulation for common usage includes: 248 Value 4 for IPv4 packet as BIERv6 payload. 250 Value 41 for IPv6 packet as BIERv6 payload. 252 Value 143 for Ethernet packet as BIERv6 payload. 254 Multicast VPN (MVPN) service is considered as part of the BIER 255 layering mode defined in [RFC8279], and should be supported by 256 BIERv6 encapsulation. [I-D.xie-bier-ipv6-mvpn] illustrates how 257 MVPN is supported in BIERv6 encapsulation without using this 258 Proto field. 260 BIER-PING [I-D.ietf-bier-ping] is considered a useful function 261 of the BIER architecture, and should be supported by BIERv6 262 encapsulation. How BIER-PING is supported in BIERv6 263 encapsulation without using this Proto field is outside the 264 scope of this document. 266 BFIR-id: See Section 2.1.2 of RFC 8296. 268 BitString: See Section 2.1.2 of RFC 8296. 270 3.2. Destination Address in BIERv6 Encapsulation 272 When a BIERv6 packet is replicated to a next hop BFR, an unicast 273 address of the next hop BFR is used as the destination address of the 274 BIERv6 packet. Considerations of using unicast (or multicast) 275 address is listed in Appendix C. 277 The unicast address used in BIERv6 packet targeting a BFR SHOULD be 278 advertised as part of the BIER IPv6 Encapsulation. When a BFR 279 advertises the BIER information with BIERv6 encapsulation capability, 280 an IPv6 unicast address of this BFR MUST be selected specifically for 281 BIERv6 packet forwarding. Locally this "BIER Specific" IPv6 address 282 is initialized in FIB with a flag of "BIER specific handling", 283 represented as End.BIER function. 285 If a BFR belongs to more than one sub-domain, it may (though it need 286 not) have a different End.BIER in each sub-domain. If different 287 End.BIER is used for each sub-domain, implementation SHOULD support 288 verifying the DA of a BIERv6 packet is the End.BIER address bound by 289 the sub-domain of the packet. 291 For security deployment of BIERv6, the End.BIER address(es) is 292 required to be allocated from an IPv6 address block, and the IPv6 293 address block is used for domain boundary security policy. See 294 section 5.1 of this document for such security policy. Such kind of 295 security policy using IPv6 address block follows the paradigm settled 296 by the [RFC8754] section 5. 298 Deployment of BIERv6 in SRv6 network is allowed. In this case, the 299 BIERv6 domain is the same as SRv6 domain, and the End.BIER address is 300 allocated from the locator of SRv6. 302 To better understand the configuration mode of End.BIER address in 303 BIERv6, [I-D.geng-bier-bierv6-yang] could be referenced. 305 For the convenience of such co-existence of BIERv6 and SRv6, the 306 indication of End.BIER or "BIER specific handling" in FIB shares the 307 same space as SRv6 Endpoints Behaviors defined in 308 [I-D.ietf-spring-srv6-network-programming]. 310 The following is an example pseudo-code of the End.BIER function: 312 1. IF NH = 60 and HopLimit > 0 ;;Ref1 313 2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2 314 3. Lookup the BIER Header inside the BIER option TLV. 315 4. Forward via the matched entry. 316 5. ELSE ;;Ref3 317 6. Drop the packet and end the process. 318 7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4 319 8. Send to CPU. 320 9. ELSE ;;Ref5 321 10. Drop the packet. 323 Ref1: Destination options header follows the IPv6 header directly and 324 HopLimit is bigger than zero. 326 Ref2: The first TLV is BIER type and is the only TLV present in 327 Destination options header. 329 Ref3/Ref5: Undesired packet is droped because the destination address 330 is the BIER specific IPv6 address (End.BIER function). 332 Ref4: An ICMPv6 packet using End.BIER as destination address. 334 3.3. BIERv6 Packet Format 336 As a multicast packet enters the BIER domain in a Non-MPLS IPv6 337 network, the multicast packet will be encapsulated with BIERv6 Header 338 by the Ingress BFR (BFIR). 340 Typically a BIERv6 header would contain the Destination Options 341 Header as the only Extensions Header besides IPv6 Header, as depicted 342 in the below figure. 344 +---------------+------------------+----------------------+ 345 | IPv6 header | IPv6 DO Header | X type of | 346 | | with BIER Option | C-multicast packet | 347 | | | | 348 | Next Hdr = 60 | Nxt Hdr = X | (IPv4/IPv6/Ethernet) | 349 +---------------+------------------+----------------------+ 350 | | | 351 |<----------BIERv6 header--------->|<---BIERv6 payload--->| 353 Format of the multicast packet with BIERv6 encapsulation carrying 354 other extension headers along with Destination Options extension 355 header is required to follow general recommendations of [RFC8200] and 356 examples in other RFCs. [RFC6275] introduces how the order should be 357 when other extension headers carries along with Home address option 358 in a destination options header. Similar to this example, this 359 document requires the Destination Options Header carrying the BIER 360 option MUST be placed as follows: 362 o After the routing header, if that header is present 364 o Before the Fragment Header, if that header is present 366 o Before the AH Header or ESP Header, if either one of those headers 367 is present 369 Source Address field in the IPv6 header MUST be a routable IPv6 370 unicast address of the BFIR in any case. 372 BFIR encodes the BIERv6 header in the above mentioned encapsulation 373 format and forwards the BIERv6 packet to the nexthop BFR following 374 the local BIFT table. 376 BFRs in the IPv6 network, processes and replicates the packets 377 towards the BFERs using the local BIFT table. The BitString field in 378 the BIERv6 Option Data may be changed by the BFRs as they replicate 379 the packet. BFRs MUST follow the procedures defined in section 3.1 380 as they modify the other fields in the BIERv6 Option Data. The 381 source address in the IPv6 header MUST NOT be modified by the BFRs. 383 4. BIERv6 Packet Processing 385 When a multicast packet enters the BIER domain, the Ingress BFR 386 (BFIR) encapsulates the multicast packet with a BIERv6 Header, 387 transforming it to a BIERv6 packet. The BIERv6 header includes an 388 IPv6 header and a BIERv6 Option in IPv6 Destination Options Header. 389 Source Address field in the IPv6 header MUST be set to a routable 390 IPv6 unicast address of the BFIR. Destination Address field in the 391 IPv6 header is set to the End.BIER address of the next-hop BFR the 392 BIERv6 packet replicating to, no matter next-hop BFR is directly 393 connected (one-hop) or not directly connected (multi-hop). 395 Upon receiving an BIERv6 packet, the BFR processes the IPv6 header 396 first. This is the general procedure of IPv6. 398 If the IPv6 Destination address is an End.BIER IPv6 unicast address 399 of this BFR, a 'BIER Specific Handling' indication will be obtained 400 by the preceding Unicast DA lookup (FIB lookup). The BIER option, if 401 exists, will be checked to decide which neighbor(s) to replicate the 402 BIERv6 packet to. 404 It is a local behavior to handle the combination of extension 405 headers, options and the BIER option(s) in destination options header 406 when a 'BIER Specific Handling' indication is got by the preceding 407 FIB lookup. Early deployment of BIERv6 may require there is only one 408 BIER option TLV in the destination options header followed the IPv6 409 header. How other extension headers or more BIER option TLVs in a 410 BIERv6 packet is handled is outside the scope of this document. 412 A packet having a 'BIER Specific Handling' indication but not having 413 a BIER option is supposed to be a wrong packet or an ICMPv6 packet, 414 and the process can be referred to the example in section 3.2. 416 A packet not having a 'BIER Specific Handling' indication but having 417 a BIER option SHOULD be processed normally as unicast forwarding 418 procedures, which may be a behavior of drop, or send to CPU, or other 419 behaviors in existing implementations. 421 The Destination Address field in the IPv6 Header MUST change to the 422 nexthop BFR's End.BIER Unicast address in BIERv6. 424 The Hop Limit field of IPv6 header MUST decrease by 1 when sending 425 packets to a BFR neighbor, while the TTL in the BIER header MUST be 426 unchanged on a Non-BIER router, or decrease by 1 on a BFR. 428 The BitString in the BIER header in the Destination Options Header 429 may change when sending packets to a neighbor. Such change of 430 BitString MUST be aligned with the procedure defined in RFC8279. 432 Because of the requirement to change the content of the option when 433 forwarding BIERv6 packet, the BIER option type should have chg flag 1 434 per section 4.2 of RFC8200. 436 The procedures applies normally if a bit corresponding to the self 437 bfr-id is set in the BitString field of the BIERv6 Option Data of the 438 BIERv6 packet. The node is considered to be an Egress BFR (BFER) in 439 this case. The BFER removes the BIERv6 header, including the IPv6 440 header and the Destination Options header, and copies the packet to 441 the multicast flow overlay. The egress VRF of a packet may be 442 determined by a further lookup on the IPv6 source address instead of 443 the upstream-assigned MPLS Label as described in [RFC8556]. 445 The Fragment Header, AH Header or ESP Header, if exists after the 446 BIER options header, can be processed on BFER only as part of the 447 multicast flow overlay process. 449 The following diagram shows the whole progression of the multicast 450 packet as it enters the BIERv6 domain on PE1, and leaves the BIERv6 451 domain on PE2 and PE3. 453 +-------------+ +-------------+ 454 |{S=PE1,D=P2} | |{S=PE1,D=PE2}| 455 +-------------+ +-------------+ 456 |[BitStr=0110]| |[BitStr=0010]| 457 +==========+ +=============+ +=============+ +==========+ 458 |(C-MC Pkt)| >> | (C-MC Pkt) | >> | (C-MC Pkt) | >> |(C-MC Pkt)| 459 +==========+ +=============+ +=============+ +==========+ 460 CE1-----------PE1------[P1]------P2----------------PE2------------CE2 461 (BFIR) /(BFR) (BFER, BFR-id=2) 462 / 463 / +-------------+ 464 | |{S=PE1,D=PE3}| 465 | +-------------+ 466 | |[BitStr=0100]| 467 \ +=============+ +==========+ 468 \ >> | (C-MC Pkt) | >> |(C-MC Pkt)| 469 \ +=============+ +==========+ 470 +------[P3]-------PE3------------CE3 471 (BFER, BFR-id=3) 473 {S=PE1,D=PE2}: Source address and Destination address in IPv6 header. 474 [BitStr=0110]: BitString value in IPv6 DO Header. 475 (C-MC Pkt): Customer MultiCast packet. 477 o PE1 is Provider Edge router, acting as BFIR. 479 o P2 is Provider Core router, acting as BFR. 481 o P1 and P3 are IPv6 routers, acting as Non-BFR. 483 o PE2 and PE3 are Provider Edge routers, acting as BFER. 485 o CE1 and CE2 are Customer Edge routers. 487 5. Security Considerations 489 BIER IPv6 encapsulation provides a new encapsulation based on IPv6 490 and BIER to transport multicast data packet in a BIER domain. The 491 BIER domain can be a single IGP area, an anonymous system (AS) with 492 multiple IGP areas, or multiple anonymous systems (ASes) operated by 493 a network operator. A single BIER Sub-domain may be deployed through 494 the whole BIER Domain, as illustrated in 495 [I-D.geng-bier-ipv6-inter-domain]. 497 This section reviews security considerations related to the BIER IPv6 498 encapsulation, based on security considerations of [RFC8279], 499 [RFC8296], and other documents related to IPv6 extension. 501 It is expected that all nodes in a BIER IPv6 domain are managed by 502 the same administrative entity. BIER-encapsulated packets should 503 generally not be accepted from untrusted interfaces or tunnels. For 504 example, an operator may wish to have a policy of accepting BIER- 505 encapsulated packets only from interfaces to trusted routers, and not 506 from customer-facing interfaces. See section 5.1 for normal Intra 507 domain deployment. 509 For applications that require a BFR to accept a BIER-encapsulated 510 packet from an interface to a system that is not controlled by the 511 network operator, the security considerations of [RFC8296] apply. 513 BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause 514 security problems. See section 5.2 for ICMP related problems. 516 This document introduces a new option used in IPv6 Destination 517 Options Header, together with the special-use IPv6 address called 518 End.BIER in IPv6 destination address for BIER IPv6 forwarding. 519 However the option newly introduced may be wrongly used with normal 520 IPv6 destination address. See section 5.3 for problems introduced by 521 the new IPv6 option with normal IPv6 destination address. 523 If the multicast data packet of a BIERv6 packet is altered by an 524 intermediate router, contents of the multicast data packet will be 525 damaged. BIER IPv6 encapsulation provides the ability of IPsec to 526 ensure the confidentiality or integrity for multicast data packet. 527 See section 5.4 for this security problem. 529 If the BIERv6 encapsulation of a particular packet specifies a 530 BitString (together with SI) other than the one intended by the BFIR, 531 the packet is likely to be misdelivered. Some modifications of the 532 BIER encapsulation, e.g., setting every bit in the BitString, may 533 result in denial-of-service (DoS) attacks. This kind of DoS attack 534 is a challenge not only in BIERv6 but also in BIER as specified in 535 [RFC8279] and [RFC8296], as the BitString is required to change on 536 BFR per the BIER forwarding procedures. This document does not 537 provide new mechanisms to improve this kind of weakness. 539 A BIER router accepts and uses the End.BIER IPv6 address to construct 540 BIFT only when the IPv6 address is configured explicitly, or received 541 from a router via control-plane protocols. The received information 542 is validated using existing authentication and security mechanisms of 543 the control-plane protocols. BIER IPv6 encapsulation does not define 544 any additional security mechanism in existing control-plane 545 protocols, and it inherits any security considerations that apply to 546 the control-plane protocols. 548 5.1. Intra Domain Deployment 550 Generally nodes outside the BIER Domain are not trusted: they cannot 551 directly use the End.BIER of the domain. This is enforced by two 552 levels of access control lists: 554 1. Any packet entering the BIER Domain and destined to an End.BIER 555 IPv6 Address within the BIER Domain is dropped. This may be realized 556 with the following logic. Other methods with equivalent outcome are 557 considered compliant: 559 * allocate all the End.BIER IPv6 Address from a block S/s 561 * configure each external interface of each edge node of the domain 562 with an inbound infrastructure access list (IACL) which drops any 563 incoming packet with a destination address in S/s 565 * Failure to implement this method of ingress filtering exposes the 566 BIER Domain to BIER attacks as described and referenced in [RFC8296]. 568 2. The distributed protection in #1 is complemented with per node 569 protection, dropping packets to End.BIER IPv6 Address from source 570 addresses outside the BIER Domain. This may be realized with the 571 following logic. Other methods with equivalent outcome are 572 considered compliant: 574 * assign all interface addresses from prefix A/a 576 * assign all the IPv6 addresses used as source address of BIER IPv6 577 packets from a block B/b 579 * at node k, all End.BIER IPv6 addresses local to k are assigned from 580 prefix Sk/sk 582 * configure each internal interface of each BIER node k in the BIER 583 Domain with an inbound IACL which drops any incoming packet with a 584 destination address in Sk/sk if the source address is not in A/a or 585 B/b. 587 For simplicity of deployment, a configuration of IACL effective for 588 all interfaces can be provided by a router. Such IACL can be 589 referred to as global IACL(GIACL) .Each BIER node k then simply 590 configs a GIACL which drops any incoming packet with a destination 591 address in Sk/sk if the source address is not in A/a or B/b for the 592 intra-domain deployment mode. 594 5.2. ICMP Error Processing 596 The BIERv6 BFR does not send ICMP error messages to the source 597 address of a BIERv6 packet, there is still chance that Non-BFR 598 routers send ICMP error messages to source nodes within the BIER 599 Domain. 601 A large number of ICMP may be elicited and sent to a BFIR router, in 602 case when a BIERv6 packet is filled with wrong Hop Limit, either 603 error or malfeasance. A rate-limiting of ICMP packet should be 604 implemented on each BFR. 606 The ingress node can take note of the fact that it is getting, in 607 response to BIER IPv6 packet, one or more ICMP error packets. By 608 default, the reception of such a packets MUST be countered and 609 logged. However, it is possible for such log entries to be "false 610 positives" that generate a lot of "noise" in the log; therefore, 611 implementations SHOULD have a knob to disable this logging. 613 5.3. Security caused by BIER option 615 This document introduces a new option used in IPv6 Destination 616 Options Header. An IPv6 packet with a normal IPv6 address of a 617 router (e.g. loopback IPv6 address of the router) as destination 618 address will possibly carry a BIER option. 620 For a router incapable of BIERv6, such BIERv6 packet will not be 621 processed by the procedure described in this document, but be 622 processed as normal IPv6 packet with unknown option, and the existing 623 security considerations for handling IPv6 options apply. Possible 624 way of handling IPv6 packets with BIER option may be send to CPU for 625 slow path processing, with rate-limiting, or be discarded according 626 to the local policy. 628 For a router capable of BIERv6, such BIERv6 packet MUST NOT be 629 forwarded, but should be processed as a normal IPv6 packet with 630 unknown option, or additionally and optionally be countered and 631 logged if the router is capable of doing so. 633 5.4. Applicability of IPsec 635 IPsec [RFC4301] uses two protocols to provide traffic security 636 services -- Authentication Header (AH) [RFC4302] and Encapsulating 637 Security Payload (ESP) [RFC4303]. Each protocol supports two modes 638 of use: transport mode and tunnel mode. IPsec support both unicast 639 and multicast. IPsec implementations MUST support ESP and MAY 640 support AH. 642 This document assume IPsec working in tunnel mode with inner IPv4 or 643 IPv6 multicast packet encapsulated in outer BIERv6 header and IPsec 644 header(s). 646 IPsec used with BIER IPv6 encapsulation to ensure that a BIER payload 647 is not altered while in transit between BFIR and BFERs. If a BFR in 648 between BFIR and BFERs is compromised, there is no way to prevent the 649 compromised BFR from making illegitimate modifications to the BIER 650 payload or to prevent it from misforwarding or misdelivering the 651 BIER-encapsulated packet, but the BFERs will detect the illegitimate 652 modifications to the BIER Payload (or the inner multicast data 653 packet). This could provide cryptographic integrity protection for 654 multicast data transport. This capability of IPsec comes from the 655 design that, the destination options header carrying the BIER header 656 is located before the AH or ESP and the BFR routers in between BFIR 657 and BFERs can process the BIER header without aware of AH or ESP. 659 For ESP, the Integrity Check Value (ICV) is computed over the ESP 660 header, Payload, and ESP trailer fields. It doesn't require the IP 661 or extension header for ICV calculating, and thus the change of DA 662 and BIER option data does not affect the function of ESP. 664 For AH, the Integrity Check Value (ICV) is computed over the IP or 665 extension header fields before the AH header, the AH header, and the 666 Payload. The IPv6 DA is immutable for unicast traffic in AH, and the 667 change of DA in BIER IPv6 forwarding for multicast traffic is 668 incompatible to this rule. How AH is extended to support multicast 669 traffic transporting through BIER IPv6 encapsulation is outside the 670 scope of this document. 672 The detailed control-plane for BIER IPv6 encapsulation IPsec function 673 is outside the scope of the document. Internet Key Exchange Protocol 674 Version 2 (IKEv2) [RFC7296] and Group Security Association (GSA) 675 [RFC5374] can be referred to for further studying. 677 6. IANA Considerations 679 6.1. BIER Option Type 681 Allocation is expected from IANA for a BIER Option Type codepoint 682 from the "Destination Options and Hop-by-Hop Options" sub-registry of 683 the "Internet Protocol Version 6 (IPv6) Parameters" registry. The 684 value 0x70 is suggested. 686 +-----------+-----+-----+-------+-------------+------------+ 687 | Hex Value | act | chg | rest | Description | Reference | 688 +-----------+-----+-----+-------+-------------+------------+ 689 | 0x70 | 01 | 1 | 10000 | BIER Option | This draft | 690 +-----------+-----+-----+-------+-------------+------------+ 692 6.2. End.BIER Function 694 Allocation is expected from IANA for an End.BIER function codepoint 695 from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is 696 suggested. 698 +-------+--------+--------------------------+------------+ 699 | Value | Hex | Endpoint function | Reference | 700 +-------+--------+--------------------------+------------+ 701 | TBD | TBD | End.BIER | This draft | 702 +-------+--------+--------------------------+------------+ 704 7. Acknowledgements 706 The authors would like to thank Stig Venaas for his valuable 707 comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda, 708 Toerless Eckert, Jeffrey Zhang, Pascal Thubert for the helpful 709 comments to improve this document. 711 Thanks Aijun Wang for comments about BIER OAM function in BIER IPv6 712 encapsulation. 714 Thanks Mach Chen for review and suggestions about BIER-PING function 715 in BIER IPv6 encapsulation. 717 8. Contributors 719 Gang Yan 721 Huawei Technologies 723 China 725 Email: yangang@huawei.com 727 Yang(Yolanda) Xia 729 Huawei Technologies 731 China 733 Email: yolanda.xia@huawei.com 735 9. References 737 9.1. Normative References 739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 740 Requirement Levels", BCP 14, RFC 2119, 741 DOI 10.17487/RFC2119, March 1997, 742 . 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 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 762 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 763 2011, . 765 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 766 Kivinen, "Internet Key Exchange Protocol Version 2 767 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 768 2014, . 770 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 771 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 772 May 2017, . 774 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 775 (IPv6) Specification", STD 86, RFC 8200, 776 DOI 10.17487/RFC8200, July 2017, 777 . 779 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 780 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 781 Explicit Replication (BIER)", RFC 8279, 782 DOI 10.17487/RFC8279, November 2017, 783 . 785 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 786 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 787 for Bit Index Explicit Replication (BIER) in MPLS and Non- 788 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 789 2018, . 791 [RFC8401] Ginsberg, L., Ed., Przygienda, T., Aldrin, S., and Z. 792 Zhang, "Bit Index Explicit Replication (BIER) Support via 793 IS-IS", RFC 8401, DOI 10.17487/RFC8401, June 2018, 794 . 796 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 797 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 798 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 799 2019, . 801 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 802 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 803 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 804 . 806 9.2. Informative References 808 [I-D.geng-bier-bierv6-yang] 809 Geng, X., Qin, Z., and F. Zheng, "YANG Data Model for 810 Bierv6", draft-geng-bier-bierv6-yang-00 (work in 811 progress), June 2020. 813 [I-D.geng-bier-ipv6-inter-domain] 814 Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain 815 Multicast Deployment using BIERv6", draft-geng-bier-ipv6- 816 inter-domain-01 (work in progress), January 2020. 818 [I-D.ietf-bier-ipv6-requirements] 819 McBride, M., Xie, J., Dhanaraj, S., Asati, R., Zhu, Y., 820 and G. Mishra, "BIER IPv6 Requirements", draft-ietf-bier- 821 ipv6-requirements-05 (work in progress), July 2020. 823 [I-D.ietf-bier-ping] 824 Nainar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 825 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 826 ping-07 (work in progress), May 2020. 828 [I-D.ietf-spring-srv6-network-programming] 829 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 830 Matsushima, S., and Z. Li, "SRv6 Network Programming", 831 draft-ietf-spring-srv6-network-programming-16 (work in 832 progress), June 2020. 834 [I-D.xie-bier-ipv6-isis-extension] 835 Xie, J., Wang, A., Yan, G., and S. Dhanaraj, "BIER IPv6 836 Encapsulation (BIERv6) Support via IS-IS", draft-xie-bier- 837 ipv6-isis-extension-01 (work in progress), January 2020. 839 [I-D.xie-bier-ipv6-mvpn] 840 Xie, J., McBride, M., Dhanaraj, S., and L. Geng, "Use of 841 BIER IPv6 Encapsulation (BIERv6) for Multicast VPN in IPv6 842 networks", draft-xie-bier-ipv6-mvpn-02 (work in progress), 843 January 2020. 845 Appendix A. Relationship to BIER Core Standards 847 The BIER architecture [RFC8279] is inherited in this BIERv6 proposal, 848 and the layering mode of BIER architecture is fully supported with 849 some necessary extension to the data plane as well as the control 850 plane standards. 852 The focus of this document is BIERv6 data plane, including the BIERv6 853 encapsulation and packet forwarding procedures. The common BIER 854 header encoding [RFC8296] is maximum reused in this BIERv6 proposal. 856 To better understand the overall BIER IPv6 problem space and 857 requirements, refer to [I-D.ietf-bier-ipv6-requirements]. 859 Appendix B. Extensions to BIER Control-plane Standards 861 The relevant control-plane documents that have done or still to be 862 done are listed below. 864 o Based on [RFC8401], IS-IS extension is defined in 865 [I-D.xie-bier-ipv6-isis-extension] for intra-AS BIERv6 information 866 advertisement and BIRT/BIFT building. 868 o OSPFv3 extension for intra-AS BIERv6 information advertisement and 869 BIRT/BIFT building is to be defined. 871 o Based on this BIERv6 encapsulation, 872 [I-D.geng-bier-ipv6-inter-domain] illustrates how inter-AS BIRT/ 873 BIFT are built and how inter-AS multicast deployment is supported. 875 o BGP extension for inter-AS BIERv6 information advertisement and 876 BIRT/BIFT building is to be defined. 878 o Based on [RFC8556], BGP-MVPN using BIERv6 encapsulation is defined 879 in [I-D.xie-bier-ipv6-mvpn] for multicast service deployment. 881 Appendix C. Considerations of Using Unicast Address 883 BIER is generally a hop-by-hop and one-to-many architecture, and thus 884 the IPv6 Destination Address (DA) being a Multicast Address is a way 885 one may think of as an approach for both the two paradigms in BIERv6 886 encapsulation. 888 However using a unicast address has the following benefits: 890 1. Replicating a BIERv6 packet over a non-BIER capable router. 892 2. Fast rerouting a BIERv6 packet using a unicast by-pass tunnel. 894 3. Forwarding a BIERv6 packet to one of the many BFR neighbors 895 connected on a LAN without imposing new requirements of snooping 896 on switches. 898 4. Replicating a BIERv6 packet through an anonymous system(AS) to 899 BFERs in other ASes, as illustrated in 900 [I-D.geng-bier-ipv6-inter-domain]. 902 Some of the above scenarios are assumed part of BIER architecture as 903 described in [RFC8279], and some of them are the scalability aspects 904 for inter-AS stateless multicast this document intends to support. 905 This document intends to fulfil all these requirements (categorized 906 as multi-hop replication), and proposes to use unicast address for 907 both one-hop replication and multi-hop replication. 909 Authors' Addresses 911 Jingrong Xie 912 Huawei Technologies 914 Email: xiejingrong@huawei.com 916 Liang Geng 917 China Mobile 918 Beijing 10053 920 Email: gengliang@chinamobile.com 922 Mike McBride 923 Futurewei 925 Email: mmcbride7@gmail.com 927 Rajiv Asati 928 Cisco 930 Email: rajiva@cisco.com 932 Senthil Dhanaraj 933 Huawei 935 Email: senthil.dhanaraj@huawei.com 937 Yongqing Zhu 938 China Telecom 940 Email: zhuyq8@chinatelecom.cn 942 Zhuangzhuang Qin 943 China Unicom 945 Email: qinzhuangzhuang@chinaunicom.cn 946 MooChang Shin 947 LG Uplus 949 Email: himzzang@lguplus.co.kr 951 Gyan Mishra 952 Verizon Inc. 954 Email: gyan.s.mishra@verizon.com 956 Xuesong Geng 957 Huawei 959 Email: gengxuesong@huawei.com