RFC 6294

Survey of Proposed Use Cases for the IPv6 Flow Label

📅 published June 2011, from ietf

RFC 6294: Survey of Proposed Use Cases for the IPv6 Flow Label 🎀

Okay bestie, this one is a whole vibe. It's RFC 6294, written by Q. Hu and B. Carpenter at the University of Auckland 🇳🇿. It's Informational, so it's not a Standards Track spec. It was an independent submission, published in June 2011, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's not replacing or amending any other RFC. ✨

Abstract

okay so the IPv6 header has a flow label in every packet, but nobody really uses it 🙈 This paper explains the flow label standard and the implementation problems it creates. Then it goes through a bunch of published proposals for using the flow label and shows that most of them don't match the standard 💀 It also briefly reviews ways to fix that, and asks whether the standard itself should be revised. Main character research energy 💅

Status of This Memo

This document is not an Internet Standards Track specification. It's just published for information 🧚

This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no statement about how valuable it is for implementation or deployment. Documents the RFC Editor approves for publication aren't candidates for any level of Internet Standard. See Section 2 of RFC 5741 for the details 📚

Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc6294 🦋

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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🫶

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  1.1.  A Brief History of the Flow Label  . . . . . . . . . . . .  2
  1.2.  The Flow Label and Quality of Service  . . . . . . . . . .  3
2.  Flow Label Definition and Issues . . . . . . . . . . . . . . .  4
  2.1.  Flow Label Properties  . . . . . . . . . . . . . . . . . .  4
  2.2.  Dependency Prohibition . . . . . . . . . . . . . . . . . .  5
  2.3.  Other Issues . . . . . . . . . . . . . . . . . . . . . . .  5
3.  Documented Proposals for the Flow Label  . . . . . . . . . . .  6
  3.1.  Specify the Flow Label as a Pseudo-Random Value  . . . . .  7
    3.1.1.  End-to-End QoS Provisioning  . . . . . . . . . . . . .  7
    3.1.2.  Load-Balancing . . . . . . . . . . . . . . . . . . . .  8
    3.1.3.  Security Nonce . . . . . . . . . . . . . . . . . . . .  8
  3.2.  Specify QoS Parameters in the Flow Label . . . . . . . . .  8
  3.3.  Use Flow Label Hop-by-Hop to Control Switching . . . . . .  9
  3.4.  Diffserv Use of IPv6 Flow Label  . . . . . . . . . . . . . 12
  3.5.  Other Uses . . . . . . . . . . . . . . . . . . . . . . . . 12
4.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7.  Informative References . . . . . . . . . . . . . . . . . . . . 14

1. Introduction ✨

okay so IPv6 exists to fix the address shortage in IPv4, but it also brings a new feature: the Flow Label field in the IPv6 packet header 🦋 The flow label isn't encrypted by IPsec, and it's present in all fragments. The catch is that it's barely used in practice, for reasons covered below and in [Amante11]. This doc sums up the current IPv6 flow label spec and some open issues about using it in Section 2. Section 3 describes and analyzes the different proposals people have made for it. Then Section 4 talks about the implications and tries to draw conclusions 💅

The Flow Label field takes up bits 12 through 31 of the IPv6 packet header. It offers a potential way to mark a packet, identify a flow, and look up the matching flow state 🌈 This field is always in an IPv6 header, so when we say "a packet with no flow label," we mean a packet whose Flow Label field has 20 zero bits. In other words, a flow label whose value is zero 🫶

1.1. A Brief History of the Flow Label 🕰️

The original flow label idea gets credited to Dave Clark [Deering93], who proposed that it contain a pseudo-random value. A Flow Label field got put into the packet header during the early design of IPv6, after a really intense stretch of debate over several competing proposals. The final choice was made in 1994 [RFC1752] 😭 The IETF rejected a proposal called the Common Architecture for Next Generation Internet Protocol (CATNIP) [RFC1707]. CATNIP had so-called 'cache handles' to identify the next hop in high-performance routers. So CATNIP introduced the idea of a header field shared by every packet in a flow, used to control packet forwarding on a hop-by-hop basis. We now see that as a precursor of the MPLS label [RFC3031] 🔥

The IETF went with a different proposal instead, the Simple Internet Protocol plus (SIPP) [RFC1710], and folded it into IP version 6. SIPP included "labeling of packets belonging to particular traffic 'flows' for which the sender requests special handling, such as non-default quality of service or 'real-time' service" [RFC1710]. In 1994 this used a 28-bit Flow Label field. In 1995 it dropped to 24 bits [RFC1883], and it was finally reduced to 20 bits [RFC2460] so it could fit the IPv6 Traffic Class, which is fully compatible with the IPv4 Type of Service byte 🍓

There was a lot of debate in the IETF about what the flow label was even for. Was it meant to be a handle for fast switching, like in CATNIP? Or was it supposed to be meaningful to applications and used to specify quality of service? Must it be set by the sending host, or could routers set it? Could it be changed en route, or did it have to arrive unchanged? 🤔

Because of all these open questions, plus more urgent work, implementors basically ignored the flow label. Today it's set to zero in almost every IPv6 packet 💀 In fact, [RFC2460] defined it as "experimental and subject to change". There was plenty of preliminary work too, like [Metzler00], [Conta01a], [Conta01b], and [Hagino01]. The proposed standard "IPv6 Flow Label Specification" (RFC 3697) [RFC3697] came next, trying to clear things up by giving precise boundary conditions for using the flow label. That didn't really work at getting the flow label used in practice, so 20 bits sit unused in every IPv6 packet header. Oof 🙈

1.2. The Flow Label and Quality of Service 🎀

High-speed switch design and the success of MPLS have mostly made people stop thinking about the flow label for high-speed switching 🧚 So even though lots of use cases have been proposed, most of them assume it should mainly support quality of service (QoS). For years it's been recognized that real-time Internet traffic needs a different QoS from general data traffic, and that's still true in the era of network neutrality 🫶 That means an alternative to uniform best-effort service is needed, where packets get classified as belonging to a particular class of service or flow.

Right now this causes a layer violation problem, because a 5-tuple is often used to classify each packet. The 5-tuple includes source and destination addresses, port numbers, and the transport protocol type. So when we want to forward or process packets, we have to pull information from the layer above IP. That can be impossible when packets are encrypted so port numbers are hidden, or when packets are fragmented. So the layer violation is a real problem, not just an academic one 😤 The flow label is exempt from IPsec encryption and gets replicated in packet fragments, so it avoids this difficulty. That's why it's gotten attention from designers of new QoS approaches 👑

2. Flow Label Definition and Issues 🌸

2.1. Flow Label Properties 💖

RFC 3697 [RFC3697] standardizes properties of the flow label. They include the following:

  • If the packets are not part of any flow, the flow label value is zero.
  • The 3-tuple {source address, destination address, flow label} uniquely identifies which packets belong to which particular flow.
  • Packets can receive flow-specific treatment if the node has been set up with flow-specific state.
  • The flow label set by the source node must be delivered to the destination node; i.e., it is an end-to-end label.
  • The same pair of source and destination addresses must not use the same flow label value again within a timeout of at least 120 seconds.

One effect of the second rule is that it avoids the layer violation problem from Section 1. By using the 3-tuple, we only use the IP layer to classify packets, with no transport-layer information needed 🦋 That can cut lookup time if flow-based treatment is required, and it works even with IPsec encryption and fragmentation. So for traffic that needs something other than best-effort service, like real-time applications, the flow label can be set to different values to represent different flows. Then each node that forwards or receives the packets can give different flow-specific treatment by looking at the flow label value. This is more fine-grained than differentiated services (Diffserv) [Carpenter02] [RFC2474], and it doesn't need to be less efficient either ✨

2.2. Dependency Prohibition ✨

okay so this is the rule that makes everyone's brain hurt 💀 The standard [RFC3697] basically bans putting any meaning into the bits of the flow label. The exact line is "IPv6 nodes MUST NOT assume any mathematical or other properties of the flow label values assigned by source nodes" 🙈 The worry is a packet coming from a source that uses one encoding scheme and landing at a node that uses a different one. If the bit pattern happens to mean something in both schemes, the receiver will misread it. So unless it has other info, the receiver must not assume anything about what the flow label value means 🫶

The standard [RFC3697] also says "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" 💅 The problem is that if a source picks flow labels one way (like counting up from 1), but a router assumes they're picked another way (like pseudo-random), the router might not work the way it's supposed to 😭

Here's the tricky part: there's no easy way out of these two prohibitions together, and we'll call that combo the dependency prohibition 🦋 Unlike Diffserv code points, flow labels aren't locally significant inside a single administrative domain. They have to be preserved end-to-end. A router generally can't tell whether a packet came from a host that uses some specific flow label scheme. So any method that breaks one or both of these rules will only work if there's some way for a router to figure out which sources are using the same scheme it is 🧚

The dependency rule is subtle, and [RFC3697] doesn't spell it out 👑 A node must not assume properties of the flow label, but it may know them by construction or by signaling. The flow label bits alone are poor material for a hash key, but they can be mixed with bits from other sources to get uniformly distributed hash outputs. ✨

2.3. Other Issues 🌈

ok so [RFC3697] doesn't cover how to use the flow label most effectively 🤷‍♀️ That's still the big open question, but some authors suggest the label could go with reserved bandwidth to get customized QoS. If you pair that with admission control at the edge router, it could help limit congestion 💖 But that's not the only proposed use, and we'll see more of them below.

Now for some other open issues, bestie 👀

  • Unknown flow labels: [RFC1809] proposed that when a router gets a datagram with an unknown flow label, it should treat it as zero. The standard [RFC3697] is silent on this though 🙃 Some ways of setting up flow state might actually use an unknown label as the trigger for creating that state.
  • Deleting old flow labels: When a flow is done, how does the router know the flow label has expired? Should it be based on a timeout, on watching the transport layer, or on explicit signaling? [RFC3697] defines a timeout (120 seconds) that effectively puts a maximum lifetime on flow label state in a router. That means flow labeling is kind of inappropriate for very intermittent flows, unless there's some mechanism to refresh router state 😩 On the other hand, [Banerjee02] suggested that a router should send an ICMP message to the source before deleting a particular label. The source node may then send a KEEPALIVE message to the router, and if it doesn't, the router will release that label 🫠
  • Choosing when to set the flow label: For what kinds of applications should we set up non-zero flow labels? [RFC1809] suggested not setting it for short flows with only a few bytes, but using it for long TCP connections and some real-time applications 🎀
  • Can we modify the flow label? [RFC3697] states that the flow label must be delivered unchanged. Immutable flow labels have a bunch of perks apart from just following the standard: the rule is easy to understand, it doesn't need extra processing in routers or a signaling protocol, and it allows for really simple host implementations 💅 It's also straightforward for hosts and routers to just ignore the flow label. The catch is that this rule seems to rule out any MPLS-like or CATNIP-like use for optimized packet switching 😬 Some of the proposed mechanisms below actually go against this by suggesting that switches should change the flow label for routing purposes.

3. Documented Proposals for the Flow Label 🦋

Quick disclaimer, bestie: we're not here to recommend or roast any of these proposals 🫶 This section just shows the variety that's been published and whether each one fits the existing standard. Almost all of them assume the flow label's main job is supporting QoS, so their flow label mechanisms are tangled up with their QoS mechanisms 🕸️ We sort them into five broad, slightly overlapping categories:

  1. using pseudo-random flow label values for various purposes (for example, to improve routing performance when retrieving cached routing state);
  2. defining specific QoS requirements as parameters embedded in the flow label field;
  3. using the flow label to control packet switching;
  4. using the flow label specifically to extend the existing differentiated services QoS architecture;
  5. other uses.

Across the five sections coming up, there are lots of different ways to set up the flow label value 🌸 Some of these proposals are novel and maybe controversial takes on QoS, and you honestly can't pull them apart from how they use the flow label. We'll give some proposals a reasonable amount of technical detail so you can see how far they go in spelling out the semantics of the flow label value 💜

3.1. Specify the Flow Label as a Pseudo-Random Value 🎲

3.1.1. End-to-End QoS Provisioning 💫

First up, [Lin06] specifies a 17-bit pseudo-random value. The figure below shows the proposed flow label structure 👀

  • The Label Flag (LF) bit: 1 means this type of flow label is present. Heads up, this encoding is incompatible with the dependency prohibition in [RFC3697], since a source that doesn't use this method may also set the LF bit 😭
  • The Label Type (LT): 2 bits that describe the type of packet.
  • The Label Number (LN): randomly generated by the source node.

[Lin06] also describes a signaling process between the source, routing, and destination nodes. It's based on this label structure and on the IPv6 Traffic Class byte, and it's used to reserve and release router resources for a given flow within a given class of traffic 🚦 The pseudo-random LN value is what uniquely identifies a given flow 🔑

Flow Label Specification (figure simplified from [Lin06])

+--+----+-----------------------------+
| 1| 2  |              17 bits        |
+--+----+-----------------------------+
|LF| LT |              LN             |
+--+----+-----------------------------+
LF   0  Disable
     1  Enable
LT  00  Flow label requested by source
    01  Flow label returned by destination
    10  Flow label for data delivery
    11  Flow label terminates connection
LN      Random number created by source

3.1.2. Load-Balancing ⚖️

There have been tons of informal discussions about using pseudo-random flow labels for load-balancing, or at least load-sharing 🙌 The idea is to include the flow label value among the header fields that get fed into a modulo(N) hash, which picks one of N alternative paths. But concerns about how to read the dependency prohibition kept these proposals from getting written up until recently [Carpenter11] 🫣

3.1.3. Security Nonce 🔐

Another pseudo-random flow label proposal is [Blake09] 🙈 It says off-path spoofing attacks have become a huge problem for TCP and other transport-layer applications. So it proposes that in IPv6 we should set a random value in the flow label, which makes the packet header more complex and harder for an attacker to guess 🛡️ The two ends of the session agree on flow label values during the SYN/ACK exchange, and off-path attackers are unlikely to guess the agreed value. But on-path attackers who can see the flow labels in use can trivially get around this, so it's not a real safety net against them 💀 This proposal doesn't use the flow label value to retrieve routing state 🌈

3.2. Specify QoS Parameters in the Flow Label 🎀

[Prakash04] proposes using the flow label to indicate the required QoS parameters in detail 💖 It uses the first few bits of the Flow Label field as codes for different approaches, which are summarized in the table below. Again, this is incompatible with the dependency prohibition in [RFC3697], since a source that doesn't use this method may also set the first two bits to non-zero 😩

Classification for various approaches (from [Prakash04])

 Bit Pattern   Approach
------------------------------------------------------------------
00            No QoS requirement (Default QoS value)
01            Pseudo-Random value used for the value of Flow-Label
10            Support for Direct Parametric Representation
1100          Support for the DiffServ Model
1101          Reserved for future use
111           Reserved for future use

This method allows a pseudo-random option, but it also adds options for a direct QoS request and for Diffserv 🍓 In the direct QoS parameters approach, 18 bits are used to encode requirements for one-way delay, IP delay variation, bandwidth, and one-way packet loss. The proposal seems to assume that the Resource Reservation Protocol (RSVP) [RFC2205] mechanisms are used to actually implement these QoS parameters 🔧

This proposal lets the flow label support several important QoS models, so the end user and the service provider can pick the most suitable one for their situation 🧁 [Prakash04] claims that "The proposed approach results in a simple, scalable, modular and generic implementation to provide for QoS using the IPv6 flow label field" 👑

Similarly, [Lee04] defines the Flow Label field in five parts, with the first 3 bits used as an approach type 🧩 The authors define two approaches: a "random" scheme and a "hybrid" scheme. If the first 3 bits equal "001", the flow label is used as the random identifier of the flow. But if they equal "101", the remaining bits include a hybrid QoS requirement for that packet, broken down into traffic type (stringent or best-effort), bandwidth, buffer, and delay requirements 📦 Once again, the dependency prohibition in [RFC3697] gets broken 😭 This proposal also includes throughput monitoring and dynamic capacity allocation. Basically, it uses the flow label both to signal Intserv-like QoS requirements and to sort traffic into Diffserv-like virtual label-switched paths 🛤️ Packets with a "random" flow label get mapped into a generic (best-effort) virtual path 🌸

3.3. Use Flow Label Hop-by-Hop to Control Switching

Okay so [Chakravorty08b] and [Chakravorty08a] describe an architecture called "IPv6 Label Switching Architecture" (6LSA) 🦋. In 6LSA, network components identify a flow by looking at the Flow Label field in the IPv6 packet header. All packets with the same flow label must receive the same treatment and be sent to the same next hop. But 6LSA acts a lot like MPLS, since it treats a label as only meaningful between 6LSA routers, and each hop sets the flow label again. So if the original source sets a non-zero flow label, there's no way to restore it before delivery, and that's a total breach of [RFC3697] 💀. The authors of [Chakravorty08b] did at one point talk about using an IPv6 hop-by-hop option to fix this, but that idea never got documented 🙈. Honestly, this is a way bigger incompatibility than just breaking the dependency prohibition.

Unlike traditional routing algorithms, but like MPLS, 6LSA packets get sorted into a Forwarding Equivalence Class (FEC), and routers send packets down different paths based on the FEC 🛣️. Like earlier solutions, this one splits the Flow Label field into three parts. The first 3 bits identify the FEC, which helps routers or 6LSA nodes group the IP packets that get the same forwarding treatment and send them along the same virtual path. The next 4 bits describe the application type, and the final 13 bits (defined by each node or a group of nodes) specify the hop-specific label. The table below shows that the FEC has 6 major categories, and each one has up to 16 subcategories 💜.

Flow Label Specification (shortened from [Chakravorty08b])

+--------------------------+-------------+--------------------------+
| FEC (First 3 Bits)       | Next 4 Bits | Purpose                  |
+--------------------------+-------------+--------------------------+
| No FEC (000)             | 0000        |                          |
| Domain Specific (000)    | 0001 - 1111 |                          |
| ------------------------ |             |                          |
| VPN (001)                | 0001        | (IPSec - Tunnel Mode)    |
|                          | 0010        | (IPSec - Transport Mode) |
|                          | 0011        | (Special Encryption)     |
|                          | 0100        | (VRF)                    |
|                          | 0101        | (End Network Specific)   |
|                          | 0110 - 1111 | (Reserved)               |
| ------------------------ |             |                          |
| TE Subset/               | 0001        | (DiffServ)               |
| QoS Enhancement (010)    | 0010        | (RSVP)                   |
. . .
|                          | 1111        | (Reserved)               |
| ------------------------ |             |                          |
| Encapsulation (011)      | 0001        | (IPv6 in IPv6)           |
|                          | 0010        | (IPv4 in IPv6)           |
|                          | 0011        | (Other in IPv6)          |
|                          | 0100        | (Enterprise Specific)    |
|                          | 0101 - 1111 | (Reserved)               |
| ------------------------ |             |                          |
| Enterprise Specific(111) | 0000 - 1111 | (Reserved)               |
+--------------------------+-------------+--------------------------+

The authors claim that fast switching with 20-bit labels, instead of 128-bit IPv6 addresses, saves memory and processing, and gives network management some perks too ✨. Their words: "It also allows a network management entity updating available label tables, across the network to reduce man-in-the-middle attacks [sic]" [Chakravorty08b]. Iykyk, that [sic] is doing a lot of work there 😭.

We should also note that a similar proposal for QoS-based switching of IPv6 packets [Roberts05] was designed to use a hop-by-hop option, and the IETF hasn't allocated one of those so far 🫠. Related ideas have been discussed by the Telecommunications Industry Association and the ITU-T [Adams08].

Last thing: router lookup efficiency was a huge concern back when Clark first proposed a flow label [Deering93]. But now that very large scale integrated circuits can do rapid lookups in a routing table, most vendors don't stress about it anymore 💅.

3.4. Diffserv Use of IPv6 Flow Label

[Banerjee02] uses the Flow Label field as a replacement for the IPv6 Traffic Class field 🎀. The idea is that the incoming flow label can signal the QoS requirement by matching a Diffserv classifier. The authors use the first three bits to do this, then the following 16 bits to hold a Differentiated Services Per-Hop Behavior Identification code (Diffserv PHB-ID) [RFC3140], and the last bit is reserved for future use. Unfortunately, this method also breaks the dependency prohibition in [RFC3697] 😬.

[Beckman07a] blends the flow label with Diffserv as an MPLS-like switching tag ✨. Unlike 6LSA, this method tries to get around the dependency prohibition by using one bit in the Diffserv Code Point [RFC2474] to show that the flow label is a switching tag. That way, a router can tell whether the flow label follows [RFC3697] or [Beckman07a] 🧠. In [Beckman07b], the same author proposes using the flow label to compress IPv6 headers by hashing the addresses into the flow label, and again uses the Diffserv Code Point to mark the packets 🌸.

3.5. Other Uses

The Integrated Services QoS architecture [RFC1633] says the flow label may be used as a packet filter [RFC2205]. At least one implementation supported this [Braden10] 🔥.

We aren't aware of any proposals that combine the flow label with the Next Steps in Signaling (NSIS) [RFC4080] architecture 🤷‍♀️.

[Donley11] proposes a use case where certain flows, encapsulated in a particular type of IPv4-in-IPv6 tunnel, would be told apart at the far end of the tunnel by a specific flow label value 🧚. This would let a service provider deliver a tailored quality of service. This usage seems completely compatible with [RFC3697] 👑.

There's been some discussion of possible flow label uses in both the ROLL (Routing Over Low power and Lossy networks) [RPL-07] and MEXT (Mobility EXTensions for IPv6) working groups of the IETF 🌈. These uses tend to encode specific local meanings or routing-related tags in the label, so they seem to break the dependency prohibition or the immutability of the Flow Label field 😤. The ROLL group most recently chose not to use the Flow Label field for these reasons, even though it meant adding the undesirable overhead of an IPv6 hop-by-hop option instead [RPL] 🙃. MEXT, similarly, defined a new mobility option to support flow bindings [RFC6089] rather than using the IPv6 Flow Label field 💅.

4. Conclusion

Three aspects of the current standard [RFC3697] have caused problems for lots of designers 😩:

  1. The immutability of labels
  2. "Nodes MUST NOT assume any mathematical or other properties of the Flow Label"
  3. "Router performance SHOULD NOT be dependent on the distribution of the Flow Label values"

Put together, these rules basically forbid encoding the semantics of a flow, or any information about its path, in the flow label 🚫. This was on purpose, to match the stateless nature of the Internet architecture and the end-to-end principle [Saltzer84], [RFC3724]. People also felt that QoS encoding via Diffserv was enough, and that MPLS could cover the need for high-speed switching. But that means most of the proposals above break the standard and its intent. The authors often seem to use the flow label either as an MPLS-like switching handle or as an encoded QoS signal 🫣.

Meanwhile, a few documents mentioned above do seem to respect the rules of RFC 3697 🥰. These are [Blake09], [Donley11], [Carpenter11], [Beckman07a], and [Beckman07b]. [Lin06] would have joined this list too, if it hadn't assigned three flag bits in the Flow Label field. The Integrated Services usage [RFC2205] also seems compatible, even though it predates RFC 3697 ✨.

So what should other designers do if they want to respect RFC 3697? There seem to be two choices 🤔. The first is to just accept the existing rules at face value, like the proposals listed above do. This limits what the flow label can be used for. For example, it can be used as a nonce, or as part of the material for a hash used to spread load across alternate paths. It can't be the only material for such a hash, because of the dependency prohibition. An application designer could also use the flow label consistently with RFC 3697, to tie together all packets belonging to one application session between two hosts, across multiple transport sessions. But this would presumably rule out using the flow label to make routing decisions in any way, and it would have widespread implications nobody has really explored 🌀.

The second choice is for designers who want to use the flow label to control switching or QoS directly. They can bypass the rules inside a given domain (a set of cooperating nodes) in a way that nodes outside the domain can't detect 🕵️‍♀️. In that case, any deviation from RFC 3697 has no possible effect outside the domain in question.

Here's an example scheme for emulating the immutability of labels 🧩. Inside the domain, all hosts set the label to zero, the routers set and interpret the label however they like, and the last-hop router always sets the label back to zero. If a packet arrives from outside the domain with a non-zero label, there's a method (such as a special Diffserv code point) to mark that packet so its label gets ignored and it's delivered unchanged. Another option would be to define a hop-by-hop option that carries the original flow label across the domain, so it can be changed inside the domain but restored before the packet is forwarded beyond it 🔄.

If a domain allows mutable labels this way, it may safely ignore the dependency prohibition, and it may set the bits in the label according to locally defined rules 🎉. Inside the domain, the label can be used however they want, and most of the proposed designs above could be "rescued" 🚑.

Still, with so many designers proposing solutions that clash with RFC 3697, relatively few designs using the standard rules, and designs like ROLL and MEXT not using the flow label at all, it's fair to ask whether the RFC 3697 standard has value 🤨.

5. Security Considerations

🚨 The flow label is not protected in any way, and an on-path attacker can forge it. Off-path attackers may be able to guess a valid flow label unless a pseudo-random value is used. Specific usage models for the flow label need to allow for these exposures. For further discussion, see [RFC3697].

6. Acknowledgements

An invaluable review of this document was performed by Bob Braden 🫶. Helpful comments were made by Sheng Jiang 💖.

7. Informative References ✨

okay bestie, the references are the receipts 🧾 every single source the author leaned on is listed here, so if you ever wanna go digging, this is your treasure map 🗺️🦋

  • [Adams08] Adams, J., Joung, J., and J. Song, "Progress and future development of Flow State Aware standards, and a proposal for alerting nodes or end-systems on data related to a flow", Work in Progress, June 2008.
  • [Amante11] Amante, S., Carpenter, B., and S. Jiang, "Rationale for update to the IPv6 flow label specification", Work in Progress, May 2011.
  • [Banerjee02] Banerjee, R., Malhotra, S., and M. M, "A Modified Specification for use of the IPv6 Flow Label for providing An efficient Quality of Service using a hybrid approach", Work in Progress, April 2002.
  • [Beckman07a] Beckman, M., "IPv6 Dynamic Flow Label Switching (FLS)", Work in Progress, February 2007.
  • [Beckman07b] Beckman, M., "IPv6 Header Compression via Addressing Mitigation Protocol (IPv6 AMP)", Work in Progress, November 2006.
  • [Blake09] Blake, S., "Use of the IPv6 Flow Label as a Transport-Layer Nonce to Defend Against Off-Path Spoofing Attacks", Work in Progress, October 2009.
  • [Braden10] Braden, R., "Private Communication", 2010.
  • [Carpenter02] Carpenter, B. and K. Nichols, "Differentiated Services in the Internet", Proc IEEE 90 (9) 1479-1494, 2002.
  • [Carpenter11] Carpenter, B. and S. Amante, "Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels", Work in Progress, May 2011.
  • [Chakravorty08a] Chakravorty, S., "Challenges of IPv6 Flow Label implementation", Proc IEEE MILCOM2008, 2008.
  • [Chakravorty08b] Chakravorty, S., Bush, J., and J. Bound, "IPv6 Label Switching Architecture", Work in Progress, July 2008.
  • [Conta01a] Conta, A. and B. Carpenter, "A proposal for the IPv6 Flow Label Specification", Work in Progress, July 2001.
  • [Conta01b] Conta, A. and J. Rajahalme, "A model for Diffserv use of the IPv6 Flow Label Specification", Work in Progress, November 2001.
  • [Deering93] Deering, S., "SIPP Overview and Issues", Minutes of the Joint Sessions of the SIP and PIP Working Groups, November 1993.
  • [Donley11] Donley, C. and K. Erichsen, "Using the Flow Label with Dual-Stack Lite", Work in Progress, January 2011.
  • [Hagino01] Hagino, J., "Socket API for IPv6 flow label field", Work in Progress, April 2001.
  • [Lee04] Lee, I. and S. Kim, "A QoS Improvement Scheme for Real-Time Traffic Using IPv6 Flow Labels", Lecture Notes in Computer Science Vol. 3043, 2004.
  • [Lin06] Lin, C., Tseng, P., and W. Hwang, "End-to-End QoS Provisioning by Flow Label in IPv6", JCIS , 2006.
  • [Metzler00] Metzler, J. and S. Hauth, "An end-to-end usage of the IPv6 flow label", Work in Progress, November 2000.
  • [Prakash04] Prakash, B., "Using the 20 bit flow label field in the IPv6 header to indicate desirable quality of service on the internet", University of Colorado (M.Sc. Thesis), 2004.
  • [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
  • [RFC1707] McGovern, M. and R. Ullmann, "CATNIP: Common Architecture for the Internet", RFC 1707, October 1994.
  • [RFC1710] Hinden, R., "Simple Internet Protocol Plus White Paper", RFC 1710, October 1994.
  • [RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995.
  • [RFC1809] Partridge, C., "Using the Flow Label Field in IPv6", RFC 1809, June 1995.
  • [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
  • [RFC2205] Braden, R., Ed., 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.
  • [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
  • [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
  • [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
  • [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004.
  • [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080, June 2005.
  • [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011.
  • [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Work in Progress, March 2011.
  • [RPL-07] Winter, T., Ed. and P. Thubert, Ed., "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Work in Progress, March 2010.
  • [Roberts05] Roberts, L. and J. Harford, "In-Band QoS Signaling for IPv6", Work in Progress, July 2005.
  • [Saltzer84] Saltzer, J., Reed, D., and D. Clark, "End-To-End Arguments in System Design", ACM TOCS 2 (4) 277-288, 1984.

Authors' Addresses 🎀

okay and here's who wrote it, the two lovely humans behind the whole thing 🫶

Qinwen Hu Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand

EMail: qhu009@aucklanduni.ac.nz

Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand

EMail: brian.e.carpenter@gmail.com

and that's a wrap on RFC 6294 💅✨🌸 periodt

📦 where this page comes from