idnits 2.17.00 (12 Aug 2021) /tmp/idnits26119/draft-lx-msr6-rgb-segment-00.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 are 5 instances of too long lines in the document, the longest one being 18 characters 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 (25 October 2021) is 201 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) == Unused Reference: 'I-D.geng-bier-ipv6-inter-domain' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bier-ping' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'I-D.xie-bier-ipv6-mvpn' is defined on line 584, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 597, but no explicit reference was found in the text == Unused Reference: 'RFC4302' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC5374' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC7296' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC8200' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'RFC8754' is defined on line 641, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-cheng-spring-ipv6-msr-design-consideration-00 ** Downref: Normative reference to an Informational draft: draft-cheng-spring-ipv6-msr-design-consideration (ref. 'I-D.cheng-spring-ipv6-msr-design-consideration') Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Liu 3 Internet-Draft China Mobile 4 Intended status: Standards Track J. Xie 5 Expires: 28 April 2022 X. Geng 6 Huawei Technologies 7 25 October 2021 9 RGB (Replication through Global Bitstring) Segment for Multicast Source 10 Routing over IPv6 11 draft-lx-msr6-rgb-segment-00 13 Abstract 15 This document introduces the RGB (Replication through Global 16 Bitstring) Segment for Multicast Source Routing over IPv6. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 28 April 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. RGB Destination Options Header . . . . . . . . . . . . . . . 4 60 4. RGB Segment . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. RGB Segment Definition . . . . . . . . . . . . . . . . . 5 62 4.2. End.RGB Behavior . . . . . . . . . . . . . . . . . . . . 6 63 5. MSR6 BE Encapsulation . . . . . . . . . . . . . . . . . . . . 6 64 6. Packet Processing Procedure . . . . . . . . . . . . . . . . . 7 65 7. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 8.1. RGB Option Type . . . . . . . . . . . . . . . . . . . . . 10 68 8.2. End.RGB Function . . . . . . . . . . . . . . . . . . . . 10 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 9.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 11 71 9.2. ICMP Error Processing . . . . . . . . . . . . . . . . . . 12 72 9.3. Security caused by RGB option . . . . . . . . . . . . . . 12 73 10. Normative References . . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 Segment Routing ([RFC8402]) leverages the mechanism of source 79 routing. An ingress node steers a packet through an ordered list of 80 instructions, called "segments". Each one of these instructions 81 represents a function to be implemented at a specific location in the 82 network. A function is locally defined on the node where it is 83 executed. Network Programming combines Segment Routing functions to 84 achieve a networking objective that goes beyond mere packet routing. 85 [RFC8986] defines the SRv6 Network Programming concept and specifies 86 the main Segment Routing behaviors and network programming functions. 88 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 89 that provides optimal multicast forwarding without requiring a 90 protocol for explicitly building multicast distribution trees or per- 91 flow state maintained by intermediate routers. When a multicast data 92 packet enters BIER forwarding domain, the ingress node encapsulates 93 the packet with a bitstring, each bitposition of which presents the 94 egress nodes. To forward the packet to a given set of egress nodes, 95 the bits corresponding to those egress nodes are set in the 96 bitstring. The intermediate nodes in the BIER domain replicate and 97 forward the packet based on the bitstring.The mechanism of forwarding 98 a packet based on bitstring of BIER are specified in [RFC8279]. 100 An IPv6 based multicast source routing (MSR6) solution is defined in 101 [I-D.cheng-spring-ipv6-msr-design-consideration], which leverages the 102 benefits of source routing over IPv6 data plane to provide simplified 103 multicast TE and BE service in an IPv6 network without unnecessary 104 multicast tree status and complex control plane protocols. MSR6 105 needs to reuse the advantages of SRv6 and BIER to implement source 106 routing. 108 MSR6 has two basic modes of forwarding: one is based on Shortest Path 109 First(SPF), which is called MSR6 BE mode; the other is based on 110 traffic engineered, which is called MSR6 TE mode. This document 111 defines a new type of segment, Replication through Global Bitstring 112 Segment (RGB Segment), and the packet processing procedures over the 113 IPv6 data plane for the MSR6 BE solutions. 115 2. Terminologies 117 The following new terms are used throughout this document: 119 MSR6 Domain: a set of nodes participating in the multicast source 120 routing; 122 MSR6 Ingress Node: a node through which a multicast data packet 123 enters an MSR6 domain; The MSR6 Ingress Node could be a host or a 124 network device. 126 MSR6 Egress Node: a node through which a multicast data packet leaves 127 an MSR6 domain; The MSR6 Egress Node could be a host or a network 128 device. 130 MSR6 Root Node: a node which is the beginning point of a multicast 131 tree. It encapsulates the packet with an MSR6 multicast header. 133 MSR6 Leaf Node: a node which is the ending point of a multicast tree. 134 It decapsulates the MSR6 multicast header in the packet. 136 MSR6 Replication Endpoint: the intermediate node of a multicast tree, 137 which replicates packet and forwards the packet to the downstream 138 nodes. For MSR6, the Replication Node is called Replication Endpoint 139 which can be indicated by the MSR6 Segment and replicate packets 140 according to the multicast source routing information encapsulation 141 in the MSR6 header of the packet. 143 MSR6 Transit Node: a node which forwards the MSR6 packet as an IPv6 144 unicast packet; 146 3. RGB Destination Options Header 148 MSR6 BE needs to indicate egress nodes in the packet to avoid 149 maintaining multicast tree state in the intermediate nodes. Such 150 mechanism that has been defined in IETF, as BIER defined in 151 [RFC8279], could be reused in MSR6 BE with global bitstring 152 indicating egress nodes. 154 A new DoH option called RGB option is introduced in this document to 155 support MSR6 BE. The option includes the bistring representing 156 egress nodes and MUST be encapsulated in the IPv6 Destination Options 157 Header defined in RFC8200. 159 The encoding of RGB(Replication through Global Bitstring) Option Data 160 is defined as 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 ~ RGB Option Data ~ 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 RGB Option is defined as follows: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | BIFT-id | Rsv | TTL | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Rsv | Ver | BSL | Entropy | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 |OAM|Rsv| DSCP | Rsv | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | BitString (first 32 bits) ~ 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 ~ ~ 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 ~ BitString (last 32 bits) | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 The RGB Option Data reuses some codepoint of Non-MPLS BIER Header 202 defined in [RFC8296] except the fields of Nibble, DSCP and Proto, 203 which are replaced as the Reserved field. The Reserved fields SHOULD 204 be set to 0 and MUST be ignored up reception. 206 4. RGB Segment 208 4.1. RGB Segment Definition 210 The segment defined in [RFC8402] can represent instruction, 211 topological or service based. In an IPv6 domain, a segment could be 212 encoded as an IPv6 address. 214 In the IPv6 data plane, RGB segment is a new type of segment which is 215 used to identify the Replication Endpoint. Replication Endpoint is 216 able to replicate the packet using BIER forwarding mechanism 217 according to the bitstring defined in the RGB Option. 219 RGB segment is used as an IPv6 address, which is 128 bits and follows 220 the SID format defined in [RFC8986], consisting of LOC:FUNCT:ARG. 221 RGB segment is advertised by the RGB replication endpoint. 223 In an MSR6 domain, RGB segment is used as the destination address of 224 the MSR BE packet, when a packet is replicated to the next 225 Replication Endpoint. If there is 1 or more MSR6 transit node 226 between two Replication Endpoints, the packet is forwarded as normal 227 unicast IPv6 packet. 229 4.2. End.RGB Behavior 231 In SRv6, a packet processing behavior executed at an SRv6 Segment 232 Endpoint Node ([RFC8986]). In MSR6, a new type of behavior, 233 End.RGB(End. Replication through Global Bitstring), is defined for 234 RGB Segment. The pseudo-code for End.RGB is defined in this section. 236 When an MSR6 Replication Endpoint receives a packet whose IPv6 DA 237 (Destination Address) is a SID and the SID is a local End.RGB SID, 238 the MSR6 Replication Endpoint does the following: 240 1. IF (There is DoH as an IPv6 Extension header and one of the options type is RGB) ; 241 2. Lookup BIFT(Bit Index Forwarding Table, RFC8279) based on the bitstring 242 inside the RGB Option Data. 243 3. Forward the packet via the matched entry in the BIFT. 244 4. ELSE IF NH=ICMPv6 or (NH=RGB Extension Header Type and NH 245 of Extension Header=ICMPv6) ; 246 5. Send to CPU. 247 6. ELSE ;Ref 248 7. Drop the packet. 250 Ref: An ICMPv6 packet using End.RGB as destination address. 252 5. MSR6 BE Encapsulation 254 The Encapsulation of MSR6 BE packet is defined as follows: 256 +---------------+------------------+----------------------+ 257 | IPv6 header | IPv6 DO Header | Client Multicast | 258 | | with RGB Option | Packet or Upper | 259 | | | Layer Encasulations | 260 | Next Hdr = 60 | Nxt Hdr = X | | 261 +---------------+------------------+----------------------+ 262 | | | 263 |<---------MSR6 BE header--------->|<--MSR6 BE payload--->| 265 In the MSR6 BE header, the RGB Segment is used as the IPv6 266 Destination Address and it indicates the next MSR6 Replication 267 Endpoints in an MSR domain in an MSR6 domain. 269 The MSR6 BE header also includes a DOH containing RGB option defined 270 in section. The RGB Replication Endpoint indicated by the RGB 271 Segment replicate the packet according to the bitstring information 272 in the RGB option. 274 6. Packet Processing Procedure 276 This section defines the general process of MSR6 to transport a 277 multicast service. The corresponding control plane is out of scope 278 of this document and could be discussed in the following work. 280 MSR6 Root Node: Encapsulate the packet with MSR BE encapsulation as 281 defined in section 5. The bitstring in the DoH is determined by the 282 egress nodes the packet is supposed to be replicated to. The IPv6 283 destination address is the RGB segment which is determined by the 284 next MSR6 RGB Replication Endpoints the packet is supposed to be sent 285 to. The downstream MSR6 Replication Endpoints are determined by the 286 matched entries in BIFT according to the bier forwarding mechanism. 288 MSR6 Replication Endpoint: Replicate the packet and forward it to the 289 next MSR6 Replication Endpoints. When an MSR6 Replication Endpoint 290 receives a packet whose IPv6 Destination Address is A and A is the 291 local RGB segment for the existing MSR6 Replication Endpoint, process 292 the bitstring in the RGB DoH of the packet and look up the 293 corresponding BITF for the next MSR6 Replication Endpoints. 294 Replicate the packet, update the bitstring and DA in each replicated 295 packet based on the lookup result.The RGB processing procedure 296 follows the specification in RGB architecture defined in RFC8279. 298 MSR6 Transit Node: Transit the packet as an ordinary IPv6 packet by 299 looking up FIB until find the next MSR6 Replication Endpoint. 301 MSR6 Leaf Node: Decasulate the MSR BE encapsulation. When an MSR6 302 Replication Endpoint receives a packet whose IPv6 Destination Address 303 is A and A is the local RGB segment and the one of the bits set to 1 304 identifies the MSR6 Replication Endpoint itself, this Replication 305 Endpoint is the egress node. If the MSR6 egress node is the edge of 306 a network, copy the packet and send the copy to the multicast flow 307 overlay; If the MSR6 egress node is the host supposed to receive the 308 packet, send the packet to the upper layer. 310 MSR6 Replication Endpoint MSR6 Leaf Node 311 +----+ +----+ +----+ 312 | |-----------| |--------------| | 313 +----+ +----+ +----+ 314 MSR6 Root Node | +----+ +----+ 315 +-----| |-----| | 316 +----+ +----+ 317 MSR6 Transit Node MSR6 Leaf Node 319 7. Illustration 321 * Case 1: Host originating MSR6 BE 323 +-------------+ +-------------+ 324 | {S=S1,D=P1} | | {S=S1,D=C1} | 325 +-------------+ +-------------+ 326 |[BitStr=0110]| |[BitStr=0100]| 327 +=============+ +=============+ 328 | Upper Layer | >> | Upper Layer | 329 +=============+ +=============+ 330 | Pay Load | | Pay Load | 331 +=============+ +=============+ 332 [Server1]--------------[P1]-------------------[Client1] 333 (MSR6 Ingress) (MSR6 Replication Endpoint) (MSR6 Egress,BFR-id=2) 334 / 335 / +-------------+ +-------------+ 336 | | {S=S1,D=C2} | | {S=S1,D=C2} | 337 | +-------------+ +-------------+ 338 | |[BitStr=0010]| |[BitStr=0010]| 339 | +=============+ +=============+ 340 | >> | Upper Layer | >> | Upper Layer | 341 \ +=============+ +=============+ 342 \ | Pay Load | | Pay Load | 343 \ +=============+ +=============+ 344 +-------------[P2]-----------[Client2] 345 (MSR6 Transit)(MSR6 Egress, BFR-id=3) 347 {S=Server1,D=P1}: Source address and Destination address in IPv6 header. 348 [BitStr=0110]: BitString value in IPv6 Destination Options Header. 350 Server1 generates the packet with an IPv6 Header. Knowing that BFR- 351 ID of Client 1 is 2 and BFR-ID of Client 2 is 3, it follows that when 352 the multicast service is supposed to be transmitted to Client1 and 353 Client2, the bitstring in RGB DoH of the IPv6 header is set as 354 "0110". Look up the BIFT and finds the RGB segment of next MSR6 BFR 355 is P1. The IPv6 DA is set as "P1". 357 P1 receives the packet with DA as "P1", which is the local RGB 358 segment. P1 parses the DoH with RGB Option Data and looks up the 359 BIFT to find the corresponding entry. P1 replicates the packets into 360 2 copies based on the look up result. DA of one replicated packet is 361 set to "C1" and the bitstring is set to "0100". DA of the other 362 replicated packet is set to "C2" and the bitstring is set to "0010". 363 These 2 packets are forwarded to next hop based on the updated DA. 365 P2 receives the packet and forwards it Client2 based on the DA of 366 "C2". 368 Client1 receives the packet with DA as "C1". "C1" is the local RGB 369 segment and "0100" identifies Client1 itself. The packet is sent to 370 the upper layer. 372 Client2 receives the packet with DA as "C2". "C2" is the local RGB 373 segment and "0010" identifies Client2 itself. The packet is sent to 374 the upper layer. 376 * Caes 2: MSR6 is used in a network domain 378 +-------------+ +-------------+ 379 |{S=PE1,D=P2} | |{S=PE1,D=PE2}| 380 +-------------+ +-------------+ 381 |[BitStr=0110]| |[BitStr=0100]| 382 +==========+ +=============+ +=============+ +==========+ 383 |(C-MC Pkt)| >> | (C-MC Pkt) | >> | (C-MC Pkt) | >> |(C-MC Pkt)| 384 +==========+ +=============+ +=============+ +==========+ 385 CE1-----------[PE1]------[P1]------[P2]-----------[PE2]---------CE2 386 (MSR6 Ingress)(MSR6 Transit)/(MSR6 Replication Endpoint) (MSR6 Egress,BFR-id=2) 387 / 388 / +-------------+ 389 | |{S=PE1,D=PE3}| 390 | +-------------+ 391 | |[BitStr=0010]| 392 \ +=============+ +==========+ 393 \ >> | (C-MC Pkt) | >> |(C-MC Pkt)| 394 \ +=============+ +==========+ 395 +------[P3]------[PE3]----------CE3 396 (MSR6 Transit)(MSR6 Egress, BFR-id=3) 398 {S=CE1,D=P1}: Source address and Destination address in IPv6 header. 399 [BitStr=0110]: BitString value in IPv6 Destination Options Header. 400 (C-MC Pkt): Customer MultiCast packet. 402 PE1 receives the customer multicast packet from CE1. An MSR BE 403 header is encapsulated as defined in section 3. Knowing that BFR-ID 404 of PE 1 is 2 and BFR-ID of PE 2 is 3, it follows that when the 405 multicast service is supposed to be transmitted to PE2 and PE3, the 406 bitstring in the RGB Options Header of DoH is set as "0110". Look up 407 the corresponding BIFT and finds the RGB segment of next MSR6 BFR is 408 P2. The IPv6 DA is set as "P2". 410 P1 receives the packet and forwards it P2 based on the DA of "P2". 412 P2 receives the packet with DA as "P2", which is the local RGB 413 segment. P2 parses the DoH with RGB Option Data and looks up the 414 BIFT to find the corresponding entry.P2 replicates the packets into 2 415 copies based on the look up result. DA of one replicated packet is 416 set to "PE2" and the bitstring is set to "0100". DA of the other 417 replicated packet is set to "PE3" and the bitstring is set to "0010". 418 These 2 packets are forwarded to next hop based on the updated DA. 420 P3 receives the packet and forwards it PE3 based on the DA of "PE3". 422 PE2 receives the packet with DA as "PE2". "PE2" is the local RGB 423 segment and "0100" identifies PE2 itself. The packet is sent to the 424 multicast flow overlay. 426 PE3 receives the packet with DA as "PE3". "PE3" is the local RGB 427 segment and "0010" identifies PE3 itself. The packet is sent to the 428 multicast flow overlay. 430 8. IANA Considerations 432 8.1. RGB Option Type 434 Allocation is expected from IANA for a RGB Option Type codepoint from 435 the "Destination Options and Hop-by-Hop Options" sub-registry of the 436 "Internet Protocol Version 6 (IPv6) Parameters" registry. 438 +-----------+-----+-----+-------+-------------+------------+ 439 | Hex Value | act | chg | rest | Description | Reference | 440 +-----------+-----+-----+-------+-------------+------------+ 441 | TBD | 01 | 1 | TBD | RGB Option | This draft | 442 +-----------+-----+-----+-------+-------------+------------+ 444 8.2. End.RGB Function 446 Allocation is expected from IANA for an End.RGB function codepoint 447 from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is 448 suggested. 450 +-------+--------+--------------------------+------------+ 451 | Value | Hex | Endpoint function | Reference | 452 +-------+--------+--------------------------+------------+ 453 | TBD | TBD | End.RGB | This draft | 454 +-------+--------+--------------------------+------------+ 456 9. Security Considerations 458 The MSR6 domain can be a single IGP area, an anonymous system (AS) 459 with multiple IGP areas, or multiple anonymous systems (ASes) 460 operated by a network operator. 462 It is expected that all nodes in an MSR6 domain are managed by the 463 same administrative entity. MSR6-encapsulated packets should 464 generally not be accepted from untrusted interfaces or tunnels. For 465 example, an operator may wish to have a policy of accepting MSR6 466 encapsulated packets only from interfaces to trusted routers, and not 467 from customer-facing interfaces. 469 For applications that require a MSR6 Replication Endpoint to accept a 470 MSR6 encapsulated packet from an interface to a system that is not 471 controlled by the network operator, the security considerations of 472 [RFC8296] apply 474 9.1. Intra Domain Deployment 476 Generally nodes outside the MSR6 Domain are not trusted: they cannot 477 directly use the End.RGB segment of the domain. This is enforced by 478 two levels of access control lists: 480 1. Any packet entering the MSR6 Domain and destined to an End.RGB 481 Segment within the MSR6 Domain is dropped. This may be realized with 482 the following logic. Other methods with equivalent outcome are 483 considered compliant: 485 * allocate all the End.RGB Segment from a block S/s 487 * configure each external interface of each edge node of the domain 488 with an inbound infrastructure access list (IACL) which drops any 489 incoming packet with a destination address in S/s 491 * Failure to implement this method of ingress filtering may expose 492 the MSR6 Domain to BIER attacks. The security consideration on BIER 493 attacks is as described and referenced in [RFC8296]. 495 2. The distributed protection in #1 is complemented with per node 496 protection, dropping packets to End.RGB Segment from source addresses 497 outside the MSR6 Domain. This may be realized with the following 498 logic. Other methods with equivalent outcome are considered 499 compliant: 501 * assign all interface addresses from prefix A/a 502 * assign all the IPv6 addresses used as source address of MSR6 503 packets from a block B/b 505 * at node k, all End.RGB Segment IPv6 addresses local to k are 506 assigned from prefix Sk/sk 508 * configure each internal interface of each MSR6 node k in the MSR6 509 Domain with an inbound IACL which drops any incoming packet with a 510 destination address in Sk/sk if the source address is not in A/a or 511 B/b. 513 For simplicity of deployment, a configuration of IACL effective for 514 all interfaces can be provided by a router. Such IACL can be 515 referred to as global IACL(GIACL) .Each MSR6 node k then simply 516 configures a GIACL which drops any incoming packet with a destination 517 address in Sk/sk if the source address is not in A/a or B/b for the 518 intra-domain deployment mode. 520 9.2. ICMP Error Processing 522 The MSR6 Replication Endpoint does not send ICMP error messages to 523 the source address of a MSR BE packet, but there is still chance that 524 Non-MSR6 Replication Endpoint routers send ICMP error messages to 525 source nodes within the MSR6 Domain. 527 A large number of ICMP may be elicited and sent to a MSR6 Ingress 528 router, in case when an MSR6 BE packet is filled with wrong Hop 529 Limit, either error or malfeasance. A rate-limiting of ICMP packet 530 should be implemented on each MSR6 Replication Endpoint. 532 The ingress node can take note of the fact that it is getting, in 533 response to MSR6 BE packet, one or more ICMP error packets. By 534 default, the reception of such packet MUST be countered and logged. 535 However, it is possible for such log entries to be "false positives" 536 that generate a lot of "noise" in the log; therefore, implementations 537 SHOULD have a knob to disable this logging. 539 9.3. Security caused by RGB option 541 This document introduces a new option used in IPv6 Destination 542 Options Header. An IPv6 packet with a normal IPv6 address of a 543 router (e.g. loopback IPv6 address of the router) as destination 544 address will possibly carry a RGB option. 546 For a router incapable of MSR6 BE, such MSR6 BE packet will not be 547 processed by the procedure described in this document, but be 548 processed as normal IPv6 packet with unknown option, and the existing 549 security considerations for handling IPv6 options apply. Possible 550 way of handling IPv6 packets with RGB option may be send to CPU for 551 slow path processing, with rate-limiting, or be discarded according 552 to the local policy. 554 For a router capable of MSR6 BE, such MSR6 BE packet MUST NOT be 555 forwarded, but should be processed as a normal IPv6 packet with 556 unknown option, or additionally and optionally be countered and 557 logged if the router is capable of doing so. 559 10. Normative References 561 [I-D.cheng-spring-ipv6-msr-design-consideration] 562 Cheng, W., Mishra, G., Li, Z., Wang, A., Qin, Z., and C. 563 Fan, "Design Consideration of IPv6 Multicast Source 564 Routing (MSR6)", Work in Progress, Internet-Draft, draft- 565 cheng-spring-ipv6-msr-design-consideration-00, 12 July 566 2021, . 569 [I-D.geng-bier-ipv6-inter-domain] 570 Geng, L., Xie, J., McBride, M., Yan, G., and X. Geng, 571 "Inter-Domain Multicast Deployment using BIERv6", Work in 572 Progress, Internet-Draft, draft-geng-bier-ipv6-inter- 573 domain-02, 27 October 2020, 574 . 577 [I-D.ietf-bier-ping] 578 Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 579 and G. Mirsky, "BIER Ping and Trace", Work in Progress, 580 Internet-Draft, draft-ietf-bier-ping-07, 11 May 2020, 581 . 584 [I-D.xie-bier-ipv6-mvpn] 585 Xie, J., McBride, M., Dhanaraj, S., Geng, L., and G. 586 Mishra, "Use of BIER IPv6 Encapsulation (BIERv6) for 587 Multicast VPN in IPv6 networks", Work in Progress, 588 Internet-Draft, draft-xie-bier-ipv6-mvpn-03, 10 October 589 2020, . 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, 594 DOI 10.17487/RFC2119, March 1997, 595 . 597 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 598 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 599 December 2005, . 601 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 602 DOI 10.17487/RFC4302, December 2005, 603 . 605 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 606 RFC 4303, DOI 10.17487/RFC4303, December 2005, 607 . 609 [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast 610 Extensions to the Security Architecture for the Internet 611 Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, 612 . 614 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 615 Kivinen, "Internet Key Exchange Protocol Version 2 616 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 617 2014, . 619 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 620 (IPv6) Specification", STD 86, RFC 8200, 621 DOI 10.17487/RFC8200, July 2017, 622 . 624 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 625 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 626 Explicit Replication (BIER)", RFC 8279, 627 DOI 10.17487/RFC8279, November 2017, 628 . 630 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 631 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 632 for Bit Index Explicit Replication (BIER) in MPLS and Non- 633 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 634 2018, . 636 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 637 Decraene, B., Litkowski, S., and R. Shakir, "Segment 638 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 639 July 2018, . 641 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 642 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 643 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 644 . 646 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 647 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 648 (SRv6) Network Programming", RFC 8986, 649 DOI 10.17487/RFC8986, February 2021, 650 . 652 Authors' Addresses 654 Yisong Liu 655 China Mobile 657 Email: liuyisong@chinamobile.com 659 Jingrong Xie 660 Huawei Technologies 662 Email: xiejingrong@huawei.com 664 Xuesong Geng 665 Huawei Technologies 667 Email: gengxuesong@huawei.com