draft-ietf-bier-ipv6-requirements-04.txt   draft-ietf-bier-ipv6-requirements-05.txt 
Network Working Group M. McBride Network Working Group M. McBride
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Standards Track J. Xie Intended status: Standards Track J. Xie
Expires: July 18, 2020 S. Dhanaraj Expires: January 11, 2021 S. Dhanaraj
Huawei Huawei
R. Asati R. Asati
Cisco Cisco
Y. Zhu Y. Zhu
China Telecom China Telecom
January 15, 2020 G. Mishra
Verizon Inc.
July 10, 2020
BIER IPv6 Requirements BIER IPv6 Requirements
draft-ietf-bier-ipv6-requirements-04 draft-ietf-bier-ipv6-requirements-05
Abstract Abstract
The BIER WG includes, in its charter, work on developing mechanisms The BIER WG charter includes work on developing "a mechanism to use
to transport BIER natively in IPv6. This document is intended to BIER natively in IPv6". There have been several proposed solutions
help the WG with this effort by specifying requirements for in this area. But there hasn't been a document which describes the
transporting packets, with Bit Index Explicit Replication (BIER) problem and lists the requirements. The goal of this document is to
headers, in an IPv6 environment. There will be a need to send IPv6 describe the BIER IPv6 requirements, summarize the encapsulation
payloads, to multiple IPv6 destinations, using BIER. There have been modes of the proposed solutions, guide the working group in
several proposed solutions in this area. But there hasn't been a understanding the benefits and drawbacks of the various solutions,
document which describes the problem and lists the requirements. The and help in the development of acceptable solutions.
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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 18, 2020. This Internet-Draft will expire on January 11, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. BIER IPv6 Scenario's . . . . . . . . . . . . . . . . . . . . 4 3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding 4
3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4 3.1. Transport-Independent Model . . . . . . . . . . . . . . . 5
3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4 3.2. Native IPv6 Model . . . . . . . . . . . . . . . . . . . . 6
3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 5 3.3. Encapsulation Approaches Considered . . . . . . . . . . . 7
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Mandatory Requirements . . . . . . . . . . . . . . . . . 8
4.2. Hop by hop SA or DA modification . . . . . . . . . . . . 5 4.1.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . 8
4.3. L4 Inspection . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Support BIER architecture . . . . . . . . . . . . . . 8
4.4. Multicast address in SA field . . . . . . . . . . . . . . 6 4.1.3. Conform to existing IPv6 Spec . . . . . . . . . . . . 8
4.5. Incorrect bits . . . . . . . . . . . . . . . . . . . . . 6 4.1.4. Support deployment with Non-BFR routers . . . . . . . 8
4.6. SA filtering . . . . . . . . . . . . . . . . . . . . . . 7 4.1.5. Support inter-AS multicast deployment . . . . . . . . 8
4.7. BIER architecture support . . . . . . . . . . . . . . . . 7 4.1.6. Support Simple Encapsulation . . . . . . . . . . . . 9
4.8. Simple Encapsulation . . . . . . . . . . . . . . . . . . 7 4.1.7. Support Deployment Security . . . . . . . . . . . . . 9
4.9. Hardware fast path . . . . . . . . . . . . . . . . . . . 7 4.2. Optional Requirements . . . . . . . . . . . . . . . . . . 9
4.10. Conform to existing IPv6 Spec . . . . . . . . . . . . . . 7 4.2.1. Support MVPN . . . . . . . . . . . . . . . . . . . . 9
4.11. Support Fragmentation . . . . . . . . . . . . . . . . . . 8 4.2.2. Support OAM . . . . . . . . . . . . . . . . . . . . . 9
4.12. Support IPv6 Security . . . . . . . . . . . . . . . . . . 8 4.2.3. Support IPSEC . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.2.4. Support Fragmentation . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4.2.5. Support hardware fast path . . . . . . . . . . . . . 10
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Appendix A. Solutions Evaluation . . . . . . . . . . . . . . . . 9 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
A.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . 10
A.2. Encode Bitstring in IPv6 destination address . . . . . . 11 Appendix A. Solutions Evaluation . . . . . . . . . . . . . . . . 12
A.3. Add BIER header into IPv6 Extension Header . . . . . . . 11 A.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 12
A.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 13 A.2. Encode Bitstring in IPv6 destination address . . . . . . 13
A.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 13 A.3. Add BIER header into IPv6 Extension Header . . . . . . . 13
A.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 A.5. Tunnelling BIER in a IPv6 tunnel . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Bit Index Explicit Replication (BIER) [RFC8279] is an architecture Bit Index Explicit Replication (BIER) [RFC8279] is an architecture
that provides optimal multicast forwarding, without requiring that provides optimal multicast forwarding, without requiring
intermediate routers to maintain per-flow state, through the use of a intermediate routers to maintain per-flow state, through the use of a
multicast-specific BIER header. [RFC8296] defines two types of BIER multicast-specific BIER header. [RFC8296] defines two types of BIER
encapsulation to run on physical links: one is BIER MPLS encapsulation to run on physical links: one is BIER MPLS
encapsulation to run on various physical links that support MPLS, the encapsulation to run on various physical links that support MPLS, the
other is non-MPLS BIER Ethernet encapsulation to run on ethernet other is non-MPLS BIER Ethernet encapsulation to run on ethernet
links, with an ethertype 0xAB37. This document describes using BIER links, with an ethertype 0xAB37. This document describes using BIER
in non-MPLS IPv6 environments. We explain the requirements of in non-MPLS IPv6 environments. We explain the requirements of
transporting IPv4/IPv6 multicast payloads, from an IPv6 router (BFIR) transporting IPv4/IPv6 multicast payloads through an IPv6 network
to multicast IPv6 destinations (BFERs), using BIER. This can include using "BIER natively in IPv6". As clarified in the working-group,
native IPv6 encapsulation and generic tunneling. Native IPv6, in "BIER natively in IPv6" means BIER not encapsulated in MPLS or
this document, is defined as BIER not encapsulated in mpls or Ethernet. This may include native IPv6 encapsulation and generic
ethernet. The goal of this document is to help the BIER WG evaluate IPv6 tunnelling. The goal of this document is to help the BIER WG
the BIER v6 requirements and solutions in order to begin adopting evaluate the BIER v6 requirements and solutions in order to begin
solution drafts. adopting solution drafts.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
o BIER: Bit Index Explicit Replication. Provides optimal multicast o BIER: Bit Index Explicit Replication. Provides optimal multicast
forwarding through adding a BIER header and removing state in forwarding through adding a BIER header and removing state in
intermediate routers. intermediate routers.
o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe
the three types of Ethernet modes that will be forwarded to the three types of Ethernet modes that will be forwarded to
multiple destinations multiple destinations
2. Problem Statement 2. Problem Statement
The problem is the ability of the network to transport BUM packets, The problem is the ability of the network to transport BUM packets,
with BIER headers, in an IPv6 environment. In IPv6 networks, many with BIER headers, in an IPv6 environment. In many IPv6 network
deployments use non-MPLS encapsulation for unicast as the data-plane. deployments, non-MPLS encapsulation is used for unicast as the data-
In such case, it may be expected to have a BIER IPv6 encapsulation plane and it is likewise expected to have BIER IPv6 deployments which
which is compliant with various kinds of physical links, perhaps in a depend on these same unicast technologies.
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 One such case involves supporting a non-BFR router in a network as
described 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 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 technology may be
"Transition Mechanisms and Partial Deployments" which is listed as
the No.1 charter item of BIER WG. Therefore, a basic requirement of
BIER IPv6 is to leverage IPv6 reachability for incremental and inter-
AS BIER deployment.
Below is a simple scenario that needs BIER IPv6 encapsulation and
forwarding:
+--------------------------------------------+ +--------------------------------------------+
| | | |
| +------+ | +------+
| | BFER | | | BFER |
+------+ IPv6 +------+ +------+ +-------+ +-----+ +------+
| BFIR | | | BFIR | |Non-BFR| | BFR | |
+------+ Network +------+ +------+ +-------+ +-----+ +------+
| | BFER | | | BFER |
| +------+ | IPv6 Network +------+
| | | (intra-AS or inter-AS) |
+--------------------------------------------+ +--------------------------------------------+
This basic scenario depicts the need to replicate bier packets from a This scenario depicts the need to replicate bier packets from a BFIR
BFIR to BFERs across an IPv6 core. The IPv6 environment may include to BFERs across an IPv6 core. The IPv6 environment may include a
a variety of link types, may be entirely IPv6, may be dual stack or variety of link types, may be entirely IPv6, may be dual stack or any
any type of combination which includes IPv6. Regardless of the type of combination which includes IPv6. Regardless of the
environment, there are times when a BIER header, including the BIER environment, there are times when a BIER header, including the BIER
bitstring used to determine the set of BIER forwarding egress BitString used to determine the set of BIER forwarding egress
routers, will need to traverse a IPv6 domain. The ways in which BIER 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 will function in an IPv6 environment is the problem that needs to be
solved. [RFC8354] lists some good IPv6 related use cases which we solved.
will similarly reference in this document.
3.1. BIERv6 for Access Network 3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding
Access networks deliver a variety of types of multicast video traffic This analysis introduces two conceptual models for BIER IPv6
from the service provider's network to the home (or Enterprise) encapsulation and forwarding based on the experience and examples
environment and from the home towards the service provider's network. that have been seen in the IETF community.
There will be a need to send traffic from the IPv4 access towards the 3.1. Transport-Independent Model
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 The first conceptual model is a Transport-Independent Model that
views IP tunnels as links of BIER, and views BIER as an independent
"Layer-2.5".
Some Data Center operators are transitioning their Data Center |<----------(L2.5 BIER(P2MP) Tunnel)-------->|
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. +------+ +-------+ +-----+ +------+
| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
+------+ +-------+ +-----+ +------+
3.3. BIERv6 for Core Networks ------- physical link
While the overall amount of traffic offered to the network continues ~~~~~~~ IPv6(P2P) tunnel
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 <-----> BIER(P2MP) tunnel
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.
4. Requirements 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) over a virtual-
link (IPv6 tunnel). On each BFR, the IPv6 tunnel of the receiving
packet is decapsulated, and a new IPv6 tunnel is encapsulated before
sending the packet to the next-hop BFR neighbour.
There have been several suggested requirements, on the BIER email From the view of the IPv6 layer, the BIER header is a kind of Upper-
list and in meetings, which have been used to form BIER IPv6 layer header (Layer-4). From the view of the BIER layer, the IPv6
requirements used to help the wg evaluate against the proposed encapsulation is a tunnel working as a "link" of BIER. With an End-
solutions: to-End view, the tunnel from BFIR to BFERs is a Layer-2.5 BIER (P2MP)
tunnel, and the BFIR-id is the BIER packet source-origin identifier,
and is unchanged through the BIER domain from BFIR to BFERs.
4.1. L2 Agnostic 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.
The solution should be agnostic to the underlying L2 data link type. 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.
4.2. Hop by hop SA or DA modification For IPv4/IPv6 GRE, the "Next Header" is the 16-bit "Protocol Type"
field, and has adequate space for such requirement.
The solution should not require hop-by-hop modification of the IP For IPv4/IPv6 UDP, the "Next Header" is the 16-bit "Destination Port"
source address field. field, and has adequate space for such requirement.
Solutions that do not require Hop-by-hop SA modification are For IPv4/IPv6, the "Next Header" is a 8-bit value and needs to be
preferred. Solutions which maintain the SA will help fast-path allocated from the "Assigned Internet Protocol Numbers" registry.
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, 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 Reassembly/Re-fragmentation of a packet has to be executed on each
the BIER architecture without introducing additional tunnel BFR in such case. This may be common and even friendly for a
encapsulation, and thus may require DA modification by each BFR hop. protocol stack in a BFR software implementation, but it may impose
cost for a BFR hardware implementation.
It is commonly thought that BIERv6 could use a multicast address, as IPv6 functions that are expected to be executed from BFIR to BFER are
BIER is one-hop replication on each BFR in normal cases. However, as assumed to be broken on the BFRs, for example, IPv6 Fragmentation/
described in section 6.9 of [RFC8279], it is useful to support non- Assembly or IPSEC ESP. This is because the "IPv6 tunnel" and all its
BIER routers within a BIER domain. From the wg discussion about this functions is "terminated" on the BFRs. These functions, if desired,
document, focus is on the advantages of using unicast addresses that may need to be re-designed in the "Layer-2.5" BIER mode.
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 For deployment security, it is necessary to ensure the "BIER" packet
is only using the allowed IPv6 tunnel.
The solution should not require the BFRs to inspect layer 4 or 3.2. Native IPv6 Model
require any changes to layer 4.
The proposals requiring BIER header encapsulated as part of the The second conceptual model is a Native IPv6 Model that integrates
payload may conflict with the layers of IP protocol stack. On the BIER as part of the IPv6 data plane, making it a "Layer-3 BIER"
one hand, fast-path BIER forwarding has to be based on the L4 approach.
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 |<----------(L3 BIER(P2MP) tunnel)--------->|
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 | BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
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 ------- physical link
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 <-----> BIER(P2MP) tunnel
The solution should not allow a multicast address to be put in the IP In this model, BIER works as part of the IPv6 data plane. BFIR and
source address field. According to [RFC1112] "A host group address BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6
must never be placed in the source address field or anywhere in a segment endpoints. On each BFR, the segment endpoint behaviour of
source route or record route option of an outgoing IP datagram." IPv6 data plane is executed, and there is no decapsulation of
receiving IPv6 tunnel and encapsulation of new IPv6 tunnel for
sending.
4.5. Incorrect bits In this mode, BIER is integrated into the IPv6 data plane. The IPv6
source address is the BIER packet source-origin identifier, and is
unchanged through the BIER domain from BFIR to BFERs.
The solution should not assume that bits never get set incorrectly. 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.
If a packet with incorrect bits is set, it should not damage BIERv6 This model typically needs an extension to IPv6 data plane, with an
functionality or any other functions such as Unicast Reverse Path IPv6 extension header or Option introduced.
Forwarding (URPF), nor should it cause loops or duplicates as
described in section 6.8 of [RFC8279].
4.6. SA filtering 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.
The solution should not require changes in source address filtering For deployment security, it is necessary to ensure the "BIER" packet
procedures. For instance if a host uses a "BIER address" as its is in a trusted IPv6-based domain.
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 3.3. Encapsulation Approaches Considered
It should be possible to use the solution to support the entire BIER A number of approaches to the design of BIER-IPv6 encapsulation were
architecture. The ability to bypass Non-BIER routers and L2 switches investigated by the BIER Working Group and were discussed in IETF
is part of the BIER architecture and having this ability is a meetings and on the BIER list. This section divides these approaches
mandatory requirement. into the two conceptual models.
Multiple sub-domains bound to one or many topologies or algorithms, Transport-Independent Model approaches include:
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 Transport-Independent BIER [I-D.xu-bier-encapsulation].
The solution should avoid requiring different encapsulation types, or BIERin6 [I-D.zhang-bier-bierin6].
complex tunneling techniques, to support BIER as an E2E multicast
transport.
A single encapsulation should support Layer-2 switches within BFRs, Native IPv6 Model approaches include:
or non-BFR within a BIER domain, or inter-domain deployment of BIER.
4.9. Hardware fast path BIER-over-IPv6 [I-D.pfister-bier-over-ipv6].
The solution should enable the processing and forwarding of BIER BIERv6 [I-D.xie-bier-ipv6-encapsulation].
packets in hardware fast path.
4.10. Conform to existing IPv6 Spec 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. 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 this document, the requirements are divided into two
groups: mandatory and optional. The requirements in the mandatory
group are considered necessary for any BIER IPv6 solution, while the
requirements in the optional group should be considered but are not
mandatory.
4.1. Mandatory Requirements
4.1.1. L2 Agnostic
The solution must be agnostic to the underlying L2 data link type.
The solution needs to support P2P ethernet links as well as shared
media ethernet links without requiring the LAN switch to perform BIER
snooping.
4.1.2. Support BIER architecture
The solution must support the BIER architecture.
Multiple sub-domains bound to one or many topologies or algorithms,
multiple sets for more BFERs, multiple Bit String Lengths for
different forwarding capabilities, and multiple BIFTs for 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 The proposed encapsulation must conform to the IPv6 specification and
guidelines as described in RFC8200. It should not require any new guidelines as described in RFC8200. If new extensions to existing
modifications to the IPv6 specification aside from extensions to IPv6 specification are required, it needs to be discussed and
existing mechanisms such as IPv6 Options. reviewed by the 6man working-group.
4.11. Support Fragmentation 4.1.4. Support deployment with Non-BFR routers
The proposed encapsulation must support fragmentation. It shouldn't The solution must support deployments with Non-BFR routers. This is
require fragmentation and re-assembly at each hop. 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.12. Support IPv6 Security 4.1.5. Support inter-AS multicast deployment
The proposed encapsulation should support IPv6 security including AH/ Inter-AS multicast support is needed for ease of provisioning the
ESP extension headers. It shouldn't require hop-by-hop encryption/ P2MP transport service to enterprises. This could greatly increase
decryption. 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.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.2.5. Support hardware fast path
If a proposed solution is intended for some scenarios like service-
provider networks, it should enable the processing and forwarding of
BIER packets in hardware fast path.
5. IANA Considerations 5. IANA Considerations
Some BIERv6 encapsulation proposals do not require any action from Some BIERv6 encapsulation proposals do not require any action from
IANA while other proposals require new BIER Destination Option IANA while other proposals require new BIER Destination Option
codepoints from IPv6 sub-registries, new "Next header" values, or codepoints from IPv6 sub-registries, new "Next header" values, or
require new IP Protocol codes. This document, however, does not require new IP Protocol codes. This document, however, does not
require anything from IANA. require anything from IANA.
6. Security Considerations 6. Security Considerations
There are no security issues introduced by this draft. There are no security issues introduced by this draft.
7. Acknowledgement 7. Acknowledgement
Thank you to Eric Rosen for his listed set of requirements on the Thank you to Eric Rosen for his listed set of requirements on the
bier wg list. bier wg list.
8. Normative References 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] [I-D.pfister-bier-over-ipv6]
Pfister, P. and I. Wijnands, "An IPv6 based BIER Pfister, P. and I. Wijnands, "An IPv6 based BIER
Encapsulation and Encoding", draft-pfister-bier-over- Encapsulation and Encoding", draft-pfister-bier-over-
ipv6-01 (work in progress), October 2016. ipv6-01 (work in progress), October 2016.
[I-D.xie-bier-ipv6-encapsulation] [I-D.xie-bier-ipv6-encapsulation]
Xie, J., Geng, L., McBride, M., Asati, R., and S. Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S.,
Dhanaraj, "Encapsulation for BIER in Non-MPLS IPv6 Zhu, Y., Qin, Z., Shin, M., and X. Geng, "Encapsulation
Networks", draft-xie-bier-ipv6-encapsulation-04 (work in for BIER in Non-MPLS IPv6 Networks", draft-xie-bier-
progress), December 2019. ipv6-encapsulation-07 (work in progress), June 2020.
[I-D.xu-bier-encapsulation] [I-D.xu-bier-encapsulation]
Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet, Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet,
C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit
Index Explicit Replication (BIER) Encapsulation Header", Index Explicit Replication (BIER) Encapsulation Header",
draft-xu-bier-encapsulation-06 (work in progress), draft-xu-bier-encapsulation-06 (work in progress),
September 2016. September 2016.
[I-D.zhang-bier-bierin6] [I-D.zhang-bier-bierin6]
Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and
skipping to change at page 9, line 23 skipping to change at page 11, line 36
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/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 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279, Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. <https://www.rfc-editor.org/info/rfc8279>.
[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
for Bit Index Explicit Replication (BIER) in MPLS and Non- for Bit Index Explicit Replication (BIER) in MPLS and Non-
MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
2018, <https://www.rfc-editor.org/info/rfc8296>. 2018, <https://www.rfc-editor.org/info/rfc8296>.
[RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx,
Ed., and M. Townsley, "Use Cases for IPv6 Source Packet W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663,
Routing in Networking (SPRING)", RFC 8354, DOI 10.17487/RFC8663, December 2019,
DOI 10.17487/RFC8354, March 2018, <https://www.rfc-editor.org/info/rfc8663>.
<https://www.rfc-editor.org/info/rfc8354>.
[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,
<https://www.rfc-editor.org/info/rfc8754>.
Appendix A. Solutions Evaluation Appendix A. Solutions Evaluation
The following are solutions that have been proposed to solve BIER in The following are solutions that have been proposed to solve BIER in
IPv6 environments. Some solutions propose encoding while others IPv6 environments. Some solutions propose encoding while others
propose encapsulation. It is recommended for the wg to evaluate propose encapsulation. It is recommended for the wg to evaluate
these solutions against the requirements listed previously in order these solutions against the requirements listed previously in order
to make informed decisions on solution readiness. to make informed decisions on solution readiness.
As illustrated in these examples, the BIER header, or the BitString, As illustrated in these examples, the BIER header, or the BitString,
skipping to change at page 10, line 21 skipping to change at page 13, line 8
+---------------+-----------------+------------------- +---------------+-----------------+-------------------
| Ethernet | BIER header | payload | Ethernet | BIER header | payload
| (ethType = | (BIFT-id, ...) | | (ethType = | (BIFT-id, ...) |
| 0xAB37) | | | 0xAB37) | |
| | Next Header | | | Next Header |
+---------------+-----------------+------------------- +---------------+-----------------+-------------------
BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined
in [RFC8296]) can be used to transport the multicast data in the IPv6 in [RFC8296]) can be used to transport the multicast data in the IPv6
network by encapsulating the multicast user data payload within the network by encapsulating the multicast user data payload within the
BIER-ETH header. However, using BIER-ETH in IPv6 networks is not BIER-ETH header. However, BIER-ETH in IPv6 networks is not
considered to be a native IPv6 solution which utilizes the IPv6 considered to be a "BIER natively in IPv6" solution which utilizes
header to forward the packet. Below listed are some of the the IPv6 header to forward the packet.
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 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 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 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, 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, Mixed use of BIER-ETH in a native IPv6 solution is up to the solution
to tunnel over BIER incapable nodes etc. While it is possible and is outside the scope of this document.
for 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 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.
A.2. Encode Bitstring in IPv6 destination address A.2. Encode Bitstring in IPv6 destination address
+---------------+------------------- +---------------+-------------------
| IPv6 header | payload | IPv6 header | payload
| (BitString in | | (BitString in |
| DA lower bits)| | DA lower bits)|
| Next Header | | Next Header |
+---------------+------------------- +---------------+-------------------
skipping to change at page 13, line 30 skipping to change at page 15, line 17
technology. As described in [I-D.xu-bier-encapsulation] and technology. As described in [I-D.xu-bier-encapsulation] and
[I-D.zhang-bier-bierin6], the BIER header, and the payload following [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 it, can be combined as an IPv6 payload, and be indicated by a new
Upper-layer IPv6 Next-Header value. A unicast IPv6 destination Upper-layer IPv6 Next-Header value. A unicast IPv6 destination
address is used for the replication and changes when replicating a address is used for the replication and changes when replicating a
packet out to a neighbor. packet out to a neighbor.
Such proposals may include a request to IANA to allocate an IPv6 Such proposals may include a request to IANA to allocate an IPv6
Next-Header code from "Assigned Internet Protocol Numbers". Next-Header code from "Assigned Internet Protocol Numbers".
A.5. Tunneling BIER in a IPv6 tunnel A.5. Tunnelling BIER in a IPv6 tunnel
+---------------+-----------------+------------+---------------- +---------------+-----------------+------------+----------------
| IPv6 header | IPv6 Ext header | GRE header | | IPv6 header | IPv6 Ext header | GRE header |
| | (optional) | | BIER Hdr + | | (optional) | | BIER Hdr +
| | | | payload as GRE | | | | payload as GRE
| Next Header | Next Header | Proto = X | Payload | Next Header | Next Header | Proto = X | Payload
+---------------+-----------------+------------+---------------- +---------------+-----------------+------------+----------------
A generic IPv6 Tunnel could be used to encapsulate the bier packet A generic IPv6 Tunnel could be used to encapsulate the bier packet
within an IPv6 domain. within an IPv6 domain.
skipping to change at page 14, line 12 skipping to change at page 15, line 42
0xAB37, defined for BIER, can be used in a GRE header to indicate the 0xAB37, defined for BIER, can be used in a GRE header to indicate the
subsequent BIER header and payload in an IPv6 network. subsequent BIER header and payload in an IPv6 network.
+---------------+-----------------+------------+---------------- +---------------+-----------------+------------+----------------
| IPv6 header | IPv6 Ext header | UDP header | | IPv6 header | IPv6 Ext header | UDP header |
| | (optional) | | BIER Hdr + | | (optional) | | BIER Hdr +
| | | | payload as UDP | | | | payload as UDP
| Next Header | Next Header | DPort = X | Payload | Next Header | Next Header | DPort = X | Payload
+---------------+-----------------+------------+---------------- +---------------+-----------------+------------+----------------
UDP-based tunneling is another mechanism which uses a specific UDP UDP-based tunnelling is another mechanism which uses a specific UDP
port to indicate a UDP payload format. Both IPv4 and IPv6 can 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 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 network by defining a new UDP port to indicate the BIER header and
payload. payload.
Authors' Addresses Authors' Addresses
Mike McBride Mike McBride
Futurewei Futurewei
Email: michael.mcbride@futurewei.com Email: michael.mcbride@futurewei.com
Jingrong Xie Jingrong Xie
Huawei Huawei
Email: xiejingrong@huawei.com Email: xiejingrong@huawei.com
skipping to change at line 652 skipping to change at page 17, line 4
Rajiv Asati Rajiv Asati
Cisco Cisco
Email: rajiva@cisco.com Email: rajiva@cisco.com
Yongqing Zhu Yongqing Zhu
China Telecom China Telecom
Email: zhuyq8@chinatelecom.cn 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
 End of changes. 67 change blocks. 
264 lines changed or deleted 339 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/