IPv6 Working Group J. Rajahalme INTERNET-DRAFT Nokia <draft-rajahalme-ipv6-flow-label-00.txt> A. Conta Transwitch Expires: May 2002 November 2001 An IPv6 Flow Label Specification Proposal draft-rajahalme-ipv6-flow-label-00.txt Status of this memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract The IPv6 flow label field has been designed to allow eliminating protocol layer violations and the related problems from flow specific packet classifiers. This document provides an analysis of the current state of the IPv6 flow label field definition and proposes new text to be included in the next revision of the IPv6 specification. Rajahalme & Conta Expires: May 2002 [Page 1]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 Table of Contents 1. Introduction....................................................3 1.1 Overview.....................................................3 1.2 Problem Statement............................................3 1.3 Requirements.................................................4 1.4 Terminology..................................................4 2. Analysis of the RFC 2460 Flow Label Specification...............5 2.1 RFC 2460 Definition of the Flow Label........................5 2.1.1 Appendix A - Semantics and Usage of the Flow Label Field.5 2.2 Applicability of the RFC 2460 Flow Label Definition..........6 2.2.1 Lacking Support for RSVP WF Reservation Style............7 2.2.2 Too Restricted Flow Classifier...........................7 2.2.3 RSVP/Integrated Services Specific Rules..................8 2.2.4 Too Restricting Rule for Flow Label Value Re-use.........8 2.2.5 Unnecessary Rule for Flow Label Value Selection..........8 2.2.6 Ambiguity on the End-to-End Nature of the Flow Label.....8 3. New Flow Label Specification....................................9 3.1 Proposed Flow Label Text for IPv6 Specification..............9 3.2 Requirements for Flow State Establishment Methods............9 3.3 Implications of the New Definition..........................10 4. Conceptual Models Relating to the Flow Label...................12 4.1 About Packet Classification.................................12 4.2 Host Considerations for the Flow Label......................12 4.2.1 Choosing Flow Label Values..............................12 4.2.2 End-to-End Negotiation..................................13 4.2.3 Relation to the Other Packet Header Fields..............13 4.3 Router Considerations for the Flow Label....................13 4.3.1 Flow Label is End-to-End Immutable......................13 4.3.2 Flow Label Values Have No Known Properties..............14 4.3.3 Conceptual Model for Flow State.........................14 4.3.4 Classification..........................................14 Appendix A: Why no Flow Label Format?.............................16 Appendix B: Why no Pseudo-Random Values?..........................16 References.........................................................17 Security Considerations............................................18 Acknowledgements...................................................18 Author's Address...................................................18 Expiration Date....................................................18 Rajahalme & Conta Expires: May 2002 [Page 2]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 1. Introduction 1.1 Overview At the time when the IPv6 specification [RFC2460] was written, the requirements for flow label field usage were still evolving. The last several years of work in IETF provide new perspective and framework for the standardization of the IPv6 flow label. Also, the new charter of the IPv6 Working Group invites contributions to flow label standardization. A detailed problem statement is provided in section 1.2, and the goals for the flow label definition in 1.3. Section 2 provides an analysis of the current definition of the IPv6 flow label [RFC2460, RFC1809, RFC2205]. Section 3 details the new definition with its implications, with proposed text to be included in the next revision of the IPv6 specification. Finally, section 4 provides some useful background information on the topic. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.2 Problem Statement The IPv6 flow label field is designed to enable efficient classification of packets that should receive some flow-specific "special handling". Without the flow label, flow classification must be based on the transport header information (port numbers). Snooping in the transport header is problematic due to several factors: The transport header may be unavailable because of either fragmentation, or IPsec encryption. Usage of IPv6 extension headers will also make finding the transport header more expensive, even if it is available. Finally, reliance on the transport header information is a layer violation and hinders introduction of new transport layer protocols (e.g. SCTP). Current non-normative text in the Appendix A of [RFC2460] seems to be specific to the Integrated Services service model, unnecessarily restricting future work on defining new state establishment methods, but at the same time falls short in enabling flow label based classification of RSVP defined end-to-end flows in all cases. The current normative specification of the flow label field in [RFC2460] is providing inadequate guidance for different flow state establishment methods to be defined. Rajahalme & Conta Expires: May 2002 [Page 3]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 See section 2.2 for more detailed analysis of the problems with Appendix A definition. 1.3 Requirements The IPv6 protocol specification SHOULD only state generic rules, if any, governing the use of the flow label field by any flow state establishment method, and MUST enable co-existence of different flow state establishment methods in IPv6 hosts and routers. The space of possible flow state establishment methods SHOULD NOT be restricted to end-to-end signaling protocols. For example, the IPv6 protocol specification should allow for future definition of administratively provisioned flows (automated through e.g. COPS, or manual configuration). The text in the IPv6 protocol specification SHOULD leave the specifics arising from different flow state establishment methods, and different models of using the flow label to the documents that specify those methods and models. The models for the use of the flow label and their specific state establishment methods should enable eliminating the layer violations in flow specific packet classifiers, thus facilitating evolution of the higher protocol layers independent of the specific flow state establishment method. The semantics-free nature of the flow label, when out of context of the source and destination addresses, SHOULD be maintained. Changes to the current specification SHOULD be kept minimal, and backwards compatibility SHOULD be maintained. 1.4 Terminology Classifier An entity which selects packets based on the content of packet headers according to defined rules. Control plane Part of the router taking care of router control functions, such as routing protocols and flow set-up signaling protocols. Controls the functions of the forwarding plane. Forwarding plane Part of the router receiving and forwarding user packets; also known as "fast path". Multi-Field (MF) A classifier which selects packets based on Classifier the content of some arbitrary number of header fields. Rajahalme & Conta Expires: May 2002 [Page 4]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 2. Analysis of the RFC 2460 Flow Label Specification 2.1 RFC 2460 Definition of the Flow Label The IPv6 Flow Label is defined in [RFC2460] as a 20 bit field in the IPv6 header which may be used by a source to label sequences of packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. The Flow Label aspect of IPv6 is stated to be "still experimental and subject to change". The only rule set for the flow label in the main body of the [RFC2460] is that if the Flow Label field use is not supported, it is set to zero when originating the packet, passed on unchanged when forwarding the packet, and ignored when receiving the packet. 2.1.1 Appendix A - Semantics and Usage of the Flow Label Field The characteristics of IPv6 flows and flow labels, and the rules that govern the flow label functions are further defined in [RFC2460] Appendix A (non-normative text). Background information on the documented semantics can be found in [RFC1809]. According to [RFC2460], the nature of the special handling might be conveyed to the routers by a control protocol, such as a resource reservation protocol, or by information within the flow's packets themselves, e.g., in a hop-by-hop option. For the purpose of this document the rules from the Appendix A of [RFC2460] are rearranged as follows: (a) A flow is uniquely identified by the combination of a source address and a non-zero flow label. (b) Packets that do not belong to a flow carry a flow label of zero. (c) A flow label is assigned to a flow by the flow's source node. (d) New flow labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow Label field suitable for use as a hash key by routers, for looking up the state associated with the flow. (e) All packets belonging to the same flow must be sent with the same source address, destination address, and flow label. (f) If packets of a flow include a Hop-by-Hop Options header, then they all must be originated with the same Hop-by-Hop Options Rajahalme & Conta Expires: May 2002 [Page 5]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 header contents (excluding the Next Header field of the Hop-by- Hop Options header). (g) If packets of a flow include a Routing header, then they all must be originated with the same contents in all extension headers up to and including the Routing header (excluding the Next Header field in the Routing header). (h) The routers or destinations are permitted, but not required, to verify that these conditions are satisfied. If a violation is detected, it should be reported to the source by an ICMP Parameter Problem message, Code 0, pointing to the high-order octet of the Flow Label field (i.e., offset 1 within the IPv6 packet). (i) The maximum lifetime of any flow-handling state established along a flow's path must be specified as part of the description of the state-establishment mechanism, e.g., the resource reservation protocol or the flow-setup hop-by-hop option. (j) A source must not reuse a flow label for a new flow within the maximum lifetime of any flow-handling state that might have been established for the prior use of that flow label. When a node stops and restarts (e.g., as a result of a "crash"), it must be careful not to use a flow label that it might have used for an earlier flow whose lifetime may not have expired yet. 2.2 Applicability of the RFC 2460 Flow Label Definition As stated in [RFC2460], the motivation for the Flow Label field is to request special handling for the packets belonging to a flow. The flow label value itself has no semantics, but it can be used by routers to determine the appertaining of a packet to a certain flow (classification), and to find the state containing the definition for the "special handling" admitted for that flow. The exact nature of the "special handling" is defined through means other than the flow label itself. At the time of the definition of the rules in [RFC2460] the major method for defining the "special handling" by routers was the resource reservation signaling protocol (RSVP) of the "Integrated Services" architecture [RFC1633, RFC2205]. With the hindsight it seems that some of the flow label rules set in [RFC2460] Appendix A are quite specific to the Integrated Services model, and block the way forward for definition of other flow state establishment methods. Some specific points are raised in the following subsections. Rajahalme & Conta Expires: May 2002 [Page 6]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 2.2.1 Lacking Support for RSVP WF Reservation Style The Wildcard-Filter (WF) reservation style allows the RSVP session destination to reserve resources for transmission by any of the senders of the RSVP session. All the state that can be utilized for packet classification with the WF-style session is in the RSVP Session object, since the WF-style reservations have no Filter Specs [RFC2205]. Currently, for end-to-end flows, the Session object can only be specified in the terms of the destination address, transport protocol identifier (Id), and the destination port number. This results in layer violation in packet classification with all the identified problems (inefficiency, fragmentation, IPsec) in spite of using the flow label Filter Specs. For WF-style sessions this situation could be remedied with a new type (or "C-Type") of a Session object, where only the destination IPv6 address and the flow label are specified (quite much like the Session object defined in [RFC3175] for aggregated flows). For other flow styles it might be more appropriate to have the session object to specify the destination address only, and have each Filter Spec to contain the source's flow label. The problem with the current flow label rules is that if the flow label is set according to information received from the destination (e.g. through the Session Announcement Protocol (SAP)), it becomes possible that the same flow label value should be used for two different flows from the same source simultaneously. This can happen if the source is taking part to two different sessions with different destinations, and the flow label number generators in the destinations happen to pick up the same number. This is in direct contrast with the rule (a) above. Requesting the destination to pick another flow label would be infeasible, if the RSVP sessions already have other senders. 2.2.2 Too Restricted Flow Classifier The rule (a) states that a flow is uniquely identified by the source address and the flow label. Rule (e) states that all the packets in the flow must also have the same destination address. This means that the source may not use the same flow label value for flows to two different destination addresses. As stated above, this is in violation with RSVP model, but also is unnecessarily hindering introduction of other flow state establishment methods. Rajahalme & Conta Expires: May 2002 [Page 7]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 2.2.3 RSVP/Integrated Services Specific Rules The rules (f) and (g) state that any hop-by-hop or routing headers must be the same for all packets in a flow. This matches the Intserv practice of nailing down the path for the flow. The intent has probably been to enable the router to by-pass next-hop look-up and to supply pre-processed routing header contents for the packets in the flow. These rules are clearly specific to the RSVP flow state establishment method, and should not be required of flows in general. The RSVP flow state establishment method would still mandate these rules for Integrated Services flows. The forwarding path of a IntServ capable router would also be able to enforce these rules for IntServ flows. 2.2.4 Too Restricting Rule for Flow Label Value Re-use The rule (j) defines guard periods on re-use of flow label values. This is too restrictive even in the case of Intserv flows. There would be no harm in a (rebooted) node reusing a flow label value, as the RSVP signaling would enable the routers to flush any old state for the same flow classifier. 2.2.5 Unnecessary Rule for Flow Label Value Selection Finally, it has been concluded that routers can't actually rely on the random distribution of the flow label values as required by the rule (d). In practice routers MUST be able to utilize algorithms that do not depend on the statistical distribution of the flow label values. Therefore, the rule (d) SHOULD be relaxed for flow labels in general. However, specific flow state establishment methods MAY still use pseudo-random numbers as flow label values. 2.2.6 Ambiguity on the End-to-End Nature of the Flow Label The RSVP/Intserv usage calls for end-to-end immutable flow classifier. At the same time, the flow label field has been left unprotected by the Authentication Header (AH) computation. Rajahalme & Conta Expires: May 2002 [Page 8]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 3. New Flow Label Specification The section proposes new text to be included in the IPv6 Specification. The section 3.1 is intended to provide a new version of the text in [RFC2460] section 6. The text in sections 3.2 and 3.3 could go to different parts of the IPv6 specification. 3.1 Proposed Flow Label Text for IPv6 Specification The 20-bit Flow Label field in the IPv6 header MAY be used by a source to label sequences of packets for which it requests special handling. A non-zero flow label indicates that the IPv6 packet is labeled. IPv6 nodes receiving a labeled IPv6 packet can use the Source Address, Flow Label, Destination Address triplet to classify the packet to a certain flow. A flow is given some specific treatment based on the flow state established on a set of IPv6 routers. The nature of the specific treatment and the methods for the flow state establishment are out of scope for this specification. The host MUST keep track of the Flow Label values in use to avoid trying to establish conflicting flow state. The Flow Label value, when set, is end-to-end immutable, but MAY be temporarily changed, if so required by the flow state establishment method. Hosts or routers that do not support the functions of the Flow Label field MUST 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. 3.2 Requirements for Flow State Establishment Methods The following MUST be considered by all flow state establishment methods: (1) A flow is uniquely identified by the combination of the source address, non-zero flow label, and the destination address. (2) All flow state MUST be created with a flow state establishment method. All such methods are out of scope for this specification. (3) Flow state with the flow label value zero SHALL NOT be created. (4) Host implementations SHOULD keep track of the flow label values used by any flow establishment methods from a local source address to all used destination addresses. (5) A non-zero flow label value is end-to-end immutable, but can be changed if the established flow state so requires. Rajahalme & Conta Expires: May 2002 [Page 9]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 (6) The maximum lifetime of any established flow state must be specified as part of the flow state establishment method. (7) A source MAY reuse a flow label value any time, unless otherwise specified by the flow state establishment method for the new flow. (8) All flow state establishment methods MUST allow for the case where a router determines the offered flow to be in conflict with flow state created with an other flow state establishment method. If a conflict is detected, it SHOULD be reported by the flow state establishment method. 3.3 Implications of the New Definition - The same flow label value can be used for different flows with the same source addresses, provided that the destination addresses are different (1). - Each (source address, flow label, destination address) triplet can uniquely determine a flow and the relevant flow state, if any (1). However, multiple different triplets MAY determine the same flow, and refer to the same flow state, depending on how the flow was defined with the flow state establishment method. - The only requirement for a flow label value used for the flow is that it MUST be non-zero (3). However, specific flow state establishment methods MAY use (non-zero) pseudo-random numbers as flow label values. - A non-zero flow label value is guaranteed to be received by the destination. If the source sends the packet with a zero flow label value, a router in the network MAY set the flow label value to a non-zero value (5). - A non-zero flow label value MAY be changed in transit by a router, but the original value MUST be restored before the packet leaves the domain of the flow state establishment method defining such a temporary change (5). - Flow state lifetime may also be indefinite, if so specified by a flow state establishment method. The method MUST also provide the means to guarantee no dangling state (6). - If new flow state is signaled through a certain path, the routers can flush any old state they might have, and install the new flow state (7). - Some host implementations of flow state establishment methods might be impractical or impossible to synchronize in a host environment (e.g., the host OS may implement one method in the kernel with no interface to user space, where another state establishment method Rajahalme & Conta Expires: May 2002 [Page 10]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 is residing). Therefore the routers MUST be able to return an error as part of the flow establishment response, if the offered flow is deemed conflicting with a flow state created by another flow establishment method. Local policy at the router MAY set a precedence between the flow establishment methods, and MAY be able to cancel a lower precedence flow in favor of the new flow (8). Rajahalme & Conta Expires: May 2002 [Page 11]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 4. Conceptual Models Relating to the Flow Label 4.1 About Packet Classification This section briefly summarizes issues relating to packet classification relating to the use of the flow label. Packet classification happens in a context of an agreement ("contract") between a "customer" and a "provider". The only fields in the IP packet header that the provider can utilize in mapping a packet to a specific customer's contract are the source and destination address fields. We call this "customer classification". Other information, such as incoming link, can also be used to map packets to the customer's contract. In the context of the contract governing the packet, the packet can be further classified to a flow. The packet filter rules for the flow classifiers in the network are part of the flow state. The flow state also specifies what kind of "special handling" the packets of the flow should get, and what are the flow traffic parameters (e.g. bandwidth, delay, etc.) and contains the flow usage counters. It should be noted that the actual values of the header fields specified in a flow classifier are immaterial to the network operator - the operator assigns no specific semantics to any of the fields. Actual implementations will likely combine the "customer classification" and flow classification into one filter rule, but the conceptual separation between the two is essential. Usage of the IPv6 flow label greatly simplifies the filter rules, as the classification can be done on the basis of the IP addresses and the flow label alone. A packet classified to a flow can be further mapped to a Behavior Aggregate (BA), enabling other routers in the network bypass flow classification. The Differentiated Services Code Point (DSCP) field is used to identify the selected BA [RFC2475]. 4.2 Host Considerations for the Flow Label 4.2.1 Choosing Flow Label Values A specific flow state establishment method MAY set requirements on the flow label values to be used. In any case, the host implementation SHOULD keep track of the actual flow label values being used between a local source address and any destination addresses. The same facility keeping track of the flow label values SHOULD be utilized to check whether the flow label value chosen by Rajahalme & Conta Expires: May 2002 [Page 12]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 the flow state establishment method is currently in use or not between the given source and destination address pair, and SHOULD also return a flow label value assigned by host implementation specific algorithm, if the flow state establishment method did not specify any specific value. 4.2.2 End-to-End Negotiation Flow label values for flows SHOULD be included as part of any end-to- end signaling dealing with the flow, e.g. RSVP for resource reservation, or SIP/SDP for end-to-end session establishment. RSVP usage is analogous to the familiar MF classifier, but now the flow label replaces the need to specify the transport protocol and port numbers for the flow classifier. In the case of SIP either the source or the destination could have a preference for the flow label value to be used. For example, the destination could have an agreement with its access provider effecting flow state for "special handling" for all packets marked with a certain flow label value towards the destination. Therefore the source SHOULD honor the destination's request to mark the packets with the flow label value specified. 4.2.3 Relation to the Other Packet Header Fields A flow can be uniquely identified by the (source address, flow label, destination address) triplet. Any possible constraints for the rest of the IPv6 header fields or extension headers are to be specified by the flow state establishment method defining the flow semantics. Flow state establishment methods SHOULD include the Mobile IP Home Addresses of the source and the destination in the state establishment process, if available. This enables avoiding state duplication on fixed portions of the path when either end changes its Care-of Address. 4.3 Router Considerations for the Flow Label 4.3.1 Flow Label is End-to-End Immutable Routers MAY NOT change the end-to-end flow label value, unless explicitly so requested by the flow state establishment method. The flow state establishment method MUST be able to tell the destination which value to expect on the received packets. Also, an administrative domain MAY internally change the flow label value, but it SHALL restore the original value on domain egress. Intra-domain modification MUST NOT interfere with inter-domain flow Rajahalme & Conta Expires: May 2002 [Page 13]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 set-up signaling carrying the original end-to-end immutable flow label value. 4.3.2 Flow Label Values Have No Known Properties The router MUST NOT assume any specific property on the flow label values assigned by hosts. Router performance SHOULD NOT be dependent on the overall distribution of the flow label values of the established flows. 4.3.3 Conceptual Model for Flow State This section lays out a simple conceptual model for minimal flow state in the router forwarding plane. Actual implementations may choose any implementation methods they like. Router forwarding plane needs to maintain at least the following information (flow state) for each defined flow: Source Address, The triplet identifying the flow. Flow Label, Destination Address Flow Accounting Counter of the number of bytes or packets of Information the flow data forwarded. The router control plane can see from this if the flow has been active (since it was last checked), and how much data has been forwarded (useful for accounting purposes). Forwarding Defines the actual "special handling" the flow Treatment packets are subjected to. The flow state is created by the router control plane via a flow state establishment method. The flow state establishment method definitions are out of scope for this specification. Stale flow state is deleted by the router control plane after the flow expires, or when a new flow state overriding the old is created. The flow state can also be explicitly deleted via the flow state establishment method. 4.3.4 Classification Packet classification is done by the router forwarding plane on the flat 20-bit flow label, and the source and destination address fields. Rajahalme & Conta Expires: May 2002 [Page 14]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 When matching flow state has been found, the router will be able to update the Flow Accounting Information and forward the packet with the "special handling" as specified by the Forwarding Treatment in the flow state. If flow state can not be located for a packet it is forwarded as if the flow label was zero, but the flow label is left intact. No flow state is maintained for unknown flows. Rajahalme & Conta Expires: May 2002 [Page 15]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 Appendix A: Why no Flow Label Format? The choice to not introduce any internal format for the flow label represents the "minimal modification" policy and is intended to ease the process of the acceptance of this specification by the IPv6 community. This is also in line with the removal of any "flags" from the IPv6 main header design, and the recent deprecation of the term "format prefix" in conjunction of IPv6 addresses. In the same way as next-hop lookup should function independent of any "format prefixes" or administrative boundaries in the IPv6 addresses, the flow label lookup should remain independent of any possible internal structure for the flow label values themselves. Abstaining from eating in to the 20 bits of the flow label also keeps maximal possibilities open for future refinement of this specification. Appendix B: Why no Pseudo-Random Values? [RFC2460] motivates the requirement for pseudo random flow label field with easing the hash key computation in routers doing flow classification. Hashing has to deal with the problem of large hash buckets due to unbalanced hash key distribution. If the router trusts on the hosts to generate good hash keys, it places itself on the mercy of the hosts. A not-so-good generator in any widely used host platform may become problematic for the router. In recent years the hardware implementations of the classifiers have advanced, and schemes like search trees and Content Addressable Memory (CAM) are widely used for classification. It is the authors' view that the flow label specification SHOULD NOT favor any individual classification implementation strategy, especially when it provides no functional value for the purpose of the flow label itself, and seems to hinder future use of the flow label for non- signaled flow state establishment methods. Hash implementations in routers can compute a hash key over the (source address, flow label, destination address) triplet. Rajahalme & Conta Expires: May 2002 [Page 16]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 References [RFC2460] S. Deering, R. Hinden, "Internet Protocol Version 6 Specification", RFC 2460, December 1998. [RFC1809] C. Partridge, "Using the Flow Label Field in IPv6", RFC 1809, June 1995. [RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [RFC1633] R. Braden, D. Clark, S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin S., "Resource Reservation Protocol (RSVP) Version 1 Functional Specification", RFC 2205, September 1997. [RFC3175] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [Conta] A. Conta, B. Carpenter, "A proposal for the IPv6 Flow Label Specification", Internet Draft <draft-conta-ipv6- flow-label-02.txt>, July 2001, expires January 2002, Work in progress. Rajahalme & Conta Expires: May 2002 [Page 17]
INTERNET-DRAFT draft-rajahalme-ipv6-flow-label-00.txt November 2001 Security Considerations Anything that facilitates flow classification also increases the vulnerability to traffic analysis. The use of flow label in general enables flow classification also in the presence of ESP headers. This allows the transport header values to remain confidential, which may lessen the possibilities for some forms of traffic analysis. Acknowledgements The discussion on the topic in the IPv6 WG mailing list has been instrumental for the definition of this specification. The authors want to thank Steve Blake, Jim Bound, Brian Carpenter, Francis Dupont, Robert Elz, Tony Hain, Christian Huitema, Frank Kastenholz, Hesham Soliman, Michael Thomas for their tireless contributions on the list. Charles Perkins reviewed the text and provided many helpful comments. Author's Address Jarno Rajahalme Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP, Finland E-mail: jarno.rajahalme@nokia.com Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484 USA Email: aconta@txc.com Expiration Date This memo is filed as <draft-rajahalme-ipv6-flow-label-00.txt> and expires in May 2002. Rajahalme & Conta Expires: May 2002 [Page 18]