draft-ietf-6man-flow-ecmp-02.txt   draft-ietf-6man-flow-ecmp-03.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: November 3, 2011 Level 3 Expires: December 22, 2011 Level 3
May 2, 2011 June 20, 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-02 draft-ietf-6man-flow-ecmp-03
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 November 3, 2011. This Internet-Draft will expire on December 22, 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 4, line 48 skipping to change at page 4, line 48
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
paths between routers R1 and R2, and ECMP or LAG is applied to choose 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 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 constant and no load sharing will be achieved. If there is a high
proportion of tunnel traffic, traffic will not be distributed as proportion of traffic from one or small number of tunnels, traffic
intended across the paths between R1 and R2. will not be distributed as intended across the paths between R1 and
R2.
_____ _____ _____ _____ _____ _____ _____ _____
| TEP |_________| R1 |-------------| R2 |_________| TEP | | TEP |_________| R1 |-------------| R2 |_________| TEP |
|__A__| |_____|-------------|_____| |__B__| |__A__| |_____|-------------|_____| |__B__|
tunnel ECMP or LAG tunnel tunnel ECMP or LAG tunnel
here here
As noted above, for IPv6, the 5-tuple is in any case quite As noted above, for IPv6, the 5-tuple is in any case quite
inconvenient to extract due to the next-header placement. The inconvenient to extract due to the next-header placement. The
question therefore arises whether the 20-bit flow label in IPv6 question therefore arises whether the 20-bit flow label in IPv6
skipping to change at page 6, line 46 skipping to change at page 6, line 46
points (TEPs). points (TEPs).
o The flow label in the outer packet SHOULD be set by the sending o The flow label in the outer packet SHOULD be set by the sending
TEP to a 20-bit value in accordance with TEP to a 20-bit value in accordance with
[I-D.ietf-6man-flow-3697bis]. The same flow label value MUST be [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 used for all packets in a single user flow, as determined by the
IP header fields of the inner packet. IP header fields of the inner packet.
o To achieve this, the sending TEP MUST classify all packets into o To achieve this, the sending TEP MUST classify all packets into
flows, once it has determined that they should enter a given flows, once it has determined that they should enter a given
tunnel, and then write the relevant flow label into the outer IPv6 tunnel, and then write the relevant flow label into the outer IPv6
header. A user flow could be identified by the sending TEP most header. A user flow could be identified by the sending TEP most
simply by its {destination, source} address 2-tuple (coarse) or by simply by its {destination, source} address 2-tuple or by its
its 5-tuple {dest addr, source addr, protocol, dest port, source 5-tuple {dest addr, source addr, protocol, dest port, source
port} (fine). At present, ironically, there would be little point port}. At present, there would be little point in using the {dest
in using the {dest addr, source addr, flow label} 3-tuple of the addr, source addr, flow label} 3-tuple of the inner packet, but
inner packet. The choice of n-tuple is an implementation choice doing so would be a future-proof option. The choice of n-tuple is
in the sending TEP. an implementation choice in the sending TEP.
* As specified in [I-D.ietf-6man-flow-3697bis], the flow label * As specified in [I-D.ietf-6man-flow-3697bis], the flow label
values should be chosen from a uniform distribution so that values should be chosen from a uniform distribution. Such
they appear to be pseudo-random. Such values will be suitable values will be suitable as input to a load balancing hash
as input to a load balancing hash function and will be hard for function and will be hard for a malicious third party to
a malicious third party to predict. predict.
* The sending TEP MAY perform stateless flow label assignment, by * The sending TEP MAY perform stateless flow label assignment, by
using a suitable 20 bit hash of the inner IP header's 2-tuple using a suitable 20 bit hash of the inner IP header's 2-tuple
or 5-tuple as the flow label value. or 5-tuple as the flow label value.
* If the inner packet is an IPv6 packet, its flow label value * If the inner packet is an IPv6 packet, its flow label value
could also be included in this hash. could also be included in this hash.
* This stateless method creates a small probability of two * This stateless method creates a small probability of two
different user flows hashing to the same flow label. Since different user flows hashing to the same flow label. Since
[I-D.ietf-6man-flow-3697bis] allows a source (the TEP in this [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 case) to define any set of packets that it wishes as a single
flow, occasionally labeling two user flows as a single flow flow, occasionally labeling two user flows as a single flow
through the tunnel is acceptable. through the tunnel is acceptable.
o At intermediate router(s) that perform load distribution, the hash o At intermediate router(s) that perform load distribution, the hash
algorithm used to determine the outgoing component-link in an ECMP algorithm used to determine the outgoing component-link in an ECMP
and/or LAG toward the next-hop MUST minimally include the 3-tuple and/or LAG toward the next-hop MUST minimally include the 3-tuple
{dest addr, source addr, flow label} and MAY also include the {dest addr, source addr, flow label} and MAY also include the
remaining components of the 5-tuple. This applies whether the remaining components of the 5-tuple. This applies whether the
traffic is tunneled traffic only, or a mixture of normal traffic traffic is tunneled traffic only, or a mixture of normal traffic
and tunneled traffic. and tunneled traffic.
* Intermediate IPv6 router(s) will presumably encounter a mixture * Intermediate IPv6 router(s) will presumably encounter a mixture
of tunneled traffic and normal IPv6 traffic. Because of this, of tunneled traffic and normal IPv6 traffic. Because of this,
the design may also include {protocol, dest port, source port} the design should also include {protocol, dest port, source
as input keys to the ECMP and/or LAG hash algorithms, to port} as input keys to the ECMP and/or LAG hash algorithms, to
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. Whether this is zero, including non-tunneled traffic flows.
appropriate depends on the expected traffic mix and on
considerations of implementation efficiency.
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 value is used. In either case, the worst an attacker could do
against ECMP or LAG is to attempt to selectively overload a against ECMP or LAG is to attempt to selectively overload a
skipping to change at page 8, line 21 skipping to change at page 8, line 21
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 Jarno Rajahalme, Brian
Haberman, Sheng Jiang, Thomas Narten, and others. Haberman, Sheng Jiang, Thomas Narten, 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-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,
2010-10-07 2010-10-07
skipping to change at page 8, line 47 skipping to change at page 8, line 49
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-02 (work in progress), draft-ietf-6man-flow-3697bis-04 (work in progress),
March 2011. May 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. 
23 lines changed or deleted 24 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/