GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6436

Internet Engineering Task Force (IETF) S. Amante Request for Comments: 6436 Level 3 Category: Informational B. Carpenter ISSN: 2070-1721 Univ. of Auckland

                                                              S. Jiang
                                                                Huawei
                                                         November 2011
     Rationale for Update to the IPv6 Flow Label Specification

Abstract

 Various published proposals for use of the IPv6 flow label are
 incompatible with its original 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 discusses and motivates changes to
 the specification in order to clarify it and to introduce some
 additional flexibility.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are 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/rfc6436.

Amante, et al. Informational [Page 1] RFC 6436 Flow Label Update November 2011

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.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Impact of Current Specification  . . . . . . . . . . . . . . .  3
 3.  Changes to the Specification . . . . . . . . . . . . . . . . .  6
 4.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  8
 5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
 6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
 7.  Informative References . . . . . . . . . . . . . . . . . . . . 10
 Appendix A.  Alternative Approaches  . . . . . . . . . . . . . . . 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."

Amante, et al. Informational [Page 2] RFC 6436 Flow Label Update November 2011

 Additionally, RFC 3697 does not define the 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 signaling methods
 might be defined for agreeing on values of the flow label, but no
 such methods have been standardized, except a pre-existing option in
 RSVP [RFC2205].
 The flow label is hardly used in practice in widespread IPv6
 implementations, although some operating systems do set it
 [McGann05].  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 situation in more
 detail and to motivate changes to RFC 3697 intended to remove the
 uncertainties and encourage active usage of the flow label.  It does
 not formally update RFC 3697, but it serves as background material
 for [RFC6437].

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 decision 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 thereof, with regards to 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
 covert data [NIST].  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

Amante, et al. Informational [Page 3] RFC 6436 Flow Label Update November 2011

 a result, some security specialists believe that flow labels should
 be cleared for safety [LABEL-SEC] [NSA].  These points must be
 considered when discussing the immutability of the flow label across
 domain boundaries.  In fact, the adjective "immutable" is confusing,
 since it implies a property that the flow label field does not
 actually possess.  It has therefore been abandoned as a descriptive
 term in [RFC6437].  It is only used in the present document to
 explain why it has been abandoned.
 Rule (b) appears to forbid any usage in which the bits of the flow
 label are encoded with a specific semantic meaning.  However, the
 words "MUST NOT assume" are to be interpreted precisely - if a router
 knows by configuration or by signaling that the flow label has been
 assigned in a certain way, it can make use of that knowledge.  It is
 not made clear by the rule that there is an implied distinction
 between stateless models (in which there is no signaling, so no
 specific assumption about the meaning of the flow label value can be
 made) and stateful models (in which there is signaling and the router
 has explicit knowledge about the label).
 If the word "alone" is overlooked, rule (c) has sometimes been
 interpreted as forbidding the use of the flow label as part of a hash
 used by load distribution mechanisms.  In this case too, the word
 "alone" needs to be taken into account - a router is allowed to
 combine the flow label value with other data in order to produce a
 uniformly distributed hash.
 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 [RFC6294].  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
    way.

Amante, et al. Informational [Page 4] RFC 6436 Flow Label Update November 2011

 These proposals require either some form of semantics encoding 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 [RFC6294] 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 and/or stateful use of the flow label.
     Strengthen RFC 3697 to say that hosts should set a label value,
     without necessarily creating state, which would clarify and limit
     its possible uses.  In particular, its use for load distribution
     and balancing would be encouraged.
 2.  Relax the rules to encourage locally defined and/or stateful 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 distribution, on a
     local basis, but it would exclude end-to-end applications.
 There was considerable debate about these options and their variants
 during 2010 - 2011, 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 distribution 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 modifications en route cannot be detected.
 For this reason, even with the current strict immutability rule,
 downstream nodes cannot rely mathematically on the value being
 unchanged.  In this sense, any use of the flow label must be viewed

Amante, et al. Informational [Page 5] RFC 6436 Flow Label Update November 2011

 as an optimization 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 discusses specific modifications to
 the standard, which are defined normatively in a companion document
 [RFC6437].

3. Changes to the Specification

 Although RFC 3697 requires that the flow label 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; the most widespread operating systems and
 applications do not 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 "immutability" of the label can be moderated
 without serious 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 uniformly distributed flow labels that can be used to
 assist load distribution or 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 allow changes to 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 general description of the changes follows.  The normative text is
 to be found in [RFC6437].
 The definition of a flow is subtly changed from RFC 3697 to allow any
 node, not just the source node, to set the flow label value.
 However, it is recommended that sources should set a uniformly
 distributed flow label value in all flows, replacing the less precise
 recommendation made in Section 3 of RFC 3697.  Both stateful and
 stateless methods of assigning a uniformly distributed value could be
 used.

Amante, et al. Informational [Page 6] RFC 6436 Flow Label Update November 2011

 Flow label values should be chosen such that their bits exhibit a
 high degree of variability, thus making them suitable for use as part
 of the input to a hash function used in a load distribution scheme.
 At the same time, third parties should have a low probability of
 guessing the next value that a source of flow labels will choose.
 In statistics, a discrete uniform distribution is defined as a
 probability distribution in which each value in a given range of
 equally spaced values (such as a sequence of integers) is equally
 likely to be chosen as the next value.  The values in such a
 distribution exhibit both variability and unguessability.  Thus, an
 approximation to a discrete uniform distribution is preferable as the
 source of flow label values.  In contrast, an implementation in which
 flow labels are assigned sequentially is definitely not recommended,
 to avoid guessability.
 In practice, it is expected that a uniform distribution of flow label
 values will be approximated by use of a hash function or a pseudo-
 random number generator.  Either approach will produce values that
 will appear pseudo-random to an external observer.
 Section 3 of RFC 3697 allows nodes to participate in an unspecified
 stateful method of flow state establishment.  The changes do not
 remove that option, but clarify that stateless models are also
 possible and are the recommended default. The specific text on
 requirements for stateful models has been reduced to a bare minimum
 requirement that they do not interfere with the stateless model.  To
 enable stateless load distribution at any point in the Internet, a
 node using a stateful model should never send packets whose flow
 label values do not conform to a uniform distribution.
 The main novelty is that a forwarding node (typically a first-hop or
 ingress router) may set the flow label value if the source has not
 done so, according to the same recommendations that apply to the
 source.  This might place a considerable processing load on ingress
 routers that choose to do so, even if they adopted a stateless method
 of flow identification and label assignment.
 The value of the flow label, once it has been set, must not be
 changed.  However, some qualifications are placed on this rule, to
 allow for the fact that the flow label is an unprotected field and
 might be misused.  No Internet-wide mechanism can depend
 mathematically on immutable flow labels.  The new rules require that
 flow labels exported to the Internet should always be either zero or
 uniformly distributed, but even this cannot be relied on
 mathematically.  Use cases need to be robust against non-conforming

Amante, et al. Informational [Page 7] RFC 6436 Flow Label Update November 2011

 flow label values.  This will also enhance compatibility with any
 legacy hosts that set the flow label according to RFC 2460 and RFC
 3697.
 A complication that led to much discussion is the possibility that
 hosts inside a particular network domain might use a stateful method
 of setting the flow label, and that packets bearing stateful labels
 might then erroneously escape the domain and be received by nodes
 performing stateless processing, such as load balancing.  This might
 result in undesirable operational implications (e.g., congestion,
 reordering) for not only the inappropriately flow-labeled packets,
 but also well-behaved flow-labeled packets, during forwarding at
 various intermediate devices.  It was suggested that border routers
 might "correct" this problem by overwriting such labels in packets
 leaving the domain.  However, 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-distribution hash) can determine by
 inspection that a value is not part of a uniform distribution.  Thus,
 there is no way that such values can be detected and "corrected".
 Therefore, the recommendation to choose flow labels from a uniform
 distribution also applies to stateful schemes.

4. Discussion

 The following are some practical consequences of the above changes:
 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 the new specification will by default
    choose uniformly distributed labels between 1 and 0xFFFFF.
 o  Sending hosts may continue to send all-zero labels, in which case
    an ingress router may set uniformly distributed labels between 1
    and 0xFFFFF.
 o  The flow label is no longer unrealistically asserted to be
    strictly immutable; it is recognized 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 [LABEL-SEC].
 o  The expected default usage of the flow label is some form of
    stateless load distribution, such as the ECMP/LAG usage defined in
    [RFC6438].

Amante, et al. Informational [Page 8] RFC 6436 Flow Label Update November 2011

 o  If the new rules are followed, all IPv6 traffic flows on the
    Internet should have zero or uniformly distributed 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 the new 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.  However,
 this doesn't apply if a cryptographically generated label is being
 used to detect attackers [LABEL-SEC].
 Similarly, routers that ignore the flow label will be unaffected by
 implementations of the specification.
 Hosts that set a default (zero) flow label but are in a domain where
 routers set a label as recommended in Section 3 will benefit from
 whatever flow label handling is used on the path.
 Hosts and routers that adopt the recommended 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.

5. Security Considerations

 See [RFC6437] and [LABEL-SEC] for full discussion.  Some useful
 remarks are in [Partridge].

6. 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 Ran Atkinson, Fred
 Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Gont, Brian
 Haberman, Tony Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka
 Savola, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other
 participants in the 6man working group.

Amante, et al. Informational [Page 9] RFC 6436 Flow Label Update November 2011

7. Informative References

 [FLOWSWITCH]  Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)",
               Work in Progress, March 2007.
 [LABEL-SEC]   Gont, F., "Security Assessment of the IPv6 Flow Label",
               Work in Progress, November 2010.
 [McGann05]    McGann, O. and D. Malone, "Flow Label Filtering
               Feasibility", European Conference on Computer Network
               Defence , 2005.
 [NIST]        Frankel, S., Graveman, R., Pearce, J., and M. Rooks,
               "Guidelines for the Secure Deployment of IPv6",
               National Institute of Standards and Technology Special
               Publication 800-119, 2010, <http://csrc.nist.gov/
               publications/nistpubs/800-119/sp800-119.pdf>.
 [NSA]         Potyraj, C., "Firewall Design Considerations for IPv6",
               National Security Agency I733-041R-2007, 2007,
               <http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>.
 [Partridge]   Partridge, C., Arsenault, A., and S. Kent, "Information
               Assurance and the Transition to IP Version 6 (IPv6)",
               Military Communications Conference (MILCOM 2007)  ,
               2007, <http://www.ir.bbn.com/documents/articles/
               MILCOM_Paper_from_Proceedings.pdf>.
 [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.
 [RFC3697]     Rajahalme, J., Conta, A., Carpenter, B., and S.
               Deering, "IPv6 Flow Label Specification", RFC 3697,
               March 2004.
 [RFC4302]     Kent, S., "IP Authentication Header", RFC 4302,
               December 2005.

Amante, et al. Informational [Page 10] RFC 6436 Flow Label Update November 2011

 [RFC6294]     Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases
               for the IPv6 Flow Label", RFC 6294, June 2011.
 [RFC6437]     Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
               "IPv6 Flow Label Specification", RFC 6437, November
               2011.
 [RFC6438]     Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
               for Equal Cost Multipath Routing and Link Aggregation
               in Tunnels", RFC 6438, November 2011.

Amante, et al. Informational [Page 11] RFC 6436 Flow Label Update November 2011

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 behavior of domain boundary
 routers, and proved controversial in discussion.
 Two even more complex alternative approaches were also considered and
 rejected.
 The first was to distinguish locally significant flow labels from
 those conforming to RFC 3697 by setting or clearing the most
 significant bit (MSB) of the flow label.  This led to quite
 complicated rules, seems impossible to make fully self-consistent,
 and was not considered practical.
 The second was to use a specific differentiated services code point
 (DSCP) [RFC2474] in the Traffic Class octet instead of the MSB of the
 flow label itself, to flag a locally defined behavior.  A more
 elaborate version of this was proposed in [FLOWSWITCH].  There are
 two issues with that 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.

Amante, et al. Informational [Page 12] RFC 6436 Flow Label Update November 2011

Authors' Addresses

 Shane Amante
 Level 3 Communications, LLC
 1025 Eldorado Blvd
 Broomfield, CO  80021
 USA
 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
 Q14, Huawei Campus
 No.156 Beiqing Road
 Hai-Dian District, Beijing  100095
 P.R. China
 EMail: jiangsheng@huawei.com

Amante, et al. Informational [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6436.txt · Last modified: 2011/11/01 22:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki