diff options
Diffstat (limited to 'doc/rfc/rfc6436.txt')
| -rw-r--r-- | doc/rfc/rfc6436.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc6436.txt b/doc/rfc/rfc6436.txt new file mode 100644 index 0000000..521846f --- /dev/null +++ b/doc/rfc/rfc6436.txt @@ -0,0 +1,731 @@ + + + + + + +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] + |