<?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-xie-bier-ipv6-encapsulation-10"
     ipr="trust200902" obsoletes="" updates="8296">
  <front>
    <title abbrev="Encapsulation for BIER in IPv6">Encapsulation for BIER in
    Non-MPLS IPv6 Networks</title>

    <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="Liang Geng" initials="L." surname="Geng">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing 10053</city>

          <code/>

          <country/>
        </postal>

        <email>gengliang@chinamobile.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M." surname="McBride">
      <organization>Futurewei</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>mmcbride7@gmail.com</email>
      </address>
    </author>

    <author fullname="Rajiv Asati" initials="R." surname="Asati">
      <organization>Cisco</organization>

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

        <email>rajiva@cisco.com</email>
      </address>
    </author>

    <author fullname="Senthil Dhanaraj" initials="S." surname="Dhanaraj">
      <organization>Huawei</organization>

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

        <email>senthil.dhanaraj@huawei.com</email>
      </address>
    </author>

    <author fullname="Yongqing Zhu" initials="Y." surname="Zhu">
      <organization>China Telecom</organization>

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

        <email>zhuyq8@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Zhuangzhuang Qin" initials="Z." surname="Qin">
      <organization>China Unicom</organization>

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

        <email>qinzhuangzhuang@chinaunicom.cn</email>
      </address>
    </author>

    <author fullname="MooChang Shin" initials="M." surname="Shin">
      <organization>LG Uplus</organization>

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

        <email>himzzang@lguplus.co.kr</email>
      </address>
    </author>

    <author fullname="Gyan Mishra" initials="G." surname="Mishra">
      <organization>Verizon Inc.</organization>

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

        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

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

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

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

    <date day="22" month="February" year="2021"/>

    <abstract>
      <t>This document proposes a BIER IPv6 (BIERv6) encapsulation for
      Non-MPLS IPv6 Networks using the IPv6 Destination Option extension
      header. This document updates RFC 8296.</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"/>
      and <xref target="RFC8174"/>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Bit Index Explicit Replication (BIER) <xref target="RFC8279"/> is an
      architecture that provides optimal multicast forwarding without
      requiring intermediate routers to maintain any per-flow state by using a
      multicast-specific BIER header.</t>

      <t><xref target="RFC8296"/> defines a common BIER Header format for MPLS
      and Non-MPLS networks. It has defined two types of encapsulation methods
      using the common BIER Header, (1) BIER encapsulation in MPLS networks,
      here-in after referred as MPLS BIER Header in this document and (2) BIER
      encapsulation in Non-MPLS networks, here-in after referred as Non-MPLS
      BIER Header in this document. <xref target="RFC8296"/> also assigned
      Ethertype=0xAB37 for Non-MPLS BIER Header packets to be directly carried
      over the Ethernet links.</t>

      <t>This document proposes a BIER IPv6 encapsulation for Non-MPLS IPv6
      Networks, defining a method to carry the standard Non-MPLS BIER header
      (as defined in [RFC8296]) in the native IPv6 header. A new IPv6 Option
      type - BIER Option is defined to encode the standard Non-MPLS BIER
      header and this newly defined BIER Option is carried under the
      Destination Options header of the native IPv6 Header <xref
      target="RFC8200"/>.</t>

      <t>The relationship of this document to BIER core standards is listed in
      Appendix A.</t>

      <t>The relevant extensions to BIER Control-plane Standards are listed in
      Appendix B.</t>
    </section>

    <section title="Terminology">
      <t>Readers of this document are assumed to be familiar with the
      terminology and concepts of the documents listed as Normative
      References.</t>

      <t>The following new terms are used throughout this document:</t>

      <t><list style="symbols">
          <t>BIERv6 - Bit indexed explicit replication using IPv6 data
          plane.</t>

          <t>BIERv6 Domain - A limited-domain using BIERv6 encapsulation as
          specified in this document for transporting customer multicast
          packets from one router to multiple destination routers. It is
          usually managed by a single administrative entity, e.g., a
          service-provider. It could be a single AS network or a large-scale
          network that includes multiple ASes. BIER Domain is also used for
          the same meaning as BIERv6 domain in this document.</t>

          <t>BIERv6 Option - An Option type carried in IPv6 Destination
          Options Header (DO header, DOH) which includes the standard Non-MPLS
          BIER Header. It is in type-length-value (TLV) format. The value
          portion of the BIERv6 Option TLV, or the BIERv6 Option Data, is in
          the format of the standard Non-MPLS BIER header. BIER option is also
          used for the same meaning as BIERv6 option in this document.</t>

          <t>BIERv6 Header - An IPv6 Header with BIER Option.</t>

          <t>BIERv6 Packet - An IPv6 packet with BIERv6 Header. An
          IP/IPv6/Ethernet multicast packet is encapsulated with an outside
          BIERv6 header and transformed to a BIERv6 packet on the ingress PE
          (BFIR). BIERv6 packet is transported by the transit routers (BFRs)
          through a BIERv6 domain towards egress PEs(BFERs). BIERv6 packet is
          decapsulated by the BFERs, with the original IP/IPv6/Ethernet
          multicast packet being obtained and forwarded towards the multicast
          receivers .</t>
        </list></t>
    </section>

    <section title="BIER IPv6 Encapsulation">
      <section title="BIER Option in IPv6 Destination Options Header">
        <t>Destination Options Header and the Options that can be carried
        under this extension header is defined in <xref target="RFC8200"/>.
        This document defines a new Option type - BIER Option, to encode the
        Non-MPLS BIER header. As specified in Section 4.2 <xref
        target="RFC8200"/>, the BIER Option follows type-length-value (TLV)
        encoding format and the standard Non-MPLS BIER header <xref
        target="RFC8296"/> is encoded in the value portion of the BIER Option
        TLV.</t>

        <t>This BIER Option MUST be carried only inside the IPv6 Destination
        Options header and MUST NOT be carried under the Hop-by-Hop Options
        header.</t>

        <t>The BIER Option is encoded in type-length-value (TLV) format 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 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~  BIERv6 Option Data (Non-MPLS BIER Header defined in RFC8296) ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ]]></artwork>
          </figure></t>

        <t><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>

            <t hangText="BIERv6 Option Data">The BIERv6 Option Data contains
            the Non-MPLS BIER Header defined in RFC8296. Fields in the
            Non-MPLS BIER Header MUST be encoded as below. <list
                hangIndent="0" style="hanging">
                <t>BIFT-id: The BIFT-id is a domain-wide unique value in
                Non-MPLS IPv6 encapsulation. See Section 2.2 of RFC 8296.</t>

                <t>TC: SHOULD be set to binary value 000 upon transmission and
                MUST be ignored upon. See Section 2.2 of RFC 8296.</t>

                <t>S bit: SHOULD be set to 1 upon transmission, and MUST be
                ignored upon reception. See Section 2.2 of RFC 8296.</t>

                <t>TTL: MUST be set to a value larger than 0 upon
                encapsulation, and SHOULD decrease by 1 by a BFR when
                forwarding a BIERv6 packet to a BFR adjacency. If the incoming
                TTL is 0, the packet is considered to be "expired". See
                Section 2.1.1.2 of RFC 8296.</t>

                <t>Nibble: SHOULD be set to 0000 upon transmission, and MUST
                be ignored upon reception. See Section 2.2 of RFC 8296.</t>

                <t>Ver: MUST be set to 0 upon transmission, and MUST be
                discarded when it is not 0 upon reception. See Section 2.2 of
                RFC 8296.</t>

                <t>BSL: See Section 2.1.2 of RFC 8296.</t>

                <t>Entropy: See Section 2.1.2 of RFC 8296.</t>

                <t>OAM: See Section 2.1.2 of RFC 8296.</t>

                <t>Rsv: See Section 2.1.2 of RFC 8296.</t>

                <t>DSCP: SHOULD be set to binary value 000000 upon
                transmission and MUST be ignored upon reception. In BIERv6
                encapsulation, uses Traffic Class field of IPv6 header
                instead.</t>

                <t>Proto: SHOULD be set to 0 upon transmission and be ignored
                upon reception. In BIERv6 encapsulation, the functionality of
                this 6-bit Proto field is replaced by the Next Header field in
                Destination Options header or the last IPv6 extension header
                to indicate the type of the payload. This updates section
                2.1.2 of <xref target="RFC8296"/> about Proto definition. Next
                Header value in BIERv6 encapsulation for common usage
                includes: <list hangIndent="0" style="hanging">
                    <t>Value 4 for IPv4 packet as BIERv6 payload.</t>

                    <t>Value 41 for IPv6 packet as BIERv6 payload.</t>

                    <t>Value 143 for Ethernet packet as BIERv6 payload.</t>
                  </list></t>

                <t>Multicast VPN (MVPN) service is considered as part of the
                BIER layering mode defined in [RFC8279], and should be
                supported by BIERv6 encapsulation. <xref
                target="I-D.xie-bier-ipv6-mvpn"/> illustrates how MVPN is
                supported in BIERv6 encapsulation without using this Proto
                field.</t>

                <t>BIER-PING <xref target="I-D.ietf-bier-ping"/> is considered
                a useful function of the BIER architecture, and should be
                supported by BIERv6 encapsulation. How BIER-PING is supported
                in BIERv6 encapsulation without using this Proto field is
                outside the scope of this document.</t>

                <t>BFIR-id: See Section 2.1.2 of RFC 8296.</t>

                <t>BitString: See Section 2.1.2 of RFC 8296.</t>
              </list></t>
          </list></t>
      </section>

      <section title="Destination Address in BIERv6 Encapsulation">
        <t>When a BIERv6 packet is replicated to a next hop BFR, an unicast
        address of the next hop BFR is used as the destination address of the
        BIERv6 packet. Considerations of using unicast (or multicast) address
        is listed in Appendix C.</t>

        <t>The unicast address used in BIERv6 packet targeting a BFR SHOULD be
        advertised as part of the BIER IPv6 Encapsulation. When a BFR
        advertises the BIER information with BIERv6 encapsulation capability,
        an IPv6 unicast address of this BFR MUST be selected specifically for
        BIERv6 packet forwarding. Locally this "BIER Specific" IPv6 address is
        initialized in FIB with a flag of "BIER specific handling",
        represented as End.BIER function.</t>

        <t>If a BFR belongs to more than one sub-domain, it may (though it
        need not) have a different End.BIER in each sub-domain. If different
        End.BIER is used for each sub-domain, implementation SHOULD support
        verifying the DA of a BIERv6 packet is the End.BIER address bound by
        the sub-domain of the packet.</t>

        <t>For security deployment of BIERv6, the End.BIER address(es) is
        required to be allocated from an IPv6 address block, and the IPv6
        address block is used for domain boundary security policy. See section
        5.1 of this document for such security policy. Such kind of security
        policy using IPv6 address block follows the paradigm settled by the
        <xref target="RFC8754"/> section 5.</t>

        <t>Deployment of BIERv6 in SRv6 network is allowed. In this case, the
        BIERv6 domain is the same as SRv6 domain, and the End.BIER address is
        allocated from the locator of SRv6.</t>

        <t>To better understand the configuration mode of End.BIER address in
        BIERv6, <xref target="I-D.geng-bier-bierv6-yang"/> could be
        referenced.</t>

        <t>For the convenience of such co-existence of BIERv6 and SRv6, the
        indication of End.BIER or "BIER specific handling" in FIB shares the
        same space as SRv6 Endpoints Behaviors defined in <xref
        target="I-D.ietf-spring-srv6-network-programming"/>.</t>

        <t>The following is an example pseudo-code of the End.BIER
        function:</t>

        <t><figure>
            <artwork align="left"><![CDATA[
    1. IF NH = 60 and HopLimit > 0                               ;;Ref1
    2.   IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2
    3.     Lookup the BIER Header inside the BIER option TLV.
    4.     Forward via the matched entry.
    5.   ELSE                                                    ;;Ref3
    6.     Drop the packet and end the process.
    7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6)           ;;Ref4
    8.   Send to CPU.
    9. ELSE                                                      ;;Ref5
   10.   Drop the packet.
 ]]></artwork>
          </figure>Ref1: Destination options header follows the IPv6 header
        directly and HopLimit is bigger than zero.</t>

        <t>Ref2: The first TLV is BIER type and is the only TLV present in
        Destination options header.</t>

        <t>Ref3/Ref5: Undesired packet is droped because the destination
        address is the BIER specific IPv6 address (End.BIER function).</t>

        <t>Ref4: An ICMPv6 packet using End.BIER as destination address.</t>

        <t/>
      </section>

      <section title="BIERv6 Packet Format">
        <t>As a multicast packet enters the BIER domain in a Non-MPLS IPv6
        network, the multicast packet will be encapsulated with BIERv6 Header
        by the Ingress BFR (BFIR).</t>

        <t>Typically a BIERv6 header would contain the Destination Options
        Header as the only Extensions Header besides IPv6 Header, as depicted
        in the below figure.</t>

        <t><figure>
            <artwork align="left"><![CDATA[
   +---------------+------------------+----------------------+
   |  IPv6 header  |  IPv6 DO Header  |      X type of       |
   |               | with BIER Option |  C-multicast packet  |
   |               |                  |                      |
   | Next Hdr = 60 |   Nxt Hdr = X    | (IPv4/IPv6/Ethernet) |
   +---------------+------------------+----------------------+
   |                                  |                      |
   |<----------BIERv6 header--------->|<---BIERv6 payload--->|
          ]]></artwork>
          </figure></t>

        <t>Format of the multicast packet with BIERv6 encapsulation carrying
        other extension headers along with Destination Options extension
        header is required to follow general recommendations of [RFC8200] and
        examples in other RFCs. <xref target="RFC6275"/> introduces how the
        order should be when other extension headers carries along with Home
        address option in a destination options header. Similar to this
        example, this document requires the Destination Options Header
        carrying the BIER option MUST be placed as follows:</t>

        <t><list style="symbols">
            <t>After the routing header, if that header is present</t>

            <t>Before the Fragment Header, if that header is present</t>

            <t>Before the AH Header or ESP Header, if either one of those
            headers is present</t>
          </list></t>

        <t>Source Address field in the IPv6 header MUST be a routable IPv6
        unicast address of the BFIR in any case.</t>

        <t>BFIR encodes the BIERv6 header in the above mentioned encapsulation
        format and forwards the BIERv6 packet to the nexthop BFR following the
        local BIFT table.</t>

        <t>BFRs in the IPv6 network, processes and replicates the packets
        towards the BFERs using the local BIFT table. The BitString field in
        the BIERv6 Option Data may be changed by the BFRs as they replicate
        the packet. BFRs MUST follow the procedures defined in section 3.1 as
        they modify the other fields in the BIERv6 Option Data. The source
        address in the IPv6 header MUST NOT be modified by the BFRs.</t>
      </section>
    </section>

    <section title="BIERv6 Packet Processing">
      <t>When a multicast packet enters the BIER domain, the Ingress BFR
      (BFIR) encapsulates the multicast packet with a BIERv6 Header,
      transforming it to a BIERv6 packet. The BIERv6 header includes an IPv6
      header and a BIERv6 Option in IPv6 Destination Options Header. Source
      Address field in the IPv6 header MUST be set to a routable IPv6 unicast
      address of the BFIR. Destination Address field in the IPv6 header is set
      to the End.BIER address of the next-hop BFR the BIERv6 packet
      replicating to, no matter next-hop BFR is directly connected (one-hop)
      or not directly connected (multi-hop).</t>

      <t>Upon receiving an BIERv6 packet, the BFR processes the IPv6 header
      first. This is the general procedure of IPv6.</t>

      <t>If the IPv6 Destination address is an End.BIER IPv6 unicast address
      of this BFR, a 'BIER Specific Handling' indication will be obtained by
      the preceding Unicast DA lookup (FIB lookup). The BIER option, if
      exists, will be checked to decide which neighbor(s) to replicate the
      BIERv6 packet to.</t>

      <t>It is a local behavior to handle the combination of extension
      headers, options and the BIER option(s) in destination options header
      when a 'BIER Specific Handling' indication is got by the preceding FIB
      lookup. Early deployment of BIERv6 may require there is only one BIER
      option TLV in the destination options header followed the IPv6 header.
      How other extension headers or more BIER option TLVs in a BIERv6 packet
      is handled is outside the scope of this document.</t>

      <t>A packet having a 'BIER Specific Handling' indication but not having
      a BIER option is supposed to be a wrong packet or an ICMPv6 packet, and
      the process can be referred to the example in section 3.2.</t>

      <t>A packet not having a 'BIER Specific Handling' indication but having
      a BIER option SHOULD be processed normally as unicast forwarding
      procedures, which may be a behavior of drop, or send to CPU, or other
      behaviors in existing implementations.</t>

      <t>The Destination Address field in the IPv6 Header MUST change to the
      nexthop BFR's End.BIER Unicast address in BIERv6.</t>

      <t>The Hop Limit field of IPv6 header MUST decrease by 1 when sending
      packets to a BFR neighbor, while the TTL in the BIER header MUST be
      unchanged on a Non-BIER router, or decrease by 1 on a BFR.</t>

      <t>The BitString in the BIER header in the Destination Options Header
      may change when sending packets to a neighbor. Such change of BitString
      MUST be aligned with the procedure defined in RFC8279. Because of the
      requirement to change the content of the option when forwarding BIERv6
      packet, the BIER option type should have chg flag 1 per section 4.2 of
      RFC8200.</t>

      <t>The procedures applies normally if a bit corresponding to the self
      bfr-id is set in the BitString field of the BIERv6 Option Data of the
      BIERv6 packet. The node is considered to be an Egress BFR (BFER) in this
      case. The BFER removes the BIERv6 header, including the IPv6 header and
      the Destination Options header, and copies the packet to the multicast
      flow overlay. The egress VRF of a packet may be determined by a further
      lookup on the IPv6 source address instead of the upstream-assigned MPLS
      Label as described in <xref target="RFC8556"/>.</t>

      <t>The Fragment Header, AH Header or ESP Header, if exists after the
      BIER options header, can be processed on BFER only as part of the
      multicast flow overlay process.</t>

      <t>The following diagram shows the whole progression of the multicast
      packet as it enters the BIERv6 domain on PE1, and leaves the BIERv6
      domain on PE2 and PE3.</t>

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

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

      <t><list hangIndent="0" style="symbols">
          <t>PE1 is Provider Edge router, acting as BFIR.</t>

          <t>P2 is Provider Core router, acting as BFR.</t>

          <t>P1 and P3 are IPv6 routers, acting as Non-BFR.</t>

          <t>PE2 and PE3 are Provider Edge routers, acting as BFER.</t>

          <t>CE1 and CE2 are Customer Edge routers.</t>
        </list></t>
    </section>

    <section title="Security Considerations">
      <t>BIER IPv6 encapsulation provides a new encapsulation based on IPv6
      and BIER to transport multicast data packet in a BIER domain. The BIER
      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. A single BIER Sub-domain may be deployed through the whole
      BIER Domain, as illustrated in <xref
      target="I-D.geng-bier-ipv6-inter-domain"/>.</t>

      <t>This section reviews security considerations related to the BIER IPv6
      encapsulation, based on security considerations of [RFC8279], [RFC8296],
      and other documents related to IPv6 extension.</t>

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

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

      <t>BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause
      security problems. See section 5.2 for ICMP related problems.</t>

      <t>This document introduces a new option used in IPv6 Destination
      Options Header, together with the special-use IPv6 address called
      End.BIER in IPv6 destination address for BIER IPv6 forwarding. However
      the option newly introduced may be wrongly used with normal IPv6
      destination address. See section 5.3 for problems introduced by the new
      IPv6 option with normal IPv6 destination address.</t>

      <t>If the multicast data packet of a BIERv6 packet is altered by an
      intermediate router, contents of the multicast data packet will be
      damaged. BIER IPv6 encapsulation provides the ability of IPsec to ensure
      the confidentiality or integrity for multicast data packet. See section
      5.4 for this security problem.</t>

      <t>If the BIERv6 encapsulation of a particular packet specifies a
      BitString (together with SI) other than the one intended by the BFIR,
      the packet is likely to be misdelivered. Some modifications of the BIER
      encapsulation, e.g., setting every bit in the BitString, may result in
      denial-of-service (DoS) attacks. This kind of DoS attack is a challenge
      not only in BIERv6 but also in BIER as specified in [RFC8279] and
      [RFC8296], as the BitString is required to change on BFR per the BIER
      forwarding procedures. This document does not provide new mechanisms to
      improve this kind of weakness.</t>

      <t>A BIER router accepts and uses the End.BIER IPv6 address to construct
      BIFT only when the IPv6 address is configured explicitly, or received
      from a router via control-plane protocols. The received information is
      validated using existing authentication and security mechanisms of the
      control-plane protocols. BIER IPv6 encapsulation does not define any
      additional security mechanism in existing control-plane protocols, and
      it inherits any security considerations that apply to the control-plane
      protocols.</t>

      <t/>

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

        <t>1. Any packet entering the BIER Domain and destined to an End.BIER
        IPv6 Address within the BIER 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.BIER IPv6 Address 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 exposes the
        BIER Domain to BIER attacks as described and referenced in
        [RFC8296].</t>

        <t>2. The distributed protection in #1 is complemented with per node
        protection, dropping packets to End.BIER IPv6 Address from source
        addresses outside the BIER 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 BIER IPv6
        packets from a block B/b</t>

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

        <t>* configure each internal interface of each BIER node k in the BIER
        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 BIER node k then simply configs 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 BIERv6 BFR does not send ICMP error messages to the source
        address of a BIERv6 packet, there is still chance that Non-BFR routers
        send ICMP error messages to source nodes within the BIER Domain.</t>

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

        <t>The ingress node can take note of the fact that it is getting, in
        response to BIER IPv6 packet, one or more ICMP error packets. By
        default, the reception of such a packets 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 BIER 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 BIER option.</t>

        <t>For a router incapable of BIERv6, such BIERv6 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 BIER 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 BIERv6, such BIERv6 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 title="Applicability of IPsec">
        <t>IPsec <xref target="RFC4301"/> uses two protocols to provide
        traffic security services -- Authentication Header (AH) <xref
        target="RFC4302"/> and Encapsulating Security Payload (ESP) <xref
        target="RFC4303"/>. Each protocol supports two modes of use: transport
        mode and tunnel mode. IPsec support both unicast and multicast. IPsec
        implementations MUST support ESP and MAY support AH.</t>

        <t>This document assume IPsec working in tunnel mode with inner IPv4
        or IPv6 multicast packet encapsulated in outer BIERv6 header and IPsec
        header(s).</t>

        <t>IPsec used with BIER IPv6 encapsulation to ensure that a BIER
        payload is not altered while in transit between BFIR and BFERs. If a
        BFR in between BFIR and BFERs is compromised, there is no way to
        prevent the compromised BFR from making illegitimate modifications to
        the BIER payload or to prevent it from misforwarding or misdelivering
        the BIER-encapsulated packet, but the BFERs will detect the
        illegitimate modifications to the BIER Payload (or the inner multicast
        data packet). This could provide cryptographic integrity protection
        for multicast data transport. This capability of IPsec comes from the
        design that, the destination options header carrying the BIER header
        is located before the AH or ESP and the BFR routers in between BFIR
        and BFERs can process the BIER header without aware of AH or ESP.</t>

        <t>For ESP, the Integrity Check Value (ICV) is computed over the ESP
        header, Payload, and ESP trailer fields. It doesn't require the IP or
        extension header for ICV calculating, and thus the change of DA and
        BIER option data does not affect the function of ESP.</t>

        <t>For AH, the Integrity Check Value (ICV) is computed over the IP or
        extension header fields before the AH header, the AH header, and the
        Payload. The IPv6 DA is immutable for unicast traffic in AH, and the
        change of DA in BIER IPv6 forwarding for multicast traffic is
        incompatible to this rule. How AH is extended to support multicast
        traffic transporting through BIER IPv6 encapsulation is outside the
        scope of this document.</t>

        <t>The detailed control-plane for BIER IPv6 encapsulation IPsec
        function is outside the scope of the document. Internet Key Exchange
        Protocol Version 2 (IKEv2) <xref target="RFC7296"/> and Group Security
        Association (GSA) <xref target="RFC5374"/> can be referred to for
        further studying.</t>

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

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

      <section title="BIER Option Type">
        <t>Allocation is expected from IANA for a BIER 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  | BIER Option | This draft |
        +-----------+-----+-----+-------+-------------+------------+]]></artwork>
          </figure></t>
      </section>

      <section title="End.BIER Function">
        <t>Allocation is expected from IANA for an End.BIER 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.BIER              | This draft |
        +-------+--------+--------------------------+------------+]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="Implementation Status">
      <t>Implementation of BIERv6 as described in this document and related
      drafts defined in appendix B has been operational.</t>

      <t>In February 2021, China Unicom successfully validated this BIERv6
      solution over its Beijing Metro network.</t>

      <t>The BIERv6 test network contains the following network devices:</t>

      <t>STB, ONT, OLT, BFER,non-BFR, BFR, BFIR, Switch, CR (Core Router,
      video flow input node)</t>

      <t>where BIERv6 capable nodes include:</t>

      <t><list style="symbols">
          <t>BFER: Huawei ATN980C</t>

          <t>BFR&amp;BFIR: Huawei NE40E</t>
        </list></t>

      <t>and IPv6 capable nodes include:</t>

      <t><list style="symbols">
          <t>non-BFR: Cisco ASR 9006</t>
        </list></t>

      <t>BIERv6 test is composed of the following scenarios:</t>

      <t><list style="symbols">
          <t>Intra-AS BIERv6: mechanisms defined in this document and <xref
          target="I-D.xie-bier-ipv6-isis-extension"/> are validated.</t>

          <t>Inter-AS BIERv6: mechanisms defined in <xref
          target="I-D.geng-bier-ipv6-inter-domain"/> are validated.</t>

          <t>IPv4 multicast traffic over BIERv6 MVPN. Mechanisms defined in
          <xref target="I-D.xie-bier-ipv6-mvpn"/> are validated.</t>

          <t>Deployment of Intra-AS and Inter-AS BIERv6 with non-BIERv6
          capable intermediate nodes, where these nodes only need to be IPv6
          capable.</t>

          <t>BIERv6 Ping</t>

          <t>Deterministic convergence as indicated in <xref
          target="RFC8279"/>, where intermediate link or BFR node fails.</t>

          <t>Service reliability where BIERv6 source side link or BFIR node
          fails.</t>

          <t>Service reliability where BIERv6 receiver side link or BFER node
          fails.</t>
        </list></t>
    </section>

    <section title="Acknowledgements">
      <t>The authors would like to thank Stig Venaas for his valuable
      comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda,
      Toerless Eckert, Jeffrey Zhang, Pascal Thubert for the helpful comments
      to improve this document.</t>

      <t>Thanks Aijun Wang for comments about BIER OAM function in BIER IPv6
      encapsulation.</t>

      <t>Thanks Mach Chen for review and suggestions about BIER-PING function
      in BIER IPv6 encapsulation.</t>
    </section>

    <section title="Contributors">
      <t>Gang Yan</t>

      <t>Huawei Technologies</t>

      <t>China</t>

      <t>Email: yangang@huawei.com</t>

      <t/>

      <t>Yang(Yolanda) Xia</t>

      <t>Huawei Technologies</t>

      <t>China</t>

      <t>Email: yolanda.xia@huawei.com</t>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.RFC.8401'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-bier-ipv6-requirements'?>

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

      <?rfc include='reference.I-D.ietf-spring-srv6-network-programming'?>

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

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

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

      <?rfc include='reference.I-D.geng-bier-bierv6-yang'?>
    </references>

    <section title="Relationship to BIER Core Standards">
      <t>The BIER architecture [RFC8279] is inherited in this BIERv6 proposal,
      and the layering mode of BIER architecture is fully supported with some
      necessary extension to the data plane as well as the control plane
      standards.</t>

      <t>The focus of this document is BIERv6 data plane, including the BIERv6
      encapsulation and packet forwarding procedures. The common BIER header
      encoding [RFC8296] is maximum reused in this BIERv6 proposal.</t>

      <t>To better understand the overall BIER IPv6 problem space and
      requirements, refer to <xref
      target="I-D.ietf-bier-ipv6-requirements"/>.</t>
    </section>

    <section title="Extensions to BIER Control-plane Standards">
      <t>The relevant control-plane documents that have done or still to be
      done are listed below.</t>

      <t><list style="symbols">
          <t>Based on <xref target="RFC8401"/>, IS-IS extension is defined in
          <xref target="I-D.xie-bier-ipv6-isis-extension"/> for intra-AS
          BIERv6 information advertisement and BIRT/BIFT building.</t>

          <t>OSPFv3 extension for intra-AS BIERv6 information advertisement
          and BIRT/BIFT building is to be defined.</t>

          <t>Based on this BIERv6 encapsulation, <xref
          target="I-D.geng-bier-ipv6-inter-domain"/> illustrates how inter-AS
          BIRT/BIFT are built and how inter-AS multicast deployment is
          supported.</t>

          <t>BGP extension for inter-AS BIERv6 information advertisement and
          BIRT/BIFT building is to be defined.</t>

          <t>Based on <xref target="RFC8556"/>, BGP-MVPN using BIERv6
          encapsulation is defined in <xref target="I-D.xie-bier-ipv6-mvpn"/>
          for multicast service deployment.</t>
        </list></t>
    </section>

    <section title="Considerations of Using Unicast Address">
      <t>BIER is generally a hop-by-hop and one-to-many architecture, and thus
      the IPv6 Destination Address (DA) being a Multicast Address is a way one
      may think of as an approach for both the two paradigms in BIERv6
      encapsulation.</t>

      <t>However using a unicast address has the following benefits:</t>

      <t><list style="numbers">
          <t>Replicating a BIERv6 packet over a non-BIER capable router.</t>

          <t>Fast rerouting a BIERv6 packet using a unicast by-pass
          tunnel.</t>

          <t>Forwarding a BIERv6 packet to one of the many BFR neighbors
          connected on a LAN without imposing new requirements of snooping on
          switches.</t>

          <t>Replicating a BIERv6 packet through an anonymous system(AS) to
          BFERs in other ASes, as illustrated in <xref
          target="I-D.geng-bier-ipv6-inter-domain"/>.</t>
        </list></t>

      <t>Some of the above scenarios are assumed part of BIER architecture as
      described in [RFC8279], and some of them are the scalability aspects for
      inter-AS stateless multicast this document intends to support. This
      document intends to fulfil all these requirements (categorized as
      multi-hop replication), and proposes to use unicast address for both
      one-hop replication and multi-hop replication.</t>
    </section>
  </back>
</rfc>
