6MAN                                                           S. Amante
Internet-Draft                                                   Level 3
Intended status: Informational                              B. Carpenter
Expires: June 6, July 14, 2011                                 Univ. of Auckland
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                        December 3, 2010
                                                        January 10, 2011

              Update to the IPv6 flow label specification


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

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 June 6, July 14, 2011.

Copyright Notice

   Copyright (c) 2010 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Impact of current specification  . . . . . . . . . . . . . . .  4
   3.  Normative Notation . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Proposed changes to specification  . . . . . . . . . . . . . .  6
   5.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  8  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 10 11
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 11
   Appendix A.  Alternative Approaches  . . . . . . . . . . . . . . . 11 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12

1.  Introduction

   The flow label field in the IPv6 header was reserved but left
   experimental by [RFC2460], which mandates only that "Hosts or routers
   that do not support the functions of the Flow Label field are
   required to set the field to zero when originating a packet, pass the
   field on unchanged when forwarding a packet, and ignore the field
   when receiving a packet."

   The flow label field was normatively specified by [RFC3697].  In
   particular, we quote three rules from that RFC:
   a.  "The Flow Label value set by the source MUST be delivered
       unchanged to the destination node(s)."
   b.  "IPv6 nodes MUST NOT assume any mathematical or other properties
       of the Flow Label values assigned by source nodes."
   c.  "Router performance SHOULD NOT be dependent on the distribution
       of the Flow Label values.  Especially, the Flow Label bits alone
       make poor material for a hash key."

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

   RFC 2460 mandates only that "Hosts or routers that do not support the
   functions of the Flow Label field are required to set the field to
   zero when originating a packet, pass the field on unchanged when
   forwarding a packet, and ignore the field when receiving a packet."

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

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

2.  Impact of current specification

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

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

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

   Both before and after these rules were laid down, a considerable
   number of proposals for use of the flow label were published that
   seem incompatible with them.  Numerous examples and an analysis are
   presented in [I-D.hu-flow-label-cases].  Those examples propose use
   cases in which some or all of the following apply:
   o  The flow label may be changed by intermediate systems.
   o  It doesn't matter if the flow label is changed, because the
      receiver doesn't use it.
   o  Some or all bits of the flow label are encoded: they have specific
      meanings understood by routers and switches along the path.
   o  The encoding is related to the required quality of service, as
      well as identifying a flow.
   o  The flow label is used to control forwarding or switching in some

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

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

   If our goal is for the flow label to be used in practice, the
   conflict between the various approaches creates a dilemma.  There
   appear to be two major options:
   1.  Discourage locally defined use of the flow label.  Strengthen RFC
       3697 to say that hosts SHOULD set a pseudo-random label value,
       which would clarify and limit its possible uses.  In particular,
       its use for load balancing would be encouraged.
   2.  Relax the rules to encourage locally defined use of the flow
       label.  This approach would make the flow label completely
       mutable and would exclude use cases depending on strict end-to-
       end immutability.  It would encourage applications of a pseudo-
       random flow label, such as load balancing, on a local basis, but
       it would exclude end-to-end applications.

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

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

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

3.  Normative Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

4.  Proposed changes to specification

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

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

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

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

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

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

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

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

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

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

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

   3.  A forwarding node MUST NOT change the flow label value in an
       arriving packet if it is non-zero.  However, there are two
       qualifications to this rule:
       1.  Implementers are advised that forwarding nodes, especially
           those acting as domain border devices, might nevertheless be
           configured to change the flow label value in packets (e.g.,
           to a new pseudo-random value).  This is undetectable, unless
           some future version of IPsec authentication [RFC4302]
           protects the flow label value.

       2.  A  To enable stateless load balancing at any point in the
           Internet, a network domain MUST NOT forward packets outside
           the domain whose flow label values are other than zero or
           pseudo-random.  Neither domain border egress routers nor
           intermediate routers/devices (using a flow-label, for
           example, as a part of an input-key for a load-balancing hash)
           can determine by inspection that a value is not pseudo-random.  Thus, pseudo-
           random.  Therefore, if nodes within a domain ignore the above
           recommendations to set zero or pseudo-random flow label
           values, then and such packets are forwarded outside the domain,
           this would likely result in undesirable operational
           implications (e.g., congestion, reordering) for not only the
           inappropriately flow-labelled packets, but also well-behaved
           flow-labelled packets, during forwarding at various
           intermediate devices.  Thus, a domain must protect its peers
           by never exporting inappropriately labelled packets.  This
           document does not specify the method for enforcing this rule.
           The suggested way to enforce it is that nodes within a domain
           MUST NOT set the flow label to a non-zero and non-pseudo-
           random number if the packet will leave the domain.  If this
           is not known to be the case, the border router will need to
           change outgoing flow labels.

       Note that the new rules above, taken together, allow a given
       network domain to include routers that set flow labels on behalf
       of hosts that do not do so.  They also require that flow labels
       exported to the Internet must always be either zero or pseudo-
       random.  These changes replace rule (a) quoted in Section 1.
       However, there is no way to verify whether a flow label has been
       modified en route.  No Internet-wide mechanism can depend
       mathematically on immutable flow labels.  This leads to the
       following formal rule:

   4.  IPv6 nodes MUST NOT assume that the Flow Label value in a
       incoming packet is identical to the value set by the source node.
       *  This replaces rule (b) quoted in Section 1.

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

5.  Discussion

   The following are the consequences of the above changes, taken
   together with the unaffected parts of RFC 3697:
   o  Sending hosts that are not updated will in practice continue to
      send all-zero labels.  If there is no label-setting router along
      the path taken by a packet, the label will be delivered as zero.
   o  Sending hosts conforming to this specification will by default
      choose pseudo-random labels between 1 and 0xFFFFF.
   o  Sending hosts may continue to send all-zero labels, in which case
      an ingress router may set pseudo-random labels between 1 and
   o  The flow label is no longer unrealistically asserted to be
      strictly immutable; it is recognised that it may, incorrectly, be
      changed en route.  In some circumstances this will break end-to-
      end usage, e.g. potential detection of third-party spoofing
      attacks [I-D.gont-6man-flowlabel-security].
   o  The expected default usage of the flow label is some form of load
      balancing, such as the ECMP/LAG usage defined in
   o  If the rules in Section 4 are followed, including rule 3.2, all
      IPv6 traffic flows on the Internet will have zero or pseudo-random
      flow label values.

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

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

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

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

6.  Security Considerations

   The flow label is not protected in any way and can be forged by an
   on-path attacker.  On the other hand, a pseudo-random flow label
   cannot be readily guessed by an off-path attacker.  See RFC 3697 and
   [I-D.gont-6man-flowlabel-security] for further discussion.

   Security devices that clear or rewrite flow label values would be in
   violation of this specification.

7.  IANA Considerations

   This document requests no action by IANA.

8.  Acknowledgements

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

   This document was produced using the xml2rfc tool [RFC2629].

9.  Change log

   draft-ietf-6man-flow-update-01: clarified that this is not a formal
   update of RFC 3697, clarified text about domains exporting
   inappropriate labels, 2011-01-10

   draft-ietf-6man-flow-update-00: adopted as WG document at IETF 79,
   mutability rules adjusted according to WG discussion, 2010-12-03

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

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

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

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

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

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

10.2.  Informative References

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

              Gont, F., "Security Assessment of the IPv6 Flow Label",
              draft-gont-6man-flowlabel-security-01 (work in progress),
              November 2010.

              Hu, Q. and B. Carpenter, "Survey of proposed use cases for
              the IPv6 flow label", draft-hu-flow-label-cases-02 (work
              in progress), September 2010.

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

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

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

Appendix A.  Alternative Approaches

   A model was discussed in an earlier version of this document which
   defined a notion of 'flow label domain' analogous to a differentiated
   services domain [RFC2474].  This model would have encouraged local
   usage of the flow label as an alternative to any form of generic use,
   but it required complex rules for the behaviour of domain boundary
   routers, and proved controversial in discussion.

   Two even more complex alternative approaches were also considered and

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

   The second was to use a specific differentiated services code point
   (DSCP)[RFC2474] in the Traffic Class octet instead of the MSB of the
   flow label itself, to flag a locally defined behaviour.  A more
   elaborate version of this was proposed in
   [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching].  There are two
   issues with this approach.  One is that DSCP values are themselves
   only locally significant, inconsistent with the end-to-end nature of
   the original flow label definition.  Secondly, it seems unwise to
   meld the semantics of differentiated services, which are currently
   deployed, with the unknown future semantics of flow label usage.
   However, this approach, while not recommended, does not appear to
   violate any basic principles if applied strictly within a single
   differentiated services domain.

Authors' Addresses

   Shane Amante
   Level 3 Communications, LLC
   1025 Eldorado Blvd
   Broomfield, CO  80021

   Email: shane@level3.net
   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland,   1142
   New Zealand

   Email: brian.e.carpenter@gmail.com

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Huawei Building, No.9 No.3 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing
   P.R. China

   Email: shengjiang@huawei.com