One document matched: draft-donley-softwire-dslite-flowlabel-00.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY RFC3697 SYSTEM 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3697.xml'>
  <!ENTITY I-D.ietf-softwire-dual-stack-lite SYSTEM 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-softwire-dual-stack-lite-04.xml'>
]>


<rfc category="exp" ipr="trust200902" docName="draft-donley-softwire-dslite-flowlabel-00">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<front>
	<title abbrev="dslite-flowlabel">
			   Using the Flow Label with Dual-Stack Lite
	</title>

	<author initials='C.D.' surname="Donley" fullname='Chris Donley'>
		<organization>CableLabs </organization>
		<address>
			<postal>
				<street>858 Coal Creek Circle</street>
				<city>Louisville</city> <region>CO</region> 
				<code>80027</code>
				<country>USA</country>
			</postal>
			<email>c.donley@cablelabs.com</email>
		</address>
	</author>
	
	<author initials='K.E.' surname="Erichsen" fullname='Kirk Erichsen'>
		<organization>Time Warner Cable </organization>
		<address>
			<postal>
				<street>12101 Airport Way</street>
				<city>Broomfield</city> <region>CO</region> 
				<code>80021</code>
				<country>USA</country>
			</postal>
			<email>kirk.erichsen@twcable.com</email>
		</address>
	</author>
	<date month="July" year="2010"/>
		<abstract>
			<t>This document extends the use of Dual-Stack Lite to identify discrete traffic flows using the IPv6 Flow Label.  The identification of discrete traffic flows allows for the application of Quality of Service (QoS) classification and prioritization of traffic traversing Dual-Stack Lite tunnels.
</t>
		</abstract>
</front>


<middle>
<section title="Introduction">
  <t>
  Dual-Stack Lite <xref target="I-D.ietf-softwire-dual-stack-lite"/> describes a method for transitioning to IPv6 by encapsulating IPv4 traffic within an IPv6 tunnel and translating it at the Address Family Translation Router.  Through such encapsulation, DS-Lite obfuscates the IPv4 5-tuple behind the IPv6 header, thereby making it difficult to classify IPv4 traffic.  Thus, to QoS classifiers, all IPv4 traffic is encapsulated as IP-in-IP and uses the same IPv6 source address, destination address, and protocol.  There is no differentiation of IPv4 traffic requiring differentiated quality of service such as Voice over IP. 
</t><t>
This lack of differentiation can be problematic for traffic types where prioritization is desired. For example, it is common practice to provide QoS for voice traffic.  Such classification and prioritization is typically performed by network elements located between the Basic BroadBand Bridging element and Address Family Transition Router, particularly on WAN links. However, in a Dual-Stack Lite environment, many such network elements are unable to identify characteristics of a particular IPv4 traffic flow and apply QoS accordingly.
</t><t>
This document proposes a method of providing QoS to IPv4 traffic in a DS-Lite environment by identifying individual traffic flows using the IPv6 Flow Label.
</t>
</section>
<section title="Conventions used in this document">
  <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 title="Allowing Dual-Stack Lite QoS Using the IPv6 Flow Label">
  <t>
As described in <xref target="RFC3697"/>, a flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the sender desires to label as a flow. IPv6 uses the Flow Label in the IPv6 header to identify such flows. In cases where the Flow Label field uniquely identifies such traffic flows, packet classifiers can utilize the triplet of Flow Label, Source Address, and Destination Address fields in order to identify packets belonging to a particular flow. 
</t><t>
As described in <xref target="I-D.ietf-softwire-dual-stack-lite"/>, traffic is encapsulated between the Basic BroadBand Bridging (B4) element and Address Family Transition Router (AFTR).  Both the B4 and AFTR are aware of the 5-tuple of the encapsulated IPv4 traffic.  Thus, both the B4 and AFTR are capable of identifying IPv4 traffic flows and setting the IPv6 Flow Label for the DS-Lite tunnel accordingly. By populating the Flow Label field in DS-Lite tunnels, service providers can use Flow Label classifiers to provide priority treatment to appropriate traffic flows. 
</t>
<section title="B4 Considerations">
<t>
The B4 SHOULD uniquely set the IPv6 Flow Label to a non-zero value per IPv4 traffic flow in accordance with <xref target="RFC3697"/>. That is, the B4 SHOULD identify IPv4 traffic flows by the IPv4 5-tuple of IPv4 Source Address, Destination Address, Protocol, Source Port, and Destination Port.  The B4 SHOULD construct a unique Flow Label based on the IPv4 5-tuple and apply it to the IPv6 header attached to that flow as it is encapsulated within a DS-Lite tunnel. If the B4 sets the IPv6 Flow Label to a non-zero value, it MUST use the same Flow Label value for other IPv4 packets belonging to the same flow (as determined by the IPv4 5-tuple). 
</t>
</section>
<section title="AFTR Considerations">
<t>
The AFTR SHOULD uniquely set the IPv6 Flow Label per IPv4 traffic flow in accordance with <xref target="RFC3697"/>. That is, the AFTR SHOULD identify IPv4 traffic flows to be sent to the B4 by the IPv4 5-tuple of IPv4 Source Address, Destination Address, Protocol, Source Port, and Destination Port after completing Network Address Translation.  The AFTR SHOULD construct a unique Flow Label based on the IPv4 5-tuple and apply it to the IPv6 header attached to that flow as it is encapsulated within a DS-Lite tunnel. If the AFTR sets the IPv6 Flow Label to a non-zero value, it MUST use the same Flow Label value for other IPv4 packets belonging to the same flow (as determined by the IPv4 5-tuple). 
</t>
</section>
<section title="Constructing the Flow Label">
<t>
The exact mechanism for constructing the Flow Label is not specified, except as per <xref target="RFC3697"/>. Implementations could use a 20-bit hash of the IPv4 5-tuple such that subsequent IPv4 packets with the same 5-tuple will receive the same Flow Label. 
</t><t>
As specified by <xref target="RFC3697"/>, Flow Label information is only significant to the B4 or AFTR transmitting the particular DS-Lite flow. Since the Flow Label will be consistently applied to all packets in the flow, however, intermediate devices between the B4 and AFTR can use the Flow Label in packet classifiers to provide quality of service treatment to the flow. 
  </t>
</section>  
</section>
<section title="Security Considerations">
  <t>Security considerations are described in <xref target="RFC3697"/>, section 5. The Flow Label is not protected, and could be modified by an on-path attacker. However, the impact of any such modification would be limited to the QoS treatment of the modified packet(s).</t>
</section>
<section title="IANA Considerations">
  <t>There are no IANA considerations.</t>
</section>
</middle>


<back>

<references title="Normative References">
 &RFC2119;
 &RFC3697;
 &I-D.ietf-softwire-dual-stack-lite;
</references>

   <section title="Acknowledgements">
    <t>Thanks to the following people for their guidance and feedback:
      <list style="hanging">
        <t>Lee Howard</t>
        <t>Andy Shappell</t>
        <t>Chris Williams</t>
        <t>Marla Azinger</t>
	</list>
    </t>
   </section>
</back>


</rfc>