draft-ietf-intarea-gue-02.txt		draft-ietf-intarea-gue-03.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 October 28, 2017 Huawei USA		Expires November 11, 2017 Huawei USA
	O. Zia		O. Zia
	Microsoft		Microsoft
	April 26, 2017		May 10, 2017
	Generic UDP Encapsulation		Generic UDP Encapsulation
	draft-ietf-intarea-gue-02		draft-ietf-intarea-gue-03
	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 October 28, 2017.		This Internet-Draft will expire on November 11, 2017.
	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 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	5.9. Congestion control . . . . . . . . . . . . . . . . . . . . 21		5.9. Congestion control . . . . . . . . . . . . . . . . . . . . 21
	5.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 22		5.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 22
	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 Consideration . . . . . . . . . . . . . . . . . . . . . . 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 version number . . . . . . . . . . . . . . . . . . . . 28
	8.3. Control types . . . . . . . . . . . . . . . . . . . . . . . 28		8.3. Control types . . . . . . . . . . . . . . . . . . . . . . . 28
	8.4. Flag-fields . . . . . . . . . . . . . . . . . . . . . . . . 28		8.4. Flag-fields . . . . . . . . . . . . . . . . . . . . . . . . 28
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 29		10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
	10.2. Informative References . . . . . . . . . . . . . . . . . . 30		10.2. Informative References . . . . . . . . . . . . . . . . . . 30
	Appendix A: NIC processing for GUE . . . . . . . . . . . . . . . . 33		Appendix A: NIC processing for GUE . . . . . . . . . . . . . . . . 33
	A.1. Receive multi-queue . . . . . . . . . . . . . . . . . . . . 33		A.1. Receive multi-queue . . . . . . . . . . . . . . . . . . . . 33
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 27 ¶
	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.
	[GUEEXTENS] specifies a set of core extensions and [GUE4NVO3] defines		[GUEEXTENS] specifies a set of core extensions.
	an extension for using GUE with network virtualization.
	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
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 12 ¶
	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 the
	total header length in bytes. All GUE headers are a multiple of		total header length in bytes. All GUE headers are a multiple of
	four bytes in length. Maximum header length is 128 bytes.		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 C-bit		control message type for the payload (section 3.2.2). When the
	is not set, the field holds the Internet protocol number for the		C-bit is not set, the field holds the Internet protocol number
	encapsulated packet in the payload (section 3.2.1). The control		for the encapsulated packet in the payload (section 3.2.1). The
	message or encapsulated packet begins at the offset provided by		control message or encapsulated packet begins at the offset
	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
	flag bits MUST be set to zero on transmission.		flag bits MUST be set to zero on transmission.
	o Extension Fields: Optional fields whose presence is indicated by		o Extension Fields: Optional fields whose presence is indicated by
	corresponding flags.		corresponding flags.
	o Private data: Optional private data block (see section 3.4). If		o Private data: Optional private data block (see section 3.4). If
	the private block is present, it immediately follows that last		the private block is present, it immediately follows that last
	skipping to change at page 10, line 50 ¶		skipping to change at page 10, line 50 ¶
	3.3. Flags and extension fields		3.3. Flags and extension fields
	Flags and associated extension fields are the primary mechanism of		Flags and associated extension fields are the primary mechanism of
	extensibility in GUE. As mentioned in section 3.1, GUE header flags		extensibility in GUE. As mentioned in section 3.1, GUE header flags
	indicate the presence of optional extension fields in the GUE header.		indicate the presence of optional extension fields in the GUE header.
	[GUEXTENS] defines a basic set of GUE extensions.		[GUEXTENS] defines a basic set of GUE extensions.
	3.3.1. Requirements		3.3.1. Requirements
	There are sixteen flag bits in the GUE header. Some flags indicate		There are sixteen flag bits in the GUE header. Flags may indicate
	presence of an extension fields. The size of an extension field		presence of an extension fields. The size of an extension field
	indicated by a flag MUST be fixed.		indicated by a flag MUST be fixed.
	Flags can be paired together to allow different lengths for an		Flags can be paired together to allow different lengths for an
	extension field. For example, if two flag bits are paired, a field		extension field. For example, if two flag bits are paired, a field
	can possibly be three different lengths-- that is bit value of 00		can possibly be three different lengths-- that is bit value of 00
	indicates no field present; 01, 10, and 11 indicate three possible		indicates no field present; 01, 10, and 11 indicate three possible
	lengths for the field. Regardless of how flag bits are paired, the		lengths for the field. Regardless of how flag bits are paired, the
	lengths and offsets of optional fields corresponding to a set of		lengths and offsets of optional fields corresponding to a set of
	flags MUST be well defined.		flags MUST be well defined.
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 38 ¶
	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
	of flags.		of flags.
	3.3.2. Example GUE header with extension fields		3.3.2. Example GUE header with extension fields
	An example GUE header for a data message encapsulating an IPv4 packet		An example GUE header for a data message encapsulating an IPv4 packet
	and containing the VNID and Security extension fields (both defined		and containing the Group Identifier and Security extension fields
	in [GUEXTENS]) is shown below:		(both defined in [GUEXTENS]) is shown 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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0 |0| 3 | 94 |1|0 0 1| 0 |		| 0 |0| 3 | 94 |1|0 0 1| 0 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| VNID |		| Group Identifier |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ Security +		+ Security +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	In the above example, the first flag bit is set which indicates that		In the above example, the first flag bit is set which indicates that
	the VNID extension is present which is a 32 bit field. The second		the Group Identifier extension is present which is a 32 bit field.
	through fourth bits of the flags are paired flags that indicate the		The second through fourth bits of the flags are paired flags that
	presence of a security field with seven possible sizes. In this		indicate the presence of a Security field with seven possible sizes.
	example 001 indicates a sixty-four bit security field.		In this example 001 indicates a sixty-four bit security field.
	3.4. Private data		3.4. Private data
	An implementation MAY use private data for its own use. The private		An implementation MAY use private data for its own use. The private
	data immediately follows the last field in the GUE header and is not		data immediately follows the last field in the GUE header and is not
	a fixed length. This data is considered part of the GUE header and		a fixed length. This data is considered part of the GUE header and
	MUST be accounted for in header length (Hlen). The length of the		MUST be accounted for in header length (Hlen). The length of the
	private data MUST be a multiple of four and is determined by		private data MUST be a multiple of four and is determined by
	subtracting the offset of private data in the GUE header from the		subtracting the offset of private data in the GUE header from the
	header length. Specifically:		header length. Specifically:
	skipping to change at page 16, line 34 ¶		skipping to change at page 16, line 34 ¶
	packets. In this case the encapsulator and decapsulator nodes are the		packets. In this case the encapsulator and decapsulator nodes are the
	tunnel endpoints. These could be routers that provide network tunnels		tunnel endpoints. These could be routers that provide network tunnels
	on behalf of communicating hosts.		on behalf of communicating hosts.
	5.2. Transport layer encapsulation		5.2. Transport layer encapsulation
	When encapsulating layer 4 packets, the encapsulator and decapsulator		When encapsulating layer 4 packets, the encapsulator and decapsulator
	should be co-resident with the hosts. In this case, the encapsulation		should be co-resident with the hosts. In this case, the encapsulation
	headers are inserted between the IP header and the transport packet.		headers are inserted between the IP header and the transport packet.
	The addresses in the IP header refer to both the endpoints of the		The addresses in the IP header refer to both the endpoints of the
	encapsulation and the endpoints for terminating the the transport		encapsulation and the endpoints for terminating the transport
	protocol. Note that the transport layer ports in the encapsulated		protocol. Note that the transport layer ports in the encapsulated
	packet are independent of the UDP ports in the outer packet.		packet are independent of the UDP ports in the outer packet.
	Details about performing transport layer encapsulation are discussed		Details about performing transport layer encapsulation are discussed
	in [TOU].		in [TOU].
	5.3. Encapsulator operation		5.3. Encapsulator operation
	Encapsulators create GUE data messages, set the fields of the UDP		Encapsulators create GUE data messages, set the fields of the UDP
	header, set flags and optional extension fields in the GUE header,		header, set flags and optional extension fields in the GUE header,
	skipping to change at page 17, line 32 ¶		skipping to change at page 17, line 32 ¶
	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.
	5.4.1. Processing a received data message		5.4.1. Processing a received data message
	If a valid data message is received, the UDP headers are removed from		If a valid data message is received, the UDP header and GUE header
	the packet. The outer IP header remains intact and the next protocol		are removed from the packet. The outer IP header remains intact and
	in the IP header is set to the protocol from the proto field in the		the next protocol in the IP header is set to the protocol from the
	GUE header. The resulting packet is then resubmitted into the		proto field in the GUE header. The resulting packet is then
	protocol stack to process that packet as though it was received with		resubmitted into the protocol stack to process that packet as though
	the protocol in the GUE header.		it was received with the protocol in the GUE header.
	As an example, consider that a data message is received where GUE		As an example, consider that a data message is received where GUE
	encapsulates an IP packet. In this case proto field in the GUE header		encapsulates an IP packet. In this case proto field in the GUE header
	is set 94 for IPIP:		is set 94 for IPIP:
	+-------------------------------------+		+-------------------------------------+
	| IP header (next proto = 17,UDP) |		| IP header (next proto = 17,UDP) |
	|-------------------------------------|		|-------------------------------------|
	| UDP |		| UDP |
	|-------------------------------------|		|-------------------------------------|
	skipping to change at page 20, line 36 ¶		skipping to change at page 20, line 36 ¶
	described in [GUEEXTENS] assuming there are no other mechanisms used		described in [GUEEXTENS] 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 sending over paths subject to packet corruption. If verification		be traversing paths subject to packet corruption. If verification of
	of a non-zero checksum fails, a decapsulator lacks the capability to		a non-zero checksum fails, a decapsulator lacks the capability to
	verify a non-zero checksum, or a packet with a zero-checksum was		verify a non-zero checksum, or a packet with a zero-checksum was
	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
	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 [7510], and Generic UDP Encapsulation for IP Tunneling (GRE		MPLS/UDP [RFC7510], and Generic UDP Encapsulation for IP Tunneling
	over UDP)[RFC8086]. Generic UDP tunneling [GUT] is a proposal similar		(GRE over UDP)[RFC8086]. Generic UDP tunneling [GUT] is a proposal
	to GUE in that it aims to tunnel packets of IP protocols over UDP.		similar to GUE in that it aims to tunnel packets of IP 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 32 ¶		skipping to change at page 26, line 32 ¶
	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		For instance a TCAM can be use to parse a known set of N flags
	where the number of entries in the TCAM is 2^N.		where the number of entries in the TCAM is 2^N.
	For comparison, the number of TCAM entries needed to parse a set		By comparison, the number of TCAM entries needed to parse a set
	of N arbitrarily ordered TLVS is approximately e*N!.		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
	skipping to change at page 27, line 8 ¶		skipping to change at page 27, line 8 ¶
	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.
	8. IANA Consideration		8. IANA Considerations
	8.1. UDP source port		8.1. UDP source port
	A user UDP port number assignment for GUE has been assigned:		A user UDP port number assignment for GUE has been assigned:
	Service Name: gue		Service Name: gue
	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
	skipping to change at page 29, line 8 ¶		skipping to change at page 29, line 8 ¶
	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].		assigned in accordance with RFC Required policy [RFC5226].
	+-------------+--------------+-------------+--------------------+		+-------------+--------------+-------------+--------------------+
	| Flags bits | Field size | Description | Reference |		| Flags bits | Field size | Description | Reference |
	+-------------+--------------+-------------+--------------------+		+-------------+--------------+-------------+--------------------+
	| Bit 0 | 4 bytes | VNID | [GUE4NVO3] |		| Bit 0 | 4 bytes | Group | [GUEEXTENS] |
			| | | identifier | |
	| | | | |		| | | | |
	| Bit 1..3 | 001->8 bytes | Security | [GUEEXTENS] |		| Bit 1..3 | 001->8 bytes | Security | [GUEEXTENS] |
	| | 010->16 bytes| | |		| | 010->16 bytes| | |
	| | 011->32 bytes| | |		| | 011->32 bytes| | |
	| | | | |		| | | | |
	| Bit 4 | 8 bytes | Fragmen- | [GUEEXTENS] |		| Bit 4 | 8 bytes | Fragmen- | [GUEEXTENS] |
	| | | tation | |		| | | tation | |
	| | | | |		| | | | |
	| Bit 5 | 4 bytes | Payload | [GUEEXTENS] |		| Bit 5 | 4 bytes | Payload | [GUEEXTENS] |
	| | | transform | |		| | | transform | |
End of changes. 18 change blocks.
	35 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/