draft-ietf-6man-flow-ecmp-03.txt		draft-ietf-6man-flow-ecmp-04.txt
	Network Working Group B. Carpenter		Network Working Group B. Carpenter
	Internet-Draft Univ. of Auckland		Internet-Draft Univ. of Auckland
	Intended status: BCP S. Amante		Intended status: BCP S. Amante
	Expires: December 22, 2011 Level 3		Expires: January 6, 2012 Level 3
	June 20, 2011		July 5, 2011
	Using the IPv6 flow label for equal cost multipath routing and link		Using the IPv6 flow label for equal cost multipath routing and link
	aggregation in tunnels		aggregation in tunnels
	draft-ietf-6man-flow-ecmp-03		draft-ietf-6man-flow-ecmp-04
	Abstract		Abstract
	The IPv6 flow label has certain restrictions on its use. This		The IPv6 flow label has certain restrictions on its use. This
	document describes how those restrictions apply when using the flow		document describes how those restrictions apply when using the flow
	label for load balancing by equal cost multipath routing, and for		label for load balancing by equal cost multipath routing, and for
	link aggregation, particularly for IP-in-IPv6 tunneled traffic.		link aggregation, particularly for IP-in-IPv6 tunneled traffic.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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 December 22, 2011.		This Internet-Draft will expire on January 6, 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 2, line 17		skipping to change at page 2, line 17
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Choice of IP Header Fields for Hash Input . . . . . . . . . 3		1.1. Choice of IP Header Fields for Hash Input . . . . . . . . . 3
	1.2. Flow label rules . . . . . . . . . . . . . . . . . . . . . 5		1.2. Flow label rules . . . . . . . . . . . . . . . . . . . . . 5
	2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6		2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6
	3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7		4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
	7. Change log [RFC Editor: please remove] . . . . . . . . . . . . 8		7. Change log [RFC Editor: please remove] . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	8.2. Informative References . . . . . . . . . . . . . . . . . . 9		8.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	When several network paths between the same two nodes are known by		When several network paths between the same two nodes are known by
	the routing system to be equally good (in terms of capacity and		the routing system to be equally good (in terms of capacity and
	latency), it may be desirable to share traffic among them. Two such		latency), it may be desirable to share traffic among them. Two such
	techniques are known as equal cost multipath routing (ECMP) and link		techniques are known as equal cost multipath routing (ECMP) and link
	aggregation (LAG) [IEEE802.1AX]. There are of course numerous		aggregation (LAG) [IEEE802.1AX]. There are of course numerous
	skipping to change at page 4, line 30		skipping to change at page 4, line 30
	transport layer information is inconvenient to extract, due to the		transport layer information is inconvenient to extract, due to the
	variable placement of and variable length of next-headers; all		variable placement of and variable length of next-headers; all
	implementations must be capable of skipping over next-headers, even		implementations must be capable of skipping over next-headers, even
	if they are rarely present in actual traffic. In fact, [RFC2460]		if they are rarely present in actual traffic. In fact, [RFC2460]
	implies that next-headers, except hop-by-hop options, are not		implies that next-headers, except hop-by-hop options, are not
	normally inspected by intermediate nodes in the network. This		normally inspected by intermediate nodes in the network. This
	situation may be challenging for some hardware implementations,		situation may be challenging for some hardware implementations,
	raising the potential that network equipment vendors might sacrifice		raising the potential that network equipment vendors might sacrifice
	the length of the fields extracted from an IPv6 header.		the length of the fields extracted from an IPv6 header.
	It is worth noting that the possible presence of a GRE header		It is worth noting that the possible presence of a Generic Routing
	[RFC2784] and the possible presence of a GRE key within that header		Encapsulation (GRE) header [RFC2784] and the possible presence of a
	creates a similar challenge to the possible presence of IPv6		GRE key within that header creates a similar challenge to the
	extension headers; anything that complicates header analysis is		possible presence of IPv6 extension headers; anything that
	undesirable.		complicates header analysis is undesirable.
	The situation is different in IP-in-IP tunneled scenarios.		The situation is different in IP-in-IP tunneled scenarios.
	Identifying a flow inside the tunnel is more complicated,		Identifying a flow inside the tunnel is more complicated,
	particularly because nearly all hardware can only identify flows		particularly because nearly all hardware can only identify flows
	based on information contained in the outermost IP header. Assume		based on information contained in the outermost IP header. Assume
	that traffic from many sources to many destinations is aggregated in		that traffic from many sources to many destinations is aggregated in
	a single IP-in-IP tunnel from tunnel end point (TEP) A to TEP B (see		a single IP-in-IP tunnel from tunnel end point (TEP) A to TEP B (see
	figure). Then all the packets forming the tunnel have outer source		figure). Then all the packets forming the tunnel have outer source
	address A and outer destination address B. In all probability they		address A and outer destination address B. In all probability they
	also have the same port and protocol numbers. If there are multiple		also have the same port and protocol numbers. If there are multiple
	skipping to change at page 7, line 43		skipping to change at page 7, line 43
	provide additional entropy for flows whose flow label is set to		provide additional entropy for flows whose flow label is set to
	zero, including non-tunneled traffic flows.		zero, including non-tunneled traffic flows.
	4. Security Considerations		4. Security Considerations
	The flow label is not protected in any way and can be forged by an		The flow label is not protected in any way and can be forged by an
	on-path attacker. However, it is expected that tunnel end-points and		on-path attacker. However, it is expected that tunnel end-points and
	the ECMP or LAG paths will be part of managed infrastructure that is		the ECMP or LAG paths will be part of managed infrastructure that is
	well protected against on-path attacks. Off-path attackers are		well protected against on-path attacks. Off-path attackers are
	unlikely to guess a valid flow label if an apparently pseudo-random		unlikely to guess a valid flow label if an apparently pseudo-random
	value is used. In either case, the worst an attacker could do		and unpredictable value is used. In either case, the worst an
	against ECMP or LAG is to attempt to selectively overload a		attacker could do against ECMP or LAG is to attempt to selectively
	particular path. For further discussion, see		overload a particular path. For further discussion, see
	[I-D.ietf-6man-flow-3697bis].		[I-D.ietf-6man-flow-3697bis].
	5. IANA Considerations		5. IANA Considerations
	This document requests no action by IANA.		This document requests no action by IANA.
	6. Acknowledgements		6. Acknowledgements
	This document was suggested by corridor discussions at IETF76. Joel		This document was suggested by corridor discussions at IETF76. Joel
	Halpern made crucial comments on an early version. We are grateful		Halpern made crucial comments on an early version. We are grateful
	to Qinwen Hu for general discussion about the flow label. Valuable		to Qinwen Hu for general discussion about the flow label. Valuable
	comments and contributions were made by Jarno Rajahalme, Brian		comments and contributions were made by Miguel Garcia, Brian
	Haberman, Sheng Jiang, Thomas Narten, and others.		Haberman, Sheng Jiang, Thomas Narten, Jarno Rajahalme, Brian Weis,
			and others.
	This document was produced using the xml2rfc tool [RFC2629].		This document was produced using the xml2rfc tool [RFC2629].
	7. Change log [RFC Editor: please remove]		7. Change log [RFC Editor: please remove]
	draft-ietf-6man-flow-ecmp-03: minor editorial fixes, AD comments, 2011-06-20.		draft-ietf-6man-flow-ecmp-04: IETF Last Call comments, 2011-06-20.
			draft-ietf-6man-flow-ecmp-03: minor editorial fixes, AD comments,
			2011-06-20.
	draft-ietf-6man-flow-ecmp-02: updated after further comments, 2011-		draft-ietf-6man-flow-ecmp-02: updated after further comments, 2011-
	05-02. Note that RFC3697bis becomes a normative reference.		05-02. Note that RFC3697bis becomes a normative reference.
	draft-ietf-6man-flow-ecmp-01: updated after WG Last Call, 2011-02-10		draft-ietf-6man-flow-ecmp-01: updated after WG Last Call, 2011-02-10
	draft-ietf-6man-flow-ecmp-00: after WG adoption at IETF 79,		draft-ietf-6man-flow-ecmp-00: after WG adoption at IETF 79,
	2010-12-02		2010-12-02
	draft-carpenter-flow-ecmp-03: clarifications after further comments,		draft-carpenter-flow-ecmp-03: clarifications after further comments,
	skipping to change at page 8, line 43		skipping to change at page 9, line 4
	draft-carpenter-flow-ecmp-02: updated after IETF77 discussion,		draft-carpenter-flow-ecmp-02: updated after IETF77 discussion,
	especially adding LAG, changed to BCP language, added second author,		especially adding LAG, changed to BCP language, added second author,
	2010-04-14		2010-04-14
	draft-carpenter-flow-ecmp-01: updated after comments, 2010-02-18		draft-carpenter-flow-ecmp-01: updated after comments, 2010-02-18
	draft-carpenter-flow-ecmp-00: original version, 2010-01-19		draft-carpenter-flow-ecmp-00: original version, 2010-01-19
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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-04 (work in progress),		draft-ietf-6man-flow-3697bis-05 (work in progress),
	May 2011.		June 2011.
	[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.
	[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.
	[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,		[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
	"IPv6 Flow Label Specification", RFC 3697, March 2004.		"IPv6 Flow Label Specification", RFC 3697, March 2004.
End of changes. 10 change blocks.
	20 lines changed or deleted		23 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/