< draft-herbert-ipv4-udpencap-eh-00.txt		draft-herbert-ipv4-udpencap-eh-01.txt >
	INTERNET-DRAFT T. Herbert		INTERNET-DRAFT T. Herbert
	Intended Status: Proposed Standard Quantonium		Intended Status: Proposed Standard Quantonium
	Expires: August 2019		Expires: September 2019
	February 27, 2019		March 8, 2019
	IPv4 Extension Headers and UDP Encapsulated Extension Headers		IPv4 Extension Headers and UDP Encapsulated Extension Headers
	draft-herbert-ipv4-udpencap-eh-00		draft-herbert-ipv4-udpencap-eh-01
	Abstract		Abstract
	This specification defines extension headers for IPv4 and a method to		This specification defines extension headers for IPv4 and a method to
	encapsulate extension headers in UDP to facilitate transmission over		encapsulate extension headers in UDP to facilitate transmission over
	the Internet. The goal is to provide a uniform and feasible method of		the Internet, as well as a definition of an IPv4 flow label. The goal
	extensibility that is shared between IPv4 and IPv6.		is to provide a uniform and feasible method of extensibility that is
			shared between IPv4 and IPv6.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 17 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1 IPv4 extension headers . . . . . . . . . . . . . . . . . . . 3		1.1 IPv4 extension headers . . . . . . . . . . . . . . . . . . . 3
	1.2 Encapsulating extension headers in UDP . . . . . . . . . . . 3		1.2 Encapsulating extension headers in UDP . . . . . . . . . . . 3
			1.3 The IPv4 flow label . . . . . . . . . . . . . . . . . . . . 4
	2 IPv4 extension headers . . . . . . . . . . . . . . . . . . . . 4		2 IPv4 extension headers . . . . . . . . . . . . . . . . . . . . 4
	2.1 Extension Header Order . . . . . . . . . . . . . . . . . . . 6		2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . . 7		2.2 Interaction with standard IPv4 mechanisms . . . . . . . . . 6
	2.3 Hop-by-Hop Options Header . . . . . . . . . . . . . . . . . 9		2.2.1 IPv4 options and IPv4 extension headers . . . . . . . . 7
	2.4 Routing Header . . . . . . . . . . . . . . . . . . . . . . . 10		2.2.2 IPv4 fragmentation and IPv4 extension headers . . . . . 7
	2.5 Fragment Header . . . . . . . . . . . . . . . . . . . . . . 11		3 Encapsulating extension headers in UDP . . . . . . . . . . . . 7
	2.6 Destination Options Header . . . . . . . . . . . . . . . . . 18		3.1 Encapsulation format . . . . . . . . . . . . . . . . . . . . 8
	2.7 No Next Header . . . . . . . . . . . . . . . . . . . . . . . 18		3.2 GUE magic numbers . . . . . . . . . . . . . . . . . . . . . 9
	2.8 Interaction with standard IPv4 mechanisms . . . . . . . . . 19		3.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 10
	2.8.1 IPv4 options and IPv4 extension headers . . . . . . . . 19		3.3.1 Sender processing . . . . . . . . . . . . . . . . . . . 10
	2.8.2 IPv4 fragmentation and IPv4 extension headers . . . . . 19		3.3.2 Destination Processing . . . . . . . . . . . . . . . . . 11
	3 Encapsulating extension headers in UDP . . . . . . . . . . . . 20		3.3.3 Intermediate device processing . . . . . . . . . . . . . 11
	3.1 Encapsulation format . . . . . . . . . . . . . . . . . . . . 20		4 The IPv4 flow label . . . . . . . . . . . . . . . . . . . . . . 12
	3.2 GUE magic numbers . . . . . . . . . . . . . . . . . . . . . 21		4.1 Sender requirements . . . . . . . . . . . . . . . . . . . . 12
	3.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . 22		4.2 Receiver requirements . . . . . . . . . . . . . . . . . . . 13
	3.3.1 Sender processing . . . . . . . . . . . . . . . . . . . 22		5 Security Considerations . . . . . . . . . . . . . . . . . . . . 14
	3.3.2 Destination Processing . . . . . . . . . . . . . . . . . 23		6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
	3.3.3 Intermediate device processing . . . . . . . . . . . . . 23		7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4 Security Considerations . . . . . . . . . . . . . . . . . . . . 25		7.1 Normative References . . . . . . . . . . . . . . . . . . . 14
	5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25		7.2 Informative References . . . . . . . . . . . . . . . . . . 15
	6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.1 Normative References . . . . . . . . . . . . . . . . . . . 25
	6.2 Informative References . . . . . . . . . . . . . . . . . . 25
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
	1 Introduction		1 Introduction
	This specification defines extension headers for IPv4 and a method to		This specification defines extension headers for IPv4 and a method to
	encapsulate extension headers in UDP to facilitate transmission over		encapsulate extension headers in UDP to facilitate transmission over
	the Internet.		the Internet. An IPv4 flow label is also defined to help intermediate
			nodes classify flows for packets with unknown protocols.
	1.1 IPv4 extension headers		1.1 IPv4 extension headers
	IPv4 options were defined in [RFC791] as the means of extending the		IPv4 options were defined in [RFC0791] as the means of extending the
	IP protocol. IPv4 options have not been successful. Early router		IP protocol. IPv4 options have not been successful. Early router
	implementations, and even those today, either don't process IPv4		implementations, and even those today, either don't process IPv4
	options or relegate them to a slow path effectively making them		options or relegate them to a slow path effectively making them
	unusable for serious applications. IPv4 options are limited to forty		unusable for serious applications. IPv4 options are limited to forty
	bytes length and, unlike TCP options, no IP options have been defined		bytes length and, unlike TCP options, no IP options have been defined
	that are critical to communications. The upshot is that IPv4 options		that are critical to communications. The upshot is that IPv4 options
	have long not been considered an option for deployment [IPNOPT].		have long not been considered an option for deployment [IPNOPT].
	IPv6 took a different approach. Extensibility of IPv6 is provided by		IPv6 took a different approach. Extensibility of IPv6 is provided by
	extension headers. Optional internet-layer information is encoded in		extension headers. Optional internet-layer information is encoded in
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 28 ¶
	node were to modify a UDP payload whose type it has misinterpreted,		node were to modify a UDP payload whose type it has misinterpreted,
	then systematic silent data corruption ensues. To mitigate this		then systematic silent data corruption ensues. To mitigate this
	issue, a magic number can be set in the UDP data that indicates the		issue, a magic number can be set in the UDP data that indicates the
	payload type. A magic number identifies the payload as being GUE with		payload type. A magic number identifies the payload as being GUE with
	high probability to minimize the risk of misintepretation.		high probability to minimize the risk of misintepretation.
	Note that the solution to encapsulate extension headers can be used		Note that the solution to encapsulate extension headers can be used
	for both IPv4 and IPv6. Encapsulation serves as workaround for paths		for both IPv4 and IPv6. Encapsulation serves as workaround for paths
	that have problems processing IPv6 extension headers.		that have problems processing IPv6 extension headers.
			1.3 The IPv4 flow label
			IPv6 introduced the concept of a flow label that has proven quite
			convenient to perform flow classification, such as that needed by
			Equal-Cost Multipath (ECMP). The base IPv4 header does not have
			reserved bits that could be allocated as a flow label, however the
			sixteen bit Identification field can be used as a flow label in
			atomic datagrams [RFC6864].
			The IPv4 flow label will be most useful in scenarios for which the
			existing mechanisms used to classify IPv4 packets, such as parsing
			transport layer headers to extract port information, aren't
			available. Defining an IPv4 flow label would also be another instance
			of backporting a beneficial feature from IPv6 and further unifying
			the two protocols.
	2 IPv4 extension headers		2 IPv4 extension headers
	IPv4 extension headers are optional internet-layer information		IPv4 extension headers are optional internet-layer information
	encoded in separate headers that may be placed between the IPv4		encoded in separate headers that may be placed between the IPv4
	header and the upper-layer header in a packet. IPv4 extension headers		header and the upper-layer header in a packet. IPv4 extension headers
	are based on IPv6 extension headers and share the same basic		are based on IPv6 extension headers and share the same basic
	properties and semantics [RFC8200].		properties and semantics [RFC8200].
	Extension headers are numbered from IANA IP Protocol Numbers [IANA-		Extension headers are numbered from IANA IP Protocol Numbers [IANA-
	PN], the same values are used for IPv4 and IPv6. When processing a		PN], the same values are used for IPv4 and IPv6. When processing a
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 22 ¶
	As illustrated in these examples, an IPv4 packet MAY carry zero, one,		As illustrated in these examples, an IPv4 packet MAY carry zero, one,
	or more extension headers, each identified by the Next Header field		or more extension headers, each identified by the Next Header field
	of the preceding header or the Protocol field of the IPv4 header:		of the preceding header or the Protocol field of the IPv4 header:
	+---------------+------------------------		+---------------+------------------------
	| IPv4 header | TCP header + data		| IPv4 header | TCP header + data
	| |		| |
	| Protocol = |		| Protocol = |
	| TCP |		| TCP |
	+---------------+------------------------		+---------------+------------------------
	+---------------+----------------+------------------------		+---------------+----------------+------------------------
	| IPv4 header | Hop-by-Hop | TCP header + data		| IPv4 header | Hop-by-Hop | TCP header + data
	| | |		| | |
	| Protocol = | Next Header = |		| Protocol = | Next Header = |
	| Hop-by-Hop | TCP |		| Hop-by-Hop | TCP |
	+---------------+----------------+------------------------		+---------------+----------------+------------------------
	+---------------+----------------+-----------------+-----------------		+---------------+----------------+-----------------+-----------------
	| IPv4 header | Hop-by-Hop | Fragment header | fragment of TCP		| IPv4 header | Hop-by-Hop | Fragment header | fragment of TCP
	| | | | header + data		| | | | header + data
	| Protocol = | Next Header = | Next Header = |		| Protocol = | Next Header = | Next Header = |
	| Hop-by-Hop | Fragment | TCP |		| Hop-by-Hop | Fragment | TCP |
	+---------------+----------------+-----------------+-----------------		+---------------+----------------+-----------------+-----------------
	Extension headers (except for the Hop-by-Hop Options header) MUST NOT		2.1 Requirements
	be processed, inserted, or deleted by any node along a packet's
	delivery path, until the packet reaches the node (or each of the set
	of nodes, in the case of multicast) identified in the Destination
	Address field of the IPv4 header.
	The Hop-by-Hop Options header MUST NOT be inserted or deleted, but
	MAY be examined or processed by any node along a packet's delivery
	path, until the packet reaches the node (or each of the set of nodes,
	in the case of multicast) identified in the Destination Address field
	of the IPv4 header. The Hop-by-Hop Options header, when present, MUST
	immediately follow the IPv4 header. Its presence is indicated by the
	value zero in the Protocol field of the IPv4 header.
	At the destination node, normal demultiplexing on the Protocol field
	of the IPv4 header invokes the module to process the first extension
	header, or the upper-layer header if no extension header is present.
	The contents and semantics of each extension header determine whether
	or not to proceed to the next header. Therefore, extension headers
	MUST be processed strictly in the order they appear in the packet; a
	receiver MUST NOT, for example, scan through a packet looking for a
	particular kind of extension header and process that header prior to
	processing all preceding ones.
	If, as a result of processing a header, the destination node is
	required to proceed to the next header but the Next Header value in
	the current header is unrecognized by the node, it SHOULD discard the
	packet and send an ICMP Parameter Problem message to the source of
	the packet, with an ICMP Code value of 1 ("unrecognized Next Header
	type encountered") and the ICMP Pointer field containing the offset
	of the unrecognized value within the original packet. The same action
	should be taken if a node encounters a Next Header value of zero in
	any header other than an IPv6 or IPv4 header.
	Each extension header is an integer multiple of 8 octets long, in
	order to retain 8-octet alignment for subsequent headers. Multi-
	octet fields within each extension header are aligned on their
	natural boundaries, i.e., fields of width n octets are placed at an
	integer multiple of n octets from the start of the header, for n = 1,
	2, 4, or 8.
	A full implementation of IPv4 with extension headers includes
	implementation of the following extension headers:
	Hop-by-Hop Options
	Fragment
	Destination Options
	Routing
	Authentication
	Encapsulating Security Payload
	The first four are specified in this document; IPv4 support for the
	last two are specified in [RFC4302] and [RFC4303], respectively. The
	current list of IPv4 extension headers is assumed to be the same as
	the list of IPv6 extension headers which can be found at [IANA-EH].
	2.1 Extension Header Order
	When more than one extension header is used in the same packet, it is
	RECOMMENDED that those headers appear in the following order:
	IPv4 header
	Hop-by-Hop Options header
	Destination Options header (note 1)
	Routing header
	Fragment header
	Authentication header (note 2)
	Encapsulating Security Payload header (note 2)
	Destination Options header (note 3)
	Upper-Layer header
	note 1: for options to be processed by the first destination that
	appears in the IPv4 Destination Address field plus
	subsequent destinations listed in the Routing header.
	note 2: additional recommendations regarding the relative order of
	the Authentication and Encapsulating Security Payload
	headers are given in [RFC4303].
	note 3: for options to be processed only by the final destination
	of the packet.
	Each extension header should occur at most once, except for the
	Destination Options header, which should occur at most twice (once
	before a Routing header and once before the upper-layer header).
	If a legacy IPv4 destination node, one that does not support IPv4
	extension headers, receives a packet with extension headers then the
	packet will be processed as having an unknown protocol. The packet
	will be discarded and an ICMP error should be generated.
	IPv4 nodes that support extension headers MUST accept and attempt to
	process extension headers in any order and occurring any number of
	times in the same packet, except for the Hop-by-Hop Options header,
	which is restricted to appear immediately after an IPv4 header only.
	Nonetheless, it is strongly RECOMMENDED that sources of IPv4 packets
	adhere to the above recommended order until and unless subsequent
	specifications revise that recommendation.
	2.2 Options
	Two of the currently defined extension headers specified in this
	document -- the Hop-by-Hop Options header and the Destination Options
	header -- carry a variable number of "options" that are type-length-
	value (TLV). The format is:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
	| Option Type | Opt Data Len | Option Data
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
	Option Type 8-bit identifier of the type of option.
	Opt Data Len 8-bit unsigned integer. Length of the Option
	Data field of this option, in octets.
	Option Data Variable-length field. Option-Type-specific
	data.
	The sequence of options within a header MUST be processed strictly in
	the order they appear in the header; a receiver MUST NOT scan through
	the header looking for a particular kind of option and process that
	option prior to processing all preceding ones.
	The Option Type identifiers are internally encoded such that their
	highest-order 2 bits specify the action that MUST be taken if the
	processing IPv4 node does not recognize the Option Type:
	00 - skip over this option and continue processing the header.
	01 - discard the packet.
	10 - discard the packet and, regardless of whether or not the
	packet's Destination Address was a multicast address, send an
	ICMP Parameter Problem, Code 2, message to the packet's
	Source Address, pointing to the unrecognized Option Type.
	11 - discard the packet and, only if the packet's Destination
	Address was not a multicast address, send an ICMP Parameter
	Problem, Code 2, message to the packet's Source Address,
	pointing to the unrecognized Option Type.
	The third-highest-order bit of the Option Type specifies whether or
	not the Option Data of that option can change en route to the
	packet's final destination. When an Authentication header is present
	in the packet, for any option whose data may change en route, its
	entire Option Data field MUST be treated as zero-valued octets when
	computing or verifying the packet's authenticating value.
	0 - Option Data does not change en route
	1 - Option Data may change en route
	The three high-order bits described above are to be treated as part
	of the Option Type, not independent of the Option Type. That is, a
	particular option is identified by a full 8-bit Option Type, not just
	the low-order 5 bits of an Option Type.
	The same Option Type numbering space is used for both the Hop-by-Hop
	Options header and the Destination Options header. However, the
	specification of a particular option may restrict its use to only one
	of those two headers.
	Individual options may have specific alignment requirements, to
	ensure that multi-octet values within Option Data fields fall on
	natural boundaries. The alignment requirement of an option is
	specified using the notation xn+y, meaning the Option Type must
	appear at an integer multiple of x octets from the start of the
	header, plus y octets. For example:
	2n means any 2-octet offset from the start of the header.
	8n+2 means any 8-octet offset from the start of the header, plus
	2 octets.
	There are two padding options that are used when necessary to align
	subsequent options and to pad out the containing header to a multiple
	of 8 octets in length. These padding options MUST be recognized by
	all IPv4 implementations that support extension headers:
	Pad1 option (alignment requirement: none)
	+-+-+-+-+-+-+-+-+
	| 0 |
	+-+-+-+-+-+-+-+-+
	NOTE! the format of the Pad1 option is a special case -- it does
	not have length and value fields.
	The Pad1 option is used to insert 1 octet of padding into the
	Options area of a header. If more than one octet of padding is
	required, the PadN option, described next, SHOULD be used, rather
	than multiple Pad1 options.
	PadN option (alignment requirement: none)
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
	| 1 | Opt Data Len | Option Data
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
	The PadN option is used to insert two or more octets of padding
	into the Options area of a header. For N octets of padding, the
	Opt Data Len field contains the value N-2, and the Option Data
	consists of N-2 zero-valued octets.
	2.3 Hop-by-Hop Options Header
	The Hop-by-Hop Options header is used to carry optional information
	that MAY be examined and processed by any node along a packet's
	delivery path. The Hop-by-Hop Options header is identified by a Next
	Header value of 0 in the IPv4 header and has the following format:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | Hdr Ext Len | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	| |
	. .
	. Options .
	. .
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header 8-bit selector. Identifies the type of header
	immediately following the Hop-by-Hop Options
	header. Values are defined in [IANA-PN].
	Hdr Ext Len 8-bit unsigned integer. Length of the Hop-by-
	Hop Options header in 8-octet units, not
	including the first 8 octets.
	Options Variable-length field, of length such that the
	complete Hop-by-Hop Options header is an
	integer multiple of 8 octets long. Contains
	one or more TLV-encoded options, as described
	in Section 2.2.
	The only hop-by-hop options defined in this document are the Pad1 and
	PadN options specified in Section 2.2.
	2.4 Routing Header
	The Routing header is used by an IPv4 source to list one or more
	intermediate nodes to be "visited" on the way to a packet's
	destination. This function is very similar to IPv4's Loose Source and
	Record Route option. The Routing header is identified by a Next
	Header value of 43 in the immediately preceding header and has the
	following format:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | Hdr Ext Len | Routing Type | Segments Left |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	. .
	. type-specific data .
	. .
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header 8-bit selector. Identifies the type of header
	immediately following the Routing
	header. Values are defined in [IANA-PN].
	Hdr Ext Len 8-bit unsigned integer. Length of the Routing
	header in 8-octet units, not including the
	first 8 octets.
	Routing Type 8-bit identifier of a particular Routing
	header variant.
	Segments Left 8-bit unsigned integer. Number of route
	segments remaining, i.e., number of explicitly
	listed intermediate nodes still to be visited
	before reaching the final destination.
	type-specific data Variable-length field, of format determined by
	the Routing Type, and of length such that the
	complete Routing header is an integer multiple
	of 8 octets long.
	If, while processing a received packet, a node encounters a Routing
	header with an unrecognized Routing Type value, the required behavior
	of the node depends on the value of the Segments Left field, as
	follows:
	If Segments Left is zero, the node MUST ignore the Routing header
	and proceed to process the next header in the packet, whose type
	is identified by the Next Header field in the Routing header.
	If Segments Left is non-zero, the node MUST discard the packet and
	send an ICMP Parameter Problem, Code 0, message to the packet's
	Source Address, pointing to the unrecognized Routing Type.
	If, after processing a Routing header of a received packet, an
	intermediate node determines that the packet is to be forwarded onto
	a link whose link MTU is less than the size of the packet, the node
	MUST discard the packet and send an ICMP Packet Too Big message to
	the packet's Source Address.
	2.5 Fragment Header
	The Fragment header is used by an IPv4 source to send a packet larger
	than would fit in the path MTU to its destination. This can be used
	as an alternative to canonical IPv4 fragmentation. As in IPv6,
	fragmentation using the Fragment Header is performed only by source
	nodes. Section 2.8.1 discusses the interaction between IPv4 extension
	headers and standard IPv4 fragmentation.
	A Fragment header is identified by a Next Header value of 44 in the
	immediately preceding header and has the following format:
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Next Header | Reserved | Fragment Offset |Res|M|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identification |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header 8-bit selector. Identifies the initial header
	type of the Fragmentable Part of the original
	packet (defined below). Uses the same values
	as the IPv4 Protocol field [IANA-PN].
	Reserved 8-bit reserved field. Initialized to zero for
	transmission; ignored on reception.
	Fragment Offset 13-bit unsigned integer. The offset, in
	8-octet units, of the data following this
	header, relative to the start of the
	Fragmentable Part of the original packet.
	Res 2-bit reserved field. Initialized to zero for
	transmission; ignored on reception.
	M flag 1 = more fragments; 0 = last fragment.
	Identification 32 bits. See description below.
	In order to send a packet that is too large to fit in the MTU of the
	path to its destination, a source node may divide the packet into
	fragments and send each fragment as a separate packet, to be
	reassembled at the receiver.
	For every packet that is to be fragmented, the source node generates
	an Identification value. The Identification must be different than
	that of any other fragmented packet sent recently* with the same
	Source Address and Destination Address. If a Routing header is
	present, the Destination Address of concern is that of the final
	destination.
	* "recently" means within the maximum likely lifetime of a
	packet, including transit time from source to destination and
	time spent awaiting reassembly with other fragments of the same
	packet. However, it is not required that a source node knows
	the maximum packet lifetime. Rather, it is assumed that the
	requirement can be met by implementing an algorithm that
	results in a low identification reuse frequency. Examples of
	algorithms meeting this requirement are described in [RFC7739].
	The initial unfragmented packet is referred to as the "original
	packet" and is considered to consist of three parts, as shown:
	original packet:
	+------------------+-------------------------+---//----------------+
	| Per-Fragment | Extension & Upper-Layer | Fragmentable |
	| Headers | Headers | Part |
	+------------------+-------------------------+---//----------------+
	The Per-Fragment headers must consist of the IPv4 header plus any
	extension headers that must be processed by nodes en route to the
	destination, that is, all headers up to and including the Routing
	header if present, else the Hop-by-Hop Options header if present,
	else no extension headers.
	The Extension headers are all other extension headers that are not
	included in the Per-Fragment headers part of the packet. For this
	purpose, the Encapsulating Security Payload (ESP) is not
	considered an extension header. The Upper-Layer header is the
	first upper-layer header that is not an IPv4 extension header.
	Examples of upper-layer headers include TCP, UDP, IPv4, IPv6,
	ICMPv4, and as noted ESP.
	The Fragmentable Part consists of the rest of the packet after the
	upper-layer header or after any header (i.e., initial IPv4 header
	or extension header) that contains a Next Header value of No Next
	Header.
	The Fragmentable Part of the original packet is divided into
	fragments. The lengths of the fragments MUST be chosen such that the
	resulting fragment packets fit within the MTU of the path to the
	packet's destination(s). Each complete fragment, except possibly the
	last ("rightmost") one, is an integer multiple of 8 octets long.
	The fragments are transmitted in separate "fragment packets" as
	illustrated:
	original packet:
	+-----------------+-----------------+--------+--------+-//-+--------+
	| Per-Fragment |Ext & Upper-Layer| first | second | | last |
	| Headers | Headers |fragment|fragment|....|fragment|
	+-----------------+-----------------+--------+--------+-//-+--------+
	fragment packets:
	+------------------+---------+-------------------+----------+
	| Per-Fragment |Fragment | Ext & Upper-Layer | first |
	| Headers | Header | Headers | fragment |
	+------------------+---------+-------------------+----------+
	+------------------+--------+-------------------------------+
	| Per-Fragment |Fragment| second |
	| Headers | Header | fragment |
	+------------------+--------+-------------------------------+
	o
	o
	o
	+------------------+--------+----------+
	| Per-Fragment |Fragment| last |
	| Headers | Header | fragment |
	+------------------+--------+----------+
	The first fragment packet is composed of:
	(1) The Per-Fragment headers of the original packet, with the
	Total Length of the original IPv4 header changed to contain
	the length of this fragment packet only, and the Next Header
	field of the last header of the Per-Fragment headers changed
	to 44.
	(2) A Fragment header containing:
	The Next Header value that identifies the first header
	after the Per-Fragment headers of the original packet.
	A Fragment Offset containing the offset of the fragment,
	in 8-octet units, relative to the start of the
	Fragmentable Part of the original packet. The Fragment
	Offset of the first ("leftmost") fragment is 0.
	An M flag value of 1 as this is the first fragment.
	The Identification value generated for the original
	packet.
	(3) Extension headers, if any, and the Upper-Layer header. These
	headers must be in the first fragment. Note: This restricts
	the size of the headers through the Upper-Layer header to the
	MTU of the path to the packet's destinations(s).
	(4) The first fragment.
	The subsequent fragment packets are composed of:
	(1) The Per-Fragment headers of the original packet, with the
	Total Length of the original IPv4 header changed to contain
	the length of this fragment packet only, and the Next Header
	field of the last header of the Per-Fragment headers changed
	to 44.
	(2) A Fragment header containing:
	The Next Header value that identifies the first header
	after the Per-Fragment headers of the original packet.
	A Fragment Offset containing the offset of the fragment,
	in 8-octet units, relative to the start of the
	Fragmentable Part of the original packet.
	An M flag value of 0 if the fragment is the last
	("rightmost") one, else an M flag value of 1.
	The Identification value generated for the original
	packet.
	(3) The fragment itself.
	Fragments MUST not be created that overlap with any other fragments
	created from the original packet.
	At the destination, fragment packets are reassembled into their
	original, unfragmented form, as illustrated:
	reassembled original packet:
	+---------------+-----------------+---------+--------+-//--+--------+
	| Per-Fragment |Ext & Upper-Layer| first | second | | last |
	| Headers | Headers |frag data|fragment|.....|fragment|
	+---------------+-----------------+---------+--------+-//--+--------+
	The following rules govern reassembly:
	An original packet is reassembled only from fragment packets that
	have the same Source Address, Destination Address, and Fragment
	Identification.
	The Per-Fragment headers of the reassembled packet consists of all
	headers up to, but not including, the Fragment header of the first
	fragment packet (that is, the packet whose Fragment Offset is
	zero). This includes the IPv4 header and any associated IPv4
	options of the first fragment. The Per-Fragment headers of the
	reassembled packet include the following two changes:
	The Next Header field of the last header of the Per-Fragment
	headers is obtained from the Next Header field of the first
	fragment's Fragment header.
	The Total Length of the reassembled packet is computed from the
	length of the Per-Fragment headers (including the IPv4 header)
	and the length and offset of the last fragment. For example, a
	formula for computing the Total Length of the reassembled
	original packet is:
	TL.orig = TL.first - FL.first - 8 + (8 * FO.last) + FL.last
	where
	TL.orig = Total Length of reassembled packet.
	FL.first = length of fragment following Fragment header of
	first fragment packet.
	FO.last = Fragment Offset field of Fragment header of last
	fragment packet.
	FL.last = length of fragment following Fragment header of
	last fragment packet.
	The Fragmentable Part of the reassembled packet is constructed
	from the fragments following the Fragment headers in each of
	the fragment packets. The length of each fragment is computed
	by subtracting from the packet's Total Length the length of the
	headers before the fragment itself; its relative position in
	Fragmentable Part is computed from its Fragment Offset value.
	The Fragment header is not present in the final, reassembled
	packet.
	If the fragment is a whole datagram (that is, both the Fragment
	Offset field and the M flag are zero), then it does not need
	any further reassembly and should be processed as a fully
	reassembled packet (i.e., updating Next Header or Protocol,
	adjust Total Length, removing the Fragment header, etc.). Any
	other fragments that match this packet (i.e., the same IPv4
	Source Address, IPv4 Destination Address, and Fragment
	Identification) should be processed independently.
	The following error conditions may arise when reassembling fragmented
	packets:
	o If insufficient fragments are received to complete reassembly
	of a packet within 60 seconds or a configured time limit of the
	reception of the first-arriving fragment of that packet,
	reassembly of that packet MUST be abandoned and all the
	fragments that have been received for that packet MUST be
	discarded. If the first fragment (i.e., the one with a
	Fragment Offset of zero) has been received, an ICMP Time
	Exceeded -- Fragment Reassembly Time Exceeded message SHOULD be
	sent to the source of that fragment.
	o If the length of a fragment, as derived from the fragment
	packet's Total Length field, is not a multiple of 8 octets and
	the M flag of that fragment is 1, then that fragment MUST be
	discarded and an ICMP Parameter Problem, Code 0, message SHOULD
	be sent to the source of the fragment, pointing to the Total
	Length field of the fragment packet.
	o If the length and offset of a fragment are such that the Total
	Length of the packet reassembled from that fragment would
	exceed 65,535 octets, then that fragment MUST be discarded and
	an ICMP Parameter Problem, Code 0, message SHOULD be sent to
	the source of the fragment, pointing to the Fragment Offset
	field of the fragment packet.
	o If the first fragment does not include all headers through an
	Upper-Layer header, then that fragment SHOULD be discarded and
	an ICMP Parameter Problem, Code 3, message should be sent to
	the source of the fragment, with the Pointer field set to zero.
	o If any of the fragments being reassembled overlap with any
	other fragments being reassembled for the same packet,
	reassembly of that packet MUST be abandoned and all the
	fragments that have been received for that packet MUST be
	discarded, and no ICMP error messages SHOULD be sent.
	It should be noted that fragments may be duplicated in the
	network. Instead of treating these exact duplicate fragments as
	overlapping fragments, an implementation MAY choose to detect
	this case and drop exact duplicate fragments while keeping the
	other fragments belonging to the same packet.
	The following conditions are not expected to occur frequently but are
	not considered errors if they do:
	The number and content of the headers preceding the Fragment		IPv4 extension headers normatively assumes the requirements of IPv6
	header of different fragments of the same original packet may		extension headers as defined in [RFC8200] section 4, with the
	differ. Whatever headers are present, preceding the Fragment		following modifications:
	header in each fragment packet, MUST be processed when the packets
	arrive and prior to queuing the fragments for reassembly. Only
	those headers in the Offset zero fragment packet are retained in
	the reassembled packet.
	Different IP options may appear in different fragments of the same		* References to the IPv6 header are replaced by references to the
	original packet. Whatever IP options are present are processed		IPv4 header.
	when the packets arrive prior to processing any extension headers
	or queuing the fragments for reassembly. Only the IP options in
	the Offset zero fragment packet are retained in the reassembled
	packet.
	The Next Header values in the Fragment headers of different		* ICMP errors sent in the course of processing extension headers
	fragments of the same original packet may differ. Only the value		use ICMPv4.
	from the Offset zero fragment packet is used for reassembly.
	Other fields in the IPv4 header may also vary across the fragments		* The IPv4 header Protocol field assumes the same role and
	being reassembled. Specifications that use these fields may		semantics with respect to extension headers as the IPv6 Next
	provide additional instructions if the basic mechanism of using		Header field.
	the values from the Offset zero fragment is not sufficient. For
	example, Section 5.3 of [RFC3168] describes how to combine the
	Explicit Congestion Notification (ECN) bits from different
	fragments to derive the ECN bits of the reassembled packet.
	2.6 Destination Options Header		* The Hop-by-Hop Options header is used to carry optional
			information that MAY be examined and processed by any node along
			a packet's delivery path.
	The Destination Options header is used to carry optional information		* If a legacy IPv4 destination node, one that does not support
	that need be examined only by a packet's destination node(s). The		IPv4 extension headers, receives a packet with extension headers
	Destination Options header is identified by a Next Header value of 60		then the packet will be processed as having an unknown protocol.
	in the immediately preceding header and has the following format:		It is expected that the packet will be discarded and an ICMP
			error is generated.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		* Extension headers or options that carry IPv6 specific data or
	| Next Header | Hdr Ext Len | |		are otherwise specific to IPv6 MUST not be used with IPv4
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		(Segment Routing [SRV6EH] for example). IPv4 variants of these
	| |		might be defined if achieving the same functionality in IPv4 is
	. .		desirable.
	. Options .
	. .
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Next Header 8-bit selector. Identifies the type of header		* References to the IPv6 Payload Length, for instance in
	immediately following the Destination Options		reassembly procedures, are interpreted as being the computed
	header. Uses the same values as the IPv4		IPv4 payload length (i.e. IPv4 Total Length minus the length of
	Protocol field [IANA-PN].		the IPv4 header).
	Hdr Ext Len 8-bit unsigned integer. Length of the		The following are modifications to fragmentation and reassembly
	Destination Options header in 8-octet units,		requirements:
	not including the first 8 octets.
	Options Variable-length field, of length such that the		* References to setting the Payload Length field in the IPv6
	complete Destination Options header is an		header are interpreted to be setting the Total Length in the
	integer multiple of 8 octets long. Contains		IPv4 header taking into account the IPv4 header length.
	one or more TLV-encoded options, as described
	in Section 2.2.
	The only destination options defined in this document are the Pad1		* When creating or modifying IPv4 headers in packets, the IPv4
	and PadN options specified in Section 2.2.		header checksum MUST be set correctly.
	2.7 No Next Header		* Different fragment packets MAY contain different IP options. The
			IP header and any options in the reassembled packet are taken
			from the first fragment packet (the one with offset of zero).
	The value 59 in the Protocol field of an IPv4 header or Next Header		* If the length and offset of a fragment are such that the Total
	field extension header indicates that there is nothing following that		Length of the packet reassembled from that fragment would exceed
	header. If the Total Length field of the IPv4 header indicates the		65,535 octets, then that fragment must be discarded and an ICMP
	presence of octets past the end of a header whose Next Header field		Parameter Problem, Code 0, message should be sent to the source
	contains 59, those octets must be ignored and passed on unchanged if		of the fragment, pointing to the Fragment Offset field of the
	the packet is forwarded.		fragment packet.
	2.8 Interaction with standard IPv4 mechanisms		2.2 Interaction with standard IPv4 mechanisms
	IPv4 extension headers may be used concurrently with IPv4 mechanisms		IPv4 extension headers may be used concurrently with IPv4 mechanisms
	such as IPv4 options and IPv4 fragmentation. This section discusses		such as IPv4 options and IPv4 fragmentation. This section discusses
	the interactions.		the interactions.
	2.8.1 IPv4 options and IPv4 extension headers		2.2.1 IPv4 options and IPv4 extension headers
	An IPv4 packet MAY contain both IPv4 options and extension headers.		An IPv4 packet MAY contain both IPv4 options and extension headers.
	IPv4 options are completely independent of IPv4 extension headers.		IPv4 options are completely independent of IPv4 extension headers.
	IPv4 options MUST be processed before processing any extension		IPv4 options MUST be processed before processing any extension
	headers per normal requirements of processing the IP header before		headers per normal requirements of processing the IP header before
	the IP payload.		the IP payload.
	2.8.2 IPv4 fragmentation and IPv4 extension headers		2.2.2 IPv4 fragmentation and IPv4 extension headers
	An IPv4 packet may be fragmented both by using a Fragment extension		An IPv4 packet may be fragmented both by using a Fragment extension
	header as well as by standard IPv4 fragmentation. The Fragment header		header as well as by standard IPv4 fragmentation. The Fragment header
	can only be set at the source, however intermediate devices can		can only be set at the source, however intermediate devices can
	fragment packets using standard IPv4 fragmentation. Standard IPv4		fragment packets using standard IPv4 fragmentation. Standard IPv4
	fragmentation at a source node MUST be done only after any extension		fragmentation at a source node MUST be done only after any extension
	headers are set in a packet or the packet was fragmented using the		headers are set in a packet or the packet was fragmented using the
	Fragment header. Specifically, fragmentation using the extension		Fragment header. Specifically, fragmentation using the extension
	header MUST NOT be done on packet fragments created by standard IPv4		header MUST NOT be done on packet fragments created by standard IPv4
	fragmentation. However, a packet fragment that contains a Fragment		fragmentation. However, a packet fragment that contains a Fragment
	skipping to change at page 21, line 4 ¶		skipping to change at page 8, line 47 ¶
	| | |		| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
	| |		| |
	~ Extension headers ~		~ Extension headers ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Transport packet ~		~ Transport packet ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The pertinent fields in the base GUE header are:		The pertinent fields in the base GUE header are:
	o Variant - set 0 for variant 0.		o Variant - set 0 for variant 0.
	o C bit - Control bit. Set to zero indicating a data message.		o C bit - Control bit. Set to zero indicating a data message.
	o Hlen - Header length of GUE header in four byte words not		o Hlen - Header length of GUE header in four byte words not
	including the first four bytes.		including the first four bytes.
	o Proto/ctype - The type of the encapsulated protocol. This is an		o Proto/ctype - The type of the encapsulated protocol. This is an
	IP protocol and may be an extension header. If the payload is		IP protocol and may be an extension header. If the payload is
	something other than an IP protocol or the payload is encrypted		something other than an IP protocol or the payload is encrypted
	or transformed, then this field is set to 59 (No Next Header)--		or transformed, then this field is set to 59 (No Next Header)--
	in this case the type of the payload is determined through other		in this case the type of the payload is determined through other
	means.		means.
	o M: Magic number bit. If this bit is set then the GUE magic		o M: Magic number bit. If this bit is set then the GUE magic
	number option is present. The GUE magic number option is		number option is present. The GUE magic number option is
	described below.		described below.
	Any of the GUE options defined in [GUEEXT] may be set in the packet.		Any of the GUE options defined in [GUEEXT] MAY be set in the packet.
	To facilitate maintaining the correct transport layer checksum across		To facilitate maintaining the correct transport layer checksum across
	NAT translation, the NAT checksum address option SHOULD be used		NAT translation, the NAT address checksum option SHOULD be used
	([GUEEXT]). The GUE magic number option, defined below, is used to		([GUEEXT]). The GUE magic number option, defined below, is used to
	help intermediate nodes correctly identify GUE packets.		help intermediate nodes correctly identify GUE packets.
	If a transport layer protocol is encapsulated in GUE then the IP		If a transport layer protocol is encapsulated in GUE then the IP
	header for the transport header is taken to be the IP header of the		header for the transport header is taken to be the IP header of the
	GUE/UDP packet. In particular, an encapsulated transport header may		GUE/UDP packet. In particular, an encapsulated transport header may
	have a checksum that includes the IP addresses in a pseudo header for		have a checksum that includes the IP addresses in a pseudo header for
	checksum calculation (TCP or UDP).		checksum calculation (TCP or UDP).
	3.2 GUE magic numbers		3.2 GUE magic numbers
	skipping to change at page 22, line 28 ¶		skipping to change at page 10, line 22 ¶
	To encapsulate extension headers, a sender inserts a UDP and GUE		To encapsulate extension headers, a sender inserts a UDP and GUE
	header between an IP header and the first extension header.		header between an IP header and the first extension header.
	If a sender encapsulates extension headers in GUE then it MUST NOT		If a sender encapsulates extension headers in GUE then it MUST NOT
	also set extension headers in the IPv4 or IPv6 header. When extension		also set extension headers in the IPv4 or IPv6 header. When extension
	headers are encapsulated in GUE, the Next Header field of the IPv6		headers are encapsulated in GUE, the Next Header field of the IPv6
	header or the Protocol field of the IPv4 header MUST be set to 17 to		header or the Protocol field of the IPv4 header MUST be set to 17 to
	indicate UDP.		indicate UDP.
	If the encapsulated transport protocol contains a checksum with a		If the encapsulated transport protocol contains a checksum with a
	pseudo header and the packet may traverse a NAT, then the NAT		pseudo header and the packet may traverse a NAT, then the NAT Address
	Checksum option SHOULD be set to allow the receiver to properly		Checksum option SHOULD be set to allow the receiver to properly
	adjust the received transport layer checksum. Other GUE options MAY		adjust the received transport layer checksum. Other GUE options MAY
	be set per the discretion of the sender.		be set per the discretion of the sender.
	If the packet being encapsulated contains a Hop-by-Hop extension		If the packet being encapsulated contains a Hop-by-Hop extension
	header then the Magic Number option MUST be used to allow		header then the Magic Number option MUST be used to allow
	intermediate nodes to process and potentially modify data in the		intermediate nodes to process and potentially modify data in the
	extension header. Note that in this case the proto/ctype field in the		extension header. Note that in this case the proto/ctype field in the
	GUE header MUST be zero indicating Hop-by-Hop options extension		GUE header MUST be zero indicating Hop-by-Hop options extension
	header.		header.
	skipping to change at page 23, line 15 ¶		skipping to change at page 11, line 9 ¶
	o The remote checksum option MAY be used concurrently with the		o The remote checksum option MAY be used concurrently with the
	magic number option under the assumption that intermediate nodes		magic number option under the assumption that intermediate nodes
	will not modify encapsulated transport checksum fields or		will not modify encapsulated transport checksum fields or
	attempt to verify an encapsulated transport layer checksum (in		attempt to verify an encapsulated transport layer checksum (in
	the latter case they could do that it they were to take the		the latter case they could do that it they were to take the
	remote checksum offload option into account).		remote checksum offload option into account).
	3.3.2 Destination Processing		3.3.2 Destination Processing
	Encapsulated extension headers in GUE is processed by normal methods		Encapsulated extension headers in GUE are processed by normal methods
	of processing GUE. As described in [GUE]:		of processing GUE. As described in [GUE]:
	If a valid data message is received, the UDP header and GUE header		If a valid data message is received, the UDP header and GUE header
	are removed from the packet. The outer IP header remains intact		are removed from the packet. The outer IP header remains intact
	and the next protocol in the IP header is set to the protocol from		and the next protocol in the IP header is set to the protocol from
	the proto field in the GUE header. The resulting packet is then		the proto field in the GUE header. The resulting packet is then
	resubmitted into the protocol stack to process that packet as		resubmitted into the protocol stack to process that packet as
	though it was received with the protocol in the GUE header.		though it was received with the protocol in the GUE header.
	In the case that the GUE packet contains extension headers, the		In the case that the GUE packet contains extension headers, the
	skipping to change at page 24, line 5 ¶		skipping to change at page 11, line 46 ¶
	might contain Hop-by-Hop options to process.		might contain Hop-by-Hop options to process.
	Processing of packets with encapsulated Hop-by-Hop options has the		Processing of packets with encapsulated Hop-by-Hop options has the
	following flow:		following flow:
	1) Match destination UDP port number to be GUE.		1) Match destination UDP port number to be GUE.
	2) If the GUE variant is not zero or the C bit is set (control		2) If the GUE variant is not zero or the C bit is set (control
	message) then discontinue payload processing.		message) then discontinue payload processing.
	3) If magic number option is not present in the GUE header then		3) If proto/ctype value is not zero (not Hop-by-Hop options) then
	discontinue payload processing.		discontinue payload processing.
	4) If proto/ctype value is not zero (not Hop-by-Hop options) then		5) If magic number option is not present in the GUE header then
	discontinue payload processing.		discontinue payload processing.
	5) If the GUE header indicates that a fragment option or payload		5) Compare the magic number value in the GUE header to the
	transform option is present then discontinue payload
	processing.
	6) If the checksum option is present and the payload coverage is
	non-zero then discontinue payload processing.
	7) If the alternate checksum option is present and the payload
	coverage is non-zero then discontinue payload processing.
	8) If the HMAC security option is present and the Payload length
	is not zero then discontinue payload processing.
	9) Compare the magic number value in the GUE header to the
	defined value. If they are not equal then discontinue payload		defined value. If they are not equal then discontinue payload
	processing		processing
	10) If the GUE checksum option is present (and payload coverage is		6) If the GUE checksum option is present (and payload coverage is
	zero) then the GUE checksum MAY be validated. If checksum		zero) then the GUE checksum MAY be validated. If checksum
	validation fails, then discontinue payload processing		validation fails, then discontinue payload processing
	11) If the alternate checksum is present (and payload coverage is		7) If the alternate checksum is present (and payload coverage is
	zero) then the alternate checksum MAY be validated. If		zero) then the alternate checksum MAY be validated. If
	alternate checksum validation fails, then discontinue payload		alternate checksum validation fails, then discontinue payload
	processing		processing
	12) Process the encapsulated Hop-by-Hop options. If a Hop-by-Hop		8) Process the encapsulated Hop-by-Hop options. If a Hop-by-Hop
	option is modified then the outer UDP checksum MUST be updated		option is modified then the outer UDP checksum MUST be updated
	to reflect the change.		to reflect the change.
	Note that intermediate MUST not modify any fields other then data in		Note that an intermediate node MUST not modify any fields other then
	modifiable Hop-by-Hop options or the UDP checksum which needs to be		data in modifiable Hop-by-Hop options or the UDP checksum which needs
	updated when UDP payload is modified. In particular, intermediate		to be updated when UDP payload is modified. In particular,
	nodes MUST NOT modify the GUE header nor an data aside from that in		intermediate nodes MUST NOT modify the GUE header nor an data aside
	modifiable Hop-by-Hop options.		from that in modifiable Hop-by-Hop options.
	4 Security Considerations		4 The IPv4 flow label
			As stated in [RFC6864]:
			">> Originating sources MAY set the IPv4 ID field of atomic
			datagrams to any value."
			This specification allows the IPv4 ID to be used as a flow label in
			atomic datagrams. Atomic datagrams are IPv4 packets for which
			(DF==1)&&(MF==0)&&(frag_offset==0).
			4.1 Sender requirements
			An origin host MAY set the IPv4 Identification field as a flow label
			in atomic packets. The IPv4 flow label is set following the same
			procedures for setting the IPv6 flow label as described in [RFC6437],
			with the following modifications:
			* The Identification field MUST NOT be used as a flow label in
			non-atomic fragments.
			* Only stateless flow labels can be set.
			* The value to set, e.g. from a hash computation over packet
			headers, is truncated to sixteen bits (the size of the
			Identification field).
			* If the IPv4 Identification field is not used as a flow label in
			atomic fragments, it SHOULD be set to zero.
			* Intermediate nodes MUST NOT set the Identification field in
			atomic datagrams.
			4.2 Receiver requirements
			Receivers, including intermediate hosts, MAY process non-zero
			Identification fields in IPv4 header of atomic datagrams as being a
			flow label. The IPv4 flow label for instance can be used as input to
			ECMP as described in [RFC6438].
			It is RECOMMENDED that a receiver only consumes the flow label if
			other typical means flow classification, such as parsing the
			transport layer headers to extract port numbers for the flow, are not
			available. For instance, the IPv4 flow label could be used for flow
			based packet steering if a router encounters a packet with a protocol
			that is unknown to it.
			5 Security Considerations
	This specification enables use of IPv6 extension headers in IPv4.		This specification enables use of IPv6 extension headers in IPv4.
	Related security mechanisms of IPv6 extension headers can be applied		Related security mechanisms of IPv6 extension headers can be applied
	for use with IPv4 extension headers.		for use with IPv4 extension headers.
	When extension headers are encapsulated in GUE, normal GUE security		When extension headers are encapsulated in GUE, normal GUE security
	mechanisms can be used. If an intermediate node might modify GUE		mechanisms can be used. If an intermediate node might modify GUE
	payload to process modifiable extension headers, then a GUE security		payload to process modifiable extension headers, then a GUE security
	algorithm cannot take input to authenticate the GUE payload. If		algorithm cannot take input to authenticate the GUE payload. If
	authentication is necessary, then an Authentication header may be		authentication is necessary, then an Authentication header may be
	used that treats modifiable data fields as zero-valued octets when		used that treats modifiable data fields as zero-valued octets when
	computing or verifying the packet's authenticating value.		computing or verifying the packet's authenticating value.
	5 IANA Considerations		The IPv4 flow label has similar security properties as the IPv6 flow
			label. If the security intent of the sender is to prevent
			intermediate nodes in the network from classifying its traffic into
			flows then the IPv4 flow label SHOULD NOT be used.
	IANA is requested to assign a value in the "GUE flag-fields" resigtry		6 IANA Considerations
			IANA is requested to assign a value in the "GUE flag-fields" registry
	for the Magic Number option.		for the Magic Number option.
	+-------------+---------------+-------------+--------------------+		+-------------+---------------+-------------+--------------------+
	| Flags bits | Field size | Description | Reference |		| Flags bits | Field size | Description | Reference |
	+-------------+---------------+-------------+--------------------+		+-------------+---------------+-------------+--------------------+
	| Bit 10 | 8 bytes | Magic number| This document |		| Bit 10 | 8 bytes | Magic number| This document |
	+-------------+---------------+-------------+--------------------+		+-------------+---------------+-------------+--------------------+
	6 References		7 References
	6.1 Normative References		7.1 Normative References
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
	1981.		1981.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200, DOI		(IPv6) Specification", STD 86, RFC 8200, DOI
	10.17487/RFC8200, July 2017, <https://www.rfc-		10.17487/RFC8200, July 2017, <https://www.rfc-
	editor.org/info/rfc8200>.		editor.org/info/rfc8200>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of		[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
	Explicit Congestion Notification (ECN) to IP", RFC 3168,		RFC 6864, DOI 10.17487/RFC6864, February 2013,
	DOI 10.17487/RFC3168, September 2001, <https://www.rfc-		<https://www.rfc-editor.org/info/rfc6864>.
	editor.org/info/rfc3168>.
	[GUE] Herbert, T., Yong, L., Zia, )., "Generic UDP		[GUE] Herbert, T., Yong, L., Zia, )., "Generic UDP
	Encapsulation", draft-ietf-intarea-gue-06		Encapsulation", draft-ietf-intarea-gue-07
	6.2 Informative References		7.2 Informative References
	[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations		[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations
	on the Dropping of Packets with IPv6 Extension Headers in		on the Dropping of Packets with IPv6 Extension Headers in
	the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016,		the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016,
	<https://www.rfc-editor.org/info/rfc7872>.		<https://www.rfc-editor.org/info/rfc7872>.
	[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>.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI		[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
	10.17487/RFC4302, December 2005, <https://www.rfc-		"IPv6 Flow Label Specification", RFC 6437, DOI
	editor.org/info/rfc4302>.		10.17487/RFC6437, November 2011, <https://www.rfc-
			editor.org/info/rfc6437>.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
	4303, DOI 10.17487/RFC4303, December 2005,
	<https://www.rfc-editor.org/info/rfc4303>.
	[RFC7739] Gont, F., "Security Implications of Predictable Fragment
	Identification Values", RFC 7739, DOI 10.17487/RFC7739,
	February 2016, <https://www.rfc-editor.org/info/rfc7739>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of		[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for
	Explicit Congestion Notification (ECN) to IP", RFC 3168,		Equal Cost Multipath Routing and Link Aggregation in
	DOI 10.17487/RFC3168, September 2001, <https://www.rfc-		Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
	editor.org/info/rfc3168>.		<https://www.rfc-editor.org/info/rfc6438>.
	[IPNOPT] Rodrigo Fonseca, George Manning Porter, Randy H. Katz,		[IPNOPT] Rodrigo Fonseca, George Manning Porter, Randy H. Katz,
	Scott Shenker and Ion Stoica, "IP Options are not an		Scott Shenker and Ion Stoica, "IP Options are not an
	option",		option",
	<https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-		<https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-
	2005-24.html>		2005-24.html>
	[FAST] Herbert, T., "Firewall and Service Tickets", draft-herbert-		[FAST] Herbert, T., "Firewall and Service Tickets", draft-herbert-
	fast-03		fast-03
	skipping to change at page 27, line 10 ¶		skipping to change at page 16, line 7 ¶
	ietf-6man-segment-routing-header-16		ietf-6man-segment-routing-header-16
	[IANA-PN] IANA, "Protocol Numbers",		[IANA-PN] IANA, "Protocol Numbers",
	<https://www.iana.org/assignments/protocol-numbers>.		<https://www.iana.org/assignments/protocol-numbers>.
	[IANA-EH] IANA, "IPv6 Extension Header Types",		[IANA-EH] IANA, "IPv6 Extension Header Types",
	<https://www.iana.org/assignments/ipv6-parameters>.		<https://www.iana.org/assignments/ipv6-parameters>.
	[GUEEXT] Herbert, T., Yong, L., and Templin, F., "Extensions for		[GUEEXT] Herbert, T., Yong, L., and Templin, F., "Extensions for
	Generic UDP Encapsulation", draft-ietf-intarea-gue-		Generic UDP Encapsulation", draft-ietf-intarea-gue-
	extensions-05		extensions-07
	Author's Address		Author's Address
	Tom Herbert		Tom Herbert
	Quantonium		Quantonium
	Santa Clara, CA		Santa Clara, CA
	USA		USA
	Email: tom@quantonium.net		Email: tom@quantonium.net
End of changes. 50 change blocks.
	733 lines changed or deleted		181 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/