< draft-ietf-6man-flow-3697bis-06.txt		draft-ietf-6man-flow-3697bis-07.txt >
	6MAN S. Amante		6MAN S. Amante
	Internet-Draft Level 3		Internet-Draft Level 3
	Obsoletes: 3697 (if approved) B. Carpenter		Obsoletes: 3697 (if approved) B. Carpenter
	Updates: 2205, 2460 (if approved) Univ. of Auckland		Updates: 2205, 2460 (if approved) Univ. of Auckland
	Intended status: Standards Track S. Jiang		Intended status: Standards Track S. Jiang
	Expires: January 12, 2012 Huawei Technologies Co., Ltd		Expires: January 30, 2012 Huawei Technologies Co., Ltd
	J. Rajahalme		J. Rajahalme
	Nokia Siemens Networks		Nokia Siemens Networks
	July 11, 2011		July 29, 2011
	IPv6 Flow Label Specification		IPv6 Flow Label Specification
	draft-ietf-6man-flow-3697bis-06		draft-ietf-6man-flow-3697bis-07
	Abstract		Abstract
	This document specifies the IPv6 Flow Label field and the minimum		This document specifies the IPv6 Flow Label field and the minimum
	requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding		requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding
	labeled packets, and flow state establishment methods. Even when		labeled packets, and flow state establishment methods. Even when
	mentioned as examples of possible uses of the flow labeling, more		mentioned as examples of possible uses of the flow labeling, more
	detailed requirements for specific use cases are out of scope for		detailed requirements for specific use cases are out of scope for
	this document.		this document.
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on January 12, 2012.		This Internet-Draft will expire on January 30, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 12 ¶		skipping to change at page 3, line 12 ¶
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. IPv6 Flow Label Specification . . . . . . . . . . . . . . . . 5		2. IPv6 Flow Label Specification . . . . . . . . . . . . . . . . 5
	3. Flow Labeling Requirements in the Stateless Scenario . . . . . 6		3. Flow Labeling Requirements in the Stateless Scenario . . . . . 6
	4. Flow State Establishment Requirements . . . . . . . . . . . . 8		4. Flow State Establishment Requirements . . . . . . . . . . . . 8
	5. Essential correction to RFC 2205 . . . . . . . . . . . . . . . 8		5. Essential correction to RFC 2205 . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6.1. Covert Channel Risk . . . . . . . . . . . . . . . . . . . 9		6.1. Covert Channel Risk . . . . . . . . . . . . . . . . . . . 9
	6.2. Theft and Denial of Service . . . . . . . . . . . . . . . 9		6.2. Theft and Denial of Service . . . . . . . . . . . . . . . 10
	6.3. IPsec and Tunneling Interactions . . . . . . . . . . . . . 11		6.3. IPsec and Tunneling Interactions . . . . . . . . . . . . . 11
	6.4. Security Filtering Interactions . . . . . . . . . . . . . 12		6.4. Security Filtering Interactions . . . . . . . . . . . . . 12
	7. Differences from RFC 3697 . . . . . . . . . . . . . . . . . . 12		7. Differences from RFC 3697 . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	10. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 13		10. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 13
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 14		11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	11.2. Informative References . . . . . . . . . . . . . . . . . . 14		11.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. Example 20-bit Hash Function . . . . . . . . . . . . 15		Appendix A. Example 20-bit Hash Function . . . . . . . . . . . . 15
	skipping to change at page 4, line 35 ¶		skipping to change at page 4, line 35 ¶
	classification, where only IPv6 main header fields in fixed positions		classification, where only IPv6 main header fields in fixed positions
	are used.		are used.
	The flow label could be used in both stateless and stateful		The flow label could be used in both stateless and stateful
	scenarios. A stateless scenario is one where any node that processes		scenarios. A stateless scenario is one where any node that processes
	the flow label in any way does not need to store any information		the flow label in any way does not need to store any information
	about a flow before or after a packet has been processed. A stateful		about a flow before or after a packet has been processed. A stateful
	scenario is one where a node that processes the flow label value		scenario is one where a node that processes the flow label value
	needs to store information about the flow, including the flow label		needs to store information about the flow, including the flow label
	value. A stateful scenario might also require a signaling mechanism		value. A stateful scenario might also require a signaling mechanism
	to establish flow state in the network.		to inform downstream nodes that the flow label is being used in a
			certain way and to establish flow state in the network. For example,
			RSVP [RFC2205] and GIST [RFC5971] can signal flow label values.
	The flow label can be used most simply in stateless scenarios. This		The flow label can be used most simply in stateless scenarios. This
	specification concentrates on the stateless model and how it can be		specification concentrates on the stateless model and how it can be
	used as a default mechanism. Details of stateful models, signaling,		used as a default mechanism. Details of stateful models, signaling,
	specific flow state establishment methods and their related service		specific flow state establishment methods and their related service
	models are out of scope for this specification. The basic		models are out of scope for this specification. The basic
	requirement for stateful models is set forth in Section 4.		requirement for stateful models is set forth in Section 4.
	The minimum level of IPv6 flow support consists of labeling the		The minimum level of IPv6 flow support consists of labeling the
	flows. A specific goal is to enable and encourage the use of the		flows. A specific goal is to enable and encourage the use of the
	flow label for various forms of stateless load distribution,		flow label for various forms of stateless load distribution,
	especially across Equal Cost Multi-Path (EMCP) and/or Link		especially across Equal Cost Multi-Path (EMCP) and/or Link
	Aggregation Group (LAG) paths. ECMP and LAG are methods to bond		Aggregation Group (LAG) paths. ECMP and LAG are methods to bond
	together multiple physical links used to procure the required		together multiple physical links used to procure the required
	capacity necessary to carry an offered load greater than the		capacity necessary to carry an offered load greater than the
	bandwidth of an individual physical link. IPv6 source nodes SHOULD		bandwidth of an individual physical link. Further details are in a
	be able to label known flows (e.g., TCP connections, application		separate document [I-D.ietf-6man-flow-ecmp]. IPv6 source nodes
	streams), even if the node itself does not require any flow-specific		SHOULD be able to label known flows (e.g., TCP connections,
	treatment. Node requirements for stateless flow labeling are given		application streams), even if the node itself does not require any
	in Section 3.		flow-specific treatment. Node requirements for stateless flow
			labeling are given in Section 3.
	This document replaces [RFC3697] and Section 6 and Appendix A of		This document replaces [RFC3697] and Section 6 and Appendix A of
	[RFC2460]. A rationale for the changes made is documented in		[RFC2460]. A rationale for the changes made is documented in
	[I-D.ietf-6man-flow-update]. The present document also includes a		[I-D.ietf-6man-flow-update]. The present document also includes a
	correction to [RFC2205] concerning the flow label.		correction to [RFC2205] concerning the flow label.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	2. IPv6 Flow Label Specification		2. IPv6 Flow Label Specification
	The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a		The 20-bit Flow Label field in the IPv6 header [RFC2460] is used by a
	node to label packets of a flow. A Flow Label of zero is used to		node to label packets of a flow. A Flow Label of zero is used to
	indicate packets that have not been labeled. Packet classifiers can		indicate packets that have not been labeled. Packet classifiers can
	use the triplet of Flow Label, Source Address, and Destination		use the triplet of Flow Label, Source Address, and Destination
	Address fields to identify which flow a particular packet belongs to.		Address fields to identify which flow a particular packet belongs to.
	Packets are processed in a flow-specific manner by nodes that are		Packets are processed in a flow-specific manner by nodes that are
	able to do so in a stateless manner, or that have been set up with		able to do so in a stateless manner, or that have been set up with
	skipping to change at page 5, line 47 ¶		skipping to change at page 6, line 5 ¶
	probability distribution in which each value in a given range of		probability distribution in which each value in a given range of
	equally spaced values (such as a sequence of integers) is equally		equally spaced values (such as a sequence of integers) is equally
	likely to be chosen as the next value. The values in such a		likely to be chosen as the next value. The values in such a
	distribution exhibit both variability and unguessability. Thus, as		distribution exhibit both variability and unguessability. Thus, as
	specified below in Section 3, an approximation to a discrete uniform		specified below in Section 3, an approximation to a discrete uniform
	distribution is preferable as the source of flow label values.		distribution is preferable as the source of flow label values.
	Intentionally, there are no precise mathematical requirements placed		Intentionally, there are no precise mathematical requirements placed
	on the distribution or the method used to achieve such a		on the distribution or the method used to achieve such a
	distribution.		distribution.
	Once set to a non-zero value, the Flow Label MUST be delivered		Once set to a non-zero value, the Flow Label is expected to be
	unchanged to the destination node(s). That is, a forwarding node		delivered unchanged to the destination node(s). A forwarding node
	MUST NOT change the flow label value in an arriving packet if it is		MUST either leave a non-zero flow label value unchanged, or change it
	non-zero. A possible exception to this rule is if a security gateway		only for compelling operational security reasons as described in
	for operational security reasons changes a non-zero Flow Label value		Section 6.1.
	to a different non-zero value compliant with this RFC; see
	Section 6.1 for details.
	There is no way to verify whether a flow label has been modified en		There is no way to verify whether a flow label has been modified en
	route or whether it belongs to a uniform distribution. Therefore, no		route or whether it belongs to a uniform distribution. Therefore, no
	Internet-wide mechanism can depend mathematically on unmodified and		Internet-wide mechanism can depend mathematically on unmodified and
	uniformly distributed flow labels; they have a "best effort" quality.		uniformly distributed flow labels; they have a "best effort" quality.
	Implementers should be aware that the flow label is an unprotected		Implementers should be aware that the flow label is an unprotected
	field that could have been accidentally or intentionally changed en		field that could have been accidentally or intentionally changed en
	route (see Section 6). This leads to the following formal rule:		route (see Section 6). This leads to the following formal rule:
	o Forwarding nodes such as routers and load distributors MUST NOT		o Forwarding nodes such as routers and load distributors MUST NOT
	depend only on Flow Label values being uniformly distributed. In		depend only on Flow Label values being uniformly distributed. In
	any usage such as a hash key for load distribution, the Flow Label		any usage such as a hash key for load distribution, the Flow Label
	bits MUST be combined at least with bits from other sources within		bits MUST be combined at least with bits from other sources within
	the packet, so as to produce a constant hash value for each flow		the packet, so as to produce a constant hash value for each flow
	and a suitable distribution of hash values across flows.		and a suitable distribution of hash values across flows.
	Typically the other fields used will be some or all components of		Typically the other fields used will be some or all components of
	the usual 5-tuple. In this way, load distribution will still		the usual 5-tuple. In this way, load distribution will still
	occur even if the Flow Label values are poorly distributed.		occur even if the Flow Label values are poorly distributed.
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 26 ¶
	fixed position might assist traffic analysis and cryptoanalysis.		fixed position might assist traffic analysis and cryptoanalysis.
	The flow label is not protected in any way, even if IPsec		The flow label is not protected in any way, even if IPsec
	authentication [RFC4302] is in use, so it can be forged by an on-path		authentication [RFC4302] is in use, so it can be forged by an on-path
	attacker. Implementers are advised that any en-route change to the		attacker. Implementers are advised that any en-route change to the
	flow label value is undetectable. On the other hand, a uniformly		flow label value is undetectable. On the other hand, a uniformly
	distributed pseudo-random flow label cannot be readily guessed by an		distributed pseudo-random flow label cannot be readily guessed by an
	attacker; see [I-D.gont-6man-flowlabel-security] for further		attacker; see [I-D.gont-6man-flowlabel-security] for further
	discussion. If a hash algorithm is used, as suggested in Section 3,		discussion. If a hash algorithm is used, as suggested in Section 3,
	it SHOULD include a step that makes the flow-label value		it SHOULD include a step that makes the flow-label value
	significantly difficult to predict, even with knowledge of the		significantly difficult to predict [RFC4086], even with knowledge of
	algorithm being used.		the algorithm being used.
	6.1. Covert Channel Risk		6.1. Covert Channel Risk
	The flow label could be used as a covert data channel, since		The flow label could be used as a covert data channel, since
	apparently pseudo-random flow label values could in fact consist of		apparently pseudo-random flow label values could in fact consist of
	covert data [NSA]. This could for example be achieved using a series		covert data [NSA]. This could for example be achieved using a series
	of otherwise innocuous UDP packets whose flow label values constitute		of otherwise innocuous UDP packets whose flow label values constitute
	a covert message, or by co-opting a TCP session to carry a covert		a covert message, or by co-opting a TCP session to carry a covert
	message in the flow labels of successive packets. Both of these		message in the flow labels of successive packets. Both of these
	could be recognised as suspicious - the first because isolated UDP		could be recognised as suspicious - the first because isolated UDP
	skipping to change at page 9, line 44 ¶		skipping to change at page 9, line 49 ¶
	and the second because the flow label values in a given TCP session		and the second because the flow label values in a given TCP session
	should all be equal. However, other methods, such as co-opting the		should all be equal. However, other methods, such as co-opting the
	flow labels of occasional packets, might be rather hard to detect.		flow labels of occasional packets, might be rather hard to detect.
	In situations where the covert channel risk is considered		In situations where the covert channel risk is considered
	significant, the only certain defense is for a firewall to rewrite		significant, the only certain defense is for a firewall to rewrite
	non-zero flow labels. This would be an exceptional violation of the		non-zero flow labels. This would be an exceptional violation of the
	rule that the flow label, once set to a non-zero value, must not be		rule that the flow label, once set to a non-zero value, must not be
	changed. To preserve load distribution capability, such a firewall		changed. To preserve load distribution capability, such a firewall
	SHOULD rewrite labels by following the method described for a		SHOULD rewrite labels by following the method described for a
	forwarding node (see Section 3) and MUST NOT set non-zero flow labels		forwarding node (see Section 3), as if the incoming label value were
	to zero.		zero, and MUST NOT set non-zero flow labels to zero. This behaviour
			is nevertheless undesirable, since (as discussed in Section 3), only
			source nodes have straightforward access to the complete 5-tuple.
	6.2. Theft and Denial of Service		6.2. Theft and Denial of Service
	Since the mapping of network traffic to flow-specific treatment is		Since the mapping of network traffic to flow-specific treatment is
	triggered by the IP addresses and Flow Label value of the IPv6		triggered by the IP addresses and Flow Label value of the IPv6
	header, an adversary may be able to obtain unintended service by		header, an adversary may be able to obtain a class of service that
	modifying the IPv6 header or by injecting packets with false		the network did not intend to provide by modifying the IPv6 header or
	addresses and/or labels. Theft of service is not further discussed		by injecting packets with false addresses and/or labels. A concrete
	in this document, since it can only be analysed for specific stateful		analysis of this threat is only possible for specific stateful
	methods of using the flow label. However, a denial of service attack		methods of signaling and using the flow label, which are out of scope
	becomes possible in the stateless model when the modified or injected		for this document. Clearly, a full analysis will be required when
	traffic depletes the resources available to forward it and other		any such method is specified, but in general networks SHOULD NOT make
	traffic streams. If a DoS attack were undertaken against a given		resource allocation decisions based on flow labels without some
	Flow Label (or set of Flow Labels), then traffic containing an		external means of assurance.
	affected Flow Label might well experience worse-than-best-effort
	network performance.		A denial of service attack [RFC4732] becomes possible in the
			stateless model when the modified or injected traffic depletes the
			resources available to forward it and other traffic streams. If a
			DoS attack were undertaken against a given Flow Label (or set of Flow
			Labels), then traffic containing an affected Flow Label might well
			experience worse-than-best-effort network performance.
	Note that since the treatment of IP headers by nodes is typically		Note that since the treatment of IP headers by nodes is typically
	unverified, there is no guarantee that flow labels sent by a node are		unverified, there is no guarantee that flow labels sent by a node are
	set according to the recommendations in this document. A man-in-the-		set according to the recommendations in this document. A man-in-the-
	middle or injected-traffic denial of service attack specifically		middle or injected-traffic denial of service attack specifically
	directed at flow label handling would involve setting unusual flow		directed at flow label handling would involve setting unusual flow
	labels. For example, an attacker could set all flow labels reaching		labels. For example, an attacker could set all flow labels reaching
	a given router to the same arbitrary non-zero value, or could perform		a given router to the same arbitrary non-zero value, or could perform
	rapid cycling of flow label values such that the packets of a given		rapid cycling of flow label values such that the packets of a given
	flow will each have a different value. Either of these attacks would		flow will each have a different value. Either of these attacks would
	skipping to change at page 12, line 16 ¶		skipping to change at page 12, line 23 ¶
	The Flow Label does nothing to eliminate the need for packet		The Flow Label does nothing to eliminate the need for packet
	filtering based on headers past the IP header, if such filtering is		filtering based on headers past the IP header, if such filtering is
	deemed necessary for security reasons on nodes such as firewalls or		deemed necessary for security reasons on nodes such as firewalls or
	filtering routers.		filtering routers.
	7. Differences from RFC 3697		7. Differences from RFC 3697
	The main differences between this specification and its predecessor		The main differences between this specification and its predecessor
	are as follows:		are as follows:
	o This specification encourages non-zero flow label values to be		o This specification encourages non-zero flow label values to be
	used, and clearly defines how to set a non-zero value.		used, and clearly defines how to set a non-zero value.
	o It encourages a stateless model with uniformly distributed flow		o It encourages a stateless model with uniformly distributed flow
	label values.		label values.
	o It does not specify any details of a stateful model.		o It does not specify any details of a stateful model.
	o It retains the rule that the flow label must not be changed en		o It retains the rule that the flow label must not be changed en
	route, but allows routers to set the label on behalf of hosts that		route, but allows routers to set the label on behalf of hosts that
	do not do so.		do not do so.
	o It discusses the covert channel risk and its consequences for		o It discusses the covert channel risk and its consequences for
	firewalls.		firewalls.
	For further details see [I-D.ietf-6man-flow-update].		For further details see [I-D.ietf-6man-flow-update].
	8. IANA Considerations		8. IANA Considerations
	This document requests no action by IANA.		This document requests no action by IANA.
	9. Acknowledgements		9. Acknowledgements
	Valuable comments and contributions were made by Jari Arkko, Ran		Valuable comments and contributions were made by Jari Arkko, Ran
	Atkinson, Fred Baker, Steve Blake, Remi Despres, Alan Ford, Fernando		Atkinson, Fred Baker, Richard Barnes, Steve Blake, Remi Despres, Alan
	Gont, Brian Haberman, Tony Hain, Joel Halpern, Qinwen Hu, Chris		Ford, Fernando Gont, Brian Haberman, Tony Hain, Joel Halpern, Qinwen
	Morrow, Thomas Narten, Mark Smith, Pascal Thubert, Iljitsch van		Hu, Chris Morrow, Thomas Narten, Mark Smith, Pascal Thubert, Iljitsch
	Beijnum, and other participants in the 6man working group.		van Beijnum, and other participants in the 6man working group.
	Cristian Calude suggested the von Neumann algorithm in Appendix A.		Cristian Calude suggested the von Neumann algorithm in Appendix A.
	David Malone and Donald Eastlake gave additional input about hash		David Malone and Donald Eastlake gave additional input about hash
	algorithms.		algorithms.
	Steve Deering and Alex Conta were co-authors of RFC 3697, on which		Steve Deering and Alex Conta were co-authors of RFC 3697, on which
	this document is based.		this document is based.
	Contributors to the original development of RFC 3697 included Ran		Contributors to the original development of RFC 3697 included Ran
	Atkinson, Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony		Atkinson, Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony
	Hain, Robert Hancock, Bob Hinden, Christian Huitema, Frank		Hain, Robert Hancock, Bob Hinden, Christian Huitema, Frank
	Kastenholz, Thomas Narten, Charles Perkins, Pekka Savola, Hesham		Kastenholz, Thomas Narten, Charles Perkins, Pekka Savola, Hesham
	Soliman, Michael Thomas, Margaret Wasserman, and Alex Zinin.		Soliman, Michael Thomas, Margaret Wasserman, and Alex Zinin.
	This document was produced using the xml2rfc tool [RFC2629].		This document was produced using the xml2rfc tool [RFC2629].
	10. Change log [RFC Editor: Please remove]		10. Change log [RFC Editor: Please remove]
			draft-ietf-6man-flow-3697bis-06: resolved IESG comments, 2011-07-29.
	draft-ietf-6man-flow-3697bis-06: resolved IETF Last Call comments,		draft-ietf-6man-flow-3697bis-06: resolved IETF Last Call comments,
	2011-07-11.		2011-07-11.
	draft-ietf-6man-flow-3697bis-05: resolved AD comments, improved hash		draft-ietf-6man-flow-3697bis-05: resolved AD comments, improved hash
	algorithm, 2011-06-29.		algorithm, 2011-06-29.
	draft-ietf-6man-flow-3697bis-04: update to resolve further WG		draft-ietf-6man-flow-3697bis-04: update to resolve further WG
	comments, 2011-05-11:		comments, 2011-05-11:
	o Suggested a specific hash algorithm to generate a flow label.		o Suggested a specific hash algorithm to generate a flow label.
	o Removed reference to stateful domain.		o Removed reference to stateful domain.
	o Added text about covert channel and tuned text about firewall		o Added text about covert channel and tuned text about firewall
	behavior; removed the confusing word "immutable".		behavior; removed the confusing word "immutable".
	o Added that Section 6 of RFC 2460 is replaced.		o Added that Section 6 of RFC 2460 is replaced.
	o Editorial fixes.		o Editorial fixes.
	draft-ietf-6man-flow-3697bis-03: update to resolve WGLC comments,		draft-ietf-6man-flow-3697bis-03: update to resolve WGLC comments,
	2011-05-02:		2011-05-02:
	o Clarified that the network layer view of flows is agnostic about		o Clarified that the network layer view of flows is agnostic about
	transport sessions.		transport sessions.
	o Honed the definition of stateless v stateful models.		o Honed the definition of stateless v stateful models.
	o Honed the text about using a pseudo-random function.		o Honed the text about using a pseudo-random function.
	o Moved material about violation of immutability to Security		o Moved material about violation of immutability to Security
	section, and rephrased accordingly.		section, and rephrased accordingly.
	o Dropped material about setting the flow label at a domain exit		o Dropped material about setting the flow label at a domain exit
	router: doesn't belong here now that we have dropped almost all		router: doesn't belong here now that we have dropped almost all
	the stateful text.		the stateful text.
	o Removed normative reference to draft-gont-6man-flowlabel-security.		o Removed normative reference to draft-gont-6man-flowlabel-security.
	o Removed the statement that a node that does not set or use the		o Removed the statement that a node that does not set or use the
	flow label must ignore it: this statement appears to be a no-op.		flow label must ignore it: this statement appears to be a no-op.
	o Added a summary of changes from RFC 3697.		o Added a summary of changes from RFC 3697.
	o Miscellaneous editorial fixes.		o Miscellaneous editorial fixes.
	draft-ietf-6man-flow-3697bis-02: update to remove most text about		draft-ietf-6man-flow-3697bis-02: update to remove most text about
	stateful methods, 2011-03-13		stateful methods, 2011-03-13
	draft-ietf-6man-flow-3697bis-01: update after resolving 11 initial		draft-ietf-6man-flow-3697bis-01: update after resolving 11 initial
	skipping to change at page 14, line 20 ¶		skipping to change at page 14, line 34 ¶
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, September 1997.		Functional Specification", RFC 2205, September 1997.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
			[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
			Requirements for Security", BCP 106, RFC 4086, June 2005.
	11.2. Informative References		11.2. Informative References
	[I-D.gont-6man-flowlabel-security]		[I-D.gont-6man-flowlabel-security]
	Gont, F., "Security Assessment of the IPv6 Flow Label",		Gont, F., "Security Assessment of the IPv6 Flow Label",
	draft-gont-6man-flowlabel-security-01 (work in progress),		draft-gont-6man-flowlabel-security-01 (work in progress),
	November 2010.		November 2010.
			[I-D.ietf-6man-flow-ecmp]
			Carpenter, B. and S. Amante, "Using the IPv6 flow label
			for equal cost multipath routing and link aggregation in
			tunnels", draft-ietf-6man-flow-ecmp-05 (work in progress),
			July 2011.
	[I-D.ietf-6man-flow-update]		[I-D.ietf-6man-flow-update]
	Amante, S., Carpenter, B., and S. Jiang, "Rationale for		Amante, S., Carpenter, B., and S. Jiang, "Rationale for
	update to the IPv6 flow label specification",		update to the IPv6 flow label specification",
	draft-ietf-6man-flow-update-07 (work in progress),		draft-ietf-6man-flow-update-07 (work in progress),
	July 2011.		July 2011.
	[NSA] Potyraj, C., "Firewall Design Considerations for IPv6",		[NSA] Potyraj, C., "Firewall Design Considerations for IPv6",
	National Security Agency I733-041R-2007, 2007,		National Security Agency I733-041R-2007, 2007,
	<http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>.		<http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>.
	skipping to change at page 15, line 12 ¶		skipping to change at page 15, line 34 ¶
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,		[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
	December 2005.		December 2005.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, December 2005.		RFC 4303, December 2005.
	[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load		[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
	Sharing", RFC 4311, November 2005.		Sharing", RFC 4311, November 2005.
			[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
			Service Considerations", RFC 4732, December 2006.
			[RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet
			Signalling Transport", RFC 5971, October 2010.
	[vonNeumann]		[vonNeumann]
	von Neumann, J., "Various techniques used in connection		von Neumann, J., "Various techniques used in connection
	with random digits", National Bureau of Standards Applied		with random digits", National Bureau of Standards Applied
	Math Series 12, 36-38, 1951.		Math Series 12, 36-38, 1951.
	Appendix A. Example 20-bit Hash Function		Appendix A. Example 20-bit Hash Function
	As mentioned in Section 3, a stateless hash function may be used to		As mentioned in Section 3, a stateless hash function may be used to
	generate a flow label value from an IPv6 packet's 5-tuple. It is not		generate a flow label value from an IPv6 packet's 5-tuple. It is not
	trivial to choose a suitable hash function, and it is expected that		trivial to choose a suitable hash function, and it is expected that
End of changes. 23 change blocks.
	40 lines changed or deleted		71 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/