RFC 3697

IPv6 Flow Label Specification

📅 published March 2004, from ietf

RFC 3697: IPv6 Flow Label Specification 🦋

Okay bestie, here's the title block tea ☕:

  • RFC number: 3697
  • Title: IPv6 Flow Label Specification
  • Authors: J. Rajahalme (Nokia), A. Conta (Transwitch), B. Carpenter (IBM), S. Deering (Cisco)
  • Category: Standards Track
  • Date: March 2004
  • Obsoletes / updates: the header doesn't list anything it obsoletes or updates ✨

Status of this Memo 📜

So this doc is an Internet standards track protocol for the Internet community, and it's basically inviting everyone to discuss and suggest improvements 🫶. If you want to know where this protocol stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited, so share away 💖.

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 🔮

This doc specifies the IPv6 Flow Label field, plus the minimum requirements for IPv6 source nodes that label flows, IPv6 nodes that forward labeled packets, and flow state establishment methods 🧚. Even when examples of possible uses of flow labeling get mentioned, the more detailed requirements for specific use cases are out of scope here, so don't look for them in this doc 🙈.

The whole point of the Flow Label field is that it makes IPv6 flow classification efficient, because classifiers only need to look at IPv6 main header fields that sit in fixed positions. Iconic, honestly 👑.

1. Introduction ✨

Okay so a flow is a sequence of packets sent from one particular source to one particular destination (unicast, anycast, or multicast), and the source wants to label that sequence as a flow 🦋. A flow could be all the packets in one specific transport connection, or a media stream. BUT a flow is not necessarily 1:1 mapped to a transport connection, so don't assume they're the same thing 🙅‍♀️.

Traditionally, flow classifiers were based on the 5-tuple: source and destination addresses, ports, and the transport protocol type. Here's the drama though 😭. Some of those fields might be unavailable because of fragmentation or encryption, or finding them past a chain of IPv6 option headers might be inefficient. Also, if classifiers only depend on IP layer headers, then introducing alternative transport layer protocols later will be way easier 💅.

The usage of the 3-tuple of the Flow Label plus the Source and Destination Address fields enables efficient IPv6 flow classification. Only IPv6 main header fields in fixed positions get used, and that's the whole slay 🔥.

The minimum level of IPv6 flow support is labeling the flows. IPv6 source nodes that support flow labeling MUST be able to label known flows (for example, TCP connections or application streams), even if the node itself wouldn't need any flow-specific treatment 🌈. Doing this enables load spreading and receiver oriented resource reservations, for example ✨. Node requirements for flow labeling are in section 3, so go check that next 💖.

Specific flow state establishment methods and the related service models are out of scope for this spec. BUT the generic requirements that let different methods co-exist in IPv6 nodes are set out in section 4 🎀. The scaling characteristics (like which nodes are involved in state establishment, how much state they keep, and the state growth function) will depend on the particular service models 🍓.

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 BCP 14, RFC 2119 [KEYWORDS]. Bookmark that one, it matters 💜.

2. IPv6 Flow Label Specification 🎀

The 20-bit Flow Label field in the IPv6 header [IPv6] is what a source uses to label packets of a flow 🦋. A Flow Label of zero means the packet isn't part of any flow 🫧. Packet classifiers use the triplet of Flow Label, Source Address, and Destination Address fields to figure out which flow a packet belongs to 🧐. Packets get processed in a flow-specific way by the nodes that have been set up with flow-specific state 🔥. The nature of that specific treatment and the methods for setting up flow state are out of scope for this spec, so we're leaving that for another day 🙈.

The Flow Label value set by the source MUST be delivered unchanged to the destination node(s). No edits allowed, periodt 💅.

IPv6 nodes MUST NOT assume any mathematical or other properties of the Flow Label values that source nodes assign 🙅‍♀️. Router performance SHOULD NOT depend on how the Flow Label values are distributed 📊. Especially, the Flow Label bits alone make poor material for a hash key. Bestie, do NOT hash on these bits by themselves 💀.

Nodes keeping dynamic flow state MUST NOT assume that packets arriving 120 seconds or more after the previous packet of a flow still belong to the same flow 🕰️. The exception: a flow state establishment method in use defines a longer flow state lifetime, or the flow state has been explicitly refreshed within the lifetime duration ✨.

Using the Flow Label field does not necessarily signal any requirement on packet reordering 🌀. Especially, the zero label does not imply that significant reordering is acceptable. Zero doesn't mean "reorder away" 🙃.

If an IPv6 node is not providing flow-specific treatment, it MUST ignore the field when receiving or forwarding a packet 🫶.

3. Flow Labeling Requirements 🏷️

So to enable Flow Label based classification, source nodes SHOULD assign each unrelated transport connection and application data stream to a new flow 🧁. The source node MAY also take part in flow state establishment methods that result in assigning certain packets to specific flows 🦋. A source node that does not assign traffic to flows MUST set the Flow Label to zero 💜.

To let applications and transport protocols define which packets make up a flow, the source node MUST provide means for those applications and transport protocols to specify the Flow Label values to be used with their flows 🎀. Using those means is subject to appropriate privileges (see section 5.1) 🔐. The source node SHOULD be able to select unused Flow Label values for flows that aren't requesting a specific value 🌈.

A source node MUST ensure that it does not unintentionally reuse Flow Label values it is currently using or has recently used when creating new flows ⚠️. Flow Label values previously used with a specific pair of source and destination addresses MUST NOT be assigned to new flows with the same address pair within 120 seconds of the termination of the previous flow ⏳. The source node SHOULD provide the means for applications and transport protocols to specify quarantine periods longer than the default 120 seconds for individual flows 🍓.

To avoid accidental Flow Label value reuse, the source node SHOULD select new Flow Label values in a well-defined sequence (for example, sequential or pseudo-random) 🔢. It should also use an initial value that avoids reusing recently used Flow Label values each time the system restarts 🔄. The initial value SHOULD be derived from a previous value stored in non-volatile memory. Without that history, a randomly generated initial value SHOULD be used, produced by techniques that have good randomness properties [RND] 🎲. Randomness with good vibes 🌸.

4. Flow State Establishment Requirements 🧚

To enable flow-specific treatment, flow state needs to be established on all or a subset of the IPv6 nodes on the path from the source to the destination(s) 🛤️. The methods for state establishment, as well as the models for flow-specific treatment, will be defined in separate specifications 📚.

To enable co-existence of different methods in IPv6 nodes, the methods MUST meet the following basic requirements:

(1) The method MUST provide the means for flow state clean-up from the IPv6 nodes providing the flow-specific treatment. Signaling based methods where the source node is involved are free to specify flow state lifetimes longer than the default 120 seconds 🧹.

(2) Flow state establishment methods MUST be able to recover from the case where the requested flow state cannot be supported 🔄. Resilience is everything 💪.

5. Security Considerations 🔐

This section considers security issues raised by using the Flow Label. The big ones are the potential for denial-of-service attacks, and the related potential for theft of service by unauthorized traffic (Section 5.1) 🚨. Section 5.2 covers using the Flow Label in the presence of IPsec, including how it interacts with IPsec tunnel mode and other tunneling protocols 🛡️.

We also note that inspection of unencrypted Flow Labels may allow some forms of traffic analysis by revealing some structure of the underlying communications 👀. Even if the flow label were encrypted, its presence as a constant value in a fixed position might assist traffic analysis and cryptoanalysis 💀. Be careful out there, bestie 🫣.

5.1. Theft and Denial of Service

okay so the Flow Label gets used to decide which traffic gets special treatment, and that decision is based on the IP addresses and the Flow Label value in the IPv6 header 😭. That means an attacker could try to get better service by editing the IPv6 header or injecting packets with fake addresses and/or labels 🦋. If they push it far enough, theft of service turns into denial of service, because the modified or injected traffic can eat up the resources needed to forward it and everyone else's traffic too 💀. A curiosity here is that if someone launched a DoS attack against a given Flow Label (or a set of them), traffic carrying an affected Flow Label might end up with worse-than-best-effort performance 🙈.

Also, nodes usually don't verify how IP headers get treated, so there's no guarantee that a node's flow labels were set according to the recommendations in this document 💅. So any assumptions the network makes about header fields like flow labels should be limited to upstream nodes that are explicitly trusted 🫶.

Flows are identified by the 3-tuple of the Flow Label plus the Source and Destination Address, so the risk of theft or DoS from the Flow Label is closely tied to the risk from address spoofing 🌸. Someone who can forge an address can probably forge a label too, and the other way around ✨.

There are two different issues here: spoofing only the Flow Label, and spoofing the whole 3-tuple, Source and Destination Address included 👑.

Spoofing only the Flow Label can happen inside a node that is using or transmitting the correct source address 🎀. Being able to spoof a Flow Label usually means you can also forge an address, but in lots of cases spoofing an address isn't interesting to the spoofer, especially if they're going for theft of service instead of denial of service 🧚.

Spoofing the whole 3-tuple can be done by a host that isn't subject to ingress filtering [INGR] or by an intermediate router 🍓. Because of how it works, it's usually only useful for denial of service 😤. Without ingress filtering, pretty much any third party could start an attack like this 💀.

With ingress filtering in place, forging a non-zero Flow Label on packets that started with a zero label, or modifying or clearing a label, could only happen if an intermediate system like a router got compromised, or through some other man-in-the-middle attack 🕵️‍♀️. Even then, the risk is limited to traffic getting better or worse quality of service than intended 🌈. For example, if Flow Labels get altered or cleared at random, flow classification stops working as intended, and the altered packets get default treatment 🧃. If a complete 3-tuple is forged, the altered packets get classified into the forged flow and receive that flow's quality of service, which creates a denial of service attack that's subtly different from one where only the addresses are forged 🦄. Since it's limited to a single flow definition, for instance to a limited amount of bandwidth, this kind of attack is more targeted and works at a finer granularity than a normal address-spoofing attack 🎯.

Since flows are identified by the complete 3-tuple, ingress filtering [INGR] will, as noted above, cut down part of the risk 🛡️. If a packet's source address is validated by ingress filtering, you can have some trust that the packet didn't pass through a compromised router, to the extent that ISP infrastructure can be trusted 💖. But that doesn't guarantee that some other form of man-in-the-middle attack hasn't happened 😬.

Only applications with the appropriate privilege on a sending host are entitled to set a non-zero Flow Label 👑. How this works depends on the operating system ⭐. Related policy and authorization mechanisms may also be needed. For example, on a multi-user host, only some users might be entitled to set the Flow Label 🧑‍🤝‍🧑. Those authorization issues are outside the scope of this specification 🫠.

5.2. IPsec and Tunneling Interactions

The IPsec protocol, defined in [IPSec, AH, ESP], doesn't include the IPv6 header's Flow Label in any of its cryptographic calculations 🔐. (In tunnel mode, it's the outer IPv6 header's Flow Label that gets left out.) So if a network node modifies the Flow Label, it has no effect on IPsec end-to-end security, because it can't make any IPsec integrity check fail 🙌. As a result, IPsec doesn't give any defense against an adversary modifying the Flow Label, which is a man-in-the-middle attack 😭.

IPsec tunnel mode does provide security for the encapsulated IP header's Flow Label ✨. A tunnel mode IPsec packet has two IP headers: an outer header supplied by the tunnel ingress node, and an encapsulated inner header supplied by the packet's original source 🎀. When an IPsec tunnel passes through nodes that do flow classification, those intermediate nodes work with the Flow Label in the outer header 🦋. At the tunnel egress node, IPsec processing removes the outer header and forwards the packet (if required) using the inner header 🚀. The IPsec protocol requires that the inner header's Flow Label not be changed by this decapsulation processing, so that changes to the label can't be used to launch theft or denial of service attacks across an IPsec tunnel endpoint 🛡️. This document doesn't change that requirement. In fact, it forbids changes to the Flow Label 🙅‍♀️.

When IPsec tunnel egress decapsulation includes a sufficiently strong cryptographic integrity check of the encapsulated packet (with "sufficiently" decided by local security policy), the tunnel egress node can safely assume that the inner header's Flow Label has the same value it had at the tunnel ingress node 💜.

This analysis and its implications apply to any tunneling protocol that performs integrity checks 🌸. And of course, any Flow Label set in an encapsulating IPv6 header is subject to the risks described in the previous section 😅.

5.3. Security Filtering Interactions

The Flow Label doesn't get rid of the need for packet filtering based on headers past the IP header 🙃. That's still needed if it's deemed necessary for security reasons on nodes like firewalls or filtering routers 🧱.

6. Acknowledgements 🫶

The discussion on this topic in the IPv6 WG mailing list was super important for defining this specification 💌. The authors want to thank Ran Atkinson, Steve Blake, Jim Bound, Francis Dupont, Robert Elz, Tony Hain, Robert Hancock, Bob Hinden, Christian Huitema, Frank Kastenholz, Thomas Narten, Charles Perkins, Pekka Savola, Hesham Soliman, Michael Thomas, Margaret Wasserman, and Alex Zinin for their contributions 👑✨.

7. References 📚

7.1. Normative References

[IPv6]      Deering, S. and R. Hinden, "Internet Protocol Version 6
            Specification", RFC 2460, December 1998.

[KEYWORDS]  Bradner, S., "Key words for use in RFCs to indicate
            requirement levels", BCP 14, RFC 2119, March 1997.

[RND]       Eastlake, D., Crocker, S. and J. Schiller, "Randomness
            Recommendations for Security", RFC 1750, December 1994.

7.2. Informative References

[AH]        Kent, S. and R. Atkinson, "IP Authentication Header", RFC
            2402, November 1998.

[ESP]       Kent, S. and R. Atkinson, "IP Encapsulating Security
            Payload (ESP)", RFC 2406, November 1998.

[INGR]      Ferguson, P. and D. Senie, "Network Ingress Filtering:
            Defeating Denial of Service Attacks which employ IP
            Source Address Spoofing", BCP 38, RFC 2827, May 2000.

[IPSec]     Kent, S. and R. Atkinson, "Security Architecture for the
            Internet Protocol", RFC 2401, November 1998.

Authors' Addresses 🖊️

Jarno Rajahalme
Nokia Research Center
P.O. Box 407
FIN-00045 NOKIA GROUP,
Finland

EMail: jarno.rajahalme@nokia.com


Alex Conta
Transwitch Corporation
3 Enterprise Drive
Shelton, CT 06484
USA

EMail: aconta@txc.com


Brian E. Carpenter
IBM Zurich Research Laboratory
Saeumerstrasse 4 / Postfach
8803 Rueschlikon
Switzerland

EMail: brc@zurich.ibm.com


Steve Deering
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧾

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💕

Funding for the RFC Editor function is currently provided by the Internet Society ✨

📦 where this page comes from