< draft-ietf-bier-ipv6-requirements-03.txt		draft-ietf-bier-ipv6-requirements-04.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: May 5, 2020 S. Dhanaraj		Expires: July 18, 2020 S. Dhanaraj
	Huawei		Huawei
	R. Asati		R. Asati
	Cisco		Cisco
	November 2, 2019		Y. Zhu
			China Telecom
			January 15, 2020
	BIER IPv6 Requirements		BIER IPv6 Requirements
	draft-ietf-bier-ipv6-requirements-03		draft-ietf-bier-ipv6-requirements-04
	Abstract		Abstract
	The BIER WG includes, in its charter, work on developing mechanisms		The BIER WG includes, in its charter, work on developing mechanisms
	to transport BIER natively in IPv6. This document is intended to		to transport BIER natively in IPv6. This document is intended to
	help the WG with this effort by specifying requirements for		help the WG with this effort by specifying requirements for
	transporting packets, with Bit Index Explicit Replication (BIER)		transporting packets, with Bit Index Explicit Replication (BIER)
	headers, in an IPv6 environment. There will be a need to send IPv6		headers, in an IPv6 environment. There will be a need to send IPv6
	payloads, to multiple IPv6 destinations, using BIER. There have been		payloads, to multiple IPv6 destinations, using BIER. There have been
	several proposed solutions in this area. But there hasn't been a		several proposed solutions in this area. But there hasn't been a
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 47 ¶
	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 May 5, 2020.		This Internet-Draft will expire on July 18, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	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. BIER IPv6 Scenario's . . . . . . . . . . . . . . . . . . . . 4
	3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4		3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4
	3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4		3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4
	3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 5		3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 5
	3.4. Implications for BIER in SRv6 . . . . . . . . . . . . . . 5
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Hop by hop SA or DA modification . . . . . . . . . . . . 5		4.2. Hop by hop SA or DA modification . . . . . . . . . . . . 5
	4.3. L4 Inspection . . . . . . . . . . . . . . . . . . . . . . 6		4.3. L4 Inspection . . . . . . . . . . . . . . . . . . . . . . 6
	4.4. Multicast address in SA field . . . . . . . . . . . . . . 7		4.4. Multicast address in SA field . . . . . . . . . . . . . . 6
	4.5. Incorrect bits . . . . . . . . . . . . . . . . . . . . . 7		4.5. Incorrect bits . . . . . . . . . . . . . . . . . . . . . 6
	4.6. SA filtering . . . . . . . . . . . . . . . . . . . . . . 7		4.6. SA filtering . . . . . . . . . . . . . . . . . . . . . . 7
	4.7. BIER architecture support . . . . . . . . . . . . . . . . 7		4.7. BIER architecture support . . . . . . . . . . . . . . . . 7
	4.8. Simple Encapsulation . . . . . . . . . . . . . . . . . . 8		4.8. Simple Encapsulation . . . . . . . . . . . . . . . . . . 7
	4.9. Hardware fast path . . . . . . . . . . . . . . . . . . . 8		4.9. Hardware fast path . . . . . . . . . . . . . . . . . . . 7
	4.10. Conform to existing IPv6 Spec . . . . . . . . . . . . . . 8		4.10. Conform to existing IPv6 Spec . . . . . . . . . . . . . . 7
	4.11. Support Fragmentation . . . . . . . . . . . . . . . . . . 8		4.11. Support Fragmentation . . . . . . . . . . . . . . . . . . 8
	4.12. Support IPv6 Security . . . . . . . . . . . . . . . . . . 8		4.12. Support IPv6 Security . . . . . . . . . . . . . . . . . . 8
	5. Solutions Evaluation . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	5.2. Encode Bitstring in IPv6 destination address . . . . . . 10		7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
	5.3. Add BIER header into IPv6 Extension Header . . . . . . . 10		8. Normative References . . . . . . . . . . . . . . . . . . . . 8
	5.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 11		Appendix A. Solutions Evaluation . . . . . . . . . . . . . . . . 9
	5.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 12		A.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		A.2. Encode Bitstring in IPv6 destination address . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		A.3. Add BIER header into IPv6 Extension Header . . . . . . . 11
	8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13		A.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 13
	9. Normative References . . . . . . . . . . . . . . . . . . . . 13		A.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	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
	skipping to change at page 5, line 18 ¶		skipping to change at page 5, line 18 ¶
	to grow and considering that multiple types of traffic with different		to grow and considering that multiple types of traffic with different
	characteristics and requirements are quickly converging over single		characteristics and requirements are quickly converging over single
	network architecture, the network operators are starting to face new		network architecture, the network operators are starting to face new
	challenges.		challenges.
	Some operators are currently building, or plan to build in the near		Some operators are currently building, or plan to build in the near
	future, an IPv6 only native infrastructure for their core network.		future, an IPv6 only native infrastructure for their core network.
	Having a native BIERv6 infrastructure will help maintain simplicity		Having a native BIERv6 infrastructure will help maintain simplicity
	of the network and reduce state versus traditional IP Multicast.		of the network and reduce state versus traditional IP Multicast.
	3.4. Implications for BIER in SRv6
	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.
	4. Requirements		4. Requirements
	There have been several suggested requirements, on the BIER email		There have been several suggested requirements, on the BIER email
	list and in meetings, which have been used to form BIER IPv6		list and in meetings, which have been used to form BIER IPv6
	requirements used to help the wg evaluate against the proposed		requirements used to help the wg evaluate against the proposed
	solutions:		solutions:
	4.1. L2 Agnostic		4.1. L2 Agnostic
	The solution should be agnostic to the underlying L2 data link type.		The solution should be agnostic to the underlying L2 data link type.
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 39 ¶
	4.2. Hop by hop SA or DA modification		4.2. Hop by hop SA or DA modification
	The solution should not require hop-by-hop modification of the IP		The solution should not require hop-by-hop modification of the IP
	source address field.		source address field.
	Solutions that do not require Hop-by-hop SA modification are		Solutions that do not require Hop-by-hop SA modification are
	preferred. Solutions which maintain the SA will help fast-path		preferred. Solutions which maintain the SA will help fast-path
	forwarding (req 4.9 in this doc), are beneficial for receiving		forwarding (req 4.9 in this doc), are beneficial for receiving
	notices from the BFIR for functions like BIER PING, TRACE and MTU		notices from the BFIR for functions like BIER PING, TRACE and MTU
	notification, are beneficial for identifying an MVPN instance to help		notification, are beneficial for identifying an MVPN instance to help
	remove more encapsulation such as Service Label (such as MPLS VPN		remove more encapsulation such as Service Label, are beneficial for
	Label or VNI in the SRv6 network), are beneficial for SA filtering		SA filtering (req 4.6 in this doc), and are beneficial for data
	(req 4.6 in this doc), and are beneficial for data origin		origin authentication if IPSEC is desired (req 4.12 in this doc).
	authentication if IPSEC is desired (req 4.12 in this doc).
	The solution should use a IPv6 unicast address in the DA to satisfy		The solution should use a IPv6 unicast address in the DA to satisfy
	the BIER architecture without introducing additional tunnel		the BIER architecture without introducing additional tunnel
	encapsulation, and thus may require DA modification by each BFR hop.		encapsulation, and thus may require DA modification by each BFR hop.
	It is commonly thought that BIERv6 could use a multicast address, as		It is commonly thought that BIERv6 could use a multicast address, as
	BIER is one-hop replication on each BFR in normal cases. However, as		BIER is one-hop replication on each BFR in normal cases. However, as
	described in section 6.9 of [RFC8279], it is useful to support non-		described in section 6.9 of [RFC8279], it is useful to support non-
	BIER routers within a BIER domain. From the wg discussion about this		BIER routers within a BIER domain. From the wg discussion about this
	document, focus is on the advantages of using unicast addresses that		document, focus is on the advantages of using unicast addresses that
	skipping to change at page 6, line 51 ¶		skipping to change at page 6, line 40 ¶
	forward this packet because BFR B doesn't have the BIER header in the		forward this packet because BFR B doesn't have the BIER header in the
	second fragmentation packet. Section 4.11 describes the		second fragmentation packet. Section 4.11 describes the
	fragmentation requirements.		fragmentation requirements.
	The second example is in IPSEC case, where the BIER header is part of		The second example is in IPSEC case, where the BIER header is part of
	the payload for confidentiality or integrity. The need to change the		the payload for confidentiality or integrity. The need to change the
	BitString in the BIER Header, when forwarding BIER packets, makes it		BitString in the BIER Header, when forwarding BIER packets, makes it
	incompatible with IPSEC. Section 4.12 describes the IPSEC		incompatible with IPSEC. Section 4.12 describes the IPSEC
	requirements.		requirements.
	The third example is in the case of working in SRv6 networks, as
	described in section 3.4 of this document, BIERv6 may be used with
	SRH. As BIER header is part of the payload, it will be reached only
	after the SRH is processed. That is to say, when BFR B receives a
	packet with SRH from BFR A, BFR B has to process the SRH first, and
	then the Upper-layer BIER header last. The SRH can work well based
	on the indication of the preceding IPv6 DA lookup in FIB, but for
	BIER forwarding, the BIER header part of the payload has to be deeply
	inspected on each BFR.
	4.4. Multicast address in SA field		4.4. Multicast address in SA field
	The solution should not allow a multicast address to be put in the IP		The solution should not allow a multicast address to be put in the IP
	source address field. According to [RFC1112] "A host group address		source address field. According to [RFC1112] "A host group address
	must never be placed in the source address field or anywhere in a		must never be placed in the source address field or anywhere in a
	source route or record route option of an outgoing IP datagram."		source route or record route option of an outgoing IP datagram."
	4.5. Incorrect bits		4.5. Incorrect bits
	The solution should not assume that bits never get set incorrectly.		The solution should not assume that bits never get set incorrectly.
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 16 ¶
	The proposed encapsulation must support fragmentation. It shouldn't		The proposed encapsulation must support fragmentation. It shouldn't
	require fragmentation and re-assembly at each hop.		require fragmentation and re-assembly at each hop.
	4.12. Support IPv6 Security		4.12. Support IPv6 Security
	The proposed encapsulation should support IPv6 security including AH/		The proposed encapsulation should support IPv6 security including AH/
	ESP extension headers. It shouldn't require hop-by-hop encryption/		ESP extension headers. It shouldn't require hop-by-hop encryption/
	decryption.		decryption.
	5. Solutions Evaluation		5. IANA Considerations
			Some BIERv6 encapsulation proposals do not require any action from
			IANA while other proposals require new BIER Destination Option
			codepoints from IPv6 sub-registries, new "Next header" values, or
			require new IP Protocol codes. This document, however, does not
			require anything from IANA.
			6. Security Considerations
			There are no security issues introduced by this draft.
			7. Acknowledgement
			Thank you to Eric Rosen for his listed set of requirements on the
			bier wg list.
			8. Normative References
			[I-D.pfister-bier-over-ipv6]
			Pfister, P. and I. Wijnands, "An IPv6 based BIER
			Encapsulation and Encoding", draft-pfister-bier-over-
			ipv6-01 (work in progress), October 2016.
			[I-D.xie-bier-ipv6-encapsulation]
			Xie, J., Geng, L., McBride, M., Asati, R., and S.
			Dhanaraj, "Encapsulation for BIER in Non-MPLS IPv6
			Networks", draft-xie-bier-ipv6-encapsulation-04 (work in
			progress), December 2019.
			[I-D.xu-bier-encapsulation]
			Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet,
			C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit
			Index Explicit Replication (BIER) Encapsulation Header",
			draft-xu-bier-encapsulation-06 (work in progress),
			September 2016.
			[I-D.zhang-bier-bierin6]
			Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and
			M. McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier-
			bierin6-04 (work in progress), January 2020.
			[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
			RFC 1112, DOI 10.17487/RFC1112, August 1989,
			<https://www.rfc-editor.org/info/rfc1112>.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<https://www.rfc-editor.org/info/rfc2119>.
			[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
			IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
			December 1998, <https://www.rfc-editor.org/info/rfc2473>.
			[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", STD 86, RFC 8200,
			DOI 10.17487/RFC8200, July 2017,
			<https://www.rfc-editor.org/info/rfc8200>.
			[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
			Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
			Explicit Replication (BIER)", RFC 8279,
			DOI 10.17487/RFC8279, November 2017,
			<https://www.rfc-editor.org/info/rfc8279>.
			[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
			Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
			for Bit Index Explicit Replication (BIER) in MPLS and Non-
			MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
			2018, <https://www.rfc-editor.org/info/rfc8296>.
			[RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R.,
			Ed., and M. Townsley, "Use Cases for IPv6 Source Packet
			Routing in Networking (SPRING)", RFC 8354,
			DOI 10.17487/RFC8354, March 2018,
			<https://www.rfc-editor.org/info/rfc8354>.
			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,
	may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload,		may appear in the IPv6 Header, IPv6 Extension Header, IPv6 Payload,
	or IPv6 Tunnel Packet:		or IPv6 Tunnel Packet:
	5.1. BIER-ETH encapsulation in IPv6 networks		A.1. BIER-ETH encapsulation in IPv6 networks
	+---------------+-----------------+-------------------		+---------------+-----------------+-------------------
	| 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
	skipping to change at page 10, line 8 ¶		skipping to change at page 11, line 14 ¶
	* The absence of an IPv6 header, and the optional IPv6 extension		* The absence of an IPv6 header, and the optional IPv6 extension
	headers, deprives BIER of some of the useful cases (ex: Use of		headers, deprives BIER of some of the useful cases (ex: Use of
	IPv6 address for identification of network function or service		IPv6 address for identification of network function or service
	mapping) that is otherwise possible in native IPv6		mapping) that is otherwise possible in native IPv6
	encapsulation which utilizes a IPv6 header.		encapsulation which utilizes a IPv6 header.
	* Tunneling of BIER packets is one common technique used for FRR,		* Tunneling of BIER packets is one common technique used for FRR,
	to tunnel over BIER incapable nodes etc. While it is possible		to tunnel over BIER incapable nodes etc. While it is possible
	for the BIER-ETH encapsulated packet to be further encapsulated		for the BIER-ETH encapsulated packet to be further encapsulated
	within a GRE6 or SRv6, etc tunnel, it might not be possible to		within a GRE6, etc tunnel, it might not be possible to parse
	parse and decapsulate different types of tunnel headers and		and decapsulate different types of tunnel headers and forward
	forward the BIER packet completely in hardware fast path		the BIER packet completely in hardware fast path similar to the
	similar to the label stack processing in BIER-MPLS networks.		label stack processing in BIER-MPLS networks. It would be
	It would be useful to select an encapsulation which could help		useful to select an encapsulation which could help in
	in processing the tunnel and BIER header and make the		processing the tunnel and BIER header and make the forwarding
	forwarding decision completely in hardware fast path, which is		decision completely in hardware fast path, which is lacking in
	lacking in BIER-ETH encapsulation if chosen to be deployed in		BIER-ETH encapsulation if chosen to be deployed in pure IPv6
	pure IPv6 networks.		networks.
	5.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 |
	+---------------+-------------------		+---------------+-------------------
	As described in [I-D.pfister-bier-over-ipv6], The information		As described in [I-D.pfister-bier-over-ipv6], The information
	required by BIER is stored in the destination IPv6 address. The BIER		required by BIER is stored in the destination IPv6 address. The BIER
	skipping to change at page 10, line 40 ¶		skipping to change at page 11, line 46 ¶
	address of each packet. The high-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,		address are used by intermediate routers for unicast forwarding,
	deciding whether a packet is a BIER packet, and if so, to identify		deciding whether a packet is a BIER packet, and if so, to identify
	the BIER Sub-Domain, Set Identifier and BitString length. No		the BIER Sub-Domain, Set Identifier and BitString length. No
	additional extension or encapsulation header is required. Instead of		additional extension or encapsulation header is required. Instead of
	encapsulating the packet in IPv6, the payload is attached to the BIER		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		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		payload. If the payload is UDP, the UDP checksum needs to change
	when the BitString in the IPv6 destination address changes.		when the BitString in the IPv6 destination address changes.
	5.3. Add BIER header into IPv6 Extension Header		A.3. Add BIER header into IPv6 Extension Header
	+---------------+-----------------+-------------------		+---------------+-----------------+-------------------
	| IPv6 header | IPv6 Ext header | payload		| IPv6 header | IPv6 Ext header | payload
	| | (BIER header in |		| | (BIER header in |
	| | TLV Type = X) |		| | TLV Type = X) |
	| Next Header | Next Header |		| Next Header | Next Header |
	+---------------+-----------------+-------------------		+---------------+-----------------+-------------------
	According to [RFC8200] In IPv6, optional internet-layer information		According to [RFC8200] In IPv6, optional internet-layer information
	is encoded in separate headers that may be placed between the IPv6		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		header and the upper- layer header in a packet. There is a small
	skipping to change at page 11, line 46 ¶		skipping to change at page 13, line 9 ¶
	IPv6 header.		IPv6 header.
	Defining New Extension Headers and Options may also be considered, if		Defining New Extension Headers and Options may also be considered, if
	the IPv6 Destination Option Header is not good enough and new		the IPv6 Destination Option Header is not good enough and new
	extension headers can solve the problem better.		extension headers can solve the problem better.
	Such proposals may include requests to IANA to allocate a "BIER		Such proposals may include requests to IANA to allocate a "BIER
	Option" code from "Destination Options and Hop-by-Hop Options", and/		Option" code from "Destination Options and Hop-by-Hop Options", and/
	or a "BIER Option Header" code from "IPv6 Extension Header Types".		or a "BIER Option Header" code from "IPv6 Extension Header Types".
	5.4. Transport BIER as IPv6 payload		A.4. Transport BIER as IPv6 payload
	+---------------+-----------------+-------------------		+---------------+-----------------+-------------------
	| IPv6 header | IPv6 Ext header | BIER Hdr + payload		| IPv6 header | IPv6 Ext header | BIER Hdr + payload
	| | (optional) | as IPv6 payload		| | (optional) | as IPv6 payload
	| | |		| | |
	| Next Header | Next Header = X |		| Next Header | Next Header = X |
	+---------------+-----------------+-------------------		+---------------+-----------------+-------------------
	There is a proposal for a transport-independent BIER encapsulation		There is a proposal for a transport-independent BIER encapsulation
	header which is applicable regardless of the underlying transport		header which is applicable regardless of the underlying transport
	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".
	5.5. Tunneling BIER in a IPv6 tunnel		A.5. Tunneling 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 13, line 7 ¶		skipping to change at page 14, line 18 ¶
	| | | | 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 tunneling 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.
	6. IANA Considerations
	Some BIERv6 encapsulation proposals do not require any action from
	IANA while other proposals require new BIER Destination Option
	codepoints from IPv6 sub-registries, new "Next header" values, or
	require new IP Protocol codes. This document, however, does not
	require anything from IANA.
	7. Security Considerations
	There are no security issues introduced by this draft.
	8. Acknowledgement
	Thank you to Eric Rosen for his listed set of requirements on the
	bier wg list.
	9. Normative References
	[I-D.pfister-bier-over-ipv6]
	Pfister, P. and I. Wijnands, "An IPv6 based BIER
	Encapsulation and Encoding", draft-pfister-bier-over-
	ipv6-01 (work in progress), October 2016.
	[I-D.xie-bier-ipv6-encapsulation]
	Xie, J., Geng, L., McBride, M., Asati, R., and S.
	Dhanaraj, "Encapsulation for BIER in Non-MPLS IPv6
	Networks", draft-xie-bier-ipv6-encapsulation-03 (work in
	progress), July 2019.
	[I-D.xu-bier-encapsulation]
	Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet,
	C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit
	Index Explicit Replication (BIER) Encapsulation Header",
	draft-xu-bier-encapsulation-06 (work in progress),
	September 2016.
	[I-D.zhang-bier-bierin6]
	Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and
	M. McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier-
	bierin6-03 (work in progress), July 2019.
	[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
	RFC 1112, DOI 10.17487/RFC1112, August 1989,
	<https://www.rfc-editor.org/info/rfc1112>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
	December 1998, <https://www.rfc-editor.org/info/rfc2473>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.
	[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
	Explicit Replication (BIER)", RFC 8279,
	DOI 10.17487/RFC8279, November 2017,
	<https://www.rfc-editor.org/info/rfc8279>.
	[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
	for Bit Index Explicit Replication (BIER) in MPLS and Non-
	MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
	2018, <https://www.rfc-editor.org/info/rfc8296>.
	[RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R.,
	Ed., and M. Townsley, "Use Cases for IPv6 Source Packet
	Routing in Networking (SPRING)", RFC 8354,
	DOI 10.17487/RFC8354, March 2018,
	<https://www.rfc-editor.org/info/rfc8354>.
	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
	skipping to change at page 15, line 4 ¶		skipping to change at page 14, line 29 ¶
	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
	Senthil Dhanaraj		Senthil Dhanaraj
	Huawei		Huawei
	Email: senthil.dhanaraj@huawei.com		Email: senthil.dhanaraj@huawei.com
	Rajiv Asati		Rajiv Asati
	Cisco		Cisco
	Email: rajiva@cisco.com		Email: rajiva@cisco.com
			Yongqing Zhu
			China Telecom
			Email: zhuyq8@chinatelecom.cn
End of changes. 22 change blocks.
	138 lines changed or deleted		121 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/