draft-ietf-6man-flow-update-05.txt		draft-ietf-6man-flow-update-06.txt
	6MAN S. Amante		6MAN S. Amante
	Internet-Draft Level 3		Internet-Draft Level 3
	Intended status: Informational B. Carpenter		Intended status: Informational B. Carpenter
	Expires: November 3, 2011 Univ. of Auckland		Expires: November 12, 2011 Univ. of Auckland
	S. Jiang		S. Jiang
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	May 2, 2011		May 11, 2011
	Rationale for update to the IPv6 flow label specification		Rationale for update to the IPv6 flow label specification
	draft-ietf-6man-flow-update-05		draft-ietf-6man-flow-update-06
	Abstract		Abstract
	Various published proposals for use of the IPv6 flow label are		Various published proposals for use of the IPv6 flow label are
	incompatible with its original specification in RFC 3697.		incompatible with its original specification in RFC 3697.
	Furthermore, very little practical use is made of the flow label,		Furthermore, very little practical use is made of the flow label,
	partly due to some uncertainties about the correct interpretation of		partly due to some uncertainties about the correct interpretation of
	the specification. This document discusses and motivates changes to		the specification. This document discusses and motivates changes to
	the specification in order to clarify it, and to introduce some		the specification in order to clarify it, and to introduce some
	additional flexibility.		additional flexibility.
	skipping to change at page 1, line 39		skipping to change at page 1, line 39
	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 November 3, 2011.		This Internet-Draft will expire on November 12, 2011.
	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 2, line 21		skipping to change at page 2, line 21
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Impact of current specification . . . . . . . . . . . . . . . 3		2. Impact of current specification . . . . . . . . . . . . . . . 3
	3. Changes to specification . . . . . . . . . . . . . . . . . . . 6		3. Changes to specification . . . . . . . . . . . . . . . . . . . 6
	4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8		4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	8. Change log [RFC Editor: please remove] . . . . . . . . . . . . 10		8. Change log [RFC Editor: please remove] . . . . . . . . . . . . 10
	9. Informative References . . . . . . . . . . . . . . . . . . . . 10		9. Informative References . . . . . . . . . . . . . . . . . . . . 10
	Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 11		Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The flow label field in the IPv6 header was reserved but left		The flow label field in the IPv6 header was reserved but left
	experimental by [RFC2460], which mandates only that "Hosts or routers		experimental by [RFC2460], which mandates only that "Hosts or routers
	that do not support the functions of the Flow Label field are		that do not support the functions of the Flow Label field are
	required to set the field to zero when originating a packet, pass the		required to set the field to zero when originating a packet, pass the
	field on unchanged when forwarding a packet, and ignore the field		field on unchanged when forwarding a packet, and ignore the field
	when receiving a packet."		when receiving a packet."
	skipping to change at page 4, line 24		skipping to change at page 4, line 24
	unprotected as it travels through the network, because there is no		unprotected as it travels through the network, because there is no
	IPv6 header checksum, and the flow label is not included in transport		IPv6 header checksum, and the flow label is not included in transport
	pseudo-header checksums, nor in IPsec checksums. As a result,		pseudo-header checksums, nor in IPsec checksums. As a result,
	intentional and malicious changes to its value cannot be detected.		intentional and malicious changes to its value cannot be detected.
	Also, it could be used as a covert data channel, since apparently		Also, it could be used as a covert data channel, since apparently
	pseudo-random flow label values could in fact consist of covert data.		pseudo-random flow label values could in fact consist of covert data.
	If the flow label were to carry quality of service semantics, then		If the flow label were to carry quality of service semantics, then
	like the diffserv code point [RFC2474], it would not be intrinsically		like the diffserv code point [RFC2474], it would not be intrinsically
	trustworthy across domain boundaries. As a result, some security		trustworthy across domain boundaries. As a result, some security
	specialists believe that flow labels should be cleared for safety		specialists believe that flow labels should be cleared for safety
	[I-D.gont-6man-flowlabel-security]. These points must be considered		[I-D.gont-6man-flowlabel-security], [NSA], [NIST]. These points must
	when discussing the immutability of the flow label across domain		be considered when discussing the immutability of the flow label
	boundaries.		across domain boundaries. In fact, the adjective "immutable" is
			confusing, since it implies a property that the flow label field does
			not actually possess. It has therefore been abandoned as a
			descriptive term in [I-D.ietf-6man-flow-3697bis]. It is only used in
			the present document to explain why it has been abandoned.
	Rule (b) appears to forbid any usage in which the bits of the flow		Rule (b) appears to forbid any usage in which the bits of the flow
	label are encoded with a specific semantic meaning. However, the		label are encoded with a specific semantic meaning. However, the
	words "MUST NOT assume" are to be interpreted precisely - if a router		words "MUST NOT assume" are to be interpreted precisely - if a router
	knows by configuration or by signaling that the flow label has been		knows by configuration or by signaling that the flow label has been
	assigned in a certain way, it can make use of that knowledge. It is		assigned in a certain way, it can make use of that knowledge. It is
	not made clear by the rule that there is an implied distinction		not made clear by the rule that there is an implied distinction
	between stateless models (in which case no assumption may be made)		between stateless models (in which case no assumption may be made)
	and stateful models (in which the router has explicit knowledge).		and stateful models (in which the router has explicit knowledge).
	skipping to change at page 6, line 31		skipping to change at page 6, line 33
	as noted above, it is not included in any transport layer pseudo-		as noted above, it is not included in any transport layer pseudo-
	header checksums nor in IPsec authentication [RFC4302]. Both RFC		header checksums nor in IPsec authentication [RFC4302]. Both RFC
	2460 and RFC 3697 define the default flow label to be zero. At the		2460 and RFC 3697 define the default flow label to be zero. At the
	time of writing, this is the observed value in an overwhelming		time of writing, this is the observed value in an overwhelming
	proportion of IPv6 packets; the most widespread operating systems and		proportion of IPv6 packets; the most widespread operating systems and
	applications do not set it, and routers do not rely on it. Thus		applications do not set it, and routers do not rely on it. Thus
	there is no reason to expect operational difficulties if a careful		there is no reason to expect operational difficulties if a careful
	change is made to the rules of RFC 3697.		change is made to the rules of RFC 3697.
	In particular, the facts that the label is not checksummed and rarely		In particular, the facts that the label is not checksummed and rarely
	used mean that the current strict immutability of the label can be		used mean that the "immutability" of the label can be moderated
	moderated without serious operational consequences.		without serious operational consequences.
	The purposes of the proposed changes are to remove the uncertainties		The purposes of the proposed changes are to remove the uncertainties
	left by RFC 3697, in order to encourage setting of the flow label by		left by RFC 3697, in order to encourage setting of the flow label by
	default, and to enable its generic use. The proposed generic use is		default, and to enable its generic use. The proposed generic use is
	to encourage uniformly distributed flow labels that can be used to		to encourage uniformly distributed flow labels that can be used to
	assist load distribution balancing. There should be no impact on		assist load distribution or balancing. There should be no impact on
	existing IETF specifications other than RFC 3697 and no impact on		existing IETF specifications other than RFC 3697 and no impact on
	currently operational software and hardware.		currently operational software and hardware.
	A secondary purpose is to modify the immutability of the flow label		A secondary purpose is to allow changes to the flow label in a
	in a limited way, to allow hosts that do not set the flow label to		limited way, to allow hosts that do not set the flow label to benefit
	benefit from it nevertheless. The fact that the flow label may in		from it nevertheless. The fact that the flow label may in practice
	practice be changed en route is also reflected in the reformulation		be changed en route is also reflected in the reformulation of the
	of the rules.		rules.
	A general description of the changes follows. The normative text is		A general description of the changes follows. The normative text is
	to be found in [I-D.ietf-6man-flow-3697bis].		to be found in [I-D.ietf-6man-flow-3697bis].
	The definition of a flow is subtly changed from RFC 3697 to allow any		The definition of a flow is subtly changed from RFC 3697 to allow any
	node, not just the source node, to set the flow label value.		node, not just the source node, to set the flow label value.
	However, it is recommended that sources should set a uniformly		However, it is recommended that sources should set a uniformly
	distributed flow label value in all flows, replacing the less precise		distributed flow label value in all flows, replacing the less precise
	recommendation made in Section 3 of RFC 3697. Both stateful and		recommendation made in Section 3 of RFC 3697. Both stateful and
	stateless methods of assigning a uniformly distributed value could be		stateless methods of assigning a uniformly distributed value could be
	used.		used.
	Flow label values should be chosen such that their bits exhibit a		Flow label values should be chosen such that their bits exhibit a
	high degree of variability, making them suitable for use as part of		high degree of variability, thus making them suitable for use as part
	the input to a hash function used in a load distribution scheme. At		of the input to a hash function used in a load distribution scheme.
	the same time, third parties should be unlikely to be able to guess		At the same time, third parties should be unlikely to be able to
	the next value that a source of flow labels will choose.		guess the next value that a source of flow labels will choose.
	In statistics, a discrete uniform distribution is defined as a		In statistics, a discrete uniform distribution is defined as a
	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, an		distribution exhibit both variability and unguessability. Thus, an
	approximation to a discrete uniform distribution is preferable as the		approximation to a discrete uniform distribution is preferable as the
	source of flow label values. In contrast, an implementation in which		source of flow label values. In contrast, an implementation in which
	flow labels are assigned sequentially is definitely not recommended.		flow labels are assigned sequentially is definitely not recommended,
			to avoid guessability.
	In practice it is expected that a uniform distribution of flow label		In practice it is expected that a uniform distribution of flow label
	values will be approximated by use of a hash function or a pseudo-		values will be approximated by use of a hash function or a pseudo-
	random number generator. Either approach will produce values which		random number generator. Either approach will produce values which
	will appear pseudo-random to an external observer.		will appear pseudo-random to an external observer.
	Section 3 of RFC 3697 also allows nodes to participate in an		Section 3 of RFC 3697 allows nodes to participate in an unspecified
	unspecified stateful method of flow state establishment. The changes		stateful method of flow state establishment. The changes do not
	do not remove that option, but it is made clear that stateless models		remove that option, but it is made clear that stateless models are
	are also possible and are the recommended default. The specific text		also possible and are the recommended default. The specific text
	about requirements for stateful models has been reduced to a bare		about requirements for stateful models has been reduced to a bare
	minimum requirement that they do not interfere with the stateless		minimum requirement that they do not interfere with the stateless
	model. To enable stateless load distribution at any point in the		model. To enable stateless load distribution at any point in the
	Internet, a network domain using a stateful model should never export		Internet, a network using a stateful model should never export
	packets originating within the domain whose flow label values do not		packets whose flow label values do not conform to a uniform
	conform to a uniform distribution.		distribution.
	The main novelty is that a forwarding node (typically a first-hop or		The main novelty is that a forwarding node (typically a first-hop or
	ingress router) may set the flow label value if the source has not		ingress router) may set the flow label value if the source has not
	done so, according to the same recommendations that apply to the		done so, according to the same recommendations that apply to the
	source. This might place a considerable processing load on ingress		source. This might place a considerable processing load on ingress
	routers, even if they adopted a stateless method of flow		routers, even if they adopted a stateless method of flow
	identification and label assignment.		identification and label assignment.
	The immutability of the flow label, once it has been set, is not		The value of the flow label, once it has been set, must not be
	changed. However, some qualifications are placed on this property,		changed. However, some qualifications are placed on this rule, to
	to allow for the fact that the flow label is an unprotected field and		allow for the fact that the flow label is an unprotected field and
	might be changed undetectably. No Internet-wide mechanism can depend		might be misused. No Internet-wide mechanism can depend
	mathematically on immutable flow labels. The new rules require that		mathematically on immutable flow labels. The new rules require that
	flow labels exported to the Internet should always be either zero or		flow labels exported to the Internet should always be either zero or
	uniformly distributed, but even this cannot be relied on		uniformly distributed, but even this cannot be relied on
	mathematically. Use cases need to be robust against non-conforming		mathematically. Use cases need to be robust against non-conforming
	flow label values. This will also enhance compatibility with any		flow label values. This will also enhance compatibility with any
	legacy hosts that set the flow label according to RFC 2460 or RFC		legacy hosts that set the flow label according to RFC 2460 or RFC
	3697.		3697.
	A complication that led to much discussion is the possibility that		A complication that led to much discussion is the possibility that
	hosts inside a particular domain might use a stateful method of		hosts inside a particular network domain might use a stateful method
	setting the flow label, and that packets bearing stateful labels		of setting the flow label, and that packets bearing stateful labels
	might then erroneously escape the domain and be received by nodes		might then erroneously escape the domain and be received by nodes
	performing stateless processing such as load balancing. This might		performing stateless processing such as load balancing. This might
	result in undesirable operational implications (e.g., congestion,		result in undesirable operational implications (e.g., congestion,
	reordering) for not only the inappropriately flow-labelled packets,		reordering) for not only the inappropriately flow-labelled packets,
	but also well-behaved flow-labelled packets, during forwarding at		but also well-behaved flow-labelled packets, during forwarding at
	various intermediate devices. It was proposed to suggest that border		various intermediate devices. It was proposed to suggest that border
	routers might "correct" this problem by overwriting such labels in		routers might "correct" this problem by overwriting such labels in
	packets leaving the domain. However, neither domain border egress		packets leaving the domain. However, neither domain border egress
	routers nor intermediate routers/devices (using a flow label, for		routers nor intermediate routers/devices (using a flow label, for
	example, as a part of an input key for a load-distribution hash) can		example, as a part of an input key for a load-distribution hash) can
	determine by inspection that a value is not part of a uniform		determine by inspection that a value is not part of a uniform
	distribution. Therefore, there is no way that such values can be		distribution. Thus there is no way that such values can be detected
	detected and "corrected".		and "corrected". Therefore, the recommendation to choose flow labels
			from a uniform distribution also applies to stateful schemes.
	4. Discussion		4. Discussion
	The following are some practical consequences of the above changes:		The following are some practical consequences of the above changes:
	o Sending hosts that are not updated will in practice continue to		o Sending hosts that are not updated will in practice continue to
	send all-zero labels. If there is no label-setting router along		send all-zero labels. If there is no label-setting router along
	the path taken by a packet, the label will be delivered as zero.		the path taken by a packet, the label will be delivered as zero.
	o Sending hosts conforming to the new specification will by default		o Sending hosts conforming to the new specification will by default
	choose uniformly distributed labels between 1 and 0xFFFFF.		choose uniformly distributed labels between 1 and 0xFFFFF.
	o Sending hosts may continue to send all-zero labels, in which case		o Sending hosts may continue to send all-zero labels, in which case
	skipping to change at page 9, line 32		skipping to change at page 9, line 35
	whatever flow label handling is used on the path.		whatever flow label handling is used on the path.
	Hosts and routers that adopt the recommended mechanism will enhance		Hosts and routers that adopt the recommended mechanism will enhance
	the performance of any load balancing devices that include the flow		the performance of any load balancing devices that include the flow
	label in the hash used to select a particular path or server, even		label in the hash used to select a particular path or server, even
	when packets leave the local domain.		when packets leave the local domain.
	5. Security Considerations		5. Security Considerations
	See [I-D.ietf-6man-flow-3697bis] and		See [I-D.ietf-6man-flow-3697bis] and
	[I-D.gont-6man-flowlabel-security] for full discussion.		[I-D.gont-6man-flowlabel-security] for full discussion. Some useful
			remarks are in [Partridge].
	6. IANA Considerations		6. IANA Considerations
	This document requests no action by IANA.		This document requests no action by IANA.
	7. Acknowledgements		7. Acknowledgements
	The authors are grateful to Qinwen Hu for general discussion about		The authors are grateful to Qinwen Hu for general discussion about
	the flow label and for his work in searching the literature.		the flow label and for his work in searching the literature.
	Valuable comments and contributions were made by Fred Baker, Steve		Valuable comments and contributions were made by Fred Baker, Steve
	Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony		Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony
	Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka Savola, Mark		Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka Savola, Mark
	Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants		Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants
	in the 6man working group.		in the 6man working group.
	This document was produced using the xml2rfc tool [RFC2629].		This document was produced using the xml2rfc tool [RFC2629].
	8. Change log [RFC Editor: please remove]		8. Change log [RFC Editor: please remove]
			draft-ietf-6man-flow-update-06: updated again to be in step with RFC
			3697bis, 2011-05-11
	draft-ietf-6man-flow-update-05: updated again to be in step with RFC		draft-ietf-6man-flow-update-05: updated again to be in step with RFC
	3697bis, 2011-05-02		3697bis, 2011-05-02
	draft-ietf-6man-flow-update-04: updated again to be in step with RFC		draft-ietf-6man-flow-update-04: updated again to be in step with RFC
	3697bis, 2011-03-13		3697bis, 2011-03-13
	draft-ietf-6man-flow-update-03: updated to be in step with RFC		draft-ietf-6man-flow-update-03: updated to be in step with RFC
	3697bis, 2011-02-26		3697bis, 2011-02-26
	draft-ietf-6man-flow-update-02: repurposed as rationale for update of		draft-ietf-6man-flow-update-02: repurposed as rationale for update of
	skipping to change at page 11, line 13		skipping to change at page 11, line 21
	November 2010.		November 2010.
	[I-D.hu-flow-label-cases]		[I-D.hu-flow-label-cases]
	Hu, Q. and B. Carpenter, "Survey of proposed use cases for		Hu, Q. and B. Carpenter, "Survey of proposed use cases for
	the IPv6 flow label", draft-hu-flow-label-cases-03 (work		the IPv6 flow label", draft-hu-flow-label-cases-03 (work
	in progress), February 2011.		in progress), February 2011.
	[I-D.ietf-6man-flow-3697bis]		[I-D.ietf-6man-flow-3697bis]
	Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,		Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
	"IPv6 Flow Label Specification",		"IPv6 Flow Label Specification",
	draft-ietf-6man-flow-3697bis-02 (work in progress),		draft-ietf-6man-flow-3697bis-03 (work in progress),
	March 2011.		May 2011.
	[I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]		[I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]
	Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)",		Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)",
	draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03		draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03
	(work in progress), March 2007.		(work in progress), March 2007.
	[McGann05]		[McGann05]
	McGann, O. and D. Malone, "Flow Label Filtering		McGann, O. and D. Malone, "Flow Label Filtering
	Feasibility", European Conference on Computer Network		Feasibility", European Conference on Computer Network
	Defence , 2005.		Defence , 2005.
			[NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks,
			"Guidelines for the Secure Deployment of IPv6", National
			Institute of Standards and Technology Special Publication
			800-119, 2010, <http://csrc.nist.gov/publications/
			nistpubs/800-119/sp800-119.pdf>.
			[NSA] Potyraj, C., "Firewall Design Considerations for IPv6",
			National Security Agency I733-041R-2007, 2007,
			<http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>.
			[Partridge]
			Partridge, C., Arsenault, A., and S. Kent, "Information
			Assurance and the Transition to IP Version 6 (IPv6)",
			Military Communications Conference (MILCOM 2007) , 2007,
			<http://www.ir.bbn.com/documents/articles/
			MILCOM_Paper_from_Proceedings.pdf>.
	[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.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474,
	December 1998.		December 1998.
End of changes. 21 change blocks.
	40 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/