Flow label for ECMP: Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels
How tunnel endpoints and routers can use the IPv6 flow label to spread traffic over equal cost paths.
Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>.
@misc{rfc6438,
series = {Request for Comments},
number = 6438,
howpublished = {RFC 6438},
publisher = {RFC Editor},
doi = {10.17487/RFC6438},
url = {https://www.rfc-editor.org/info/rfc6438},
author = {B. Carpenter and S. Amante},
title = {{Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels}},
pagetotal = 9,
year = 2011,
month = nov,
} RFC text
Contents
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6438 Univ. of Auckland
Category: Standards Track S. Amante
ISSN: 2070-1721 Level 3
November 2011
Using the IPv6 Flow Label for
Equal Cost Multipath Routing and Link Aggregation in Tunnels
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
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6438.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Choice of IP Header Fields for Hash Input . . . . . . . . . 3
1.2. Flow Label Rules . . . . . . . . . . . . . . . . . . . . . 4
2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 5
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
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 (ECMP) routing and link
aggregation (LAG) [IEEE802.1AX]. There are, of course, numerous
possible approaches to this, but certain goals need to be met:
o Maintain roughly equal share of traffic on each path.
(In some cases, the multiple paths might not all have the same
capacity, and the goal might be appropriately weighted traffic
shares rather than equal shares. This would affect the load-
sharing algorithm but would not otherwise change the argument.)
o Minimize or avoid out-of-order delivery for individual traffic
flows.
o Minimize idle time on any path when queue is non-empty.
There is some conflict between these goals: for example, strictly
avoiding idle time could cause a small packet sent on an idle path to
overtake a bigger packet from the same flow, causing out-of-order
delivery.
One lightweight approach to ECMP or LAG is this: if there are N
equally good paths to choose from, then form a modulo(N) hash
[RFC2991] from a defined set of fields in each packet header that are
certain to have the same values throughout the duration of a flow,
and use the resulting output hash value to select a particular path.
If the hash function is chosen so that the output values have a
uniform statistical distribution, this method will share traffic
roughly equally between the N paths. If the header fields included
in the hash input are consistent, all packets from a given flow will
generate the same hash output value, so out-of-order delivery will
not occur. Assuming a large number of unique flows are involved, it
is also probable that the method will avoid idle time, since the
queue for each link will remain non-empty.
1.1. Choice of IP Header Fields for Hash Input
In the remainder of this document, we will use the term "flow" to
represent a sequence of packets that may be identified by either the
source and destination IP addresses alone {2-tuple} or the source IP
address, destination IP address, protocol number, source port number,
and destination port number {5-tuple}. It should be noted that the
latter is more specifically referred to as a "microflow" in
[RFC2474], but this term is not used in connection with the flow
label in [RFC3697].
The question, then, is which header fields are used to identify a
flow and serve as input keys to a modulo(N) hash algorithm. A common
choice when routing general traffic is simply to use a hash of the
source and destination IP addresses, i.e., the 2-tuple. This is
necessary and sufficient to avoid out-of-order delivery and, with a
wide variety of sources and destinations as one finds in the core of
the network, often statistically sufficient to distribute the load
evenly. In practice, many implementations use the 5-tuple {dest
addr, source addr, protocol, dest port, source port} as input keys to
the hash function, to maximize the probability of evenly sharing
traffic over the equal cost paths. However, including transport-
layer information as input keys to a hash may be a problem for IP
fragments [RFC2991] or for encrypted traffic. Including the protocol
and port numbers, totaling 40 bits, in the hash input makes the hash
slightly more expensive to compute but does improve the hash
distribution, due to the variable nature of ephemeral ports.
Ephemeral port numbers are quite well distributed [Lee10] and will
typically contribute 16 variable bits. However, in the case of IPv6,
transport-layer information is inconvenient to extract, due to the
variable placement of and variable length of next-headers; all
implementations must be capable of skipping over next-headers, even
if they are rarely present in actual traffic. In fact, [RFC2460]
implies that next-headers, except hop-by-hop options, are not
normally inspected by intermediate nodes in the network. This
situation may be challenging for some hardware implementations,
raising the potential that network equipment vendors might sacrifice
the length of the fields extracted from an IPv6 header.
It is worth noting that the possible presence of a Generic Routing
Encapsulation (GRE) header [RFC2784] and the possible presence of a
GRE key within that header creates a similar challenge to the
possible presence of IPv6 extension headers; anything that
complicates header analysis is undesirable.
The situation is different in IP-in-IP tunneled scenarios.
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 endpoint (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, i.e., polarization
will occur. If there is a high proportion of traffic from one or a
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 [MPLS-LABEL].)
_____ _____ _____ _____
| TEP |_________| R1 |-------------| R2 |_________| TEP |
|__A__| |_____|-------------|_____| |__B__|
tunnel ECMP or LAG tunnel
here
As noted above, for IPv6, the 5-tuple is 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 algorithm,
especially in the case of tunnels where the inner packet header is
inaccessible. If the flow label could be used in place of the port
numbers and protocol number in the 5-tuple, the implementation would
be simplified.
1.2. Flow Label Rules
The flow label was left Experimental by [RFC2460] but was better
defined by [RFC3697]. We quote three rules from that RFC:
1. "The Flow Label value set by the source MUST be delivered
unchanged to the destination node(s)."
2. "IPv6 nodes MUST NOT assume any mathematical or other properties
of the Flow Label values assigned by source nodes."
3. "Router performance SHOULD NOT be dependent on the distribution
of the Flow Label values. Especially, the Flow Label bits alone
make poor material for a hash key."
These rules, especially the last one, have caused designers to
hesitate about using the flow label in support of ECMP or LAG. The
fact is that today most nodes set a zero value in the flow label, and
the first rule definitely forbids the routing system from changing
the flow label once a packet has left the source node. Considering
normal IPv6 traffic, the fact that the flow label is typically zero
means that it would add no value to an ECMP or LAG hash, but neither
would it do any harm to the distribution of the hash values.
However, in the case of an IP-in-IPv6 tunnel, the TEP is itself the
source node of the outer packets. Therefore, a TEP may freely set a
flow label in the outer IPv6 header of the packets it sends into the
tunnel.
The second two rules quoted above need to be seen in the context of
[RFC3697], which assumes that routers using the flow label in some
way will be involved in some sort of method of establishing flow
state: "To enable flow-specific treatment, flow state needs to be
established on all or a subset of the IPv6 nodes on the path from the
source to the destination(s)." The RFC should perhaps have made
clear that a router that has participated in flow state establishment
can rely on properties of the resulting flow label values without
further signaling. If a router knows these properties, rule 2 is
irrelevant, and it can choose to deviate from rule 3.
In the tunneling situation sketched above, routers R1 and R2 can rely
on the flow labels set by TEP A and TEP B being assigned by a known
method. This allows an ECMP or LAG method to be based on the flow
label consistently with [RFC3697], regardless of whether the non-
tunnel traffic carries non-zero flow label values.
The IETF has recently revised RFC 3697 [RFC6437]. That revision is
fully compatible with the present document and obviates the concerns
resulting from the above three rules. Therefore, the present
specification applies both to RFC 3697 and to RFC 6437.
2. Normative Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Guidelines
We assume that the routers supporting ECMP or LAG (R1 and R2 in the
above figure) are unaware that they are handling tunneled traffic.
If it is desired to include the IPv6 flow label in an ECMP or LAG
hash in the tunneled scenario shown above, the following guidelines
apply:
o Inner packets MUST be encapsulated in an outer IPv6 packet whose
source and destination addresses are those of the tunnel endpoints
(TEPs).
o The flow label in the outer packet SHOULD be set by the sending
TEP to a 20-bit value in accordance with [RFC6437]. 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 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 [RFC6437], the flow label 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
[RFC6437] 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 routers 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 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 Operations, Administration, and Maintenance (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 [RFC6391].
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 endpoints and
the ECMP or LAG paths will be part of a managed infrastructure that
is well protected against on-path attacks (e.g., by using IPsec
between the two tunnel endpoints). 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 attempt to selectively overload a
particular path. For further discussion, see [RFC6437].
5. Acknowledgements
This document was suggested by corridor discussions at IETF 76. 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.
6. References
6.1. Normative References
[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.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J.
Rajahalme, "IPv6 Flow Label Specification", RFC 6437,
November 2011.
6.2. Informative References
[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.
[MPLS-LABEL] Kompella, K., Drake, J., Amante, S., Henderickx, W.,
and L. Yong, "The Use of Entropy Labels in MPLS
Forwarding", Work in Progress, May 2011.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[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.
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V.,
Regan, J., and S. Amante, "Flow-Aware Transport of
Pseudowires over an MPLS Packet Switched Network",
RFC 6391, November 2011.
Authors' Addresses
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland 1142
New Zealand
EMail: brian.e.carpenter@gmail.com
Shane Amante
Level 3 Communications, LLC
1025 Eldorado Blvd
Broomfield, CO 80021
USA
EMail: shane@level3.net
ISO Plain Language
On this page
§1Equal Cost Multipath and Link Aggregation
When the routing system knows that several paths between the same two nodes are equally good in capacity and latency, it can be useful to share traffic among them. Two techniques do this: equal cost multipath (ECMP) routing and link aggregation (LAG). Several goals have to be met at once. The traffic share on each path should stay roughly equal, or appropriately weighted when the paths differ in capacity. Out-of-order delivery within an individual flow should be avoided as far as possible. Idle time on any path should be minimised when a queue elsewhere is not empty.
These goals can conflict. Strictly avoiding idle time could let a small packet sent on an idle path overtake a larger packet from the same flow, which is out-of-order delivery.
The lightweight approach described here is a modulo(N) hash over a defined set of packet header fields, where N is the number of equally good paths. The fields chosen are certain to hold the same values for the whole duration of a flow, and the hash output selects a path. If the hash function has a uniform statistical distribution, the traffic is shared roughly equally. Because the hash input is consistent across a flow, all packets of that flow produce the same output, so no reordering happens within the flow. With a large number of distinct flows, each link's queue also stays non-empty, which avoids idle paths.
When a router has several equally good ways to reach the same destination, it can split traffic across them. A common way is to hash certain header fields of each packet and pick the path by the result. Packets of the same flow hash the same way, so they all take the same path and stay in order.
- OUTER PACKETOuter source A, outer destination B, flow label set by the sending tunnel endpoint.
- ECMP OR LAG SELECTIONThe outgoing link is chosen by hashing the 3-tuple {dest addr, source addr, flow label}.
- OUTER PACKETThe same flow label value is carried through to the far tunnel endpoint.
§1.1Choosing Header Fields for the Hash
Throughout the document a flow is a sequence of packets identified either by the source and destination IP addresses alone, the 2-tuple, or by source address, destination address, protocol number, source port and destination port, the 5-tuple. The 5-tuple is more specifically called a microflow in RFC 2474, but that term is not used in connection with the flow label in RFC 3697.
For general traffic a common choice is a hash of the 2-tuple. That is necessary and sufficient to avoid out-of-order delivery, and with the variety of sources and destinations found in the core of the network it is often statistically enough to distribute the load evenly. In practice many implementations use the 5-tuple, because the protocol number and port numbers add 40 bits and improve the distribution thanks to the variability of ephemeral ports, which are well distributed and typically contribute 16 variable bits. Including transport-layer information can be a problem for IP fragments and for encrypted traffic.
In IPv6 the 5-tuple is inconvenient to extract, because the next-header fields vary in placement and length, so every implementation must be able to skip over next-headers even when they rarely appear. RFC 2460 implies that next-headers other than hop-by-hop options are not normally inspected by intermediate nodes, so some hardware implementations may struggle, and network equipment vendors might cut the number of fields they take from an IPv6 header. A Generic Routing Encapsulation (GRE) header and a GRE key create a similar difficulty, and anything that complicates header analysis is undesirable.
The situation is different in IP-in-IP tunneled scenarios. Identifying a flow inside a tunnel is more complicated, because nearly all hardware can only identify flows from the outermost IP header. Suppose traffic from many sources to many destinations is aggregated in a single IP-in-IP tunnel from tunnel endpoint A to tunnel endpoint B. All packets forming the tunnel have outer source address A and outer destination address B, and in all probability the same port and protocol numbers. If ECMP or LAG is applied between routers R1 and R2, the 2-tuple or 5-tuple and its hash are constant, so no load sharing is achieved: polarization occurs. If a high proportion of traffic comes from one or a small number of tunnels, the traffic is not distributed as intended across the paths between R1 and R2, which is partial polarization.
The hash needs fields that do not change during a flow. Source and destination addresses work, and adding the protocol and ports spreads traffic better. But in IPv6 those transport fields sit behind variable-length extension headers, so routers often cannot read them cheaply. Inside a tunnel, the outer addresses are the same for every packet, so hashing them sends all the traffic down one path.
| Hash input | What the RFC says |
|---|---|
| 2-tuple | Source and destination addresses. Necessary and sufficient to avoid out-of-order delivery, and often statistically sufficient in the network core. |
| 5-tuple | Adds protocol and port numbers, 40 bits in total. Improves the hash distribution but is inconvenient to extract in IPv6 and is a problem for fragments and encrypted traffic. |
| 3-tuple with flow label THIS RFC | The 20-bit IPv6 flow label replaces the port numbers and protocol number as hash input where the inner header is inaccessible, as in a tunnel. |
§1.2The Flow Label Rules
The flow label was left Experimental by RFC 2460 and was better defined by RFC 3697. Three rules from that document are quoted. The flow label value set by the source must be delivered unchanged to the destination nodes. IPv6 nodes must not assume any mathematical or other properties of the flow label values assigned by source nodes. Router performance should not depend on the distribution of the flow label values, and especially the flow label bits alone make poor material for a hash key.
These rules, and the last one in particular, made designers hesitant to use the flow label for ECMP or LAG. Most nodes set a zero value in the flow label, and the first rule forbids the routing system from changing the flow label once a packet has left the source node. For normal IPv6 traffic a typically zero flow label would add nothing to an ECMP or LAG hash, though it would do no harm to the distribution of the hash values either.
In an IP-in-IPv6 tunnel, however, the tunnel endpoint is itself the source node of the outer packets, so it may freely set a flow label in the outer IPv6 header of the packets it sends into the tunnel. The second and third rules have to be read in the context of RFC 3697, which assumes that routers using the flow label take part in some method of establishing flow state, so that flow state is established on all or a subset of the IPv6 nodes on the path. A router that knows the properties of the resulting flow label values can rely on them without further signalling, and rule 2 does not apply to it; it can also deviate from rule 3. In the tunnel situation, routers R1 and R2 can rely on the flow labels set by the tunnel endpoints being assigned by a known method. An ECMP or LAG method can therefore be based on the flow label consistently with RFC 3697, whether or not the non-tunnel traffic carries non-zero flow label values.
The IETF has since revised RFC 3697 in RFC 6437. That revision is fully compatible with this document and removes the concerns that came from the three rules above, so this specification applies both to RFC 3697 and to RFC 6437.
Earlier IPv6 rules told routers not to depend on the flow label, because most senders left it at zero and the label was not protected. A tunnel endpoint is different: it creates the outer header, so it chooses the label itself, and the routers on the path can be told how it is chosen. The newer flow label specification, RFC 6437, settles this.
- Delivered unchangedThe flow label value set by the source must reach the destination nodes unchanged.
- No assumed propertiesIPv6 nodes must not assume any mathematical or other properties of the flow label values.
- Poor hash materialRouter performance should not depend on the distribution of the values, and the label bits alone make a poor hash key.
§3Guidelines
The guidelines assume that the routers supporting ECMP or LAG, R1 and R2 in the figure, do not know they are handling tunneled traffic. If the IPv6 flow label is to be included in an ECMP or LAG hash in that scenario, the following apply.
Inner packets must be encapsulated in an outer IPv6 packet whose source and destination addresses are those of the tunnel endpoints. The flow label in the outer packet should be set by the sending tunnel endpoint to a 20-bit value in accordance with RFC 6437, and 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. To achieve this, the sending endpoint must classify all packets into flows once it has decided they should enter a given tunnel, and then write the relevant flow label into the outer IPv6 header. A user flow can be identified by the sending endpoint most simply by its {destination, source} address 2-tuple or by its 5-tuple; using the {dest addr, source addr, flow label} 3-tuple of the inner packet would be a future-proof option, and the choice of n-tuple is an implementation choice in the sending endpoint.
As specified in RFC 6437, the flow label values should be chosen from a uniform distribution. Such values suit a load-balancing hash function and are hard for a malicious third party to predict. The sending endpoint 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 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 that two different user flows hash to the same label; since RFC 6437 allows a source to define any set of packets as a single flow, occasionally labelling two user flows as one flow through the tunnel is acceptable.
At intermediate routers that perform load distribution, the hash algorithm used to determine the outgoing component link 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 only or a mixture of tunneled and normal traffic. Because an intermediate IPv6 router will probably meet a mixture of tunneled and normal traffic, the design should also include {protocol, dest port, source port} as input keys, to give additional entropy for flows whose flow label is zero, including non-tunneled traffic flows.
Individual nodes are free to implement different algorithms that conform to this specification without affecting the interoperability or function of the network. Operations, administration and maintenance techniques will need to be adapted to manage ECMP and LAG based on the flow label, with issues similar to those that arise for MPLS and pseudowires.
The tunnel endpoint reads the inner packet headers, works out which flow the packet belongs to, and writes a label for that flow into the outer IPv6 header. Every packet of the same flow gets the same label. The routers in between then hash the outer address pair and the label, and add the protocol and ports when they can, so that flows with a zero label still spread out.
§4Security Considerations
The flow label is not protected in any way and can be forged by an on-path attacker. It is expected, however, that tunnel endpoints and the ECMP or LAG paths will be part of a managed infrastructure that is well protected against on-path attacks, for example by using IPsec between the two tunnel endpoints. 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 try to selectively overload a particular path. The RFC refers the reader to RFC 6437 for further discussion.
Nothing protects the flow label, so an attacker on the path could change it. The expected answer is that tunnels run inside a managed and protected network. Even then, the most an attacker could achieve is to push traffic onto one path and overload it.