--- 1/draft-ietf-6man-flow-ecmp-02.txt 2011-06-20 16:15:46.000000000 +0200 +++ 2/draft-ietf-6man-flow-ecmp-03.txt 2011-06-20 16:15:46.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group B. Carpenter Internet-Draft Univ. of Auckland Intended status: BCP S. Amante -Expires: November 3, 2011 Level 3 - May 2, 2011 +Expires: December 22, 2011 Level 3 + June 20, 2011 Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels - draft-ietf-6man-flow-ecmp-02 + draft-ietf-6man-flow-ecmp-03 Abstract The IPv6 flow label has certain restrictions on its use. This document describes how those restrictions apply when using the flow label for load balancing by equal cost multipath routing, and for link aggregation, particularly for IP-in-IPv6 tunneled traffic. Status of this Memo @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 December 22, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -149,22 +149,23 @@ particularly because nearly all hardware can only identify flows based on information contained in the outermost IP header. Assume 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 figure). Then all the packets forming the tunnel have outer source address A and outer destination address B. In all probability they also have the same port and protocol numbers. If there are multiple paths between routers R1 and R2, and ECMP or LAG is applied to choose a particular path, the 2-tuple or 5-tuple, and its hash, will be constant and no load sharing will be achieved. If there is a high - proportion of tunnel traffic, traffic will not be distributed as - intended across the paths between R1 and R2. + proportion of traffic from one or small number of tunnels, traffic + will not be distributed as intended across the paths between R1 and + R2. _____ _____ _____ _____ | TEP |_________| R1 |-------------| R2 |_________| TEP | |__A__| |_____|-------------|_____| |__B__| tunnel ECMP or LAG tunnel here As noted above, for IPv6, the 5-tuple is in any case quite inconvenient to extract due to the next-header placement. The question therefore arises whether the 20-bit flow label in IPv6 @@ -241,57 +242,55 @@ points (TEPs). o The flow label in the outer packet SHOULD be set by the sending TEP to a 20-bit value in accordance with [I-D.ietf-6man-flow-3697bis]. The same flow label value MUST be used for all packets in a single user flow, as determined by the IP header fields of the inner packet. o To achieve this, the sending TEP MUST classify all packets into flows, once it has determined that they should enter a given tunnel, and then write the relevant flow label into the outer IPv6 header. A user flow could be identified by the sending TEP most - simply by its {destination, source} address 2-tuple (coarse) or by - its 5-tuple {dest addr, source addr, protocol, dest port, source - port} (fine). At present, ironically, there would be little point - in using the {dest addr, source addr, flow label} 3-tuple of the - inner packet. The choice of n-tuple is an implementation choice - in the sending TEP. + simply by its {destination, source} address 2-tuple or by its + 5-tuple {dest addr, source addr, protocol, dest port, source + port}. At present, there would be little point in using the {dest + addr, source addr, flow label} 3-tuple of the inner packet, but + doing so would be a future-proof option. The choice of n-tuple is + an implementation choice in the sending TEP. * As specified in [I-D.ietf-6man-flow-3697bis], the flow label - values should be chosen from a uniform distribution so that - they appear to be pseudo-random. Such values will be suitable - as input to a load balancing hash function and will be hard for - a malicious third party to predict. + values should be chosen from a uniform distribution. Such + values will be suitable as input to a load balancing hash + function and will be hard for a malicious third party to + predict. * The sending TEP MAY perform stateless flow label assignment, by using a suitable 20 bit hash of the inner IP header's 2-tuple or 5-tuple as the flow label value. * If the inner packet is an IPv6 packet, its flow label value could also be included in this hash. * This stateless method creates a small probability of two different user flows hashing to the same flow label. Since [I-D.ietf-6man-flow-3697bis] allows a source (the TEP in this case) to define any set of packets that it wishes as a single flow, occasionally labeling two user flows as a single flow through the tunnel is acceptable. o At intermediate router(s) that perform load distribution, the hash algorithm used to determine the outgoing component-link in an ECMP and/or LAG toward the next-hop MUST minimally include the 3-tuple {dest addr, source addr, flow label} and MAY also include the remaining components of the 5-tuple. This applies whether the traffic is tunneled traffic only, or a mixture of normal traffic and tunneled traffic. * Intermediate IPv6 router(s) will presumably encounter a mixture of tunneled traffic and normal IPv6 traffic. Because of this, - the design may also include {protocol, dest port, source port} - as input keys to the ECMP and/or LAG hash algorithms, to + the design should also include {protocol, dest port, source + port} as input keys to the ECMP and/or LAG hash algorithms, to provide additional entropy for flows whose flow label is set to - zero, including non-tunneled traffic flows. Whether this is - appropriate depends on the expected traffic mix and on - considerations of implementation efficiency. + zero, including non-tunneled traffic flows. 4. Security Considerations 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 the ECMP or LAG paths will be part of managed infrastructure that is well protected against on-path attacks. Off-path attackers are unlikely to guess a valid flow label if an apparently pseudo-random value is used. In either case, the worst an attacker could do against ECMP or LAG is to attempt to selectively overload a @@ -307,20 +306,22 @@ This document was suggested by corridor discussions at IETF76. Joel Halpern made crucial comments on an early version. We are grateful to Qinwen Hu for general discussion about the flow label. Valuable comments and contributions were made by Jarno Rajahalme, Brian Haberman, Sheng Jiang, Thomas Narten, and others. This document was produced using the xml2rfc tool [RFC2629]. 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-02: updated after further comments, 2011- 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-00: after WG adoption at IETF 79, 2010-12-02 draft-carpenter-flow-ecmp-03: clarifications after further comments, 2010-10-07 @@ -333,22 +334,22 @@ draft-carpenter-flow-ecmp-00: original version, 2010-01-19 8. References 8.1. Normative References [I-D.ietf-6man-flow-3697bis] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", - draft-ietf-6man-flow-3697bis-02 (work in progress), - March 2011. + draft-ietf-6man-flow-3697bis-04 (work in progress), + May 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.