draft-ietf-6man-rfc6434-bis-06.txt		draft-ietf-6man-rfc6434-bis-07.txt
	Internet Engineering Task Force T. Chown		Internet Engineering Task Force T. Chown
	Internet-Draft Jisc		Internet-Draft Jisc
	Obsoletes: 6434 (if approved) J. Loughney		Obsoletes: 6434 (if approved) J. Loughney
	Intended status: Best Current Practice Intel		Intended status: Best Current Practice Intel
	Expires: September 4, 2018 T. Winters		Expires: September 4, 2018 T. Winters
	UNH-IOL		UNH-IOL
	March 3, 2018		March 3, 2018
	IPv6 Node Requirements		IPv6 Node Requirements
	draft-ietf-6man-rfc6434-bis-06		draft-ietf-6man-rfc6434-bis-07
	Abstract		Abstract
	This document defines requirements for IPv6 nodes. It is expected		This document defines requirements for IPv6 nodes. It is expected
	that IPv6 will be deployed in a wide range of devices and situations.		that IPv6 will be deployed in a wide range of devices and situations.
	Specifying the requirements for IPv6 nodes allows IPv6 to function		Specifying the requirements for IPv6 nodes allows IPv6 to function
	well and interoperate in a large number of situations and		well and interoperate in a large number of situations and
	deployments.		deployments.
	This document obsoletes RFC 6434, and in turn RFC 4294.		This document obsoletes RFC 6434, and in turn RFC 4294.
	skipping to change at page 7, line 10 ¶		skipping to change at page 7, line 10 ¶
	See [RFC5722] for more information.		See [RFC5722] for more information.
	As recommended in [RFC8021], nodes MUST NOT generate atomic		As recommended in [RFC8021], nodes MUST NOT generate atomic
	fragments, i.e., where the fragment is a whole datagram. As per		fragments, i.e., where the fragment is a whole datagram. As per
	[RFC6946], if a receiving node reassembling a datagram encounters an		[RFC6946], if a receiving node reassembling a datagram encounters an
	atomic fragment, it should be processed as a fully reassembled		atomic fragment, it should be processed as a fully reassembled
	packet, and any other fragments that match this packet should be		packet, and any other fragments that match this packet should be
	processed independently.		processed independently.
	[RFC6946] discusses IPv6 atomic fragments, and recommends that IPv6
	atomic fragments are processed independently of any other fragments,
	to protect against fragmentation-based attacks.
	To mitigate a variety of potential attacks, nodes SHOULD avoid using		To mitigate a variety of potential attacks, nodes SHOULD avoid using
	predictable fragment Identification values in Fragment Headers, as		predictable fragment Identification values in Fragment Headers, as
	discussed in [RFC7739].		discussed in [RFC7739].
	All nodes SHOULD support the setting and use of the IPv6 Flow Label		All nodes SHOULD support the setting and use of the IPv6 Flow Label
	field as defined in the IPv6 Flow Label specification [RFC6437].		field as defined in the IPv6 Flow Label specification [RFC6437].
	Forwarding nodes such as routers and load distributors MUST NOT		Forwarding nodes such as routers and load distributors MUST NOT
	depend only on Flow Label values being uniformly distributed. It is		depend only on Flow Label values being uniformly distributed. It is
	RECOMMENDED that source hosts support the flow label by setting the		RECOMMENDED that source hosts support the flow label by setting the
	Flow Label field for all packets of a given flow to the same value		Flow Label field for all packets of a given flow to the same value
End of changes. 2 change blocks.
	5 lines changed or deleted		1 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/