| BIER | M. McBride |
| Internet-Draft | J. Xie |
| Intended status: Standards Track | S. Dhanaraj |
| Expires: November 10, 2019 | Huawei |
| R. Asati | |
| Cisco | |
| May 9, 2019 |
BIER IPv6 Requirements
draft-mcbride-bier-ipv6-requirements-01
The BIER WG has a charter item to work on mechanisms which 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. 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 and summarize the pro's and con's of the proposed solutions.
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 November 10, 2019.
Copyright (c) 2019 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.
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. The goal of this document is to help the BIER WG evaluate the BIER v6 requirements and solutions.
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.
The problem is the ability of the network to transport BUM packets, with BIER headers, in an IPv6 environment. In an IPv6 network, many deployments consider using a 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.
+--------------------------------------------+
| |
| +------+
| | 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.
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.
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.
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.
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.
There have been several suggested requirements, on the BIER email list, which we will use to form the BIER IPv6 requirements and to help evaluate the proposed solutions:
The solution should be agnostic to the underlying L2 data link type.
The solution should not require hop-by-hop modification of the IP destination address field.
The solution should not require the BFRs to inspect layer 4 or require any changes to layer 4.
The solution should not allow a multicast address to be put in the IP source address field.
The solution should not assume that bits never get set incorrectly.
The solution should not require changes in source address filtering procedures.
The solution should be possible to be used to support the entire BIER architecture.
The solution should avoid having to use different encapsulation types, or use complex tunneling techniques, to support BIER as a E2E multicast transport.
The solution should enable the processing and forwarding of BIER packets in hardware fast path.
The following are solutions that have been proposed to solve BIER in IPv6 environments.
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:
+---------------+-----------------+-------------------
| Ethernet | BIER header | payload
| (ethType = | (BIFT-id, ...) |
| 0xAB37) | |
| | Next Header |
+---------------+-----------------+-------------------
BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined in [RFC8296]) can be used to transport the multicast data in the IPv6 network by encapsulating the multicast user data payload within the BIER-ETH header. However, using BIER-ETH 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 for the same,
+---------------+-------------------
| IPv6 header | payload
| (BitString in |
| DA lower bits)|
| Next Header |
+---------------+-------------------
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.
+---------------+-----------------+-------------------
| IPv6 header | IPv6 Ext header | payload
|(Multicast DA) | (BIER header in |
| | TLV Type = X) |
| Next Header | Next Header |
+---------------+-----------------+-------------------
According to [RFC8200] In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper- layer header in a packet. There is a small number of such extension headers, each one identified by a distinct Next Header value. An IPv6 packet may carry zero, one, or more extension headers, each identified by the Next Header field of the preceding header. Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. The Hop-by-Hop Options header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field 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".
+---------------+-----------------+-------------------
| IPv6 header | IPv6 Ext header | BIER Hdr + payload
| | (optional) | as IPv6 payload
| | |
| Next Header | Next Header = X |
+---------------+-----------------+-------------------
There is a proposal for a transport-independent BIER encapsulation header which is applicable regardless of the underlying transport technology. As described 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".
+---------------+-----------------+------------+----------------
| 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 to encapsulate the bier packet within an IPv6 domain.
GRE is a mechanism by which any ethernet payload can be carried by an IP GRE tunnel due to the 16-bits 'Protocol Type' field. Both IPv4 and IPv6 can be used to carry GRE. The Ethernet type codepoint 0xAB37, defined for BIER, can be used in a GRE header to indicate the subsequent BIER header and payload in an IPv6 network.
+---------------+-----------------+------------+----------------
| IPv6 header | IPv6 Ext header | UDP header |
| | (optional) | | BIER Hdr +
| | | | payload as UDP
| Next Header | Next 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 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.
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.
There are no security issues introduced by this draft.
Thank you to Eric Rosen for his listed set of requirements on the bier wg list.