--- 1/draft-ietf-6man-flow-ecmp-04.txt 2011-07-22 17:16:39.000000000 +0200 +++ 2/draft-ietf-6man-flow-ecmp-05.txt 2011-07-22 17:16:39.000000000 +0200 @@ -1,20 +1,20 @@ Network Working Group B. Carpenter Internet-Draft Univ. of Auckland -Intended status: BCP S. Amante -Expires: January 6, 2012 Level 3 - July 5, 2011 +Intended status: Standards Track S. Amante +Expires: January 20, 2012 Level 3 + July 19, 2011 Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels - draft-ietf-6man-flow-ecmp-04 + draft-ietf-6man-flow-ecmp-05 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,52 +24,52 @@ 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 January 6, 2012. + This Internet-Draft will expire on January 20, 2012. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 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 2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Change log [RFC Editor: please remove] . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction When several network paths between the same two nodes are known by the routing system to be equally good (in terms of capacity and latency), it may be desirable to share traffic among them. Two such techniques are known as equal cost multipath routing (ECMP) and link aggregation (LAG) [IEEE802.1AX]. There are of course numerous possible approaches to this, but certain goals need to be met: o Roughly equal share of traffic on each path. @@ -148,25 +148,25 @@ Identifying a flow inside the tunnel is more complicated, 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 traffic from one or small number of tunnels, traffic - will not be distributed as intended across the paths between R1 and - R2. - + constant and no load sharing will be achieved, i.e., polarization + will occur. If there is a high proportion of traffic from one or + small number of tunnels, traffic will not be distributed as intended + across the paths between R1 and R2, due to partial polarization. + (Related issues arise with MPLS [I-D.ietf-mpls-entropy-label].) _____ _____ _____ _____ | 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 packets would be suitable for use as input to an ECMP or LAG hash @@ -277,51 +277,60 @@ {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 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. + o Individual nodes in a network are free to implement different + algorithms that conform to this specification, without impacting + the interoperability or function of the network. + o OAM techniques will need to be adapted to manage ECMP and LAG + based on the flow label. The issues will be similar to those that + arise for MPLS [RFC4379] and pseudowires [I-D.ietf-pwe3-fat-pw]. 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 - and unpredictable value is used. In either case, the worst an - attacker could do against ECMP or LAG is to attempt to selectively - overload a particular path. For further discussion, see + well protected against on-path attacks (e.g., by using IPsec between + the two tunnel end-points). Off-path attackers are unlikely to guess + a valid flow label if an apparently pseudo-random and unpredictable + value is used. In either case, the worst an attacker could do + against ECMP or LAG is to attempt to selectively overload a + particular path. For further discussion, see [I-D.ietf-6man-flow-3697bis]. 5. IANA Considerations This document requests no action by IANA. 6. Acknowledgements 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 Miguel Garcia, Brian Haberman, Sheng Jiang, Thomas Narten, Jarno Rajahalme, Brian Weis, and others. This document was produced using the xml2rfc tool [RFC2629]. 7. Change log [RFC Editor: please remove] - draft-ietf-6man-flow-ecmp-04: IETF Last Call comments, 2011-06-20. + draft-ietf-6man-flow-ecmp-05: IESG comments, 2011-07-19. + + draft-ietf-6man-flow-ecmp-04: IETF Last Call comments, 2011-07-05. 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, @@ -328,43 +337,55 @@ 2010-12-02 draft-carpenter-flow-ecmp-03: clarifications after further comments, 2010-10-07 draft-carpenter-flow-ecmp-02: updated after IETF77 discussion, especially adding LAG, changed to BCP language, added second author, 2010-04-14 draft-carpenter-flow-ecmp-01: updated after comments, 2010-02-18 - 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-05 (work in progress), - June 2011. + draft-ietf-6man-flow-3697bis-06 (work in progress), + July 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. 8.2. Informative References + [I-D.ietf-mpls-entropy-label] + Kompella, K., Drake, J., Amante, S., Henderickx, W., and + L. Yong, "The Use of Entropy Labels in MPLS Forwarding", + draft-ietf-mpls-entropy-label-00 (work in progress), + May 2011. + + [I-D.ietf-pwe3-fat-pw] + Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, + J., and S. Amante, "Flow Aware Transport of Pseudowires + over an MPLS Packet Switched Network", + draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. + [IEEE802.1AX] Institute of Electrical and Electronics Engineers, "Link Aggregation", IEEE Standard 802.1AX-2008, 2008. [Lee10] Lee, D., Carpenter, B., and N. Brownlee, "Observations of UDP to TCP Ratio and Port Numbers", Fifth International Conference on Internet Monitoring and Protection ICIMP 2010, May 2010, . @@ -376,20 +397,24 @@ [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000. + [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol + Label Switched (MPLS) Data Plane Failures", RFC 4379, + February 2006. + Authors' Addresses Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand Email: brian.e.carpenter@gmail.com