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

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.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-06.xml">
<!ENTITY I-D.ietf-6man-flow-update SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-6man-flow-update-00.xml">
]>
<rfc category="exp" docName="draft-donley-softwire-dslite-flowlabel-01"
     ipr="trust200902">
  <?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 fullname="Chris Donley" initials="C.D." surname="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 fullname="Kirk Erichsen" initials="K.E." surname="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="January" year="2011" />

    <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"></xref> describes a method
      for transitioning to IPv6 by encapsulating IPv4 traffic inside an IPv6
      tunnel and translating it at the Address Family Translation Router. By
      encapsulating such traffic, DS-Lite obfuscates the IPv4 5-tuple behind
      the IPv6 header, thereby making it difficult to classify IPv4 traffic.
      To QoS classifiers, all IPv4 traffic is encapsulated as an IP-in-IP
      tunnel using the same IPv6 source address, destination address, and
      protocol. There is no differentiation for 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, and service providers need a way to
      classify such traffic. For example, it is common practice to provide QoS
      for voice traffic. In a cable environment, such
      classification/prioritization is performed using PacketCable Multimedia
      (PCMM). PCMM identifies traffic at an application manager (AM)/policy
      server(PS) and notifies the Cable Modem Termination System (CMTS) to
      provide QoS using DOCSIS classifiers. However, in a Dual-Stack Lite
      environment, the AM/PS is unable to identify characteristics of a
      particular IPv4 traffic flow and apply QoS using DOCSIS classifiers.
      This problem is applicable to other QoS systems, as well, including
      access-list-based classifiers.</t>

      <t>This document proposes a method of identifying individual traffic
      flows encapsulated using DS-Lite 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"></xref>.</t>
    </section>

    <section title="Allowing Dual-Stack Lite QoS Using the IPv6 Flow Label">
      <t>As described in <xref target="RFC3697"></xref>, a flow is a sequence
      of packets sent from a particular source to a particular unicast,
      anycast, or multicast destination that the source 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 use the triplet of Flow Label,
      Source Address, and Destination Address fields to identify packets
      belonging to a particular flow.</t>

      <t>As described in <xref
      target="I-D.ietf-softwire-dual-stack-lite"></xref>, 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>

      <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"></xref>
      and <xref target="I-D.ietf-6man-flow-update"></xref>. 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 inside 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>

      <t>The AFTR SHOULD uniquely set the IPv6 Flow Label per IPv4 traffic
      flow in accordance with <xref target="RFC3697"></xref> and <xref
      target="I-D.ietf-6man-flow-update"></xref>. 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 inside
      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>

      <t>The exact mechanism for constructing the Flow Label is not specified,
      except as per <xref target="RFC3697"></xref> and <xref
      target="I-D.ietf-6man-flow-update"></xref>. 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 directed by <xref target="RFC3697"></xref> and <xref
      target="I-D.ietf-6man-flow-update"></xref>, 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 title="Security Considerations">
      <t>Security considerations are described in <xref
      target="RFC3697"></xref>, 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;

      &I-D.ietf-6man-flow-update;
    </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>
        </list></t>
    </section>
  </back>
</rfc>