One document matched: draft-hu-flow-label-cases-03.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- This is built from a template for a generic Internet Draft. Suggestions for
improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->
<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
(which supports the latest, sometimes undocumented and under-tested, features.) -->
<?rfc toc="yes"?> <!-- You want a table of contents -->
<?rfc symrefs="yes"?> <!-- Symbolic or numeric references -->
<?rfc sortrefs="yes"?> <!-- This sorts the references -->
<?rfc iprnotified="no" ?> <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-hu-flow-label-cases-03" category="info">
<front>
<title abbrev="Flow label use cases">Survey of proposed use cases for the IPv6 flow label</title>
<author initials="Q." surname="Hu" fullname="Qinwen Hu">
<organization abbrev="Univ. of Auckland"></organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region></region>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>qhu009@aucklanduni.ac.nz</email>
</address>
</author>
<author initials="B. E." surname="Carpenter" fullname="Brian Carpenter">
<organization abbrev="Univ. of Auckland"></organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region></region>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<date day="23" month="February" year="2011" />
<workgroup>Independent Submission</workgroup>
<abstract>
<t>The IPv6 protocol includes a flow label in every packet header, but this
field is not used in practice. This paper describes the flow label standard
and discusses the implementation issues that it raises. It then describes
various published proposals for using the flow label, and shows that most
of them are inconsistent with the standard. Methods to address this problem
are briefly reviewed. We also question whether the standard should be revised.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
IPv6 is being introduced to overcome the address shortage of the current IPv4
protocol, but it also offers a new feature, i.e., the flow label field in the IPv6
packet header. The flow label is not encrypted by IPsec, and is present in all
fragments. However, it is very little used in practice, for reasons discussed below
and in <xref target="I-D.ietf-6man-flow-update"/>. After a short
introduction, this document summarizes the current specification of the IPv6 flow
label and some open issues about its use in <xref target="def"/>, and then
<xref target="prop"/> describes and analyses various proposals that have been made
for its use. Finally, <xref target="concl"/> discusses the implications and attempts
to draw conclusions.
<t>
The flow label field occupies bits 12 through 31 of the IPv6 packet header. It provides
a potential way to mark a packet, identify a flow, and look up the corresponding flow
state. This field is always present in an IPv6 header, so a phrase such
as "a packet with no flow label" refers to a packet whose flow label field contains 20 zero bits,
i.e., a flow label whose value is zero. </t>
</t>
<section title="A brief history of the flow label">
<t>
The original proposal for a flow label has been attributed to Dave Clark
<xref target="Deering93"/>, who proposed that it should contain a pseudo-random value.
A flow label field was included in the packet header during the preliminary design
of IPv6, which followed an intense period of debate about several competing proposals.
The final choice was made in 1994 <xref target="RFC1752"/>. In particular, the IETF
rejected a proposal known as CATNIP <xref target="RFC1707"/>, which included so-called
'cache handles' to identify the next hop in high performance routers. Thus CATNIP
introduced the notion of a header field that would be shared by all packets belonging
to a flow, to control packet forwarding on a hop-by-hop basis. We recognize this today
as a precursor of the MPLS label <xref target="RFC3031"/>. </t>
<t>The IETF decided instead to develop a proposal known as SIPP 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" <xref target="RFC1710"/>. In 1994, this used a 28-bit flow label field. In 1995
it was down to 24 bits <xref target="RFC1883"/> and it was finally reduced to 20 bits
<xref target="RFC2460"/> to accommodate the IPv6 Traffic Class, which is fully compatible
with the IPv4 Type of Service byte.
</t><t>
There was considerable debate in the IETF about the very purpose of the flow label.
Was it to be a handle for fast switching, as in CATNIP, or was it to be meaningful
to applications and used to specify quality of service? Must it be set by the sending
host, or could it be set by routers? Could it be modified en route, or must it be
delivered with no change? </t>
<t>Because of these uncertainties, and more urgent work, the flow label was consistently
ignored by implementors, and today is set to zero in almost every IPv6 packet.
In fact, <xref target="RFC2460"/> defined it as "experimental and subject to change."
There was considerable preliminary work such as <xref target="Metzler00"/>,
<xref target="Conta01a"/>,
<xref target="I-D.conta-diffserv-ipv6-fl-classifier"/> and
<xref target="Hagino01"/>.
The ensuing proposed standard "IPv6 Flow Label Specification" (RFC 3697) <xref target="RFC3697"/>
intended to clarify this situation by providing precise boundary conditions for use of the
flow label. However, this has not proved successful in promoting use of the flow label in
practice, as a result of which 20 bits are unused in every IPv6 packet header.
</t>
</section>
<section title="The flow label and quality of service">
<t>Developments in high speed switch design, and the success of MPLS, have largely obviated
consideration of the flow label for high-speed switching. Thus, although various use cases
for the flow label have been proposed, most of them assume that it should be used principally
to support the provision of quality of service (QoS). For many years it has been recognized
that real-time Internet traffic requires a different QoS from general data traffic, and this
remains true in the era of network neutrality. Thus an alternative to uniform best-effort
service is needed, requiring packets to be classified as belonging to a particular class of
service or flow. Currently, this leads to a layer violation problem, since 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 need to extract
information from the layer above IP. This may be impossible when packets are encrypted such that
port numbers are hidden, or when packets are fragmented, so
the layer violation is not an academic concern. The flow label, being exempt from IPsec encryption
and being replicated in packet fragments, avoids this difficulty. It has therefore attracted
attention from the designers of new approaches to QoS.
</t>
</section>
</section>
<section anchor="def" title="Flow label definition and issues">
<section title="Flow label properties">
<t>
RFC 3697 <xref target="RFC3697"/> standardizes properties of the flow label, including:</t>
<list style="symbols">
<t>If the packets are not part of any flow, the flow label value is zero.
</t><t> The 3-tuple {source address, destination address, flow label} uniquely identifies
which packets belong to which particular flow.
</t><t> Packets can receive flow-specific treatment if the node has been set up with flow-specific state.
</t><t> The flow label set by the source node must be delivered to the destination node,
i.e., it is an end-to-end label.
</t><t> 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.
</t></list>
<t>
One effect of the second of these rules is to avoid the layer violation problem mentioned in
<xref target="intro"/>. By using the 3-tuple, we only use the IP layer to classify packets,
without needing any transport layer information. This may reduce the lookup time if flow-based
treatment is required, and will work even with IPsec encryption and fragmentation. Therefore,
for traffic needing other than best-effort service, such as real-time applications, the flow
label can be set to different values to represent different flows, and each node forwarding
or receiving the packets may provide different flow-specific treatments by looking at the
flow label value. This is more fine-grained than differentiated services
(Diffserv) <xref target="Carpenter02"/>, <xref target="RFC2474"/> but need not be less efficient.
</t>
</section>
<section title="Dependency prohibition">
<t>
An additional important rule in the standard <xref target="RFC3697"/> effectively forbids any
encoding of meaning in the bits of the flow label. To be exact, the standard states that "IPv6
nodes MUST NOT assume any mathematical or other properties of the flow Label values assigned
by source nodes." This rule is aimed at the case where a packet from a source using a particular
encoding scheme for the flow label reaches a node that is using a different scheme. If by chance
the bit pattern in the flow label is meaningful in both schemes, the receiver would misinterpret
the flow label. Therefore, in the absence of other information, the receiver must not
assume anything about the meaning of the value of the flow label.
</t><t>
The standard <xref target="RFC3697"/> also states "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 this rule is intended to avoid is that if a source uses one method of
choosing flow labels (e.g., counting up from 1), any router that assumes another method (e.g.,
pseudo-randomness) may not perform as intended.
</t><t>
Note that there is no easy escape from the combination of these two prohibitions, which we will
call the dependency prohibition. Unlike Diffserv code points, flow labels are not locally significant
within a single administrative domain; they must be preserved end-to-end. In general, a router cannot
know whether a particular packet originated in a host supporting a specific usage of the flow label.
Therefore, any method that breaks one or both of these rules will only work if there is some way for
a router to determine which sources use the same scheme as itself.
</t>
<t>The interpretation of the dependency rule can be subtle and is not spelled out in <xref target="RFC3697"/>.
A node must not assume properties of the flow label - but it may know them by construction or by signaling. The bits of
the flow label alone are poor material for a hash key - but they may be combined with bits from
other sources, to provide uniformly distributed hash outputs.
</t>
</section>
<section title="Other issues">
<t>
<xref target="RFC3697"/> does not discuss how to use flow label most effectively. This remains the
major open issue, but some authors propose that the label should be used with reserved bandwidth to
achieve customized QoS provision. Coupled with admission control at the edge router, this could
limit congestion. However, as we will see below, this is not the only proposed use.
</t><t>
We now introduce some other open issues.
</t>
<list style='symbols'>
<t>
Unknown flow labels: <xref target="RFC1809"/> proposed that when a router receives a datagram with
an unknown flow label, it should treat it as zero. However, the standard <xref target="RFC3697"/>
is silent on this issue. Indeed, some methods of flow state establishment might choose to use an
unknown label as the trigger for creating flow state.
</t><t>
Deleting old flow labels: When a flow finishes, how does the router know the flow label has expired?
Should this be based on a timeout, on observation of the transport layer, or on explicit signalling?
<xref target="RFC3697"/> defines a timeout (120 seconds) that effectively imposes a maximum lifetime
on flow label state in a router. This implies that flow labeling is inappropriate for very intermittent
flows, unless there is some mechanism to refresh router state. In contrast,
<xref target="I-D.banerjee-flowlabel-ipv6-qos"/> suggested that a router should send an ICMP message
to the source prior to deleting a particular label. The source node may then send a KEEPALIVE message
to the router; if it does not, the router will release that label.
</t><t>
Choosing when to set the flow label: For what kinds of application should we set up non-zero flow labels?
<xref target="RFC1809"/> suggested not setting it for short flows containing few bytes, but using it for
long TCP connections and some real-time applications.
</t><t>
Can we modify the flow label? <xref target="RFC3697"/> states that the flow label must be delivered
unchanged. There are several advantages of immutable flow labels, apart from respecting the standard:
the rule is easy to understand, does not require extra processing in routers or a signalling protocol,
and allows for very simple host implementations. Also, it is straightforward for hosts and routers to
simply ignore the flow label. However, this rule does appear to exclude any MPLS-like or CATNIP-like
use for optimized packet switching. Some of the proposed mechanisms described below contradict this
by suggesting that switches should change the flow label for routing purposes.
</t>
</list>
</section>
</section>
<section anchor="prop" title="Documented proposals for the flow label">
<t>In the following, we do not intend to recommend or criticise various proposals. This section shows
the variety of proposals that have been published, and whether they are compatible with the existing standard.
These proposals almost all assume that the flow label's main purpose is to support QoS,
and their flow label mechanisms are entangled with QoS mechanisms.
We describe the proposals in five broad, and somewhat overlapping, categories, i.e.,</t>
<list style="numbers">
<t>use pseudo-random flow label values for various purposes (for example, to improve routing
performance when retrieving cached routing state) </t>
<t>define specific QoS requirements as parameters embedded in the flow label field; </t>
<t>use the flow label to control packet switching; </t>
<t>use the flow label specifically to extend the existing differentiated services QoS architecture; </t>
<t>other uses. </t>
</list>
<t>Among the proposals described in the following five sections, various methods are proposed
to set up the flow label value. It should be noted that some of these proposals
embody novel and perhaps controversial approaches
to QoS provision, and these cannot readily be separated from their use of the flow label. We give
a reasonable amount of technical detail for some of the proposals, to show the extent to
which they propose detailed semantics for the flow label value. </t>
<section title="Specify the flow label as a pseudo-random value">
<section title="End-to-End QoS Provisioning">
<t>
As our first example, <xref target="Lin06"/> specifies a 17-bit pseudo-random value. The
figure below shows the proposed flow label structure. </t>
<list style="symbols">
<t> The Label Flag (LF) bit: 1 means this type of flow label is present. We note that this
encoding is incompatible with the dependency prohibition in <xref target="RFC3697"/>, since
a source that does not use this method may also set the LF bit.
</t><t> The Label type (LT): 2 bits which describe the type of packet.
</t><t> The Label Number (LN): which is randomly generated by the source node.
</t></list>
<t>
<xref target="Lin06"/> also describes a signalling process between source, routing and
destination nodes based on this label structure and on the IPv6 Traffic Class byte, in order
to reserve and release router resources for a given flow within a given class of traffic.
The pseudo-random LN value is used to uniquely identify a given flow.
</t>
<t>
<figure>
<preamble>Flow Label Specification (figure simplified from <xref target="Lin06"/>)</preamble>
<artwork>
+--+----+-----------------------------+
| 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
</artwork></figure>
</t>
</section>
<section title="Load balancing">
<t>
There have been numerous informal discussions of using pseudo-random flow labels to allow
load-balancing or at least load-sharing.
This would be achieved by including the flow label value among the fields in each packet
header used as input to a modulo(N) hash
used to select among N alternative paths.
However, concerns about the interpretation of the dependency prohibition have generally prevented such proposals
from being written up until recently <xref target="I-D.ietf-6man-flow-ecmp"/>.
</t>
</section>
<section title="Security nonce">
<t>
Another proposal for a pseudo-random flow label value is <xref target="I-D.blake-ipv6-flow-label-nonce"/>.
This states that off-path spoofing attacks have become a big issue for TCP and other transport-layer
applications, and proposes that in IPv6 we should set a random value in the flow label to make the
packet header more complex and less easy for the attacker to guess. The two ends of the session
will agree on flow label values during the SYN/ACK exchange, but off-path attackers will be unlikely
to guess the agreed value. Naturally, on-path attackers who can observe the flow labels in use can
trivially defeat this protection. This proposal does
not involve using the flow label value to retrieve routing state.
</t>
</section>
</section>
<section title="Specify QoS parameters in the flow label">
<t>
<xref target="Prakash04"/> proposes to utilize the flow label to indicate required QoS parameters
in detail. It uses the first few bits of the flow label field as codes to support different approaches,
as summarized in following table. Again, this is incompatible with the dependency prohibition in
<xref target="RFC3697"/>, since a source that does not use this method may also set the first
two bits to non-zero.
</t>
<figure>
<preamble>Classification for various approaches (from <xref target="Prakash04"/>)</preamble>
<artwork>
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
</artwork></figure>
<t>
This method allows a pseudo-random option, but 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 appears to
assume that RSVP <xref target="RFC2205"/> mechanisms are used to actually implement these QoS parameters.
</t><t>
This proposal allows use of flow label for various important QoS models, so the end user and service
provider can choose the most suitable model for their situation; <xref target="Prakash04"/> claims that
"this proposal is simple, scalable, modular and generic implementation to provide for QoS using the
IPv6 flow label field".
</t><t>
Similarly, <xref target="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 will be used as the random identifier of the flow,
but if they equal "101", the remaining bits will include a hybrid QoS requirement for this packet,
subdivided into traffic type (stringent or best effort), bandwidth, buffer, and delay requirements.
Once again the dependency prohibition in <xref target="RFC3697"/> is broken. This proposal also includes
throughput monitoring and dynamic capacity allocation. Effectively this proposal uses the flow label
both to signal Intserv-like QoS requirements and to classify traffic into Diffserv-like virtual label-switched
paths. Packets with a "random" flow label are mapped into a generic (best effort) virtual path.
</t>
</section>
<section title="Use flow label hop-by-hop to control switching">
<t>
<xref target="I-D.chakravorty-6lsa"/> and <xref target="Chakravorty08a"/> describe an architectural
framework 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. However, 6LSA resembles MPLS
by considering that a label only has meaning between 6LSA routers, and setting the flow label at each
hop. If the original source sets a non-zero flow label, there is no mechanism to restore it before
delivery, a fundamental breach of <xref target="RFC3697"/>. The authors of
<xref target="I-D.chakravorty-6lsa"/> did at one stage discuss using an IPv6 hop-by-hop option to
correct this problem, but this has not been documented. This is a more serious incompatibility than
simply breaking the dependency prohibition
</t><t>
Unlike traditional routing algorithms, but like MPLS, 6LSA packets are classified into a Forwarding
Equivalence Class (FEC), and routers forward packets on different paths by looking at the FEC. Like
previous solutions, the authors divide the flow label field into three parts. The first 3 bits
identify the FEC, which will help the router or 6LSA nodes to group the IP packets that receive
the same forwarding treatment and forwarding them on the same virtual path. The following 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. From the table below, we can see the FEC has 6 major categories,
each with up to 16 subcategories.
</t>
<figure>
<preamble>Flow Label Specification (shortened from <xref target="I-D.chakravorty-6lsa"/>)</preamble>
<artwork>
+--------------------------+-------------+--------------------------+
| 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) |
+--------------------------+-------------+--------------------------+
</artwork></figure>
<t>
The authors claim that fast switching using 20-bit labels instead of 128-bit IPv6 addresses will
provide memory and processing savings, as well as network management advantages. "It also allows a
network management entity updating available label tables, across the network to reduce
man-in-the-middle attacks [sic]" <xref target="I-D.chakravorty-6lsa"/>.
</t><t>
We note that a similar proposal for QoS-based switching of IPv6 packets
<xref target="I-D.roberts-inband-qos-ipv6"/> is designed to use a hop-by-hop option, which has not
so far been allocated by the IETF. Proposals related to this have been discussed by the
Telecommunications Industry Association and the ITU-T <xref target="I-D.adams-tsvwg-flow-signalling-codepoint"/>.
</t>
<t>
We also note that router lookup efficiency was a major concern at the time when Clark first proposed
a flow label <xref target="Deering93"/>, but with the advent of very large scale integrated circuits capable of
rapid lookup in a routing table, most vendors no longer express such concern.
</t>
</section>
<section title="Diffserv use of IPv6 flow label">
<t>
<xref target="I-D.banerjee-flowlabel-ipv6-qos"/> uses the flow label field as a replacement for the
IPv6 Traffic Class field; this proposal suggests the incoming flow label can indicate the QoS
requirement by matching a Diffserv classifier. The authors have used the first three bits to
indicate this, and the following 16 bits to indicate a Differentiated Services Per-Hop Behavior
Identification code (Diffserv PHB-ID) <xref target="RFC3140"/>; the last bit is reserved for
future use. This method too breaks the dependency prohibition in <xref target="RFC3697"/>.
</t><t>
<xref target="I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching"/> blends the flow label as an
MPLS-like switching tag with Diffserv. Unlike 6LSA, the method attempts to bypass the dependency
prohibition by using one bit in the Diffserv Code Point <xref target="RFC2474"/> to indicate
that the flow label is a switching tag. In this way, a router can determine whether the flow label conforms
to <xref target="RFC3697"/> or to <xref target="I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching"/>.
In <xref target="I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp"/>, the same author proposes using the flow
label as a way of compressing IPv6 headers by hashing the addresses into the flow label, again using the
Diffserv Code Point to mark the packets accordingly.
</t>
</section>
<section title="Other uses">
<t>
The Integrated Services QoS architecture <xref target="RFC1633"/> specifies that the flow label may
be used as a packet filter <xref target="RFC2205"/>. At least one implementation supported this
<xref target="Braden10"/>.
</t><t>
We are not aware of any proposals combining the flow label with the Next Steps in Signaling (NSIS)
<xref target="RFC4080"/> architecture.
</t>
<t>
<xref target="I-D.donley-softwire-dslite-flowlabel"/> proposes a use case whereby certain flows
encapsulated in a particular type of IPv4-in-IPv6 tunnel would be distinguished at the remote
end of the tunnel by a specific flow label value. This would allow a service provider
to deliver a tailored quality of service. This usage appears to be completely compatible
with <xref target="RFC3697"/>.
</t>
<t>
There has been some discussion of possible flow label use in both the ROLL
(Routing Over Low power and Lossy networks) <xref target="RPL-07"/>
and MEXT (Mobility EXTensions for IPv6) working groups of the IETF. Such uses tend to encode
specific local meanings or routing-related tags in the label, so they appear to infringe the dependency
prohibition or the immutability of the flow label field. The ROLL group has indeed most recently
opted not to use the flow label field for these reasons, despite having to add the undesirable
overhead of an IPv6 hop-by-hop option instead <xref target="I-D.ietf-roll-rpl"/>.
Similarly, MEXT has defined a new mobility option to support flow bindings <xref target="I-D.ietf-mext-flow-binding"/>,
rather than using the IPv6 flow label field.
</t>
</section>
</section>
<section anchor="concl" title="Conclusion">
<t>
Three aspects of the current standard <xref target="RFC3697"/> have caused problems to many designers:</t>
<list style="numbers">
<t> The immutability of labels
</t><t> "Nodes MUST NOT assume any mathematical or other properties of the Flow Label"
</t><t> "Router performance SHOULD NOT be dependent on the distribution of the Flow Label values."
</t></list>
<t>
Taken together, these rules essentially forbid any encoding of the semantics of a flow, or of
any information about its path, in the flow label. This was intentional, in accordance with the
stateless nature of the Internet architecture and with the end-to-end principle <xref target="Saltzer84"/>,
<xref target="RFC3724"/>. It was also felt that QoS encoding via Diffserv was sufficient, and that
the requirement for high-speed switching could be met by MPLS. But this means that the majority of
the proposals described above breach the standard and the intent of the standard. The authors often
appear to be using the flow label either as an MPLS-like switching handle, or as an encoded QoS signal. </t>
<t>In contrast, a few documents metioned above do appear to
respect the rules of RFC 3697. These are
<xref target="I-D.blake-ipv6-flow-label-nonce"/>,
<xref target="I-D.donley-softwire-dslite-flowlabel"/>,
<xref target="I-D.ietf-6man-flow-ecmp"/>,
<xref target="I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching"/> and
<xref target="I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp"/>.
Additionally, <xref target="Lin06"/> would have joined this list if it had not assigned three flag bits in the flow label field.
Although predating RFC 3697, the Integrated Services usage <xref target="RFC2205"/> also seems to be compatible.
</t><t>
What would other designers need to do, if they wish to respect RFC 3697? There appear to be two choices.
One is to simply accept the existing rules at face value, as in the proposals just listed. This limits
the application of the flow label. It can, for example, be used as a nonce or as part of the material
for a hash used to share load among alternate paths. It cannot be the only material for such a hash,
because of the dependency prohibition. The flow label could also be used
consistently with RFC 3697, if an application designer so chose, as a way to associate all packets
belonging to a given application session between two hosts, across multiple transport sessions. This,
however, would presumably exclude using the flow label to govern routing decisions in any way, and
would have widespread implications that have never been explored.
</t><t>
The other choice, for designers who wish to use the flow label to control switching or QoS directly,
is to bypass the rules within a given domain (a set of cooperating nodes) in a way that nodes outside
the domain cannot detect. In this case, any deviation from RFC 3697 has no possible effect outside
the domain in question.
</t><t>
An example scheme to emulate the immutability of labels is as follows. Within the domain, all hosts
set the label to zero, the routers set and interpret the label in any way they wish, 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 is a method (such as a special Diffserv code point) to mark this packet so
that its label would be ignored and delivered unchanged. An alternative approach would be to define a
hop-by-hop option to carry the original flow label across the domain, so that it could be changed
within the domain but restored before forwarding the packet beyond the domain.
</t><t>
If a domain allows mutable labels in such a way, it may safely ignore the dependency prohibition,
and it may set the bits in the label according to locally defined rules. Within the domain, the
label could be used as desired, and most of the proposed designs discussed above could be "rescued."
</t><t>
However, given the considerable number of designers who have proposed solutions incompatible with
RFC 3697, the relatively few designs using the standard rules, and the failure of designs such as
ROLL and MEXT to make use of the flow label, it seems reasonable to ask whether the RFC 3697 standard has value.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>The flow label is not protected in any way and can be forged by an on-path
attacker. 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 <xref target="RFC3697"/>. </t>
</section> <!-- security -->
<section anchor="iana" title="IANA Considerations">
<t>This document requests no action by IANA. </t>
</section> <!-- iana -->
<section anchor="ack" title="Acknowledgements">
<t>An invaluable review of this document was performed by Bob Braden. Helpful comments
were made by Sheng Jiang.</t>
<t>This document was produced using the xml2rfc tool
<xref target="RFC2629"/>.</t>
</section> <!-- ack -->
<section anchor ="changes" title="Change log">
<t>draft-hu-flow-label-cases-00: first I-D version, 2010-04-19</t>
<t>draft-hu-flow-label-cases-01: updated following review comments, 2010-08-18</t>
<t>draft-hu-flow-label-cases-02: updated following more review comments, 2010-09-30</t>
<t>draft-hu-flow-label-cases-03: updated following more review comments, 2011-02-23</t>
</section> <!-- changes -->
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.1752"?>
<?rfc include="reference.RFC.1883"?>
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.4080"?>
<?rfc include="reference.RFC.1710"?>
<?rfc include="reference.RFC.1707"?>
<?rfc include="reference.RFC.2474"?>
<?rfc include="reference.RFC.1809"?>
<?rfc include="reference.RFC.3697"?>
<?rfc include="reference.RFC.1633"?>
<?rfc include="reference.RFC.3140"?>
<?rfc include="reference.RFC.2629"?>
<?rfc include="reference.RFC.2205"?>
<?rfc include="reference.RFC.3724"?>
<?rfc include="reference.RFC.3031"?>
<!-- I-D references follow. Preferred symbolic labels at the right. I don't know
how to get them to come out in xml2rfc. -->
<?rfc include="reference.I-D.conta-diffserv-ipv6-fl-classifier"?> <!-- Conta01b -->
<?rfc include="reference.I-D.chakravorty-6lsa"?> <!-- Chakravorty08b -->
<?rfc include="reference.I-D.banerjee-flowlabel-ipv6-qos"?> <!-- Banerjee02 -->
<?rfc include="reference.I-D.roberts-inband-qos-ipv6"?> <!-- Roberts05 -->
<?rfc include="reference.I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching"?> <!-- Beckman07a -->
<?rfc include="reference.I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp"?> <!-- Beckman07b -->
<?rfc include="reference.I-D.blake-ipv6-flow-label-nonce"?> <!-- Blake09 -->
<?rfc include="reference.I-D.ietf-6man-flow-ecmp"?> <!-- Carpenter11 -->
<?rfc include="reference.I-D.ietf-6man-flow-update"?> <!-- Amante11 -->
<?rfc include="reference.I-D.adams-tsvwg-flow-signalling-codepoint"?> <!-- Adams08 -->
<?rfc include="reference.I-D.donley-softwire-dslite-flowlabel"?> <!-- Donley11 -->
<?rfc include="reference.I-D.ietf-mext-flow-binding"?> <!-- Tsirtsis10 -->
<?rfc include="reference.I-D.ietf-roll-rpl"?> <!-- RPL -->
<!-- ********** This reference is specifically to version 07 of the draft and is therefore
********** hand-crafted instead of using the I-D bibliography. -->
<reference anchor='RPL-07'>
<front>
<title>RPL: IPv6 Routing Protocol for Low power and Lossy Networks</title>
<author initials="T." surname="Winter" fullname="T. Winter"/>
<author initials="P." surname="Thubert" fullname="P. Thubert"/>
<date month='March' year='2010'/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-roll-rpl-07"/>
</reference>
<!-- ********** The following drafts were not present in the I-D bibliography, so their
********** references have been hand-crafted. -->
<reference anchor='Metzler00'>
<front>
<title>An end-to-end usage of the IPv6 flow label</title>
<author initials="J." surname="Metzler" fullname="Jochen Metzler"/>
<author initials="S." surname="Hauth" fullname="Stephan Hauth"/>
<date month='November' year='2000'/>
</front>
<seriesInfo name="Internet-Draft" value="draft-metzler-ipv6-flowlabel-00" />
</reference>
<reference anchor='Conta01a'>
<front>
<title>A proposal for the IPv6 Flow Label Specification</title>
<author initials="A. " surname="Conta" fullname="Alex Conta"/>
<author initials="B." surname="Carpenter" fullname="Brian Carpenter"/>
<date month='July' year='2001'/>
</front>
<seriesInfo name="Internet-Draft" value="draft-conta-ipv6-flow-label-02" />
</reference>
<reference anchor='Hagino01'>
<front>
<title>Socket API for IPv6 flow label field</title>
<author initials="J. " surname="Hagino" fullname="Jun-ichiro itojun Hagino"/>
<date month='April' year='2001'/>
</front>
<seriesInfo name="Internet-Draft" value="draft-itojun-ipv6-flowlabel-api-01" />
</reference>
<!-- ********** Non RFC or I-D references follow. -->
<reference anchor='Deering93'>
<front>
<title>SIPP Overview and Issues</title>
<author initials="S." surname="Deering" fullname="Steve Deering"/>
<date month='November' year='1993'/>
</front>
<seriesInfo name="Minutes of the Joint Sessions of the SIP and PIP Working Groups" value='' />
</reference>
<reference anchor='Braden10'>
<front>
<title>Private Communication</title>
<author initials="R." surname="Braden" fullname="Robert Braden"/>
<date year='2010'/>
</front>
</reference>
<reference anchor='Lee04'>
<front>
<title>A QoS Improvement Scheme for Real-Time Traffic Using IPv6 Flow Labels</title>
<author initials="I. H." surname="Lee" fullname="I.H. Lee"/>
<author initials="S. J." surname="Kim" fullname="S.-J. Kim"/>
<date year='2004'/>
</front>
<seriesInfo name="Lecture Notes in Computer Science" value='Vol. 3043' />
</reference>
<reference anchor='Lin06'>
<front>
<title>End-to-End QoS Provisioning by Flow Label in IPv6</title>
<author initials="C. N." surname="Lin" fullname="C.-N. Lin"/>
<author initials="P. C." surname="Tseng" fullname="P.-C. Tseng"/>
<author initials="W. S." surname="Hwang" fullname="W.-S. Hwang"/>
<date year='2006'/>
</front>
<seriesInfo name="JCIS" value='' />
</reference>
<reference anchor='Prakash04'>
<front>
<title>Using the 20 bit flow label field in the IPv6
header to indicate desirable quality of service on the
internet</title>
<author initials="B." surname="Prakash" fullname="B. Prakash"/>
<date year='2004'/>
</front>
<seriesInfo name="University of Colorado" value='(M.Sc. Thesis)' />
</reference>
<reference anchor='Chakravorty08a'>
<front>
<title>Challenges of IPv6 Flow Label implementation</title>
<author initials="S." surname="Chakravorty" fullname="S. Chakravorty"/>
<date year='2008'/>
</front>
<seriesInfo name="Proc IEEE MILCOM2008" value=""/>
</reference>
<reference anchor="Carpenter02">
<front>
<title>Differentiated Services in the Internet</title>
<author initials="B." surname="Carpenter" fullname="Brian Carpenter"/>
<author initials="K." surname="Nichols" fullname="Kathie Nichols"/>
<date year="2002"/>
</front>
<seriesInfo name="Proc IEEE" value="90 (9) 1479-1494"/>
</reference>
<reference anchor="Saltzer84">
<front>
<title>End-To-End Arguments in System Design</title>
<author initials="J.H. " surname="Saltzer" fullname="J.H. Saltzer"/>
<author initials="D.P." surname="Reed" fullname="D.P. Reed"/>
<author initials="D.D." surname="Clark" fullname="D.D. Clark"/>
<date year="1984"/>
</front>
<seriesInfo name="ACM TOCS" value="2 (4) 277-288"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 04:39:24 |