draft-ietf-intarea-gue-08.txt		draft-ietf-intarea-gue-09.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 April 6, 2020 Independent		Expires April 28, 2020 Independent
	O. Zia		O. Zia
	Microsoft		Microsoft
	October 4, 2019		October 26, 2019
	Generic UDP Encapsulation		Generic UDP Encapsulation
	draft-ietf-intarea-gue-08		draft-ietf-intarea-gue-09
	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 April 6, 2020.		This Internet-Draft will expire on April 28, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 31 ¶		skipping to change at page 3, line 31 ¶
	1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . . 5
	1.2. Terminology and acronyms . . . . . . . . . . . . . . . . . 6		1.2. Terminology and acronyms . . . . . . . . . . . . . . . . . 6
	1.3. Requirements Language . . . . . . . . . . . . . . . . . . . 7		1.3. Requirements Language . . . . . . . . . . . . . . . . . . . 7
	2. Base packet format . . . . . . . . . . . . . . . . . . . . . . 8		2. Base packet format . . . . . . . . . . . . . . . . . . . . . . 8
	2.1. GUE variant . . . . . . . . . . . . . . . . . . . . . . . . 8		2.1. GUE variant . . . . . . . . . . . . . . . . . . . . . . . . 8
	3. Variant 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3. Variant 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Header format . . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Header format . . . . . . . . . . . . . . . . . . . . . . . 9
	3.2. Proto/ctype field . . . . . . . . . . . . . . . . . . . . . 10		3.2. Proto/ctype field . . . . . . . . . . . . . . . . . . . . . 10
	3.2.1. Proto field . . . . . . . . . . . . . . . . . . . . . . 10		3.2.1. Proto field . . . . . . . . . . . . . . . . . . . . . . 10
	3.2.2. Ctype field . . . . . . . . . . . . . . . . . . . . . . 10		3.2.2. Ctype field . . . . . . . . . . . . . . . . . . . . . . 10
	3.3. Flags and extension fields . . . . . . . . . . . . . . . . 11		3.3. Flags and extension fields . . . . . . . . . . . . . . . . 12
	3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . . 11		3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . . 12
	3.3.2. Example GUE header with extension fields . . . . . . . 12		3.3.2. Example GUE header with extension fields . . . . . . . 12
	3.4. Surplus space . . . . . . . . . . . . . . . . . . . . . . . 12		3.4. Surplus space . . . . . . . . . . . . . . . . . . . . . . . 13
	3.5. Message types . . . . . . . . . . . . . . . . . . . . . . . 13		3.5. Message types . . . . . . . . . . . . . . . . . . . . . . . 13
	3.5.1. Control messages . . . . . . . . . . . . . . . . . . . 13		3.5.1. Control messages . . . . . . . . . . . . . . . . . . . 13
	3.5.2. Data messages . . . . . . . . . . . . . . . . . . . . . 13		3.5.2. Data messages . . . . . . . . . . . . . . . . . . . . . 14
	4. Variant 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		4. Variant 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.1. Direct encapsulation of IPv4 . . . . . . . . . . . . . . . 14		4.1. Direct encapsulation of IPv4 . . . . . . . . . . . . . . . 15
	4.2. Direct encapsulation of IPv6 . . . . . . . . . . . . . . . 15		4.2. Direct encapsulation of IPv6 . . . . . . . . . . . . . . . 16
	5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.1. Network tunnel encapsulation . . . . . . . . . . . . . . . 16		5.1. Network tunnel encapsulation . . . . . . . . . . . . . . . 17
	5.2. Transport layer encapsulation . . . . . . . . . . . . . . . 16		5.2. Transport layer encapsulation . . . . . . . . . . . . . . . 17
	5.3. Encapsulator operation . . . . . . . . . . . . . . . . . . 17		5.3. Encapsulator operation . . . . . . . . . . . . . . . . . . 18
	5.4. Decapsulator operation . . . . . . . . . . . . . . . . . . 17		5.4. Decapsulator operation . . . . . . . . . . . . . . . . . . 18
	5.4.1. Processing a received data message . . . . . . . . . . 17		5.4.1. Processing a received data message . . . . . . . . . . 18
	5.4.2. Processing a received control message . . . . . . . . . 18		5.4.2. Processing a received control message . . . . . . . . . 19
	5.5. Middlebox inspection . . . . . . . . . . . . . . . . . . . 18		5.5. Middlebox inspection . . . . . . . . . . . . . . . . . . . 19
	5.6. Router and switch operation . . . . . . . . . . . . . . . . 19		5.6. Router and switch operation . . . . . . . . . . . . . . . . 20
	5.6.1. Connection semantics . . . . . . . . . . . . . . . . . 19		5.6.1. Connection semantics . . . . . . . . . . . . . . . . . 20
	5.6.2. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . 20		5.6.2. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	5.7. MTU and fragmentation . . . . . . . . . . . . . . . . . . . 20		5.7. MTU and fragmentation . . . . . . . . . . . . . . . . . . . 21
	5.8. UDP Checksum Handling . . . . . . . . . . . . . . . . . . . 20		5.8. UDP Checksum Handling . . . . . . . . . . . . . . . . . . . 21
	5.8.1. UDP Checksum with IPv4 . . . . . . . . . . . . . . . . 20		5.8.1. UDP Checksum with IPv4 . . . . . . . . . . . . . . . . 21
	5.8.2. UDP Checksum with IPv6 . . . . . . . . . . . . . . . . 21		5.8.2. UDP Checksum with IPv6 . . . . . . . . . . . . . . . . 22
	5.9. Congestion Considerations . . . . . . . . . . . . . . . . . 24		5.9. Congestion Considerations . . . . . . . . . . . . . . . . . 25
	5.9.1. GUE tunnels . . . . . . . . . . . . . . . . . . . . . . 24		5.9.1. GUE tunnels . . . . . . . . . . . . . . . . . . . . . . 25
	5.9.2 Transport layer encapsulation . . . . . . . . . . . . . 25		5.9.2 Transport layer encapsulation . . . . . . . . . . . . . 26
	5.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 25		5.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 26
	5.11. Flow entropy for ECMP . . . . . . . . . . . . . . . . . . 25		5.11. Flow entropy for ECMP . . . . . . . . . . . . . . . . . . 26
	5.11.1. Flow classification . . . . . . . . . . . . . . . . . 25		5.11.1. Flow classification . . . . . . . . . . . . . . . . . 26
	5.11.2. Flow entropy properties . . . . . . . . . . . . . . . 26		5.11.2. Flow entropy properties . . . . . . . . . . . . . . . 27
	5.12. Negotiation of acceptable flags and extension fields . . . 27		5.12. Negotiation of acceptable flags and extension fields . . . 28
	6. Motivation for GUE . . . . . . . . . . . . . . . . . . . . . . 27		6. Motivation for GUE . . . . . . . . . . . . . . . . . . . . . . 28
	6.1. Benefits of GUE . . . . . . . . . . . . . . . . . . . . . . 27		6.1. Benefits of GUE . . . . . . . . . . . . . . . . . . . . . . 28
	6.2. Comparison of GUE to other encapsulations . . . . . . . . . 28		6.2. Comparison of GUE to other encapsulations . . . . . . . . . 29
	7. Security Considerations . . . . . . . . . . . . . . . . . . . . 30		7. Security Considerations . . . . . . . . . . . . . . . . . . . . 31
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 30		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 31
	8.1. UDP source port . . . . . . . . . . . . . . . . . . . . . . 30		8.1. UDP source port . . . . . . . . . . . . . . . . . . . . . . 31
	8.2. GUE variant number . . . . . . . . . . . . . . . . . . . . 31		8.2. GUE variant number . . . . . . . . . . . . . . . . . . . . 32
	8.3. Control types . . . . . . . . . . . . . . . . . . . . . . . 31		8.3. Control types . . . . . . . . . . . . . . . . . . . . . . . 32
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31		8.4 Control Type Experimental Identifiers . . . . . . . . . . . 32
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 32		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
	10.2. Informative References . . . . . . . . . . . . . . . . . . 33		10.1. Normative References . . . . . . . . . . . . . . . . . . . 34
	Appendix A: NIC processing for GUE . . . . . . . . . . . . . . . . 36		10.2. Informative References . . . . . . . . . . . . . . . . . . 35
	A.1. Receive multi-queue . . . . . . . . . . . . . . . . . . . . 36		Appendix A: NIC processing for GUE . . . . . . . . . . . . . . . . 38
	A.2. Checksum offload . . . . . . . . . . . . . . . . . . . . . 36		A.1. Receive multi-queue . . . . . . . . . . . . . . . . . . . . 38
	A.2.1. Transmit checksum offload . . . . . . . . . . . . . . . 37		A.2. Checksum offload . . . . . . . . . . . . . . . . . . . . . 38
	A.2.2. Receive checksum offload . . . . . . . . . . . . . . . 37		A.2.1. Transmit checksum offload . . . . . . . . . . . . . . . 39
	A.3. Transmit Segmentation Offload . . . . . . . . . . . . . . . 38		A.2.2. Receive checksum offload . . . . . . . . . . . . . . . 39
	A.4. Large Receive Offload . . . . . . . . . . . . . . . . . . . 39		A.3. Transmit Segmentation Offload . . . . . . . . . . . . . . . 40
	Appendix B: Implementation considerations . . . . . . . . . . . . 39		A.4. Large Receive Offload . . . . . . . . . . . . . . . . . . . 41
	B.1. Priveleged ports . . . . . . . . . . . . . . . . . . . . . 39		Appendix B: Implementation considerations . . . . . . . . . . . . 41
	B.2. Setting flow entropy as a route selector . . . . . . . . . 40		B.1. Priveleged ports . . . . . . . . . . . . . . . . . . . . . 41
	B.3. Hardware protocol implementation considerations . . . . . . 40		B.2. Setting flow entropy as a route selector . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41		B.3. Hardware protocol implementation considerations . . . . . . 42
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
	1. Introduction		1. Introduction
	This specification describes Generic UDP Encapsulation (GUE) which is		This specification describes Generic UDP Encapsulation (GUE) which is
	a general method for encapsulating packets of arbitrary IP protocols		a general method for encapsulating packets of arbitrary IP protocols
	within User Datagram Protocol (UDP) [RFC0768] packets. Encapsulating		within User Datagram Protocol (UDP) [RFC0768] packets. Encapsulating
	packets in UDP facilitates efficient transport across networks.		packets in UDP facilitates efficient transport across networks.
	Networking devices widely provide protocol specific processing and		Networking devices widely provide protocol specific processing and
	optimizations for UDP (as well as TCP) packets. Packets for atypical		optimizations for UDP (as well as TCP) packets. Packets for atypical
	IP protocols (those not usually parsed by networking hardware) can be		IP protocols (those not usually parsed by networking hardware) can be
	skipping to change at page 10, line 51 ¶		skipping to change at page 10, line 51 ¶
	the GUE payload does not begin with the header of an IP protocol.		the GUE payload does not begin with the header of an IP protocol.
	This would be the case, for instance, if the GUE payload were a		This would be the case, for instance, if the GUE payload were a
	fragment when performing GUE level fragmentation. The interpretation		fragment when performing GUE level fragmentation. The interpretation
	of the payload is performed through other means such as flags and		of the payload is performed through other means such as flags and
	extension fields, and nodes MUST NOT parse packets based on the IP		extension fields, and nodes MUST NOT parse packets based on the IP
	protocol number in this case.		protocol number in this case.
	3.2.2. Ctype field		3.2.2. Ctype field
	When the C-bit is set, the proto/ctype field MUST be set to a valid		When the C-bit is set, the proto/ctype field MUST be set to a valid
	control message type. A value of zero indicates that the GUE payload		control message type. Control messages will be defined in an IANA
	requires further interpretation to deduce the control type. This		registry. Type 0 and type 255 are specified in this document, type 1
	might be the case when the payload is a fragment of a control		through 254 are reserved and may be defined in standards.
	message, where only the reassembled packet can be interpreted as a
	control message.
	Control messages will be defined in an IANA registry. Control message		Type 0 indicates that the GUE payload is a control message, or part
	types 1 through 127 may be defined in standards. Types 128 through		of a control message that cannot be correctly parsed or interpreted
	255 are reserved to be user defined for experimentation.		without additional context. This might be the case when the payload
			is a fragment of a control message, where only the reassembled packet
			can be interpreted as a control message.
	This document does not specify any standard control message types		Type 255 is reserved for experimentation. When this control type is
	other than type 0. Type 0 indicates that the GUE payload is a control		set the first four bytes of the GUE payload (control message) are an
	message, or part of a control message (as might be the case in GUE		experiment identifier (ExId). The ExID is used to differentiate
	fragmentation) that cannot be correctly parsed or interpreted without		experiments (similar to the experimental identifier defined for TCP
	additional context.		options in [RFC6994]). A control message of type 255 MUST include an
			ExID.
			The format of a GUE control message with the experimental control
			message type is:
			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
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
			| Source port | Destination port | |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
			| Length | Checksum | |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
			| 0 |1| Hlen | 255 | Flags |\
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
			| | GUE
			~ Extensions Fields (optional) ~ |
			| | |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
			| ExID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			~ Control message ~
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Note that the ExID is not part of the GUE header, it is in the
			payload. In particular, the ExID is not accounted for in the GUE
			Hlen.
			ExIDs are selected at design time, when the protocol designer first
			implements or specifies the experimental control message. An ExID is
			thirty-two bits. The value is stored in the header in network-
			standard (big-endian) byte order.
			ExIDs are registered with IANA using "first come, first served"
			(FCFS) priority. ExIDs MUST be unique.
	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.
	[GUEEXTEN] defines an initial set of GUE extensions.		[GUEEXTEN] defines an initial set of GUE extensions.
	3.3.1. Requirements		3.3.1. Requirements
	skipping to change at page 18, line 34 ¶		skipping to change at page 19, line 34 ¶
	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 IPv4 encapsulated packet.		processed as an IPv4 encapsulated 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 value in the ctype field of the GUE header.		on the value in the ctype field of the GUE header.
			If an experimental control message is received (ctype is 255) then
			the ExID MUST be processed. The ExID is used to identify the
			particular experimental control message.
			If a receiver does not recognize a control message type, or an
			experimental identifier in an experimental control message, then the
			packet MUST be dropped and and error message MAY be logged. If a GUE
			control message is received with control type 255 and the length of
			the GUE payload is less than four, the size of the ExId, then the
			packet MUST be dropped and an error message MAY be logged.
	5.5. Middlebox inspection		5.5. Middlebox inspection
	A middlebox MAY inspect a GUE header. A middlebox MUST NOT modify a		A middlebox MAY inspect a GUE header. A middlebox MUST NOT modify a
	GUE header or UDP payload.		GUE header or UDP payload.
	To inspect a GUE header, a middlebox needs to identify GUE packets.		To inspect a GUE header, a middlebox needs to identify GUE packets.
	The obvious method is to match the destination UDP port number to be		The obvious method is to match the destination UDP port number to be
	the GUE port number (i.e. 6080). Per [RFC7605], transport port		the GUE port number (i.e. 6080). Per [RFC7605], transport port
	numbers only have meaning at the endpoints of communications, so		numbers only have meaning at the endpoints of communications, so
	inferring the type of a UDP payload based on port number may be		inferring the type of a UDP payload based on port number may be
	skipping to change at page 31, line 39 ¶		skipping to change at page 32, line 39 ¶
	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 |
	+----------------+------------------+---------------+		+----------------+------------------+---------------+
	| 0 | Control payload | This document |		| 0 | Control payload | This document |
	| | needs more | |		| | needs more | |
	| | context for | |		| | context for | |
	| | interpretation | |		| | interpretation | |
	| | | |		| | | |
	| 1..127 | Unassigned | |		| 1..254 | Unassigned | |
	| | | |		| | | |
	| 128..255 | Experimental | This document |		| 255 | Experimental | This document |
	+----------------+------------------+---------------+		+----------------+------------------+---------------+
			8.4 Control Type Experimental Identifiers
			IANA is requested to create a "GUE Control Type Experimental
			Identifiers (GUE Control ExIDs)" registry. The registry records 32-
			bit ExIDs, as well as a reference (description, document pointer,
			assignee name, and e-mail contact) for each entry.
			Entries are assigned on a First Come, First Served (FCFS) basis
			[RFC5226]. The registry operates FCFS on the entire ExID (in network-
			standard order).
			IANA will advise applicants of duplicate entries to select an
			alternate value, as per typical FCFS processing.
			IANA will record known duplicate uses to assist the community in both
			debugging assigned uses as well as correcting unauthorized duplicate
			uses.
			IANA should impose no requirements on making a registration other
			than indicating the desired codepoint and providing a point of
			contact. A short description or acronym for the use is desired but
			should not be required.
			Initial assignments are:
			+----------------+----------------+---------------+
			| ExI D | Description | Reference |
			+----------------+----------------+---------------+
			| 1..x0ffffffff | Unassigned | |
			+----------------+----------------+---------------+
	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, Murray Kucherawy, Mirja		Templin, Adrian Farrel, Bob Briscoe, Murray Kucherawy, Mirja
	Kuhlewind, and David Black for valuable input on this draft. Special		Kuhlewind, David Black, Joe Touch, and Greg Mirsky for valuable input
	thanks to Fred Templin who is serving as document shepherd.		on this draft. Special thanks to Fred Templin who is serving as
			document shepherd.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", BCP 14, RFC 2119, DOI
			10.17487/RFC2119, March 1997, <https://www.rfc-
			editor.org/info/rfc2119>.
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI
	10.17487/RFC0768, August 1980, <http://www.rfc-		10.17487/RFC0768, August 1980, <http://www.rfc-
	editor.org/info/rfc768>.		editor.org/info/rfc768>.
	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage		[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,		Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
	March 2017, <https://www.rfc-editor.org/info/rfc8085>.		March 2017, <https://www.rfc-editor.org/info/rfc8085>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI		Requirement Levels", BCP 14, RFC 2119, DOI
	skipping to change at page 33, line 15 ¶		skipping to change at page 35, line 20 ¶
	6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-		6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-
	editor.org/info/rfc6335>.		editor.org/info/rfc6335>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226, DOI		IANA Considerations Section in RFCs", RFC 5226, DOI
	10.17487/RFC5226, May 2008, <https://www.rfc-		10.17487/RFC5226, May 2008, <https://www.rfc-
	editor.org/info/rfc5226>.		editor.org/info/rfc5226>.
	10.2. Informative References		10.2. Informative References
			[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC
			6994, DOI 10.17487/RFC6994, August 2013, <https://www.rfc-
			editor.org/info/rfc6994>.
	[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-		[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
	in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,		in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
	March 2017, <http://www.rfc-editor.org/info/rfc8086>.		March 2017, <http://www.rfc-editor.org/info/rfc8086>.
	[RFC7605] Touch, J., "Recommendations on Using Assigned Transport		[RFC7605] Touch, J., "Recommendations on Using Assigned Transport
	Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,		Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
	August 2015, <https://www.rfc-editor.org/info/rfc7605>.		August 2015, <https://www.rfc-editor.org/info/rfc7605>.
	[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address		[RFC4787] Audet, F., Ed., and C. Jennings, "Network Address
	Translation (NAT) Behavioral Requirements for Unicast		Translation (NAT) Behavioral Requirements for Unicast
End of changes. 17 change blocks.
	75 lines changed or deleted		164 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/