< draft-xie-bier-ipv6-encapsulation-06.txt   draft-xie-bier-ipv6-encapsulation-07.txt >
Network Working Group J. Xie Network Working Group J. Xie
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track L. Geng Updates: 8296 (if approved) L. Geng
Expires: September 10, 2020 China Mobile Intended status: Standards Track China Mobile
M. McBride Expires: December 31, 2020 M. McBride
Futurewei Futurewei
R. Asati R. Asati
Cisco Cisco
S. Dhanaraj S. Dhanaraj
Huawei Huawei
March 9, 2020 Y. Zhu
China Telecom
Z. Qin
China Unicom
M. Shin
LG Uplus
X. Geng
Huawei
June 29, 2020
Encapsulation for BIER in Non-MPLS IPv6 Networks Encapsulation for BIER in Non-MPLS IPv6 Networks
draft-xie-bier-ipv6-encapsulation-06 draft-xie-bier-ipv6-encapsulation-07
Abstract Abstract
This document proposes a BIER IPv6 (BIERv6) encapsulation for Non- This document proposes a BIER IPv6 (BIERv6) encapsulation for Non-
MPLS IPv6 Networks using the IPv6 Destination Option extension MPLS IPv6 Networks using the IPv6 Destination Option extension
header. This document updates [RFC8296]. header. This document updates RFC 8296.
Requirements Language 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 [RFC2119] and document are to be interpreted as described in [RFC2119] and
[RFC8174]. [RFC8174].
Status of This Memo Status of This Memo
skipping to change at page 1, line 46 skipping to change at page 2, line 10
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 September 10, 2020. This Internet-Draft will expire on December 31, 2020.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 3 3. BIER IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 4
3.1. BIER Option in IPv6 Destination Options Header . . . . . 3 3.1. BIER Option in IPv6 Destination Options Header . . . . . 4
3.2. Multicast and Unicast Destination Address . . . . . . . . 6 3.2. Multicast and Unicast Destination Address . . . . . . . . 6
3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8 3.3. BIERv6 Packet Format . . . . . . . . . . . . . . . . . . 8
4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9 4. BIERv6 Packet Processing . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 11 5.1. Intra Domain Deployment . . . . . . . . . . . . . . . . . 12
5.2. ICMP Error Processing . . . . . . . . . . . . . . . . . . 12 5.2. ICMP Error Processing . . . . . . . . . . . . . . . . . . 13
5.3. Security caused by BIER option . . . . . . . . . . . . . 13 5.3. Security caused by BIER option . . . . . . . . . . . . . 13
5.4. Applicability of IPsec . . . . . . . . . . . . . . . . . 13 5.4. Applicability of IPsec . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 14 6.1. BIER Option Type . . . . . . . . . . . . . . . . . . . . 15
6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15 6.2. End.BIER Function . . . . . . . . . . . . . . . . . . . . 15
6.3. BIER Next Protocol Identifiers . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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 any per-flow state by using a intermediate routers to maintain any per-flow state by using a
multicast-specific BIER header. multicast-specific BIER header.
[RFC8296] defines a common BIER Header format for MPLS and Non-MPLS [RFC8296] defines a common BIER Header format for MPLS and Non-MPLS
networks. It has defined two types of encapsulation methods using networks. It has defined two types of encapsulation methods using
skipping to change at page 3, line 34 skipping to change at page 3, line 41
[I-D.ietf-bier-ipv6-requirements]. [I-D.ietf-bier-ipv6-requirements].
2. Terminology 2. Terminology
Readers of this document are assumed to be familiar with the Readers of this document are assumed to be familiar with the
terminology and concepts of the documents listed as Normative terminology and concepts of the documents listed as Normative
References. References.
The following new terms are used throughout this document: The following new terms are used throughout this document:
o BIERv6 - BIER IPv6. o BIERv6 - Bit indexed explicit replication using IPv6 data plane.
o BIER Option - An Option type carried in IPv6 Destination Options o BIERv6 Domain - A limited-domain using BIERv6 encapsulation as
Header which includes the standard Non-MPLS BIER Header. specified in this document for transporting customer multicast
packets from one router to multiple destination routers. It is
usually managed by a single administrative entity, e.g., a
service-provider. It could be a single AS network or a large-
scale network that includes multiple ASes. BIER Domain is also
used for the same meaning as BIERv6 domain in this document.
o BIERv6 Option - An Option type carried in IPv6 Destination Options
Header (DO header, DOH) which includes the standard Non-MPLS BIER
Header. It is in type-length-value (TLV) format. The value
portion of the BIERv6 Option TLV, or the BIERv6 Option Data, is in
the format of the standard Non-MPLS BIER header. BIER option is
also used for the same meaning as BIERv6 option in this document.
o BIERv6 Header - An IPv6 Header with BIER Option. o BIERv6 Header - An IPv6 Header with BIER Option.
o BIERv6 Packet - An IPv6 packet with BIERv6 Header. Such an IPv6 o BIERv6 Packet - An IPv6 packet with BIERv6 Header. An IP/IPv6/
packet typically carries the user multicast payload and is Ethernet multicast packet is encapsulated with an outside BIERv6
forwarded by BFRs in the BIERv6 network towards the multicast header and transformed to a BIERv6 packet on the ingress PE
receivers. (BFIR). BIERv6 packet is transported by the transit routers
(BFRs) through a BIERv6 domain towards egress PEs(BFERs). BIERv6
packet is decapsulated by the BFERs, with the original IP/IPv6/
Enthernet multicast packet being obtained and forwarded towards
the multicast receivers .
3. BIER IPv6 Encapsulation 3. BIER IPv6 Encapsulation
3.1. BIER Option in IPv6 Destination Options Header 3.1. BIER Option in IPv6 Destination Options Header
Destination Options Header and the Options that can be carried under Destination Options Header and the Options that can be carried under
this extension header is defined in [RFC8200]. This document defines this extension header is defined in [RFC8200]. This document defines
a new Option type - BIER Option, to encode the Non-MPLS BIER header. a new Option type - BIER Option, to encode the Non-MPLS BIER header.
As specified in Section 4.2 [RFC8200], the BIER Option follows type- As specified in Section 4.2 [RFC8200], the BIER Option follows type-
length-value (TLV) encoding format and the standard Non-MPLS BIER length-value (TLV) encoding format and the standard Non-MPLS BIER
header [RFC8296] is encoded in the value portion of the BIER Option header [RFC8296] is encoded in the value portion of the BIER Option
TLV. TLV.
This BIER Option MUST be carried only inside the IPv6 Destination This BIER Option MUST be carried only inside the IPv6 Destination
Options header and MUST NOT be carried under the Hop-by-Hop Options Options header and MUST NOT be carried under the Hop-by-Hop Options
header. header.
Co-existence of Destination Options Header with BIER option TLV and
other IPv6 extension headers MUST confirm to the general requirements
defined in [RFC8200]. In addition to the requirements defined in
[RFC8200], this document requires that the Destination Options Header
with a BIER Option TLV MUST appear only after the Routing Header if
the Routing Header is present in the IPv6 Header.
The BIER Option is encoded in type-length-value (TLV) format as The BIER Option is encoded in type-length-value (TLV) format as
follows: follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Option Type | Option Length | | Next Header | Hdr Ext Len | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Non-MPLS BIER Header (defined in RFC8296) ~ ~ BIERv6 Option Data (Non-MPLS BIER Header defined in RFC8296) ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header Next Header 8-bit selector. Identifies the type of header
immediately following the Destination Options header. immediately following the Destination Options header.
Hdr Ext Len 8-bit unsigned integer. Length of the Destination Hdr Ext Len 8-bit unsigned integer. Length of the Destination
Options header in 8-octet units, not including the first 8 octets. Options header in 8-octet units, not including the first 8 octets.
Option Type To be allocated by IANA. See section 6. Option Type To be allocated by IANA. See section 6.
Option Length 8-bit unsigned integer. Length of the option, in Option Length 8-bit unsigned integer. Length of the option, in
octets, excluding the Option Type and Option Length fields. octets, excluding the Option Type and Option Length fields.
Non-MPLS BIER Header The Non-MPLS BIER Header defined in RFC8296. BIERv6 Option Data The BIERv6 Option Data contains the Non-MPLS BIER
Fields in the Non-MPLS BIER Header MUST be encoded as below. Header defined in RFC8296. Fields in the Non-MPLS BIER Header
MUST be encoded as below.
BIFT-id: The BIFT-id is a domain-wide unique value in Non-MPLS BIFT-id: The BIFT-id is a domain-wide unique value in Non-MPLS
IPv6 encapsulation. See Section 2.2 of RFC 8296. IPv6 encapsulation. See Section 2.2 of RFC 8296.
TC: SHOULD be set to binary value 000 upon transmission and MUST TC: SHOULD be set to binary value 000 upon transmission and MUST
be ignored upon. See Section 2.2 of RFC 8296. be ignored upon. See Section 2.2 of RFC 8296.
S bit: SHOULD be set to 1 upon transmission, and MUST be ignored S bit: SHOULD be set to 1 upon transmission, and MUST be ignored
upon reception. See Section 2.2 of RFC 8296. upon reception. See Section 2.2 of RFC 8296.
skipping to change at page 5, line 31 skipping to change at page 5, line 46
BSL: See Section 2.1.2 of RFC 8296. BSL: See Section 2.1.2 of RFC 8296.
Entropy: See Section 2.1.2 of RFC 8296. Entropy: See Section 2.1.2 of RFC 8296.
OAM: See Section 2.1.2 of RFC 8296. OAM: See Section 2.1.2 of RFC 8296.
Rsv: See Section 2.1.2 of RFC 8296. Rsv: See Section 2.1.2 of RFC 8296.
DSCP: SHOULD be set to binary value 000000 upon transmission and DSCP: SHOULD be set to binary value 000000 upon transmission and
MUST be ignored upon reception. In IPv6 BIER encapsulation, MUST be ignored upon reception. In BIERv6 encapsulation, uses
uses highest 6-bit of Traffic Class field of IPv6 header to hold Traffic Class field of IPv6 header instead.
a Differentiated Services Codepoint [RFC2474].
Proto: This fileld is used for two functions. The first is to Proto: SHOULD be set to 0 upon transmission and be ignored upon
identify the BIER Payload following the BIER header, and the reception. In BIERv6 encapsulation, the functionality of this
second is to deliver the packet to a proper overlay module by 6-bit Proto field is replaced by the Next Header field in
BIER layer, with VRF lookup in case of BIER data process, or Destination Options header or the last IPv6 extension header to
without VRF lookup in case of BIER OAM process. In BIER IPv6 indicate the type of the payload. This updates section 2.1.2 of
encapsulation, the first function of Proto is compromised by a [RFC8296] about Proto definition. Next Header value in BIERv6
proper Next Header value combination, and the second function of encapsulation for common usage includes:
Proto should be kept with the semantic unique and consistent for
BIER demultiplexing. This updates section 2.1.2 of [RFC8296]
about Proto defination. This document support the following
combination of BIER Proto and Next Header:
Use Next Header value 4, 41 and 143 for IPv4 packet, IPv6 Value 4 for IPv4 packet as BIERv6 payload.
packet and Ethernet packet respectively, and use Proto value
TBD1 indicating "Delivering the data packet with VRF lookup
in IPv6 source address".
Use Next Header value 59 for private packet format, and use Value 41 for IPv6 packet as BIERv6 payload.
Proto value 5 indicating "Delivering the BIER OAM packet
without VRF lookup". The BIER-PING [I-D.ietf-bier-ping]
works equally in BIER IPv6 encapsulation as well as in BIER
MPLS or BIER Ethernet encapsulation.
Allocation of BIER Proto value TBD1 is listed in the IANA Value 143 for Ethernet packet as BIERv6 payload.
considerations section of this document.
Multicast VPN (MVPN) service is considered as part of the BIER
layering mode defined in [RFC8279], and should be supported by
BIERv6 encapsulation. [I-D.xie-bier-ipv6-mvpn] illustrates how
MVPN is supported in BIERv6 encapsulation without using this
Proto field.
BIER-PING [I-D.ietf-bier-ping] is considered a useful function
of the BIER architecture, and should be supported by BIERv6
encapsulation. How BIER-PING is supported in BIERv6
encapsulation without using this Proto field is outside the
scope of this document.
BFIR-id: See Section 2.1.2 of RFC 8296. BFIR-id: See Section 2.1.2 of RFC 8296.
BitString: See Section 2.1.2 of RFC 8296. BitString: See Section 2.1.2 of RFC 8296.
3.2. Multicast and Unicast Destination Address 3.2. Multicast and Unicast Destination Address
BIER is generally a hop-by-hop and one-to-many architecture, and thus BIER is generally a hop-by-hop and one-to-many architecture, and thus
the IPv6 Destination Address (DA) being a Multicast Address is a way the IPv6 Destination Address (DA) being a Multicast Address is a way
one may think of as an approach for both the two paradigms in BIERv6 one may think of as an approach for both the two paradigms in BIERv6
encapsulation. encapsulation.
However using a unicast address has the following benefits: However using a unicast address has the following benefits:
1. Tunneling a BIERv6 packet over a non-BIER capable router. 1. Replicating a BIERv6 packet over a non-BIER capable router.
2. Fast rerouting a BIERv6 packet using a unicast by-pass tunnel. 2. Fast rerouting a BIERv6 packet using a unicast by-pass tunnel.
3. Forwarding a BIERv6 packet to one of the many BFR neighbors 3. Forwarding a BIERv6 packet to one of the many BFR neighbors
connected on a LAN. connected on a LAN without imposing new requirements of snooping
on switches.
4. Connecting BIER domains, for example Data Center domains, in an 4. Replicating a BIERv6 packet through an anonymous system(AS) to
overlay manner. BFERs in other ASes, as illustrated in
[I-D.geng-bier-ipv6-inter-domain].
Some of the above functions are assumed very basic requirements and Some of the above scenarios are assumed part of BIER architecture as
part of BIER architecture as described in [RFC8279]. This document described in [RFC8279], and some of them are the scalability aspects
uses unicast address for both one-hop replication and multi-hop for inter-AS stateless multicast this document intends to support.
replication. This document intends to fulfil all these requirements (categorized
as multi-hop replication), and proposes to use unicast address for
both one-hop replication and multi-hop replication.
The unicast address used in BIERv6 packet targeting a BFR SHOULD be The unicast address used in BIERv6 packet targeting a BFR SHOULD be
advertised as part of the BIER IPv6 Encapsulation. When a BFR advertised as part of the BIER IPv6 Encapsulation. When a BFR
advertises the BIER information with BIERv6 encapsulation capability, advertises the BIER information with BIERv6 encapsulation capability,
an IPv6 unicast address of this BFR MUST be selected specifically for an IPv6 unicast address of this BFR MUST be selected specifically for
BIERv6 packet forwarding. Locally this "BIER Specific" IPv6 address BIERv6 packet forwarding. Locally this "BIER Specific" IPv6 address
is initialized in FIB with a flag of "BIER specific handling", is initialized in FIB with a flag of "BIER specific handling",
represented as End.BIER function. represented as End.BIER function.
If a BFR belongs to more than one sub-domain, it may (though it need If a BFR belongs to more than one sub-domain, it may (though it need
not) have a different End.BIER in each sub-domain. If different not) have a different End.BIER in each sub-domain. If different
End.BIER is used for each sub-domain, implementation SHOULD support End.BIER is used for each sub-domain, implementation SHOULD support
verifying the DA of a BIERv6 packet is the End.BIER address bound by verifying the DA of a BIERv6 packet is the End.BIER address bound by
the sub-domain of the packet. See section 5.2 for such use case. the sub-domain of the packet.
For security deployment of BIERv6, the End.BIER address(es) is
required to be allocated from an IPv6 address block, and the IPv6
address block is used for domain boundary security policy. See
section 5.1 of this document for such security policy. Such kind of
security policy using IPv6 address block follows the paradigm settled
by the [RFC8754] section 5.
The following is an example of configuring a sub-domain using BIER The following is an example of configuring a sub-domain using BIER
IPv6 encapsualation: IPv6 encapsualation:
# Config an IPv6 block for End.BIER IPv6 address allocation # Config an IPv6 block for End.BIER IPv6 address allocation
ipv6-block blk1 2001:DB8:A1:: 96 static 32 ipv6-block blk1 2001:DB8:A1:: 96 static 32
# Config BIER Sub-domain using End.BIER allocated from blk1 # Config BIER Sub-domain using End.BIER allocated from blk1
bier sub-domain 6 ipv6-underlay bier sub-domain 6 ipv6-underlay
bfr-prefix interface loopback0 bfr-prefix interface loopback0
end-bier ipv6-block blk1 opcode ::1 end-bier ipv6-block blk1 opcode ::1
encapsulation ipv6 bsl 256 max-si 0 encapsulation ipv6 bsl 256 max-si 0
The co-existance of BIERv6 and SRv6 is allowed. The following is an Deployment of BIERv6 in SRv6 network is allowed. In this case, the
example of configuring a sub-domain using BIERv6 when SRv6 is already BIERv6 domain is the same as SRv6 domain, and the End.BIER address is
deployed with a locator 'loc1' configured: allocated from the locator of SRv6. The following is an example of
configuring a sub-domain using BIERv6 when SRv6 is already deployed
with a locator 'loc1' configured:
# Config BIER Sub-domain using End.BIER allocated from loc1 # Config BIER Sub-domain using End.BIER allocated from loc1
bier sub-domain 6 ipv6-underlay bier sub-domain 6 ipv6-underlay
bfr-prefix interface loopback0 bfr-prefix interface loopback0
end-bier locator loc1 opcode ::1 end-bier locator loc1 opcode ::1
encapsulation ipv6 bsl 256 max-si 0 encapsulation ipv6 bsl 256 max-si 0
For the convenience of such co-existence of BIERv6 and SRv6, the For the convenience of such co-existence of BIERv6 and SRv6, the
indication of End.BIER or "BIER specific handling" in FIB shares the indication of End.BIER or "BIER specific handling" in FIB shares the
same space as SRv6 Endpoints Behaviors defined in same space as SRv6 Endpoints Behaviors defined in
[I-D.ietf-spring-srv6-network-programming]. Apart from this sharing [I-D.ietf-spring-srv6-network-programming].
of code space, there is nothing dependent on SRv6.
The following is an example pseudo-code of the End.BIER function: The following is an example pseudo-code of the End.BIER function:
1. IF NH = 60 and HopLimit > 0 ;;Ref1 1. IF NH = 60 and HopLimit > 0 ;;Ref1
2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2 2. IF (OptType1 = BIER) and (OptLength1 = HdrExtLen*8 + 4) ;;Ref2
3. Lookup the BIER Header inside the BIER option TLV. 3. Lookup the BIER Header inside the BIER option TLV.
4. Forward via the matched entry. 4. Forward via the matched entry.
5. ELSE ;;Ref3 5. ELSE ;;Ref3
6. Drop the packet and end the process. 6. Drop the packet and end the process.
7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4 7. ELSE IF NH=ICMPv6 or (NH=60 and Dest_NH=ICMPv6) ;;Ref4
skipping to change at page 8, line 16 skipping to change at page 8, line 43
Destination options header. Destination options header.
Ref3/Ref5: Undesired packet is droped because the destination address Ref3/Ref5: Undesired packet is droped because the destination address
is the BIER specific IPv6 address (End.BIER function). is the BIER specific IPv6 address (End.BIER function).
Ref4: An ICMPv6 packet using End.BIER as destination address. Ref4: An ICMPv6 packet using End.BIER as destination address.
3.3. BIERv6 Packet Format 3.3. BIERv6 Packet Format
As a multicast packet enters the BIER domain in a Non-MPLS IPv6 As a multicast packet enters the BIER domain in a Non-MPLS IPv6
network, the multicast packet will be encapsulated with BIERv6 network, the multicast packet will be encapsulated with BIERv6 Header
Header. by the Ingress BFR (BFIR).
Typically a BIERv6 header would contain the Destination Options Typically a BIERv6 header would contain the Destination Options
Header as the only Extensions Header besides IPv6 Header. However, Header as the only Extensions Header besides IPv6 Header, as depicted
it is allowed and possible for other extension headers to appear in the below figure.
along with the Destination Options Header as long as the requirements
listed in section 3.1 of this document is met.
Format of the multicast packet with BIERv6 encapsulation carrying
only the Destination Options header is depicted in the below figure.
+---------------+--------------+------------ +---------------+--------------+------------
| IPv6 header | Dest Options | X type of | IPv6 header | Dest Options | X type of
| | Header with | multicast | | Header with | multicast
| | BIER Option | packet | | BIER Option | packet
| | | | | |
| Next Hdr = 60 | Nxt Hdr = X | | Next Hdr = 60 | Nxt Hdr = X |
+---------------+--------------+------------ +---------------+--------------+------------
Format of the multicast packet with BIERv6 encapsulation carrying Format of the multicast packet with BIERv6 encapsulation carrying
skipping to change at page 9, line 8 skipping to change at page 9, line 32
o After the routing header, if that header is present o After the routing header, if that header is present
o Before the Fragment Header, if that header is present o Before the Fragment Header, if that header is present
o Before the AH Header or ESP Header, if either one of those headers o Before the AH Header or ESP Header, if either one of those headers
is present is present
Source Address field in the IPv6 header MUST be a routable IPv6 Source Address field in the IPv6 header MUST be a routable IPv6
unicast address of the BFIR in any case. unicast address of the BFIR in any case.
BFIR encodes the Non-MPLS BIER header in the above mentioned BFIR encodes the BIERv6 header in the above mentioned encapsulation
encapsulation format and forwards the BIERv6 packet to the nexthop format and forwards the BIERv6 packet to the nexthop BFR following
BFR following the local BIFT table. the local BIFT table.
BFRs in the IPv6 network, processes and replicates the packets BFRs in the IPv6 network, processes and replicates the packets
towards the BFERs using the local BIFT table. The bit-string field towards the BFERs using the local BIFT table. The BitString field in
in the Non-MPLS BIER header may be changed by the BFRs as they the BIERv6 Option Data may be changed by the BFRs as they replicate
replicate the packet. BFRs MUST follow the procedures defined in the packet. BFRs MUST follow the procedures defined in section 3.1
section 3.1 as they modify the other fields in the Non-MPLS BIER as they modify the other fields in the BIERv6 Option Data. The
header. The source address in the IPv6 header MUST NOT be modified source address in the IPv6 header MUST NOT be modified by the BFRs.
by the BFRs.
4. BIERv6 Packet Processing 4. BIERv6 Packet Processing
There is no BIER-specific processing, and all the 8 steps in section When a multicast packet enters the BIER domain, the Ingress BFR
6.5 of RFC8279 apply to BIERv6 packet processing. However, there are (BFIR) encapsulates the multicast packet with a BIERv6 Header,
some IPv6-specific processing procedures due to the base and general transforming it to a BIERv6 packet. The BIERv6 header includes an
procedures of IPv6. IPv6 header and a BIERv6 Option in IPv6 Destination Options Header.
On the overlay layer, when a multicast packet enters the BIER domain
in a Non-MPLS IPv6 network, the Ingress BFR (BFIR) encapsulates the
multicast packet with a BIERv6 Header, transforming it to a BIERv6
packet. The BIERv6 header includes an IPv6 header and IPv6
Destination Options Header within a standard Non-MPLS BIER header.
Source Address field in the IPv6 header MUST be set to a routable Source Address field in the IPv6 header MUST be set to a routable
IPv6 unicast address of the BFIR. Destination Address field in the IPv6 unicast address of the BFIR. Destination Address field in the
IPv6 header is set to the End.BIER address of the next-hop BFR the IPv6 header is set to the End.BIER address of the next-hop BFR the
BIERv6 packet replicating to, no matter next-hop BFR is directly BIERv6 packet replicating to, no matter next-hop BFR is directly
connected (one-hop) or not directly connected (multi-hop). connected (one-hop) or not directly connected (multi-hop).
On the BIER layer, upon receiving an BIERv6 packet, the BFR processes Upon receiving an BIERv6 packet, the BFR processes the IPv6 header
the IPv6 header first. This is the general procedure of IPv6. first. This is the general procedure of IPv6.
If the IPv6 Destination address is an End.BIER IPv6 unicast address If the IPv6 Destination address is an End.BIER IPv6 unicast address
of this BFR, a 'BIER Specific Handling' indication will be obtained of this BFR, a 'BIER Specific Handling' indication will be obtained
by the preceding Unicast DA lookup (FIB lookup). The BIER option, if by the preceding Unicast DA lookup (FIB lookup). The BIER option, if
exists, will be checked to decide which neighbor(s) to replicate the exists, will be checked to decide which neighbor(s) to replicate the
BIERv6 packet to. BIERv6 packet to.
It is a local behavior to handle the combination of extension It is a local behavior to handle the combination of extension
headers, options and the BIER option(s) in destination options header headers, options and the BIER option(s) in destination options header
when a 'BIER Specific Handling' indication is got by the preceding when a 'BIER Specific Handling' indication is got by the preceding
FIB lookup. Early deployment of BIERv6 may require there is only one FIB lookup. Early deployment of BIERv6 may require there is only one
BIER option TLV in the destination options header followed the IPv6 BIER option TLV in the destination options header followed the IPv6
header. How other extension headers or more BIER option TLVs in a header. How other extension headers or more BIER option TLVs in a
BIERv6 packet is handled is outside the scope of this document. BIERv6 packet is handled is outside the scope of this document.
A packet having a 'BIER Specific Handling' indication but not having A packet having a 'BIER Specific Handling' indication but not having
a BIER option is supposed to be a wrong packet or an ICMPv6 packet, a BIER option is supposed to be a wrong packet or an ICMPv6 packet,
and the process can be refered to the example in section 3.2. and the process can be referred to the example in section 3.2.
A packet not having a 'BIER Specific Handling' indication but having A packet not having a 'BIER Specific Handling' indication but having
a BIER option SHOULD be processed normally as unicast forwarding a BIER option SHOULD be processed normally as unicast forwarding
procedures, which may be a behavior of drop, or send to CPU, or other procedures, which may be a behavior of drop, or send to CPU, or other
behaviors in existing implementations. behaviors in existing implementations.
The Destination Address field in the IPv6 Header MUST change to the The Destination Address field in the IPv6 Header MUST change to the
nexthop BFR's End.BIER Unicast address in BIERv6. nexthop BFR's End.BIER Unicast address in BIERv6.
The Hop Limit field of IPv6 header MUST decrease by 1 when sending The Hop Limit field of IPv6 header MUST decrease by 1 when sending
skipping to change at page 10, line 31 skipping to change at page 10, line 48
unchanged on a Non-BIER router, or decrease by 1 on a BFR. unchanged on a Non-BIER router, or decrease by 1 on a BFR.
The BitString in the BIER header in the Destination Options Header The BitString in the BIER header in the Destination Options Header
may change when sending packets to a neighbor. Such change of may change when sending packets to a neighbor. Such change of
BitString MUST be aligned with the procedure defined in RFC8279. BitString MUST be aligned with the procedure defined in RFC8279.
Because of the requirement to change the content of the option when Because of the requirement to change the content of the option when
forwarding BIERv6 packet, the BIER option type should have chg flag 1 forwarding BIERv6 packet, the BIER option type should have chg flag 1
per section 4.2 of RFC8200. per section 4.2 of RFC8200.
The procedures applies normally if a bit corresponding to the self The procedures applies normally if a bit corresponding to the self
bfr-id is set in the bit-string field of the Non-MPLS BIER header of bfr-id is set in the BitString field of the BIERv6 Option Data of the
the BIERv6 packet. The node is considered to be an Egress BFR (BFER) BIERv6 packet. The node is considered to be an Egress BFR (BFER) in
in this case. The BFER removes the BIERv6 header, including the IPv6 this case. The BFER removes the BIERv6 header, including the IPv6
header and the Destination Options header, and copies the packet to header and the Destination Options header, and copies the packet to
the multicast flow overlay. The egress VRF of a packet may be the multicast flow overlay. The egress VRF of a packet may be
determined by a further lookup on the IPv6 source address instead of determined by a further lookup on the IPv6 source address instead of
the upstream-assigned MPLS Label as described in [RFC8556]. the upstream-assigned MPLS Label as described in [RFC8556].
The Fragment Header, AH Header or ESP Header, if exists after the The Fragment Header, AH Header or ESP Header, if exists after the
BIER options header, can be processed on BFER only as part of the BIER options header, can be processed on BFER only as part of the
multicast flow overlay process. multicast flow overlay process.
5. Security Considerations 5. Security Considerations
skipping to change at page 11, line 31 skipping to change at page 11, line 48
BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause BIER IPv6 encapsulation may cause ICMP packet sent to BFIR and cause
security problems. See section 5.2 for ICMP related problems. security problems. See section 5.2 for ICMP related problems.
This document introduces a new option used in IPv6 Destination This document introduces a new option used in IPv6 Destination
Options Header, together with the special-use IPv6 address called Options Header, together with the special-use IPv6 address called
End.BIER in IPv6 destination address for BIER IPv6 forwarding. End.BIER in IPv6 destination address for BIER IPv6 forwarding.
However the option newly introduced may be wrongly used with normal However the option newly introduced may be wrongly used with normal
IPv6 destination address. See section 5.3 for problems introduced by IPv6 destination address. See section 5.3 for problems introduced by
the new IPv6 option with normal IPv6 destination address. the new IPv6 option with normal IPv6 destination address.
If a BIER packet is altered, either the BIER header, or the multicast If the multicast data packet of a BIERv6 packet is altered by an
data packet, by an intermediate router, packets may be lost, stolen, intermediate router, contents of the multicast data packet will be
or otherwise misdelivered. BIER IPv6 encapsulation provides the damaged. BIER IPv6 encapsulation provides the ability of IPsec to
ability of IPsec to ensure the confidentiality or integrity. See ensure the confidentiality or integrity for multicast data packet.
section 5.4 for this security problem. See section 5.4 for this security problem.
If the BIERv6 encapsulation of a particular packet specifies a
BitString (together with SI) other than the one intended by the BFIR,
the packet is likely to be misdelivered. Some modifications of the
BIER encapsulation, e.g., setting every bit in the BitString, may
result in denial-of-service (DoS) attacks. This kind of DoS attack
is a challenge not only in BIERv6 but also in BIER as specified in
[RFC8279] and [RFC8296], as the BitString is required to change on
BFR per the BIER forwarding procedures. This document does not
provide new mechanisms to improve this kind of weakness.
A BIER router accepts and uses the End.BIER IPv6 address to construct A BIER router accepts and uses the End.BIER IPv6 address to construct
BIFT only when the IPv6 address is configured explicitly, or received BIFT only when the IPv6 address is configured explicitly, or received
from a router via control-plane protocols. The received information from a router via control-plane protocols. The received information
is validated using existing authentication and security mechanisms of is validated using existing authentication and security mechanisms of
the control-plane protocols. BIER IPv6 encapsulation does not define the control-plane protocols. BIER IPv6 encapsulation does not define
any additional security mechanism in existing control-plane any additional security mechanism in existing control-plane
protocols, and it inherits any security considerations that apply to protocols, and it inherits any security considerations that apply to
the control-plane protocols. the control-plane protocols.
skipping to change at page 12, line 47 skipping to change at page 13, line 27
For simplicity of deployment, a configuration of IACL effective for For simplicity of deployment, a configuration of IACL effective for
all interfaces can be provided by a router. Such IACL can be all interfaces can be provided by a router. Such IACL can be
referred to as global IACL(GIACL) .Each BIER node k then simply referred to as global IACL(GIACL) .Each BIER node k then simply
configs a GIACL which drops any incoming packet with a destination configs a GIACL which drops any incoming packet with a destination
address in Sk/sk if the source address is not in A/a or B/b for the address in Sk/sk if the source address is not in A/a or B/b for the
intra-domain deployment mode. intra-domain deployment mode.
5.2. ICMP Error Processing 5.2. ICMP Error Processing
ICMP error packets generated within the BIER Domain are sent to The BIERv6 BFR does not send ICMP error messages to the source
source nodes within the BIER Domain. address of a BIERv6 packet, there is still chance that Non-BFR
routers send ICMP error messages to source nodes within the BIER
Domain.
A large number of ICMP may be elicited and sent to a BFIR router, in A large number of ICMP may be elicited and sent to a BFIR router, in
case when a BIER IPv6 packet is filled with wrong TTL, either error case when a BIERv6 packet is filled with wrong Hop Limit, either
or malfeasance. A rate-limiting of ICMP packet should be implemented error or malfeasance. A rate-limiting of ICMP packet should be
on each BFR. implemented on each BFR.
The ingress node can take note of the fact that it is getting, in The ingress node can take note of the fact that it is getting, in
response to BIER IPv6 packet, one or more ICMP error packets. By response to BIER IPv6 packet, one or more ICMP error packets. By
default, the reception of such a packets MUST be countered and default, the reception of such a packets MUST be countered and
logged. However, it is possible for such log entries to be "false logged. However, it is possible for such log entries to be "false
positives" that generate a lot of "noise" in the log; therefore, positives" that generate a lot of "noise" in the log; therefore,
implementations SHOULD have a knob to disable this logging. implementations SHOULD have a knob to disable this logging.
OAM functions of PING and TRACE for BIER IPv6 encapsulation may also
need ICMP based on BIER IPv6 encapsulation and cause ICMP response
message containing BIER option. The ability of seperating such OAM
ICMP packets from error ICMP packets caused by error is necessary for
the availability of OAM, otherwise the OAM function may fail due to
the rate-limiting of ICMP error packets.
5.3. Security caused by BIER option 5.3. Security caused by BIER option
This document introduces a new option used in IPv6 Destination This document introduces a new option used in IPv6 Destination
Options Header. An IPv6 packet with a normal IPv6 address of a Options Header. An IPv6 packet with a normal IPv6 address of a
router (e.g. loopback IPv6 address of the router) as destination router (e.g. loopback IPv6 address of the router) as destination
address will possibly carry a BIER option. address will possibly carry a BIER option.
For a router incapable of BIERv6, such BIERv6 packet will not be For a router incapable of BIERv6, such BIERv6 packet will not be
processed by the procedure described in this document, but be processed by the procedure described in this document, but be
processed as normal IPv6 packet with unknown option, and the existing processed as normal IPv6 packet with unknown option, and the existing
skipping to change at page 14, line 37 skipping to change at page 15, line 9
For AH, the Integrity Check Value (ICV) is computed over the IP or For AH, the Integrity Check Value (ICV) is computed over the IP or
extension header fields before the AH header, the AH header, and the extension header fields before the AH header, the AH header, and the
Payload. The IPv6 DA is immutable for unicast traffic in AH, and the Payload. The IPv6 DA is immutable for unicast traffic in AH, and the
change of DA in BIER IPv6 forwarding for multicast traffic is change of DA in BIER IPv6 forwarding for multicast traffic is
incompatible to this rule. How AH is extended to support multicast incompatible to this rule. How AH is extended to support multicast
traffic transporting through BIER IPv6 encapsulation is outside the traffic transporting through BIER IPv6 encapsulation is outside the
scope of this document. scope of this document.
The detailed control-plane for BIER IPv6 encapsulation IPsec function The detailed control-plane for BIER IPv6 encapsulation IPsec function
is outside the scope of the document. Internet Key Exchange Protocol is outside the scope of the document. Internet Key Exchange Protocol
Version 2 (IKEv2) [RFC5996] and Group Security Association (GSA) Version 2 (IKEv2) [RFC7296] and Group Security Association (GSA)
[RFC5374] can be referred to for further studying. [RFC5374] can be referred to for further studying.
6. IANA Considerations 6. IANA Considerations
6.1. BIER Option Type 6.1. BIER Option Type
Allocation is expected from IANA for a BIER Option Type codepoint Allocation is expected from IANA for a BIER Option Type codepoint
from the "Destination Options and Hop-by-Hop Options" sub-registry of from the "Destination Options and Hop-by-Hop Options" sub-registry of
the "Internet Protocol Version 6 (IPv6) Parameters" registry. The the "Internet Protocol Version 6 (IPv6) Parameters" registry. The
value 0x70 is suggested. value 0x70 is suggested.
skipping to change at page 15, line 23 skipping to change at page 15, line 39
Allocation is expected from IANA for an End.BIER function codepoint Allocation is expected from IANA for an End.BIER function codepoint
from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is from the "SRv6 Endpoint Behaviors" sub-registry. The value 60 is
suggested. suggested.
+-------+--------+--------------------------+------------+ +-------+--------+--------------------------+------------+
| Value | Hex | Endpoint function | Reference | | Value | Hex | Endpoint function | Reference |
+-------+--------+--------------------------+------------+ +-------+--------+--------------------------+------------+
| TBD | TBD | End.BIER | This draft | | TBD | TBD | End.BIER | This draft |
+-------+--------+--------------------------+------------+ +-------+--------+--------------------------+------------+
6.3. BIER Next Protocol Identifiers
Allocation is expected from IANA for a BIER Proto codepoint from the
"BIER Next Protocol Identifiers" sub-registry.
TBD1: Delivering the packet with VRF lookup in IPv6 source address
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Stig Venaas for his valuable The authors would like to thank Stig Venaas for his valuable
comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda, comments. Thanks IJsbrand Wijnands, Greg Shepherd, Tony Przygienda,
Toerless Eckert, Jeffrey Zhang for the helpful comments to improve Toerless Eckert, Jeffrey Zhang for the helpful comments to improve
this document. this document.
Thanks Aijun Wang for comments about BIER OAM function in BIER IPv6 Thanks Aijun Wang for comments about BIER OAM function in BIER IPv6
encapsulation. encapsulation.
skipping to change at page 16, line 4 skipping to change at page 16, line 14
8. Contributors 8. Contributors
Gang Yan Gang Yan
Huawei Technologies Huawei Technologies
China China
Email: yangang@huawei.com Email: yangang@huawei.com
Yang(Yolanda) Xia Yang(Yolanda) Xia
Huawei Technologies Huawei Technologies
China China
Email: yolanda.xia@huawei.com Email: yolanda.xia@huawei.com
9. References 9. References
9.1. Normative References 9.1. Normative References
[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>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast [RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet Extensions to the Security Architecture for the Internet
Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008,
<https://www.rfc-editor.org/info/rfc5374>. <https://www.rfc-editor.org/info/rfc5374>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, DOI 10.17487/RFC5996, September 2010,
<https://www.rfc-editor.org/info/rfc5996>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
skipping to change at page 17, line 16 skipping to change at page 17, line 36
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>.
[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
and A. Dolganow, "Multicast VPN Using Bit Index Explicit and A. Dolganow, "Multicast VPN Using Bit Index Explicit
Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
2019, <https://www.rfc-editor.org/info/rfc8556>. 2019, <https://www.rfc-editor.org/info/rfc8556>.
[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>.
9.2. Informative References 9.2. Informative References
[I-D.geng-bier-ipv6-inter-domain] [I-D.geng-bier-ipv6-inter-domain]
Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain
Multicast Deployment using BIERv6", draft-geng-bier-ipv6- Multicast Deployment using BIERv6", draft-geng-bier-ipv6-
inter-domain-01 (work in progress), January 2020. inter-domain-01 (work in progress), January 2020.
[I-D.ietf-bier-ipv6-requirements] [I-D.ietf-bier-ipv6-requirements]
McBride, M., Xie, J., Dhanaraj, S., Asati, R., and Y. Zhu, McBride, M., Xie, J., Dhanaraj, S., Asati, R., and Y. Zhu,
"BIER IPv6 Requirements", draft-ietf-bier- "BIER IPv6 Requirements", draft-ietf-bier-
ipv6-requirements-04 (work in progress), January 2020. ipv6-requirements-04 (work in progress), January 2020.
[I-D.ietf-bier-ping] [I-D.ietf-bier-ping]
Kumar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., Nainar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M.,
and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier-
ping-06 (work in progress), October 2019. ping-07 (work in progress), May 2020.
[I-D.ietf-spring-srv6-network-programming] [I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming", Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-10 (work in draft-ietf-spring-srv6-network-programming-15 (work in
progress), February 2020. progress), March 2020.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [I-D.xie-bier-ipv6-mvpn]
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Xie, J., McBride, M., Dhanaraj, S., and L. Geng, "Use of
May 2017, <https://www.rfc-editor.org/info/rfc8174>. BIER IPv6 Encapsulation (BIERv6) for Multicast VPN in IPv6
networks", draft-xie-bier-ipv6-mvpn-02 (work in progress),
January 2020.
Authors' Addresses Authors' Addresses
Jingrong Xie Jingrong Xie
Huawei Technologies Huawei Technologies
Email: xiejingrong@huawei.com Email: xiejingrong@huawei.com
Liang Geng Liang Geng
China Mobile China Mobile
Beijing 10053 Beijing 10053
Email: gengliang@chinamobile.com Email: gengliang@chinamobile.com
skipping to change at line 823 skipping to change at page 19, line 4
Rajiv Asati Rajiv Asati
Cisco Cisco
Email: rajiva@cisco.com Email: rajiva@cisco.com
Senthil Dhanaraj Senthil Dhanaraj
Huawei Huawei
Email: senthil.dhanaraj@huawei.com Email: senthil.dhanaraj@huawei.com
Yongqing Zhu
China Telecom
Email: zhuyq8@chinatelecom.cn
Zhuangzhuang Qin
China Unicom
Email: qinzhuangzhuang@chinaunicom.cn
MooChang Shin
LG Uplus
Email: himzzang@lguplus.co.kr
Xuesong Geng
Huawei
Email: gengxuesong@huawei.com
 End of changes. 56 change blocks. 
152 lines changed or deleted 178 lines changed or added

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