<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-lx-msr6-rgb-segment-00" ipr="trust200902">
  <front>
    <title abbrev="RGB Segment for MSR6">RGB (Replication through Global
    Bitstring) Segment for Multicast Source Routing over IPv6</title>

    <author fullname="Yisong Liu" initials="Y." surname="Liu">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>liuyisong@chinamobile.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Jingrong Xie" initials="J." surname="Xie">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>xiejingrong@huawei.com</email>
      </address>
    </author>

    <author fullname="Xuesong Geng" initials="X." surname="Geng">
      <organization>Huawei Technologies</organization>

      <address>
        <postal>
          <street/>
        </postal>

        <email>gengxuesong@huawei.com</email>
      </address>
    </author>

    <date day="25" month="October" year="2021"/>

    <abstract>
      <t>This document introduces the RGB (Replication through Global
      Bitstring) Segment for Multicast Source Routing over IPv6.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Segment Routing (<xref target="RFC8402"/>) leverages the mechanism of
      source routing. An ingress node steers a packet through an ordered list
      of instructions, called "segments". Each one of these instructions
      represents a function to be implemented at a specific location in the
      network. A function is locally defined on the node where it is executed.
      Network Programming combines Segment Routing functions to achieve a
      networking objective that goes beyond mere packet routing. <xref
      target="RFC8986"/> defines the SRv6 Network Programming concept and
      specifies the main Segment Routing behaviors and network programming
      functions.</t>

      <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> is an
      architecture that provides optimal multicast forwarding without
      requiring a protocol for explicitly building multicast distribution
      trees or per-flow state maintained by intermediate routers. When a
      multicast data packet enters BIER forwarding domain, the ingress node
      encapsulates the packet with a bitstring, each bitposition of which
      presents the egress nodes. To forward the packet to a given set of
      egress nodes, the bits corresponding to those egress nodes are set in
      the bitstring. The intermediate nodes in the BIER domain replicate and
      forward the packet based on the bitstring.The mechanism of forwarding a
      packet based on bitstring of BIER are specified in <xref
      target="RFC8279"/>.</t>

      <t>An IPv6 based multicast source routing (MSR6) solution is defined in
      <xref target="I-D.cheng-spring-ipv6-msr-design-consideration"/>, which
      leverages the benefits of source routing over IPv6 data plane to provide
      simplified multicast TE and BE service in an IPv6 network without
      unnecessary multicast tree status and complex control plane protocols.
      MSR6 needs to reuse the advantages of SRv6 and BIER to implement source
      routing.</t>

      <t>MSR6 has two basic modes of forwarding: one is based on Shortest Path
      First(SPF), which is called MSR6 BE mode; the other is based on traffic
      engineered, which is called MSR6 TE mode. This document defines a new
      type of segment, Replication through Global Bitstring Segment (RGB
      Segment), and the packet processing procedures over the IPv6 data plane
      for the MSR6 BE solutions.</t>
    </section>

    <section title="Terminologies">
      <t>The following new terms are used throughout this document:</t>

      <t>MSR6 Domain: a set of nodes participating in the multicast source
      routing;</t>

      <t>MSR6 Ingress Node: a node through which a multicast data packet
      enters an MSR6 domain; The MSR6 Ingress Node could be a host or a
      network device.</t>

      <t>MSR6 Egress Node: a node through which a multicast data packet leaves
      an MSR6 domain; The MSR6 Egress Node could be a host or a network
      device.</t>

      <t>MSR6 Root Node: a node which is the beginning point of a multicast
      tree. It encapsulates the packet with an MSR6 multicast header.</t>

      <t>MSR6 Leaf Node: a node which is the ending point of a multicast tree.
      It decapsulates the MSR6 multicast header in the packet.</t>

      <t>MSR6 Replication Endpoint: the intermediate node of a multicast tree,
      which replicates packet and forwards the packet to the downstream nodes.
      For MSR6, the Replication Node is called Replication Endpoint which can
      be indicated by the MSR6 Segment and replicate packets according to the
      multicast source routing information encapsulation in the MSR6 header of
      the packet.</t>

      <t>MSR6 Transit Node: a node which forwards the MSR6 packet as an IPv6
      unicast packet;</t>
    </section>

    <section title="RGB Destination Options Header">
      <t>MSR6 BE needs to indicate egress nodes in the packet to avoid
      maintaining multicast tree state in the intermediate nodes. Such
      mechanism that has been defined in IETF, as BIER defined in <xref
      target="RFC8279"/>, could be reused in MSR6 BE with global bitstring
      indicating egress nodes.</t>

      <t>A new DoH option called RGB option is introduced in this document to
      support MSR6 BE. The option includes the bistring representing egress
      nodes and MUST be encapsulated in the IPv6 Destination Options Header
      defined in RFC8200.</t>

      <t>The encoding of RGB(Replication through Global Bitstring) Option Data
      is defined as follows:</t>

      <t><figure align="left">
          <artwork><![CDATA[       0                   1                   2                   3
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |  Hdr Ext Len  |  Option Type  | Option Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                      RGB Option Data                         ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      ]]></artwork>
        </figure><list style="hanging">
          <t hangText="Next Header">8-bit selector. Identifies the type of
          header immediately following the Destination Options header.</t>

          <t hangText="Hdr Ext Len">8-bit unsigned integer. Length of the
          Destination Options header in 8-octet units, not including the first
          8 octets.</t>

          <t hangText="Option Type">To be allocated by IANA. See section
          6.</t>

          <t hangText="Option Length">8-bit unsigned integer. Length of the
          option, in octets, excluding the Option Type and Option Length
          fields.</t>
        </list>RGB Option is defined as follows:</t>

      <t><figure align="left">
          <artwork><![CDATA[      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              BIFT-id                  |   Rsv |     TTL       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Rsv  |  Ver  |  BSL  |              Entropy                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |OAM|Rsv|   DSCP    |                   Rsv                     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                BitString  (first 32 bits)                     ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                BitString  (last 32 bits)                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork>
        </figure></t>

      <t>The RGB Option Data reuses some codepoint of Non-MPLS BIER Header
      defined in <xref target="RFC8296"/> except the fields of Nibble, DSCP
      and Proto, which are replaced as the Reserved field. The Reserved fields
      SHOULD be set to 0 and MUST be ignored up reception.</t>
    </section>

    <section title="RGB Segment ">
      <t/>

      <section title="RGB Segment Definition">
        <t>The segment defined in <xref target="RFC8402"/> can represent
        instruction, topological or service based. In an IPv6 domain, a
        segment could be encoded as an IPv6 address.</t>

        <t>In the IPv6 data plane, RGB segment is a new type of segment which
        is used to identify the Replication Endpoint. Replication Endpoint is
        able to replicate the packet using BIER forwarding mechanism according
        to the bitstring defined in the RGB Option.</t>

        <t>RGB segment is used as an IPv6 address, which is 128 bits and
        follows the SID format defined in <xref target="RFC8986"/>, consisting
        of LOC:FUNCT:ARG. RGB segment is advertised by the RGB replication
        endpoint.</t>

        <t>In an MSR6 domain, RGB segment is used as the destination address
        of the MSR BE packet, when a packet is replicated to the next
        Replication Endpoint. If there is 1 or more MSR6 transit node between
        two Replication Endpoints, the packet is forwarded as normal unicast
        IPv6 packet.</t>
      </section>

      <section title="End.RGB Behavior">
        <t>In SRv6, a packet processing behavior executed at an SRv6 Segment
        Endpoint Node (<xref target="RFC8986"/>). In MSR6, a new type of
        behavior, End.RGB(End. Replication through Global Bitstring), is
        defined for RGB Segment. The pseudo-code for End.RGB is defined in
        this section.</t>

        <t>When an MSR6 Replication Endpoint receives a packet whose IPv6 DA
        (Destination Address) is a SID and the SID is a local End.RGB SID, the
        MSR6 Replication Endpoint does the following:</t>

        <t><figure>
            <artwork align="right"><![CDATA[    1. IF (There is DoH as an IPv6 Extension header and one of the options type is RGB)  ;
    2.   Lookup BIFT(Bit Index Forwarding Table, RFC8279) based on the bitstring 
           inside the RGB Option Data.
    3.   Forward the packet via the matched entry in the BIFT.
    4. ELSE IF NH=ICMPv6 or (NH=RGB Extension Header Type and NH 
        of Extension Header=ICMPv6)  ;
    5.   Send to CPU.
    6. ELSE  ;Ref
    7.   Drop the packet.
]]></artwork>
          </figure></t>

        <t>Ref: An ICMPv6 packet using End.RGB as destination address.</t>

        <t/>
      </section>
    </section>

    <section title="MSR6 BE Encapsulation">
      <t/>

      <t>The Encapsulation of MSR6 BE packet is defined as follows:</t>

      <t><figure>
          <artwork align="left"><![CDATA[
   +---------------+------------------+----------------------+
   |  IPv6 header  |  IPv6 DO Header  |  Client Multicast    |
   |               | with RGB Option |  Packet or Upper     |
   |               |                  |  Layer Encasulations |
   | Next Hdr = 60 |   Nxt Hdr = X    |                      |
   +---------------+------------------+----------------------+
   |                                  |                      |
   |<---------MSR6 BE header--------->|<--MSR6 BE payload--->|
          ]]></artwork>
        </figure></t>

      <t>In the MSR6 BE header, the RGB Segment is used as the IPv6
      Destination Address and it indicates the next MSR6 Replication Endpoints
      in an MSR domain in an MSR6 domain.</t>

      <t>The MSR6 BE header also includes a DOH containing RGB option defined
      in section. The RGB Replication Endpoint indicated by the RGB Segment
      replicate the packet according to the bitstring information in the RGB
      option.</t>
    </section>

    <section title="Packet Processing Procedure">
      <t>This section defines the general process of MSR6 to transport a
      multicast service. The corresponding control plane is out of scope of
      this document and could be discussed in the following work.</t>

      <t>MSR6 Root Node: Encapsulate the packet with MSR BE encapsulation as
      defined in section 5. The bitstring in the DoH is determined by the
      egress nodes the packet is supposed to be replicated to. The IPv6
      destination address is the RGB segment which is determined by the next
      MSR6 RGB Replication Endpoints the packet is supposed to be sent to. The
      downstream MSR6 Replication Endpoints are determined by the matched
      entries in BIFT according to the bier forwarding mechanism.</t>

      <t>MSR6 Replication Endpoint: Replicate the packet and forward it to the
      next MSR6 Replication Endpoints. When an MSR6 Replication Endpoint
      receives a packet whose IPv6 Destination Address is A and A is the local
      RGB segment for the existing MSR6 Replication Endpoint, process the
      bitstring in the RGB DoH of the packet and look up the corresponding
      BITF for the next MSR6 Replication Endpoints. Replicate the packet,
      update the bitstring and DA in each replicated packet based on the
      lookup result.The RGB processing procedure follows the specification in
      RGB architecture defined in RFC8279.</t>

      <t>MSR6 Transit Node: Transit the packet as an ordinary IPv6 packet by
      looking up FIB until find the next MSR6 Replication Endpoint.</t>

      <t>MSR6 Leaf Node: Decasulate the MSR BE encapsulation. When an MSR6
      Replication Endpoint receives a packet whose IPv6 Destination Address is
      A and A is the local RGB segment and the one of the bits set to 1
      identifies the MSR6 Replication Endpoint itself, this Replication
      Endpoint is the egress node. If the MSR6 egress node is the edge of a
      network, copy the packet and send the copy to the multicast flow
      overlay; If the MSR6 egress node is the host supposed to receive the
      packet, send the packet to the upper layer.</t>

      <t><figure>
          <artwork><![CDATA[                       MSR6 Replication Endpoint             MSR6 Leaf Node
        +----+           +----+              +----+
        |    |-----------|    |--------------|    | 
        +----+           +----+              +----+
    MSR6 Root Node          |     +----+     +----+
                            +-----|    |-----|    |
                                  +----+     +----+
                         MSR6 Transit Node MSR6 Leaf Node



]]></artwork>
        </figure></t>
    </section>

    <section title="Illustration">
      <t><list style="symbols">
          <t>Case 1: Host originating MSR6 BE</t>
        </list></t>

      <t><figure align="right">
          <artwork><![CDATA[
                    
              +-------------+      +-------------+           
              | {S=S1,D=P1} |      | {S=S1,D=C1} |           
              +-------------+      +-------------+          
              |[BitStr=0110]|      |[BitStr=0100]|           
              +=============+      +=============+           
              | Upper Layer |  >>  | Upper Layer |     
              +=============+      +=============+           
              |  Pay Load   |      |  Pay Load   |          
              +=============+      +=============+          
       [Server1]--------------[P1]-------------------[Client1]
   (MSR6 Ingress)         (MSR6 Replication Endpoint)      (MSR6 Egress,BFR-id=2)
                           /  
                         /   +-------------+    +-------------+
                        |    | {S=S1,D=C2} |    | {S=S1,D=C2} |
                        |    +-------------+    +-------------+
                        |    |[BitStr=0010]|    |[BitStr=0010]|
                        |    +=============+    +=============+
                        | >> | Upper Layer | >> | Upper Layer |
                         \   +=============+    +=============+
                          \  |  Pay Load   |    |   Pay Load  |
                           \ +=============+    +=============+
                              +-------------[P2]-----------[Client2]
                               (MSR6 Transit)(MSR6 Egress, BFR-id=3)


{S=Server1,D=P1}: Source address and Destination address in IPv6 header.
[BitStr=0110]: BitString value in IPv6 Destination Options Header.
]]></artwork>
        </figure></t>

      <t>Server1 generates the packet with an IPv6 Header. Knowing that BFR-ID
      of Client 1 is 2 and BFR-ID of Client 2 is 3, it follows that when the
      multicast service is supposed to be transmitted to Client1 and Client2,
      the bitstring in RGB DoH of the IPv6 header is set as "0110". Look up
      the BIFT and finds the RGB segment of next MSR6 BFR is P1. The IPv6 DA
      is set as "P1".</t>

      <t>P1 receives the packet with DA as "P1", which is the local RGB
      segment. P1 parses the DoH with RGB Option Data and looks up the BIFT to
      find the corresponding entry. P1 replicates the packets into 2 copies
      based on the look up result. DA of one replicated packet is set to "C1"
      and the bitstring is set to "0100". DA of the other replicated packet is
      set to "C2" and the bitstring is set to "0010". These 2 packets are
      forwarded to next hop based on the updated DA.</t>

      <t>P2 receives the packet and forwards it Client2 based on the DA of
      "C2".</t>

      <t>Client1 receives the packet with DA as "C1". "C1" is the local RGB
      segment and "0100" identifies Client1 itself. The packet is sent to the
      upper layer.</t>

      <t>Client2 receives the packet with DA as "C2". "C2" is the local RGB
      segment and "0010" identifies Client2 itself. The packet is sent to the
      upper layer.</t>

      <t><list style="symbols">
          <t>Caes 2: MSR6 is used in a network domain</t>
        </list></t>

      <t><figure align="right">
          <artwork><![CDATA[
                   +-------------+    +-------------+
                   |{S=PE1,D=P2} |    |{S=PE1,D=PE2}|
                   +-------------+    +-------------+
                   |[BitStr=0110]|    |[BitStr=0100]|
   +==========+    +=============+    +=============+    +==========+
   |(C-MC Pkt)| >> | (C-MC Pkt)  | >> | (C-MC Pkt)  | >> |(C-MC Pkt)|
   +==========+    +=============+    +=============+    +==========+
  CE1-----------[PE1]------[P1]------[P2]-----------[PE2]---------CE2
       (MSR6 Ingress)(MSR6 Transit)/(MSR6 Replication Endpoint) (MSR6 Egress,BFR-id=2)
                                 /
                                /     +-------------+
                               |      |{S=PE1,D=PE3}|
                               |      +-------------+
                               |      |[BitStr=0010]|
                                \     +=============+    +==========+
                                 \ >> | (C-MC Pkt)  | >> |(C-MC Pkt)|
                                  \   +=============+    +==========+
                                   +------[P3]------[PE3]----------CE3
                                  (MSR6 Transit)(MSR6 Egress, BFR-id=3)

 {S=CE1,D=P1}: Source address and Destination address in IPv6 header.
 [BitStr=0110]: BitString value in IPv6 Destination Options Header.
    (C-MC Pkt): Customer MultiCast packet.
]]></artwork>
        </figure></t>

      <t>PE1 receives the customer multicast packet from CE1. An MSR BE header
      is encapsulated as defined in section 3. Knowing that BFR-ID of PE 1 is
      2 and BFR-ID of PE 2 is 3, it follows that when the multicast service is
      supposed to be transmitted to PE2 and PE3, the bitstring in the RGB
      Options Header of DoH is set as "0110". Look up the corresponding BIFT
      and finds the RGB segment of next MSR6 BFR is P2. The IPv6 DA is set as
      "P2".</t>

      <t>P1 receives the packet and forwards it P2 based on the DA of
      "P2".</t>

      <t>P2 receives the packet with DA as "P2", which is the local RGB
      segment. P2 parses the DoH with RGB Option Data and looks up the BIFT to
      find the corresponding entry.P2 replicates the packets into 2 copies
      based on the look up result. DA of one replicated packet is set to "PE2"
      and the bitstring is set to "0100". DA of the other replicated packet is
      set to "PE3" and the bitstring is set to "0010". These 2 packets are
      forwarded to next hop based on the updated DA.</t>

      <t>P3 receives the packet and forwards it PE3 based on the DA of
      "PE3".</t>

      <t>PE2 receives the packet with DA as "PE2". "PE2" is the local RGB
      segment and "0100" identifies PE2 itself. The packet is sent to the
      multicast flow overlay.</t>

      <t>PE3 receives the packet with DA as "PE3". "PE3" is the local RGB
      segment and "0010" identifies PE3 itself. The packet is sent to the
      multicast flow overlay.</t>

      <t/>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t/>

      <section title="RGB Option Type">
        <t>Allocation is expected from IANA for a RGB Option Type codepoint
        from the "Destination Options and Hop-by-Hop Options" sub-registry of
        the "Internet Protocol Version 6 (IPv6) Parameters" registry.</t>

        <t><figure align="left">
            <artwork><![CDATA[
        +-----------+-----+-----+-------+-------------+------------+
        | Hex Value | act | chg |  rest | Description | Reference  |
        +-----------+-----+-----+-------+-------------+------------+
        |    TBD    |  01 |  1  |  TBD  | RGB Option | This draft |
        +-----------+-----+-----+-------+-------------+------------+]]></artwork>
          </figure></t>
      </section>

      <section title="End.RGB Function">
        <t>Allocation is expected from IANA for an End.RGB function codepoint
        from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is
        suggested.</t>

        <t><figure align="left">
            <artwork><![CDATA[
        +-------+--------+--------------------------+------------+
        | Value |  Hex   |    Endpoint function     | Reference  |
        +-------+--------+--------------------------+------------+
        | TBD   |  TBD   |    End.RGB              | This draft |
        +-------+--------+--------------------------+------------+]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>The MSR6 domain can be a single IGP area, an anonymous system (AS)
      with multiple IGP areas, or multiple anonymous systems (ASes) operated
      by a network operator.</t>

      <t>It is expected that all nodes in an MSR6 domain are managed by the
      same administrative entity. MSR6-encapsulated packets should generally
      not be accepted from untrusted interfaces or tunnels. For example, an
      operator may wish to have a policy of accepting MSR6 encapsulated
      packets only from interfaces to trusted routers, and not from
      customer-facing interfaces.</t>

      <t>For applications that require a MSR6 Replication Endpoint to accept a
      MSR6 encapsulated packet from an interface to a system that is not
      controlled by the network operator, the security considerations of
      [RFC8296] apply</t>

      <section title="Intra Domain Deployment">
        <t>Generally nodes outside the MSR6 Domain are not trusted: they
        cannot directly use the End.RGB segment of the domain. This is
        enforced by two levels of access control lists:</t>

        <t>1. Any packet entering the MSR6 Domain and destined to an End.RGB
        Segment within the MSR6 Domain is dropped. This may be realized with
        the following logic. Other methods with equivalent outcome are
        considered compliant:</t>

        <t>* allocate all the End.RGB Segment from a block S/s</t>

        <t>* configure each external interface of each edge node of the domain
        with an inbound infrastructure access list (IACL) which drops any
        incoming packet with a destination address in S/s</t>

        <t>* Failure to implement this method of ingress filtering may expose
        the MSR6 Domain to BIER attacks. The security consideration on BIER
        attacks is as described and referenced in <xref
        target="RFC8296"/>.</t>

        <t>2. The distributed protection in #1 is complemented with per node
        protection, dropping packets to End.RGB Segment from source addresses
        outside the MSR6 Domain. This may be realized with the following
        logic. Other methods with equivalent outcome are considered
        compliant:</t>

        <t>* assign all interface addresses from prefix A/a</t>

        <t>* assign all the IPv6 addresses used as source address of MSR6
        packets from a block B/b</t>

        <t>* at node k, all End.RGB Segment IPv6 addresses local to k are
        assigned from prefix Sk/sk</t>

        <t>* configure each internal interface of each MSR6 node k in the MSR6
        Domain with an inbound IACL which drops any incoming packet with a
        destination address in Sk/sk if the source address is not in A/a or
        B/b.</t>

        <t>For simplicity of deployment, a configuration of IACL effective for
        all interfaces can be provided by a router. Such IACL can be referred
        to as global IACL(GIACL) .Each MSR6 node k then simply configures a
        GIACL which drops any incoming packet with a destination address in
        Sk/sk if the source address is not in A/a or B/b for the intra-domain
        deployment mode.</t>

        <t/>
      </section>

      <section title="ICMP Error Processing">
        <t>The MSR6 Replication Endpoint does not send ICMP error messages to
        the source address of a MSR BE packet, but there is still chance that
        Non-MSR6 Replication Endpoint routers send ICMP error messages to
        source nodes within the MSR6 Domain.</t>

        <t>A large number of ICMP may be elicited and sent to a MSR6 Ingress
        router, in case when an MSR6 BE packet is filled with wrong Hop Limit,
        either error or malfeasance. A rate-limiting of ICMP packet should be
        implemented on each MSR6 Replication Endpoint.</t>

        <t>The ingress node can take note of the fact that it is getting, in
        response to MSR6 BE packet, one or more ICMP error packets. By
        default, the reception of such packet MUST be countered and logged.
        However, it is possible for such log entries to be "false positives"
        that generate a lot of "noise" in the log; therefore, implementations
        SHOULD have a knob to disable this logging.</t>

        <t/>
      </section>

      <section title="Security caused by RGB option">
        <t>This document introduces a new option used in IPv6 Destination
        Options Header. An IPv6 packet with a normal IPv6 address of a router
        (e.g. loopback IPv6 address of the router) as destination address will
        possibly carry a RGB option.</t>

        <t>For a router incapable of MSR6 BE, such MSR6 BE packet will not be
        processed by the procedure described in this document, but be
        processed as normal IPv6 packet with unknown option, and the existing
        security considerations for handling IPv6 options apply. Possible way
        of handling IPv6 packets with RGB option may be send to CPU for slow
        path processing, with rate-limiting, or be discarded according to the
        local policy.</t>

        <t>For a router capable of MSR6 BE, such MSR6 BE packet MUST NOT be
        forwarded, but should be processed as a normal IPv6 packet with
        unknown option, or additionally and optionally be countered and logged
        if the router is capable of doing so.</t>

        <t/>
      </section>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"
?>

      <?rfc include='reference.RFC.8296'?>

      <?rfc include='reference.RFC.4301'?>

      <?rfc include='reference.RFC.4302'?>

      <?rfc include='reference.RFC.4303'?>

      <?rfc include='reference.RFC.5374'?>

      <?rfc include='reference.RFC.7296'?>

      <?rfc include='reference.RFC.8754'?>

      <?rfc include='reference.RFC.8402'?>

      <?rfc include='reference.I-D.xie-bier-ipv6-mvpn'?>

      <?rfc include='reference.I-D.ietf-bier-ping'?>

      <?rfc ?>

      <?rfc include='reference.I-D.cheng-spring-ipv6-msr-design-consideration'?>

      <?rfc include="reference.RFC.8279"
?>

      <?rfc include="reference.RFC.8986"?>

      <?rfc include="reference.RFC.8200"
?>

      <?rfc include='reference.I-D.geng-bier-ipv6-inter-domain'?>
    </references>
  </back>
</rfc>
