One document matched: draft-ietf-6man-flow-update-07.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"?>        <!-- Use symbolic labels for 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"?>

<!-- You need one entry like the following for each RFC referenced -->


<!ENTITY RFC2119 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119'>
<!ENTITY RFC2629 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629'>
<!ENTITY RFC2460 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460'>
<!ENTITY RFC3697 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3697'>
<!ENTITY RFC4302 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4302'>
<!ENTITY RFC2474 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474'>
<!ENTITY RFC2205 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2205'>


<!-- You need one entry like the following for each I-D referenced -->

<!-- ENTITY DRAFT-conta1 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.conta-ipv6-flow-label.xml"> -->
<!-- ENTITY DRAFT-metzler SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.metzler-ipv6-flowlabel.xml"> -->


<!ENTITY DRAFT-conta2 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.conta-diffserv-ipv6-fl-classifier.xml">
<!ENTITY DRAFT-chakra SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chakravorty-6lsa.xml">
<!ENTITY DRAFT-bannerj SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.banerjee-flowlabel-ipv6-qos.xml">
<!ENTITY DRAFT-roberts SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.roberts-inband-qos-ipv6.xml">
<!ENTITY DRAFT-beck1 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching.xml">
<!ENTITY DRAFT-beck2 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp.xml">
<!ENTITY DRAFT-nonce SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.blake-ipv6-flow-label-nonce.xml">
<!ENTITY DRAFT-ecmp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.carpenter-flow-ecmp.xml">
<!ENTITY DRAFT-hu SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hu-flow-label-cases.xml">
<!ENTITY DRAFT-gont SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.gont-6man-flowlabel-security.xml">
<!ENTITY DRAFT-3697bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-flow-3697bis.xml">


<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-ietf-6man-flow-update-07" category="info">  


<front>
<title abbrev="Flow Label Update">Rationale for update to the IPv6 flow label specification</title>

<author initials="S." surname="Amante" fullname="Shane Amante">
<organization abbrev="Level 3"></organization>
  <address>
      <postal>
        <street>Level 3 Communications, LLC</street>
        <street>1025 Eldorado Blvd</street>
        <city>Broomfield</city>
        <region>CO</region>
        <code>80021</code>
        <country>USA</country>
      </postal>
      <email>shane@level3.net</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>

   <author fullname="Sheng Jiang" initials="S.J." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>
      <address>
        <postal>
          <street>Huawei Building, No.3 Xinxi Rd.,</street>
          <city>Shang-Di Information Industry Base, Hai-Dian District, Beijing</city>
          <country>P.R. China</country>
        </postal>
        <email>shengjiang@huawei.com</email>
      </address>
    </author>



 
<date day="5" month="July" year="2011" />

<area>Internet</area>
<workgroup>6MAN</workgroup>

 


<abstract>

<t>Various published proposals for use of the IPv6 flow label are incompatible with 
its original specification in RFC 3697. Furthermore, very little practical use is
made of the flow label, partly due to some uncertainties about the correct interpretation 
of the specification. This document discusses and motivates changes to the specification 
in order to clarify it, and to introduce some additional flexibility.
</t>
    
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction">


<t>The flow label field in the IPv6 header was reserved but left experimental by <xref target="RFC2460"/>,
which mandates only that "Hosts or routers
   that do not support the functions of the Flow Label field are
   required to set the field to zero when originating a packet, pass the
   field on unchanged when forwarding a packet, and ignore the field
   when receiving a packet." </t>


<t>The flow label field
was normatively specified by <xref target="RFC3697"/>. In particular, we quote three rules
from that RFC:</t>
<list style="letters">
<t>"The Flow Label value set by the source MUST be delivered unchanged to
   the destination node(s)."</t>
<t>"IPv6 nodes MUST NOT assume any mathematical or other properties
of the Flow Label values assigned by source nodes." </t>
<t>"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." </t>
</list>

<t>Additionally, RFC 3697 leaves it undefined what method a host should adopt by default
to choose the value of the flow label, if no specific method is in use. It was expected that
various signaling methods might be defined for agreeing on values of the flow label, but
no such methods have been standardised, except a pre-existing option in RSVP <xref target="RFC2205"/>. </t>

<t>The flow label is hardly used in practice in widespread IPv6 implementations, although
some operating systems do set it <xref target="McGann05"/>. To some extent
this is due to the main focus being on basic deployment of IPv6, but the absence of a default
method of choosing the flow label value means that most host implementations simply set it to zero. 
There is also anecdotal evidence that the rules quoted above have led to uncertainty about exactly 
what is possible. Furthermore, various use cases have been
proposed that infringe one or another of the rules. None of these proposals
has been accepted as a standard and in practice there is no significant deployment
of any mechanism to set the flow label. </t>

<t>
The intention of this document is to explain this situation
in more detail and to motivate changes to RFC 3697 intended to remove the uncertainties and encourage
active usage of the flow label. It does not formally update RFC 3697, but it serves as
background material for <xref target="I-D.ietf-6man-flow-3697bis"/>. </t>

</section> <!-- intro -->

<section anchor="impact" title="Impact of current specification">

<t>Rule (a) makes it impossible for the routing system to use the flow label as any form
of dynamic routing tag. This was a conscious choice in the early design of IPv6 and there
appears to be no practical possibility of revisiting this choice at this stage in the
deployment of IPv6, which uses conventional routing mechanisms like those used for IPv4. 
However, this rule also makes
it impossible to make any use at all of the flow label unless hosts choose to set it. It also
forbids clearing the flow label for security reasons. </t>

<t>This last point highlights the security properties, or rather the lack of them,
of the flow label. The flow label field is always unprotected as it travels
through the network, because there is no IPv6 header
checksum, and the flow label is not included in transport pseudo-header checksums, nor in
IPsec checksums. As a result, intentional and malicious changes
to its value cannot be detected. Also, it could be used as a
covert data channel, since apparently pseudo-random flow label values could in fact
consist of covert data <xref target="NIST"/>.  If the flow label were to carry quality of service
semantics, then like the diffserv code point <xref target="RFC2474"/>, it would not be
intrinsically trustworthy across domain boundaries. As a result, some security
specialists believe that flow labels should be cleared for safety <xref target="I-D.gont-6man-flowlabel-security"/>,
<xref target="NSA"/>. 
These points must be considered when discussing the immutability of the flow label across domain
boundaries. In fact, the adjective "immutable" is confusing, since it implies a property
that the flow label field does not actually possess. It has therefore been abandoned
as a descriptive term in <xref target="I-D.ietf-6man-flow-3697bis"/>. It is only used in the
present document to explain why it has been abandoned. </t>

<t>Rule (b) appears to forbid any usage in which the bits of the flow label are encoded
with a specific semantic meaning. However, the words "MUST NOT assume" are to be interpreted
precisely - if a router knows by configuration or by signaling that the flow label has
been assigned in a certain way, it can make use of that knowledge. It is not made clear
by the rule that there is an implied distinction between stateless models (in which case
no assumption may be made) and stateful models (in which the router has explicit knowledge). </t>


<t>If the word "alone" is overlooked, rule (c) has sometimes
been interpreted to forbid the use of the flow label as part of a hash used by load distribution mechanisms.
In this case too, the word "alone" needs to be taken into account - a router is allowed to
combine the flow label value with other data in order to produce a uniformly distributed hash. </t>

<t>Both before and after these rules were laid down, a considerable number
of proposals for use of the flow label were published that seem incompatible with
them. Numerous examples and an analysis are presented in <xref target="I-D.hu-flow-label-cases"/>.
Those examples propose use cases in which some or all of the following
apply:</t>
 <list style="symbols">
 <t>The flow label may be changed by intermediate systems. </t>
 <t>It doesn't matter if the flow label is changed, because the receiver doesn't use it. </t>
 <t>Some or all bits of the flow label are encoded: they have specific meanings
 understood by routers and switches along the path. </t>
 <t>The encoding is related to the required quality of service, as well as identifying a flow. </t>
 <t>The flow label is used to control forwarding or switching in some way. </t>
 </list>

<t>These proposals all require either some form of encoding of semantics
in the bits of the flow label, or the ability for routers to modify
the flow label, or both. Thus they appear to infringe the rules from RFC 3697 
quoted above. </t>

<t>We can conclude that a considerable number of researchers and designers have been
stymied by RFC 3697. On the other hand, some other proposals discussed in
<xref target="I-D.hu-flow-label-cases"/> appear to be compatible with RFC 3697.
Several are based on the originator of a packet choosing a pseudo-random flow label for 
each flow, which is one option suggested in RFC 3697. Thus, we can also conclude that there is a useful
role for this approach.  </t>

<t>If our goal is for the flow label to be used in practice, the conflict between
the various approaches creates a dilemma. There appear to be two major options: </t>
<list style="numbers">
<t>Discourage locally defined and/or stateful use of the flow label. 
Strengthen RFC 3697 to say that hosts should set
a label value, without necessarily creating state, which would clarify and limit its possible uses.
In particular, its use for load distribution and balancing would be encouraged. </t> 

<t>Relax the rules to encourage locally defined and/or stateful use of the flow label. This approach would make the flow
label completely mutable and would exclude use cases depending on strict end-to-end immutability. It
would encourage applications of a pseudo-random flow label, such as load distribution,
on a local basis, but it would exclude end-to-end applications.
</t>
</list>

<t>During 2010/2011 there was considerable debate about these options and variants
of them, with a variety of proposals in previous versions of this document and in
mailing list discussions. After these discussions, there appears to be
a view that simplicity should prevail, and that complicated proposals such as
defining quality of service semantics in the flow label, or sub-dividing the flow label
field into smaller sub-fields, will not prove efficient
or deployable, especially in high speed routers. There is also a clearly expressed view 
that using the flow label for various forms of stateless load distribution is the best simple 
application for it. At the same time, it is necessary to recognize that the strict
immutability rule has drawbacks as noted above. </t>

<t>Even under the rules of RFC 3697, the flow label is intrinsically untrustworthy,
because modifications en route cannot be detected. For this reason, even with
the current strict immutability rule, downstream nodes cannot rely mathematically on the value being unchanged.
In this sense, any use of the flow label must be viewed as an optimisation on a best
effort basis; a packet with a changed (or zero) flow label value should never cause
a hard failure. </t>

<t>The remainder of this document discusses specific modifications to the standard, 
which are defined normatively in a companion document <xref target="I-D.ietf-6man-flow-3697bis"/>. </t>
 
</section> <!-- impact -->


<section anchor="spec" title="Changes to specification">

<t>Although RFC 3697 requires the flow label to be delivered
unchanged, as noted above, it is not included in any transport layer pseudo-header checksums
nor in IPsec authentication <xref target="RFC4302"/>.  
Both RFC 2460 and RFC 3697 define the default flow label to be zero. 
At the time of writing, this is the observed value in an
overwhelming proportion of IPv6 packets; the most widespread operating systems and
applications do not set it, and routers do not rely on it. Thus there is no reason
to expect operational difficulties if a careful change is made to the rules of RFC 3697. </t>

<t>In particular, the facts that the label is not checksummed and rarely used mean
that the "immutability" of the label can be moderated without serious operational
consequences. </t>

<t>The purposes of the proposed changes are to remove the uncertainties left
by RFC 3697, in order to encourage setting of the flow label by default, and
to enable its generic use. The proposed generic use is to
encourage uniformly distributed flow labels that can be used to assist load distribution or balancing.
There should be no impact on existing IETF specifications other than RFC 3697 and no impact on currently
operational software and hardware. </t>

<t>A secondary purpose is to allow changes to the flow label in a limited
way, to allow hosts that do not set the flow label to benefit from it
nevertheless. The fact that the flow label may in practice be changed en route is also reflected
in the reformulation of the rules. </t>

<t>A general description of the changes follows. The normative text is to be found
in <xref target="I-D.ietf-6man-flow-3697bis"/>.</t>

<t>The definition of a flow is subtly changed from RFC 3697 to allow any node,
not just the source node, to set the flow label value. However, it is recommended
that sources should set a uniformly distributed flow label value in all flows, replacing 
the less precise recommendation made in Section 3
of RFC 3697. Both stateful and stateless methods of assigning a uniformly distributed
value could be used. </t>

<t>Flow label values should be chosen such that their bits exhibit
   a high degree of variability, thus making them suitable for use as part of
   the input to a hash function used in a load distribution scheme.
   At the same time, third parties should be unlikely to be able to
   guess the next value that a source of flow labels will choose. </t>

<t>In statistics, a discrete uniform distribution is defined as
   a probability distribution in which each value in a given range
   of equally spaced values (such as a sequence of integers) is equally
   likely to be chosen as the next value. The values in such a distribution
   exhibit both variability and unguessability. Thus, an approximation to
   a discrete uniform distribution is preferable as the source of
   flow label values. In contrast, an implementation in which flow labels
   are assigned sequentially is definitely not recommended, to avoid guessability. </t>

<t>In practice it is expected that a uniform distribution of flow label values
   will be approximated by use of a hash function or a pseudo-random number
   generator.  Either approach will produce values which will appear pseudo-random
   to an external observer. </t>

<t>Section 3 of RFC 3697 allows nodes to participate in an unspecified stateful
method of flow state establishment. The changes do not remove that option, but
it is made clear that stateless models are also possible and are the recommended default.
The specific text about requirements for stateful models has been reduced to
a bare minimum requirement that they do not interfere with the stateless model. 
To enable stateless load distribution at any point in the
Internet, a node using a stateful model should never send packets
whose flow label values do not conform to a uniform distribution. </t>

<t>The main novelty is that a forwarding node (typically a first-hop or ingress router) may set the flow label value if the source
has not done so, according to the same recommendations that apply to the source. 
This might place a considerable processing load on ingress routers that choose to do so,
even if they adopted a stateless method of 
flow identification and label assignment. </t>

<t>The value of the flow label, once it has been set, must not be changed. However,
some qualifications are placed on this rule, to allow for the fact that the flow label is
an unprotected field and might be misused. No Internet-wide mechanism can depend 
mathematically on immutable flow labels. The new rules require that flow labels exported
to the Internet should always be either zero or uniformly distributed, but even this cannot
be relied on mathematically. Use cases need to be robust against non-conforming
flow label values. This will also enhance compatibility with any legacy hosts that set
the flow label according to RFC 2460 or RFC 3697. </t>

<t>A complication that led to much discussion is the possibility that hosts inside a particular network domain
might use a stateful method of setting the flow label, and that packets bearing stateful labels
might then erroneously escape the domain and be received by nodes performing stateless processing such as
load balancing. This might result in undesirable operational implications (e.g., congestion,
reordering) for not only the inappropriately flow-labelled packets, but also well-behaved flow-labelled packets, during
forwarding at various intermediate devices.  It was proposed to suggest that border routers might "correct" this problem
by overwriting such labels in packets leaving the domain. 
However, neither domain border egress routers nor intermediate
routers/devices (using a flow label, for example, as a part of an
input key for a load-distribution hash) can determine by
inspection that a value is not part of a uniform distribution. 
Thus there is no way that such values can be detected and "corrected". Therefore,
the recommendation to choose flow labels from a uniform distribution also applies to stateful schemes. </t>


</section> <!-- spec -->

<section anchor="disc" title="Discussion">

<t>The following are some practical consequences of the above changes:</t>

<list style="symbols">
<t>Sending hosts that are not updated will in practice continue to send all-zero labels. If there
is no label-setting router along the path taken by a packet, the label
will be delivered as zero. </t>

<t>Sending hosts conforming to the new specification will by default choose uniformly distributed 
labels between 1 and 0xFFFFF. </t>

<t>Sending hosts may continue to send all-zero labels, in which case an ingress router may set uniformly distributed 
labels between 1 and 0xFFFFF. </t>

<t>The flow label is no longer unrealistically asserted to be strictly immutable; it is recognised
that it may, incorrectly, be changed en route. In some circumstances
this will break end-to-end usage, e.g. potential detection of third-party spoofing
attacks <xref target="I-D.gont-6man-flowlabel-security"/>.
 </t>

<t>The expected default usage of the flow label is some form of stateless
load distribution, such as the ECMP/LAG usage defined in <xref target="I-D.carpenter-flow-ecmp"/>. </t>


<t>If the new rules are followed, all IPv6 traffic flows on the Internet should have zero or uniformly distributed
flow label values. </t>


</list>

<t>From an operational viewpoint, existing IPv6 hosts that set a default (zero) flow label value
and ignore the flow label on receipt will be unaffected 
by implementations of the new specification. In general, it is assumed that hosts will ignore the
value of the flow label on receipt; it cannot be relied on as an end-to-end 
signal. However, this doesn't apply if a cryptographically generated label is being
used to detect attackers <xref target="I-D.gont-6man-flowlabel-security"/>. </t>

<t>Similarly, routers that ignore
the flow label will be unaffected by implementations of the specification. </t>

<t>Hosts that set a default (zero) flow label but are in a domain where routers
set a label as recommended in <xref target="spec"/>
will benefit from whatever flow label handling is used on the path. 
</t>

<t>Hosts and routers that adopt the recommended mechanism
will enhance the performance of any load balancing devices that include the flow label
in the hash used to select a particular path or server, even when
packets leave the local domain. </t>

</section> <!-- disc -->

<section anchor="security" title="Security Considerations">

<t>See  <xref target="I-D.ietf-6man-flow-3697bis"/>
and <xref target="I-D.gont-6man-flowlabel-security"/> for full discussion. 
Some useful remarks are in <xref target="Partridge"/>. </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>The authors are grateful to Qinwen Hu for general
discussion about the flow label and for his work in searching the literature.
Valuable comments and contributions were made by
Ran Atkinson,
Fred Baker,
Steve Blake,
Remi Despres,
Alan Ford,
Fernando Gont,
Brian Haberman,
Tony Hain,
Joel Halpern,
Chris Morrow,
Thomas Narten,
Pekka Savola,
Mark Smith,
Pascal Thubert,
Iljitsch van Beijnum,
and other participants in the 6man working group.</t>

<t>This document was produced using the xml2rfc tool
<xref target="RFC2629"/>.</t>

</section> <!-- ack -->


<section anchor ="changes" title="Change log [RFC Editor: please remove]">

<t>draft-ietf-6man-flow-update-07: minor editorial fix, AD comments, 2011-07-05</t>
<t>draft-ietf-6man-flow-update-06: updated again to be in step with RFC 3697bis, 2011-05-11</t>
<t>draft-ietf-6man-flow-update-05: updated again to be in step with RFC 3697bis, 2011-05-02</t>
<t>draft-ietf-6man-flow-update-04: updated again to be in step with RFC 3697bis, 2011-03-13</t>
<t>draft-ietf-6man-flow-update-03: updated to be in step with RFC 3697bis, 2011-02-26</t>
<t>draft-ietf-6man-flow-update-02: repurposed as rationale for update of RFC 3697, 2011-01-31</t>
<t>draft-ietf-6man-flow-update-01: clarified that this is not a formal update of RFC 3697, clarified text about domains exporting inappropriate labels, 2011-01-10</t>
<t>draft-ietf-6man-flow-update-00: adopted as WG document at IETF 79, mutability rules adjusted according to WG discussion, 2010-12-03</t>
<t>draft-carpenter-6man-flow-update-04: even more simplified according to WG discussion, 2010-09-16</t>
<t>draft-carpenter-6man-flow-update-03: futher simplified according to WG discussion, 2010-05-07</t>
<t>draft-carpenter-6man-flow-update-02: revised and simplified according to WG discussion, 2010-04-13</t>
<t>draft-carpenter-6man-flow-update-01: revised according to mail list discussion, 2010-03-05</t>
<t>draft-carpenter-6man-flow-update-00: original version, 2010-02-18</t>


</section> <!-- changes -->

</middle>

<back>

<references title="Informative References">
&RFC2460;
&RFC2629;
&RFC2474;
&RFC4302;
&RFC3697;
&RFC2205;



&DRAFT-beck1;
&DRAFT-ecmp;
&DRAFT-hu;
&DRAFT-gont;
&DRAFT-3697bis;

<reference anchor='McGann05'>
<front>
<title>Flow Label Filtering Feasibility</title>
<author initials="O." surname="McGann" fullname="Orla McGann"/>
<author initials="D." surname="Malone" fullname="David Malone"/>
<date year='2005'/>
</front>
<seriesInfo name="European Conference on Computer Network Defence" value=""/>
</reference>

<reference anchor='NSA' target="http://www.nsa.gov/ia/_files/ipv6/I733-041R-2007.pdf">
<front>
<title>Firewall Design Considerations for IPv6</title>
<author initials="C.A." surname="Potyraj" fullname="Casimir A. Potyraj"/>
<date year='2007'/>
</front>
<seriesInfo name="National Security Agency" value="I733-041R-2007"/>
</reference>

<reference anchor='NIST' target="http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf">
<front>
<title>Guidelines for the Secure Deployment of IPv6 </title>
<author initials="S." surname="Frankel" fullname="Sheila Frankel"/>
<author initials="R." surname="Graveman" fullname="Richard Graveman"/>
<author initials="J." surname="Pearce" fullname="John Pearce"/>
<author initials="M." surname="Rooks" fullname="Mark Rooks"/>
<date year='2010'/>
</front>
<seriesInfo name="National Institute of Standards and Technology" value="Special Publication 800-119"/>
</reference>

<reference anchor='Partridge' target="http://www.ir.bbn.com/documents/articles/MILCOM_Paper_from_Proceedings.pdf">
<front>
<title>Information Assurance and the Transition to IP Version 6 (IPv6)</title>
<author initials="C." surname="Partridge" fullname="Craig Partridge"/>
<author initials="A.W." surname="Arsenault" fullname="Alfred W. Arsenault"/>
<author initials="S.T." surname="Kent" fullname="Stephen T. Kent"/>
<date year='2007'/>
</front>
<seriesInfo name="Military Communications Conference (MILCOM 2007)" value=" "/>
</reference>

    
</references>

<section anchor="Appendix1" title="Alternative Approaches">

<t>A model was discussed in an earlier version of this document which defined a notion
of 'flow label domain' analogous to a differentiated
services domain <xref target="RFC2474"/>. This model would have encouraged
local usage of the flow label as an alternative to any form of generic use,
but it required complex rules for the behaviour of domain boundary routers, and proved
controversial in discussion. </t>

<t>Two even more complex alternative approaches were also considered and rejected. </t>

<t>The first was to distinguish locally significant flow labels from those
conforming to RFC 3697 by setting or clearing the most significant bit (MSB)
of the flow label. This led to quite complicated rules, seems impossible
to make fully self-consistent, and was not considered practical. </t>

<t>The second was to use  a specific differentiated
services code point (DSCP)<xref target="RFC2474"/> in the Traffic Class octet 
instead of the MSB of the flow label itself, to flag a locally defined behaviour.
A more elaborate version of this was proposed
in <xref target="I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching"/>.
There are two issues with this approach. One is that DSCP values
are themselves only locally significant, inconsistent with the end-to-end nature
of the original flow label definition. Secondly, it seems unwise to meld the
semantics of differentiated services, which are currently deployed,
with the unknown future semantics of flow label usage. However, this approach,
while not recommended, does not appear to violate any basic principles if applied
strictly within a single differentiated services domain. </t>

</section>

</back>
</rfc>