Survey of proposed use cases for the IPv6 flow label
draft-hu-flow-label-cases-01

Abstract

The IPv6 protocol includes a flow label in every packet header, but it is not used in practice. This paper describes the flow label standard and discusses the implementation issues that it raises. It then describes various published proposals for using the flow label, and shows that most of them are inconsistent with the standard. Methods to address this problem are briefly reviewed. We also question whether the standard should be revised.

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 February 19, 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.  Flow label definition and issues
    2.1.  Flow label properties
    2.2.  Dependency prohibition
    2.3.  Other issues
3.  Documented proposals for the flow label
    3.1.  Specify the flow label as a pseudo-random value
    3.2.  Specify QoS parameters in the flow label
    3.3.  Use flow label to control switching
    3.4.  Diffserv use of IPv6 flow label
    3.5.  Other uses
4.  Discussion
5.  Conclusion
6.  Security Considerations
7.  IANA Considerations
8.  Acknowledgements
9.  Change log
10.  Informative References
§  Authors' Addresses

1.  Introduction

For many years it has been recognized that real-time Internet traffic requires a different quality of service from general data traffic, and this remains true in the era of network neutrality. Thus an alternative to uniform best-effort service is needed, requiring packets to be classified as belonging to a particular class of service or flow. Currently, this leads to a layer violation problem, since a 5-tuple is often used to classify each packet. The 5-tuple includes source and destination addresses, port numbers, and the transport protocol type, so when we want to forward or process packets, we need to extract information from the layer above IP. This may be impossible when packets are encrypted such that port numbers are hidden, or when packets are fragmented, so the layer violation is not an academic concern.

IPv6 will progressively replace the current IPv4 protocol. This will solve the Internet's address shortage, but it also offers a new feature to resolve the above difficulty, i.e., the flow label field in the IPv6 packet header. The flow label is not encrypted by IPsec, and is present in all fragments. It was reserved in the IPv6 packet header in 1995 [RFC1883] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1995.), and general rules governing its use were defined in 2004 [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.), but it is still rarely set in IPv6 packets. This paper reviews the syntax and semantics of the flow label, and then describes various proposals that have been made for its use.

The original proposal for a random flow label has been attributed to Dave Clark [Deering] (Deering, S., “SIPP Overview and Issues,” November 1993.). A flow label field was included in the IPv6 packet header during the preliminary design of IPv6, which followed an intense period of debate about several competing proposals. The final choice was made in 1994 [RFC1752] (Bradner, S. and A. Mankin, “The Recommendation for the IP Next Generation Protocol,” January 1995.). In particular, the IETF rejected a proposal known as CATNIP [RFC1707] (McGovern, M. and R. Ullmann, “CATNIP: Common Architecture for the Internet,” October 1994.), which included so-called 'cache handles' to identify the next hop in high performance routers. We recognize this today as a precursor of the MPLS label, and it introduced the notion of a header field that would be shared by all packets belonging to a flow, on a hop-by-hop basis. The IETF decided instead to develop a proposal known as SIPP into IP version 6. SIPP included "labeling of packets belonging to particular traffic 'flows' for which the sender requests special handling, such as non-default quality of service or 'real-time' service" [RFC1710] (Hinden, R., “Simple Internet Protocol Plus White Paper,” October 1994.). In 1994, this was a 28-bit flow label field. In 1995 it was down to 24 bits [RFC1883] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1995.) and it was finally reduced to 20 bits [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) to accommodate the IPv6 Traffic Class, which is fully compatible with the IPv4 Type of Service byte.

There was considerable debate in the IETF about the very purpose of the flow label. Was it to be a handle for fast switching, as in CATNIP, or was it to be meaningful to applications and for quality of service? Must it be set by the sending host, or could it be set by routers? Could it be modified en route, or must it be delivered with no change? Because of these uncertainties, and more urgent work, the flow label was consistently ignored by implementors, and today is set to zero in almost every IPv6 packet. In fact, [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) defined it as "experimental and subject to change." After preliminary work such as [I‑D.metzler‑ipv6‑flowlabel] (Metzler, J. and S. Hauth, “An end-to-end usage of the IPv6 flow label,” November 2000.), [I‑D.conta‑ipv6‑flow‑label] (Conta, A. and B. Carpenter, “A proposal for the IPv6 Flow Label Specification,” July 2001.), [I‑D.conta‑diffserv‑ipv6‑fl‑classifier] (Conta, A. and J. Rajahalme, “Amodel for Diffserv use of the IPv6 Flow Label Specification,” November 2001.) and [I‑D.itojun‑ipv6‑flowlabel‑api] (Hagino, J., “Socket API for IPv6 flow label field,” April 2001.), the standard [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) intended to clarify this situation by providing precise boundary conditions for use of the flow label.

This paper summarizes the resulting definition of the flow label and some open issues about its use, and then describes and analyses various use cases that have been proposed, before drawing conclusions and suggesting a strategy.

2.  Flow label definition and issues

2.1.  Flow label properties

The flow label field occupies bits 12 through 31 of the IPv6 packet header, providing an easy way to mark a packet, identify a flow, and look up the flow state. This field is always present, so a phrase such as "a packet with no flow label" refers to a packet whose flow label field contains 20 zero bits, i.e., a flow label whose value is zero. [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) standardizes properties of the flow label, including:

• If the packets are not part of any flow, the flow label value is zero.
• The 3-tuple {source address, destination address, flow label} uniquely identifies which packets belong to which particular flow.
• Packets can receive flow-specific treatment if the node has been set up with flow-specific state.
• The flow label set by the source node must be delivered to the destination node.
• The same pair of source and destination must not use the same flow label value again within 120 seconds or more.

One effect of these rules is to avoid the layer violation problem mentioned in Section 1 (Introduction). By using the 3-tuple, we only use the IP layer to classify packets, without needing any transport layer information. Also we can reduce the lookup time if flow-based treatment is required, and we can do this even with IPsec encryption and fragmentation. Therefore, for traffic needing other than best-effort service, such as real-time applications, the flow label can be set to different values to represent different flows, and each node may provide different flow-specific treatments by looking at the flow label value. This is more fine-grained than differentiated services (Diffserv) [Carpenter] (Carpenter, B. and K. Nichols, “Differentiated Services in the Internet,” 2002.), [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.) but need not be less efficient.

2.2.  Dependency prohibition

An additional important rule in the standard [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) effectively forbids any encoding of meaning in the bits of the flow label. To be exact, the standard states that "IPv6 nodes MUST NOT assume any mathematical or other properties of the flow Label values assigned by source nodes." Without this rule, if a packet with a non-zero flow label that is not from a source using a particular encoding method reaches a node that is following that method, and if by chance the bits in the flow label would be meaningful in that method, the receiver would misinterpret the flow label.

The standard also states "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." The problem this rule is intended to avoid is that if a source uses a simple method of choosing flow labels (e.g., counting up from 1), any router that assumes pseudo-randomness, e.g., to choose alternative routes for load-balancing, will be misled.

Note that there is no easy escape from the combination of these two prohibitions, which we will call the dependency prohibition. Unlike Diffserv code points, flow labels are not locally significant within a single administrative domain; they must be preserved end-to-end. In general, a router cannot know whether a particular packet originated in a host supporting a specific usage of the flow label. Therefore, any method that breaks one or both of these rules will only work if there is some method for the routers concerned to determine at line speed which sources use the same method.

2.3.  Other issues

How to use flow label most effectively is not discussed in [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) and remains the major open issue, but many researchers believe that it can be used with reserved bandwidth to achieve customized Quality of Service (QoS) provision. Coupled with admission control at the edge router, this should limit congestion. However, as we will see below, this is not the only use case proposed.

We now introduce some other open issues.

Unknown flow labels: [RFC1809] (Partridge, C., “Using the Flow Label Field in IPv6,” June 1995.) proposed that when a router receives a datagram with an unknown flow label, it should treat it as zero. However, the standard [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) is silent on this issue. Indeed, some methods of flow state establishment might choose to use an unknown label as the trigger for creating flow state.

Deleting old flow labels: When a flow finishes, how does the router know the flow label has expired? Should this be based on a timeout, on observation of the transport layer, or on explicit signalling? The standard defines a timeout (120 seconds) after which a receiving node should discard a previously recorded flow label if there is no more traffic. However, this will be unsatisfactory in the case of a very intermittent flow. In contrast, [I‑D.banerjee‑flowlabel‑ipv6‑qos] (Banerjee, R., “A Modified Specification for use of the IPv6 Flow Label for providing An efficient Quality of Service using hybrid approach,” April 2002.) suggested that a router should send an ICMP message to the source to delete a particular label. The source node can then either send a KEEPALIVE message to the router, or it can allow the router to release that label.

Choosing when to set the flow label: For what kinds of application should we set up non-zero flow labels? [RFC1809] (Partridge, C., “Using the Flow Label Field in IPv6,” June 1995.) suggested not setting it for short flows containing few bytes, but using it for long TCP connections and some real-time applications. However, this does not really define clear use cases.

Can we modify the flow label? [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) states that the flow label must be delivered unchanged. There are several advantages of non-mutable flow labels, apart from respecting the standard: the rule is easy to understand, does not require extra processing in routers or a signalling protocol, and allows for very simple host implementations. Also, it is straightforward for hosts and routers to simply ignore the flow label. However, this rule does appear to exclude any MPLS-like or CATNIP-like use for optimized packet switching. Some authors have objected to this feature, suggesting that switches should change the flow label for routing purposes. We will describe these and other proposed mechanisms in next section, and we will discuss their advantages and disadvantages.

3.  Documented proposals for the flow label

In the following, we do not intend to recommend or criticise various proposals. The intention is only to show the variety of proposals that have been published, and how they relate to the standard. We consider that published proposals for the flow label fall into three broad categories, i.e., (1) improve routing performance by using random flow label values; (2) define a QoS requirement in the flow label field; (3) use the flow label to extend existing QoS architectures such as Diffserv. Across these categories, we observe various options to set up the flow label value.

3.1.  Specify the flow label as a pseudo-random value

For example, [LinTseng] (Lin, C., Tseng, P., and W. Hwang, “End-to-End QoS Provisioning by Flow Label in IPv6,” 2006.) specifies a 17-bit pseudo-random value. The following figure shows the proposed flow label structure, which assumes that routers can support flow label and DiffServ architectures.

• The Label Flag (LF) bit: 1 means this type of flow label is present. We note that this encoding breaks the dependency prohibition in [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.), since a source that does not use this method may also set the LF bit.
• The Label type (LT): 2 bits which describe the type of packet.
• The Label Number (LN): which is randomly generated by the source node.

[LinTseng] (Lin, C., Tseng, P., and W. Hwang, “End-to-End QoS Provisioning by Flow Label in IPv6,” 2006.) also describes a signalling process between source, routing and destination nodes based on this label structure and on the IPv6 Traffic Class byte, in order to reserve and release router resources for a given flow within a given class of traffic. The pseudo-random LN value is used to uniquely identify a given flow.

Flow Label Specification (figure simplified from [LinTseng] (Lin, C., Tseng, P., and W. Hwang, “End-to-End QoS Provisioning by Flow Label in IPv6,” 2006.))

      +--+----+-----------------------------+
      | 1| 2  |              17 bits        |
      +--+----+-----------------------------+
      |LF| LT |              LN             |
      +--+----+-----------------------------+

LF   0  Disable
     1  Enable
LT  00  Flow label requested by source
    01  Flow label returned by destination
    10  Flow label for data delivery
    11  Flow label terminates connection
LN      Random number created by source

[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.) states that off-path spoofing attacks have become a big issue for TCP and other transport-layer applications, and proposes that in IPv6 we should set a random value in the flow label to make the packet header more complex and less easy for the attacker to guess. The two ends of the session will agree on flow label values during the SYN/ACK exchange, but off-path attackers will be unlikely to guess the agreed value. Naturally, on-path attackers who can observe the flow labels in use can trivially defeat this protection.

There have been numerous informal discussions of using random flow labels to allow load-balancing or at least load-sharing. However, concerns about the dependency prohibition have generally prevented such proposals from being written up until recently [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.).

3.2.  Specify QoS parameters in the flow label

[Prakash] (Prakash, B., “Using the 20 bit flow label field in the IPv6 header to indicate desirable quality of service on the internet,” 2004.) proposes to utilize the flow label to indicate required QoS parameters in detail. It uses the first few bits of the flow label field as codes to support different approaches, as summarized in following table. Again, this breaks the dependency prohibition in [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.), since a source that does not use this method may also set the first two bits to non-zero.

Classification for various approaches (from [Prakash] (Prakash, B., “Using the 20 bit flow label field in the IPv6 header to indicate desirable quality of service on the internet,” 2004.))

  Bit Pattern   Approach
  ------------------------------------------------------------------
  00            No QoS requirement (Default QoS value)
  01            Pseudo-Random value used for the value of Flow-Label
  10            Support for Direct Parametric Representation
  1100          Support for the DiffServ Model
  1101          Reserved for future use
  111           Reserved for future use

This method does allow for a pseudo-random option, but also adds options for a direct QoS request and for Diffserv. In the direct QoS parameters approach, 18 bits are used to encode requirements for one way delay, IP delay variation, bandwidth and one way packet loss. The proposal appears to assume that RSVP [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.) mechanisms are used to actually implement these QoS parameters.

This proposal allows use of flow label for various important QoS models, so the end user and service provider can choose the most suitable model for their situation; [Prakash] (Prakash, B., “Using the 20 bit flow label field in the IPv6 header to indicate desirable quality of service on the internet,” 2004.) claims that "this proposal is simple, scalable, modular and generic implementation to provide for QoS using the IPv6 flow label field".

Similarly, [LeeKim] (Lee, I. and S. Kim, “A QoS Improvement Scheme for Real-Time Traffic Using IPv6 Flow Labels,” 2004.) defines the flow label field in five parts, with the first 3 bits used as an approach type, because the authors have defined two approaches: a "random" scheme and a "hybrid" scheme. If the first 3 bits equal "001", the flow label will be used as the random identifier of the flow, but if they equal "101", the remaining bits will include the hybrid QoS requirement for this packet, subdivided into traffic type (stringent or best effort), bandwidth, buffer, and delay requirements. Once again the dependency prohibition in [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) is broken. This proposal also includes throughput monitoring and dynamic capacity allocation. Effectively this proposal uses the flow label both to signal Intserv-like QoS requirements and to classify traffic into Diffserv-like virtual label-switched paths. Packets with a "random" flow label are mapped into a generic (best effort) virtual path.

The authors simulated this architecture for a network of fourteen nodes, using the NS-2 simulator with a weighted fair queueing extension to support the "hybrid" scheme. Their results indicate that the "hybrid" scheme improves capacity utilization for QoS traffic and performance for real-time traffic, rather in the manner of differentiated services, whereas competing traffic using the "random" scheme simply experiences best effort service. It must be considered, however, that NS-2 does not accurately simulate the performance of typical high-performance routers.

3.3.  Use flow label to control switching

[I‑D.chakravorty‑6lsa] (Chakravorty, S., Bush, J., and J. Bound, “IPv6 Label Switching Architecture,” July 2008.) and [Chakravorty] (Chakravorty, S., “Challenges of IPv6 Flow Label implementation,” 2008.) describe an architectural framework called "IPv6 Label Switching Architecture" (6LSA). In 6LSA, network components identify a flow by looking at the flow label field in the IPv6 packet header; all packets with the same flow label must receive the same treatment and be sent to the same next hop. However, 6LSA resembles MPLS by considering that a label only has meaning between 6LSA routers, and setting the flow label at each hop. If the original source sets a non-zero flow label, there is no mechanism to restore it before delivery, a fundamental breach of [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.). The authors of [I‑D.chakravorty‑6lsa] (Chakravorty, S., Bush, J., and J. Bound, “IPv6 Label Switching Architecture,” July 2008.) did at one stage discuss using an IPv6 hop-by-hop option to correct this problem, but this has not been documented. This is a more serious problem than simply breaking the dependency prohibition

Unlike traditional routing algorithms, but like MPLS, 6LSA packets are classified into a Forwarding Equivalence Class (FEC), and routers forward packets on different paths by looking at the FEC. Like previous solutions, the authors divide the flow label field into three parts. The first 3 bits identify the FEC, which will help the router or 6LSA nodes to group the IP packets that receive the same forwarding treatment and forwarding them on the same virtual path. The following 4 bits describe the application type, and the final 13 bits (defined by each node or a group of nodes) specify the hop-specific label. From the table below, we can see the FEC has 6 major categories, each with up to 16 subcategories.

Flow Label Specification (shortened from [I‑D.chakravorty‑6lsa] (Chakravorty, S., Bush, J., and J. Bound, “IPv6 Label Switching Architecture,” July 2008.))

   +--------------------------+-------------+--------------------------+
   | FEC (First 3 Bits)       | Next 4 Bits | Purpose                  |
   +--------------------------+-------------+--------------------------+
   | No FEC (000)             | 0000        |                          |
   | Domain Specific (000)    | 0001 - 1111 |                          |
   | ------------------------ |             |                          |
   | VPN (001)                | 0001        | (IPSec - Tunnel Mode)    |
   |                          | 0010        | (IPSec - Transport Mode) |
   |                          | 0011        | (Special Encryption)     |
   |                          | 0100        | (VRF)                    |
   |                          | 0101        | (End Network Specific)   |
   |                          | 0110 - 1111 | (Reserved)               |
   | ------------------------ |             |                          |
   | TE Subset/               | 0001        | (DiffServ)               |
   | QoS Enhancement (010)    | 0010        | (RSVP)                   |
   . . .
   |                          | 1111        | (Reserved)               |
   | ------------------------ |             |                          |
   | Encapsulation (011)      | 0001        | (IPv6 in IPv6)           |
   |                          | 0010        | (IPv4 in IPv6)           |
   |                          | 0011        | (Other in IPv6)          |
   |                          | 0100        | (Enterprise Specific)    |
   |                          | 0101 - 1111 | (Reserved)               |
   | ------------------------ |             |                          |
   | Enterprise Specific(111) | 0000 - 1111 | (Reserved)               |
   +--------------------------+-------------+--------------------------+

The authors claim that fast switching using 20-bit labels instead of 128-bit IPv6 addresses will provide memory and processing savings, as well as network management advantages. "It also allows a network management entity updating available label tables, across the network to reduce man-in-the-middle attacks [sic]" [I‑D.chakravorty‑6lsa] (Chakravorty, S., Bush, J., and J. Bound, “IPv6 Label Switching Architecture,” July 2008.).

We note that a similar proposal for QoS-based switching of IPv6 packets [I‑D.roberts‑inband‑qos‑ipv6] (Roberts, L. and J. Harford, “In-Band QoS Signaling for IPv6,” July 2005.) is designed to use a hop-by-hop option, which has not so far been allocated by the IETF. Proposals related to this have been discussed by the Telecommunications Industry Association and the ITU-T [I‑D.adams‑tsvwg‑flow‑signalling‑codepoint] (song, j., Adams, J., and J. Joung, “Progress and future development of Flow State Aware standards, and a proposal for alerting nodes or end-systems on data related to a flow,” June 2008.).

3.4.  Diffserv use of IPv6 flow label

[I‑D.banerjee‑flowlabel‑ipv6‑qos] (Banerjee, R., “A Modified Specification for use of the IPv6 Flow Label for providing An efficient Quality of Service using hybrid approach,” April 2002.) uses the flow label field as a replacement for the IPv6 Traffic Class field; this proposal suggests the incoming flow label can indicate the QoS requirement by matching a Diffserv classifier. The authors have used the first three bits to indicate this, and the following 16 bits to indicate Differentiated Services Per-Hop Behavior Identification code (Diffserv PHB-ID) [RFC3140] (Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, “Per Hop Behavior Identification Codes,” June 2001.); the last bit is reserved for future use. This method too breaks the dependency prohibition in [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.).

[I‑D.martinbeckman‑ietf‑ipv6‑fls‑ipv6flowswitching] (Beckman, M., “IPv6 Dynamic Flow Label Switching (FLS),” March 2007.) blends the flow label as an MPLS-like switching tag with Diffserv. Unlike 6LSA, the method attempts to overcome the dependency prohibition by using one bit in 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.) to indicate that the flow label is a switching tag. In this way, a router can determine whether the flow label conforms to [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) or to [I‑D.martinbeckman‑ietf‑ipv6‑fls‑ipv6flowswitching] (Beckman, M., “IPv6 Dynamic Flow Label Switching (FLS),” March 2007.). In [I‑D.martinbeckman‑ietf‑ipv6‑amp‑ipv6hcamp] (Beckman, M., “IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP),” March 2007.), the same author proposes using the flow label as a way of compressing IPv6 headers by hashing the addresses into the flow label, again using the Diffserv Code Point to mark the packets accordingly.

3.5.  Other uses

We are not aware of any proposals combining the flow label with the other two Internet QoS architectures (Integrated Services [RFC1633] (Braden, B., Clark, D., and S. Shenker, “Integrated Services in the Internet Architecture: an Overview,” June 1994.) and Next Steps in Signaling (NSIS) [RFC4080] (Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, “Next Steps in Signaling (NSIS): Framework,” June 2005.)), except for generic recognition that the flow label can be inspected by a packet classifier.

[I‑D.donley‑softwire‑dslite‑flowlabel] (Donley, C. and K. Erichsen, “Using the Flow Label with Dual-Stack Lite,” July 2010.) proposes a use case whereby certain flows encapsulated in a particular type of IPv4-in-IPv6 tunnel would be distinguished at the remote end of the tunnel by a specific flow label value. This would allow a service provider to deliver a tailored quality of service. This usage appears to be completely compatible with [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.).

There has been some discussion of possible flow label use in both the ROLL (Routing Over Low power and Lossy networks) [I‑D.ietf‑roll‑rpl‑07] (Winter, T. and P. Thubert, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” March 2010.) and MEXT (Mobility EXTensions for IPv6) working groups of the IETF. Such uses tend to encode specific local meanings or routing-related tags in the label, so they appear to infringe the dependency prohibition or the immutability of the flow label field. The ROLL group has indeed most recently opted not to use the flow label field for these reasons, despite having to add the undesirable overhead of an IPv6 hop-by-hop option instead [I‑D.ietf‑roll‑rpl] (Winter, T., Thubert, P., and R. Team, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” July 2010.). Similarly, MEXT has defined a new mobility option to support flow bindings [I‑D.ietf‑mext‑flow‑binding] (Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, “Flow Bindings in Mobile IPv6 and NEMO Basic Support,” August 2010.). It can be argued that ideally, the IPv6 Flow Label field should serve both these purposes.

4.  Discussion

Firstly we notice that three aspects of the current standard [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) have caused problems to many designers:

1. The non-mutability of labels
2. "Nodes MUST NOT assume any mathematical or other properties of the Flow Label"
3. "Router performance SHOULD NOT be dependent on the distribution of the Flow Label values."

Taken together, these rules essentially forbid any encoding of the semantics of a flow, or of any information about its path, in the flow label. This was intentional, in accordance with the stateless nature of the Internet architecture and with the end-to-end principle [Saltzer] (Saltzer, J., Reed, D., and D. Clark, “End-To-End Arguments in System Design,” 1984.), [RFC3724] (Kempf, J., Austein, R., and IAB, “The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture,” March 2004.). It was also felt that QoS encoding via Diffserv was sufficient, and that the requirement for high-speed switching could be met by MPLS. But this means that the majority of the proposals described above breach the standard and the intent of the standard. The authors often appear to be using the flow label either as an MPLS-like switching handle, or as an encoded QoS signal. In fact, we consider that only [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.), [I‑D.donley‑softwire‑dslite‑flowlabel] (Donley, C. and K. Erichsen, “Using the Flow Label with Dual-Stack Lite,” July 2010.) (and possibly [I‑D.martinbeckman‑ietf‑ipv6‑fls‑ipv6flowswitching] (Beckman, M., “IPv6 Dynamic Flow Label Switching (FLS),” March 2007.) and [I‑D.martinbeckman‑ietf‑ipv6‑amp‑ipv6hcamp] (Beckman, M., “IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP),” March 2007.)) strictly respect the intention of the standard. [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.) is also intended to conform to the standard.

What would designers need to do, if they wish to respect the standard? There appear to be two choices. One is to simply accept the above rules at face value, which as noted appears to be the case in few proposals. This limits the application of the flow label. It can be used as a nonce as 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.) or as part of the material for a hash used to share load among alternate paths. It cannot be the only material for such a hash, because of the dependency prohibition. The flow label could also be used consistently with [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.), if an application designer so chose, as a way to associate all packets belonging to a given application session between two hosts, across multiple transport sessions. This, however, would presumably exclude using the flow label to govern routing decisions in any way, and would have widespread implications that have never been explored.

The other choice, for designers who wish to use the flow label to control switching or QoS directly, is to bypass the rules within a given domain (a set of cooperating nodes) in a way that nodes outside the domain cannot detect. In this case, any deviation from [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.) has no possible effect outside the domain in question.

For example, to emulate the non-mutability of labels, we could arrange that within the domain all hosts set the label to zero, the routers set and interpret the label in any way they wish, and the last hop router always sets the label back to zero. If a packet arrives from outside the domain with a non-zero label, there would need to be a method (such as a special Diffserv code point) to mark this packet so that its label would be ignored and delivered unchanged. An alternative approach would be to standardize a hop-by-hop option to carry the original flow label across the domain, so that it could be changed within the domain but restored before forwarding the packet beyond the domain.

Once we have bypassed non-mutability, we can safely bypass the dependency prohibition for labels within the domain, because it is now possible to ensure that the bits in the label are set according to defined rules. Within the domain, we can treat the label as an expanded Diffserv field, or a 6LSA label, or a random value, etc. In fact most of the proposed designs discussed above could be "rescued."

Given the considerable number of designers who have proposed such solutions, and the almost complete lack of designs using the standard rules [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.), it seems reasonable to ask whether the current standard has value.

5.  Conclusion

As real time traffic increases, the delay and packet loss problem for real time streams has become too serious to be neglected, and many researchers have claimed that the flow label field in the IPv6 header would be a possible solution. Various proposals assert that the flow label field will improve QoS. However, we find that such proposals breach the current IETF standard for use of the flow label. More work is required to find a new structure which will respect the standard and also provide an effective way to use the flow label. If this cannot be achieved, this aspect of the IPv6 standard may need to be revised.

6.  Security Considerations

The flow label is not protected in any way and can be forged by an on-path attacker. Off-path attackers may be able to guess a valid flow label unless a pseudo-random value is used. Specific usage models for the flow label need to allow for these exposures. For further discussion, see [RFC3697] (Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, “IPv6 Flow Label Specification,” March 2004.).

7.  IANA Considerations

This document requests no action by IANA.

8.  Acknowledgements

An invaluable review of this document was performed by Bob Braden. Helpful comments were made by Sheng Jiang.

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

9.  Change log

draft-hu-flow-label-cases-00: first I-D version, 2010-04-19

draft-hu-flow-label-cases-01: updated following review comments, 2010-08-18

10. Informative References

Authors' Addresses