wdiff draft-ietf-bier-ipv6-requirements-04.txt draft-ietf-bier-ipv6-requirements-05.txt

Network Working Group M. McBride
Internet-Draft Futurewei
Intended status: Standards Track J. Xie
Expires: July 18, 2020 January 11, 2021 S. Dhanaraj
Huawei
R. Asati
Cisco
Y. Zhu
China Telecom
January 15,
G. Mishra
Verizon Inc.
July 10, 2020

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

Abstract

The BIER WG includes, in its charter, charter includes work on developing mechanisms "a mechanism to transport use
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. IPv6". 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 encapsulation
modes of the proposed solutions, and guide the working group in
understanding the benefits, benefits and drawbacks, drawbacks of the various solutions 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 July 18, 2020. January 11, 2021.

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. Conceptual Models For BIER IPv6 Scenario's . . . . . . . . . . . . . . . . . . . . Encapsulation and Forwarding 4
3.1. BIERv6 for Access Network . Transport-Independent Model . . . . . . . . . . . . . . . 4 5
3.2. BIERv6 for Data Center Native IPv6 Model . . . . . . . . . . . . . . . . . 4
3.3. BIERv6 for Core Networks . . . . . 6
3.3. Encapsulation Approaches Considered . . . . . . . . . . . 5 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 7
4.1. L2 Agnostic Mandatory Requirements . . . . . . . . . . . . . . . . . 8
4.1.1. L2 Agnostic . . . . . . 5
4.2. Hop by hop SA or DA modification . . . . . . . . . . . . 5
4.3. L4 Inspection . . . 8
4.1.2. Support BIER architecture . . . . . . . . . . . . . . 8
4.1.3. Conform to existing IPv6 Spec . . . . . 6
4.4. Multicast address in SA field . . . . . . . 8
4.1.4. Support deployment with Non-BFR routers . . . . . . . 6
4.5. Incorrect bits 8
4.1.5. Support inter-AS multicast deployment . . . . . . . . 8
4.1.6. Support Simple Encapsulation . . . . . . . . . . . . 9
4.1.7. Support Deployment Security . 6
4.6. SA filtering . . . . . . . . . . . . 9
4.2. Optional Requirements . . . . . . . . . . 7
4.7. BIER architecture support . . . . . . . . 9
4.2.1. Support MVPN . . . . . . . . 7
4.8. Simple Encapsulation . . . . . . . . . . . . 9
4.2.2. Support OAM . . . . . . 7
4.9. Hardware fast path . . . . . . . . . . . . . . . 9
4.2.3. Support IPSEC . . . . 7
4.10. Conform to existing IPv6 Spec . . . . . . . . . . . . . . 7
4.11. Support Fragmentation . . 9
4.2.4. Support Fragmentation . . . . . . . . . . . . . . . . 8
4.12. 9
4.2.5. Support IPv6 Security . . . . . hardware fast path . . . . . . . . . . . . . 8 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 8 10
Appendix A. Solutions Evaluation . . . . . . . . . . . . . . . . 9 12
A.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 10 12
A.2. Encode Bitstring in IPv6 destination address . . . . . . 11 13
A.3. Add BIER header into IPv6 Extension Header . . . . . . . 11 13
A.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 13 14
A.5. Tunneling Tunnelling BIER in a IPv6 tunnel . . . . . . . . . . . . . 13 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 15

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 payloads through an IPv6 router (BFIR)
to multicast IPv6 destinations (BFERs), network
using BIER. "BIER natively in IPv6". As clarified in the working-group,
"BIER natively in IPv6" means BIER not encapsulated in MPLS or
Ethernet. This can may include native IPv6 encapsulation and generic tunneling. Native IPv6, in
this document, is defined as BIER not encapsulated in mpls or
ethernet.
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",
"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 IPv6 network
deployments, non-MPLS encapsulation is used for unicast as the data-plane.
In such case, data-
plane and it may be is likewise expected to have a BIER IPv6 encapsulation deployments which is compliant with various kinds of physical links, perhaps
depend on these same unicast technologies.

One such case involves supporting a non-BFR router in a
hop-by-hop manner, and maintain the benefit network as
described in section 6.9 of "fast reroute" RFC8279. In the context of this
document, an IPv6 tunnel. Evaluating based unicast tunnel is needed to support such
deployment where a non-BFR exists. Another case is to support inter-
AS multicast deployment as illustrated in
[I-D.geng-bier-ipv6-inter-domain]. In 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 requirements will help
determine technology may be
"Transition Mechanisms and Partial Deployments" which is listed as
the best solutions No.1 charter item of BIER WG. Therefore, a basic requirement of
BIER IPv6 is to address these problems.

3. leverage IPv6 reachability for incremental and inter-
AS BIER deployment.

Below is a simple scenario that needs BIER IPv6 Scenario's encapsulation and
forwarding:

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

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

3. Conceptual Models For BIER IPv6 related use cases which we
will similarly reference Encapsulation and Forwarding

This analysis introduces two conceptual models for BIER IPv6
encapsulation and forwarding based on the experience and examples
that have been seen in this document. the IETF community.

3.1. BIERv6 for Access Network

Access networks deliver Transport-Independent Model

The first conceptual model is a variety Transport-Independent Model that
views IP tunnels as links of types BIER, and views BIER as an independent
"Layer-2.5".

|<----------(L2.5 BIER(P2MP) Tunnel)-------->|
| |
| +~~~~~~~~~~~~~~~~~~+ +~~~~+ |
| / \ / \ |
+------+ +-------+ +-----+ +------+
| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
+------+ +-------+ +-----+ +------+

------- physical link

~~~~~~~ IPv6(P2P) tunnel

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

In this model, an IPv6 tunnel works as a link-layer of multicast video traffic
from the service provider's network to the home (or Enterprise)
environment BIER, and from the home towards the service provider's network.

There will be BIER
works as a need to send traffic from the IPv4 access towards transport-independent layer (or layer-2.5) over a virtual-
link (IPv6 tunnel). On each BFR, the
service provider's IPv6 network and vice versa. A tunnel of the receiving
packet could be
mapped into is decapsulated, and a providers new IPv6 network through the use of a BIERv6
header. The access devices would not need to know specific details
about tunnel is encapsulated before
sending the packet to perform this mapping; instead the access device
would only need to know how to process a next-hop BFR neighbour.

From the view of the IPv6 layer, the 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 a kind of traffic offered to Upper-
layer header (Layer-4). From the network continues
to grow and considering that multiple types view 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 BIER layer, the near
future, an IPv6 only native infrastructure for their core network.
Having
encapsulation is a native BIERv6 infrastructure will help maintain simplicity tunnel working as a "link" of BIER. With an End-
to-End view, the network tunnel from BFIR to BFERs is a Layer-2.5 BIER (P2MP)
tunnel, and reduce state versus traditional IP Multicast.

4. Requirements

There have been several suggested requirements, on the BFIR-id is the BIER email
list packet source-origin identifier,
and in meetings, which have been used to form is unchanged through the BIER IPv6
requirements used domain from BFIR to help the wg evaluate against the proposed
solutions:

4.1. L2 Agnostic

The solution should be agnostic BFERs.

This model is similar to the underlying L2 data link type.

4.2. Hop by hop SA "MPLS over IP" [RFC4023] 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 "MPLS over
UDP" [RFC7510] approach. A more encapsulation general output of such as Service Label, are beneficial for
SA filtering (req 4.6 approach in this doc), and are beneficial for data
origin authentication if IPSEC
IETF is desired (req 4.12 in this doc).

The solution should "MPLS Segment Routing over IP" [RFC8663]. It makes use a IPv6 unicast address in the DA to satisfy
the BIER architecture without introducing additional of
IPv4/IPv6 tunnel, IPv4/IPv6 UDP tunnel
encapsulation, and thus may require DA modification by each BFR hop.

It is commonly thought that BIERv6 IPv4/IPv6 GRE tunnel to
encapsulate the MPLS-based instructions. In fact, BIER-MPLS could
use a multicast address, as
BIER this approach directly since BIER-MPLS is one-hop replication based on each BFR in normal cases. However, as
described MPLS.

There may be, however, in section 6.9 certain cases some difficulty with
allocation of [RFC8279], it is useful an MPLS label and advertisement through the control-
plane. For example, a simple inter-AS BIER deployment may want to support non-
use the auto-configuration of BIFT-id using Non-MPLS BIER routers within
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 domain. From header.

For IPv4/IPv6 GRE, the wg discussion about this
document, focus "Next Header" is on the advantages 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 using unicast addresses that
otherwise could not a packet has to be possible by using executed on each
BFR in such case. This may be common and even friendly for a multicast address or
anycast address
protocol stack in a BFR software implementation, but it may impose
cost for two cases: replication from a BFR hardware implementation.

IPv6 functions that are expected to other BFR(s)
connected by Layer-3 Non-BFR router(s) without using tunneling
techniques, and replication be executed from a BFR BFIR to other BFR(s) connected by
Layer-2 switch(es) without broadcasting BFER are
assumed to be broken on the BFRs, for example, IPv6 Fragmentation/
Assembly or snooping IPSEC ESP. This is because the "IPv6 tunnel" and all its
functions is "terminated" on Layer-2
switch(es) the BFRs. These functions, if desired,
may need to be re-designed in between. Based on the natural reachability of an IPv6
unicast address, "Layer-2.5" BIER mode.

For deployment security, it can support the multi-hop replication cases as
well as is necessary to ensure the one-hop replication case "BIER" packet
is only 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. allowed IPv6 tunnel.

3.2. Native IPv6 Model

The proposals requiring second conceptual model is a Native IPv6 Model that integrates
BIER header encapsulated as part of the
payload may conflict with the layers IPv6 data plane, making it a "Layer-3 BIER"
approach.

|<----------(L3 BIER(P2MP) tunnel)--------->|
| |
+------+ +-------+ +-----+ +------+
| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
+------+ +-------+ +-----+ +------+

------- physical link

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

In this model, BIER works as part of IP protocol stack. the IPv6 data plane. BFIR and
BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6
segment endpoints. On each BFR, the
one hand, fast-path 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
sending.

In this mode, BIER forwarding has to be based on is integrated into the L4
inspection of IPv6 data plane. The IPv6
source address is the BIER header within the payload, packet source-origin identifier, and on the other
hand, is
unchanged through the BIER forwarding needs domain from BFIR to change BFERs.

This model is similar to many examples emerging in the BitString 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 BIER
header number of
encapsulation layers, capability of deployment with non-capable
routers in a network, extending the payload, which technology in turn conflicts 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 other L3
functions. Following an
IPv6 extension header or Option introduced.

IPv6 functions that are some examples.

One example 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 in IP fragmentation case, where a packet may need trusted IPv6-based domain.

3.3. Encapsulation Approaches Considered

A number of approaches to
be fragmented the design of BIER-IPv6 encapsulation were
investigated by a BFIR, according to the BIER-MTU defined in
RFC8296, into one packet with BIER header Working Group and 1500 bytes of payload, were discussed in IETF
meetings and another packet with on the remaining 500 bytes of payload. When BFR
B receives BIER list. This section divides these approaches
into the second fragmentation packet from BFR A, BFR B can't
forward this packet because BFR B doesn't two conceptual models.

Transport-Independent Model approaches include:

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

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

Native IPv6 Model approaches include:

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

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

4. Requirements

There have been several suggested requirements, on the BIER header email
list and in meetings, which have been used to form BIER IPv6
requirements used to help the
second fragmentation packet. Section 4.11 describes wg evaluate against the
fragmentation requirements.

The second example proposed
solutions. There is in IPSEC case, where also many further discussions on the list about
BIER header is part of IPv6 requirements from different scenarios.

Considering that the payload importance of requirement for confidentiality or integrity. The need to change BIER IPv6 solution
is different, in this document, the
BitString requirements are divided into two
groups: mandatory and optional. The requirements in the mandatory
group are considered necessary for any BIER Header, when forwarding BIER packets, makes it
incompatible with IPSEC. Section 4.12 describes IPv6 solution, while the IPSEC
requirements.

4.4. Multicast address in SA field

The solution should not allow a multicast address to be put
requirements in the IP
source address field. According to [RFC1112] "A host optional group address should be considered but are not
mandatory.

4.1. Mandatory Requirements

4.1.1. L2 Agnostic

The solution must never be placed in agnostic to the source address field or anywhere in a
source route or record route option of an outgoing IP datagram."

4.5. Incorrect bits underlying L2 data link type.
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 needs to support P2P ethernet links 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" well as its
source address in a given packet, and shared
media ethernet links without requiring the packet doesn't get dropped
according LAN switch to existing SA filtering procedures, the packet may elicit
responses that put the perform 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.
snooping.

4.1.2. Support BIER architecture support

It should be possible to use the

The solution to must 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 Lengths for
different forwarding capability, capabilities, 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 are
considered essential functions of BIER
packets in hardware fast path.

4.10. 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. It should not require any If new
modifications extensions to the existing
IPv6 specification aside from extensions are required, it needs to
existing mechanisms such as 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 routers. This is
beneficial to the deployment of BIER, especially in early deployments
when some routers do not support BIER forwarding but support IPv6 Options.

4.11.
forwarding. This is also the No.1 charter item, "Transition
Mechanisms and Partial Deployments" of the BIER WG.

4.1.5. Support Fragmentation 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 proposed 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 fragmentation. 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.2.2. Support OAM

BIER OAM MAY be supported, either directly using existing method, or
specify some variant method for the same function. It may be
considered essential as part of the BIER architecture in some cases.

4.2.3. Support IPSEC

IPSEC is optional to IPv6 and multicast. It is preferred to support
IPSEC, including AH/ESP. If 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 IPv6 may support
fragmentation on BFIR and assembly on BFER. Support of Fragmentation
can enhance the capability of BIER leveraging the BIER-MTU as
introduced in section 3 of [RFC8296]. If Fragmentation is to be
supported, it shouldn't require fragmentation and re-assembly at each
hop.

4.12.

4.2.5. Support IPv6 Security

The hardware fast path

If a proposed encapsulation solution is intended for some scenarios like service-
provider networks, it should support IPv6 security including AH/
ESP extension headers. It shouldn't require hop-by-hop encryption/
decryption. enable the processing and forwarding of
BIER packets in hardware fast path.

5. IANA Considerations

Some BIERv6 encapsulation proposals do not require any action from
IANA while 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 Eric Rosen for his listed set of requirements on the
bier wg list.

8. Normative References

[I-D.geng-bier-ipv6-inter-domain]
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.

[I-D.ietf-bier-use-cases]
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.

[I-D.ietf-spring-srv6-network-programming]
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.

[I-D.pfister-bier-over-ipv6]
Pfister, P. and I. Wijnands, "An IPv6 based 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, S.,
Zhu, Y., Qin, Z., Shin, M., and X. Geng, "Encapsulation
for BIER in Non-MPLS IPv6 Networks", draft-xie-bier-ipv6-encapsulation-04 draft-xie-bier-
ipv6-encapsulation-07 (work in progress), December 2019. June 2020.

[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 IPv6 (BIERin6)", draft-zhang-bier-
bierin6-04 (work in progress), January 2020.

[RFC1112] Deering, S., "Host extensions for 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 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 S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.

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

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>.

[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510,
DOI 10.17487/RFC7510, April 2015,
<https://www.rfc-editor.org/info/rfc7510>.

[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., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (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.,

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

[RFC8754] Filsfils, C., Maglione, R., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and M. Townsley, "Use Cases for IPv6 Source Packet D. Voyer, "IPv6 Segment Routing in Networking (SPRING)", Header
(SRH)", RFC 8354, 8754, DOI 10.17487/RFC8354, 10.17487/RFC8754, March 2018,
<https://www.rfc-editor.org/info/rfc8354>. 2020,
<https://www.rfc-editor.org/info/rfc8754>.

Appendix A. Solutions Evaluation

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

As illustrated in these examples, the BIER header, or the BitString,
may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload,
or IPv6 Tunnel Packet:

A.1. BIER-ETH encapsulation in IPv6 networks

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, using BIER-ETH in IPv6 networks is not
considered to be a native IPv6 "BIER natively in 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 for the same,

o BIER-ETH is not agnostic to the underlying (L2) data link type.
It can be deployed only in the networks with Ethernet data link
and cannot be deployed in an network which deploys any other data
link types. Use

Mixed 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 in native 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 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
and state maintenance from the network, it still requires some
sort of ID (similar up 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, solution
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
for outside the BIER-ETH encapsulated packet to be further encapsulated
within a GRE6, etc tunnel, it might not be possible to parse
and decapsulate different types scope 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 in
processing the tunnel and BIER header 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. this document.

A.2. Encode Bitstring in IPv6 destination address

As described in [I-D.pfister-bier-over-ipv6], The information
required by BIER is stored in 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 is required. Instead of
encapsulating the packet in IPv6, the payload is attached to 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 the BitString in the IPv6 destination address changes.

A.3. Add BIER header into IPv6 Extension 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 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 IPv6 header.

Two of the currently-defined extension headers are the Hop-by-Hop
Options 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 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
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 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".

A.4. Transport BIER as IPv6 payload

There is a proposal for a transport-independent BIER encapsulation
header which is applicable regardless of the underlying transport
technology. As described 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 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. Tunneling Tunnelling BIER in a IPv6 tunnel

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.

UDP-based tunneling 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
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
Gyan S. Mishra
Verizon Inc.

13101 Columbia Pike

Silver Spring
,

MD 20904

United States of America

Phone:
301 502-1347

Email:
gyan.s.mishra@verizon.com