Network Working Group                                         M. McBride
Internet-Draft                                                 Futurewei
Intended status: Standards Track                                  J. Xie
Expires: May 5, July 18, 2020                                       S. Dhanaraj
                                                                  Huawei
                                                                R. Asati
                                                                   Cisco
                                                        November 2, 2019
                                                                  Y. Zhu
                                                           China Telecom
                                                        January 15, 2020

                         BIER IPv6 Requirements
                  draft-ietf-bier-ipv6-requirements-03
                  draft-ietf-bier-ipv6-requirements-04

Abstract

   The BIER WG includes, in its charter, work on developing mechanisms
   to transport BIER natively in IPv6.  This document is intended to
   help the WG with this effort by specifying requirements for
   transporting packets, with Bit Index Explicit Replication (BIER)
   headers, in an IPv6 environment.  There will be a need to send IPv6
   payloads, to multiple IPv6 destinations, using BIER.  There have been
   several proposed solutions in this area.  But there hasn't been a
   document which describes the problem and lists the requirements.  The
   goal of this document is to describe the BIER IPv6 requirements,
   summarize the proposed solutions, and guide the working group in
   understanding the benefits, and drawbacks, of the various solutions
   and to 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 https://datatracker.ietf.org/drafts/current/.

   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 May 5, July 18, 2020.

Copyright Notice

   Copyright (c) 2019 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
   (https://trustee.ietf.org/license-info) 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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   3.  BIER IPv6 Scenario's  . . . . . . . . . . . . . . . . . . . .   4
     3.1.  BIERv6 for Access Network . . . . . . . . . . . . . . . .   4
     3.2.  BIERv6 for Data Center  . . . . . . . . . . . . . . . . .   4
     3.3.  BIERv6 for Core Networks  . . . . . . . . . . . . . . . .   5
     3.4.  Implications for BIER in SRv6 . . . . . . . . . . . . . .   5
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Hop by hop SA or DA modification  . . . . . . . . . . . .   5
     4.3.  L4 Inspection . . . . . . . . . . . . . . . . . . . . . .   6
     4.4.  Multicast address in SA field . . . . . . . . . . . . . .   7   6
     4.5.  Incorrect bits  . . . . . . . . . . . . . . . . . . . . .   7   6
     4.6.  SA filtering  . . . . . . . . . . . . . . . . . . . . . .   7
     4.7.  BIER architecture support . . . . . . . . . . . . . . . .   7
     4.8.  Simple Encapsulation  . . . . . . . . . . . . . . . . . .   8   7
     4.9.  Hardware fast path  . . . . . . . . . . . . . . . . . . .   8   7
     4.10. Conform to existing IPv6 Spec . . . . . . . . . . . . . .   8   7
     4.11. Support Fragmentation . . . . . . . . . . . . . . . . . .   8
     4.12. Support IPv6 Security . . . . . . . . . . . . . . . . . .   8
   5.  Solutions Evaluation  . . . .  IANA Considerations . . . . . . . . . . . . . . . .   8
     5.1.  BIER-ETH encapsulation in IPv6 networks . . . . .   8
   6.  Security Considerations . . . .   9
     5.2.  Encode Bitstring in IPv6 destination address . . . . . .  10
     5.3.  Add BIER header into IPv6 Extension Header . . . . . . .  10
     5.4.  Transport BIER as IPv6 payload . .   8
   7.  Acknowledgement . . . . . . . . . . .  11
     5.5.  Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . .   8
   8.  Normative References  .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . .   8
   Appendix A.  Solutions Evaluation . .  13
   7.  Security Considerations . . . . . . . . . . . . . .   9
     A.1.  BIER-ETH encapsulation in IPv6 networks . . . . .  13
   8.  Acknowledgement . . . .  10
     A.2.  Encode Bitstring in IPv6 destination address  . . . . . .  11
     A.3.  Add BIER header into IPv6 Extension Header  . . . . . . .  11
     A.4.  Transport BIER as IPv6 payload  . . . . . .  13
   9.  Normative References . . . . . . .  13
     A.5.  Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . .  13

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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: one is BIER MPLS
   encapsulation to run on various physical links that support MPLS, the
   other is non-MPLS BIER Ethernet encapsulation to run on ethernet
   links, with an ethertype 0xAB37.  This document describes using BIER
   in non-MPLS IPv6 environments.  We explain the requirements of
   transporting IPv4/IPv6 multicast payloads, from an IPv6 router (BFIR)
   to multicast IPv6 destinations (BFERs), using BIER.  This can include
   native IPv6 encapsulation and generic tunneling.  Native IPv6, in
   this document, is defined as BIER not encapsulated in mpls or
   ethernet.  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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   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 to transport BUM packets,
   with BIER headers, in an IPv6 environment.  In IPv6 networks, many
   deployments use non-MPLS encapsulation for unicast as the data-plane.
   In such case, it may be expected to have a BIER IPv6 encapsulation
   which is compliant with various kinds of physical links, perhaps in a
   hop-by-hop manner, and maintain the benefit of "fast reroute" of an
   IPv6 tunnel.  Evaluating the BIER IPv6 requirements will help
   determine the best solutions to address these problems.

3.  BIER IPv6 Scenario's

         +--------------------------------------------+
         |                                            |
         |                                         +------+
         |                                         | BFER |
     +------+                IPv6                  +------+
     | BFIR |                                         |
     +------+               Network                +------+
         |                                         | BFER |
         |                                         +------+
         |                                            |
         +--------------------------------------------+

   This basic scenario depicts the need to replicate bier packets from a
   BFIR to BFERs across an IPv6 core.  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 the BIER
   bitstring used to determine the set of BIER forwarding egress
   routers, will need to traverse a IPv6 domain.  The ways in which BIER
   will function in an IPv6 environment is the problem that needs to be
   solved.  [RFC8354] lists some good IPv6 related use cases which we
   will similarly reference in this document.

3.1.  BIERv6 for Access Network

   Access networks deliver a variety of types of multicast video traffic
   from the service provider's network to the home (or Enterprise)
   environment and from the home towards the service provider's network.

   There will be a need to send traffic from the IPv4 access towards the
   service provider's IPv6 network and vice versa.  A packet could be
   mapped into a providers IPv6 network through the use of a BIERv6
   header.  The access devices would not need to know specific details
   about the packet to perform this mapping; instead the access device
   would only need to know how to process a BIER header unless there is
   end to end IPv6.

3.2.  BIERv6 for Data Center

   Some Data Center operators are transitioning their Data Center
   infrastructure from IPv4 to native IPv6 only, in order to cope with
   IPv4 address depletion and to achieve larger scale.  In such
   environment, BIERv6, can be used to natively steer multicast data
   across an IPv6 data center.

3.3.  BIERv6 for Core Networks

   While the overall amount of traffic offered to the network continues
   to grow and considering that multiple types of traffic with different
   characteristics and requirements are quickly converging over single
   network architecture, the network operators are starting to face new
   challenges.

   Some operators are currently building, or plan to build in the near
   future, an IPv6 only native infrastructure for their core network.
   Having a native BIERv6 infrastructure will help maintain simplicity
   of the network and reduce state versus traditional IP Multicast.

3.4.  Implications for BIER in SRv6

   The Source Packet Routing in Networking (SPRING) architecture
   describes how Segment Routing can be used to steer packets through an
   IPv6 or MPLS network using the source routing paradigm.  [RFC8354]
   focuses on use cases for Segment Routing in an IPv6 only environment,
   something which is equially important for BIER in an IPv6 only
   environment.

4.  Requirements

   There have been 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:

4.1.  L2 Agnostic

   The solution should be agnostic to the underlying L2 data link type.

4.2.  Hop by hop SA or DA modification

   The solution should not require hop-by-hop modification of the IP
   source address field.

   Solutions that do not require Hop-by-hop SA modification are
   preferred.  Solutions which maintain the SA will help fast-path
   forwarding (req 4.9 in this doc), are beneficial for receiving
   notices from the BFIR for functions like BIER PING, TRACE and MTU
   notification, are beneficial for identifying an MVPN instance to help
   remove more encapsulation such as Service Label (such as MPLS VPN
   Label or VNI in the SRv6 network), Label, are beneficial for
   SA filtering (req 4.6 in this doc), and are beneficial for data
   origin authentication if IPSEC is desired (req 4.12 in this doc).

   The solution should use a IPv6 unicast address in the DA to satisfy
   the BIER architecture without introducing additional tunnel
   encapsulation, and thus may require DA modification by each BFR hop.

   It is commonly thought that BIERv6 could use a multicast address, as
   BIER is one-hop replication on each BFR in normal cases.  However, as
   described in section 6.9 of [RFC8279], it is useful to support non-
   BIER routers within a BIER domain.  From the wg discussion about this
   document, focus is on the advantages of using unicast addresses that
   otherwise could not be possible by using a multicast address or
   anycast address for two cases: replication from a BFR to other BFR(s)
   connected by Layer-3 Non-BFR router(s) without using tunneling
   techniques, and replication from a BFR to other BFR(s) connected by
   Layer-2 switch(es) without broadcasting or snooping on Layer-2
   switch(es) in between.  Based on the natural reachability of an IPv6
   unicast address, it can support the multi-hop replication cases as
   well as the one-hop replication case using one encapsulation.

4.3.  L4 Inspection

   The solution should not require the BFRs to inspect layer 4 or
   require any changes to layer 4.

   The proposals requiring BIER header encapsulated as part of the
   payload may conflict with the layers of IP protocol stack.  On the
   one hand, fast-path BIER forwarding has to be based on the L4
   inspection of the BIER header within the payload, and on the other
   hand, the BIER forwarding needs to change the BitString in the BIER
   header of the payload, which in turn conflicts with other L3
   functions.  Following are some examples.

   One example is in IP fragmentation case, where a packet may need to
   be fragmented by a BFIR, according to the BIER-MTU defined in
   RFC8296, into one packet with BIER header and 1500 bytes of payload,
   and another packet with the remaining 500 bytes of payload.  When BFR
   B receives the second fragmentation packet from BFR A, BFR B can't
   forward this packet because BFR B doesn't have the BIER header in the
   second fragmentation packet.  Section 4.11 describes the
   fragmentation requirements.

   The second example is in IPSEC case, where the BIER header is part of
   the payload for confidentiality or integrity.  The need to change the
   BitString in the BIER Header, when forwarding BIER packets, makes it
   incompatible with IPSEC.  Section 4.12 describes the IPSEC
   requirements.

4.4.  Multicast address in SA field

   The third example is solution should not allow a multicast address to be put in the case of working IP
   source address field.  According to [RFC1112] "A host group address
   must never be placed in SRv6 networks, as
   described the source address field or anywhere in section 3.4 of this document, BIERv6 may be used with
   SRH.  As BIER header is part of the payload, it will be reached only
   after the SRH is processed.  That is to say, when BFR B receives a
   packet with SRH from BFR A, BFR B has to process the SRH first, and
   then the Upper-layer BIER header last.  The SRH can work well based
   on the indication of the preceding IPv6 DA lookup in FIB, but for
   BIER forwarding, the BIER header part of the payload has to be deeply
   inspected on each BFR.

4.4.  Multicast address in SA field

   The solution should not allow a multicast address to be put in the IP
   source address field.  According to [RFC1112] "A host group address
   must never be placed in the source address field or anywhere in a
   source route or record route option a
   source route or record route option of an outgoing IP datagram."

4.5.  Incorrect bits

   The solution should not assume that bits never get set incorrectly.

   If a packet with incorrect bits is set, it should not damage BIERv6
   functionality or any other functions such as Unicast Reverse Path
   Forwarding (URPF), nor should it cause loops or duplicates as
   described in section 6.8 of [RFC8279].

4.6.  SA filtering

   The solution should not require changes in source address filtering
   procedures.  For instance if a host uses a "BIER address" as its
   source address in a given packet, and the packet doesn't get dropped
   according to existing SA filtering procedures, the packet may elicit
   responses that put the BIER address in their destination address
   fields.  This could be a security issue, as it creates an attack
   vector that can create 64 responses to a single probe.

4.7.  BIER architecture support

   It should be possible to use the solution to support the entire BIER
   architecture.  The ability to bypass Non-BIER routers and L2 switches
   is part of the BIER architecture and having this ability is a
   mandatory requirement.

   Multiple sub-domains bound to one or many topologies or algorithms,
   multiple sets for more BFERs, multiple Bit String Length for
   different forwarding capability, and multiple BIFTs for ECMP should
   be supported.

4.8.  Simple Encapsulation

   The solution should avoid requiring different encapsulation types, or
   complex tunneling techniques, to support BIER as an E2E multicast
   transport.

   A single encapsulation should support Layer-2 switches within BFRs,
   or non-BFR within a BIER domain, or inter-domain deployment of BIER.

4.9.  Hardware fast path

   The solution should enable the processing and forwarding of BIER
   packets in hardware fast path.

4.10.  Conform to existing IPv6 Spec

   The proposed encapsulation must conform to the IPv6 specification and
   guidelines as described in RFC8200.  It should not require any new
   modifications to the IPv6 specification aside from extensions to
   existing mechanisms such as IPv6 Options.

4.11.  Support Fragmentation

   The proposed encapsulation must support fragmentation.  It shouldn't
   require fragmentation and re-assembly at each hop.

4.12.  Support IPv6 Security

   The proposed encapsulation should support IPv6 security including AH/
   ESP extension headers.  It shouldn't require hop-by-hop encryption/
   decryption.

5.  Solutions Evaluation

   The following are solutions that have been proposed to solve BIER in
   IPv6 environments.  IANA Considerations

   Some solutions propose encoding BIERv6 encapsulation proposals do not require any action from
   IANA while others
   propose encapsulation.  It is recommended for the wg other proposals require new BIER Destination 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 to evaluate
   these solutions against the requirements Eric Rosen for his listed previously in order
   to make informed decisions set of requirements on solution readiness.

   As illustrated in these examples, the
   bier wg list.

8.  Normative References

   [I-D.pfister-bier-over-ipv6]
              Pfister, P. and I. Wijnands, "An IPv6 based BIER header, or the BitString,
   may appear
              Encapsulation and Encoding", draft-pfister-bier-over-
              ipv6-01 (work in the IPv6 Header, IPv6 Extension Header, IPv6 Payload,
   or IPv6 Tunnel Packet:

5.1.  BIER-ETH encapsulation in IPv6 networks

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

   BIER-ETH encapsulation (BIER header progress), October 2016.

   [I-D.xie-bier-ipv6-encapsulation]
              Xie, J., Geng, L., McBride, M., Asati, R., and S.
              Dhanaraj, "Encapsulation for BIER in Non-MPLS networks as defined IPv6
              Networks", draft-xie-bier-ipv6-encapsulation-04 (work in [RFC8296]) can be used to transport the multicast data
              progress), December 2019.

   [I-D.xu-bier-encapsulation]
              Xu, X., somasundaram.s@alcatel-lucent.com, 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 the IPv6
   network by encapsulating the multicast user data payload within the
   BIER-ETH header.  However, using BIER-ETH progress),
              September 2016.

   [I-D.zhang-bier-bierin6]
              Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and
              M. McBride, "BIER in IPv6 networks is not
   considered to be a native IPv6 solution which utilizes the IPv6
   header to forward the packet.  Below listed are some of the
   properties of BIER-ETH encapsulation which could be seen as the
   reasons (BIERin6)", draft-zhang-bier-
              bierin6-04 (work in progress), January 2020.

   [RFC1112]  Deering, S., "Host extensions for the same,

   o  BIER-ETH is not agnostic to the underlying (L2) data link type.
      It can be deployed only IP multicasting", STD 5,
              RFC 1112, DOI 10.17487/RFC1112, August 1989,
              <https://www.rfc-editor.org/info/rfc1112>.

   [RFC2119]  Bradner, S., "Key words for use in the networks with Ethernet data link RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2473]  Conta, A. and cannot be deployed in an network which deploys any other data
      link types.  Use of BIER-ETH in IPv6 networks might also result in
      using different BIER encapsulations, when BIER is used as a E2E
      multicast transport across a larger heterogeneous IPv6 networks
      with different data link types used in different layers of the
      network.

   o  BIER-ETH S. Deering, "Generic Packet Tunneling in
              IPv6 networks is considered similar to 6PE solution
      where-in the multicast user data packet is encapsulated with-in
      the BIER-MPLS header.

      *  It is worth noting that the only major difference between BIER-
         MPLS Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <https://www.rfc-editor.org/info/rfc2473>.

   [RFC8200]  Deering, S. and BIER-Non-MPLS header is that BIER-MPLS uses downstream
         assigned MPLS label while BIER-Non-MPLS header uses a domain-
         wide-unique BIFT-id.  While the use of domain-wide-unique BIFT-
         id in BIER-ETH header takes away the complexity of allocation R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Przygienda, T., and state maintenance from the network, it still requires some
         sort of ID (similar to label) to identify the application
         context after the decapsulation of BIER header (example: MVPN
         VRF Label).  Encoding of such an ID/LABEL before encapsulating
         the multicast user data payload with BIER-ETH header cannot be
         avoided.

      *  The absence of an IPv6 header, S. Aldrin, "Multicast Using Bit Index
              Explicit Replication (BIER)", RFC 8279,
              DOI 10.17487/RFC8279, November 2017,
              <https://www.rfc-editor.org/info/rfc8279>.

   [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Tantsura, J., Aldrin, S., and the optional IPv6 extension
         headers, deprives BIER of some of the useful cases (ex: Use of
         IPv6 address for identification of network function or service
         mapping) that is otherwise possible in native IPv6
         encapsulation which utilizes a IPv6 header.

      *  Tunneling of BIER packets is one common technique used for FRR,
         to tunnel over BIER incapable nodes etc.  While it is possible I. Meilik, "Encapsulation
              for the BIER-ETH encapsulated packet to be further encapsulated
         within a GRE6 or SRv6, etc tunnel, it might not be possible to
         parse and decapsulate different types of tunnel headers and
         forward the BIER packet completely in hardware fast path
         similar to the label stack processing in BIER-MPLS networks.
         It would be useful to select an encapsulation which could help Bit Index Explicit Replication (BIER) in processing the tunnel MPLS and BIER header Non-
              MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
              2018, <https://www.rfc-editor.org/info/rfc8296>.

   [RFC8354]  Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R.,
              Ed., and make the
         forwarding decision completely in hardware fast path, which is
         lacking in BIER-ETH encapsulation if chosen to be deployed in
         pure IPv6 networks.

5.2.  Encode Bitstring in IPv6 destination address

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

   As described M. Townsley, "Use Cases for IPv6 Source Packet
              Routing in [I-D.pfister-bier-over-ipv6], Networking (SPRING)", RFC 8354,
              DOI 10.17487/RFC8354, March 2018,
              <https://www.rfc-editor.org/info/rfc8354>.

Appendix A.  Solutions Evaluation

   The information
   required by following are solutions that have been proposed to solve BIER is stored in the destination
   IPv6 address.  The BIER
   BitString environments.  Some solutions propose encoding while others
   propose encapsulation.  It 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 recommended 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 is required.  Instead of
   encapsulating wg to evaluate
   these solutions against the packet requirements listed previously in IPv6, the payload is attached order
   to make informed decisions on solution readiness.

   As illustrated in these examples, the BIER
   IPv6 header and the IPv6 protocol number is set to the type of the
   payload.  If the payload is UDP, the UDP checksum needs to change
   when header, or the BitString BitString,
   may appear in the IPv6 destination address changes.

5.3.  Add BIER header into Header, IPv6 Extension Header Header, IPv6 Payload,
   or IPv6 Tunnel Packet:

A.1.  BIER-ETH encapsulation in IPv6 networks

         +---------------+-----------------+-------------------
         |  IPv6 header   Ethernet    | IPv6 Ext   BIER header   | payload
         |  (ethType =   | (BIER header in (BIFT-id, ...)  |
         |    0xAB37)    |  TLV Type = X)                 |
         | Next Header               |  Next Header    |
         +---------------+-----------------+-------------------

   According

   BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined
   in [RFC8296]) can be used to [RFC8200] In IPv6, optional internet-layer information
   is encoded transport the multicast data in separate headers that may the IPv6
   network by encapsulating the multicast user data payload within the
   BIER-ETH header.  However, using BIER-ETH in IPv6 networks is not
   considered to be placed between a native IPv6 solution which utilizes the IPv6
   header and to forward the upper- layer header in a packet.  There is a small
   number  Below listed are some 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
   properties of BIER-ETH encapsulation which could be seen as the
   preceding header.  Extension headers (except
   reasons for the Hop-by-Hop
   Options header) are same,

   o  BIER-ETH is not processed, inserted, or deleted by any node
   along a packet's delivery path, until the packet reaches the node (or
   each of agnostic to the set of nodes, underlying (L2) data link type.
      It can be deployed only in the case networks with Ethernet data link
      and cannot be deployed in an network which deploys any other data
      link types.  Use of multicast) identified BIER-ETH in the
   Destination Address field IPv6 networks might also result in
      using different BIER encapsulations, when BIER is used as a E2E
      multicast transport across a larger heterogeneous IPv6 networks
      with different data link types used in different layers of the
      network.

   o  BIER-ETH in IPv6 networks is considered similar to 6PE solution
      where-in the multicast user data packet is encapsulated with-in
      the BIER-MPLS header.  The Hop-by-Hop Options

      *  It is worth noting that the only major difference between BIER-
         MPLS and BIER-Non-MPLS header is not inserted or deleted, but may be examined or processed
   by any node along that BIER-MPLS uses downstream
         assigned MPLS label while BIER-Non-MPLS header uses a packet's delivery path, until the packet reaches domain-
         wide-unique BIFT-id.  While the node (or each use of domain-wide-unique BIFT-
         id in BIER-ETH header takes away the set complexity of nodes, in allocation
         and state maintenance from the case network, it still requires some
         sort of multicast)
   identified in ID (similar to label) to identify the Destination Address field application
         context after the decapsulation of BIER header (example: MVPN
         VRF Label).  Encoding of such an ID/LABEL before encapsulating
         the IPv6 header. multicast user data payload with BIER-ETH header cannot be
         avoided.

      *  The
   Hop-by-Hop Options absence of an IPv6 header, when present, must immediately follow and the optional IPv6 header.  Its presence is indicated by the value zero in the Next
   Header field extension
         headers, deprives BIER of some of the useful cases (ex: Use of
         IPv6 address for identification of network function or service
         mapping) that is otherwise possible in native IPv6
         encapsulation which utilizes a IPv6 header.

   Two

      *  Tunneling of BIER packets is one common technique used for FRR,
         to tunnel over BIER incapable nodes etc.  While it is possible
         for the currently-defined extension BIER-ETH encapsulated packet to be further encapsulated
         within a GRE6, etc tunnel, it might not be possible to parse
         and decapsulate different types of tunnel headers are and forward
         the Hop-by-Hop
   Options BIER packet completely in hardware fast path similar to the
         label stack processing in BIER-MPLS networks.  It would be
         useful to select an encapsulation which could help in
         processing the tunnel and BIER header and make the Destination Options header forwarding
         decision completely in hardware fast path, which carry a
   variable number of type-length-value (TLV) encoded "options".

   In [I-D.xie-bier-ipv6-encapsulation] an is lacking in
         BIER-ETH encapsulation if chosen to be deployed in pure IPv6
         networks.

A.2.  Encode Bitstring in IPv6 BIER Destination Option
   is carried by the destination address

      +---------------+-------------------
      |  IPv6 Destination Option Header (indicated by a header  | payload
      | (BitString in |
      | DA lower bits)|
      |  Next Header value 60).  It is initialized  |
      +---------------+-------------------

   As described in a packet sent [I-D.pfister-bier-over-ipv6], The information
   required by an IPv6 BFIR
   router to inform the following BFR routers in an IPv6 BIER domain to
   replicate to is stored in the destination BFER routers hop-by-hop. IPv6 address.  The BIER
   BitString is generally
   a hop-by-hop and one-to-many architecture and it is required for a
   BIER IPv6 encapsulation to include encoded in the BIER Header ([RFC8296]) as an
   IPv6 Extension Header, to pilot low-order bits of the hop-by-hop BIER replication.

   Hop by hop Options Headers may be considered. IPv6 destination
   address of each packet.  The Hop-by-Hop Options
   header is high-order bits of the IPv6 destination
   address are used to carry optional information that may be examined and
   processed by every node along intermediate routers for unicast forwarding,
   deciding whether a packet's delivery path.  The Hop-by-
   Hop Options header packet is identified by a Next Header value of 0 in the
   IPv6 header.

   Defining New Extension Headers BIER packet, and Options may also be considered, if so, to identify
   the IPv6 Destination Option Header is not good enough BIER Sub-Domain, Set Identifier and new BitString length.  No
   additional extension headers can solve the problem better.

   Such proposals may include requests to IANA to allocate a "BIER
   Option" code from "Destination Options and Hop-by-Hop Options", and/ or a "BIER Option Header" code from "IPv6 Extension Header Types".

5.4.  Transport encapsulation header is required.  Instead of
   encapsulating the packet in IPv6, the payload is attached to the BIER as
   IPv6 header and the IPv6 protocol number is set to the type of the
   payload.  If the payload is UDP, the UDP checksum needs to change
   when the BitString in the IPv6 destination address changes.

A.3.  Add BIER header into IPv6 Extension Header
      +---------------+-----------------+-------------------
      |  IPv6 header  | IPv6 Ext header | BIER Hdr + payload
      |               |    (optional) (BIER header in | as IPv6 payload
      |               |  TLV Type = X)  |
      | Next Header   |   Next Header = X   |
      +---------------+-----------------+-------------------

   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 proposal 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 transport-independent BIER encapsulation 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 which is applicable regardless 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 of the IPv6 header.  The
   Hop-by-Hop Options header, when present, must immediately follow the
   IPv6 header.  Its presence is indicated by the value zero in the Next
   Header field of the underlying transport
   technology.  As described in [I-D.xu-bier-encapsulation] and
   [I-D.zhang-bier-bierin6], IPv6 header.

   Two of the BIER header, currently-defined extension headers are the Hop-by-Hop
   Options header and the payload following
   it, can be combined as Destination Options header which carry a
   variable number of type-length-value (TLV) encoded "options".

   In [I-D.xie-bier-ipv6-encapsulation] an IPv6 payload, and be indicated BIER Destination Option
   is carried by a new
   Upper-layer IPv6 Next-Header value.  A unicast the IPv6 destination
   address Destination Option Header (indicated by a Next
   Header value 60).  It is used for the replication and changes when replicating initialized in a packet out to a neighbor.

   Such proposals may include a request to IANA sent by an IPv6 BFIR
   router to allocate inform the following BFR routers in an IPv6
   Next-Header code from "Assigned Internet Protocol Numbers".

5.5.  Tunneling BIER in 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 IPv6 tunnel

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

   A generic IPv6 Tunnel could be used encapsulation to encapsulate include the bier packet
   within BIER Header ([RFC8296]) as an
   IPv6 domain.

   GRE is a mechanism Extension Header, to pilot the hop-by-hop BIER replication.

   Hop by which any ethernet payload can hop Options Headers may be carried 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 an
   IP GRE tunnel due to a Next Header value of 0 in the 16-bits 'Protocol Type' field.  Both IPv4
   IPv6 header.

   Defining New Extension Headers and Options may also be considered, if
   the IPv6 Destination Option Header is not good enough and new
   extension headers can be used solve the problem better.

   Such proposals may include requests to carry GRE.  The Ethernet type codepoint
   0xAB37, defined for BIER, can be used in a GRE header IANA to indicate the
   subsequent BIER header allocate a "BIER
   Option" code from "Destination Options and payload in an Hop-by-Hop Options", and/
   or a "BIER Option Header" code from "IPv6 Extension Header Types".

A.4.  Transport BIER as IPv6 network.

      +---------------+-----------------+------------+---------------- payload

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

   UDP-based tunneling
      +---------------+-----------------+-------------------

   There 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 proposal for BIER in a IPv6
   network by defining a new UDP port to indicate the transport-independent BIER encapsulation
   header which is applicable regardless of the underlying transport
   technology.  As described in [I-D.xu-bier-encapsulation] and
   payload.

6.  IANA Considerations

   Some BIERv6 encapsulation proposals do not require any action from
   IANA while other proposals require new
   [I-D.zhang-bier-bierin6], the BIER Destination 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.

7.  Security Considerations

   There are no security issues introduced header, and the payload following
   it, can be combined as an IPv6 payload, and be indicated by this draft.

8.  Acknowledgement

   Thank you to Eric Rosen a new
   Upper-layer IPv6 Next-Header value.  A unicast IPv6 destination
   address is used for his listed set of requirements on the
   bier wg list.

9.  Normative References

   [I-D.pfister-bier-over-ipv6]
              Pfister, P. replication and I. Wijnands, "An changes when replicating a
   packet out to a neighbor.

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

A.5.  Tunneling BIER
              Encapsulation and Encoding", draft-pfister-bier-over-
              ipv6-01 (work in progress), October 2016.

   [I-D.xie-bier-ipv6-encapsulation]
              Xie, J., Geng, L., McBride, M., Asati, R., and S.
              Dhanaraj, "Encapsulation for a IPv6 tunnel

      +---------------+-----------------+------------+----------------
      |  IPv6 header  | IPv6 Ext header | GRE header |
      |               |    (optional)   |            | BIER in Non-MPLS Hdr +
      |               |                 |            | payload as GRE
      | Next Header   |   Next Header   | Proto = X  | Payload
      +---------------+-----------------+------------+----------------

   A generic IPv6
              Networks", draft-xie-bier-ipv6-encapsulation-03 (work in
              progress), July 2019.

   [I-D.xu-bier-encapsulation]
              Xu, X., somasundaram.s@alcatel-lucent.com, 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.

   [I-D.zhang-bier-bierin6]
              Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and
              M. McBride, "BIER in Tunnel could be used to encapsulate the bier packet
   within an IPv6 (BIERin6)", draft-zhang-bier-
              bierin6-03 (work in progress), July 2019.

   [RFC1112]  Deering, S., "Host extensions for domain.

   GRE is a mechanism by which any ethernet payload can be carried by an
   IP multicasting", STD 5,
              RFC 1112, DOI 10.17487/RFC1112, August 1989,
              <https://www.rfc-editor.org/info/rfc1112>.

   [RFC2119]  Bradner, S., "Key words 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 use BIER, can be used in RFCs a GRE header to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2473]  Conta, A. indicate the
   subsequent BIER header and S. Deering, "Generic Packet Tunneling payload in an IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <https://www.rfc-editor.org/info/rfc2473>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [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,
              <https://www.rfc-editor.org/info/rfc8279>.

   [RFC8296]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
              Tantsura, J., Aldrin, S., network.

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

   UDP-based tunneling is another mechanism which uses a specific UDP
   port to indicate a UDP payload format.  Both IPv4 and I. Meilik, "Encapsulation IPv6 can
   support UDP.  Such UDP-based tunnels can be used for Bit Index Explicit Replication (BIER) BIER in MPLS and Non-
              MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
              2018, <https://www.rfc-editor.org/info/rfc8296>.

   [RFC8354]  Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R.,
              Ed., and M. Townsley, "Use Cases for a IPv6 Source Packet
              Routing in Networking (SPRING)", RFC 8354,
              DOI 10.17487/RFC8354, March 2018,
              <https://www.rfc-editor.org/info/rfc8354>.
   network by defining a new UDP port to indicate the BIER header and
   payload.

Authors' Addresses

   Mike McBride
   Futurewei

   Email: michael.mcbride@futurewei.com

   Jingrong Xie
   Huawei

   Email: xiejingrong@huawei.com

   Senthil Dhanaraj
   Huawei

   Email: senthil.dhanaraj@huawei.com

   Rajiv Asati
   Cisco

   Email: rajiva@cisco.com

   Yongqing Zhu
   China Telecom

   Email: zhuyq8@chinatelecom.cn