Update to the IPv6 flow label specification
draft-carpenter-6man-flow-update-04

Abstract

Various published proposals for use of the IPv6 flow label are incompatible with its existing specification in RFC 3697. Furthermore, very little practical use is made of the flow label, partly due to some uncertainties about the correct interpretation of the specification. This document proposes changes to the specification in order to clarify it, making it clear what types of usage are possible, and to introduce some additional flexibility.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 March 20, 2011.

Copyright Notice

Copyright (c) 2010 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.  Impact of current specification
3.  Normative Notation
4.  Proposed changes to specification
5.  Discussion
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  Change log
10.  References
    10.1.  Normative References
    10.2.  Informative References
Appendix A.  Alternative Approaches
§  Authors' Addresses

1.  Introduction

The flow label field in the IPv6 header was reserved but left experimental by [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.), which mandates only that "Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet."

The flow label field was normatively specified by [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.). In particular, we quote three rules from that RFC:

a.

"The Flow Label value set by the source MUST be delivered unchanged to the destination node(s)."

b.

"IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values assigned by source nodes."

c.

"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."

Additionally, RFC 3697 leaves it undefined what method a host should adopt by default to choose the value of the flow label, if no specific method is in use. It was expected that various signalling methods might be defined for agreeing on values of the flow label, but no such methods have been standardised.

The flow label is hardly used in practice in existing IPv6 implementations. To some extent this is due to the main focus being on basic deployment of IPv6, but the absence of a default method of choosing the flow label value means that most host implementations simply set it to zero. There is also anecdotal evidence that the rules quoted above have led to uncertainty about exactly what is possible. Furthermore, various use cases have been proposed that infringe one or another of the rules. None of these proposals has been accepted as a standard and in practice there is no significant deployment of any mechanism to set the flow label.

The intention of this document is to explain this in more detail and to propose changes to RFC 3697 intended to remove the uncertainties and encourage active usage of the flow label.

2.  Impact of current specification

Rule (a) makes it impossible for the routing system to use the flow label as any form of dynamic routing tag. This was a conscious choice in the early design of IPv6 and there appears to be no practical possibility of revisiting this choice at this stage in the deployment of IPv6, which uses conventional routing mechanisms like those used for IPv4. However, this rule also makes it impossible to make any use at all of the flow label unless hosts choose to set it. It also forbids clearing the flow label for security reasons.

This last point highlights the security properties, or rather the lack of them, of the flow label. The flow label field is always unprotected as it travels through the network, because there is no IPv6 header checksum, and the flow label is not included in transport pseudo-header checksums, nor in IPsec checksums. As a result, intentional and malicious changes to its value cannot be detected. Also, it could be used as a covert data channel, since apparently pseudo-random flow label values could in fact consist of encrypted data. If the flow label were to carry quality of service semantics, then like the diffserv code point [RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.), it would not be intrinsically trustworthy across domain boundaries. As a result, some security specialists believe that flow labels should be cleared for safety. These points must be considered when discussing the immutability of the flow label across domain boundaries.

Rule (b) appears to forbid any usage in which the bits of the flow label are encoded with a specific semantic meaning. If the word "alone" is overlooked, rule (c) has sometimes been interpreted to forbid the use of the flow label as part of a hash used by load balancing mechanisms.

Both before and after these rules were laid down, a considerable number of proposals for use of the flow label were published that seem incompatible with them. Numerous examples and an analysis are presented in [I‑D.hu‑flow‑label‑cases] (Hu, Q. and B. Carpenter, “Survey of proposed use cases for the IPv6 flow label,” August 2010.). Those examples propose use cases in which some or all of the following apply:

• The flow label may be changed by intermediate systems.
• It doesn't matter if the flow label is changed, because the receiver doesn't use it.
• Some or all bits of the flow label are encoded: they have specific meanings understood by routers and switches along the path.
• The encoding is related to the required quality of service, as well as identifying a flow.
• The flow label is used to control forwarding or switching in some way.

These proposals all require either some form of encoding of semantics in the bits of the flow label, or the ability for routers to modify the flow label, or both. Thus they appear to infringe the rules from RFC 3697 quoted above.

We can conclude that a considerable number of researchers and designers have been stymied by RFC 3697. On the other hand, some other proposals discussed in [I‑D.hu‑flow‑label‑cases] (Hu, Q. and B. Carpenter, “Survey of proposed use cases for the IPv6 flow label,” August 2010.) appear to be compatible with RFC 3697. Several are based on the originator of a packet choosing a pseudo-random flow label for each flow, which is one option suggested in RFC 3697. Thus, we can also conclude that there is a useful role for this approach.

If our goal is for the flow label to be used in practice, the conflict between the various approaches creates a dilemma. There appear to be two major options:

1. Discourage locally defined use of the flow label. Strengthen RFC 3697 to say that hosts SHOULD set a pseudo-random label value, which would clarify and limit its possible uses. In particular, its use for load balancing would be encouraged.
2. Relax the rules to encourage locally defined use of the flow label. This approach would make the flow label completely mutable and would exclude use cases depending on strict end-to-end immutability. It would encourage applications of a pseudo-random flow label, such as load balancing, on a local basis, but it would exclude end-to-end applications such as [I‑D.blake‑ipv6‑flow‑label‑nonce] (Blake, S., “Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks,” October 2009.).

During 2010 there has been considerable debate about these options and variants of them, with a variety of proposals in previous versions of this document and in mailing list discussions. After these discussions, there appears to be a view that simplicity should prevail, and that complicated proposals such as defining quality of service semantics in the flow label, or sub-dividing the flow label field into smaller sub-fields, will not prove efficient or deployable, especially in high speed routers. There is also a clearly expressed view that using the flow label for various forms of stateless load balancing is the best simple application for it. At the same time, it is necessary to recognize that the strict immutability rule has drawbacks as noted above.

Even under the rules of RFC 3697, the flow label is intrinsically untrustworthy, because modifcations en route cannot be detected. For this reason, even with the current strict immutability rule, downstream nodes cannot rely on the value being unchanged. In this sense, any use of the flow label must be viewed as an optimisation on a best effort basis; a packet with a changed (or zero) flow label value should never cause a hard failure.

The remainder of this document is in the form of a set of proposed modifications to the standard, consistent with the points above and written in normative form. It is suggested that if the proposal is generally accepted, a revised version of RFC 3697 should be produced including these changes.

3.  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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

4.  Proposed changes to specification

Although RFC 3697 requires the flow label to be delivered unchanged, as noted above, it is not included in any transport layer pseudo-header checksums nor in IPsec authentication [RFC4302] (Kent, S., “IP Authentication Header,” December 2005.). Both RFC 2460 and RFC 3697 define the default flow label to be zero. At the time of writing, this is the observed value in an overwhelming proportion of IPv6 packets; neither operating systems nor applications currently set it, and routers do not rely on it. Thus there is no reason to expect operational difficulties if a careful change is made to the rules of RFC 3697.

In particular, the facts that the label is not checksummed and rarely used mean that the current strict immutability of the label can be moderated without operational consequences.

The purposes of the proposed changes are to remove the uncertainties left by RFC 3697, in order to encourage setting of the flow label by default, and to enable its generic use. The proposed generic use is to encourage pseudo-random flow labels that can be used to assist load balancing. There should be no impact on existing IETF specifications other than RFC 3697 and no impact on currently operational software and hardware.

A secondary purpose is to modify the immutability of the flow label in a limited way, to allow hosts that do not set the flow label to benefit from it nevertheless.

The fact that the flow label may in practice be changed en route is also reflected in the reformulation of the rules.

A description of the changes follows. They are written in normative language to avoid ambiguity. They are mainly not written as specific text changes to RFC 3697, and significant rewriting of the latter is needed to incorporate these changes.

The definition of a flow is subtly changed from RFC 3697 as follows:

A flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that a node desires to label as a flow. A flow could consist of all packets in a specific transport connection or a media stream. However, a flow is not necessarily 1:1 mapped to a transport connection.

The change is that the words 'the source' have been replaced by 'a node'. Nodes that do not support the flow label remain subject to RFC 2460. The intention is to enable the following new specifications:

1. It is RECOMMENDED that source hosts support the flow label by setting the flow label field for all packets of a flow to the same pseudo-random value.
• This rule updates the less precise recommendation made in Section 3 of RFC 3697. Both stateful and stateless methods of assigning a pseudo-random value could be used, but it is outside the scope of this specification to mandate an algorithm.
• An OPTIONAL algorithm for generating such a pseudo-random value is proposed in [I‑D.gont‑6man‑flowlabel‑security] (Gont, F., “Security Assessment of the IPv6 Flow Label,” August 2010.).
• Section 3 of RFC 3697 also allows nodes to participate in an unspecified method of flow state establishment. The changes do not remove that option.



2. A node that forwards a flow whose flow label value in arriving packets is zero MAY set the flow label value. In that case, it is RECOMMENDED that the forwarding node sets the flow label field for a flow to a pseudo-random value.
• The same considerations apply as to the first recommendation.
• This option, if implemented, would presumably be used by ingress routers. It would place a considerable per-packet processing load on them, even if they adopted a stateless method of flow identification and label assignment. This is why the principal recommendation is that the source host should set the label.



3. In general, a forwarding node MUST NOT change the flow label value in an arriving packet if it is non-zero. However, there are two qualifications to this rule:
   1. A forwarding node acting as a domain border device MAY be configured to set the flow label value in incoming packets to the default value of zero. [[Note in draft - this is contentious, but it's going to happen anyway.]]
   2. A network domain MUST NOT forward packets outside the domain whose flow label values are other than zero or pseudo-random.
   
   
   Note that the new rules above, taken together, allow a given network domain to include routers that set flow labels on behalf of hosts that do not do so, and to be protected at its border (if desired) by clearing flow labels deemed to be untrustworthy. They also require that flow labels exported to the Internet must always be either zero or pseudo-random. These changes replace rule (a) quoted in Section 1 (Introduction). They therefore exclude Internet-wide mechanisms that depend rigidly on immutable flow labels. Given the intrinsic forgeability of the flow label, this seems unavoidable.



4. IPv6 nodes MUST NOT assume that the Flow Label value in a incoming packet is identical to the value set by the source node.
• This replaces rule (b) quoted in Section 1 (Introduction).
• Even though the flow label is in general immutable, this is not guaranteed in real life, hence this rule. See further discussion below.



5. Forwarding nodes such as routers and load balancers MUST NOT depend only on Flow Label values being randomly distributed. In any usage such as a hash key for load balancing, the Flow Label bits MUST be combined with bits from other sources within the packet, so as to produce a suitable distribution of hash values.
• This replaces rule (c) quoted in Section 1 (Introduction). Although a pseudo-random flow label is recommended, and will always be helpful for load balancing, it is unsafe to assume its presence in the general case, and the use case needs to work even if the flow label value is zero.

5.  Discussion

The following are the consequences of the above changes, taken together with the unaffected parts of RFC 3697:

• Sending hosts that are not updated will in practice continue to send all-zero labels. If there is no label-setting router along the path taken by a packet, the label will be delivered as zero.
• Sending hosts conforming to this specification will by default choose pseudo-random labels between 1 and 0xFFFFF.
• Sending hosts may continue to send all-zero labels, in which case an ingress router may set pseudo-random labels between 1 and 0xFFFFF.
• Border security devices may clear untrustworthy flow labels.
• The flow label is no longer asserted to be strictly immutable. In some circumstances this will break end-to-end usage such as proposed in [I‑D.blake‑ipv6‑flow‑label‑nonce] (Blake, S., “Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks,” October 2009.).
• The expected default usage of the flow label is some form of load balancing, such as the ECMP/LAG usage defined in [I‑D.carpenter‑flow‑ecmp] (Carpenter, B. and S. Amante, “Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels,” April 2010.).
• If the rules in Section 4 (Proposed changes to specification) are followed, especially rule 3.2, all IPv6 traffic flows on the Internet will have zero or pseudo-random flow label values.

From an operational viewpoint, existing IPv6 hosts that set a default (zero) flow label value and ignore the flow label on receipt will be unaffected by implementations of this specification. In general, it is assumed that hosts will ignore the value of the flow label on receipt; it cannot be relied on as an end-to-end signal of any kind.

Similarly, routers that ignore the flow label will be unaffected by implementations of this specification.

Hosts that set a default (zero) flow label and are in a domain where routers adopt the recommended pseudo-random mechanism in Section 4 (Proposed changes to specification) will benefit from whatever flow label handling is used in the local domain.

Hosts and routers that adopt the recommended pseudo-random mechanism will enhance the performance of any load balancing devices that include the flow label in the hash used to select a particular path or server, even when packets leave the local domain.

6.  Security Considerations

The flow label is not protected in any way and can be forged by an on-path attacker. On the other hand, a pseudo-random flow label cannot be readily guessed by an off-path attacker. See RFC 3697 and [I‑D.gont‑6man‑flowlabel‑security] (Gont, F., “Security Assessment of the IPv6 Flow Label,” August 2010.) for further discussion.

This proposal recognises that security devices might clear flow label values, if local policy so requires.

7.  IANA Considerations

This document requests no action by IANA.

8.  Acknowledgements

The authors are grateful to Qinwen Hu for general discussion about the flow label and for his work in searching the literature. Valuable comments and contributions were made by Fred Baker, Steve Blake, Remi Despres, Fernando Gont, Brian Haberman, Joel Halpern, Chris Morrow, Thomas Narten, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants in the 6man working group.

This document was produced using the xml2rfc tool [RFC2629] (Rose, M., “Writing I-Ds and RFCs using XML,” June 1999.).

9.  Change log

draft-carpenter-6man-flow-update-04: even more simplified according to WG discussion, 2010-09-16

draft-carpenter-6man-flow-update-03: futher simplified according to WG discussion, 2010-05-07

draft-carpenter-6man-flow-update-02: revised and simplified according to WG discussion, 2010-04-13

draft-carpenter-6man-flow-update-01: revised according to mail list discussion, 2010-03-05

draft-carpenter-6man-flow-update-00: original version, 2010-02-18

10.  References

10.1. Normative References

10.2. Informative References

Appendix A.  Alternative Approaches

A model was discussed in an earlier version of this document which defined a notion of 'flow label domain' analogous to a differentiated services domain [RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.). This model would have encouraged local usage of the flow label as an alternative to any form of generic use, but it required complex rules for the behaviour of domain boundary routers, and proved controversial in discussion.

Two even more complex alternative approaches were also considered and rejected.

The first was to distinguish locally significant flow labels from those conforming to RFC 3697 by setting or clearing the most significant bit (MSB) of the flow label. This led to quite complicated rules, seems impossible to make fully self-consistent, and was not considered practical.

The second was to use a specific differentiated services code point (DSCP)[RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.) in the Traffic Class octet instead of the MSB of the flow label itself, to flag a locally defined behaviour. A more elaborate version of this was proposed in [I‑D.martinbeckman‑ietf‑ipv6‑fls‑ipv6flowswitching] (Beckman, M., “IPv6 Dynamic Flow Label Switching (FLS),” March 2007.). There are two issues with this approach. One is that DSCP values are themselves only locally significant, inconsistent with the end-to-end nature of the original flow label definition. Secondly, it seems unwise to meld the semantics of differentiated services, which are currently deployed, with the unknown future semantics of flow label usage. However, this approach, while not recommended, does not appear to violate any basic principles if applied strictly within a single differentiated services domain.

Authors' Addresses