GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6294

Independent Submission Q. Hu Request for Comments: 6294 B. Carpenter Category: Informational Univ. of Auckland ISSN: 2070-1721 June 2011

        Survey of Proposed Use Cases for the IPv6 Flow Label

Abstract

 The IPv6 protocol includes a flow label in every packet header, but
 this field 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 document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6294.

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.

Hu & Carpenter Informational [Page 1] RFC 6294 Flow Label Use Cases June 2011

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   1.1.  A Brief History of the Flow Label  . . . . . . . . . . . .  2
   1.2.  The Flow Label and Quality of Service  . . . . . . . . . .  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.1.1.  End-to-End QoS Provisioning  . . . . . . . . . . . . .  7
     3.1.2.  Load-Balancing . . . . . . . . . . . . . . . . . . . .  8
     3.1.3.  Security Nonce . . . . . . . . . . . . . . . . . . . .  8
   3.2.  Specify QoS Parameters in the Flow Label . . . . . . . . .  8
   3.3.  Use Flow Label Hop-by-Hop to Control Switching . . . . . .  9
   3.4.  Diffserv Use of IPv6 Flow Label  . . . . . . . . . . . . . 12
   3.5.  Other Uses . . . . . . . . . . . . . . . . . . . . . . . . 12
 4.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
 5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
 6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
 7.  Informative References . . . . . . . . . . . . . . . . . . . . 14

1. Introduction

 IPv6 is being introduced to overcome the address shortage of the
 current IPv4 protocol, but it also offers a new feature, 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.  However, it is
 used very little in practice, for reasons discussed below and in
 [Amante11].  After a short introduction, this document summarizes the
 current specification of the IPv6 flow label and some open issues
 about its use in Section 2.  Section 3 describes and analyzes various
 proposals that have been made for its use.  Finally, Section 4
 discusses the implications and attempts to draw conclusions.
 The Flow Label field occupies bits 12 through 31 of the IPv6 packet
 header.  It provides a potential way to mark a packet, identify a
 flow, and look up the corresponding flow state.  This field is always
 present in an IPv6 header, 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.

1.1. A Brief History of the Flow Label

 The original proposal for a flow label has been attributed to Dave
 Clark [Deering93], who proposed that it should contain a pseudo-
 random value.  A Flow Label field was included in the packet header

Hu & Carpenter Informational [Page 2] RFC 6294 Flow Label Use Cases June 2011

 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 the Common Architecture for Next Generation
 Internet Protocol (CATNIP) [RFC1707], which included so-called 'cache
 handles' to identify the next hop in high-performance routers.  Thus,
 CATNIP introduced the notion of a header field that would be shared
 by all packets belonging to a flow, to control packet forwarding on a
 hop-by-hop basis.  We recognize this today as a precursor of the MPLS
 label [RFC3031].
 The IETF decided instead to develop a proposal known as the Simple
 Internet Protocol plus (SIPP) [RFC1710] 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
 used 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
 CATNIP, or was it to be meaningful to applications and used to
 specify 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".  There was considerable
 preliminary work, such as [Metzler00], [Conta01a], [Conta01b], and
 [Hagino01].  The ensuing proposed standard "IPv6 Flow Label
 Specification" (RFC 3697) [RFC3697] intended to clarify this
 situation by providing precise boundary conditions for use of the
 flow label.  However, this has not proved successful in promoting use
 of the flow label in practice, as a result of which 20 bits are
 unused in every IPv6 packet header.

1.2. The Flow Label and Quality of Service

 Developments in high-speed switch design, and the success of MPLS,
 have largely obviated consideration of the flow label for high-speed
 switching.  Thus, although various use cases for the flow label have
 been proposed, most of them assume that it should be used principally
 to support the provision of quality of service (QoS).  For many
 years, it has been recognized that real-time Internet traffic

Hu & Carpenter Informational [Page 3] RFC 6294 Flow Label Use Cases June 2011

 requires a different QoS 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.  The flow label, being exempt from IPsec encryption and
 being replicated in packet fragments, avoids this difficulty.  It has
 therefore attracted attention from the designers of new approaches to
 QoS.

2. Flow Label Definition and Issues

2.1. Flow Label Properties

 RFC 3697 [RFC3697] standardizes properties of the flow label,
 including the following:
 o  If the packets are not part of any flow, the flow label value is
    zero.
 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; i.e., it is an end-to-end label.
 o  The same pair of source and destination addresses must not use the
    same flow label value again within a timeout of at least
    120 seconds.
 One effect of the second 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.  This may reduce the lookup time if
 flow-based treatment is required and will work 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 forwarding or receiving the packets may provide

Hu & Carpenter Informational [Page 4] RFC 6294 Flow Label Use Cases June 2011

 different flow-specific treatments by looking at the flow label
 value.  This is more fine-grained than differentiated services
 (Diffserv) [Carpenter02] [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".  This rule is aimed at the case where a packet from a
 source using a particular encoding scheme for the flow label reaches
 a node that is using a different scheme.  If, by chance, the bit
 pattern in the flow label is meaningful in both schemes, the receiver
 would misinterpret the flow label.  Therefore, in the absence of
 other information, the receiver must not assume anything about the
 meaning of the value of the flow label.
 The standard [RFC3697] also states that "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 one method of choosing flow labels (e.g., counting up from 1),
 any router that assumes another method (e.g., pseudo-randomness) may
 not perform as intended.
 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 way for a router to determine which
 sources use the same scheme as itself.
 The interpretation of the dependency rule can be subtle and is not
 spelled out in [RFC3697].  A node must not assume properties of the
 flow label -- but it may know them by construction or by signaling.
 The bits of the flow label alone are poor material for a hash key --
 but they may be combined with bits from other sources, to provide
 uniformly distributed hash outputs.

2.3. Other Issues

 [RFC3697] does not discuss how to use the flow label most
 effectively.  This remains the major open issue, but some authors
 propose that the label should be used with reserved bandwidth to

Hu & Carpenter Informational [Page 5] RFC 6294 Flow Label Use Cases June 2011

 achieve customized QoS provision.  Coupled with admission control at
 the edge router, this could limit congestion.  However, as we will
 see below, this is not the only proposed use.
 We now introduce some other open issues.
 o  Unknown flow labels: [RFC1809] proposed that when a router
    receives a datagram with an unknown flow label, it should treat it
    as zero.  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.
 o  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
    signaling?  [RFC3697] defines a timeout (120 seconds) that
    effectively imposes a maximum lifetime on flow label state in a
    router.  This implies that flow labeling is inappropriate for very
    intermittent flows, unless there is some mechanism to refresh
    router state.  In contrast, [Banerjee02] suggested that a router
    should send an ICMP message to the source prior to deleting a
    particular label.  The source node may then send a KEEPALIVE
    message to the router; if it does not, the router will release
    that label.
 o  Choosing when to set the flow label: For what kinds of
    applications 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.
 o  Can we modify the flow label?  [RFC3697] states that the flow
    label must be delivered unchanged.  There are several advantages
    of immutable flow labels, apart from respecting the standard: the
    rule is easy to understand, does not require extra processing in
    routers or a signaling 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 of the proposed mechanisms described below
    contradict this by suggesting that switches should change the flow
    label for routing purposes.

3. Documented Proposals for the Flow Label

 In the following, we do not intend to recommend or criticize various
 proposals.  This section shows the variety of proposals that have
 been published, and whether they are compatible with the existing
 standard.  These proposals almost all assume that the flow label's

Hu & Carpenter Informational [Page 6] RFC 6294 Flow Label Use Cases June 2011

 main purpose is to support QoS, and their flow label mechanisms are
 entangled with QoS mechanisms.  We describe the proposals in five
 broad, and somewhat overlapping, categories, i.e.,
 1.  using pseudo-random flow label values for various purposes (for
     example, to improve routing performance when retrieving cached
     routing state);
 2.  defining specific QoS requirements as parameters embedded in the
     flow label field;
 3.  using the flow label to control packet switching;
 4.  using the flow label specifically to extend the existing
     differentiated services QoS architecture;
 5.  other uses.
 Among the proposals described in the following five sections, various
 methods are proposed to set up the flow label value.  It should be
 noted that some of these proposals embody novel and perhaps
 controversial approaches to QoS provision, and these cannot readily
 be separated from their use of the flow label.  We give a reasonable
 amount of technical detail for some of the proposals, to show the
 extent to which they propose detailed semantics for the flow label
 value.

3.1. Specify the Flow Label as a Pseudo-Random Value

3.1.1. End-to-End QoS Provisioning

 As our first example, [Lin06] specifies a 17-bit pseudo-random value.
 The figure below shows the proposed flow label structure.
 o  The Label Flag (LF) bit: 1 means this type of flow label is
    present.  We note that this encoding is incompatible with 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; describes the type of packet.
 o  The Label Number (LN): randomly generated by the source node.
 [Lin06] also describes a signaling 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.

Hu & Carpenter Informational [Page 7] RFC 6294 Flow Label Use Cases June 2011

 Flow Label Specification (figure simplified from [Lin06])
       +--+----+-----------------------------+
       | 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

3.1.2. Load-Balancing

 There have been numerous informal discussions of using pseudo-random
 flow labels to allow load-balancing or at least load-sharing.  This
 would be achieved by including the flow label value among the fields
 in each packet header used as input to a modulo(N) hash used to
 select among N alternative paths.  However, concerns about the
 interpretation of the dependency prohibition have generally prevented
 such proposals from being written up until recently [Carpenter11].

3.1.3. Security Nonce

 Another proposal for a pseudo-random flow label value is [Blake09].
 This 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.  This
 proposal does not involve using the flow label value to retrieve
 routing state.

3.2. Specify QoS Parameters in the Flow Label

 [Prakash04] 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 the following table.  Again, this is incompatible with the
 dependency prohibition in [RFC3697], since a source that does not use
 this method may also set the first two bits to non-zero.

Hu & Carpenter Informational [Page 8] RFC 6294 Flow Label Use Cases June 2011

 Classification for various approaches (from [Prakash04])
  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 allows 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 the Resource Reservation Protocol (RSVP)
 [RFC2205] mechanisms are used to actually implement these QoS
 parameters.
 This proposal allows the use of the flow label for various important
 QoS models, so the end user and service provider can choose the most
 suitable model for their situation; [Prakash04] claims that "The
 proposed approach results in a simple, scalable, modular and generic
 implementation to provide for QoS using the IPv6 flow label field".
 Similarly, [Lee04] defines the Flow Label field in five parts, with
 the first 3 bits used as an approach type.  The authors define 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 a 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 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.

3.3. Use Flow Label Hop-by-Hop to Control Switching

 [Chakravorty08b] and [Chakravorty08a] 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

Hu & Carpenter Informational [Page 9] RFC 6294 Flow Label Use Cases June 2011

 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 [Chakravorty08b] 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 incompatibility 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, this solution divides 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 forward 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.

Hu & Carpenter Informational [Page 10] RFC 6294 Flow Label Use Cases June 2011

 Flow Label Specification (shortened from [Chakravorty08b])
 +--------------------------+-------------+--------------------------+
 | 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]" [Chakravorty08b].
 We note that a similar proposal for QoS-based switching of IPv6
 packets [Roberts05] 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 [Adams08].
 We also note that router lookup efficiency was a major concern at the
 time when Clark first proposed a flow label [Deering93], but with the
 advent of very large scale integrated circuits capable of rapid
 lookup in a routing table, most vendors no longer express such
 concern.

Hu & Carpenter Informational [Page 11] RFC 6294 Flow Label Use Cases June 2011

3.4. Diffserv Use of IPv6 Flow Label

 [Banerjee02] 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 a Differentiated Services Per-Hop
 Behavior Identification code (Diffserv PHB-ID) [RFC3140]; the last
 bit is reserved for future use.  This method too breaks the
 dependency prohibition in [RFC3697].
 [Beckman07a] blends the flow label as an MPLS-like switching tag with
 Diffserv.  Unlike 6LSA, the method attempts to bypass 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 [Beckman07a].  In [Beckman07b], 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

 The Integrated Services QoS architecture [RFC1633] specifies that the
 flow label may be used as a packet filter [RFC2205].  At least one
 implementation supported this [Braden10].
 We are not aware of any proposals combining the flow label with the
 Next Steps in Signaling (NSIS) [RFC4080] architecture.
 [Donley11] 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) [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 [RPL].  Similarly, MEXT has defined a new mobility
 option to support flow bindings [RFC6089] rather than using the IPv6
 Flow Label field.

Hu & Carpenter Informational [Page 12] RFC 6294 Flow Label Use Cases June 2011

4. Conclusion

 Three aspects of the current standard [RFC3697] have caused problems
 for many designers:
 1.  The immutability 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
 [Saltzer84], [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 contrast, a few documents mentioned above do appear to respect the
 rules of RFC 3697.  These are [Blake09], [Donley11], [Carpenter11],
 [Beckman07a], and [Beckman07b].  Additionally, [Lin06] would have
 joined this list if it had not assigned three flag bits in the Flow
 Label field.  Although predating RFC 3697, the Integrated Services
 usage [RFC2205] also seems to be compatible.
 What would other designers need to do, if they wish to respect
 RFC 3697?  There appear to be two choices.  One is to simply accept
 the existing rules at face value, as in the proposals just listed.
 This limits the application of the flow label.  It can, for example,
 be used as a 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 RFC 3697, 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

Hu & Carpenter Informational [Page 13] RFC 6294 Flow Label Use Cases June 2011

 the domain cannot detect.  In this case, any deviation from RFC 3697
 has no possible effect outside the domain in question.
 An example scheme to emulate the immutability of labels is as
 follows.  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 is 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 define 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.
 If a domain allows mutable labels in such a way, it may safely ignore
 the dependency prohibition, and it may set the bits in the label
 according to locally defined rules.  Within the domain, the label
 could be used as desired, and most of the proposed designs discussed
 above could be "rescued".
 However, given the considerable number of designers who have proposed
 solutions incompatible with RFC 3697, the relatively few designs
 using the standard rules, and the failure of designs such as ROLL and
 MEXT to make use of the flow label, it seems reasonable to ask
 whether the RFC 3697 standard has value.

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

6. Acknowledgements

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

7. Informative References

 [Adams08]  Adams, J., Joung, J., and J. Song, "Progress and future
            development of Flow State Aware standards, and a proposal
            for alerting nodes or end-systems on data related to a
            flow", Work in Progress, June 2008.

Hu & Carpenter Informational [Page 14] RFC 6294 Flow Label Use Cases June 2011

 [Amante11] Amante, S., Carpenter, B., and S. Jiang, "Rationale for
            update to the IPv6 flow label specification", Work
            in Progress, May 2011.
 [Banerjee02]
            Banerjee, R., Malhotra, S., and M. M, "A Modified
            Specification for use of the IPv6 Flow Label for providing
            An efficient Quality of Service using a hybrid approach",
            Work in Progress, April 2002.
 [Beckman07a]
            Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)",
            Work in Progress, February 2007.
 [Beckman07b]
            Beckman, M., "IPv6 Header Compression via Addressing
            Mitigation Protocol (IPv6 AMP)", Work in Progress,
            November 2006.
 [Blake09]  Blake, S., "Use of the IPv6 Flow Label as a Transport-
            Layer Nonce to Defend Against Off-Path Spoofing Attacks",
            Work in Progress, October 2009.
 [Braden10] Braden, R., "Private Communication", 2010.
 [Carpenter02]
            Carpenter, B. and K. Nichols, "Differentiated Services in
            the Internet", Proc IEEE 90 (9) 1479-1494, 2002.
 [Carpenter11]
            Carpenter, B. and S. Amante, "Using the IPv6 flow label
            for equal cost multipath routing and link aggregation in
            tunnels", Work in Progress, May 2011.
 [Chakravorty08a]
            Chakravorty, S., "Challenges of IPv6 Flow Label
            implementation", Proc IEEE MILCOM2008, 2008.
 [Chakravorty08b]
            Chakravorty, S., Bush, J., and J. Bound, "IPv6 Label
            Switching Architecture", Work in Progress, July 2008.
 [Conta01a] Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow
            Label Specification", Work in Progress, July 2001.

Hu & Carpenter Informational [Page 15] RFC 6294 Flow Label Use Cases June 2011

 [Conta01b] Conta, A. and J. Rajahalme, "A model for Diffserv use of
            the IPv6 Flow Label Specification", Work in Progress,
            November 2001.
 [Deering93]
            Deering, S., "SIPP Overview and Issues", Minutes of the
            Joint Sessions of the SIP and PIP Working Groups,
            November 1993.
 [Donley11] Donley, C. and K. Erichsen, "Using the Flow Label with
            Dual-Stack Lite", Work in Progress, January 2011.
 [Hagino01] Hagino, J., "Socket API for IPv6 flow label field", Work
            in Progress, April 2001.
 [Lee04]    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.
 [Lin06]    Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS
            Provisioning by Flow Label in IPv6", JCIS , 2006.
 [Metzler00]
            Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6
            flow label", Work in Progress, November 2000.
 [Prakash04]
            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),
            2004.
 [RFC1633]  Braden, R., 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
            Next Generation Protocol", RFC 1752, January 1995.

Hu & Carpenter Informational [Page 16] RFC 6294 Flow Label Use Cases June 2011

 [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, R., Ed., 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.
 [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC 3031, January 2001.
 [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., Ed., Austein, R., Ed., 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.
 [RFC6089]  Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
            and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
            Network Mobility (NEMO) Basic Support", RFC 6089,
            January 2011.
 [RPL]      Winter, T., Ed., Thubert, P., Ed., Brandt, A., Clausen,
            T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik,
            R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low
            power and Lossy Networks", Work in Progress, March 2011.

Hu & Carpenter Informational [Page 17] RFC 6294 Flow Label Use Cases June 2011

 [RPL-07]   Winter, T., Ed. and P. Thubert, Ed., "RPL: IPv6 Routing
            Protocol for Low power and Lossy Networks", Work
            in Progress, March 2010.
 [Roberts05]
            Roberts, L. and J. Harford, "In-Band QoS Signaling for
            IPv6", Work in Progress, July 2005.
 [Saltzer84]
            Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments
            in System Design", ACM TOCS 2 (4) 277-288, 1984.

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 Informational [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6294.txt · Last modified: 2011/06/28 22:08 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki