draft-ietf-6man-flow-update-00.txt   draft-ietf-6man-flow-update-01.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: June 6, 2011 Univ. of Auckland Expires: July 14, 2011 Univ. of Auckland
S. Jiang S. Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
December 3, 2010 January 10, 2011
Update to the IPv6 flow label specification Update to the IPv6 flow label specification
draft-ietf-6man-flow-update-00 draft-ietf-6man-flow-update-01
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 existing specification in RFC 3697. incompatible with its existing 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 proposes changes to the the specification. This document describes and motivates proposed
specification in order to clarify it, making it clear what types of changes to the specification in order to clarify it, making it clear
usage are possible, and to introduce some additional flexibility. what types of usage are possible, and to introduce some additional
flexibility. It does not formally update RFC 3697.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 6, 2011. This Internet-Draft will expire on July 14, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Impact of current specification . . . . . . . . . . . . . . . 4 2. Impact of current specification . . . . . . . . . . . . . . . 4
3. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6 3. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 6
4. Proposed changes to specification . . . . . . . . . . . . . . 6 4. Proposed changes to specification . . . . . . . . . . . . . . 6
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 11 Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
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."
skipping to change at page 3, line 48 skipping to change at page 3, line 48
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 in more detail and The intention of this document is to explain this in more detail and
to propose changes to RFC 3697 intended to remove the uncertainties to propose changes to RFC 3697 intended to remove the uncertainties
and encourage active usage of the flow label. and encourage active usage of the flow label. It does not formally
update RFC 3697.
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 choice at this stage in the
deployment of IPv6, which uses conventional routing mechanisms like deployment of IPv6, which uses conventional routing mechanisms like
those used for IPv4. However, this rule also makes it impossible to 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. 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 encrypted pseudo-random flow label values could in fact consist of covert data.
data. If the flow label were to carry quality of service semantics, If the flow label were to carry quality of service semantics, then
then like the diffserv code point [RFC2474], it would not be like the diffserv code point [RFC2474], it would not be intrinsically
intrinsically trustworthy across domain boundaries. As a result, trustworthy across domain boundaries. As a result, some security
some security specialists believe that flow labels should be cleared specialists believe that flow labels should be cleared for safety.
for safety. These points must be considered when discussing the These points must be considered when discussing the immutability of
immutability of the flow label across domain boundaries. the flow label across domain boundaries.
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. If the word label are encoded with a specific semantic meaning. If the word
"alone" is overlooked, rule (c) has sometimes been interpreted to "alone" is overlooked, rule (c) has sometimes been interpreted to
forbid the use of the flow label as part of a hash used by load forbid the use of the flow label as part of a hash used by load
balancing mechanisms. balancing mechanisms.
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
skipping to change at page 8, line 5 skipping to change at page 8, line 5
3. A forwarding node MUST NOT change the flow label value in an 3. A forwarding node MUST NOT change the flow label value in an
arriving packet if it is non-zero. However, there are two arriving packet if it is non-zero. However, there are two
qualifications to this rule: qualifications to this rule:
1. Implementers are advised that forwarding nodes, especially 1. Implementers are advised that forwarding nodes, especially
those acting as domain border devices, might nevertheless be those acting as domain border devices, might nevertheless be
configured to change the flow label value in packets (e.g., configured to change the flow label value in packets (e.g.,
to a new pseudo-random value). This is undetectable, unless to a new pseudo-random value). This is undetectable, unless
some future version of IPsec authentication [RFC4302] some future version of IPsec authentication [RFC4302]
protects the flow label value. protects the flow label value.
2. A network domain MUST NOT forward packets outside the domain 2. To enable stateless load balancing at any point in the
whose flow label values are other than zero or pseudo-random. Internet, a network domain MUST NOT forward packets outside
Neither domain border egress routers nor intermediate the domain whose flow label values are other than zero or
routers/devices (using a flow-label, for example, as a part pseudo-random. Neither domain border egress routers nor
of an input-key for a load-balancing hash) can determine by intermediate routers/devices (using a flow-label, for
inspection that a value is not pseudo-random. Thus, if nodes example, as a part of an input-key for a load-balancing hash)
within a domain ignore the above recommendations to set zero can determine by inspection that a value is not pseudo-
or pseudo-random flow label values, then this would likely random. Therefore, if nodes within a domain ignore the above
result in undesirable operational implications (e.g., recommendations to set zero or pseudo-random flow label
congestion, reordering) for not only the inappropriately values, and such packets are forwarded outside the domain,
flow-labelled packets, but also well-behaved flow-labelled this would likely result in undesirable operational
packets, during forwarding at various intermediate devices. implications (e.g., congestion, reordering) for not only the
Thus, a domain must protect its peers by never exporting inappropriately flow-labelled packets, but also well-behaved
inappropriately labelled packets. flow-labelled packets, during forwarding at various
intermediate devices. Thus, a domain must protect its peers
by never exporting inappropriately labelled packets. This
document does not specify the method for enforcing this rule.
The suggested way to enforce it is that nodes within a domain
MUST NOT set the flow label to a non-zero and non-pseudo-
random number if the packet will leave the domain. If this
is not known to be the case, the border router will need to
change outgoing flow labels.
Note that the new rules above, taken together, allow a given Note that the new rules above, taken together, allow a given
network domain to include routers that set flow labels on behalf network domain to include routers that set flow labels on behalf
of hosts that do not do so. They also require that flow labels of hosts that do not do so. They also require that flow labels
exported to the Internet must always be either zero or pseudo- exported to the Internet must always be either zero or pseudo-
random. These changes replace rule (a) quoted in Section 1. random. These changes replace rule (a) quoted in Section 1.
However, there is no way to verify whether a flow label has been However, there is no way to verify whether a flow label has been
modified en route. No Internet-wide mechanism can depend modified en route. No Internet-wide mechanism can depend
mathematically on immutable flow labels. This leads to the mathematically on immutable flow labels. This leads to the
following formal rule: following formal rule:
skipping to change at page 10, line 14 skipping to change at page 10, line 19
7. IANA Considerations 7. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
8. Acknowledgements 8. 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 Fred Baker, Steve
Blake, Remi Despres, Fernando Gont, Brian Haberman, Tony Hain, Joel Blake, Remi Despres, Alan Ford, Fernando Gont, Brian Haberman, Tony
Halpern, Chris Morrow, Thomas Narten, Mark Smith, Pascal Thubert, Hain, Joel Halpern, Chris Morrow, Thomas Narten, Mark Smith, Pascal
Iljitsch van Beijnum, and other participants in the 6man working Thubert, Iljitsch van Beijnum, and other participants in the 6man
group. working group.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
9. Change log 9. Change log
draft-ietf-6man-flow-update-01: clarified that this is not a formal
update of RFC 3697, clarified text about domains exporting
inappropriate labels, 2011-01-10
draft-ietf-6man-flow-update-00: adopted as WG document at IETF 79, draft-ietf-6man-flow-update-00: adopted as WG document at IETF 79,
mutability rules adjusted according to WG discussion, 2010-12-03 mutability rules adjusted according to WG discussion, 2010-12-03
draft-carpenter-6man-flow-update-04: even more simplified according draft-carpenter-6man-flow-update-04: even more simplified according
to WG discussion, 2010-09-16 to WG discussion, 2010-09-16
draft-carpenter-6man-flow-update-03: futher simplified according to draft-carpenter-6man-flow-update-03: futher simplified according to
WG discussion, 2010-05-07 WG discussion, 2010-05-07
draft-carpenter-6man-flow-update-02: revised and simplified according draft-carpenter-6man-flow-update-02: revised and simplified according
skipping to change at page 12, line 35 skipping to change at page 13, line 4
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
KuiKe Building, No.9 Xinxi Rd., Huawei Building, No.3 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing Shang-Di Information Industry Base, Hai-Dian District, Beijing
P.R. China P.R. China
Email: shengjiang@huawei.com Email: shengjiang@huawei.com
 End of changes. 17 change blocks. 
40 lines changed or deleted 54 lines changed or added

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