Network Working Group                                         M. McBride
Internet-Draft                                                 Futurewei
Intended status: Standards Track Informational                                    J. Xie
Expires: January 29, March 20, 2021                                          X. Geng
                                                             S. Dhanaraj
                                                                R. Asati
                                                                  Y. Zhu
                                                           China Telecom
                                                               G. Mishra
                                                            Verizon Inc.
                                                           July 28,
                                                                Z. Zhang
                                                      September 16, 2020

                         BIER IPv6 Requirements


   The BIER WG charter includes work on developing "a mechanism to use
   BIER natively in IPv6".

   There have been several proposed solutions with BIER being used in this area.
   IPv6.  But there hasn't been a document which describes the problem
   and lists the requirements.  The goal of this document is to describe
   the general BIER IPv6 requirements, encapsulation problem, summarize the
   encapsulation modes of the proposed solutions, guide detail solution
   requirements, and assist the working group in
   understanding the benefits and drawbacks of the various solutions,
   and help in the development of
   acceptable solutions.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 29, March 20, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Conceptual Models For BIER IPv6 Encapsulation and Forwarding    4
     3.1.  Transport-Independent  Independent Model . . . . . . . . . . . . . . .   5
     3.2.  Native IPv6 Model . . . . . . . . . . .   4
     3.2.  Integrated Model  . . . . . . . . .   6
     3.3.  Encapsulation Approaches Considered . . . . . . . . . . .   7   5
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   7   5
     4.1.  Mandatory Requirements  . . . . . . . . . . . . . . . . .   8   6
       4.1.1.  Support various L2 Agnostic . . . . . . . . . link types . . . . . . . . . . . .   8   6
       4.1.2.  Support BIER architecture . . . . . . . . . . . . . .   8   6
       4.1.3.  Conform to existing IPv6 Spec . . . . . . . . . . . .   8
       4.1.4.  Support deployment with Non-BFR routers . . . . . . .   8
       4.1.5.  Support inter-AS multicast deployment . . . . . . . .   8
       4.1.6.   6
       4.1.4.  Support Simple Encapsulation  . . . . OAM . . . . . . . .   9
       4.1.7.  Support Deployment Security . . . . . . . . . . . . .   9   6
     4.2.  Optional Requirements . . . . . . . . . . . . . . . . . .   9   7
       4.2.1.  Support MVPN  . . . . Fragmentation . . . . . . . . . . . . . . . .   9   7
       4.2.2.  Support OAM . . . . . . . . . . . . . . . . . . . . .   9
       4.2.3.  Support IPSEC ESP . . . . . . . . . . . . . . . . . . . .   9
       4.2.4.  Support Fragmentation . . . . . . . . . . . . . . . .   9
       4.2.5.  Support hardware fast path  . . . . . . . . . . . . .  10   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10   8
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  10   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  10   8
   Appendix A.  List of Solutions Evaluation . . . . . . . . . .  . . . . . .  12
     A.1.  BIER-ETH encapsulation in IPv6 networks . . . . . . . . .  12
     A.2.  Encode Bitstring in IPv6 destination address  . . . . . .  13
     A.3.  Add BIER header into IPv6 Extension Header  .   9
     A.1.  Integrated mode approach  . . . . . .  13
     A.4.  Transport BIER as IPv6 payload . . . . . . . . . .   9
     A.2.  Independent model approach  . . .  14
     A.5.  Tunnelling BIER in a IPv6 tunnel . . . . . . . . . . . .  15  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15  11

1.  Introduction

   Bit Index Explicit Replication (BIER) [RFC8279] is an architecture
   that provides optimal multicast forwarding, without requiring
   intermediate routers to maintain per-flow state, through the use of a
   multicast-specific BIER header.  [RFC8296] defines two types of BIER
   encapsulation to run on physical links:
   encapsulation: one is BIER MPLS encapsulation to run on various physical links that support MPLS, the for MPLS environments,
   the other is non-MPLS BIER Ethernet encapsulation to run on ethernet
   links, with an ethertype 0xAB37. without MPLS.  This
   document describes using non-MPLS BIER encapsulation in non-MPLS IPv6 environments.
   We explain the requirements of transporting IPv4/IPv6 multicast payloads
   overlay payload through an IPv6 network underlay using "BIER natively in IPv6".  As clarified in BIER.  The
   solutions may require the working-group,
   "BIER natively in IPv6" means BIER not encapsulated in MPLS or
   Ethernet.  This use of IPv6 forwarding plane and may
   include native IPv6 encapsulation and and/or generic IPv6 tunnelling.  The goal of this document is to help the BIER WG
   evaluate the BIER v6 requirements and solutions in order to begin
   adopting solution drafts.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.2.  Terminology

   o  BIER: Bit Index Explicit Replication.  Provides optimal multicast
      forwarding through adding a BIER header and removing state in
      intermediate routers.

   o  BUM: Broadcast, Unknown Unicast, Multicast.  Term used to describe
      the three types of Ethernet modes that will be forwarded to
      multiple destinations

2.  Problem Statement

   The problem is the ability of the network how to transport BUM multicast packets, with non-MPLS BIER headers,
   encapsulation, in an IPv6 environment.  In many  We need to determine where to
   put the BIER header in this IPv6 environment.  With IPv6 network
   deployments, non-MPLS
   encapsulation is being increasingly used for unicast services, such as the data-
   plane.  It is likewise expected
   VPN or L2VPN, it may be desirable to have BIER IPv6 deployments which
   depend on these same unicast technologies to traverse through non-BFR

   One such case involves supporting a non-BFR router in a network as
   described encapsulation also
   used in section 6.9 of RFC8279.  In the context of this
   document, an IPv6 based unicast tunnel is needed to support such
   deployment where a non-BFR exists.  Another case is to support inter-
   AS BIER deployments for multicast deployment as illustrated in
   [I-D.geng-bier-ipv6-inter-domain].  In services such deployment, there are
   non-BFR routers, or even an entire non-BIER network, that needs the
   ability to traverse from one BFR to another.
   [I-D.ietf-bier-use-cases] shows it is possible there are other cases
   where inter-AS multicast deployment is required.

   As with IPv6, another problem of BIER IPv6 technology as MVPN.  It may
   also be
   "Transition Mechanisms and Partial Deployments" which is listed as
   the No.1 charter item of BIER WG.  Therefore, a basic requirement of
   BIER desirable to not use IPv6 encapsulation except when IPv6
   tunneling (native or GRE/UDP-like) is used to leverage IPv6 reachability for incremental and inter-
   AS transport BIER deployment. packets
   over BIER-incapable routers.

   Below is a simple scenario that needs BIER IPv6 encapsulation and IPv6-based forwarding:

         |                                            |
         |                                         +------+
         |                                         | BFER |
     +------+       +-------+       +-----+        +------+
     | BFIR |       |Non-BFR|       | BFR |           |
     +------+       +-------+       +-----+        +------+
         |                                         | BFER |
         |                IPv6 Network             +------+
         |           (intra-AS or inter-AS)                                            |

   This scenario depicts the need to replicate bier BIER packets from a BFIR
   to BFERs across an IPv6 Service Provider core.  The  Inside the IPv6 environment may include a
   variety of link types, may be entirely IPv6, may be dual stack or any
   type of combination which includes IPv6.  Regardless of the
   environment, there are times when a BIER header, including
   network, the BIER
   BitString header is used to determine direct the set of BIER forwarding egress
   routers, will need packet from one BFR to traverse
   the next BFRs, and either a IPv6 domain. header or an L2/tunnel header is
   used to provide reachability between BFRs.  The ways in which BIER
   will function IPv6 environment may
   include a variety of link types, may be entirely IPv6, or may be dual
   stack.  There may be cases where not all routers are BFR capable in an
   the IPv6 environment is but still want to deploy BIER.  Regardless of
   the environment, the problem that needs is to be
   solved. deploy BIER, with non-MPLS BIER
   encapsulation, in an IPv6 network.

3.  Conceptual Models For BIER IPv6 Encapsulation and Forwarding

   This analysis introduces two conceptual models for BIER in IPv6
   encapsulation and forwarding
   networks based on the experience and examples
   that have been seen solutions discussed in the IETF

3.1.  Transport-Independent  Independent Model

   The first conceptual model is an Independent Model, where IPv6 is
   nothing special to BIER but a Transport-Independent Model transportation means that
   views IP tunnels as links of BIER, may be used
   just like other transportation means, and views BIER as an independent

         |<----------(L2.5 is nothing special to
   IPv6 but a payload type just like other payload types.

         |<<-----(BIER-based multicast overlay)----->>|
         |                                            |
         |<---------(L2.5 BIER(P2MP) Tunnel)-------->| Tunnel)--------->|
         |                                            |
         |  TEP                  TEP      TEP    TEP  |
         |    +~~~~~~~~~~~~~~~~~~+          +~~~~+          +BIER+    |
         |   /                    \        /      \   |
     +------+       +-------+       +-----+   or   +------+
     | BFIR |-------|Non-BFR|-------| BFR |--------| |--BIER--| BFER |
     +------+       +-------+       +-----+        +------+
     ------- physical L2 link

     ~~~~~~~ IPv6(P2P) tunnel (TEP = Tunnel EndPoint)

     <-----> BIER(P2MP) tunnel

   In this model, an IPv6 tunnel works as a link-layer of BIER, and BIER
   works as a transport-independent layer (or layer-2.5) layer-2.5 over tunnels or L2 links.  Between two BFRs,
   either a virtual- L2 link can be used directly or any tunnel (IPv6 tunnel).  On each BFR, or not) can
   be used for BIER transport.  In the IPv6 tunnel of case, the receiving
   packet is decapsulated, and a new IPv6 transmitting BFR
   adds tunnel is encapsulated before
   sending the packet to encapsulation (e.g.  IPv6 header) and the next-hop receiving BFR neighbour.

   removes the view tunnel encapsulation.

   General consideration of the this model is to keep BIER and IPv6 layer, the
   independent of each other.  The BIER header is a kind of Upper-
   layer header (Layer-4).  From the view not part of the BIER layer, the IPv6
   encapsulation is a tunnel working as a "link" of BIER.  With an End-
   to-End view,
   header but comes after the transport header (L2 or tunnel from BFIR to BFERs is a Layer-2.5 BIER (P2MP)
   tunnel, header) and the BFIR-id is the
   before BIER packet source-origin identifier,
   and payload.

3.2.  Integrated Model

   The second conceptual model is unchanged through the BIER domain from BFIR to BFERs.

   This model is similar to the "MPLS over IP" [RFC4023] or "MPLS over
   UDP" [RFC7510] approach.  A more general output of such approach in
   IETF is "MPLS Segment Routing over IP" [RFC8663].  It makes use of
   IPv4/IPv6 tunnel, IPv4/IPv6 UDP tunnel and IPv4/IPv6 GRE tunnel to
   encapsulate the MPLS-based instructions.  In fact, BIER-MPLS could
   use this approach directly since BIER-MPLS is based on MPLS.

   There may be, however, in certain cases some difficulty with
   allocation of an MPLS label and advertisement through the control-
   plane.  For example, a simple inter-AS BIER deployment may want to
   use the auto-configuration of BIFT-id using Non-MPLS BIER
   encapsulation [RFC8296] as illustrated in
   [I-D.geng-bier-ipv6-inter-domain].  This brings the need of a new
   "Next Header" value to indicate the "Non-MPLS" BIER header.

   For IPv4/IPv6 GRE, the "Next Header" is the 16-bit "Protocol Type"
   field, and has adequate space for such requirement.

   For IPv4/IPv6 UDP, the "Next Header" is the 16-bit "Destination Port"
   field, and has adequate space for such requirement.

   For IPv4/IPv6, the "Next Header" is a 8-bit value and needs to be
   allocated from the "Assigned Internet Protocol Numbers" registry.

   Reassembly/Re-fragmentation of a packet has to be executed on each
   BFR in such case.  This may be common and even friendly for a
   protocol stack in a BFR software implementation, but it may impose
   cost for a BFR hardware implementation.

   IPv6 functions that are expected to be executed from BFIR to BFER are
   assumed to be broken on the BFRs, for example, IPv6 Fragmentation/
   Assembly or IPSEC ESP.  This is because the "IPv6 tunnel" and all its
   functions is "terminated" on the BFRs.  These functions, if desired,
   may need to be re-designed in the "Layer-2.5" BIER mode.

   For deployment security, it is necessary to ensure the "BIER" packet
   is only using the allowed IPv6 tunnel.

3.2.  Native IPv6 Model

   The second conceptual model is a Native IPv6 Model that integrates an Integrated Model that integrates
   BIER as part of the IPv6 data plane, making it a "Layer-3 BIER"

         |<<-----(BIER-based multicast overlay)----->>|
         |                                            |
         |<----------(L3 BIER(P2MP) tunnel)--------->| tunnel)---------->|
         |                                            |
         |  SEP                 SEP       SEP    SEP  |
         |    +~~~~~~~~~~~~~~~~~~+          +~~~~+    |
         |   /                    \        /      \   |
     +------+       +-------+       +-----+        +------+
     | BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
     +------+       +-------+       +-----+        +------+

     ------- physical L2 link

     ~~~~~~~ IPv6(P2P) segment (SEP = Segment EndPoint)

     <-----> BIER(P2MP) tunnel

   In this model, BIER works as part of the IPv6 data plane.  The BFIR
   and BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6
   segment endpoints.  On  The BIER header is processed on each BFR, the segment
   endpoint behaviour of
   IPv6 data plane is executed, and there is no decapsulation of
   receiving IPv6 tunnel and encapsulation of new IPv6 tunnel for

   In this mode, the BIER header is integrated into decapsulation, or re-encapsulation, on the
   segment endpoints.

   This model typically needs an IPv6 extension header to carry the BIER
   header.  and processing of the BIER header (e.g., the BitString) is will
   be implemented as part of the IPv6 extension header processing.  The
   IPv6 source address is the BIER packet source-origin identifier, and
   is unchanged through the BIER domain from BFIR to BFERs.


   General consideration of this model is similar to many examples emerging in the IETF community
   which soley use the IPv6 data plane.  SRv6 introduced in [RFC8754]
   and [I-D.ietf-spring-srv6-network-programming] is an example.  The
   benefits of such approach includes reducing the number of
   encapsulation layers, capability of deployment with non-capable
   routers in a network, extending the technology in a wider inter-AS
   scope using IP reachability, and capability of integrating the
   functions of the IPv6 data plane.

   This model typically needs an extension to IPv6 data plane, with an
   IPv6 extension header or Option introduced.

   IPv6 functions that are expected to be executed from BFIR to BFER is
   supported if correctly designed, for example, IPv6 Fragmentation/
   Assembly or IPSEC ESP.

   For deployment security, it is necessary to ensure the "BIER" packet
   is capabilities
   integrated, in a trusted IPv6-based domain.

3.3.  Encapsulation Approaches Considered

   A number of approaches addition to the design of BIER-IPv6 encapsulation were
   investigated by the normal BIER Working Group and were discussed function, to facilitate new
   requirements that may emerge in IETF
   meetings and on the BIER list.  This section divides these approaches
   into the two conceptual models.

   Transport-Independent Model approaches include:

      Transport-Independent BIER [I-D.xu-bier-encapsulation].

      BIERin6 [I-D.zhang-bier-bierin6].

   Native an IPv6 Model approaches include:

      BIER-over-IPv6 [I-D.pfister-bier-over-ipv6].

      BIERv6 [I-D.xie-bier-ipv6-encapsulation]. network.

4.  Requirements

   There have been are several suggested requirements, on the BIER email
   list and in meetings, which have been used to form BIER IPv6
   requirements used to help the wg evaluate against the proposed
   solutions.  There is also many further discussions on the list about
   BIER IPv6 requirements from different scenarios.

   Considering that the importance of requirement for BIER IPv6 solution
   is different, in solutions.

   In this document, the requirements are divided into two
   groups: mandatory levels:
   Mandatory and optional. Optional.  The requirements in the mandatory
   group requirement levels are considered necessary for any BIER IPv6 solution, while determined based
   on the
   requirements in following factors:

      If the optional group should requirement is required for a feature that is likely to be
      a potential deployment, the requirement level will be considered but are

      If the impact of not implementing the requirement may block BIER
      from been deployed, the requirement level will be considered

4.1.  Mandatory Requirements

4.1.1.  L2 Agnostic

   The solution must be agnostic

   Considering that these mandatory requirements are all well-known to
   the underlying working group, and practical in normal deployment, they will be
   listed without a detailed description.

4.1.1.  Support various L2 data link type. types

   The solution needs to should support P2P ethernet links as well as shared
   media ethernet links without requiring the LAN switch to perform BIER
   snooping. various kinds of L2 data link types.

4.1.2.  Support BIER architecture

   The solution must support the BIER architecture.

   Multiple sub-domains bound to one or many topologies or algorithms,

   Supporting different multicast flow overlays, multiple sets for more BFERs, sub-domains,
   multi-topologies, multiple sets, multiple Bit String Lengths for
   different forwarding capabilities, Lengths, and multiple BIFTs for
   deterministic ECMP are considered essential functions of BIER and
   need to be supported.

4.1.3.  Conform to existing IPv6 Spec

   The proposed encapsulation must conform to the IPv6 specification and
   guidelines as described in RFC8200.  If new extensions to existing
   IPv6 specification are required, it needs to be discussed and
   reviewed by the 6man working-group.

4.1.4.  Support deployment with Non-BFR routers

   The solution must support deployments with Non-BFR BIER-incapable routers.
   This is beneficial to the deployment of BIER, especially in early
   deployments when some routers do not support BIER forwarding but
   support IPv6 forwarding.  This is also the No.1 charter item, "Transition
   Mechanisms and Partial Deployments" of the BIER WG.

4.1.5.  Support inter-AS multicast deployment

   Inter-AS multicast support is needed for ease of provisioning the
   P2MP transport service to enterprises.  This could greatly increase
   the scalability of BIER, as it is usually considered to be suitable
   only for small intra-AS scenarios.

4.1.6.  Support Simple Encapsulation

   The solution must avoid requiring different encapsulation types.  A
   solution needs to do careful trade-off analysis and select one
   encapsulation as its proposal for best coverage of various scenarios.

4.1.7.  Support Deployment Security

   The proposed solution must include careful security considerations,
   including all that is already considered in BIER architecture RFC8279
   and RFC8296, and other security concerns that may raise due to the
   addition of IPv6.

4.2.  Optional Requirements

4.2.1.  Support MVPN

   The solution MAY support MVPN services that is defined in [RFC6513].
   When MVPN is supported, it should work in a "tunnel" mode,
   encapsulating IP or IPv6 multicast packet in an outer IPv6 header.
   When MVPN is supported, it is suggested to think about both intra-AS
   and inter-AS deployment.


4.1.4.  Support OAM

   BIER OAM MAY should be supported, either directly using existing method, methods,
   specify some variant by specifying a new method for the same function. functionality.  It may be
   considered essential as part of the BIER architecture in some cases.

4.2.3.  Support IPSEC

   IPSEC is optional to IPv6

4.2.  Optional Requirements

   The requirements in this section are listed as optional, and multicast.  It each
   requirement is preferred to support
   IPSEC, including AH/ESP.  If explained with a detailed scenario.  Note that
   fragmentation and IPSEC is to be supported, it shouldn't
   require hop-by-hop encryption/decryption.

4.2.4.  Support Fragmentation

   As part of IPv6 specification [RFC8200], BIER ESP are not BIER functions, they are provided
   by the upper IP layer.

4.2.1.  Support Fragmentation

   There are some cases where the Fragmentation/Assembly function is
   needed for BIER to work in an IPv6 network.

   For example, a customer IPv6 multicast packet may support
   fragmentation on BFIR be 1280 bytes and assembly on BFER.  Support
   is required to be transported through an IPv6 network using BIER.
   Every link of Fragmentation
   can enhance the capability IPv6 network is no less than the requisite 1280
   bytes [RFC8200], but the size of BIER leveraging the BIER-MTU as
   introduced payload that can be encapsulated
   in section 3 of [RFC8296].  If Fragmentation BIER (BIER-MTU) is to be
   supported, less than 1280 bytes.  In this case, it shouldn't require is not
   the appropriate action for a BFIR to drop the packet and advertise an
   MTU to the source [RFC8296].  Instead, the IPv6 transport mechanism,
   either integrated with or independent to BIER, need to provide the
   fragmentation and re-assembly at each

4.2.5. assembly function.

4.2.2.  Support hardware fast path

   If a proposed solution is intended for IPSEC ESP

   There are some scenarios like service- cases where the IPSEC ESP function may be needed to
   transport c-multicast packets through an IPv6 network with
   confidentiality using BIER technology.

   A service provider networks, it should enable may want to provide additional security SLA to its
   customer to ensure that the processing unencrypted c-multicast packet is not
   altered in the service provider's network.  In this case, if the BIER
   technology is preferred for the multicast service, BIER with IPSEC
   ESP support may be a candidate solution.  On the other hand, the
   traffic protection may be better provided via IPSEC or MACSEC at
   multicast flow overlay over and forwarding of beyond the BIER packets in hardware fast path. domain.

5.  IANA Considerations

   Some BIERv6 BIER IPv6 encapsulation proposals do not require any action from
   IANA while other proposals require new BIER Destination IPv6 Option codepoints from
   IPv6 sub-registries, new "Next header" values, or require new IP
   Protocol codes.  This document, however, does not require anything
   from IANA.

6.  Security Considerations

   There are no security issues introduced by this draft.

7.  Acknowledgement

   Thank you

   Thanks to Eric Rosen for his listed set of initial requirements on
   bier wg BIER WG mailing list.

8.  Normative References

              Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain
              Multicast Deployment using BIERv6", draft-geng-bier-ipv6-
              inter-domain-01 (work in progress), January 2020.

              Nainar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
              Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C.
              Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-11
              (work in progress), March 2020.

              Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
              Matsushima, S., and Z. Li, "SRv6 Network Programming",
              draft-ietf-spring-srv6-network-programming-16 (work in
              progress), June 2020.

              Pfister, P. and I. Wijnands, "An IPv6 based BIER
              Encapsulation and Encoding", draft-pfister-bier-over-
              ipv6-01 (work in progress), October 2016.

              Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S.,
              Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng,
              "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft-
              xie-bier-ipv6-encapsulation-08 (work in progress), July

              Xu, X.,, s., Jacquenet,
              C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit
              Index Explicit Replication (BIER) Encapsulation Header",
              draft-xu-bier-encapsulation-06 (work in progress),
              September 2016.

              Zhang, Z., Przygienda, T., Zhang, Z., Wijnands, I., Bidgoli, H., and M.
              McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier-
              bierin6-07 (work in progress), July 2020.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, DOI 10.17487/RFC1112, August 1989,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <>.

   [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, Ed.,
              "Encapsulating MPLS in IP or Generic Routing Encapsulation
              (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,

   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
              2012, <>.

   [RFC7510]  Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
              "Encapsulating MPLS in UDP", RFC 7510,
              DOI 10.17487/RFC7510, April 2015,

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,

   [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
              for Bit Index Explicit Replication (BIER) in MPLS and Non-
              MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
              2018, <>.

   [RFC8663]  Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx,
              W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663,
              DOI 10.17487/RFC8663, December 2019,

   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,

Appendix A.  List of Solutions Evaluation

   The following are solutions that

   There have been some proposed to solve solutions for BIER in IPv6
   environments.  Some solutions propose encoding while others propose
   encapsulation.  It is recommended for the wg to evaluate these solutions
   solutions, against the requirements listed previously previously, in order to
   make informed decisions on solution readiness.

   As illustrated in

   This section lists these examples, the BIER header, or the BitString,
   may appear solutions categorizing in the IPv6 Header, IPv6 Extension Header, IPv6 Payload,
   or IPv6 Tunnel Packet: two conceptual

A.1.  BIER-ETH encapsulation in IPv6 networks

         |   Ethernet    |   BIER header   | payload
         |  (ethType =   | (BIFT-id, ...)  |
         |    0xAB37)    |                 |
         |               |  Next Header    |

   BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined
   in [RFC8296]) can be used to transport the multicast data in the IPv6
   network by encapsulating the multicast user data payload within the
   BIER-ETH header.  However, BIER-ETH in IPv6 networks is not
   considered to be a "BIER natively in IPv6" solution which utilizes
   the IPv6 header to forward the packet.

   Mixed use of BIER-ETH in a native IPv6 solution is up to the solution
   and is outside the scope  Integrated mode approach

   One example of this document.

A.2.  Encode Bitstring in IPv6 destination address

      |  IPv6 header  | payload
      | (BitString in |
      | DA lower bits)|
      |  Next Header  |

   As described model is defined in [I-D.pfister-bier-over-ipv6], The
   where the information required by for BIER is stored in forwarding, e.g., the destination IPv6 address.  The BIER
   BitString, is encoded in the low-order bits of the IPv6 destination
   address of each packet.  The high-order bits of the IPv6 destination
   address are used by intermediate routers for unicast forwarding,
   deciding whether a packet is a BIER packet, and if so, to identify
   the BIER Sub-Domain, Set Identifier and BitString length.  No
   additional extension or encapsulation header  The BIER
   function is required.  Instead of
   encapsulating the packet integrated in IPv6, the IPv6 header and its forwarding
   procedure, and the BIER payload is attached to encapsulated as the BIER IPv6 payload.

      |  IPv6 header and  | payload
      | (BitString in |
      | DA lower bits)|
      |  Next Header  |

   Another example of this model is defined in
   [I-D.xie-bier-ipv6-encapsulation], where information required for
   BIER forwarding, e.g., the IPv6 protocol number BIER header, is set encoded in an Option TLV
   (indicated by an Option Type to the type be allocated by IANA) of the
   payload.  If IPv6
   Destination Option Header.  The third-highest-order bit of the payload Option
   Type is UDP, the UDP checksum needs set to change
   when 1 to allow Option Data (e.g., the BitString BitString) change en
   route.  The BIER function is integrated in the IPv6 destination address changes.

A.3.  Add BIER extension header into and
   its forwarding procedure, and the BIER payload is encapsulated as the
   IPv6 Extension Header payload.

      |  IPv6 header  | IPv6 Ext header | payload
      |               | (BIER header in |
      |               |  TLV Type = X)  |
      | Next Header   |   Next Header   |

   According to [RFC8200] In IPv6, optional internet-layer information
   is encoded in separate headers that may be placed between the IPv6
   header and the upper- layer header in a packet.  There is a small
   number of such extension headers, each one identified by a distinct
   Next Header value.  An IPv6 packet may carry zero, one, or more
   extension headers, each identified by the Next Header field of the
   preceding header.  Extension headers (except for the Hop-by-Hop
   Options header) are not processed, inserted, or deleted by any node
   along a packet's delivery path, until the packet reaches the node (or
   each of the set of nodes, in the case of multicast) identified in the
   Destination Address field of the IPv6 header.  The Hop-by-Hop Options
   header is not inserted or deleted, but may be examined or processed
   by any node along a packet's delivery path, until the packet reaches
   the node (or each of the set of nodes, in the case of multicast)
   identified in the Destination Address field

A.2.  Independent model approach

   One example of the IPv6 header.  The
   Hop-by-Hop Options header, when present, must immediately follow the
   IPv6 header.  Its presence this model is indicated by the value zero defined in [I-D.zhang-bier-bierin6],
   where the Next
   Header field of the IPv6 header.

   Two of the currently-defined extension headers are the Hop-by-Hop
   Options BIER header and the Destination Options header which carry a
   variable number of type-length-value (TLV) encoded "options".

   In [I-D.xie-bier-ipv6-encapsulation] an IPv6 BIER Destination Option
   is carried by the IPv6 Destination Option Header (indicated by a Next
   Header value 60).  It is initialized in a packet sent by an IPv6 BFIR
   router to inform the payload following BFR routers in an IPv6 BIER domain to
   replicate to destination BFER routers hop-by-hop.  BIER is generally
   a hop-by-hop and one-to-many architecture and it is required for a
   BIER IPv6 encapsulation to include the BIER Header ([RFC8296]) as an
   IPv6 Extension Header, to pilot the hop-by-hop BIER replication.

   Hop by hop Options Headers may be considered.  The Hop-by-Hop Options
   header is used to carry optional information that may be examined and
   processed by every node along a packet's delivery path.  The Hop-by-
   Hop Options header is identified by a Next Header value of 0 in the are L2 payload
   when feasible (e.g.  when two BFRs are directly connected) or IPv6 header.

   Defining New Extension Headers and Options may also be considered, if
   payload when IPv6 Destination Option Header transport is needed/desired (e.g. when two BFRs are
   not good enough and new
   extension headers can solve the problem better.

   Such proposals may include requests to IANA to allocate directly connected).  This is indicated by either a "BIER
   Option" code from "Destination Options and Hop-by-Hop Options", and/ 0xAB37
   Ethertype allocated to BIER or a "BIER Option Header" code from "IPv6 Extension Header Types".

A.4.  Transport BIER as new IPv6 Next-Header value to be
   allocated by IANA.

         |   Ethernet    |   BIER header   | payload
         |  (ethType =   | (BIFT-id, ...)  |
         |    0xAB37)    |                 |
         |               |  Next Header    |

         |  IPv6 header  | IPv6 Ext header | BIER Hdr + payload
         |               |    (optional)   | as IPv6 payload
         |               |                 |
         | Next Header   | Next Header = X |

   There is a proposal for a transport-independent BIER encapsulation
   header which is applicable regardless of the underlying transport
   technology.  As described

   While not specified in [I-D.xu-bier-encapsulation] and [I-D.zhang-bier-bierin6], the BIER header, and the payload following
   it, can be combined as an IPv6 payload, and be indicated any other tunnel
   types supported by a new
   Upper-layer IPv6 Next-Header value.  A unicast IPv6 destination
   address is used for the replication and changes when replicating a
   packet out to a neighbor.

   Such proposals may include a request to IANA to allocate an IPv6
   Next-Header code from "Assigned Internet Protocol Numbers".

A.5.  Tunnelling BIER in a environment could be used, e.g.  IPv6 tunnel

      |  IPv6 header  | IPv6 Ext header | GRE header |
      |               |    (optional)   |            | BIER Hdr +
      |               |                 |            | payload as GRE
      | Next Header   |   Next Header   | Proto = X  |   |Proto=0xAB37| Payload

   A generic IPv6 Tunnel could be used to encapsulate the bier packet
   within an IPv6 domain.

   GRE is a mechanism by which any ethernet payload can be carried by an
   IP GRE tunnel due to the 16-bits 'Protocol Type' field.  Both IPv4
   and IPv6 can be used to carry GRE.  The Ethernet type codepoint
   0xAB37, defined for BIER, can be used in a GRE header to indicate the
   subsequent BIER header and payload in an IPv6 network.

      |  IPv6 header  | IPv6 Ext header | UDP header |
      |               |    (optional)   |            | BIER Hdr +
      |               |                 |            | payload as UDP
      | Next Header   |   Next   |Next Header =UDP | DPort = X DPort=TBD  | Payload

   UDP-based tunnelling is another mechanism which uses a specific UDP
   port to indicate a UDP payload format.  Both IPv4 and IPv6 can
   support UDP.  Such UDP-based tunnels can be used for BIER in a IPv6
   network by defining a new UDP port to indicate the BIER header and

Authors' Addresses

   Mike McBride


   Jingrong Xie


   Xuesong Geng


   Senthil Dhanaraj


   Rajiv Asati


   Yongqing Zhu
   China Telecom


   Gyan S. Mishra
   Verizon Inc.

               13101 Columbia Pike

               Silver Spring

               MD 20904

               United States of America

             301 502-1347


   Zhaohui Zhang