draft-ietf-6man-flow-update-06.txt   draft-ietf-6man-flow-update-07.txt 
6MAN S. Amante 6MAN S. Amante
Internet-Draft Level 3 Internet-Draft Level 3
Intended status: Informational B. Carpenter Intended status: Informational B. Carpenter
Expires: November 12, 2011 Univ. of Auckland Expires: January 6, 2012 Univ. of Auckland
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
May 11, 2011 July 5, 2011
Rationale for update to the IPv6 flow label specification Rationale for update to the IPv6 flow label specification
draft-ietf-6man-flow-update-06 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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2011. This Internet-Draft will expire on January 6, 2012.
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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Impact of current specification . . . . . . . . . . . . . . . 3 2. Impact of current specification . . . . . . . . . . . . . . . 3
3. Changes to specification . . . . . . . . . . . . . . . . . . . 6 3. Changes to specification . . . . . . . . . . . . . . . . . . . 6
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. Change log [RFC Editor: please remove] . . . . . . . . . . . . 10 8. Change log [RFC Editor: please remove] . . . . . . . . . . . . 10
9. Informative References . . . . . . . . . . . . . . . . . . . . 10 9. Informative References . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 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
skipping to change at page 4, line 19 skipping to change at page 4, line 19
make any use at all of the flow label unless hosts choose to set it. 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. 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 of them, of the flow label. The flow label field is always
unprotected as it travels through the network, because there is no unprotected as it travels through the network, because there is no
IPv6 header checksum, and the flow label is not included in transport IPv6 header checksum, and the flow label is not included in transport
pseudo-header checksums, nor in IPsec checksums. As a result, pseudo-header checksums, nor in IPsec checksums. As a result,
intentional and malicious changes to its value cannot be detected. intentional and malicious changes to its value cannot be detected.
Also, it could be used as a covert data channel, since apparently Also, it could be used as a covert data channel, since apparently
pseudo-random flow label values could in fact consist of covert data. pseudo-random flow label values could in fact consist of covert data
If the flow label were to carry quality of service semantics, then [NIST]. If the flow label were to carry quality of service
like the diffserv code point [RFC2474], it would not be intrinsically semantics, then like the diffserv code point [RFC2474], it would not
trustworthy across domain boundaries. As a result, some security be intrinsically trustworthy across domain boundaries. As a result,
specialists believe that flow labels should be cleared for safety some security specialists believe that flow labels should be cleared
[I-D.gont-6man-flowlabel-security], [NSA], [NIST]. These points must for safety [I-D.gont-6man-flowlabel-security], [NSA]. These points
be considered when discussing the immutability of the flow label must be considered when discussing the immutability of the flow label
across domain boundaries. In fact, the adjective "immutable" is across domain boundaries. In fact, the adjective "immutable" is
confusing, since it implies a property that the flow label field does confusing, since it implies a property that the flow label field does
not actually possess. It has therefore been abandoned as a not actually possess. It has therefore been abandoned as a
descriptive term in [I-D.ietf-6man-flow-3697bis]. It is only used in descriptive term in [I-D.ietf-6man-flow-3697bis]. It is only used in
the present document to explain why it has been abandoned. the present document to 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 case no assumption may be made)
and stateful models (in which the router has explicit knowledge). and stateful models (in which the router has explicit knowledge).
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 to forbid 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" is to be interpreted precisely - 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 [I-D.hu-flow-label-cases]. Those examples propose use
cases in which some or all of the following apply: cases in which 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
skipping to change at page 7, line 42 skipping to change at page 7, line 42
random number generator. Either approach will produce values which random number generator. Either approach will produce values which
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 it is made clear that stateless models are
also possible and are the recommended default. The specific text also possible and are the recommended default. The specific text
about requirements for stateful models has been reduced to a bare about requirements for stateful models has been reduced to a bare
minimum requirement that they do not interfere with the stateless minimum requirement that they do not interfere with the stateless
model. To enable stateless load distribution at any point in the model. To enable stateless load distribution at any point in the
Internet, a network using a stateful model should never export Internet, a node using a stateful model should never send packets
packets whose flow label values do not conform to a uniform whose flow label values do not conform to a uniform distribution.
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, even if they adopted a stateless method of flow routers that choose to do so, even if they adopted a stateless method
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
skipping to change at page 9, line 46 skipping to change at page 9, line 46
remarks are in [Partridge]. remarks are in [Partridge].
6. IANA Considerations 6. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
7. Acknowledgements 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 Fred Baker, Steve Valuable comments and contributions were made by Ran Atkinson, Fred
Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony Baker, Steve Blake, Remi Despres, Alan Ford, Fernando Gont, Brian
Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka Savola, Mark Haberman, Tony Hain, Joel Halpern, Chris Morrow, Thomas Narten, Pekka
Smith, Pascal Thubert, Iljitsch van Beijnum, and other participants Savola, Mark Smith, Pascal Thubert, Iljitsch van Beijnum, and other
in the 6man working group. participants in the 6man working group.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
8. Change log [RFC Editor: please remove] 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 draft-ietf-6man-flow-update-06: updated again to be in step with RFC
3697bis, 2011-05-11 3697bis, 2011-05-11
draft-ietf-6man-flow-update-05: updated again to be in step with RFC draft-ietf-6man-flow-update-05: updated again to be in step with RFC
3697bis, 2011-05-02 3697bis, 2011-05-02
draft-ietf-6man-flow-update-04: updated again to be in step with RFC draft-ietf-6man-flow-update-04: updated again to be in step with RFC
3697bis, 2011-03-13 3697bis, 2011-03-13
draft-ietf-6man-flow-update-03: updated to be in step with RFC draft-ietf-6man-flow-update-03: updated to be in step with RFC
skipping to change at page 11, line 21 skipping to change at page 11, line 26
November 2010. November 2010.
[I-D.hu-flow-label-cases] [I-D.hu-flow-label-cases]
Hu, Q. and B. Carpenter, "Survey of proposed use cases for Hu, Q. and B. Carpenter, "Survey of proposed use cases for
the IPv6 flow label", draft-hu-flow-label-cases-03 (work the IPv6 flow label", draft-hu-flow-label-cases-03 (work
in progress), February 2011. in progress), February 2011.
[I-D.ietf-6man-flow-3697bis] [I-D.ietf-6man-flow-3697bis]
Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", "IPv6 Flow Label Specification",
draft-ietf-6man-flow-3697bis-03 (work in progress), draft-ietf-6man-flow-3697bis-05 (work in progress),
May 2011. June 2011.
[I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching] [I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching]
Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)",
draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03 draft-martinbeckman-ietf-ipv6-fls-ipv6flowswitching-03
(work in progress), March 2007. (work in progress), March 2007.
[McGann05] [McGann05]
McGann, O. and D. Malone, "Flow Label Filtering McGann, O. and D. Malone, "Flow Label Filtering
Feasibility", European Conference on Computer Network Feasibility", European Conference on Computer Network
Defence , 2005. Defence , 2005.
 End of changes. 12 change blocks. 
25 lines changed or deleted 27 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/