draft-ietf-lisp-gpe-12.txt		draft-ietf-lisp-gpe-13.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: May 22, 2020 Broadcom		Expires: July 9, 2020 Broadcom
	P. Agarwal		P. Agarwal
	Innovium		Innovium
	D. Lewis		D. Lewis
	M. Smith		M. Smith
	Cisco		Cisco
	November 19, 2019		January 6, 2020
	LISP Generic Protocol Extension		LISP Generic Protocol Extension
	draft-ietf-lisp-gpe-12		draft-ietf-lisp-gpe-13
	Abstract		Abstract
	This document describes extentions to the Locator/ID Separation		This document describes extentions 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 May 22, 2020.		This Internet-Draft will expire on July 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 9 ¶		skipping to change at page 3, line 9 ¶
	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].		[I-D.ietf-lisp-rfc6830bis]. Those two features are no longer
			available when the P-bit is used. However, appropriate LISP-GPE shim
			headers can be defined to 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
	functionalities or IOAM metadata.		functionalities or IOAM metadata.
	Nonce, Map-Versioning and Locator Status Bit fields are not part of
	the LISP-GPE header. Shim headers can be used to specify features
	such as echo-noncing, map-versioning or reachability by defining
	fields of the same size, or larger, of those specified in
	[I-D.ietf-lisp-rfc6830bis].
	1.1. Conventions		1.1. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	1.2. Definition of Terms		1.2. Definition of Terms
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 19 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Instance ID/Locator-Status-Bits |		| Instance ID/Locator-Status-Bits |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: LISP Header		Figure 1: LISP Header
	3. Generic Protocol Extension for LISP (LISP-GPE)		3. Generic Protocol Extension for LISP (LISP-GPE)
	This document defines two changes to the LISP header in order to		This document defines two changes to the LISP header in order to
	support multi-protocol encapsulation: the introduction of the P-bit		support multi-protocol encapsulation: the introduction of the P-bit
	and the definition of a Next Protocol field. This is shown in		and the definition of a Next Protocol field. This document specifies
	Figure 2 and described below.		the protocol behavior when the P-bit is set to 1, no changes are
			introduced when the P-bit is set to 0. The LISP-GPE header is shown
			in Figure 2 and described below.
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Res. |I|P|K|K| Reserved | Next Protocol |		|N|L|E|V|I|P|K|K| Reserved | Next Protocol |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Instance ID |		| Instance ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: LISP-GPE Header		Figure 2: LISP-GPE Header
	Bits 0-3 and 8-23: Bits 0-3 and 8-23 of the LISP-GPE header are		P-Bit: Flag bit 5 is defined as the Next Protocol bit. The P-bit is
	Reserved. They MUST be set to zero on transmission and ignored on		set to 1 to indicate the presence of the 8 bit Next Protocol
	receipt.		field.
	Features that were implemented with bits 0-3 and 8-23 in
	[I-D.ietf-lisp-rfc6830bis], such as echo-noncing, map-versioning
	and reachability, can be implemented by defining the appropriate
	shim headers.
	Instance ID When the I-Bit is set to 1 the high-order 24 bits of the
	Instance ID field are used as an Instance ID, as specified in
	[I-D.ietf-lisp-rfc6830bis]. The low-order 8 bits are set to zero,
	as the Locator-Status-Bits feature is not supported in LISP-GPE.
	P-Bit: Flag bit 5 is defined as the Next Protocol bit.
	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] with bits N, L, E		to the definition in [I-D.ietf-lisp-rfc6830bis].
	and V set to 0.
	The P-bit is set to 1 to indicate the presence of the 8 bit Next		When the P-bit is set to 1, bits N, E, and V MUST be set zero on
	Protocol field. The combinations of bits that are allowed when		transmission and ignored on receipt. Features equivalent to those
	the P-bit is set are the same allowed by		that were implemented with bits N,E and V in
	[I-D.ietf-lisp-rfc6830bis] when bits N, L, E and V are set to 0.		[I-D.ietf-lisp-rfc6830bis], such as echo-noncing and map-
			versioning, can be implemented by defining appropriate LISP-GPE
			shim headers.
	Next Protocol: The lower 8 bits of the first 32-bit word are used to		Next Protocol: The lower 8 bits of the first 32-bit word are used to
	carry a Next Protocol. This Next Protocol field contains the		carry a Next Protocol. This Next Protocol field contains the
	protocol of the encapsulated payload packet.		protocol of the encapsulated payload packet.
	This document defines the following Next Protocol values:		This document defines the following Next Protocol values:
	0x01 : IPv4		0x01 : IPv4
	0x02 : IPv6		0x02 : IPv6
	skipping to change at page 10, line 19 ¶		skipping to change at page 10, line 19 ¶
	When encapsulating IP packets to a non LISP-GPE capable router the		When encapsulating IP packets to a non LISP-GPE capable router the
	P-bit MUST be set to 0. That is, the encapsulation format defined in		P-bit MUST be set to 0. That is, the encapsulation format defined in
	this document MUST NOT be sent to a router that has not indicated		this document MUST NOT be sent to a router that has not indicated
	that it supports this specification because such a router would		that it supports this specification because such a router would
	ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so		ignore the P-bit (as described in [I-D.ietf-lisp-rfc6830bis]) and so
	would misinterpret the other LISP header fields possibly causing		would misinterpret the other LISP header fields possibly causing
	significant errors.		significant errors.
	5.1. Detection of ETR Capabilities		5.1. Detection of ETR Capabilities
	The detection of ETR capabilities to support multiple data plane		The discovery of xTR capabilities to support LISP-GPE is out of the
	encapsulations and shim headers is out of the scope of this document.		scope of this document. Given that the applicability domain of LISP-
	Given that the applicability domain of LISP-GPE is a traffic-managed		GPE is a traffic-managed controlled environment, ITR/ETR (xTR)
	controlled environment, ITR/ETR (xTR) configuration mechanisms may be		configuration mechanisms may be used for this purpose.
	used for this purpose.
	6. IANA Considerations		6. IANA Considerations
	6.1. LISP-GPE Next Protocol Registry		6.1. LISP-GPE Next Protocol Registry
	IANA is requested to set up a registry of LISP-GPE "Next Protocol".		IANA is requested to set up a registry of LISP-GPE "Next Protocol".
	These are 8-bit values. Next Protocol values in the table below are		These are 8-bit values. Next Protocol values in the table below are
	defined in this document. New values are assigned under the		defined in this document. New values are assigned under the
	Specification Required policy [RFC8126]. The protocols that are		Specification Required policy [RFC8126]. The protocols that are
	being assigned values do not themselves need to be IETF standards		being assigned values do not themselves need to be IETF standards
	skipping to change at page 11, line 6 ¶		skipping to change at page 11, line 6 ¶
	| 0x05..0x7F | Unassigned | |		| 0x05..0x7F | Unassigned | |
	| 0x82..0xFF | Unassigned | |		| 0x82..0xFF | Unassigned | |
	+---------------+-------------+---------------+		+---------------+-------------+---------------+
	7. Security Considerations		7. Security Considerations
	LISP-GPE security considerations are similar to the LISP security		LISP-GPE security considerations are similar to the LISP security
	considerations and mitigation techniques documented in [RFC7835].		considerations and mitigation techniques documented in [RFC7835].
	LISP-GPE, as many encapsulations that use optional extensions, is		LISP-GPE, as many encapsulations that use optional extensions, is
	subject to on-path adversaries that by manipulating the g-Bit and the		subject to on-path adversaries that by manipulating the P-Bit and the
	packet itself can remove part of the payload. Typical integrity		packet itself can remove part of the payload or claim to encapsulate
	protection mechanisms (such as IPsec) SHOULD be used in combination		any protocol payload type. Typical integrity protection mechanisms
	with LISP-GPE by those protocol extensions that want to protect from		(such as IPsec) SHOULD be used in combination with LISP-GPE by those
	on-path attackers.		protocol extensions that want to protect from on-path attackers.
	With LISP-GPE, issues such as data-plane spoofing, flooding, and		With LISP-GPE, issues such as data-plane spoofing, flooding, and
	traffic redirection may depend on the particular protocol payload		traffic redirection may depend on the particular protocol payload
	encapsulated.		encapsulated.
	8. Acknowledgements and Contributors		8. Acknowledgements and Contributors
	A special thank you goes to Dino Farinacci for his guidance and		A special thank you goes to Dino Farinacci for his guidance and
	detailed review.		detailed review.
	skipping to change at page 11, line 51 ¶		skipping to change at page 11, line 51 ¶
	o Puneet Agarwal, Innovium		o Puneet Agarwal, Innovium
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-lisp-rfc6830bis]		[I-D.ietf-lisp-rfc6830bis]
	Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.		Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
	Cabellos-Aparicio, "The Locator/ID Separation Protocol		Cabellos-Aparicio, "The Locator/ID Separation Protocol
	(LISP)", draft-ietf-lisp-rfc6830bis-27 (work in progress),		(LISP)", draft-ietf-lisp-rfc6830bis-28 (work in progress),
	June 2019.		November 2019.
	[IEEE.802.1Q_2014]		[IEEE.802.1Q_2014]
	IEEE, "IEEE Standard for Local and metropolitan area		IEEE, "IEEE Standard for Local and metropolitan area
	networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,		networks--Bridges and Bridged Networks", IEEE 802.1Q-2014,
	DOI 10.1109/ieeestd.2014.6991462, December 2014,		DOI 10.1109/ieeestd.2014.6991462, December 2014,
	<http://ieeexplore.ieee.org/servlet/		<http://ieeexplore.ieee.org/servlet/
	opac?punumber=6991460>.		opac?punumber=6991460>.
	[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,
	skipping to change at page 12, line 28 ¶		skipping to change at page 12, line 28 ¶
	Notification", RFC 6040, DOI 10.17487/RFC6040, November		Notification", RFC 6040, DOI 10.17487/RFC6040, November
	2010, <https://www.rfc-editor.org/info/rfc6040>.		2010, <https://www.rfc-editor.org/info/rfc6040>.
	9.2. Informative References		9.2. Informative References
	[I-D.brockners-ippm-ioam-vxlan-gpe]		[I-D.brockners-ippm-ioam-vxlan-gpe]
	Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,		Brockners, F., Bhandari, S., Govindan, V., Pignataro, C.,
	Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A.,		Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A.,
	Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE		Gafni, B., Lapukhov, P., and M. Spiegel, "VXLAN-GPE
	Encapsulation for In-situ OAM Data", draft-brockners-ippm-		Encapsulation for In-situ OAM Data", draft-brockners-ippm-
	ioam-vxlan-gpe-02 (work in progress), July 2019.		ioam-vxlan-gpe-03 (work in progress), November 2019.
	[I-D.ietf-tsvwg-ecn-encap-guidelines]		[I-D.ietf-tsvwg-ecn-encap-guidelines]
	Briscoe, B., Kaippallimalil, J., and P. Thaler,		Briscoe, B., Kaippallimalil, J., and P. Thaler,
	"Guidelines for Adding Congestion Notification to		"Guidelines for Adding Congestion Notification to
	Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-		Protocols that Encapsulate IP", draft-ietf-tsvwg-ecn-
	encap-guidelines-13 (work in progress), May 2019.		encap-guidelines-13 (work in progress), May 2019.
	[I-D.lemon-vxlan-lisp-gpe-gbp]		[I-D.lemon-vxlan-lisp-gpe-gbp]
	Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group		Lemon, J., Maino, F., Smith, M., and A. Isaac, "Group
	Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon-		Policy Encoding with VXLAN-GPE and LISP-GPE", draft-lemon-
End of changes. 16 change blocks.
	49 lines changed or deleted		36 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/