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/