BIER in IPv6 (BIERin6)

BIER is a new architecture for the forwarding of multicast data packets. It provides optimal forwarding through a "multicast domain" and it does not necessarily precondition construction of a multicast distribution tree, nor does it require intermediate nodes to maintain any per-flow state. This document specifies non-MPLS BIER forwarding in an IPv6 environment, refferred to as BIERin6, using non-MPLS BIER encapsulation specified in . MPLS BIER forwarding in IPv6 is outside the scope of this document. This document uses terminology defined in and . defines the BIER encapsulation format in MPLS and non-MPLS environment. In case of non-MPLS environment, a BIER packet is the payload of an "outer" encapsulation, which has a "next protocol" codepoint that is set to a value that means "non-MPLS BIER". That can be used as is in a pure IPv6 non-mpls environment. Between two directly connected BFRs, a BIER header could directly follow link layer header, e.g., an Ethernet header (with the Ethertype set to 0xAB37). If a BFR needs to tunnel BIER packets to another BFR, e.g. per Section 6.9, IPv6 encapsulation can be used, with the destination address being the downstream BFR and the Next Header field set to a to-be-assigned value for "non-MPLS BIER". The IPv6 encapsulation could be used even between two directly connected BFRs in the following two cases: An operator mandates all traffic to be carried in IPv6. A BFR does not have BIER support in its "fast forwarding path" and relies on "slow/software forwarding path", e.g. in environments like where high throughput multicast forwarding performance is not critical.

Whenever IPv6 encapsulation is used for BIER forwarding, The Next Header field in the IPv6 Header (if there are no extension headers), or the Next Header field in the last extension header is set to TBD, indicating that the payload is a BIER packet. If the neighbor is directly connected, The destination address in IPv6 header SHOULD be the neighbor's link-local address on this router's outgoing interface, the source destination address SHOULD be this router's link-local address on the outgoing interface, and the IPv6 TTL MUST be set to 1. Otherwise, the destination address SHOULD be the BIER prefix of the BFR neighbor, the source address SHOULD be this router's BIER prefix, and the TTL MUST be large enough to get the packet to the BFR neighbor. The Flow-ID in the IPv6 packet SHOULD be copied from the entropy field in the BIER encapsulation.

RFC 8200 section 4, defines the IPv6 extension headers. Currently there are two defined extension headers, Hop-by-Hop and Destination options header, which can carry a variable number of options. These extension headers are inserted by the source node. For directly connected BIER routers, IPv6 Hop-by-Hop or Destination options are irrelevant and SHOULD NOT be inserted by BFIR on the BIERin6 packet. In this case IPv6 header, Next Header field should be set to TBD. Any IPv6 packet arriving on BFRs and BFERs, with multiple extension header where the last extension header has a Next Header field set to TBD, SHOULD be discard and the node should transmit an ICMP Parameter Problem message to the source of the packet (BFIR) with an ICMP code value of TBD10 ('invalid options for BIERin6'). This also indicates that for disjoint BIER routers using IPv6 encapsulation, there SHOULD NOT be any IPv6 Hop-by-Hop or Destination options be present in a BIERin6 packet. In this case, if additional traffic engineering is required, IPv6 tunneling (i.e. BIERin6 over SRv6) can be implemented.

The BIER header MUST be encoded per Section 2.2 of [RFC8296]. The BIFT-id is either encoded per or per advertised by BFRs, as specificed in .

When IPv6 encapsulation is not required between directly connected BFRs, no signaling in addition to that specified in is needed. Otherwise, a node that requires IPv6 encapsualtion MUST advertise the BIER IPv6 transportation sub-TLV/sub-sub-TLV according to local configuration or policy in the BIER domain to request other BFRs to always use IPv6 encapsulation. In presence of multiple encapsulation possibilities hop-by-hop it is a matter of local policy which encapsulation is imposed and the receiving router MUST accept all encapsulations that it advertised.

The BIER IPv6 transportation is a new sub-TLV of BIER defined in OSPF , and a new sub-sub-TLV of BIER Info sub-TLV defined in ISIS .

Type: For OSPF, value TBD1 (prefer 12) is used to indicate it is the IPv6 transportation sub-TLV. For ISIS, value TBD2 (prefer 3) is used to indicate it is the IPv6 transportation sub-sub-TLV. Length: 0.

When BFR-prefixes are advertised across IGP areas per or redistributed across protocol boundaries per , the BIER IPv6 transportation sub-TLV or sub-sub-TLV MAY be re-advertised/re-distributed as well.

IANA is requested to assign a new "BIER" type for "Next Header" in the "Assigned Internet Protocol Numbers" registry. IANA is requested to assign a new "BIERin6" type for "invalid options" in the "ICMP code value" registry. IANA is requested to assign a new "BIER IPv6 transportation Sub-TLV" type in the "OSPFv2 Extended Prefix TLV Sub-TLVs" Registry. IANA is requested to set up a new "BIER IPv6 transportation Sub-sub-TLV" type in the "IS-IS BIER Info sub-TLV" Registry.

General IPv6 and BIER security considerations apply.

The authors would like to thank Jeffrey Zhang for his review and valuable contributions.