< draft-ietf-bier-mld-04.txt		draft-ietf-bier-mld-05.txt >
	Network Working Group P. Pfister		Network Working Group P. Pfister
	Internet-Draft IJ. Wijnands		Internet-Draft IJ. Wijnands
	Intended status: Standards Track S. Venaas		Intended status: Standards Track S. Venaas
	Expires: September 7, 2020 Cisco Systems		Expires: August 26, 2021 Cisco Systems
	C. Wang		C. Wang
	Z. Zhang		Z. Zhang
	ZTE Corporation		ZTE Corporation
	M. Stenberg		M. Stenberg
	March 6, 2020		February 22, 2021
	BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery		BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery
	Protocols		Protocols
	draft-ietf-bier-mld-04		draft-ietf-bier-mld-05
	Abstract		Abstract
	This document specifies the ingress part of a multicast flow overlay		This document specifies the ingress part of a multicast flow overlay
	for BIER networks. Using existing multicast listener discovery		for BIER networks. Using existing multicast listener discovery
	protocols, it enables multicast membership information sharing from		protocols, it enables multicast membership information sharing from
	egress routers, acting as listeners, toward ingress routers, acting		egress routers, acting as listeners, toward ingress routers, acting
	as queriers. Ingress routers keep per-egress-router state, used to		as queriers. Ingress routers keep per-egress-router state, used to
	construct the BIER bit mask associated with IP multicast packets		construct the BIER bit mask associated with IP multicast packets
	entering the BIER domain.		entering the BIER domain.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 7, 2020.		This Internet-Draft will expire on August 26, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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 37 ¶		skipping to change at page 2, line 37 ¶
	5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 8		5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 8
	5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 8		5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 8
	6. BIER MLD/IGMP Extension Type . . . . . . . . . . . . . . . . 8		6. BIER MLD/IGMP Extension Type . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. BIER Use Case in Data Centers . . . . . . . . . . . 12		Appendix A. BIER Use Case in Data Centers . . . . . . . . . . . 12
	A.1. Convention and Terminology . . . . . . . . . . . . . . . 13		A.1. Convention and Terminology . . . . . . . . . . . . . . . 14
	A.2. BIER in data centers . . . . . . . . . . . . . . . . . . 14		A.2. BIER in data centers . . . . . . . . . . . . . . . . . . 14
	A.3. A BIER MLD solution for Virtual Network information . . . 14		A.3. A BIER MLD solution for Virtual Network information . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The Bit Index Explicit Replication (BIER - [RFC8279]) forwarding		The Bit Index Explicit Replication (BIER - [RFC8279]) forwarding
	technique enables IP multicast transport across a BIER domain. When		technique enables IP multicast transport across a BIER domain. When
	receiving or originating a packet, ingress routers have to construct		receiving or originating a packet, ingress routers have to construct
	a bit mask indicating which BIER egress routers located within the		a bit mask indicating which BIER egress routers located within the
	same BIER domain will receive the packet. A stateless approach would		same BIER domain will receive the packet. A stateless approach would
	consist of forwarding all incoming packets toward all egress routers,		consist of forwarding all incoming packets toward all egress routers,
	which would in turn make a forwarding decision based on local		which would in turn make a forwarding decision based on local
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	protocol version 2 [RFC3810] (resp. the Internet Group Management		protocol version 2 [RFC3810] (resp. the Internet Group Management
	protocol version 3 [RFC3376]) as the ingress part of a BIER multicast		protocol version 3 [RFC3376]) as the ingress part of a BIER multicast
	flow overlay (BIER layering is described in [RFC8279]) for IPv6		flow overlay (BIER layering is described in [RFC8279]) for IPv6
	(resp. IPv4). It enables multicast membership information sharing		(resp. IPv4). It enables multicast membership information sharing
	from egress routers, acting as listeners, toward ingress routers,		from egress routers, acting as listeners, toward ingress routers,
	acting as queriers. Ingress routers keep per-egress-router state,		acting as queriers. Ingress routers keep per-egress-router state,
	used to construct the BIER bit mask associated with IP multicast		used to construct the BIER bit mask associated with IP multicast
	packets entering the BIER domain.		packets entering the BIER domain.
	This document defines an MLDv2 and IGMPv3 extension type, using the		This document defines an MLDv2 and IGMPv3 extension type, using the
	extension scheme defined in [I-D.venaas-pim-igmp-mld-extension], that		extension scheme defined in [I-D.ietf-pim-igmp-mld-extension], that
	allows for providing BIER specific information about the message		is used to provide BIER specific information about the message
	originator.		originator.
	This specification is applicable to both IP version 4 and version 6.		This specification is applicable to both IP version 4 and version 6.
	It therefore specifies two separate mechanisms operating		It therefore specifies two separate mechanisms operating
	independently. For the sake of simplicity, the rest of this document		independently. For the sake of simplicity, the rest of this document
	uses IPv6 terminology. It can be applied to IPv4 by replacing		uses IPv6 terminology. It can be applied to IPv4 by replacing
	'MLDv2' with 'IGMPv3', and following specific requirements when		'MLDv2' with 'IGMPv3', and following specific requirements when
	explicitly stated.		explicitly stated.
	2. Terminology		2. Terminology
	skipping to change at page 6, line 34 ¶		skipping to change at page 6, line 34 ¶
	o Toward all BMLD Nodes (i.e., providing to the BIER Layer the BFR-		o Toward all BMLD Nodes (i.e., providing to the BIER Layer the BFR-
	ids of all BMLD Nodes).		ids of all BMLD Nodes).
	o Without the IPv6 router alert option [RFC2711] in the hop-by-hop		o Without the IPv6 router alert option [RFC2711] in the hop-by-hop
	extension header [RFC8200] (or the IPv4 router alert option		extension header [RFC8200] (or the IPv4 router alert option
	[RFC2113] for IPv4).		[RFC2113] for IPv4).
	o With the IP destination address set to the 'all BMLD Nodes' group		o With the IP destination address set to the 'all BMLD Nodes' group
	address.		address.
	o With the IP source address set to the BFR-Prefix of the sender.		o With a deterministic IP source address. It is RECOMMENDED that
			the address is a BFR-Prefix of the sender, but it MAY be another
			value. This address is only used for querier election.
	o With a TTL value large enough such that the packet can be received		o With a TTL value large enough such that the packet can be received
	by all BMLD Nodes, depending on the underlying BIER layer (whether		by all BMLD Nodes, depending on the underlying BIER layer (whether
	it decrements the IP TTL or not) and the size of the network. The		it decrements the IP TTL or not) and the size of the network. The
	default value is 64.		default value is 64.
	o The extension defined in Section 6 MUST be included, specifying		o The extension type defined in Section 6 MUST be included once,
	the Sub-domain-id, BFR-id and BFR-Prefix of the sender. This		specifying the Sub-domain-id, BFR-id and BFR-Prefix of the sender.
	information may be useful for logging and debugging.		This information may be useful for logging and debugging.
	5.2.2. Sending Reports		5.2.2. Sending Reports
	BMLD Reports are IP packets sent over BIER by BMLD Listeners:		BMLD Reports are IP packets sent over BIER by BMLD Listeners:
	o Toward all BMLD Queriers (i.e., providing to the BIER layer the		o Toward all BMLD Queriers (i.e., providing to the BIER layer the
	BFR-ids of all BMLD Queriers).		BFR-ids of all BMLD Queriers).
	o Without the IPv6 router alert option [RFC2711] in the hop-by-hop		o Without the IPv6 router alert option [RFC2711] in the hop-by-hop
	extension header [RFC8200] (or the IPv4 router alert option		extension header [RFC8200] (or the IPv4 router alert option
	[RFC2113] for IPv4).		[RFC2113] for IPv4).
	o With the IP destination address set to the 'all BMLD Queriers'		o With the IP destination address set to the 'all BMLD Queriers'
	group address.		group address.
	o With the IP source address set to the BFR-Prefix of the sender.		o With a deterministic IP source address. It is RECOMMENDED that
			the address is a BFR-Prefix of the sender.
	o With a TTL value large enough such that the packet can be received		o With a TTL value large enough such that the packet can be received
	by all BMLD Queriers, depending on the underlying BIER layer		by all BMLD Queriers, depending on the underlying BIER layer
	(whether it decrements the IP TTL or not) and the size of the		(whether it decrements the IP TTL or not) and the size of the
	network. The default value is 64.		network. The default value is 64.
	o The extension defined in Section 6 MUST be included, specifying		o The extension type defined in Section 6 MUST be included once,
	the Sub-domain-id, BFR-id and BFR-Prefix of the sender. This		specifying the Sub-domain-id, BFR-id and BFR-Prefix of the sender.
	information is used to create the necessary forwarding state for		This information is used to create the necessary forwarding state
	requested flows, and may be useful for logging and debugging.		for requested flows, and may be useful for logging and debugging.
	Since the reports may contain a large number of records, they may		Since the reports may contain a large number of records, they may
	become larger than the maximum BIER payload that can be delivered to		become larger than the maximum BIER payload that can be delivered to
	all the BMLD Queriers. Hence an implementation will need to either		all the BMLD Queriers. Hence an implementation will need to either
	use a small default maximum size, allow configuration of a maximum		use a small default maximum size, allow configuration of a maximum
	size, or rely on MTU discovery. MTU discovery may be done for a sub-		size, or rely on MTU discovery. MTU discovery may be done for a sub-
	domain using BIER MTU Discovery [I-D.venaas-bier-mtud] or for the set		domain using BIER MTU Discovery [I-D.ietf-bier-mtud] or for the set
	of BMLD Queriers using Path MTU Discovery		of BMLD Queriers using Path MTU Discovery
	[I-D.ietf-bier-path-mtu-discovery].		[I-D.ietf-bier-path-mtu-discovery].
	5.2.3. Receiving Queries		5.2.3. Receiving Queries
	BMLD Queriers and Listeners MUST check the destination address of all		BMLD Queriers and Listeners MUST check the destination address of all
	the IP packets that are received or forwarded over BIER whenever		the IP packets that are received or forwarded over BIER whenever
	their own BIER bit is set in the packet. If the destination address		their own BIER bit is set in the packet. If the destination address
	is equal to the 'all BMLD Nodes' group address the packet is		is equal to the 'all BMLD Nodes' group address the packet is
	processed as specified in this section.		processed as specified in this section.
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	Listener is provided to the BIER layer such that whenever a multicast		Listener is provided to the BIER layer such that whenever a multicast
	packet enters the BIER domain, if that packet matches the membership		packet enters the BIER domain, if that packet matches the membership
	information from a BMLD Listener, its Sub-domain-id and BFR-id is		information from a BMLD Listener, its Sub-domain-id and BFR-id is
	added to the set of Sub-domains and BFR-ids the packet should be		added to the set of Sub-domains and BFR-ids the packet should be
	forwarded to by the BIER-Layer.		forwarded to by the BIER-Layer.
	6. BIER MLD/IGMP Extension Type		6. BIER MLD/IGMP Extension Type
	A new MLD/IGMP extension type adds BIER specific information to IGMP/		A new MLD/IGMP extension type adds BIER specific information to IGMP/
	MLD messages, using the extension scheme defined in		MLD messages, using the extension scheme defined in
	[I-D.venaas-pim-igmp-mld-extension]). The BIER specific information		[I-D.ietf-pim-igmp-mld-extension]). The BIER specific information is
	is the same as the PTA tunnel identifier in [RFC8556] and is shown in		the same as the PTA tunnel identifier in [RFC8556] and is shown in
	Figure 1. Note that, as defined in the MLD (resp. IGMP), existing		Figure 1. Note that, as defined in the MLD (resp. IGMP), existing
	implementations are supposed to ignore this additional data.		implementations are supposed to ignore this additional data.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Ext Type TBD | Sub-domain ID | BFR-ID |		| Ext Type TBD | Sub-domain ID | BFR-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| BFR-Prefix |		| BFR-Prefix |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 9, line 32 ¶		skipping to change at page 9, line 32 ¶
	[[RFC8279]]). This indicates the BIER sub-domain of the router		[[RFC8279]]). This indicates the BIER sub-domain of the router
	originating the message.		originating the message.
	o BFR-id: A two-octet field containing the BFR-id, in the specified		o BFR-id: A two-octet field containing the BFR-id, in the specified
	sub-domain, of the router originating the message.		sub-domain, of the router originating the message.
	o BFR-prefix: The BFR-prefix (see [[RFC8279]]) of the router that is		o BFR-prefix: The BFR-prefix (see [[RFC8279]]) of the router that is
	originating the message. The BFR-prefix will either be a /32 IPv4		originating the message. The BFR-prefix will either be a /32 IPv4
	address or a /128 IPv6 address.		address or a /128 IPv6 address.
			This extension type MUST be present once in all IGMP and MLD messages
			when originated with a BIER header to identify the BIER originator.
			It is expected that any BIER router originating IGMP/MLD messages in
			BIER supports this specification. Any IGMP/MLD messages that do not
			contain the extension Section 6) MUST be dropped by the decapsulating
			router with no processing other than potentially logging or
			debugging. It is expected that any BIER router processing IGMP/MLD
			messages with BIER encapsulation supports this specification. If
			they do not, they will likely ignore the report since they cannot
			identify the BIER receiver, but they may be able to derive some of
			the receiver information from the BIER header.
	7. Security Considerations		7. Security Considerations
	BMLD makes use of IP MLDv2 messages transported over BIER in order to		BMLD makes use of IGMPv3/MLDv2 messages transported over BIER in
	configure the BIER Layer of BFIRs. BMLD messages MUST be secured,		order to configure the BIER Layer of BFIRs. BMLD messages MUST be
	either by relying on physical or link-layer security, by securing the		secured, either by relying on physical or link-layer security, by
	IP packets (e.g., using IPSec [RFC4301]), or by relying on security		securing the IP packets (e.g., using IPSec [RFC4301]), or by relying
	features provided by the BIER Layer.		on security features provided by the BIER Layer.
	Whenever an attacker would be able to spoof the identity of a router,		By spoofing the IP source address, an attacker could become the IGMP/
	it could:		MLD querier. Once one becomes the querier, several attack vectors
			are possible. This is similar to regular IGMP/MLD without BIER
			encapsulation.
			An attacker could send reports with the BIER IGMP/MLD extension
			Section 6) specifying a BFR-ID and BIER prefix identifying another
			router. This would allow the attacker to:
	o Redirect undesired traffic toward the spoofed router by		o Redirect undesired traffic toward the spoofed router by
	subscribing to undesired multicast traffic.		subscribing to undesired multicast traffic.
	o Prevent desired multicast traffic from reaching the spoofed router		o Prevent desired multicast traffic from reaching the spoofed router
	by unsubscribing to some desired multicast traffic.		by unsubscribing to some desired multicast traffic.
	8. IANA Considerations		8. IANA Considerations
	This document requests that IANA assigns a new type called BIER		This document requests that IANA assigns a new type called BIER
	information in the registry defined in		information in the registry defined in
	[I-D.venaas-pim-igmp-mld-extension].		[I-D.ietf-pim-igmp-mld-extension].
	9. Acknowledgements		9. Acknowledgements
	Comments concerning this document are very welcome.		Comments concerning this document are very welcome.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-bier-path-mtu-discovery]		[I-D.ietf-pim-igmp-mld-extension]
	Mirsky, G., Przygienda, T., and A. Dolganow, "Path Maximum		Sivakumar, M., Venaas, S., Zhang, Z., and H. Asaeda,
	Transmission Unit Discovery (PMTUD) for Bit Index Explicit		"IGMPv3/MLDv2 Message Extension", draft-ietf-pim-igmp-mld-
	Replication (BIER) Layer", draft-ietf-bier-path-mtu-		extension-04 (work in progress), January 2021.
	discovery-07 (work in progress), November 2019.
	[I-D.venaas-bier-mtud]
	Venaas, S., Wijnands, I., Ginsberg, L., and M. Sivakumar,
	"BIER MTU Discovery", draft-venaas-bier-mtud-02 (work in
	progress), October 2018.
	[I-D.venaas-pim-igmp-mld-extension]
	Sivakumar, M., Venaas, S., and Z. Zhang, "IGMPv3/MLDv2
	Message Extension", draft-venaas-pim-igmp-mld-extension-00
	(work in progress), November 2019.
	[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,		[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
	DOI 10.17487/RFC2113, February 1997,		DOI 10.17487/RFC2113, February 1997,
	<https://www.rfc-editor.org/info/rfc2113>.		<https://www.rfc-editor.org/info/rfc2113>.
	[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>.
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 22 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[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>.
	10.2. Informative References		10.2. Informative References
			[I-D.ietf-bier-mtud]
			Venaas, S., Wijnands, I., Ginsberg, L., and M. Sivakumar,
			"BIER MTU Discovery", draft-ietf-bier-mtud-00 (work in
			progress), February 2019.
			[I-D.ietf-bier-path-mtu-discovery]
			Mirsky, G., Przygienda, T., and A. Dolganow, "Path Maximum
			Transmission Unit Discovery (PMTUD) for Bit Index Explicit
			Replication (BIER) Layer", draft-ietf-bier-path-mtu-
			discovery-09 (work in progress), November 2020.
	[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",		[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
	RFC 2711, DOI 10.17487/RFC2711, October 1999,		RFC 2711, DOI 10.17487/RFC2711, October 1999,
	<https://www.rfc-editor.org/info/rfc2711>.		<https://www.rfc-editor.org/info/rfc2711>.
	[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6		[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
	Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,		Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
	August 2002, <https://www.rfc-editor.org/info/rfc3306>.		August 2002, <https://www.rfc-editor.org/info/rfc3306>.
	[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,
End of changes. 20 change blocks.
	45 lines changed or deleted		66 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/