draft-ietf-lisp-gpe-16.txt		draft-ietf-lisp-gpe-17.txt
	Internet Engineering Task Force F. Maino, Ed.		Internet Engineering Task Force F. Maino, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track J. Lemon		Intended status: Standards Track J. Lemon
	Expires: December 5, 2020 Broadcom		Expires: January 8, 2021 Broadcom
	P. Agarwal		P. Agarwal
	Innovium		Innovium
	D. Lewis		D. Lewis
	M. Smith		M. Smith
	Cisco		Cisco
	June 3, 2020		July 7, 2020
	LISP Generic Protocol Extension		LISP Generic Protocol Extension
	draft-ietf-lisp-gpe-16		draft-ietf-lisp-gpe-17
	Abstract		Abstract
	This document describes extensions to the Locator/ID Separation		This document describes extensions to the Locator/ID Separation
	Protocol (LISP) Data-Plane, via changes to the LISP header, to		Protocol (LISP) Data-Plane, via changes to the LISP header, to
	support multi-protocol encapsulation.		support multi-protocol encapsulation.
	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
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 December 5, 2020.		This Internet-Draft will expire on January 8, 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 19 ¶		skipping to change at page 2, line 19 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3		1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
	2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3		2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3
	3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4		3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 4
	4. Implementation and Deployment Considerations . . . . . . . . 6		4. Implementation and Deployment Considerations . . . . . . . . 6
	4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6		4.1. Applicability Statement . . . . . . . . . . . . . . . . . 6
	4.2. Congestion Control Functionality . . . . . . . . . . . . 7		4.2. Congestion Control Functionality . . . . . . . . . . . . 7
	4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 7		4.3. UDP Checksum . . . . . . . . . . . . . . . . . . . . . . 8
	4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8		4.3.1. UDP Zero Checksum Handling with IPv6 . . . . . . . . 8
	4.4. DSCP, ECN and TTL . . . . . . . . . . . . . . . . . . . . 9		4.4. DSCP, ECN, TTL, and 802.1Q . . . . . . . . . . . . . . . 10
	5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10		5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10
	5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 10		5.1. Detection of ETR Capabilities . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11		6.1. LISP-GPE Next Protocol Registry . . . . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12		8. Acknowledgements and Contributors . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Normative References . . . . . . . . . . . . . . . . . . 12		9.1. Normative References . . . . . . . . . . . . . . . . . . 12
	9.2. Informative References . . . . . . . . . . . . . . . . . 13		9.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	skipping to change at page 3, line 10 ¶		skipping to change at page 3, line 10 ¶
	This document defines an extension for the LISP header, as defined in		This document defines an extension for the LISP header, as defined in
	[I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling		[I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling
	the encapsulation of Ethernet, IP or any other desired protocol all		the encapsulation of Ethernet, IP or any other desired protocol all
	the while ensuring compatibility with existing LISP deployments.		the while ensuring compatibility with existing LISP deployments.
	A flag in the LISP header, called the P-bit, is used to signal the		A flag in the LISP header, called the P-bit, is used to signal the
	presence of the 8-bit Next Protocol field. The Next Protocol field,		presence of the 8-bit Next Protocol field. The Next Protocol field,
	when present, uses 8 bits of the field that was allocated to the		when present, uses 8 bits of the field that was allocated to the
	echo-noncing and map-versioning features in		echo-noncing and map-versioning features in
	[I-D.ietf-lisp-rfc6830bis]. Those two features are no longer		[I-D.ietf-lisp-rfc6830bis]. Those two features are no longer
	available when the P-bit is used. However, appropriate LISP-GPE shim		available when the P-bit is used. However, appropriate LISP-GPE
	headers can be defined to specify capabilities that are equivalent to		(LISP Generic Protocol Extension) shim headers can be defined to
	echo-noncing and/or map-versioning.		specify capabilities that are equivalent to echo-noncing and/or map-
			versioning.
	Since all of the reserved bits of the LISP Data-Plane header have		Since all of the reserved bits of the LISP Data-Plane header have
	been allocated, LISP-GPE can also be used to extend the LISP Data-		been allocated, LISP-GPE can also be used to extend the LISP Data-
	Plane header by defining Next Protocol "shim" headers that implements		Plane header by defining Next Protocol "shim" headers that implements
	new data plane functions not supported in the LISP header. For		new data plane functions not supported in the LISP header. For
	example, the use of the Group-Based Policy (GBP) header		example, the use of the Group-Based Policy (GBP) header
	[I-D.lemon-vxlan-lisp-gpe-gbp] or of the In-situ Operations,		[I-D.lemon-vxlan-lisp-gpe-gbp] or of the In-situ Operations,
	Administration, and Maintenance (IOAM) header		Administration, and Maintenance (IOAM) header
	[I-D.brockners-ippm-ioam-vxlan-gpe] with LISP-GPE, can be considered		[I-D.brockners-ippm-ioam-vxlan-gpe] with LISP-GPE, can be considered
	an extension to add support in the Data-Plane for Group-Based Policy		an extension to add support in the Data-Plane for Group-Based Policy
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 43 ¶
	P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is		P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is
	set to 1 to indicate the presence of the 8 bit Next Protocol		set to 1 to indicate the presence of the 8 bit Next Protocol
	field.		field.
	If the P-bit is clear (0) the LISP header is bit-by-bit equivalent		If the P-bit is clear (0) the LISP header is bit-by-bit equivalent
	to the definition in [I-D.ietf-lisp-rfc6830bis].		to the definition in [I-D.ietf-lisp-rfc6830bis].
	When the P-bit is set to 1, bits N, E, V, and bits 8-23 of the		When the P-bit is set to 1, bits N, E, V, and bits 8-23 of the
	'Nonce/Map-Version/Next Protocol' field MUST be set to zero on		'Nonce/Map-Version/Next Protocol' field MUST be set to zero on
	transmission and ignored on receipt. Features equivalent to those		transmission and MUST be ignored on receipt. Features equivalent
	that were implemented with bits N,E and V in		to those that were implemented with bits N,E and V in
	[I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map-		[I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map-
	versioning, can be implemented by defining appropriate LISP-GPE		versioning, can be implemented by defining appropriate LISP-GPE
	shim headers.		shim headers.
	When the P-bit is set to 1, the LISP-GPE header is encoded as:		When the P-bit is set to 1, the LISP-GPE header is encoded as:
	0 x 0 0 x 1 x x		0 x 0 0 x 1 x x
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|N|L|E|V|I|P|K|K| 0x0000 | Next Protocol |		|N|L|E|V|I|P|K|K| 0x0000 | Next Protocol |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 21 ¶
	Figure 3: LISP-GPE with P-bit set to 1		Figure 3: LISP-GPE with P-bit set to 1
	Next Protocol: When the P-bit is set to 1, the lower 8 bits of the		Next Protocol: When the P-bit is set to 1, the lower 8 bits of the
	first 32-bit word are used to carry a Next Protocol. This Next		first 32-bit word are used to carry a Next Protocol. This Next
	Protocol field contains the protocol of the encapsulated payload		Protocol field contains the protocol of the encapsulated payload
	packet.		packet.
	This document defines the following Next Protocol values:		This document defines the following Next Protocol values:
			0x00 : Reserved
	0x01 : IPv4		0x01 : IPv4
	0x02 : IPv6		0x02 : IPv6
	0x03 : Ethernet		0x03 : Ethernet
	0x04 : Network Service Header (NSH) [RFC8300]		0x04 : Network Service Header (NSH) [RFC8300]
	0x05 to 0x7D Unassigned		0x05 to 0x7D: Unassigned
	0x7E to 0x7F: Experimentation and testing		0x7E, 0x7F: Experimentation and testing
	0x80 to 0xFD: Unassigned (shim headers)		0x80 to 0xFD: Unassigned (shim headers)
	0xFE to 0xFF: Experimentation and testing (shim headers)		0xFE, 0xFF: Experimentation and testing (shim headers)
	The values are tracked in the IANA LISP-GPE Next Protocol Registry		The values are tracked in the IANA LISP-GPE Next Protocol Registry
	as described in Section 6.1.		as described in Section 6.1.
	Next protocol values 0x7E, 0x7F and 0xFE, 0xFF are assigned for		Next protocol values 0x7E, 0x7F and 0xFE, 0xFF are assigned for
	experimentation and testing as per [RFC3692].		experimentation and testing as per [RFC3692].
	Next protocol values from Ox80 to 0xFD are assigned to protocols		Next protocol values from Ox80 to 0xFD are assigned to protocols
	encoded as generic "shim" headers. All shim protocols MUST use the		encoded as generic "shim" headers. All shim protocols MUST use the
	header structure in Figure 4, which includes a Next Protocol field.		header structure in Figure 4, which includes a Next Protocol field.
	When a shim header is used with other protocols identified by next		When shim headers are used with other protocols identified by next
	protocol values from 0x0 to 0x7D, the shim header MUST come before		protocol values from 0x00 to 0x7F, all the shim headers MUST come
	the further protocol, and the next header of the shim will indicate		first.
	which protocol follows the shim header.
	Shim headers can be used to incrementally deploy new GPE features,		Shim headers can be used to incrementally deploy new GPE features,
	keeping the processing of shim headers known to a given xTR		keeping the processing of shim headers known to a given xTR
	implementation in the 'fast' path (typically an ASIC), while punting		implementation in the 'fast' path (typically an ASIC), while punting
	the processing of the remaining new GPE features to the 'slow' path.		the processing of the remaining new GPE features to the 'slow' path.
	Shim protocols MUST have the first 32 bits defined as:		Shim protocols MUST have the first 32 bits defined as:
	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
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 30 ¶
	~ Protocol Specific Fields ~		~ Protocol Specific Fields ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Shim Header		Figure 4: Shim Header
	Where:		Where:
	Type: This field identifies the different messages of this protocol.		Type: This field identifies the different messages of this protocol.
	Length: The length, in 4-octect units, of this protocol message not		Length: The length, in 4-octet units, of this protocol message not
	including the first 4 octects.		including the first 4 octets.
	Reserved: The use of this field is reserved to the protocol defined		Reserved: The use of this field is reserved to the protocol defined
	in this message.		in this message.
	Next Protocol Field: The next protocol field contains the protocol		Next Protocol Field: The next protocol field contains the protocol
	of the encapsulated payload. The values are tracked in the IANA		of the encapsulated payload. The values are tracked in the IANA
	LISP-GPE Next Protocol Registry as described in Section 6.1.		LISP-GPE Next Protocol Registry as described in Section 6.1.
	4. Implementation and Deployment Considerations		4. Implementation and Deployment Considerations
	skipping to change at page 7, line 42 ¶		skipping to change at page 7, line 45 ¶
	LISP-GPE does not natively provide congestion control functionality		LISP-GPE does not natively provide congestion control functionality
	and relies on the payload protocol traffic for congestion control.		and relies on the payload protocol traffic for congestion control.
	As such LISP-GPE MUST be used with congestion controlled traffic or		As such LISP-GPE MUST be used with congestion controlled traffic or
	within a network that is traffic managed to avoid congestion (TMCE).		within a network that is traffic managed to avoid congestion (TMCE).
	An operator of a traffic managed network (TMCE) may avoid congestion		An operator of a traffic managed network (TMCE) may avoid congestion
	by careful provisioning of their networks, rate-limiting of user data		by careful provisioning of their networks, rate-limiting of user data
	traffic and traffic engineering according to path capacity.		traffic and traffic engineering according to path capacity.
	Encapsulated payloads may have Explicit Congestion Notification		Encapsulated payloads may have Explicit Congestion Notification
	mechanisms that may or may not be mapped to the outer IP header ECN		mechanisms that may or may not be mapped to the outer IP header ECN
	field. Such new encapsulated payolads, when registered with LISP-		field. Such new encapsulated payloads, when registered with LISP-
	GPE, MUST be accompanied by a set of guidelines derived from		GPE, MUST be accompanied by a set of guidelines derived from
	[I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].		[I-D.ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
	4.3. UDP Checksum		4.3. UDP Checksum
	For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies		For IP payloads, section 5.3 of [I-D.ietf-lisp-rfc6830bis] specifies
	how to handle UDP Checksums encouraging implementors to consider UDP		how to handle UDP Checksums encouraging implementors to consider UDP
	checksum usage guidelines in section 3.4 of [RFC8085] when it is		checksum usage guidelines in section 3.4 of [RFC8085] when it is
	desirable to protect UDP and LISP headers against corruption.		desirable to protect UDP and LISP headers against corruption.
	skipping to change at page 8, line 22 ¶		skipping to change at page 8, line 29 ¶
	layer errors or malicious modification of the datagram (see		layer errors or malicious modification of the datagram (see
	Section 3.4 of [RFC8085]). In deployments where such a risk exists,		Section 3.4 of [RFC8085]). In deployments where such a risk exists,
	an operator SHOULD use additional data integrity mechanisms such as		an operator SHOULD use additional data integrity mechanisms such as
	offered by IPSec.		offered by IPSec.
	An operator MAY choose to disable UDP checksum and use zero checksum		An operator MAY choose to disable UDP checksum and use zero checksum
	if LISP-GPE packet integrity is provided by other data integrity		if LISP-GPE packet integrity is provided by other data integrity
	mechanisms such as IPsec or additional checksums or if one of the		mechanisms such as IPsec or additional checksums or if one of the
	conditions in Section 4.3.1 a, b, c are met.		conditions in Section 4.3.1 a, b, c are met.
			4.3.1. UDP Zero Checksum Handling with IPv6
	By default, UDP checksum MUST be used when LISP-GPE is transported		By default, UDP checksum MUST be used when LISP-GPE is transported
	over IPv6. A tunnel endpoint MAY be configured for use with zero UDP		over IPv6. A tunnel endpoint MAY be configured for use with zero UDP
	checksum if additional requirements in Section 4.3.1 are met.		checksum if additional requirements in Section 4.3.1 are met.
	4.3.1. UDP Zero Checksum Handling with IPv6
	When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6		When LISP-GPE is used over IPv6, UDP checksum is used to protect IPv6
	headers, UDP headers and LISP-GPE headers and payload from potential		headers, UDP headers and LISP-GPE headers and payload from potential
	data corruption. As such by default LISP-GPE MUST use UDP checksum		data corruption. As such by default LISP-GPE MUST use UDP checksum
	when transported over IPv6. An operator MAY choose to configure to		when transported over IPv6. An operator MAY choose to configure to
	operate with zero UDP checksum if operating in a traffic managed		operate with zero UDP checksum if operating in a traffic managed
	controlled environment as stated in Section 4.1 if one of the		controlled environment as stated in Section 4.1 if one of the
	following conditions are met:		following conditions are met:
	a. It is known that the packet corruption is exceptionally unlikely		a. It is known that the packet corruption is exceptionally unlikely
	(perhaps based on knowledge of equipment types in their underlay		(perhaps based on knowledge of equipment types in their underlay
	skipping to change at page 9, line 46 ¶		skipping to change at page 10, line 5 ¶
	specified in [RFC6936].		specified in [RFC6936].
	The requirement to check the source IPv6 address in addition to the		The requirement to check the source IPv6 address in addition to the
	destination IPv6 address, plus the recommendation against reuse of		destination IPv6 address, plus the recommendation against reuse of
	source IPv6 addresses among LISP-GPE tunnels collectively provide		source IPv6 addresses among LISP-GPE tunnels collectively provide
	some mitigation for the absence of UDP checksum coverage of the IPv6		some mitigation for the absence of UDP checksum coverage of the IPv6
	header. A traffic-managed controlled environment that satisfies at		header. A traffic-managed controlled environment that satisfies at
	least one of three conditions listed at the beginning of this section		least one of three conditions listed at the beginning of this section
	provides additional assurance.		provides additional assurance.
	4.4. DSCP, ECN and TTL		4.4. DSCP, ECN, TTL, and 802.1Q
	When encapsulating IP (including over Ethernet) packets [RFC2983]		When encapsulating IP (including over Ethernet) packets [RFC2983]
	provides guidance for mapping DSCP between inner and outer IP		provides guidance for mapping DSCP between inner and outer IP
	headers. The Pipe model typically fits better Network		headers. The Pipe model typically fits better Network
	virtualization. The DSCP value on the tunnel header is set based on		virtualization. The DSCP value on the tunnel header is set based on
	a policy (which may be a fixed value, one based on the inner traffic		a policy (which may be a fixed value, one based on the inner traffic
	class, or some other mechanism for grouping traffic). Some aspects		class, or some other mechanism for grouping traffic). Some aspects
	of the Uniform model (which treats the inner and outer DSCP value as		of the Uniform model (which treats the inner and outer DSCP value as
	a single field by copying on ingress and egress) may also apply, such		a single field by copying on ingress and egress) may also apply, such
	as the ability to remark the inner header on tunnel egress based on		as the ability to remark the inner header on tunnel egress based on
End of changes. 19 change blocks.
	25 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/