One document matched: draft-carpenter-6man-flow-update-02.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'>

<!-- 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">


<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-carpenter-6man-flow-update-02" category="exp" updates="3697">  


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


<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>KuiKe Building, No.9 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="13" month="April" year="2010" />

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

 


<abstract>

<t>Various uses proposed for the IPv6 flow label are incompatible with its existing specification. 
This document describes changes to the specification that permit additional use cases as well
as allowing continued use of the previous specification.
</t>
    
</abstract>
</front>

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


<t>The flow label field in the IPv6 header is reserved but left experimental by <xref target="RFC2460"/> and
is specified by <xref target="RFC3697"/>. 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>The second two rules appear to forbid a usage in which the bits of the flow label are encoded
with a specific semantic meaning, or are assumed to have any particular property such as randomness.
However, both before and after these rules were laid down, a considerable number
of proposals for use of the flow label have been published that seem incompatible with
them. Examples are

<xref target="I-D.conta-ipv6-flow-label"/>,
<xref target="I-D.conta-diffserv-ipv6-fl-classifier"/>,
<xref target="I-D.chakravorty-6lsa"/>,
<xref target="I-D.banerjee-flowlabel-ipv6-qos"/>,
<xref target="I-D.metzler-ipv6-flowlabel"/>, 
<xref target="LeeKim"/>,
<xref target="LinTseng"/>, and
<xref target="Prakash"/>.
These authors propose use cases in which some combination of the following
options 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 coded: they have specific meanings
 understood by routers and switches along the path. </t>
 <t>The coding is related to the required quality of service, as well as identifying a flow. </t>
 <t>The 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>Although <xref target="I-D.roberts-inband-qos-ipv6"/> does not explicitly consider the flow label,
it requests hop-by-hop functionality in IPv6 packets very similar to what is needed by the
above proposals.</t>

<t>We can conclude that a considerable number of researchers and designers are
stymied by RFC 3697. On the other hand, proposals such as
<xref target="I-D.martinbeckman-ietf-ipv6-fls-ipv6flowswitching"/>,
<xref target="I-D.martinbeckman-ietf-ipv6-amp-ipv6hcamp"/>,
<xref target="I-D.blake-ipv6-flow-label-nonce"/>, and
<xref target="I-D.carpenter-flow-ecmp"/>
appear to be compatible with RFC 3697. The latter two are based on
the originator of a packet choosing a pseudo-random flow label for each flow.
Thus, we can also conclude that there is a useful
role for this approach too. The proposal below is intended to resolve this dilemma by
allowing both approaches to co-exist. </t>
 
</section> <!-- intro -->

<section title="Normative Notation">
 <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in <xref target="RFC2119"/>.</t>
 </section>

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

<t>We note that although RFC 3697 requires the flow label to be delivered
unchanged, it is not included in any transport layer pseudo-header checksums
nor in IPsec authentication <xref target="RFC4302"/>. We also note that 
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; neither operating systems nor
applications currently 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>The purpose of the proposed change is that the flow label should be
available for domain-specific use, with locally defined semantics, without
preventing uses that are compatible with RFC 3697. There should
be no impact on specifications other than RFC 3697 and no impact on currently
operational software and hardware. </t>

<t>The rules of RFC 3697 are modified as follows: </t>
<list style="numbers">

<t>If and only if the flow label in an IPv6 packet has the default value of zero, then a router MAY
set it to a value between between 1 and 0xFFFFF. This option modifies the rule that the flow label must be
delivered unchanged, by allowing exactly one router to set it if the source host did not
set it. </t>

<t>If this is done, all packets in a given flow MUST be given the same flow label value.
A flow is defined in this case as all packets with the same source and destination IPv6
addresses and port numbers and the same transport protocol number, i.e., the same
final Next Header value <xref target="RFC2460"/>. This rule constrains the definition of a flow
in RFC 3697 for the specific case that a router sets the flow label. However, it does not
constrain the bits of the flow label in any particular way. </t>

<t>An administratively defined domain containing hosts and routers MAY use a locally
defined scheme for the bits of the flow label. This is known as a flow label domain,
analogous to a differentiated services domain <xref target="RFC2474"/>. Hosts in such a
domain MUST be configured either to set a default (zero) flow label in all IPv6 packets,
or to apply the locally defined scheme. 
When a locally defined scheme is used, packets entering the flow label
domain from outside might contain an invalid label according to that scheme. Therefore,
border routers MAY treat all packets entering the flow label domain as if they had a 
default (zero) flow label. This option will be applied in any case where incorrect
flow label formats might cause unpredictable behaviour. </t>

<t>Unless a locally defined scheme for the bits of the flow label is in use, the label,
whether set by the source host according to RFC 3697, or by a router according to rules
1 and 2 above, SHOULD contain a pseudo-random value between 1 and 0xFFFFF. 
The intention of this rule is to encourage load balancing solutions based on using the 
flow label as input to a hash function, e.g., <xref target="I-D.carpenter-flow-ecmp"/>,
or to  enable behaviour such as defined in <xref target="I-D.blake-ipv6-flow-label-nonce"/>.
This recommendation constrains the choice of flow label value more than RFC 3697. </t>

</list>

<t>The following are the consequences of the above rules combined with those in RFC 3697:</t>

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

<t>Sending hosts wishing to rely only on RFC 3697 behaviour will choose labels between 1 and 0xFFFFF,
which should be pseudo-random according to rule 4 above. </t>

<t>Locally defined behaviour of the flow label will be limited to consistent
administratively defined domains. </t>

<t>Sending hosts wishing to use locally defined behaviour may continue to send
all-zero labels, relying on a router in the local flow label domain to set a value
according to rules 1, 2 and 3 above.
Alternatively, they may set a label according to locally defined rules. </t>

<t>Routers wishing to implement a locally defined behaviour will 
set a label according to rules 1, 2 and 3 above, if and only if the incoming
flow label is all-zero; if the flow label is not all-zero they must not change it,
according to rule 1 above. </t>

<t>There is an exception to immutability for border routers of a flow label domain, 
when external packets arrive with a non-zero flow label. </t>


</list>


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

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

<t>Hosts that set a default (zero) flow label and ignore the flow label on receipt will be unaffected 
by implementations of this specification. In general, it is assumed that hosts will ignore the
flow label on receipt; it cannot be safely used as an end-to-end transport or application layer
signal of any kind. </t>

<t>Routers that ignore
the flow label will be unaffected by implementations of this specification. </t>

<t>Hosts that set a default (zero) flow label and are in a flow label domain where routers
adopt rules 1, 2, and 3 or 4 in <xref target="spec"/> will benefit from
whatever flow label handling is used in the local domain. 
Clearly, the rules b and c quoted from RFC 3697 in <xref target="intro"/>
have no effect within the local domain, where the locally defined rules
(whatever they are) replace them. </t>

<t>Hosts and routers that adopt rule 4 by setting a pseudo-random flow label
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. Again, rules b and c have no effect. </t>

<t>If a locally defined flow label scheme is used, so that rule 4 is not implemented,
then packets leaving the local domain may contain flow label values
that are not pseudo-random. However, because of rule 2, the flow label will still
be part of the signature of a single packet flow, so it may still be used as part
of a load balancing hash. Rules b and c remain true but do not prevent such usage.
To allow for these rules, the load balancing hash function needs to be
be designed to allow for a possibly non-random flow label, and traffic containing
a non-random flow label might not gain full benefit from load balancing. </t>

<t>The rules defined in this document are intended to allow both RFC 3697 usage
of the flow label in the general case, and a wide variety of locally defined schemes.
Such schemes do not need any global assignments of bits in the flow label,
and should not have noticeable impact on backwards compatibility or
on domains not using them. </t>

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

<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.  On the other hand, a pseudo-random flow label cannot be readily
guessed by an off-path attacker. See RFC 3697 for further discussion. </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 Remi Despres, Mark Smith
and 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">

<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="Normative References">



&RFC2460;
&RFC3697;

&RFC2119;





</references>

<references title="Informative References">

&RFC2629;
&RFC2474;
&RFC4302;
&DRAFT-conta1;
&DRAFT-conta2;
&DRAFT-chakra;
&DRAFT-bannerj;
&DRAFT-metzler;
&DRAFT-roberts;
&DRAFT-beck1;
&DRAFT-beck2;
&DRAFT-nonce;
&DRAFT-ecmp;

<reference anchor='I-D.metzler-ipv6-flowlabel'>
<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="draft-metzler-ipv6-flowlabel-00" value='(work in progress)' />
</reference>

<reference anchor='I-D.conta-ipv6-flow-label'>
<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="draft-conta-ipv6-flow-label-02" value='(work in progress)' />
</reference>



<reference anchor='LeeKim'>
<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='LinTseng'>
<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='Prakash'>
<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>

    
</references>

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

<t>Two more complex alternative approaches were 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 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>