One document matched: draft-carpenter-6man-flow-update-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"?>        <!-- 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">
<!ENTITY DRAFT-hu SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hu-flow-label-cases.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-03" category="info">  


<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="7" month="May" year="2010" />

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

 


<abstract>

<t>Various published proposals for use of the IPv6 flow label are incompatible with 
its existing specification in RFC 3697. 
This document proposes changes to the specification that permit additional use cases. The concept
of flow label domains is introduced, with the label possibly being rewritten at domain boundaries.
</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 rule appears to forbid a usage in which the bits of the flow label are encoded
with a specific semantic meaning. If the word "alone" is overlooked, the third rule has sometimes
been interpreted to forbid the use of the flow label by load balancing mechansims.
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. An analysis is presented in <xref target="I-D.hu-flow-label-cases"/>, and 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.  </t>

<t>If our goal is for the flow label to be used in practice, the conflict between
these two approaches creates a dilemma. There appear to be two viable approaches: </t>
<list style="numbers">
<t>Definitively forbid locally defined use of the flow label. 
Strengthen RFC 3697 to say that hosts SHOULD set
a pseudo-random label value, which would clarify and limit its possible uses.
In particular, its use for load balancing and possibly as a nonce would be encouraged. </t> 

<t>Encourage locally defined use of the flow label. This approach would make the flow
label mutable and would exclude any use case depending on end-to-end immutability. It
would encourage applications of a pseudo-random flow label, such as load balancing,
on a local basis, but it would exclude end-to-end applications such as 
<xref target="I-D.blake-ipv6-flow-label-nonce"/>. </t>
</list>

<t>This document is in the form of a set of proposed modifications to the standard, 
expressing approach 2 and written in normative form. It is suggested that
if the proposal is generally accepted, a revised version of RFC 3697 should be produced
including these changes.
Alternatively, a much simpler revision to express approach 1 above could be chosen.
 </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="Proposed changes to specification">

<t>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"/>.  
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>In particular, the facts that the label is not checksummed and not used mean
that the current immutability of the label can be changed without any operational
consequences. </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 a default type of generic usage. The proposed generic usage is to
enourage pseudo-random flow labels that can be used to assist load balancing.
There should be no impact on specifications other than RFC 3697 and no impact on currently
operational software and hardware. </t>

<t>Firstly we define a "Flow Label Domain" by direct analogy with a Differentiated
Services Domain <xref target="RFC2474"/>: </t>

<list>
   <t>Flow Label Domain (also FL domain): a contiguous portion of the Internet
   over which a consistent scheme of flow label mechanisms is
   administered in a coordinated fashion.  A flow label
   domain can represent different administrative domains or autonomous
   systems, different trust regions, different network layer technologies,
   hosts and routers, etc.  </t>

   <t>Flow Label Boundary (also FL boundary): the edge of an FL domain.  A
   flow label boundary can be further sub-divided into
   ingress and egress nodes, where the ingress/egress nodes are the
   downstream/upstream nodes of a boundary link in a given traffic
   direction.  A flow label boundary is typically found at
   the ingress to the first-hop flow label router
   (or network node) that a host's packets traverse, or at the egress of
   the last-hop flow label router (or network node)
   that packets traverse before arriving at a host. A flow
   label boundary may be co-located with a host, subject to local
   policy.  </t>
  
   <t>Flow Label Router (also FL router): a router that sets or interprets the flow label
   according to the mechanisms used in a given FL domain. </t>
</list>



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

<t>An FL domain implements a local scheme of flow label mechanisms. The
RECOMMENDED scheme is that, whether set by the source host according to RFC 3697, 
or by an FL router according to the rules below, the label contains a pseudo-random 
value between 1 and 0xFFFFF. This recommendation constrains the choice of flow label 
value more than RFC 3697. An FL domain MAY define an alternative scheme. </t>

<t>If and only if the flow label in an IPv6 packet has the default value of zero, then an FL 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 a router in an FL domain 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. It should be noted that an
FL router applying this rule will be obliged to inspect the IPv6 header of every packet,
including finding the last "next header" field in the packet, at full line speed. </t>

<t>Hosts connected to an FL domain MUST be configured either to set a default (zero) flow 
label in all IPv6 packets, or to apply the locally defined scheme (which, by rule 1,
SHOULD be the pseudo-random scheme). </t>

<t>When a locally defined scheme other than the pseudo-random scheme is used, packets entering
the FL domain from outside might contain an invalid label according to that scheme. Therefore,
boundary ingress FL routers MUST treat all packets entering such an FL domain as if they had a 
default (zero) flow label. </t>

<t>When a locally defined scheme  other than the pseudo-random scheme is used, packets 
leaving the FL domain might contain
a label that would be misinterpreted elsewhere. Therefore, the boundary egress FL router
SHOULD set the label according to the pseudo-random mechanism defined in rule 1. If not,
it MUST set the label to the default value of zero. </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 as zero. </t>

<t>Sending hosts conforming to this specification will by default choose pseudo-random 
labels between 1 and 0xFFFFF. </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 the rules 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 the rules above, if and only if the incoming
flow label is all-zero, according to rule 1 above. </t>

<t>The flow label is no longer immutable if it crosses a FL domain boundary. This will allow
a wide range of uses cases previously forbidden, and will allow the ECMP/LAG usage defined
in <xref target="I-D.carpenter-flow-ecmp"/>. However, it will break the usage proposed
in <xref target="I-D.blake-ipv6-flow-label-nonce"/>. </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 an FL domain where routers
adopt a locally defined scheme, or the pseudo-random mechanism 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 the pseudo-random 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 FL domain. Again, rules b and c have no effect. </t>

<t>The rules defined in this proposal are intended to allow encourage the adoption
of pseudo-random flow labels in the general case, but also allow 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
Shane Amante,
Fred Baker,
Steve Blake,
Remi Despres,
Joel Halpern,
Chris Morrow,
Mark Smith,
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">

<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="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;
&DRAFT-hu;

<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, 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 that is also
a flow label domain. </t>

</section>

</back>
</rfc>