< draft-ietf-intarea-gue-04.txt		draft-ietf-intarea-gue-05.txt >
	Internet Area WG T. Herbert		Internet Area WG T. Herbert
	Internet-Draft Quantonium		Internet-Draft Quantonium
	Intended status: Standard track L. Yong		Intended status: Standard track L. Yong
	Expires November 19, 2017 Huawei USA		Expires June 30, 2017 Huawei USA
	O. Zia		O. Zia
	Microsoft		Microsoft
	May 18, 2017		December 30, 2017
	Generic UDP Encapsulation		Generic UDP Encapsulation
	draft-ietf-intarea-gue-04		draft-ietf-intarea-gue-05
	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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 35 ¶		skipping to change at page 1, line 35 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on November 11, 2017.		This Internet-Draft will expire on June 30, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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 3, line 24 ¶		skipping to change at page 3, line 24 ¶
	constructed. GUE is extensible by allowing optional data fields as		constructed. GUE is extensible by allowing optional data fields as
	part of the encapsulation, and is generic in that it can encapsulate		part of the encapsulation, and is generic in that it can encapsulate
	packets of various IP protocols.		packets of various IP protocols.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Terminology and acronyms . . . . . . . . . . . . . . . . . 5		1.1. Terminology and acronyms . . . . . . . . . . . . . . . . . 5
	1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6		1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6
	2. Base packet format . . . . . . . . . . . . . . . . . . . . . . 7		2. Base packet format . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. GUE version . . . . . . . . . . . . . . . . . . . . . . . . 7		2.1. GUE variant . . . . . . . . . . . . . . . . . . . . . . . . 7
	3. Version 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Variant 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Header format . . . . . . . . . . . . . . . . . . . . . . . 8		3.1. Header format . . . . . . . . . . . . . . . . . . . . . . . 8
	3.2. Proto/ctype field . . . . . . . . . . . . . . . . . . . . . 9		3.2. Proto/ctype field . . . . . . . . . . . . . . . . . . . . . 9
	3.2.1 Proto field . . . . . . . . . . . . . . . . . . . . . . 9		3.2.1 Proto field . . . . . . . . . . . . . . . . . . . . . . 9
	3.2.2 Ctype field . . . . . . . . . . . . . . . . . . . . . . 10		3.2.2 Ctype field . . . . . . . . . . . . . . . . . . . . . . 10
	3.3. Flags and extension fields . . . . . . . . . . . . . . . . 10		3.3. Flags and extension fields . . . . . . . . . . . . . . . . 10
	3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . . 10		3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . . 10
	3.3.2. Example GUE header with extension fields . . . . . . . 11		3.3.2. Example GUE header with extension fields . . . . . . . 11
	3.4. Private data . . . . . . . . . . . . . . . . . . . . . . . 12		3.4. Private data . . . . . . . . . . . . . . . . . . . . . . . 12
	3.5. Message types . . . . . . . . . . . . . . . . . . . . . . . 12		3.5. Message types . . . . . . . . . . . . . . . . . . . . . . . 12
	3.5.1. Control messages . . . . . . . . . . . . . . . . . . . 12		3.5.1. Control messages . . . . . . . . . . . . . . . . . . . 12
	3.5.2. Data messages . . . . . . . . . . . . . . . . . . . . . 13		3.5.2. Data messages . . . . . . . . . . . . . . . . . . . . . 13
	3.6. Hiding the transport layer protocol number . . . . . . . . 13		3.6. Hiding the transport layer protocol number . . . . . . . . 13
	4. Version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		4. Variant 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.1. Direct encapsulation of IPv4 . . . . . . . . . . . . . . . 14		4.1. Direct encapsulation of IPv4 . . . . . . . . . . . . . . . 14
	4.2. Direct encapsulation of IPv6 . . . . . . . . . . . . . . . 14		4.2. Direct encapsulation of IPv6 . . . . . . . . . . . . . . . 15
	5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 15		5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Network tunnel encapsulation . . . . . . . . . . . . . . . 16		5.1. Network tunnel encapsulation . . . . . . . . . . . . . . . 16
	5.2. Transport layer encapsulation . . . . . . . . . . . . . . . 16		5.2. Transport layer encapsulation . . . . . . . . . . . . . . . 16
	5.3. Encapsulator operation . . . . . . . . . . . . . . . . . . 16		5.3. Encapsulator operation . . . . . . . . . . . . . . . . . . 16
	5.4. Decapsulator operation . . . . . . . . . . . . . . . . . . 17		5.4. Decapsulator operation . . . . . . . . . . . . . . . . . . 17
	5.4.1. Processing a received data message . . . . . . . . . . 17		5.4.1. Processing a received data message . . . . . . . . . . 17
	5.4.2. Processing a received control message . . . . . . . . . 18		5.4.2. Processing a received control message . . . . . . . . . 18
	5.5. Router and switch operation . . . . . . . . . . . . . . . . 18		5.5. Router and switch operation . . . . . . . . . . . . . . . . 18
	5.6. Middlebox interactions . . . . . . . . . . . . . . . . . . 18		5.6. Middlebox interactions . . . . . . . . . . . . . . . . . . 18
	5.6.1. Inferring connection semantics . . . . . . . . . . . . 19		5.6.1. Inferring connection semantics . . . . . . . . . . . . 19
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	5.11. Flow entropy for ECMP . . . . . . . . . . . . . . . . . . 22		5.11. Flow entropy for ECMP . . . . . . . . . . . . . . . . . . 22
	5.11.1. Flow classification . . . . . . . . . . . . . . . . . 22		5.11.1. Flow classification . . . . . . . . . . . . . . . . . 22
	5.11.2. Flow entropy properties . . . . . . . . . . . . . . . 23		5.11.2. Flow entropy properties . . . . . . . . . . . . . . . 23
	5.12 Negotiation of acceptable flags and extension fields . . . 24		5.12 Negotiation of acceptable flags and extension fields . . . 24
	6. Motivation for GUE . . . . . . . . . . . . . . . . . . . . . . 24		6. Motivation for GUE . . . . . . . . . . . . . . . . . . . . . . 24
	6.1. Benefits of GUE . . . . . . . . . . . . . . . . . . . . . . 24		6.1. Benefits of GUE . . . . . . . . . . . . . . . . . . . . . . 24
	6.2 Comparison of GUE to other encapsulations . . . . . . . . . 25		6.2 Comparison of GUE to other encapsulations . . . . . . . . . 25
	7. Security Considerations . . . . . . . . . . . . . . . . . . . . 26		7. Security Considerations . . . . . . . . . . . . . . . . . . . . 26
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27
	8.1. UDP source port . . . . . . . . . . . . . . . . . . . . . . 27		8.1. UDP source port . . . . . . . . . . . . . . . . . . . . . . 27
	8.2. GUE version number . . . . . . . . . . . . . . . . . . . . 28		8.2. GUE variant number . . . . . . . . . . . . . . . . . . . . 28
	8.3. Control types . . . . . . . . . . . . . . . . . . . . . . . 28		8.3. Control types . . . . . . . . . . . . . . . . . . . . . . . 28
	8.4. Flag-fields . . . . . . . . . . . . . . . . . . . . . . . . 28		8.4. Flag-fields . . . . . . . . . . . . . . . . . . . . . . . . 28
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 29		10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	10.2. Informative References . . . . . . . . . . . . . . . . . . 29		10.2. Informative References . . . . . . . . . . . . . . . . . . 30
	Appendix A: NIC processing for GUE . . . . . . . . . . . . . . . . 32		Appendix A: NIC processing for GUE . . . . . . . . . . . . . . . . 32
	A.1. Receive multi-queue . . . . . . . . . . . . . . . . . . . . 32		A.1. Receive multi-queue . . . . . . . . . . . . . . . . . . . . 32
	A.2. Checksum offload . . . . . . . . . . . . . . . . . . . . . 33		A.2. Checksum offload . . . . . . . . . . . . . . . . . . . . . 33
	A.2.1. Transmit checksum offload . . . . . . . . . . . . . . . 33		A.2.1. Transmit checksum offload . . . . . . . . . . . . . . . 33
	A.2.2. Receive checksum offload . . . . . . . . . . . . . . . 34		A.2.2. Receive checksum offload . . . . . . . . . . . . . . . 34
	A.3. Transmit Segmentation Offload . . . . . . . . . . . . . . . 34		A.3. Transmit Segmentation Offload . . . . . . . . . . . . . . . 34
	A.4. Large Receive Offload . . . . . . . . . . . . . . . . . . . 35		A.4. Large Receive Offload . . . . . . . . . . . . . . . . . . . 35
	Appendix B: Implementation considerations . . . . . . . . . . . . 36		Appendix B: Implementation considerations . . . . . . . . . . . . 36
	B.1. Priveleged ports . . . . . . . . . . . . . . . . . . . . . 36		B.1. Priveleged ports . . . . . . . . . . . . . . . . . . . . . 36
	B.2. Setting flow entropy as a route selector . . . . . . . . . 36		B.2. Setting flow entropy as a route selector . . . . . . . . . 36
	skipping to change at page 5, line 26 ¶		skipping to change at page 5, line 26 ¶
	GUE provides an extensible header format for including optional data		GUE provides an extensible header format for including optional data
	in the encapsulation header. This data potentially covers items such		in the encapsulation header. This data potentially covers items such
	as the virtual networking identifier, security data for validating or		as the virtual networking identifier, security data for validating or
	authenticating the GUE header, congestion control data, etc. GUE also		authenticating the GUE header, congestion control data, etc. GUE also
	allows private optional data in the encapsulation header. This		allows private optional data in the encapsulation header. This
	feature can be used by a site or implementation to define local		feature can be used by a site or implementation to define local
	custom optional data, and allows experimentation of options that may		custom optional data, and allows experimentation of options that may
	eventually become standard.		eventually become standard.
	This document does not define any specific GUE extensions.		This document does not define any specific GUE extensions. [GUEEXTEN]
	[GUEEXTENS] specifies a set of core extensions.		specifies a set of core extensions.
	The motivation for the GUE protocol is described in section 6.		The motivation for the GUE protocol is described in section 6.
	1.1. Terminology and acronyms		1.1. Terminology and acronyms
	GUE Generic UDP Encapsulation		GUE Generic UDP Encapsulation
	GUE Header A variable length protocol header that is composed		GUE Header A variable length protocol header that is composed
	of a primary four byte header and zero or more four		of a primary four byte header and zero or more four
	byte words for optional header data		byte words for optional header data
	GUE packet A UDP/IP packet that contains a GUE header and GUE		GUE packet A UDP/IP packet that contains a GUE header and GUE
	payload within the UDP payload		payload within the UDP payload
	Encapsulator A network node that encapsulates a packet in GUE		GUE variant A version of the GUE protocol or an alternate form
			of a version
			Encapsulator A network node that encapsulates packets in GUE
	Decapsulator A network node that decapsulates and processes		Decapsulator A network node that decapsulates and processes
	packets encapsulated in GUE		packets encapsulated in GUE
	Data message An encapsulated packet in the GUE payload that is		Data message An encapsulated packet in the GUE payload that is
	addressed to the protocol stack for an associated		addressed to the protocol stack for an associated
	protocol		protocol
	Control message A formatted message in the GUE payload that is		Control message A formatted message in the GUE payload that is
	implicitly addressed to the decapsulator to monitor		implicitly addressed to the decapsulator to monitor
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 31 ¶
	|-------------------------------|		|-------------------------------|
	| |		| |
	| Encapsulated packet |		| Encapsulated packet |
	| or control message |		| or control message |
	| |		| |
	+-------------------------------+		+-------------------------------+
	The GUE header is variable length as determined by the presence of		The GUE header is variable length as determined by the presence of
	optional extension fields.		optional extension fields.
	2.1. GUE version		2.1. GUE variant
	The first two bits of the GUE header contain the GUE protocol version		The first two bits of the GUE header contain the GUE protocol variant
	number. The rest of the fields after the GUE version number are		number. The variant number can indicate the version of the GUE
	defined based on the version number. Versions 0 and 1 are described		protocol as well as alternate forms of a version.
	in this specification; versions 2 and 3 are reserved.
	3. Version 0		Variants 0 and 1 are described in this specification; variants 2 and
			3 are reserved.
	Version 0 of GUE defines a generic extensible format to encapsulate		3. Variant 0
	packets by Internet protocol number.
			Variant 0 indicates version 0 of GUE. This variant defines a generic
			extensible format to encapsulate packets by Internet protocol number.
	3.1. Header format		3.1. Header format
	The header format for version 0 of GUE in UDP is:		The header format for variant 0 of GUE in UDP is:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	| Source port | Destination port | |		| Source port | Destination port | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
	| Length | Checksum | |		| Length | Checksum | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	| 0 |C| Hlen | Proto/ctype | Flags |		| 0 |C| Hlen | Proto/ctype | Flags |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 8, line 49 ¶		skipping to change at page 8, line 49 ¶
	set to the GUE assigned port number, 6080.		set to the GUE assigned port number, 6080.
	o Length: Canonical length of the UDP packet (length of UDP header		o Length: Canonical length of the UDP packet (length of UDP header
	and payload).		and payload).
	o Checksum: Standard UDP checksum (handling is described in		o Checksum: Standard UDP checksum (handling is described in
	section 5.7).		section 5.7).
	The GUE header consists of:		The GUE header consists of:
	o Ver: GUE protocol version (0).		o Variant: 0 indicates GUE protocol version 0 with a header.
	o C: C-bit: When set indicates a control message, not set		o C: C-bit: When set indicates a control message, not set
	indicates a data message.		indicates a data message.
	o Hlen: Length in 32-bit words of the GUE header, including		o Hlen: Length in 32-bit words of the GUE header, including
	optional extension fields but not the first four bytes of the		optional extension fields but not the first four bytes of the
	header. Computed as (header_len - 4) / 4 where header_len is the		header. Computed as (header_len - 4) / 4, where header_len is
	total header length in bytes. All GUE headers are a multiple of		the total header length in bytes. All GUE headers are a multiple
	four bytes in length. Maximum header length is 128 bytes.		of four bytes in length. Maximum header length is 128 bytes.
	o Proto/ctype: When the C-bit is set, this field contains a		o Proto/ctype: When the C-bit is set, this field contains a
	control message type for the payload (section 3.2.2). When the		control message type for the payload (section 3.2.2). When the
	C-bit is not set, the field holds the Internet protocol number		C-bit is not set, the field holds the Internet protocol number
	for the encapsulated packet in the payload (section 3.2.1). The		for the encapsulated packet in the payload (section 3.2.1). The
	control message or encapsulated packet begins at the offset		control message or encapsulated packet begins at the offset
	provided by Hlen.		provided by Hlen.
	o Flags: Header flags that may be allocated for various purposes		o Flags: Header flags that may be allocated for various purposes
	and may indicate presence of extension fields. Undefined header		and may indicate presence of extension fields. Undefined header
	skipping to change at page 11, line 22 ¶		skipping to change at page 11, line 22 ¶
	flags MUST be well defined.		flags MUST be well defined.
	Extension fields are placed in order of the flags. New flags are to		Extension fields are placed in order of the flags. New flags are to
	be allocated from high to low order bit contiguously without holes.		be allocated from high to low order bit contiguously without holes.
	Flags allow random access, for instance to inspect the field		Flags allow random access, for instance to inspect the field
	corresponding to the Nth flag bit, an implementation only considers		corresponding to the Nth flag bit, an implementation only considers
	the previous N-1 flags to determine the offset. Flags after the Nth		the previous N-1 flags to determine the offset. Flags after the Nth
	flag are not pertinent in calculating the offset of the Nth flag.		flag are not pertinent in calculating the offset of the Nth flag.
	Random access of flags and fields permits processing of optional		Random access of flags and fields permits processing of optional
	extensions in an order that is independent of their position in the		extensions in an order that is independent of their position in the
	packet. The processing order of extensions defined in [GUEEXTENS]		packet. The processing order of extensions defined in [GUEEXTEN]
	demonstrates this property.		demonstrates this property.
	Flags (or paired flags) are idempotent such that new flags MUST NOT		Flags (or paired flags) are idempotent such that new flags MUST NOT
	cause reinterpretation of old flags. Also, new flags MUST NOT alter		cause reinterpretation of old flags. Also, new flags MUST NOT alter
	interpretation of other elements in the GUE header nor how the		interpretation of other elements in the GUE header nor how the
	message is parsed (for instance, in a data message the proto/ctype		message is parsed (for instance, in a data message the proto/ctype
	field always holds an IP protocol number as an invariant).		field always holds an IP protocol number as an invariant).
	The set of available flags can be extended in the future by defining		The set of available flags can be extended in the future by defining
	a "flag extensions bit" that refers to a field containing a new set		a "flag extensions bit" that refers to a field containing a new set
	skipping to change at page 13, line 36 ¶		skipping to change at page 13, line 36 ¶
	The payload of a data message is interpreted as an encapsulated		The payload of a data message is interpreted as an encapsulated
	packet of an Internet protocol indicated in the proto/ctype field.		packet of an Internet protocol indicated in the proto/ctype field.
	The packet immediately follows the GUE header.		The packet immediately follows the GUE header.
	3.6. Hiding the transport layer protocol number		3.6. Hiding the transport layer protocol number
	The GUE header indicates the Internet protocol of the encapsulated		The GUE header indicates the Internet protocol of the encapsulated
	packet. A protocol number is either contained in the Proto/ctype		packet. A protocol number is either contained in the Proto/ctype
	field of the primary GUE header or in the Payload Type field of a GUE		field of the primary GUE header or in the Payload Type field of a GUE
	Transform extension field (used to encrypt the payload with DTLS,		Transform extension field (used to encrypt the payload with DTLS,
	[GUEEXTENS]). If the transport protocol number needs to be hidden		[GUEEXTEN]). If the transport protocol number needs to be hidden from
	from the network, then a trivial destination options can be used.		the network, then a trivial destination options can be used.
	The PadN destination option [RFC2460] can be used to encode the		The PadN destination option [RFC2460] can be used to encode the
	transport protocol as a next header of an extension header (and		transport protocol as a next header of an extension header (and
	maintain alignment of encapsulated transport headers). The		maintain alignment of encapsulated transport headers). The
	Proto/ctype field or Payload Type field of the GUE Transform field is		Proto/ctype field or Payload Type field of the GUE Transform field is
	set to 60 to indicate that the first encapsulated header is a		set to 60 to indicate that the first encapsulated header is a
	destination options extension header.		destination options extension header.
	The format of the extension header is below:		The format of the extension header is below:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | 2 | 1 | 0 |		| Next Header | 2 | 1 | 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	For IPv4, it is permitted in GUE to used this precise destination		For IPv4, it is permitted in GUE to used this precise destination
	option to contain the obfuscated protocol number. In this case next		option to contain the obfuscated protocol number. In this case next
	header MUST refer to a valid IP protocol for IPv4. No other extension		header MUST refer to a valid IP protocol for IPv4. No other extension
	headers or destination options are permitted with IPv4.		headers or destination options are permitted with IPv4.
	4. Version 1		4. Variant 1
	Version 1 of GUE allows direct encapsulation of IPv4 and IPv6 in UDP.		Variant 1 of GUE allows direct encapsulation of IPv4 and IPv6 in UDP.
	In this version there is no GUE header; a UDP packet carries an IP		In this varinant there is no GUE header; a UDP packet carries an IP
	packet. The first two bits of the UDP payload for GUE are the GUE		packet. The first two bits of the UDP payload for GUE are the GUE
	version and coincide with the first two bits of the version number in		variant and coincide with the first two bits of the version number in
	the IP header. The first two version bits of IPv4 and IPv6 are 01, so		the IP header. The first two version bits of IPv4 and IPv6 are 01, so
	we use GUE version 1 for direct IP encapsulation which makes two bits		we use GUE variant 1 for direct IP encapsulation which makes two bits
	of GUE version to also be 01.		of GUE variant to also be 01.
	This technique is effectively a means to compress out the GUE header		This technique is effectively a means to compress out the version 0
	when encapsulating IPv4 or IPv6 packets and there are no flags or		GUE header when encapsulating IPv4 or IPv6 packets and there are no
	extension fields present. This method is compatible to use on the		flags or extension fields present. This method is compatible to use
	same port number as packets with the GUE header (GUE version 0		on the same port number as packets with the GUE header (GUE variant 0
	packets). This technique saves encapsulation overhead on costly links		packets). This technique saves encapsulation overhead on costly links
	for the common use of IP encapsulation, and also obviates the need to		for the common use of IP encapsulation, and also obviates the need to
	allocate a separate port number for IP-over-UDP encapsulation.		allocate a separate port number for IP-over-UDP encapsulation.
	4.1. Direct encapsulation of IPv4		4.1. Direct encapsulation of IPv4
	The format for encapsulating IPv4 directly in UDP is:		The format for encapsulating IPv4 directly in UDP is:
	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 14, line 48 ¶		skipping to change at page 14, line 48 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identification |Flags| Fragment Offset |		| Identification |Flags| Fragment Offset |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Time to Live | Protocol | Header Checksum |		| Time to Live | Protocol | Header Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Source IPv4 Address |		| Source IPv4 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Destination IPv4 Address |		| Destination IPv4 Address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Note that 0100 value IP version field express the GUE version as 1		Note that the 0100 value in the first four bits of the the UDP
	(bits 01) and IP version as 4 (bits 0100).		payload expresses the GUE variant as 1 (bits 01) and IP version as 4
			(bits 0100).
	4.2. Direct encapsulation of IPv6		4.2. Direct encapsulation of IPv6
	The format for encapsulating IPv6 directly in UDP is demonstrated		The format for encapsulating IPv6 directly in UDP is demonstrated
	below:		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
	| Source port | Destination port | |		| Source port | Destination port | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
	| Length | Checksum | |		| Length | Checksum | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	skipping to change at page 15, line 35 ¶		skipping to change at page 15, line 38 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ Destination IPv6 Address +		+ Destination IPv6 Address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Note that 0110 value IP version field expresses the GUE version as 1		Note that the 0110 value in the first four bits of the the UDP
	(bits 01) and IP version as 6 (bits 0110).		payload expresses the GUE variant as 1 (bits 01) and IP version as 6
			(bits 0110).
	5. Operation		5. Operation
	The figure below illustrates the use of GUE encapsulation between two		The figure below illustrates the use of GUE encapsulation between two
	hosts. Host 1 is sending packets to Host 2. An encapsulator performs		hosts. Host 1 is sending packets to Host 2. An encapsulator performs
	encapsulation of packets from Host 1. These encapsulated packets		encapsulation of packets from Host 1. These encapsulated packets
	traverse the network as UDP packets. At the decapsulator, packets are		traverse the network as UDP packets. At the decapsulator, packets are
	decapsulated and sent on to Host 2. Packet flow in the reverse		decapsulated and sent on to Host 2. Packet flow in the reverse
	direction need not be symmetric; GUE encapsulation is not required in		direction need not be symmetric; GUE encapsulation is not required in
	the reverse path.		the reverse path.
	skipping to change at page 17, line 19 ¶		skipping to change at page 17, line 19 ¶
	encapsualated in GUE then diffserv interaction [RFC2983] and ECN		encapsualated in GUE then diffserv interaction [RFC2983] and ECN
	propagation for tunnels [RFC6040] SHOULD be followed.		propagation for tunnels [RFC6040] SHOULD be followed.
	5.4. Decapsulator operation		5.4. Decapsulator operation
	A decapsulator performs decapsulation of GUE packets. A decapsulator		A decapsulator performs decapsulation of GUE packets. A decapsulator
	is addressed by the outer destination IP address of a GUE packet.		is addressed by the outer destination IP address of a GUE packet.
	The decapsulator validates packets, including fields of the GUE		The decapsulator validates packets, including fields of the GUE
	header.		header.
	If a decapsulator receives a GUE packet with an unsupported version,		If a decapsulator receives a GUE packet with an unsupported variant,
	unknown flag, bad header length (too small for included extension		unknown flag, bad header length (too small for included extension
	fields), unknown control message type, bad protocol number, an		fields), unknown control message type, bad protocol number, an
	unsupported payload type, or an otherwise malformed header, it MUST		unsupported payload type, or an otherwise malformed header, it MUST
	drop the packet. Such events MAY be logged subject to configuration		drop the packet. Such events MAY be logged subject to configuration
	and rate limiting of logging messages. No error message is returned		and rate limiting of logging messages. No error message is returned
	back to the encapsulator. Note that set flags in a GUE header that		back to the encapsulator. Note that set flags in a GUE header that
	are unknown to a decapsulator MUST NOT be ignored. If a GUE packet is		are unknown to a decapsulator MUST NOT be ignored. If a GUE packet is
	received by a decapsulator with unknown flags, the packet MUST be		received by a decapsulator with unknown flags, the packet MUST be
	dropped.		dropped.
	skipping to change at page 18, line 21 ¶		skipping to change at page 18, line 21 ¶
	| IP header and packet |		| IP header and packet |
	+-------------------------------------+		+-------------------------------------+
	This packet is then resubmitted into the protocol stack to be		This packet is then resubmitted into the protocol stack to be
	processed as an IPIP packet.		processed as an IPIP packet.
	5.4.2. Processing a received control message		5.4.2. Processing a received control message
	If a valid control message is received, the packet MUST be processed		If a valid control message is received, the packet MUST be processed
	as a control message. The specific processing to be performed depends		as a control message. The specific processing to be performed depends
	on the ctype in the GUE header.		on the value in the ctype field of the GUE header.
	5.5. Router and switch operation		5.5. Router and switch operation
	Routers and switches SHOULD forward GUE packets as standard UDP/IP		Routers and switches SHOULD forward GUE packets as standard UDP/IP
	packets. The outer five-tuple should contain sufficient information		packets. The outer five-tuple should contain sufficient information
	to perform flow classification corresponding to the flow of the inner		to perform flow classification corresponding to the flow of the inner
	packet. A router does not normally need to parse a GUE header, and		packet. A router does not normally need to parse a GUE header, and
	none of the flags or extension fields in the GUE header are expected		none of the flags or extension fields in the GUE header are expected
	to affect routing. In cases where the outer five-tuple does not		to affect routing. In cases where the outer five-tuple does not
	provide sufficient entropy for flow classification, for instance UDP		provide sufficient entropy for flow classification, for instance UDP
	skipping to change at page 20, line 5 ¶		skipping to change at page 20, line 5 ¶
	on devices incapable of computing the UDP checksum for packet. This		on devices incapable of computing the UDP checksum for packet. This
	section discusses the requirements around checksum and alternatives		section discusses the requirements around checksum and alternatives
	that might be used when an endpoint does not support UDP checksum.		that might be used when an endpoint does not support UDP checksum.
	5.7.1. Requirements		5.7.1. Requirements
	One of the following requirements MUST be met:		One of the following requirements MUST be met:
	o UDP checksums are enabled (for IPv4 or IPv6).		o UDP checksums are enabled (for IPv4 or IPv6).
	o The GUE header checksum is used (defined in [GUEEXTENS]).		o The GUE header checksum is used (defined in [GUEEXTEN]).
	o Use zero UDP checksums. This is always permissible with IPv4; in		o Use zero UDP checksums. This is always permissible with IPv4; in
	IPv6, they can only be used in accordance with applicable		IPv6, they can only be used in accordance with applicable
	requirements in [RFC8086], [RFC6935], and [RFC6936].		requirements in [RFC8086], [RFC6935], and [RFC6936].
	5.7.2. UDP Checksum with IPv4		5.7.2. UDP Checksum with IPv4
	For UDP in IPv4, the UDP checksum MUST be processed as specified in		For UDP in IPv4, the UDP checksum MUST be processed as specified in
	[RFC768] and [RFC1122] for both transmit and receive. An		[RFC768] and [RFC1122] for both transmit and receive. An
	encapsulator MAY set the UDP checksum to zero for performance or		encapsulator MAY set the UDP checksum to zero for performance or
	implementation considerations. The IPv4 header includes a checksum		implementation considerations. The IPv4 header includes a checksum
	that protects against mis-delivery of the packet due to corruption		that protects against mis-delivery of the packet due to corruption
	of IP addresses. The UDP checksum potentially provides protection		of IP addresses. The UDP checksum potentially provides protection
	against corruption of the UDP header, GUE header, and GUE payload.		against corruption of the UDP header, GUE header, and GUE payload.
	Enabling or disabling the use of checksums is a deployment		Enabling or disabling the use of checksums is a deployment
	consideration that should take into account the risk and effects of		consideration that should take into account the risk and effects of
	packet corruption, and whether the packets in the network are		packet corruption, and whether the packets in the network are
	already adequately protected by other, possibly stronger mechanisms		already adequately protected by other, possibly stronger mechanisms
	such as the Ethernet CRC. If an encapsulator sets a zero UDP		such as the Ethernet CRC. If an encapsulator sets a zero UDP
	checksum for IPv4, it SHOULD use the GUE header checksum as		checksum for IPv4, it SHOULD use the GUE header checksum as
	described in [GUEEXTENS] assuming there are no other mechanisms used		described in [GUEEXTEN] assuming there are no other mechanisms used
	to protect the GUE packet.		to protect the GUE packet.
	When a decapsulator receives a packet, the UDP checksum field MUST		When a decapsulator receives a packet, the UDP checksum field MUST
	be processed. If the UDP checksum is non-zero, the decapsulator MUST		be processed. If the UDP checksum is non-zero, the decapsulator MUST
	verify the checksum before accepting the packet. By default, a		verify the checksum before accepting the packet. By default, a
	decapsulator SHOULD accept UDP packets with a zero checksum. A node		decapsulator SHOULD accept UDP packets with a zero checksum. A node
	MAY be configured to disallow zero checksums per [RFC1122].		MAY be configured to disallow zero checksums per [RFC1122].
	Configuration of zero checksums can be selective. For instance, zero		Configuration of zero checksums can be selective. For instance, zero
	checksums might be disallowed from certain hosts that are known to		checksums might be disallowed from certain hosts that are known to
	be traversing paths subject to packet corruption. If verification of		be traversing paths subject to packet corruption. If verification of
	skipping to change at page 20, line 49 ¶		skipping to change at page 20, line 49 ¶
	received and the decapsulator is configured to disallow, the packet		received and the decapsulator is configured to disallow, the packet
	MUST be dropped.		MUST be dropped.
	5.7.3. UDP Checksum with IPv6		5.7.3. UDP Checksum with IPv6
	In IPv6, there is no checksum in the IPv6 header that protects		In IPv6, there is no checksum in the IPv6 header that protects
	against mis-delivery due to address corruption. Therefore, when GUE		against mis-delivery due to address corruption. Therefore, when GUE
	is used over IPv6, either the UDP checksum or the GUE header		is used over IPv6, either the UDP checksum or the GUE header
	checksum SHOULD be used unless there are alternative mechanisms in		checksum SHOULD be used unless there are alternative mechanisms in
	use that protect against misdelivery. The UDP checksum and GUE		use that protect against misdelivery. The UDP checksum and GUE
	header checksum SHOULD not be used at the same time since that would		header checksum SHOULD NOT be used at the same time since that would
	be mostly redundant.		be mostly redundant.
	If neither the UDP checksum or the GUE header checksum is used, then		If neither the UDP checksum or the GUE header checksum is used, then
	the requirements for using zero IPv6 UDP checksums in [RFC6935] and		the requirements for using zero IPv6 UDP checksums in [RFC6935] and
	[RFC6936] MUST be met.		[RFC6936] MUST be met.
	When a decapsulator receives a packet, the UDP checksum field MUST		When a decapsulator receives a packet, the UDP checksum field MUST
	be processed. If the UDP checksum is non-zero, the decapsulator MUST		be processed. If the UDP checksum is non-zero, the decapsulator MUST
	verify the checksum before accepting the packet. By default a		verify the checksum before accepting the packet. By default a
	decapsulator MUST only accept UDP packets with a zero checksum if		decapsulator MUST only accept UDP packets with a zero checksum if
	skipping to change at page 21, line 30 ¶		skipping to change at page 21, line 30 ¶
	(encapsulation of layer 2 or layer 3 packets) SHOULD be followed.		(encapsulation of layer 2 or layer 3 packets) SHOULD be followed.
	Details are described in MTU and Fragmentation Issues with In-the-		Details are described in MTU and Fragmentation Issues with In-the-
	Network Tunneling [RFC4459].		Network Tunneling [RFC4459].
	If a packet is fragmented before encapsulation in GUE, all the		If a packet is fragmented before encapsulation in GUE, all the
	related fragments MUST be encapsulated using the same UDP source		related fragments MUST be encapsulated using the same UDP source
	port. An operator SHOULD set MTU to account for encapsulation		port. An operator SHOULD set MTU to account for encapsulation
	overhead and reduce the likelihood of fragmentation.		overhead and reduce the likelihood of fragmentation.
	Alternative to IP fragmentation, the GUE fragmentation extension can		Alternative to IP fragmentation, the GUE fragmentation extension can
	be used. GUE fragmentation is described in [GUEEXTENS].		be used. GUE fragmentation is described in [GUEEXTEN].
	5.9. Congestion control		5.9. Congestion control
	Per requirements of [RFC5405], if the IP traffic encapsulated with		Per requirements of [RFC5405], if the IP traffic encapsulated with
	GUE implements proper congestion control no additional mechanisms		GUE implements proper congestion control no additional mechanisms
	should be required.		should be required.
	In the case that the encapsulated traffic does not implement any or		In the case that the encapsulated traffic does not implement any or
	sufficient control, or it is not known whether a transmitter will		sufficient control, or it is not known whether a transmitter will
	consistently implement proper congestion control, then congestion		consistently implement proper congestion control, then congestion
	control at the encapsulation layer MUST be provided per [RFC5405].		control at the encapsulation layer MUST be provided per [RFC5405].
	Note that this case applies to a significant use case in network		Note that this case applies to a significant use case in network
	virtualization in which guests run third party networking stacks		virtualization in which guests run third party networking stacks
	that cannot be implicitly trusted to implement conformant congestion		that cannot be implicitly trusted to implement conformant congestion
	control.		control.
	Out of band mechanisms such as rate limiting, Managed Circuit		Out of band mechanisms such as rate limiting, Managed Circuit
	Breaker [CIRCBRK], or traffic isolation MAY be used to provide		Breaker [RFC8084], or traffic isolation MAY be used to provide
	rudimentary congestion control. For finer-grained congestion control		rudimentary congestion control. For finer-grained congestion control
	that allows alternate congestion control algorithms, reaction time		that allows alternate congestion control algorithms, reaction time
	within an RTT, and interaction with ECN, in-band mechanisms might be		within an RTT, and interaction with ECN, in-band mechanisms might be
	warranted.		warranted.
	5.10. Multicast		5.10. Multicast
	GUE packets can be multicast to decapsulators using a multicast		GUE packets can be multicast to decapsulators using a multicast
	destination address in the encapsulating IP headers. Each receiving		destination address in the encapsulating IP headers. Each receiving
	host will decapsulate the packet independently following normal		host will decapsulate the packet independently following normal
	skipping to change at page 24, line 17 ¶		skipping to change at page 24, line 17 ¶
	packet, SPI from an ESP packet, or other flow related state in		packet, SPI from an ESP packet, or other flow related state in
	the encapsulator that is not necessarily conveyed in the packet.		the encapsulator that is not necessarily conveyed in the packet.
	o The assignment function for flow entropy SHOULD be randomly		o The assignment function for flow entropy SHOULD be randomly
	seeded to mitigate denial of service attacks. The seed SHOULD be		seeded to mitigate denial of service attacks. The seed SHOULD be
	changed periodically.		changed periodically.
	5.12 Negotiation of acceptable flags and extension fields		5.12 Negotiation of acceptable flags and extension fields
	An encapsulator and decapsulator need to achieve agreement about GUE		An encapsulator and decapsulator need to achieve agreement about GUE
	parameters will be used in communications. Parameters include GUE		parameters that will be used in communications. Parameters include
	version, flags and extension fields that can be used, security		supported GUE variants, flags and extension fields that can be used,
	algorithms and keys, supported protocols and control messages, etc.		security algorithms and keys, supported protocols and control
	This document proposes different general methods to accomplish this,		messages, etc. This document proposes different general methods to
	however the details of implementing these are considered out of		accomplish this, however the details of implementing these are
	scope.		considered out of scope.
	General methods for this are:		General methods for this are:
	o Configuration. The parameters used for a tunnel are configured		o Configuration. The parameters used for a tunnel are configured
	at each endpoint.		at each endpoint.
	o Negotiation. A tunnel negotiation can be performed. This could		o Negotiation. A tunnel negotiation can be performed. This could
	be accomplished in-band of GUE using control messages or private		be accomplished in-band of GUE using control messages or private
	data.		data.
	o Via a control plane. Parameters for communicating with a tunnel		o Via a control plane. Parameters for communicating with a tunnel
	endpoint can be set in a control plane protocol (such as that		endpoint can be set in a control plane protocol (such as that
	needed for nvo3).		needed for network virtualization).
	o Via security negotiation. Use of security typically implies a		o Via security negotiation. Use of security typically implies a
	key exchange between endpoints. Other GUE parameters may be		key exchange between endpoints. Other GUE parameters may be
	conveyed as part of that process.		conveyed as part of that process.
	6. Motivation for GUE		6. Motivation for GUE
	This section presents the motivation for GUE with respect to other		This section presents the motivation for GUE with respect to other
	encapsulation methods.		encapsulation methods.
	skipping to change at page 25, line 38 ¶		skipping to change at page 25, line 38 ¶
	provides layer 2 tunneling of Ethernet frames over IP. GRE [RFC2784],		provides layer 2 tunneling of Ethernet frames over IP. GRE [RFC2784],
	MPLS [RFC4023], and L2TP [RFC2661] provide methods for tunneling		MPLS [RFC4023], and L2TP [RFC2661] provide methods for tunneling
	layer 2 and layer 3 packets over IP. NVGRE [RFC7637] and VXLAN		layer 2 and layer 3 packets over IP. NVGRE [RFC7637] and VXLAN
	[RFC7348] are proposals for encapsulation of layer 2 packets for		[RFC7348] are proposals for encapsulation of layer 2 packets for
	network virtualization. IPIP [RFC2003] and Generic packet tunneling		network virtualization. IPIP [RFC2003] and Generic packet tunneling
	in IPv6 [RFC2473] provide methods for tunneling IP packets over IP.		in IPv6 [RFC2473] provide methods for tunneling IP packets over IP.
	Several proposals exist for encapsulating packets over UDP including		Several proposals exist for encapsulating packets over UDP including
	ESP over UDP [RFC3948], TCP directly over UDP [TCPUDP], VXLAN		ESP over UDP [RFC3948], TCP directly over UDP [TCPUDP], VXLAN
	[RFC7348], LISP [RFC6830] which encapsulates layer 3 packets,		[RFC7348], LISP [RFC6830] which encapsulates layer 3 packets,
	MPLS/UDP [RFC7510], and Generic UDP Encapsulation for IP Tunneling		MPLS/UDP [RFC7510], GENEVE [GENEVE], and Generic UDP Encapsulation
	(GRE over UDP)[RFC8086]. Generic UDP tunneling [GUT] is a proposal		for IP Tunneling (GRE over UDP)[RFC8086]. Generic UDP tunneling [GUT]
	similar to GUE in that it aims to tunnel packets of IP protocols over		is a proposal similar to GUE in that it aims to tunnel packets of IP
	UDP.		protocols over UDP.
	GUE has the following discriminating features:		GUE has the following discriminating features:
	o UDP encapsulation leverages specialized network device		o UDP encapsulation leverages specialized network device
	processing for efficient transport. The semantics for using the		processing for efficient transport. The semantics for using the
	UDP source port for flow entropy as input to ECMP are defined in		UDP source port for flow entropy as input to ECMP are defined in
	section 5.11.		section 5.11.
	o GUE permits encapsulation of arbitrary IP protocols, which		o GUE permits encapsulation of arbitrary IP protocols, which
	includes layer 2 3, and 4 protocols.		includes layer 2 3, and 4 protocols.
	skipping to change at page 26, line 27 ¶		skipping to change at page 26, line 27 ¶
	to parse the full encapsulation header.		to parse the full encapsulation header.
	o Private data in the encapsulation header allows local		o Private data in the encapsulation header allows local
	customization and experimentation while being compatible with		customization and experimentation while being compatible with
	processing in network nodes (routers and middleboxes).		processing in network nodes (routers and middleboxes).
	o GUE includes both data messages (encapsulation of packets) and		o GUE includes both data messages (encapsulation of packets) and
	control messages (such as OAM).		control messages (such as OAM).
	o The flags-field model facilitates efficient implementation of		o The flags-field model facilitates efficient implementation of
	extensibility in hardware.		extensibility in hardware. For instance, a TCAM can be use to
			parse a known set of N flags where the number of entries in the
	For instance a TCAM can be use to parse a known set of N flags		TCAM is 2^N. By comparison, the number of TCAM entries needed to
	where the number of entries in the TCAM is 2^N.		parse a set of N arbitrarily ordered TLVS is approximately e*N!.
	By comparison, the number of TCAM entries needed to parse a set
	of N arbitrarily ordered TLVS is approximately e*N!.
	7. Security Considerations		7. Security Considerations
	There are two important considerations of security with respect to		There are two important considerations of security with respect to
	GUE.		GUE.
	o Authentication and integrity of the GUE header.		o Authentication and integrity of the GUE header.
	o Authentication, integrity, and confidentiality of the GUE		o Authentication, integrity, and confidentiality of the GUE
	payload.		payload.
	GUE security is provided by extensions for security defined in		GUE security is provided by extensions for security defined in
	[GUEEXTENS]. These extensions include methods to authenticate the GUE		[GUEEXTEN]. These extensions include methods to authenticate the GUE
	header and encrypt the GUE payload.		header and encrypt the GUE payload.
	The GUE header can be authenticated using a security extension for an		The GUE header can be authenticated using a security extension for an
	HMAC. Securing the GUE payload can be accomplished use of the GUE		HMAC. Securing the GUE payload can be accomplished use of the GUE
	Payload Transform. This extension can be used to perform DTLS in the		Payload Transform. This extension can be used to perform DTLS in the
	payload of a GUE packet to encrypt the payload.		payload of a GUE packet to encrypt the payload.
	A hash function for computing flow entropy (section 5.11) SHOULD be		A hash function for computing flow entropy (section 5.11) SHOULD be
	randomly seeded to mitigate some possible denial service attacks.		randomly seeded to mitigate some possible denial service attacks.
	skipping to change at page 28, line 5 ¶		skipping to change at page 28, line 5 ¶
	Transport Protocol(s): UDP		Transport Protocol(s): UDP
	Assignee: Tom Herbert <tom@herbertland.com>		Assignee: Tom Herbert <tom@herbertland.com>
	Contact: Tom Herbert <tom@herbertland.com>		Contact: Tom Herbert <tom@herbertland.com>
	Description: Generic UDP Encapsulation		Description: Generic UDP Encapsulation
	Reference: draft-herbert-gue		Reference: draft-herbert-gue
	Port Number: 6080		Port Number: 6080
	Service Code: N/A		Service Code: N/A
	Known Unauthorized Uses: N/A		Known Unauthorized Uses: N/A
	Assignment Notes: N/A		Assignment Notes: N/A
	8.2. GUE version number		8.2. GUE variant number
	IANA is requested to set up a registry for the GUE version number.		IANA is requested to set up a registry for the GUE variant number.
	The GUE version number is 2 bits containing four possible values.		The GUE variant number is 2 bits containing four possible values.
	This document defines version 0 and 1. New values are assigned in		This document defines version 0 and 1. New values are assigned in
	accordance with RFC Required policy [RFC5226].		accordance with RFC Required policy [RFC5226].
	+----------------+-------------+---------------+		+----------------+----------------+---------------+
	| Version number | Description | Reference |		| Variant number | Description | Reference |
	+----------------+-------------+---------------+		+----------------+----------------+---------------+
	| 0 | Version 0 | This document |		| 0 | GUE Version 0 | This document |
	| | | |		| | with header | |
	| 1 | Version 1 | This document |		| | | |
	| | | |		| 1 | GUE Version 0 | This document |
	| 2..3 | Unassigned | |		| | with direct IP | |
	+----------------+-------------+---------------+		| | encapsulation | |
			| | | |
			| 2..3 | Unassigned | |
			+----------------+----------------+---------------+
	8.3. Control types		8.3. Control types
	IANA is requested to set up a registry for the GUE control types.		IANA is requested to set up a registry for the GUE control types.
	Control types are 8 bit values. New values for control types 1-127		Control types are 8 bit values. New values for control types 1-127
	are assigned in accordance with RFC Required policy [RFC5226].		are assigned in accordance with RFC Required policy [RFC5226].
	+----------------+------------------+---------------+		+----------------+------------------+---------------+
	| Control type | Description | Reference |		| Control type | Description | Reference |
	+----------------+------------------+---------------+		+----------------+------------------+---------------+
	skipping to change at page 28, line 48 ¶		skipping to change at page 28, line 51 ¶
	8.4. Flag-fields		8.4. Flag-fields
	IANA is requested to create a "GUE flag-fields" registry to allocate		IANA is requested to create a "GUE flag-fields" registry to allocate
	flags and extension fields used with GUE. This shall be a registry of		flags and extension fields used with GUE. This shall be a registry of
	bit assignments for flags, length of extension fields for		bit assignments for flags, length of extension fields for
	corresponding flags, and descriptive strings. There are sixteen bits		corresponding flags, and descriptive strings. There are sixteen bits
	for primary GUE header flags (bit number 0-15). New values are		for primary GUE header flags (bit number 0-15). New values are
	assigned in accordance with RFC Required policy [RFC5226]. New flags		assigned in accordance with RFC Required policy [RFC5226]. New flags
	should be allocated from high to low order bit contiguously without		should be allocated from high to low order bit contiguously without
	holes. [GUEXTENS] requests in initial set of flag assignments.		holes. [GUEXTENS] requests an initial set of flag assignments.
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank David Liu, Erik Nordmark, Fred		The authors would like to thank David Liu, Erik Nordmark, Fred
	Templin, Adrian Farrel, Bob Briscoe, and Murray Kucherawy for		Templin, Adrian Farrel, Bob Briscoe, and Murray Kucherawy for
	valuable input on this draft.		valuable input on this draft.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	skipping to change at page 31, line 50 ¶		skipping to change at page 32, line 5 ¶
	[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,		[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
	"Encapsulating MPLS in IP or Generic Routing Encapsulation		"Encapsulating MPLS in IP or Generic Routing Encapsulation
	(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,		(GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
	<http://www.rfc-editor.org/info/rfc4023>.		<http://www.rfc-editor.org/info/rfc4023>.
	[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,		[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
	G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",		G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
	RFC 2661, DOI 10.17487/RFC2661, August 1999,		RFC 2661, DOI 10.17487/RFC2661, August 1999,
	<http://www.rfc-editor.org/info/rfc2661>.		<http://www.rfc-editor.org/info/rfc2661>.
	[GUEEXTENS] Herbert, T., Yong, L., and Templin, F., "Extensions for		[RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP
			208, RFC 8084, DOI 10.17487/RFC8084, March 2017,
			<https://www.rfc-editor.org/info/rfc8084>.
			[GUEEXTEN] Herbert, T., Yong, L., and Templin, F., "Extensions for
	Generic UDP Encapsulation" draft-herbert-gue-extensions-00		Generic UDP Encapsulation" draft-herbert-gue-extensions-00
	[GUE4NVO3] Yong, L., Herbert, T., Zia, O., "Generic UDP		[GUE4NVO3] Yong, L., Herbert, T., Zia, O., "Generic UDP Encapsulation
	Encapsulation (GUE) for Network Virtualization Overlay"		(GUE) for Network Virtualization Overlay" draft-hy-nvo3-
	draft-hy-nvo3-gue-4-nvo-03		gue-4-nvo-03
	[GUESEC] Yong, L., Herbert, T., "Generic UDP Encapsulation (GUE) for		[GUESEC] Yong, L., Herbert, T., "Generic UDP Encapsulation (GUE)
	Secure Transport" draft-hy-gue-4-secure-transport-03		for Secure Transport" draft-hy-gue-4-secure-transport-03
	[TCPUDP] Chesire, S., Graessley, J., and McGuire, R.,		[TCPUDP] Chesire, S., Graessley, J., and McGuire, R.,
	"Encapsulation of TCP and other Transport Protocols over		"Encapsulation of TCP and other Transport Protocols over
	UDP" draft-cheshire-tcp-over-udp-00		UDP" draft-cheshire-tcp-over-udp-00
	[TOU] Herbert, T., "Transport layer protocols over UDP" draft-		[TOU] Herbert, T., "Transport layer protocols over UDP" draft-
	herbert-transports-over-udp-00		herbert-transports-over-udp-00
			[GENEVE] Gross, J., Ed., Ganga, I. Ed., and Sridhar, T., "Geneve:
			Generic Network Virtualization Encapsulation", draft-ietf-
			nvo3-geneve-05
	[GUT] Manner, J., Varia, N., and Briscoe, B., "Generic UDP		[GUT] Manner, J., Varia, N., and Briscoe, B., "Generic UDP
	Tunnelling (GUT) draft-manner-tsvwg-gut-02.txt"		Tunnelling (GUT) draft-manner-tsvwg-gut-02.txt"
	[CIRCBRK] Fairhurst, G., "Network Transport Circuit Breakers",
	draft-ietf-tsvwg-circuit-breaker-15
	[LCO] Cree, E., https://www.kernel.org/doc/Documentation/		[LCO] Cree, E., https://www.kernel.org/doc/Documentation/
	networking/checksum-offloads.txt		networking/checksum-offloads.txt
	Appendix A: NIC processing for GUE		Appendix A: NIC processing for GUE
	This appendix provides some guidelines for Network Interface Cards		This appendix provides some guidelines for Network Interface Cards
	(NICs) to implement common offloads and accelerations to support GUE.		(NICs) to implement common offloads and accelerations to support GUE.
	Note that most of this discussion is generally applicable to other		Note that most of this discussion is generally applicable to other
	methods of UDP based encapsulation.		methods of UDP based encapsulation.
	skipping to change at page 33, line 43 ¶		skipping to change at page 33, line 51 ¶
	In the case of GUE, the checksum for an encapsulated transport layer		In the case of GUE, the checksum for an encapsulated transport layer
	packet, a TCP packet for instance, can be offloaded by setting the		packet, a TCP packet for instance, can be offloaded by setting the
	appropriate checksum parameters.		appropriate checksum parameters.
	NICs typically can offload only one transmit checksum per packet, so		NICs typically can offload only one transmit checksum per packet, so
	simultaneously offloading both an inner transport packet's checksum		simultaneously offloading both an inner transport packet's checksum
	and the outer UDP checksum is likely not possible.		and the outer UDP checksum is likely not possible.
	If an encapsulator is co-resident with a host, then checksum offload		If an encapsulator is co-resident with a host, then checksum offload
	may be performed using remote checksum offload (described in		may be performed using remote checksum offload (described in
	[GUEEXTENS]). Remote checksum offload relies on NIC offload of the		[GUEEXTEN]). Remote checksum offload relies on NIC offload of the
	simple UDP/IP checksum which is commonly supported even in legacy		simple UDP/IP checksum which is commonly supported even in legacy
	devices. In remote checksum offload, the outer UDP checksum is set		devices. In remote checksum offload, the outer UDP checksum is set
	and the GUE header includes an option indicating the start and offset		and the GUE header includes an option indicating the start and offset
	of the inner "offloaded" checksum. The inner checksum is initialized		of the inner "offloaded" checksum. The inner checksum is initialized
	to the pseudo header checksum. When a decapsulator receives a GUE		to the pseudo header checksum. When a decapsulator receives a GUE
	packet with the remote checksum offload option, it completes the		packet with the remote checksum offload option, it completes the
	offload operation by determining the packet checksum from the		offload operation by determining the packet checksum from the
	indicated start point to the end of the packet, and then adds this		indicated start point to the end of the packet, and then adds this
	into the checksum field at the offset given in the option. Computing		into the checksum field at the offset given in the option. Computing
	the checksum from the start to end of packet is efficient if		the checksum from the start to end of packet is efficient if
End of changes. 51 change blocks.
	93 lines changed or deleted		106 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/