draft-ietf-6man-flow-update-07.txt   rfc6436.txt 
6MAN S. Amante Internet Engineering Task Force (IETF) S. Amante
Internet-Draft Level 3 Request for Comments: 6436 Level 3
Intended status: Informational B. Carpenter Category: Informational B. Carpenter
Expires: January 6, 2012 Univ. of Auckland ISSN: 2070-1721 Univ. of Auckland
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei
July 5, 2011 November 2011
Rationale for update to the IPv6 flow label specification Rationale for Update to the IPv6 Flow Label Specification
draft-ietf-6man-flow-update-07
Abstract Abstract
Various published proposals for use of the IPv6 flow label are Various published proposals for use of the IPv6 flow label are
incompatible with its original specification in RFC 3697. incompatible with its original specification in RFC 3697.
Furthermore, very little practical use is made of the flow label, Furthermore, very little practical use is made of the flow label,
partly due to some uncertainties about the correct interpretation of partly due to some uncertainties about the correct interpretation of
the specification. This document discusses and motivates changes to the specification. This document discusses and motivates changes to
the specification in order to clarify it, and to introduce some the specification in order to clarify it and to introduce some
additional flexibility. additional flexibility.
Status of this Memo 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 This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on January 6, 2012. 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.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Impact of current specification . . . . . . . . . . . . . . . 3 2. Impact of Current Specification . . . . . . . . . . . . . . . 3
3. Changes to specification . . . . . . . . . . . . . . . . . . . 6 3. Changes to the Specification . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Informative References . . . . . . . . . . . . . . . . . . . . 10
8. Change log [RFC Editor: please remove] . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The flow label field in the IPv6 header was reserved but left The flow label field in the IPv6 header was reserved but left
experimental by [RFC2460], which mandates only that "Hosts or routers Experimental by [RFC2460], which mandates only that "Hosts or routers
that do not support the functions of the Flow Label field are 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 required to set the field to zero when originating a packet, pass the
field on unchanged when forwarding a packet, and ignore the field field on unchanged when forwarding a packet, and ignore the field
when receiving a packet." when receiving a packet."
The flow label field was normatively specified by [RFC3697]. In The flow label field was normatively specified by [RFC3697]. In
particular, we quote three rules from that RFC: particular, we quote three rules from that RFC:
a. "The Flow Label value set by the source MUST be delivered a. "The Flow Label value set by the source MUST be delivered
unchanged to the destination node(s)." unchanged to the destination node(s)."
b. "IPv6 nodes MUST NOT assume any mathematical or other properties b. "IPv6 nodes MUST NOT assume any mathematical or other properties
of the Flow Label values assigned by source nodes." of the Flow Label values assigned by source nodes."
c. "Router performance SHOULD NOT be dependent on the distribution c. "Router performance SHOULD NOT be dependent on the distribution
of the Flow Label values. Especially, the Flow Label bits alone of the Flow Label values. Especially, the Flow Label bits alone
make poor material for a hash key." make poor material for a hash key."
Additionally, RFC 3697 leaves it undefined what method a host should Additionally, RFC 3697 does not define the method a host should adopt
adopt by default to choose the value of the flow label, if no by default to choose the value of the flow label, if no specific
specific method is in use. It was expected that various signaling method is in use. It was expected that various signaling methods
methods might be defined for agreeing on values of the flow label, might be defined for agreeing on values of the flow label, but no
but no such methods have been standardised, except a pre-existing such methods have been standardized, except a pre-existing option in
option in RSVP [RFC2205]. RSVP [RFC2205].
The flow label is hardly used in practice in widespread IPv6 The flow label is hardly used in practice in widespread IPv6
implementations, although some operating systems do set it implementations, although some operating systems do set it
[McGann05]. To some extent this is due to the main focus being on [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 basic deployment of IPv6, but the absence of a default method of
choosing the flow label value means that most host implementations choosing the flow label value means that most host implementations
simply set it to zero. There is also anecdotal evidence that the simply set it to zero. There is also anecdotal evidence that the
rules quoted above have led to uncertainty about exactly what is rules quoted above have led to uncertainty about exactly what is
possible. Furthermore, various use cases have been proposed that possible. Furthermore, various use cases have been proposed that
infringe one or another of the rules. None of these proposals has infringe one or another of the rules. None of these proposals has
been accepted as a standard and in practice there is no significant been accepted as a standard and in practice there is no significant
deployment of any mechanism to set the flow label. deployment of any mechanism to set the flow label.
The intention of this document is to explain this situation in more The intention of this document is to explain this situation in more
detail and to motivate changes to RFC 3697 intended to remove the detail and to motivate changes to RFC 3697 intended to remove the
uncertainties and encourage active usage of the flow label. It does uncertainties and encourage active usage of the flow label. It does
not formally update RFC 3697, but it serves as background material not formally update RFC 3697, but it serves as background material
for [I-D.ietf-6man-flow-3697bis]. for [RFC6437].
2. Impact of current specification 2. Impact of Current Specification
Rule (a) makes it impossible for the routing system to use the flow 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 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 choice in the early design of IPv6, and there appears to be no
practical possibility of revisiting this choice at this stage in the practical possibility of revisiting this decision at this stage in
deployment of IPv6, which uses conventional routing mechanisms like the deployment of IPv6, which uses conventional routing mechanisms
those used for IPv4. However, this rule also makes it impossible to like those used for IPv4. However, this rule also makes it
make any use at all of the flow label unless hosts choose to set it. impossible to make any use at all of the flow label unless hosts
It also forbids clearing the flow label for security reasons. choose to set it. It also forbids clearing the flow label for
security reasons.
This last point highlights the security properties, or rather the This last point highlights the security properties, or rather the
lack of them, of the flow label. The flow label field is always lack thereof, with regards to the flow label. The flow label field
unprotected as it travels through the network, because there is no is always unprotected as it travels through the network, because
IPv6 header checksum, and the flow label is not included in transport there is no IPv6 header checksum, and the flow label is not included
pseudo-header checksums, nor in IPsec checksums. As a result, in transport pseudo-header checksums, nor in IPsec checksums. As a
intentional and malicious changes to its value cannot be detected. result, intentional and malicious changes to its value cannot be
Also, it could be used as a covert data channel, since apparently detected. Also, it could be used as a covert data channel, since
pseudo-random flow label values could in fact consist of covert data apparently pseudo-random flow label values could in fact consist of
[NIST]. If the flow label were to carry quality of service covert data [NIST]. If the flow label were to carry quality-of-
semantics, then like the diffserv code point [RFC2474], it would not service semantics, then like the diffserv code point [RFC2474], it
be intrinsically trustworthy across domain boundaries. As a result, would not be intrinsically trustworthy across domain boundaries. As
some security specialists believe that flow labels should be cleared a result, some security specialists believe that flow labels should
for safety [I-D.gont-6man-flowlabel-security], [NSA]. These points be cleared for safety [LABEL-SEC] [NSA]. These points must be
must be considered when discussing the immutability of the flow label considered when discussing the immutability of the flow label across
across domain boundaries. In fact, the adjective "immutable" is domain boundaries. In fact, the adjective "immutable" is confusing,
confusing, since it implies a property that the flow label field does since it implies a property that the flow label field does not
not actually possess. It has therefore been abandoned as a actually possess. It has therefore been abandoned as a descriptive
descriptive term in [I-D.ietf-6man-flow-3697bis]. It is only used in term in [RFC6437]. It is only used in the present document to
the present document to explain why it has been abandoned. explain why it has been abandoned.
Rule (b) appears to forbid any usage in which the bits of the flow Rule (b) appears to forbid any usage in which the bits of the flow
label are encoded with a specific semantic meaning. However, the label are encoded with a specific semantic meaning. However, the
words "MUST NOT assume" are to be interpreted precisely - if a router words "MUST NOT assume" are to be interpreted precisely - if a router
knows by configuration or by signaling that the flow label has been 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 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 not made clear by the rule that there is an implied distinction
between stateless models (in which case no assumption may be made) between stateless models (in which there is no signaling, so no
and stateful models (in which the router has explicit knowledge). 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 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 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 used by load distribution mechanisms. In this case too, the word
"alone" needs to be taken into account - a router is allowed to "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 combine the flow label value with other data in order to produce a
uniformly distributed hash. uniformly distributed hash.
Both before and after these rules were laid down, a considerable Both before and after these rules were laid down, a considerable
number of proposals for use of the flow label were published that number of proposals for use of the flow label were published that
seem incompatible with them. Numerous examples and an analysis are seem incompatible with them. Numerous examples and an analysis are
presented in [I-D.hu-flow-label-cases]. Those examples propose use presented in [RFC6294]. Those examples propose use cases in which
cases in which some or all of the following apply: some or all of the following apply:
o The flow label may be changed by intermediate systems. o The flow label may be changed by intermediate systems.
o It doesn't matter if the flow label is changed, because the o It doesn't matter if the flow label is changed, because the
receiver doesn't use it. receiver doesn't use it.
o Some or all bits of the flow label are encoded: they have specific o Some or all bits of the flow label are encoded: they have specific
meanings understood by routers and switches along the path. meanings understood by routers and switches along the path.
o The encoding is related to the required quality of service, as o The encoding is related to the required quality of service, as
well as identifying a flow. well as identifying a flow.
o The flow label is used to control forwarding or switching in some o The flow label is used to control forwarding or switching in some
way. way.
These proposals all require either some form of encoding of semantics These proposals require either some form of semantics encoding in the
in the bits of the flow label, or the ability for routers to modify bits of the flow label, or the ability for routers to modify the flow
the flow label, or both. Thus they appear to infringe the rules from label, or both. Thus, they appear to infringe the rules from RFC
RFC 3697 quoted above. 3697 quoted above.
We can conclude that a considerable number of researchers and We can conclude that a considerable number of researchers and
designers have been stymied by RFC 3697. On the other hand, some 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 other proposals discussed in [RFC6294] appear to be compatible with
compatible with RFC 3697. Several are based on the originator of a RFC 3697. Several are based on the originator of a packet choosing a
packet choosing a pseudo-random flow label for each flow, which is pseudo-random flow label for each flow, which is one option suggested
one option suggested in RFC 3697. Thus, we can also conclude that in RFC 3697. Thus, we can also conclude that there is a useful role
there is a useful role for this approach. for this approach.
If our goal is for the flow label to be used in practice, the If our goal is for the flow label to be used in practice, the
conflict between the various approaches creates a dilemma. There conflict between the various approaches creates a dilemma. There
appear to be two major options: appear to be two major options:
1. Discourage locally defined and/or stateful use of the flow label. 1. Discourage locally defined and/or stateful use of the flow label.
Strengthen RFC 3697 to say that hosts should set a label value, Strengthen RFC 3697 to say that hosts should set a label value,
without necessarily creating state, which would clarify and limit without necessarily creating state, which would clarify and limit
its possible uses. In particular, its use for load distribution its possible uses. In particular, its use for load distribution
and balancing would be encouraged. and balancing would be encouraged.
2. Relax the rules to encourage locally defined and/or stateful use 2. Relax the rules to encourage locally defined and/or stateful use
of the flow label. This approach would make the flow label of the flow label. This approach would make the flow label
completely mutable and would exclude use cases depending on completely mutable and would exclude use cases depending on
strict end-to-end immutability. It would encourage applications strict end-to-end immutability. It would encourage applications
of a pseudo-random flow label, such as load distribution, on a of a pseudo-random flow label, such as load distribution, on a
local basis, but it would exclude end-to-end applications. local basis, but it would exclude end-to-end applications.
During 2010/2011 there was considerable debate about these options There was considerable debate about these options and their variants
and variants of them, with a variety of proposals in previous during 2010 - 2011, with a variety of proposals in previous versions
versions of this document and in mailing list discussions. After of this document and in mailing list discussions. After these
these discussions, there appears to be a view that simplicity should discussions, there appears to be a view that simplicity should
prevail, and that complicated proposals such as defining quality of prevail, and that complicated proposals such as defining quality-of-
service semantics in the flow label, or sub-dividing the flow label service semantics in the flow label, or sub-dividing the flow label
field into smaller sub-fields, will not prove efficient or field into smaller sub-fields, will not prove efficient or
deployable, especially in high speed routers. There is also a deployable, especially in high-speed routers. There is also a
clearly expressed view that using the flow label for various forms of clearly expressed view that using the flow label for various forms of
stateless load distribution is the best simple application for it. stateless load distribution is the best simple application for it.
At the same time, it is necessary to recognize that the strict At the same time, it is necessary to recognize that the strict
immutability rule has drawbacks as noted above. immutability rule has drawbacks as noted above.
Even under the rules of RFC 3697, the flow label is intrinsically Even under the rules of RFC 3697, the flow label is intrinsically
untrustworthy, because modifications en route cannot be detected. untrustworthy, because modifications en route cannot be detected.
For this reason, even with the current strict immutability rule, For this reason, even with the current strict immutability rule,
downstream nodes cannot rely mathematically on the value being downstream nodes cannot rely mathematically on the value being
unchanged. In this sense, any use of the flow label must be viewed 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 as an optimization on a best-effort basis; a packet with a changed
(or zero) flow label value should never cause a hard failure. (or zero) flow label value should never cause a hard failure.
The remainder of this document discusses specific modifications to The remainder of this document discusses specific modifications to
the standard, which are defined normatively in a companion document the standard, which are defined normatively in a companion document
[I-D.ietf-6man-flow-3697bis]. [RFC6437].
3. Changes to specification 3. Changes to the Specification
Although RFC 3697 requires the flow label to be delivered unchanged, Although RFC 3697 requires that the flow label be delivered
as noted above, it is not included in any transport layer pseudo- unchanged, as noted above, it is not included in any transport-layer
header checksums nor in IPsec authentication [RFC4302]. Both RFC pseudo-header checksums nor in IPsec authentication [RFC4302]. Both
2460 and RFC 3697 define the default flow label to be zero. At the RFC 2460 and RFC 3697 define the default flow label to be zero. At
time of writing, this is the observed value in an overwhelming the time of writing, this is the observed value in an overwhelming
proportion of IPv6 packets; the most widespread operating systems and proportion of IPv6 packets; the most widespread operating systems and
applications do not set it, and routers do not rely on it. Thus applications do not set it, and routers do not rely on it. Thus,
there is no reason to expect operational difficulties if a careful there is no reason to expect operational difficulties if a careful
change is made to the rules of RFC 3697. change is made to the rules of RFC 3697.
In particular, the facts that the label is not checksummed and rarely In particular, the facts that the label is not checksummed and rarely
used mean that the "immutability" of the label can be moderated used mean that the "immutability" of the label can be moderated
without serious operational consequences. without serious operational consequences.
The purposes of the proposed changes are to remove the uncertainties 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 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 default, and to enable its generic use. The proposed generic use is
skipping to change at page 7, line 4 skipping to change at page 6, line 42
existing IETF specifications other than RFC 3697 and no impact on existing IETF specifications other than RFC 3697 and no impact on
currently operational software and hardware. currently operational software and hardware.
A secondary purpose is to allow changes to the flow label in a 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 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 from it nevertheless. The fact that the flow label may in practice
be changed en route is also reflected in the reformulation of the be changed en route is also reflected in the reformulation of the
rules. rules.
A general description of the changes follows. The normative text is A general description of the changes follows. The normative text is
to be found in [I-D.ietf-6man-flow-3697bis]. to be found in [RFC6437].
The definition of a flow is subtly changed from RFC 3697 to allow any 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. node, not just the source node, to set the flow label value.
However, it is recommended that sources should set a uniformly However, it is recommended that sources should set a uniformly
distributed flow label value in all flows, replacing the less precise distributed flow label value in all flows, replacing the less precise
recommendation made in Section 3 of RFC 3697. Both stateful and recommendation made in Section 3 of RFC 3697. Both stateful and
stateless methods of assigning a uniformly distributed value could be stateless methods of assigning a uniformly distributed value could be
used. used.
Flow label values should be chosen such that their bits exhibit a Flow label values should be chosen such that their bits exhibit a
high degree of variability, thus making them suitable for use as part 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. of the input to a hash function used in a load distribution scheme.
At the same time, third parties should be unlikely to be able to At the same time, third parties should have a low probability of
guess the next value that a source of flow labels will choose. guessing the next value that a source of flow labels will choose.
In statistics, a discrete uniform distribution is defined as a In statistics, a discrete uniform distribution is defined as a
probability distribution in which each value in a given range of probability distribution in which each value in a given range of
equally spaced values (such as a sequence of integers) is equally equally spaced values (such as a sequence of integers) is equally
likely to be chosen as the next value. The values in such a likely to be chosen as the next value. The values in such a
distribution exhibit both variability and unguessability. Thus, an distribution exhibit both variability and unguessability. Thus, an
approximation to a discrete uniform distribution is preferable as the approximation to a discrete uniform distribution is preferable as the
source of flow label values. In contrast, an implementation in which source of flow label values. In contrast, an implementation in which
flow labels are assigned sequentially is definitely not recommended, flow labels are assigned sequentially is definitely not recommended,
to avoid guessability. to avoid guessability.
In practice it is expected that a uniform distribution of flow label 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- values will be approximated by use of a hash function or a pseudo-
random number generator. Either approach will produce values which random number generator. Either approach will produce values that
will appear pseudo-random to an external observer. will appear pseudo-random to an external observer.
Section 3 of RFC 3697 allows nodes to participate in an unspecified Section 3 of RFC 3697 allows nodes to participate in an unspecified
stateful method of flow state establishment. The changes do not stateful method of flow state establishment. The changes do not
remove that option, but it is made clear that stateless models are remove that option, but clarify that stateless models are also
also possible and are the recommended default. The specific text possible and are the recommended default. The specific text on
about requirements for stateful models has been reduced to a bare requirements for stateful models has been reduced to a bare minimum
minimum requirement that they do not interfere with the stateless requirement that they do not interfere with the stateless model. To
model. To enable stateless load distribution at any point in the enable stateless load distribution at any point in the Internet, a
Internet, a node using a stateful model should never send packets node using a stateful model should never send packets whose flow
whose flow label values do not conform to a uniform distribution. label values do not conform to a uniform distribution.
The main novelty is that a forwarding node (typically a first-hop or 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 ingress router) may set the flow label value if the source has not
done so, according to the same recommendations that apply to the done so, according to the same recommendations that apply to the
source. This might place a considerable processing load on ingress source. This might place a considerable processing load on ingress
routers that choose to do so, even if they adopted a stateless method routers that choose to do so, even if they adopted a stateless method
of flow identification and label assignment. of flow identification and label assignment.
The value of the flow label, once it has been set, must not be The value of the flow label, once it has been set, must not be
changed. However, some qualifications are placed on this rule, to changed. However, some qualifications are placed on this rule, to
allow for the fact that the flow label is an unprotected field and allow for the fact that the flow label is an unprotected field and
might be misused. No Internet-wide mechanism can depend might be misused. No Internet-wide mechanism can depend
mathematically on immutable flow labels. The new rules require that mathematically on immutable flow labels. The new rules require that
flow labels exported to the Internet should always be either zero or flow labels exported to the Internet should always be either zero or
uniformly distributed, but even this cannot be relied on uniformly distributed, but even this cannot be relied on
mathematically. Use cases need to be robust against non-conforming mathematically. Use cases need to be robust against non-conforming
flow label values. This will also enhance compatibility with any flow label values. This will also enhance compatibility with any
legacy hosts that set the flow label according to RFC 2460 or RFC legacy hosts that set the flow label according to RFC 2460 and RFC
3697. 3697.
A complication that led to much discussion is the possibility that A complication that led to much discussion is the possibility that
hosts inside a particular network domain might use a stateful method hosts inside a particular network domain might use a stateful method
of setting the flow label, and that packets bearing stateful labels of setting the flow label, and that packets bearing stateful labels
might then erroneously escape the domain and be received by nodes might then erroneously escape the domain and be received by nodes
performing stateless processing such as load balancing. This might performing stateless processing, such as load balancing. This might
result in undesirable operational implications (e.g., congestion, result in undesirable operational implications (e.g., congestion,
reordering) for not only the inappropriately flow-labelled packets, reordering) for not only the inappropriately flow-labeled packets,
but also well-behaved flow-labelled packets, during forwarding at but also well-behaved flow-labeled packets, during forwarding at
various intermediate devices. It was proposed to suggest that border various intermediate devices. It was suggested that border routers
routers might "correct" this problem by overwriting such labels in might "correct" this problem by overwriting such labels in packets
packets leaving the domain. However, neither domain border egress leaving the domain. However, neither domain border egress routers
routers nor intermediate routers/devices (using a flow label, for nor intermediate routers/devices (using a flow label, for example, as
example, as a part of an input key for a load-distribution hash) can a part of an input key for a load-distribution hash) can determine by
determine by inspection that a value is not part of a uniform inspection that a value is not part of a uniform distribution. Thus,
distribution. Thus there is no way that such values can be detected there is no way that such values can be detected and "corrected".
and "corrected". Therefore, the recommendation to choose flow labels Therefore, the recommendation to choose flow labels from a uniform
from a uniform distribution also applies to stateful schemes. distribution also applies to stateful schemes.
4. Discussion 4. Discussion
The following are some practical consequences of the above changes: The following are some practical consequences of the above changes:
o Sending hosts that are not updated will in practice continue to o Sending hosts that are not updated will in practice continue to
send all-zero labels. If there is no label-setting router along 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. the path taken by a packet, the label will be delivered as zero.
o Sending hosts conforming to the new specification will by default o Sending hosts conforming to the new specification will by default
choose uniformly distributed labels between 1 and 0xFFFFF. choose uniformly distributed labels between 1 and 0xFFFFF.
o Sending hosts may continue to send all-zero labels, in which case o Sending hosts may continue to send all-zero labels, in which case
an ingress router may set uniformly distributed labels between 1 an ingress router may set uniformly distributed labels between 1
and 0xFFFFF. and 0xFFFFF.
o The flow label is no longer unrealistically asserted to be o The flow label is no longer unrealistically asserted to be
strictly immutable; it is recognised that it may, incorrectly, be strictly immutable; it is recognized that it may, incorrectly, be
changed en route. In some circumstances this will break end-to- changed en route. In some circumstances, this will break end-to-
end usage, e.g. potential detection of third-party spoofing end usage, e.g., potential detection of third-party spoofing
attacks [I-D.gont-6man-flowlabel-security]. attacks [LABEL-SEC].
o The expected default usage of the flow label is some form of o The expected default usage of the flow label is some form of
stateless load distribution, such as the ECMP/LAG usage defined in stateless load distribution, such as the ECMP/LAG usage defined in
[I-D.carpenter-flow-ecmp]. [RFC6438].
o If the new rules are followed, all IPv6 traffic flows on the o If the new rules are followed, all IPv6 traffic flows on the
Internet should have zero or uniformly distributed flow label Internet should have zero or uniformly distributed flow label
values. values.
From an operational viewpoint, existing IPv6 hosts that set a default From an operational viewpoint, existing IPv6 hosts that set a default
(zero) flow label value and ignore the flow label on receipt will be (zero) flow label value and ignore the flow label on receipt will be
unaffected by implementations of the new specification. In general, unaffected by implementations of the new specification. In general,
it is assumed that hosts will ignore the value of the flow label on 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, receipt; it cannot be relied on as an end-to-end signal. However,
this doesn't apply if a cryptographically generated label is being this doesn't apply if a cryptographically generated label is being
used to detect attackers [I-D.gont-6man-flowlabel-security]. used to detect attackers [LABEL-SEC].
Similarly, routers that ignore the flow label will be unaffected by Similarly, routers that ignore the flow label will be unaffected by
implementations of the specification. implementations of the specification.
Hosts that set a default (zero) flow label but are in a domain where 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 routers set a label as recommended in Section 3 will benefit from
whatever flow label handling is used on the path. whatever flow label handling is used on the path.
Hosts and routers that adopt the recommended mechanism will enhance Hosts and routers that adopt the recommended mechanism will enhance
the performance of any load balancing devices that include the flow the performance of any load balancing devices that include the flow
label in the hash used to select a particular path or server, even label in the hash used to select a particular path or server, even
when packets leave the local domain. when packets leave the local domain.
5. Security Considerations 5. Security Considerations
See [I-D.ietf-6man-flow-3697bis] and See [RFC6437] and [LABEL-SEC] for full discussion. Some useful
[I-D.gont-6man-flowlabel-security] for full discussion. Some useful
remarks are in [Partridge]. remarks are in [Partridge].
6. IANA Considerations 6. Acknowledgements
This document requests no action by IANA.
7. Acknowledgements
The authors are grateful to Qinwen Hu for general discussion about The authors are grateful to Qinwen Hu for general discussion about
the flow label and for his work in searching the literature. the flow label and for his work in searching the literature.
Valuable comments and contributions were made by Ran Atkinson, Fred Valuable comments and contributions were made by Ran Atkinson, Fred
Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Gont, Brian
Haberman, Tony Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka Haberman, Tony Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka
Savola, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other Savola, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other
participants in the 6man working group. participants in the 6man working group.
This document was produced using the xml2rfc tool [RFC2629]. 7. Informative References
8. Change log [RFC Editor: please remove]
draft-ietf-6man-flow-update-07: minor editorial fix, AD comments,
2011-07-05
draft-ietf-6man-flow-update-06: updated again to be in step with RFC
3697bis, 2011-05-11
draft-ietf-6man-flow-update-05: updated again to be in step with RFC
3697bis, 2011-05-02
draft-ietf-6man-flow-update-04: updated again to be in step with RFC
3697bis, 2011-03-13
draft-ietf-6man-flow-update-03: updated to be in step with RFC
3697bis, 2011-02-26
draft-ietf-6man-flow-update-02: repurposed as rationale for update of
RFC 3697, 2011-01-31
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
9. Informative References
[I-D.carpenter-flow-ecmp]
Carpenter, B. and S. Amante, "Using the IPv6 flow label
for equal cost multipath routing and link aggregation in
tunnels", draft-carpenter-flow-ecmp-03 (work in progress),
October 2010.
[I-D.gont-6man-flowlabel-security] [FLOWSWITCH] Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)",
Gont, F., "Security Assessment of the IPv6 Flow Label", Work in Progress, March 2007.
draft-gont-6man-flowlabel-security-01 (work in progress),
November 2010.
[I-D.hu-flow-label-cases] [LABEL-SEC] Gont, F., "Security Assessment of the IPv6 Flow Label",
Hu, Q. and B. Carpenter, "Survey of proposed use cases for Work in Progress, November 2010.
the IPv6 flow label", draft-hu-flow-label-cases-03 (work
in progress), February 2011.
[I-D.ietf-6man-flow-3697bis] [McGann05] McGann, O. and D. Malone, "Flow Label Filtering
Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, Feasibility", European Conference on Computer Network
"IPv6 Flow Label Specification", Defence , 2005.
draft-ietf-6man-flow-3697bis-05 (work in progress),
June 2011.
[I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] [NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks,
Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", "Guidelines for the Secure Deployment of IPv6",
draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 National Institute of Standards and Technology Special
(work in progress), March 2007. Publication 800-119, 2010, <http://csrc.nist.gov/
publications/nistpubs/800-119/sp800-119.pdf>.
[McGann05] [NSA] Potyraj, C., "Firewall Design Considerations for IPv6",
McGann, O. and D. Malone, "Flow Label Filtering National Security Agency I733-041R-2007, 2007,
Feasibility", European Conference on Computer Network <http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>.
Defence , 2005.
[NIST] Frankel, S., Graveman, R., Pearce, J., and M. Rooks, [Partridge] Partridge, C., Arsenault, A., and S. Kent, "Information
"Guidelines for the Secure Deployment of IPv6", National Assurance and the Transition to IP Version 6 (IPv6)",
Institute of Standards and Technology Special Publication Military Communications Conference (MILCOM 2007) ,
800-119, 2010, <http://csrc.nist.gov/publications/ 2007, <http://www.ir.bbn.com/documents/articles/
nistpubs/800-119/sp800-119.pdf>. MILCOM_Paper_from_Proceedings.pdf>.
[NSA] Potyraj, C., "Firewall Design Considerations for IPv6", [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
National Security Agency I733-041R-2007, 2007, Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
<http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf>. 1 Functional Specification", RFC 2205, September 1997.
[Partridge] [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
Partridge, C., Arsenault, A., and S. Kent, "Information 6 (IPv6) Specification", RFC 2460, December 1998.
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. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 "Definition of the Differentiated Services Field (DS
Functional Specification", RFC 2205, September 1997. Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S.
(IPv6) Specification", RFC 2460, December 1998. Deering, "IPv6 Flow Label Specification", RFC 3697,
March 2004.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
"Definition of the Differentiated Services Field (DS December 2005.
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases
June 1999. for the IPv6 Flow Label", RFC 6294, June 2011.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 3697, March 2004. "IPv6 Flow Label Specification", RFC 6437, November
2011.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
December 2005. for Equal Cost Multipath Routing and Link Aggregation
in Tunnels", RFC 6438, November 2011.
Appendix A. Alternative Approaches Appendix A. Alternative Approaches
A model was discussed in an earlier version of this document which A model was discussed in an earlier version of this document which
defined a notion of 'flow label domain' analogous to a differentiated defined a notion of 'flow label domain' analogous to a differentiated
services domain [RFC2474]. This model would have encouraged local services domain [RFC2474]. This model would have encouraged local
usage of the flow label as an alternative to any form of generic use, 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 but it required complex rules for the behavior of domain boundary
routers, and proved controversial in discussion. routers, and proved controversial in discussion.
Two even more complex alternative approaches were also considered and Two even more complex alternative approaches were also considered and
rejected. rejected.
The first was to distinguish locally significant flow labels from The first was to distinguish locally significant flow labels from
those conforming to RFC 3697 by setting or clearing the most those conforming to RFC 3697 by setting or clearing the most
significant bit (MSB) of the flow label. This led to quite significant bit (MSB) of the flow label. This led to quite
complicated rules, seems impossible to make fully self-consistent, complicated rules, seems impossible to make fully self-consistent,
and was not considered practical. and was not considered practical.
The second was to use a specific differentiated services code point The second was to use a specific differentiated services code point
(DSCP)[RFC2474] in the Traffic Class octet instead of the MSB of the (DSCP) [RFC2474] in the Traffic Class octet instead of the MSB of the
flow label itself, to flag a locally defined behaviour. A more flow label itself, to flag a locally defined behavior. A more
elaborate version of this was proposed in elaborate version of this was proposed in [FLOWSWITCH]. There are
[I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]. There are two two issues with that approach. One is that DSCP values are
issues with this approach. One is that DSCP values are themselves themselves only locally significant, inconsistent with the end-to-end
only locally significant, inconsistent with the end-to-end nature of nature of the original flow label definition. Secondly, it seems
the original flow label definition. Secondly, it seems unwise to unwise to meld the semantics of differentiated services, which are
meld the semantics of differentiated services, which are currently currently deployed, with the unknown future semantics of flow label
deployed, with the unknown future semantics of flow label usage. usage. However, this approach, while not recommended, does not
However, this approach, while not recommended, does not appear to appear to violate any basic principles if applied strictly within a
violate any basic principles if applied strictly within a single single differentiated services domain.
differentiated services domain.
Authors' Addresses Authors' Addresses
Shane Amante Shane Amante
Level 3 Communications, LLC Level 3 Communications, LLC
1025 Eldorado Blvd 1025 Eldorado Blvd
Broomfield, CO 80021 Broomfield, CO 80021
USA USA
Email: shane@level3.net EMail: shane@level3.net
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland, 1142 Auckland, 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com EMail: brian.e.carpenter@gmail.com
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Huawei Building, No.3 Xinxi Rd., Q14, Huawei Campus
Shang-Di Information Industry Base, Hai-Dian District, Beijing No.156 Beiqing Road
Hai-Dian District, Beijing 100095
P.R. China P.R. China
Email: shengjiang@huawei.com EMail: jiangsheng@huawei.com
 End of changes. 77 change blocks. 
248 lines changed or deleted 199 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/