[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 6294

Independent Submission                                             Q. Hu
Internet-Draft                                              B. Carpenter
Intended status: Informational                         Univ. of Auckland
Expires: February 19, 2011                               August 18, 2010

          Survey of proposed use cases for the IPv6 flow label


   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

Hu & Carpenter          Expires February 19, 2011               [Page 1]

Internet-Draft            Flow label use cases               August 2010

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Flow label definition and issues . . . . . . . . . . . . . . .  4
     2.1.  Flow label properties  . . . . . . . . . . . . . . . . . .  4
     2.2.  Dependency prohibition . . . . . . . . . . . . . . . . . .  5
     2.3.  Other issues . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Documented proposals for the flow label  . . . . . . . . . . .  6
     3.1.  Specify the flow label as a pseudo-random value  . . . . .  7
     3.2.  Specify QoS parameters in the flow label . . . . . . . . .  8
     3.3.  Use flow label to control switching  . . . . . . . . . . .  9
     3.4.  Diffserv use of IPv6 flow label  . . . . . . . . . . . . . 10
     3.5.  Other uses . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   9.  Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   10. Informative References . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17

Hu & Carpenter          Expires February 19, 2011               [Page 2]

Internet-Draft            Flow label use cases               August 2010

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], and general rules governing its use were
   defined in 2004 [RFC3697], 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].  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].  In particular, the IETF
   rejected a proposal known as CATNIP [RFC1707], 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].
   In 1994, this was a 28-bit flow label field.  In 1995 it was down to
   24 bits [RFC1883] and it was finally reduced to 20 bits [RFC2460] 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

Hu & Carpenter          Expires February 19, 2011               [Page 3]

Internet-Draft            Flow label use cases               August 2010

   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] defined it
   as "experimental and subject to change."  After preliminary work such
   as [I-D.metzler-ipv6-flowlabel], [I-D.conta-ipv6-flow-label],
   [I-D.conta-diffserv-ipv6-fl-classifier] and
   [I-D.itojun-ipv6-flowlabel-api], the standard [RFC3697] 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] standardizes properties of the flow label,
   o  If the packets are not part of any flow, the flow label value is
   o  The 3-tuple {source address, destination address, flow label}
      uniquely identifies which packets belong to which particular flow.
   o  Packets can receive flow-specific treatment if the node has been
      set up with flow-specific state.
   o  The flow label set by the source node must be delivered to the
      destination node.
   o  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.  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

Hu & Carpenter          Expires February 19, 2011               [Page 4]

Internet-Draft            Flow label use cases               August 2010

   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], [RFC2474] but need not be less efficient.

2.2.  Dependency prohibition

   An additional important rule in the standard [RFC3697] 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]
   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] proposed that when a router receives a
   datagram with an unknown flow label, it should treat it as zero.

Hu & Carpenter          Expires February 19, 2011               [Page 5]

Internet-Draft            Flow label use cases               August 2010

   However, the standard [RFC3697] 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] 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] 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] 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.

Hu & Carpenter          Expires February 19, 2011               [Page 6]

Internet-Draft            Flow label use cases               August 2010

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

   For example, [LinTseng] 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
   o  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], since a source that does not use this
      method may also set the LF bit.
   o  The Label type (LT): 2 bits which describe the type of packet.
   o  The Label Number (LN): which is randomly generated by the source

   [LinTseng] 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])

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

Hu & Carpenter          Expires February 19, 2011               [Page 7]

Internet-Draft            Flow label use cases               August 2010

   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

3.2.  Specify QoS parameters in the flow label

   [Prakash] 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], 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])

     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] 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] claims that "this
   proposal is simple, scalable, modular and generic implementation to
   provide for QoS using the IPv6 flow label field".

   Similarly, [LeeKim] 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] is broken.  This proposal also includes

Hu & Carpenter          Expires February 19, 2011               [Page 8]

Internet-Draft            Flow label use cases               August 2010

   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] and [Chakravorty] 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].  The authors of [I-D.chakravorty-6lsa] 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])

Hu & Carpenter          Expires February 19, 2011               [Page 9]

Internet-Draft            Flow label use cases               August 2010

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

   We note that a similar proposal for QoS-based switching of IPv6
   packets [I-D.roberts-inband-qos-ipv6] 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

3.4.  Diffserv use of IPv6 flow label

   [I-D.banerjee-flowlabel-ipv6-qos] 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)

Hu & Carpenter          Expires February 19, 2011              [Page 10]

Internet-Draft            Flow label use cases               August 2010

   [RFC3140]; the last bit is reserved for future use.  This method too
   breaks the dependency prohibition in [RFC3697].

   [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] 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] to indicate that the flow
   label is a switching tag.  In this way, a router can determine
   whether the flow label conforms to [RFC3697] or to
   [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching].  In
   [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp], 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]
   and Next Steps in Signaling (NSIS) [RFC4080]), except for generic
   recognition that the flow label can be inspected by a packet

   [I-D.donley-softwire-dslite-flowlabel] 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].

   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] 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].  Similarly, MEXT has defined a new mobility
   option to support flow bindings [I-D.ietf-mext-flow-binding].  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

Hu & Carpenter          Expires February 19, 2011              [Page 11]

Internet-Draft            Flow label use cases               August 2010

   [RFC3697] 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], [RFC3724].  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],
   [I-D.donley-softwire-dslite-flowlabel] (and possibly
   [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] and
   [I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp]) strictly respect the
   intention of the standard.  [I-D.carpenter-flow-ecmp] 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] 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], 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]
   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

Hu & Carpenter          Expires February 19, 2011              [Page 12]

Internet-Draft            Flow label use cases               August 2010

   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], 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].

7.  IANA Considerations

   This document requests no action by IANA.

Hu & Carpenter          Expires February 19, 2011              [Page 13]

Internet-Draft            Flow label use cases               August 2010

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

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,

10.  Informative References

              Carpenter, B. and K. Nichols, "Differentiated Services in
              the Internet", Proc IEEE 90 (9) 1479-1494, 2002.

              Chakravorty, S., "Challenges of IPv6 Flow Label
              implementation", Proc IEEE MILCOM2008 , 2008.

   [Deering]  Deering, S., "SIPP Overview and Issues", Minutes of the
              Joint Sessions of the SIP and PIP Working Groups ,
              November 1993.

              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", draft-adams-tsvwg-flow-signalling-codepoint-00
              (work in progress), June 2008.

              Banerjee, R., "A Modified Specification for use of the
              IPv6 Flow Label for providing An  efficient Quality of
              Service using hybrid approach",
              draft-banerjee-flowlabel-ipv6-qos-03 (work in progress),
              April 2002.

              Blake, S., "Use of the IPv6 Flow Label as a Transport-
              Layer Nonce to Defend Against Off-Path Spoofing Attacks",
              draft-blake-ipv6-flow-label-nonce-02 (work in progress),

Hu & Carpenter          Expires February 19, 2011              [Page 14]

Internet-Draft            Flow label use cases               August 2010

              October 2009.

              Carpenter, B. and S. Amante, "Using the IPv6 flow label
              for equal cost multipath routing and link aggregation in
              tunnels", draft-carpenter-flow-ecmp-02 (work in progress),
              April 2010.

              Chakravorty, S., Bush, J., and J. Bound, "IPv6 Label
              Switching Architecture", draft-chakravorty-6lsa-03 (work
              in progress), July 2008.

              Conta, A. and J. Rajahalme, "Amodel for Diffserv use of
              the IPv6 Flow Label Specification",
              draft-conta-diffserv-ipv6-fl-classifier-01 (work in
              progress), November 2001.

              Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow
              Label Specification", draft-conta-ipv6-flow-label-02 (work
              in progress), July 2001.

              Donley, C. and K. Erichsen, "Using the Flow Label with
              Dual-Stack Lite",
              draft-donley-softwire-dslite-flowlabel-00 (work in
              progress), July 2010.

              Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
              Basic Support", draft-ietf-mext-flow-binding-09 (work in
              progress), August 2010.

              Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
              Protocol for Low power and Lossy Networks",
              draft-ietf-roll-rpl-11 (work in progress), July 2010.

              Winter, T. and P. Thubert, "RPL: IPv6 Routing Protocol for
              Low power and Lossy Networks",
              draft-ietf-roll-rpl-07 (work in progress), March 2010.

              Hagino, J., "Socket API for IPv6 flow label field",

Hu & Carpenter          Expires February 19, 2011              [Page 15]

Internet-Draft            Flow label use cases               August 2010

              draft-itojun-ipv6-flowlabel-api-01 (work in progress),
              April 2001.

              Beckman, M., "IPv6 Header Compression via Addressing
              Mitigation Protocol (IPv6 AMP)",
              draft-martinbeckman-ietf-ipv6-amp-ipv6hcamp-01 (work in
              progress), March 2007.

              Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)",
              (work in progress), March 2007.

              Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6
              flow label", draft-metzler-ipv6-flowlabel-00 (work in
              progress), November 2000.

              Roberts, L. and J. Harford, "In-Band QoS Signaling for
              IPv6", draft-roberts-inband-qos-ipv6-00 (work in
              progress), July 2005.

   [LeeKim]   Lee, I. and S. Kim, "A QoS Improvement Scheme for Real-
              Time Traffic Using IPv6 Flow Labels", Lecture Notes in
              Computer Science Vol. 3043, 2004.

              Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS
              Provisioning by Flow Label in IPv6", JCIS , 2006.

   [Prakash]  Prakash, B., "Using the 20 bit flow label field in the
              IPv6 header to indicate desirable quality of service on
              the internet", University of Colorado (M.Sc. Thesis),

   [RFC1633]  Braden, B., Clark, D., and S. Shenker, "Integrated
              Services in the Internet Architecture: an Overview",
              RFC 1633, June 1994.

   [RFC1707]  McGovern, M. and R. Ullmann, "CATNIP: Common Architecture
              for the Internet", RFC 1707, October 1994.

   [RFC1710]  Hinden, R., "Simple Internet Protocol Plus White Paper",
              RFC 1710, October 1994.

   [RFC1752]  Bradner, S. and A. Mankin, "The Recommendation for the IP

Hu & Carpenter          Expires February 19, 2011              [Page 16]

Internet-Draft            Flow label use cases               August 2010

              Next Generation Protocol", RFC 1752, January 1995.

   [RFC1809]  Partridge, C., "Using the Flow Label Field in IPv6",
              RFC 1809, June 1995.

   [RFC1883]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883, December 1995.

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

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

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3140]  Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
              "Per Hop Behavior Identification Codes", RFC 3140,
              June 2001.

   [RFC3697]  Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
              "IPv6 Flow Label Specification", RFC 3697, March 2004.

   [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", RFC 3724, March 2004.

   [RFC4080]  Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
              Bosch, "Next Steps in Signaling (NSIS): Framework",
              RFC 4080, June 2005.

   [Saltzer]  Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments
              in System Design", ACM TOCS 2 (4) 277-288, 1984.

Hu & Carpenter          Expires February 19, 2011              [Page 17]

Internet-Draft            Flow label use cases               August 2010

Authors' Addresses

   Qinwen Hu
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland,   1142
   New Zealand

   Email: qhu009@aucklanduni.ac.nz

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland,   1142
   New Zealand

   Email: brian.e.carpenter@gmail.com

Hu & Carpenter          Expires February 19, 2011              [Page 18]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/