< draft-ietf-bier-ipv6-requirements-04.txt		draft-ietf-bier-ipv6-requirements-05.txt >
	Network Working Group M. McBride		Network Working Group M. McBride
	Internet-Draft Futurewei		Internet-Draft Futurewei
	Intended status: Standards Track J. Xie		Intended status: Standards Track J. Xie
	Expires: July 18, 2020 S. Dhanaraj		Expires: January 11, 2021 S. Dhanaraj
	Huawei		Huawei
	R. Asati		R. Asati
	Cisco		Cisco
	Y. Zhu		Y. Zhu
	China Telecom		China Telecom
	January 15, 2020		G. Mishra
			Verizon Inc.
			July 10, 2020
	BIER IPv6 Requirements		BIER IPv6 Requirements
	draft-ietf-bier-ipv6-requirements-04		draft-ietf-bier-ipv6-requirements-05
	Abstract		Abstract
	The BIER WG includes, in its charter, work on developing mechanisms		The BIER WG charter includes work on developing "a mechanism to use
	to transport BIER natively in IPv6. This document is intended to		BIER natively in IPv6". There have been several proposed solutions
	help the WG with this effort by specifying requirements for		in this area. But there hasn't been a document which describes the
	transporting packets, with Bit Index Explicit Replication (BIER)		problem and lists the requirements. The goal of this document is to
	headers, in an IPv6 environment. There will be a need to send IPv6		describe the BIER IPv6 requirements, summarize the encapsulation
	payloads, to multiple IPv6 destinations, using BIER. There have been		modes of the proposed solutions, guide the working group in
	several proposed solutions in this area. But there hasn't been a		understanding the benefits and drawbacks of the various solutions,
	document which describes the problem and lists the requirements. The		and help in the development of acceptable solutions.
	goal of this document is to describe the BIER IPv6 requirements,
	summarize the proposed solutions, and guide the working group in
	understanding the benefits, and drawbacks, of the various solutions
	and to help in the development of acceptable solutions.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 18, 2020.		This Internet-Draft will expire on January 11, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3		2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
	3. BIER IPv6 Scenario's . . . . . . . . . . . . . . . . . . . . 4		3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding 4
	3.1. BIERv6 for Access Network . . . . . . . . . . . . . . . . 4		3.1. Transport-Independent Model . . . . . . . . . . . . . . . 5
	3.2. BIERv6 for Data Center . . . . . . . . . . . . . . . . . 4		3.2. Native IPv6 Model . . . . . . . . . . . . . . . . . . . . 6
	3.3. BIERv6 for Core Networks . . . . . . . . . . . . . . . . 5		3.3. Encapsulation Approaches Considered . . . . . . . . . . . 7
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. Mandatory Requirements . . . . . . . . . . . . . . . . . 8
	4.2. Hop by hop SA or DA modification . . . . . . . . . . . . 5		4.1.1. L2 Agnostic . . . . . . . . . . . . . . . . . . . . . 8
	4.3. L4 Inspection . . . . . . . . . . . . . . . . . . . . . . 6		4.1.2. Support BIER architecture . . . . . . . . . . . . . . 8
	4.4. Multicast address in SA field . . . . . . . . . . . . . . 6		4.1.3. Conform to existing IPv6 Spec . . . . . . . . . . . . 8
	4.5. Incorrect bits . . . . . . . . . . . . . . . . . . . . . 6		4.1.4. Support deployment with Non-BFR routers . . . . . . . 8
	4.6. SA filtering . . . . . . . . . . . . . . . . . . . . . . 7		4.1.5. Support inter-AS multicast deployment . . . . . . . . 8
	4.7. BIER architecture support . . . . . . . . . . . . . . . . 7		4.1.6. Support Simple Encapsulation . . . . . . . . . . . . 9
	4.8. Simple Encapsulation . . . . . . . . . . . . . . . . . . 7		4.1.7. Support Deployment Security . . . . . . . . . . . . . 9
	4.9. Hardware fast path . . . . . . . . . . . . . . . . . . . 7		4.2. Optional Requirements . . . . . . . . . . . . . . . . . . 9
	4.10. Conform to existing IPv6 Spec . . . . . . . . . . . . . . 7		4.2.1. Support MVPN . . . . . . . . . . . . . . . . . . . . 9
	4.11. Support Fragmentation . . . . . . . . . . . . . . . . . . 8		4.2.2. Support OAM . . . . . . . . . . . . . . . . . . . . . 9
	4.12. Support IPv6 Security . . . . . . . . . . . . . . . . . . 8		4.2.3. Support IPSEC . . . . . . . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4.2.4. Support Fragmentation . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4.2.5. Support hardware fast path . . . . . . . . . . . . . 10
	7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Normative References . . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Solutions Evaluation . . . . . . . . . . . . . . . . 9		7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
	A.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 10		8. Normative References . . . . . . . . . . . . . . . . . . . . 10
	A.2. Encode Bitstring in IPv6 destination address . . . . . . 11		Appendix A. Solutions Evaluation . . . . . . . . . . . . . . . . 12
	A.3. Add BIER header into IPv6 Extension Header . . . . . . . 11		A.1. BIER-ETH encapsulation in IPv6 networks . . . . . . . . . 12
	A.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 13		A.2. Encode Bitstring in IPv6 destination address . . . . . . 13
	A.5. Tunneling BIER in a IPv6 tunnel . . . . . . . . . . . . . 13		A.3. Add BIER header into IPv6 Extension Header . . . . . . . 13
			A.4. Transport BIER as IPv6 payload . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		A.5. Tunnelling BIER in a IPv6 tunnel . . . . . . . . . . . . 15
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	Bit Index Explicit Replication (BIER) [RFC8279] is an architecture		Bit Index Explicit Replication (BIER) [RFC8279] is an architecture
	that provides optimal multicast forwarding, without requiring		that provides optimal multicast forwarding, without requiring
	intermediate routers to maintain per-flow state, through the use of a		intermediate routers to maintain per-flow state, through the use of a
	multicast-specific BIER header. [RFC8296] defines two types of BIER		multicast-specific BIER header. [RFC8296] defines two types of BIER
	encapsulation to run on physical links: one is BIER MPLS		encapsulation to run on physical links: one is BIER MPLS
	encapsulation to run on various physical links that support MPLS, the		encapsulation to run on various physical links that support MPLS, the
	other is non-MPLS BIER Ethernet encapsulation to run on ethernet		other is non-MPLS BIER Ethernet encapsulation to run on ethernet
	links, with an ethertype 0xAB37. This document describes using BIER		links, with an ethertype 0xAB37. This document describes using BIER
	in non-MPLS IPv6 environments. We explain the requirements of		in non-MPLS IPv6 environments. We explain the requirements of
	transporting IPv4/IPv6 multicast payloads, from an IPv6 router (BFIR)		transporting IPv4/IPv6 multicast payloads through an IPv6 network
	to multicast IPv6 destinations (BFERs), using BIER. This can include		using "BIER natively in IPv6". As clarified in the working-group,
	native IPv6 encapsulation and generic tunneling. Native IPv6, in		"BIER natively in IPv6" means BIER not encapsulated in MPLS or
	this document, is defined as BIER not encapsulated in mpls or		Ethernet. This may include native IPv6 encapsulation and generic
	ethernet. The goal of this document is to help the BIER WG evaluate		IPv6 tunnelling. The goal of this document is to help the BIER WG
	the BIER v6 requirements and solutions in order to begin adopting		evaluate the BIER v6 requirements and solutions in order to begin
	solution drafts.		adopting solution drafts.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	1.2. Terminology		1.2. Terminology
	o BIER: Bit Index Explicit Replication. Provides optimal multicast		o BIER: Bit Index Explicit Replication. Provides optimal multicast
	forwarding through adding a BIER header and removing state in		forwarding through adding a BIER header and removing state in
	intermediate routers.		intermediate routers.
	o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe		o BUM: Broadcast, Unknown Unicast, Multicast. Term used to describe
	the three types of Ethernet modes that will be forwarded to		the three types of Ethernet modes that will be forwarded to
	multiple destinations		multiple destinations
	2. Problem Statement		2. Problem Statement
	The problem is the ability of the network to transport BUM packets,		The problem is the ability of the network to transport BUM packets,
	with BIER headers, in an IPv6 environment. In IPv6 networks, many		with BIER headers, in an IPv6 environment. In many IPv6 network
	deployments use non-MPLS encapsulation for unicast as the data-plane.		deployments, non-MPLS encapsulation is used for unicast as the data-
	In such case, it may be expected to have a BIER IPv6 encapsulation		plane and it is likewise expected to have BIER IPv6 deployments which
	which is compliant with various kinds of physical links, perhaps in a		depend on these same unicast technologies.
	hop-by-hop manner, and maintain the benefit of "fast reroute" of an
	IPv6 tunnel. Evaluating the BIER IPv6 requirements will help
	determine the best solutions to address these problems.
	3. BIER IPv6 Scenario's		One such case involves supporting a non-BFR router in a network as
			described in section 6.9 of RFC8279. In the context of this
			document, an IPv6 based unicast tunnel is needed to support such
			deployment where a non-BFR exists. Another case is to support inter-
			AS multicast deployment as illustrated in
			[I-D.geng-bier-ipv6-inter-domain]. In such deployment, there are
			non-BFR routers, or even an entire non-BIER network, that needs the
			ability to traverse from one BFR to another.
			[I-D.ietf-bier-use-cases] shows it is possible there are other cases
			where inter-AS multicast deployment is required.
			As with IPv6, another problem of BIER IPv6 technology may be
			"Transition Mechanisms and Partial Deployments" which is listed as
			the No.1 charter item of BIER WG. Therefore, a basic requirement of
			BIER IPv6 is to leverage IPv6 reachability for incremental and inter-
			AS BIER deployment.
			Below is a simple scenario that needs BIER IPv6 encapsulation and
			forwarding:
	+--------------------------------------------+		+--------------------------------------------+
	| |		| |
	| +------+		| +------+
	| | BFER |		| | BFER |
	+------+ IPv6 +------+		+------+ +-------+ +-----+ +------+
	| BFIR | |		| BFIR | |Non-BFR| | BFR | |
	+------+ Network +------+		+------+ +-------+ +-----+ +------+
	| | BFER |		| | BFER |
	| +------+		| IPv6 Network +------+
	| |		| (intra-AS or inter-AS) |
	+--------------------------------------------+		+--------------------------------------------+
	This basic scenario depicts the need to replicate bier packets from a		This scenario depicts the need to replicate bier packets from a BFIR
	BFIR to BFERs across an IPv6 core. The IPv6 environment may include		to BFERs across an IPv6 core. The IPv6 environment may include a
	a variety of link types, may be entirely IPv6, may be dual stack or		variety of link types, may be entirely IPv6, may be dual stack or any
	any type of combination which includes IPv6. Regardless of the		type of combination which includes IPv6. Regardless of the
	environment, there are times when a BIER header, including the BIER		environment, there are times when a BIER header, including the BIER
	bitstring used to determine the set of BIER forwarding egress		BitString used to determine the set of BIER forwarding egress
	routers, will need to traverse a IPv6 domain. The ways in which BIER		routers, will need to traverse a IPv6 domain. The ways in which BIER
	will function in an IPv6 environment is the problem that needs to be		will function in an IPv6 environment is the problem that needs to be
	solved. [RFC8354] lists some good IPv6 related use cases which we		solved.
	will similarly reference in this document.
	3.1. BIERv6 for Access Network		3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding
	Access networks deliver a variety of types of multicast video traffic		This analysis introduces two conceptual models for BIER IPv6
	from the service provider's network to the home (or Enterprise)		encapsulation and forwarding based on the experience and examples
	environment and from the home towards the service provider's network.		that have been seen in the IETF community.
	There will be a need to send traffic from the IPv4 access towards the		3.1. Transport-Independent Model
	service provider's IPv6 network and vice versa. A packet could be
	mapped into a providers IPv6 network through the use of a BIERv6
	header. The access devices would not need to know specific details
	about the packet to perform this mapping; instead the access device
	would only need to know how to process a BIER header unless there is
	end to end IPv6.
	3.2. BIERv6 for Data Center		The first conceptual model is a Transport-Independent Model that
			views IP tunnels as links of BIER, and views BIER as an independent
			"Layer-2.5".
	Some Data Center operators are transitioning their Data Center		|<----------(L2.5 BIER(P2MP) Tunnel)-------->|
	infrastructure from IPv4 to native IPv6 only, in order to cope with		| |
	IPv4 address depletion and to achieve larger scale. In such		| +~~~~~~~~~~~~~~~~~~+ +~~~~+ |
	environment, BIERv6, can be used to natively steer multicast data		| / \ / \ |
	across an IPv6 data center.		+------+ +-------+ +-----+ +------+
			| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
			+------+ +-------+ +-----+ +------+
	3.3. BIERv6 for Core Networks		------- physical link
	While the overall amount of traffic offered to the network continues		~~~~~~~ IPv6(P2P) tunnel
	to grow and considering that multiple types of traffic with different
	characteristics and requirements are quickly converging over single
	network architecture, the network operators are starting to face new
	challenges.
	Some operators are currently building, or plan to build in the near		<-----> BIER(P2MP) tunnel
	future, an IPv6 only native infrastructure for their core network.
	Having a native BIERv6 infrastructure will help maintain simplicity
	of the network and reduce state versus traditional IP Multicast.
	4. Requirements		In this model, an IPv6 tunnel works as a link-layer of BIER, and BIER
			works as a transport-independent layer (or layer-2.5) over a virtual-
			link (IPv6 tunnel). On each BFR, the IPv6 tunnel of the receiving
			packet is decapsulated, and a new IPv6 tunnel is encapsulated before
			sending the packet to the next-hop BFR neighbour.
	There have been several suggested requirements, on the BIER email		From the view of the IPv6 layer, the BIER header is a kind of Upper-
	list and in meetings, which have been used to form BIER IPv6		layer header (Layer-4). From the view of the BIER layer, the IPv6
	requirements used to help the wg evaluate against the proposed		encapsulation is a tunnel working as a "link" of BIER. With an End-
	solutions:		to-End view, the tunnel from BFIR to BFERs is a Layer-2.5 BIER (P2MP)
			tunnel, and the BFIR-id is the BIER packet source-origin identifier,
			and is unchanged through the BIER domain from BFIR to BFERs.
	4.1. L2 Agnostic		This model is similar to the "MPLS over IP" [RFC4023] or "MPLS over
			UDP" [RFC7510] approach. A more general output of such approach in
			IETF is "MPLS Segment Routing over IP" [RFC8663]. It makes use of
			IPv4/IPv6 tunnel, IPv4/IPv6 UDP tunnel and IPv4/IPv6 GRE tunnel to
			encapsulate the MPLS-based instructions. In fact, BIER-MPLS could
			use this approach directly since BIER-MPLS is based on MPLS.
	The solution should be agnostic to the underlying L2 data link type.		There may be, however, in certain cases some difficulty with
			allocation of an MPLS label and advertisement through the control-
			plane. For example, a simple inter-AS BIER deployment may want to
			use the auto-configuration of BIFT-id using Non-MPLS BIER
			encapsulation [RFC8296] as illustrated in
			[I-D.geng-bier-ipv6-inter-domain]. This brings the need of a new
			"Next Header" value to indicate the "Non-MPLS" BIER header.
	4.2. Hop by hop SA or DA modification		For IPv4/IPv6 GRE, the "Next Header" is the 16-bit "Protocol Type"
			field, and has adequate space for such requirement.
	The solution should not require hop-by-hop modification of the IP		For IPv4/IPv6 UDP, the "Next Header" is the 16-bit "Destination Port"
	source address field.		field, and has adequate space for such requirement.
	Solutions that do not require Hop-by-hop SA modification are		For IPv4/IPv6, the "Next Header" is a 8-bit value and needs to be
	preferred. Solutions which maintain the SA will help fast-path		allocated from the "Assigned Internet Protocol Numbers" registry.
	forwarding (req 4.9 in this doc), are beneficial for receiving
	notices from the BFIR for functions like BIER PING, TRACE and MTU
	notification, are beneficial for identifying an MVPN instance to help
	remove more encapsulation such as Service Label, are beneficial for
	SA filtering (req 4.6 in this doc), and are beneficial for data
	origin authentication if IPSEC is desired (req 4.12 in this doc).
	The solution should use a IPv6 unicast address in the DA to satisfy		Reassembly/Re-fragmentation of a packet has to be executed on each
	the BIER architecture without introducing additional tunnel		BFR in such case. This may be common and even friendly for a
	encapsulation, and thus may require DA modification by each BFR hop.		protocol stack in a BFR software implementation, but it may impose
			cost for a BFR hardware implementation.
	It is commonly thought that BIERv6 could use a multicast address, as		IPv6 functions that are expected to be executed from BFIR to BFER are
	BIER is one-hop replication on each BFR in normal cases. However, as		assumed to be broken on the BFRs, for example, IPv6 Fragmentation/
	described in section 6.9 of [RFC8279], it is useful to support non-		Assembly or IPSEC ESP. This is because the "IPv6 tunnel" and all its
	BIER routers within a BIER domain. From the wg discussion about this		functions is "terminated" on the BFRs. These functions, if desired,
	document, focus is on the advantages of using unicast addresses that		may need to be re-designed in the "Layer-2.5" BIER mode.
	otherwise could not be possible by using a multicast address or
	anycast address for two cases: replication from a BFR to other BFR(s)
	connected by Layer-3 Non-BFR router(s) without using tunneling
	techniques, and replication from a BFR to other BFR(s) connected by
	Layer-2 switch(es) without broadcasting or snooping on Layer-2
	switch(es) in between. Based on the natural reachability of an IPv6
	unicast address, it can support the multi-hop replication cases as
	well as the one-hop replication case using one encapsulation.
	4.3. L4 Inspection		For deployment security, it is necessary to ensure the "BIER" packet
			is only using the allowed IPv6 tunnel.
	The solution should not require the BFRs to inspect layer 4 or		3.2. Native IPv6 Model
	require any changes to layer 4.
	The proposals requiring BIER header encapsulated as part of the		The second conceptual model is a Native IPv6 Model that integrates
	payload may conflict with the layers of IP protocol stack. On the		BIER as part of the IPv6 data plane, making it a "Layer-3 BIER"
	one hand, fast-path BIER forwarding has to be based on the L4		approach.
	inspection of the BIER header within the payload, and on the other
	hand, the BIER forwarding needs to change the BitString in the BIER
	header of the payload, which in turn conflicts with other L3
	functions. Following are some examples.
	One example is in IP fragmentation case, where a packet may need to		|<----------(L3 BIER(P2MP) tunnel)--------->|
	be fragmented by a BFIR, according to the BIER-MTU defined in		| |
	RFC8296, into one packet with BIER header and 1500 bytes of payload,		+------+ +-------+ +-----+ +------+
	and another packet with the remaining 500 bytes of payload. When BFR		| BFIR |-------|Non-BFR|-------| BFR |--------| BFER |
	B receives the second fragmentation packet from BFR A, BFR B can't		+------+ +-------+ +-----+ +------+
	forward this packet because BFR B doesn't have the BIER header in the
	second fragmentation packet. Section 4.11 describes the
	fragmentation requirements.
	The second example is in IPSEC case, where the BIER header is part of		------- physical link
	the payload for confidentiality or integrity. The need to change the
	BitString in the BIER Header, when forwarding BIER packets, makes it
	incompatible with IPSEC. Section 4.12 describes the IPSEC
	requirements.
	4.4. Multicast address in SA field		<-----> BIER(P2MP) tunnel
	The solution should not allow a multicast address to be put in the IP		In this model, BIER works as part of the IPv6 data plane. BFIR and
	source address field. According to [RFC1112] "A host group address		BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6
	must never be placed in the source address field or anywhere in a		segment endpoints. On each BFR, the segment endpoint behaviour of
	source route or record route option of an outgoing IP datagram."		IPv6 data plane is executed, and there is no decapsulation of
			receiving IPv6 tunnel and encapsulation of new IPv6 tunnel for
			sending.
	4.5. Incorrect bits		In this mode, BIER is integrated into the IPv6 data plane. The IPv6
			source address is the BIER packet source-origin identifier, and is
			unchanged through the BIER domain from BFIR to BFERs.
	The solution should not assume that bits never get set incorrectly.		This model is similar to many examples emerging in the IETF community
			which soley use the IPv6 data plane. SRv6 introduced in [RFC8754]
			and [I-D.ietf-spring-srv6-network-programming] is an example. The
			benefits of such approach includes reducing the number of
			encapsulation layers, capability of deployment with non-capable
			routers in a network, extending the technology in a wider inter-AS
			scope using IP reachability, and capability of integrating the
			functions of the IPv6 data plane.
	If a packet with incorrect bits is set, it should not damage BIERv6		This model typically needs an extension to IPv6 data plane, with an
	functionality or any other functions such as Unicast Reverse Path		IPv6 extension header or Option introduced.
	Forwarding (URPF), nor should it cause loops or duplicates as
	described in section 6.8 of [RFC8279].
	4.6. SA filtering		IPv6 functions that are expected to be executed from BFIR to BFER is
			supported if correctly designed, for example, IPv6 Fragmentation/
			Assembly or IPSEC ESP.
	The solution should not require changes in source address filtering		For deployment security, it is necessary to ensure the "BIER" packet
	procedures. For instance if a host uses a "BIER address" as its		is in a trusted IPv6-based domain.
	source address in a given packet, and the packet doesn't get dropped
	according to existing SA filtering procedures, the packet may elicit
	responses that put the BIER address in their destination address
	fields. This could be a security issue, as it creates an attack
	vector that can create 64 responses to a single probe.
	4.7. BIER architecture support		3.3. Encapsulation Approaches Considered
	It should be possible to use the solution to support the entire BIER		A number of approaches to the design of BIER-IPv6 encapsulation were
	architecture. The ability to bypass Non-BIER routers and L2 switches		investigated by the BIER Working Group and were discussed in IETF
	is part of the BIER architecture and having this ability is a		meetings and on the BIER list. This section divides these approaches
	mandatory requirement.		into the two conceptual models.
	Multiple sub-domains bound to one or many topologies or algorithms,		Transport-Independent Model approaches include:
	multiple sets for more BFERs, multiple Bit String Length for
	different forwarding capability, and multiple BIFTs for ECMP should
	be supported.
	4.8. Simple Encapsulation		Transport-Independent BIER [I-D.xu-bier-encapsulation].
	The solution should avoid requiring different encapsulation types, or		BIERin6 [I-D.zhang-bier-bierin6].
	complex tunneling techniques, to support BIER as an E2E multicast
	transport.
	A single encapsulation should support Layer-2 switches within BFRs,		Native IPv6 Model approaches include:
	or non-BFR within a BIER domain, or inter-domain deployment of BIER.
	4.9. Hardware fast path		BIER-over-IPv6 [I-D.pfister-bier-over-ipv6].
	The solution should enable the processing and forwarding of BIER		BIERv6 [I-D.xie-bier-ipv6-encapsulation].
	packets in hardware fast path.
	4.10. Conform to existing IPv6 Spec		4. Requirements
			There have been several suggested requirements, on the BIER email
			list and in meetings, which have been used to form BIER IPv6
			requirements used to help the wg evaluate against the proposed
			solutions. There is also many further discussions on the list about
			BIER IPv6 requirements from different scenarios.
			Considering that the importance of requirement for BIER IPv6 solution
			is different, in this document, the requirements are divided into two
			groups: mandatory and optional. The requirements in the mandatory
			group are considered necessary for any BIER IPv6 solution, while the
			requirements in the optional group should be considered but are not
			mandatory.
			4.1. Mandatory Requirements
			4.1.1. L2 Agnostic
			The solution must be agnostic to the underlying L2 data link type.
			The solution needs to support P2P ethernet links as well as shared
			media ethernet links without requiring the LAN switch to perform BIER
			snooping.
			4.1.2. Support BIER architecture
			The solution must support the BIER architecture.
			Multiple sub-domains bound to one or many topologies or algorithms,
			multiple sets for more BFERs, multiple Bit String Lengths for
			different forwarding capabilities, and multiple BIFTs for ECMP are
			considered essential functions of BIER and need to be supported.
			4.1.3. Conform to existing IPv6 Spec
	The proposed encapsulation must conform to the IPv6 specification and		The proposed encapsulation must conform to the IPv6 specification and
	guidelines as described in RFC8200. It should not require any new		guidelines as described in RFC8200. If new extensions to existing
	modifications to the IPv6 specification aside from extensions to		IPv6 specification are required, it needs to be discussed and
	existing mechanisms such as IPv6 Options.		reviewed by the 6man working-group.
	4.11. Support Fragmentation		4.1.4. Support deployment with Non-BFR routers
	The proposed encapsulation must support fragmentation. It shouldn't		The solution must support deployments with Non-BFR routers. This is
	require fragmentation and re-assembly at each hop.		beneficial to the deployment of BIER, especially in early deployments
			when some routers do not support BIER forwarding but support IPv6
			forwarding. This is also the No.1 charter item, "Transition
			Mechanisms and Partial Deployments" of the BIER WG.
	4.12. Support IPv6 Security		4.1.5. Support inter-AS multicast deployment
	The proposed encapsulation should support IPv6 security including AH/		Inter-AS multicast support is needed for ease of provisioning the
	ESP extension headers. It shouldn't require hop-by-hop encryption/		P2MP transport service to enterprises. This could greatly increase
	decryption.		the scalability of BIER, as it is usually considered to be suitable
			only for small intra-AS scenarios.
			4.1.6. Support Simple Encapsulation
			The solution must avoid requiring different encapsulation types. A
			solution needs to do careful trade-off analysis and select one
			encapsulation as its proposal for best coverage of various scenarios.
			4.1.7. Support Deployment Security
			The proposed solution must include careful security considerations,
			including all that is already considered in BIER architecture RFC8279
			and RFC8296, and other security concerns that may raise due to the
			addition of IPv6.
			4.2. Optional Requirements
			4.2.1. Support MVPN
			The solution MAY support MVPN services that is defined in [RFC6513].
			When MVPN is supported, it should work in a "tunnel" mode,
			encapsulating IP or IPv6 multicast packet in an outer IPv6 header.
			When MVPN is supported, it is suggested to think about both intra-AS
			and inter-AS deployment.
			4.2.2. Support OAM
			BIER OAM MAY be supported, either directly using existing method, or
			specify some variant method for the same function. It may be
			considered essential as part of the BIER architecture in some cases.
			4.2.3. Support IPSEC
			IPSEC is optional to IPv6 and multicast. It is preferred to support
			IPSEC, including AH/ESP. If IPSEC is to be supported, it shouldn't
			require hop-by-hop encryption/decryption.
			4.2.4. Support Fragmentation
			As part of IPv6 specification [RFC8200], BIER IPv6 may support
			fragmentation on BFIR and assembly on BFER. Support of Fragmentation
			can enhance the capability of BIER leveraging the BIER-MTU as
			introduced in section 3 of [RFC8296]. If Fragmentation is to be
			supported, it shouldn't require fragmentation and re-assembly at each
			hop.
			4.2.5. Support hardware fast path
			If a proposed solution is intended for some scenarios like service-
			provider networks, it should enable the processing and forwarding of
			BIER packets in hardware fast path.
	5. IANA Considerations		5. IANA Considerations
	Some BIERv6 encapsulation proposals do not require any action from		Some BIERv6 encapsulation proposals do not require any action from
	IANA while other proposals require new BIER Destination Option		IANA while other proposals require new BIER Destination Option
	codepoints from IPv6 sub-registries, new "Next header" values, or		codepoints from IPv6 sub-registries, new "Next header" values, or
	require new IP Protocol codes. This document, however, does not		require new IP Protocol codes. This document, however, does not
	require anything from IANA.		require anything from IANA.
	6. Security Considerations		6. Security Considerations
	There are no security issues introduced by this draft.		There are no security issues introduced by this draft.
	7. Acknowledgement		7. Acknowledgement
	Thank you to Eric Rosen for his listed set of requirements on the		Thank you to Eric Rosen for his listed set of requirements on the
	bier wg list.		bier wg list.
	8. Normative References		8. Normative References
			[I-D.geng-bier-ipv6-inter-domain]
			Geng, L., Xie, J., McBride, M., and G. Yan, "Inter-Domain
			Multicast Deployment using BIERv6", draft-geng-bier-ipv6-
			inter-domain-01 (work in progress), January 2020.
			[I-D.ietf-bier-use-cases]
			Nainar, N., Asati, R., Chen, M., Xu, X., Dolganow, A.,
			Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C.
			Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-11
			(work in progress), March 2020.
			[I-D.ietf-spring-srv6-network-programming]
			Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
			Matsushima, S., and Z. Li, "SRv6 Network Programming",
			draft-ietf-spring-srv6-network-programming-16 (work in
			progress), June 2020.
	[I-D.pfister-bier-over-ipv6]		[I-D.pfister-bier-over-ipv6]
	Pfister, P. and I. Wijnands, "An IPv6 based BIER		Pfister, P. and I. Wijnands, "An IPv6 based BIER
	Encapsulation and Encoding", draft-pfister-bier-over-		Encapsulation and Encoding", draft-pfister-bier-over-
	ipv6-01 (work in progress), October 2016.		ipv6-01 (work in progress), October 2016.
	[I-D.xie-bier-ipv6-encapsulation]		[I-D.xie-bier-ipv6-encapsulation]
	Xie, J., Geng, L., McBride, M., Asati, R., and S.		Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S.,
	Dhanaraj, "Encapsulation for BIER in Non-MPLS IPv6		Zhu, Y., Qin, Z., Shin, M., and X. Geng, "Encapsulation
	Networks", draft-xie-bier-ipv6-encapsulation-04 (work in		for BIER in Non-MPLS IPv6 Networks", draft-xie-bier-
	progress), December 2019.		ipv6-encapsulation-07 (work in progress), June 2020.
	[I-D.xu-bier-encapsulation]		[I-D.xu-bier-encapsulation]
	Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet,		Xu, X., somasundaram.s@alcatel-lucent.com, s., Jacquenet,
	C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit		C., Raszuk, R., and Z. Zhang, "A Transport-Independent Bit
	Index Explicit Replication (BIER) Encapsulation Header",		Index Explicit Replication (BIER) Encapsulation Header",
	draft-xu-bier-encapsulation-06 (work in progress),		draft-xu-bier-encapsulation-06 (work in progress),
	September 2016.		September 2016.
	[I-D.zhang-bier-bierin6]		[I-D.zhang-bier-bierin6]
	Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and		Zhang, Z., Przygienda, T., Wijnands, I., Bidgoli, H., and
	skipping to change at page 9, line 23 ¶		skipping to change at page 11, line 36 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in		[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,		IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
	December 1998, <https://www.rfc-editor.org/info/rfc2473>.		December 1998, <https://www.rfc-editor.org/info/rfc2473>.
			[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
			"Encapsulating MPLS in IP or Generic Routing Encapsulation
			(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
			<https://www.rfc-editor.org/info/rfc4023>.
			[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
			BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
			2012, <https://www.rfc-editor.org/info/rfc6513>.
			[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
			"Encapsulating MPLS in UDP", RFC 7510,
			DOI 10.17487/RFC7510, April 2015,
			<https://www.rfc-editor.org/info/rfc7510>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,		[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Przygienda, T., and S. Aldrin, "Multicast Using Bit Index		Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
	Explicit Replication (BIER)", RFC 8279,		Explicit Replication (BIER)", RFC 8279,
	DOI 10.17487/RFC8279, November 2017,		DOI 10.17487/RFC8279, November 2017,
	<https://www.rfc-editor.org/info/rfc8279>.		<https://www.rfc-editor.org/info/rfc8279>.
	[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,		[RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation		Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation
	for Bit Index Explicit Replication (BIER) in MPLS and Non-		for Bit Index Explicit Replication (BIER) in MPLS and Non-
	MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January		MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January
	2018, <https://www.rfc-editor.org/info/rfc8296>.		2018, <https://www.rfc-editor.org/info/rfc8296>.
	[RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R.,		[RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx,
	Ed., and M. Townsley, "Use Cases for IPv6 Source Packet		W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663,
	Routing in Networking (SPRING)", RFC 8354,		DOI 10.17487/RFC8663, December 2019,
	DOI 10.17487/RFC8354, March 2018,		<https://www.rfc-editor.org/info/rfc8663>.
	<https://www.rfc-editor.org/info/rfc8354>.
			[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
			Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
			(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
			<https://www.rfc-editor.org/info/rfc8754>.
	Appendix A. Solutions Evaluation		Appendix A. Solutions Evaluation
	The following are solutions that have been proposed to solve BIER in		The following are solutions that have been proposed to solve BIER in
	IPv6 environments. Some solutions propose encoding while others		IPv6 environments. Some solutions propose encoding while others
	propose encapsulation. It is recommended for the wg to evaluate		propose encapsulation. It is recommended for the wg to evaluate
	these solutions against the requirements listed previously in order		these solutions against the requirements listed previously in order
	to make informed decisions on solution readiness.		to make informed decisions on solution readiness.
	As illustrated in these examples, the BIER header, or the BitString,		As illustrated in these examples, the BIER header, or the BitString,
	skipping to change at page 10, line 21 ¶		skipping to change at page 13, line 8 ¶
	+---------------+-----------------+-------------------		+---------------+-----------------+-------------------
	| Ethernet | BIER header | payload		| Ethernet | BIER header | payload
	| (ethType = | (BIFT-id, ...) |		| (ethType = | (BIFT-id, ...) |
	| 0xAB37) | |		| 0xAB37) | |
	| | Next Header |		| | Next Header |
	+---------------+-----------------+-------------------		+---------------+-----------------+-------------------
	BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined		BIER-ETH encapsulation (BIER header for Non-MPLS networks as defined
	in [RFC8296]) can be used to transport the multicast data in the IPv6		in [RFC8296]) can be used to transport the multicast data in the IPv6
	network by encapsulating the multicast user data payload within the		network by encapsulating the multicast user data payload within the
	BIER-ETH header. However, using BIER-ETH in IPv6 networks is not		BIER-ETH header. However, BIER-ETH in IPv6 networks is not
	considered to be a native IPv6 solution which utilizes the IPv6		considered to be a "BIER natively in IPv6" solution which utilizes
	header to forward the packet. Below listed are some of the		the IPv6 header to forward the packet.
	properties of BIER-ETH encapsulation which could be seen as the
	reasons for the same,
	o BIER-ETH is not agnostic to the underlying (L2) data link type.
	It can be deployed only in the networks with Ethernet data link
	and cannot be deployed in an network which deploys any other data
	link types. Use of BIER-ETH in IPv6 networks might also result in
	using different BIER encapsulations, when BIER is used as a E2E
	multicast transport across a larger heterogeneous IPv6 networks
	with different data link types used in different layers of the
	network.
	o BIER-ETH in IPv6 networks is considered similar to 6PE solution
	where-in the multicast user data packet is encapsulated with-in
	the BIER-MPLS header.
	* It is worth noting that the only major difference between BIER-
	MPLS and BIER-Non-MPLS header is that BIER-MPLS uses downstream
	assigned MPLS label while BIER-Non-MPLS header uses a domain-
	wide-unique BIFT-id. While the use of domain-wide-unique BIFT-
	id in BIER-ETH header takes away the complexity of allocation
	and state maintenance from the network, it still requires some
	sort of ID (similar to label) to identify the application
	context after the decapsulation of BIER header (example: MVPN
	VRF Label). Encoding of such an ID/LABEL before encapsulating
	the multicast user data payload with BIER-ETH header cannot be
	avoided.
	* The absence of an IPv6 header, and the optional IPv6 extension
	headers, deprives BIER of some of the useful cases (ex: Use of
	IPv6 address for identification of network function or service
	mapping) that is otherwise possible in native IPv6
	encapsulation which utilizes a IPv6 header.
	* Tunneling of BIER packets is one common technique used for FRR,		Mixed use of BIER-ETH in a native IPv6 solution is up to the solution
	to tunnel over BIER incapable nodes etc. While it is possible		and is outside the scope of this document.
	for the BIER-ETH encapsulated packet to be further encapsulated
	within a GRE6, etc tunnel, it might not be possible to parse
	and decapsulate different types of tunnel headers and forward
	the BIER packet completely in hardware fast path similar to the
	label stack processing in BIER-MPLS networks. It would be
	useful to select an encapsulation which could help in
	processing the tunnel and BIER header and make the forwarding
	decision completely in hardware fast path, which is lacking in
	BIER-ETH encapsulation if chosen to be deployed in pure IPv6
	networks.
	A.2. Encode Bitstring in IPv6 destination address		A.2. Encode Bitstring in IPv6 destination address
	+---------------+-------------------		+---------------+-------------------
	| IPv6 header | payload		| IPv6 header | payload
	| (BitString in |		| (BitString in |
	| DA lower bits)|		| DA lower bits)|
	| Next Header |		| Next Header |
	+---------------+-------------------		+---------------+-------------------
	skipping to change at page 13, line 30 ¶		skipping to change at page 15, line 17 ¶
	technology. As described in [I-D.xu-bier-encapsulation] and		technology. As described in [I-D.xu-bier-encapsulation] and
	[I-D.zhang-bier-bierin6], the BIER header, and the payload following		[I-D.zhang-bier-bierin6], the BIER header, and the payload following
	it, can be combined as an IPv6 payload, and be indicated by a new		it, can be combined as an IPv6 payload, and be indicated by a new
	Upper-layer IPv6 Next-Header value. A unicast IPv6 destination		Upper-layer IPv6 Next-Header value. A unicast IPv6 destination
	address is used for the replication and changes when replicating a		address is used for the replication and changes when replicating a
	packet out to a neighbor.		packet out to a neighbor.
	Such proposals may include a request to IANA to allocate an IPv6		Such proposals may include a request to IANA to allocate an IPv6
	Next-Header code from "Assigned Internet Protocol Numbers".		Next-Header code from "Assigned Internet Protocol Numbers".
	A.5. Tunneling BIER in a IPv6 tunnel		A.5. Tunnelling BIER in a IPv6 tunnel
	+---------------+-----------------+------------+----------------		+---------------+-----------------+------------+----------------
	| IPv6 header | IPv6 Ext header | GRE header |		| IPv6 header | IPv6 Ext header | GRE header |
	| | (optional) | | BIER Hdr +		| | (optional) | | BIER Hdr +
	| | | | payload as GRE		| | | | payload as GRE
	| Next Header | Next Header | Proto = X | Payload		| Next Header | Next Header | Proto = X | Payload
	+---------------+-----------------+------------+----------------		+---------------+-----------------+------------+----------------
	A generic IPv6 Tunnel could be used to encapsulate the bier packet		A generic IPv6 Tunnel could be used to encapsulate the bier packet
	within an IPv6 domain.		within an IPv6 domain.
	skipping to change at page 14, line 12 ¶		skipping to change at page 15, line 42 ¶
	0xAB37, defined for BIER, can be used in a GRE header to indicate the		0xAB37, defined for BIER, can be used in a GRE header to indicate the
	subsequent BIER header and payload in an IPv6 network.		subsequent BIER header and payload in an IPv6 network.
	+---------------+-----------------+------------+----------------		+---------------+-----------------+------------+----------------
	| IPv6 header | IPv6 Ext header | UDP header |		| IPv6 header | IPv6 Ext header | UDP header |
	| | (optional) | | BIER Hdr +		| | (optional) | | BIER Hdr +
	| | | | payload as UDP		| | | | payload as UDP
	| Next Header | Next Header | DPort = X | Payload		| Next Header | Next Header | DPort = X | Payload
	+---------------+-----------------+------------+----------------		+---------------+-----------------+------------+----------------
	UDP-based tunneling is another mechanism which uses a specific UDP		UDP-based tunnelling is another mechanism which uses a specific UDP
	port to indicate a UDP payload format. Both IPv4 and IPv6 can		port to indicate a UDP payload format. Both IPv4 and IPv6 can
	support UDP. Such UDP-based tunnels can be used for BIER in a IPv6		support UDP. Such UDP-based tunnels can be used for BIER in a IPv6
	network by defining a new UDP port to indicate the BIER header and		network by defining a new UDP port to indicate the BIER header and
	payload.		payload.
	Authors' Addresses		Authors' Addresses
	Mike McBride		Mike McBride
	Futurewei		Futurewei
	Email: michael.mcbride@futurewei.com		Email: michael.mcbride@futurewei.com
	Jingrong Xie		Jingrong Xie
	Huawei		Huawei
	Email: xiejingrong@huawei.com		Email: xiejingrong@huawei.com
	skipping to change at line 652 ¶		skipping to change at page 17, line 4 ¶
	Rajiv Asati		Rajiv Asati
	Cisco		Cisco
	Email: rajiva@cisco.com		Email: rajiva@cisco.com
	Yongqing Zhu		Yongqing Zhu
	China Telecom		China Telecom
	Email: zhuyq8@chinatelecom.cn		Email: zhuyq8@chinatelecom.cn
			Gyan S. Mishra
			Verizon Inc.
			13101 Columbia Pike
			Silver Spring
			,
			MD 20904
			United States of America
			Phone:
			301 502-1347
			Email:
			gyan.s.mishra@verizon.com
End of changes. 67 change blocks.
	264 lines changed or deleted		339 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/