<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-wang-6man-flow-label-reflection-01"
     ipr="trust200902">
  <front>
    <title abbrev="Flow Label Reflection">IPv6 Flow Label Reflection</title>

    <author fullname="Aijun Wang" initials="A." surname="Wang">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>Beijing Research Institute, China Telecom Cooperation
          Limited</street>

          <city>No.118, Xizhimenneidajie, Xicheng District, Beijing</city>

          <code>100035</code>

          <country>China</country>
        </postal>

        <phone>86-10-58552347</phone>

        <email>wangaj@ctbri.com.cn</email>
      </address>
    </author>

    <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156 Beiqing Road</street>

          <city>Hai-Dian District, Beijing, 100095</city>

          <country>P.R. China</country>
        </postal>

        <email>jiangsheng@huawei.com</email>
      </address>
    </author>

    <date month="" year="2015" />

    <area>Internet Area</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>IPv6, Flow Label, Reflection</keyword>

    <abstract>
      <t>The current definition of the IPv6 Flow Label focuses mainly on how
      the packet source forms the value of this field and how the forwarder
      in-path treats it. In network operations, there are needs to correlate
      an upstream session and the corresponding downstream session together.
      This document propose a flow label reflection mechanism that network
      devices copy the flow label value from received packets to the
      corresponding flow label field in return packets. This mechanism could
      simplify the network traffic recognition process in network operations
      and make the policy for both directions of traffic of one session
      consistent.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The IPv6 flow label <xref target="RFC6437"></xref> in the fixed IPv6
      header is designed to differentiate the various flow session of IPv6
      traffic; it can accelerate the clarification and treatment of IPv6
      traffic by the network devices in its forwarding path. In practice, many
      current implementations use the 5-tuple {dest addr, source addr,
      protocol, dest port, source port} as the identifier of network flows.
      However, transport-layer information, such as the port numbers, is not
      always in a fixed position, since it follows any IPv6 extension headers
      that may be present; in contrast, the flow label is at a fixed position
      in every IPv6 packet and easier to access. In fact, the logic of finding
      the transport header is always more complex for IPv6 than for IPv4, due
      to the absence of an Internet Header Length field in IPv6. Additionally,
      if packets are fragmented, the flow label will be present in all
      fragments, but the transport header will only be in one packet.
      Therefore, within the lifetime of a given transport-layer connection,
      the flow label can be a more convenient "handle" than the port number
      for identifying that particular connection.</t>

      <t>The usages of IPv6 flow label, so far as briefly summarized in <xref
      target="currentUsage"></xref>, only exploit the characteristic of IPv6
      flow label in one direction.</t>

      <t>In current practice, an application session is often recognized as
      two separated IP traffics, in two opposite directions. However, from the
      point view of a service provider, the upstream and downstream of one
      session should be handled together, particularly, when application-aware
      operations are placed in the network. A ubiquitous example is that end
      user initiates a request, with small-scale data transmitted, towards a
      content server, then the server responds with a large set of follow-up
      packets. The bi-directional flows should be correlated together and
      handled with the same policy. Ideally, the request embeds a flow
      recognition identifier that is accessible and the follow-up response
      packets carry the same identifier. The flow label is a good choice for
      the flow recognition identifier.</t>

      <t>This document proposes a flow label reflection mechanism so that
      network devices copy the flow label value from received packets to the
      corresponding flow label field in return packets. By having the same
      flow label value in the downstream and upstream of one IPv6 traffic
      session, the network traffic recognition process and the traffic policy
      deployment in network operations could be simplified. It may also
      increase the accuracy of network traffic recognition.</t>

      <t>Several applicable scenarios of the IPv6 flow label reflection are
      also given, in <xref target="applicableScenarios"></xref>. For now, this
      document only considers the scenario in a single administrative domain,
      although the IPv6 flow label reflection mechanism may also bring
      benefits into cross domain scenarios.</t>

      <section anchor="currentUsage"
               title="Summary of the current usage for IPv6 Flow Label">
        <t><xref target="RFC6438"></xref> describe the usage of IPv6 Flow
        Label for ECMP and link aggregation in Tunnels; it mainly utilizes the
        random distribution characteristic of IPv6 flow label. <xref
        target="RFC7098"></xref> also describes similar usage in server
        farms.</t>

        <t>All these usage scenarios consider only the usage of IPv6 flow
        label in one direction, while many bi-directional network traffics
        need to be treated together.</t>
      </section>
    </section>

    <section title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in <xref
      target="RFC2119"></xref> when they appear in ALL CAPS. When these words
      are not in ALL CAPS (such as "should" or "Should"), they have their
      usual English meanings, and are not to be interpreted as <xref
      target="RFC2119"></xref> key words.<list style="hanging">
          <t hangText="Flow Label Reflection">A mechanism/behavior so that a
          network device copies the value of flow label from a IPv6 flow into
          a corresponding return IPv6 flow.</t>

          <t hangText="Flow Label Reflection Device">A network device that
          applies the flow label reflection mechanism. It is the end of an
          IPv6 flow and the initiation node of the corresponding return IPv6
          flow.</t>
        </list></t>
    </section>

    <section title="Potential Benefit of Flow Label Reflection">
      <t>With flow label reflection mechanism, the IPv6 Flow Label could be
      used to correlate the upstream and downstream packets of bi-directional
      traffics:<list style="symbols">
          <t>It makes the downstream and upstream of one session be easily
          recognized. It makes the correlation of traffic and then the
          recognition of various traffics easier.</t>

          <t>The network operator can easily apply the same policy to the
          bi-directional traffic of one interested session</t>

          <t>The traffic analyzer can also easily correlate the upstream and
          downstream of one session to find the symptoms of various internet
          protocols.</t>
        </list></t>
    </section>

    <section title="Flow Label Reflection Behaviors on Network Devices">
      <t>To fulfill the flow label reflection mechanism, the below proposed
      behaviors on network devices:<list style="symbols">
          <t>The generation method of IPv6 flow label in source IPv6 node
          SHOULD follow the guidelines in <xref target="RFC6437"></xref>, that
          is the IPv6 flow label should be generated randomly and distributed
          enough.</t>

          <t>On the Flow Label Reflection Device, the value of IPv6 Flow Label
          from received packets SHOULD be copied into the corresponding flow
          label field in return packets by the flow label reflection
          devices.</t>

          <t>The forwarding nodes within the management domain SHOULD follow
          the specification in <xref target="RFC6437"></xref>, that is the
          IPv6 flow label SHOULD NOT be modified in the path, unless flow
          label value in arriving packets is zero. The forwarding nodes MAY
          follow the specification in <xref target="RFC6438"></xref> when
          using the flow label for load balancing by equal cost multipath
          (ECMP) routing and for link aggregation, particularly for
          IPv6-in-IPv6 tunneled traffic.</t>

          <t>The network traffic recognition devices, or devices that may have
          differentiated operations per flow, SHOULD recognize and analyze
          network traffics based on 3-tuple of {dest addr, source addr,
          flowlabel}. It SHOULD consider the traffics that have same flow
          label value and reversed source/dest addr as upstream and downstream
          of the same flow, match them together to accomplish the traffic
          recognition process.</t>

          <t>Other network operations MAY also be based on 3-tuple of {dest
          addr, source addr, flowlabel}.</t>
        </list></t>
    </section>

    <section anchor="applicableScenarios" title="Applicable Scenarios">
      <t>This section describes some applicable scenarios, which network
      operators can benefit from deploying the flow label reflection
      mechanism. It is not a complete enumeration. More scenarios may be
      introduced in the future.</t>

      <section title="Flow Label Reflection on CP servers">
        <t>There is rapidly increasing requirement from service providers (SP)
        to cooperate with the content providers (CP) to provide more accurate
        services and charging policies based on accurate traffic recognition.
        The service providers need to recognize the CP/SP's bi-directional
        traffics at the access edge devices of the network, such as
        BRAS/PDSN/P-GW devices.</t>

        <t>Normally, the burden for these edge devices to recognize the
        subscriber's upstream traffic is light, because request messages are
        typically small. But they often need more resource to recognize
        downstream traffics, which normally contain large data. With flow
        label reflection on CP servers, recognition based on the 3-tuple of
        {dest addr, source addr, flowlabel} would reduce the consumption of
        recognition and make the correlation process much easier.</t>

        <t>In this scenario, the CP servers would be the Flow Label Reflection
        Devices. They copy the flow label value from received upstream user
        request packets to the corresponding flow label field in return
        downstream packets.</t>

        <t>The access edge devices of service provider scrutinize the
        subscriber's upstream IPv6 traffic and record the binding of 3-tuple
        and traffic-specific policy. If the flow label is zero, the access
        edge devices must rewrite the flow label value according to local
        policy. With the recorded binding information, the access edge devices
        can easily recognize and match the downstream packet to the previous
        recognized upstream packet, by just accessing 3-tuple. The edge
        devices can then apply the corresponding traffic policy to the
        upstream/downstream of the session to the cooperated CP.</t>

        <t>Note: this mechanism may not reliable when the CP servers are not
        directly connected to the service provider, because there is no
        guarantee the flow label would not be changed by intermediate devices
        in other administrative domains.</t>
      </section>

      <section title="Flow Label Reflection for Bi-direction Tunnels">
        <t>Tunnel is ubiquitous within service provider networks. It is very
        difficult (important if the tunnel is encrypted) for intermediate
        network devices to recognize the inner encapsulated packet, although
        such recognition could be very helpful in some scenarios, such as
        traffic statistics, network diagnoses, etc. Furthermore, such
        recognition normally requires to correlate bi-direction traffic
        together. The flow label reflection mechanism could provide help in
        such requirement scenarios.</t>

        <t>In this scenario, the tunnel end devices would be the Flow Label
        Reflection Devices. They record the flow label value from received
        tunnel packets, and copy it to the corresponding flow label field in
        return packets, which can be recognized by 5-tuple or 3-tuple of the
        inner packet at the tunnel end devices.</t>

        <t>The tunnel initiating devices should generate different flow label
        values for different inner flow traffics based on their 5-tuple or
        3-tuple in accordance with <xref target="RFC6437"></xref>. Note: if
        the inner flow is encryption in ESP model <xref
        target="RFC4303"></xref>, the transport-layer port numbers are
        inaccessiable. In such case, 5-tuple is not available.</t>

        <t>Then the intermediate network device can easily distinguish the
        different flow within the same tunnel transport link and correlate
        bi-direction traffics of same flow together. This can also increase
        the service provider's traffic control capabilities.</t>

        <t>This mechanism can also work when the encapsulated traffics are
        IPv4 traffics, such as DS-Lite scenario <xref
        target="RFC6333"></xref>. The IPv4 5-tuple may be used as the input
        for the flow label generation.</t>
      </section>

      <section title="Flow Label Reflection on edge devices">
        <t>If the flow label reflection mechanisms have been applied on peer
        host, the service provider could always use it for bi-directional
        traffic recognition. However, there is no guarantee the flow label
        would not be changed by intermediate devices in other administrative
        domains. Therefore, to make the flow label value trustful, the edge
        devices need to validate the flow label reflection.</t>

        <t>In this scenario, the edge devices would be the (backup) Flow Label
        Reflection Devices. They record the flow label value from the packets
        that leave the domain. When the corresponding flow label field in
        return packets are recognized by 5-tuple or 3-tuple at the edge
        devices, the edge devices should check the flow label as below:</t>

        <t><list style="symbols">
            <t>if the flow label matches the record value, it remains;</t>

            <t>if the flow label is zero, the edge devices copy the record
            value into it;</t>

            <t>if the flow label is non-zero, but does not matches the record
            value, the edge devices can decide the flow label are modified by
            other intermediate devices (with the assumption the peer host has
            reflect the original flow label), then restore the flow label
            using the record value.</t>
          </list>Then the network recognition devices located anywhere within
        the service provider network could easily correlate bi-directional
        traffics together, and apply traffic-specific policy accordingly.</t>
      </section>

      <section title="Misc Possible Scenarios">
        <t>In the below scenarios, the flow label reflection mechanism needs
        to be combined with other mechanisms in order to achieve the design
        goals.</t>

        <section title="Aid to mitigate the ND cache DDoS Attack">
          <t>Neighbor Discovery Protocol <xref
          target="RFC4861"></xref>[RFC4861] is vulnerable for the possible
          DDoS attack to the device's ND cache, see section 11.1, <xref
          target="RFC4861"></xref>. There are many proposals are aiming to
          mitigate this problem, but none of them are prevalent now. It is
          mainly because that there is no obvious mechanism to assure the
          validation of the NS/RS packet on the first arrival, the receiving
          node by default will cache the link-layer address of the NA packet.
          Reverse detection mechanisms can be added to solve this issue.
          However, for reverse detection mechanisms, there would be another
          issue: how to pair the return NA/RA packet with the NS/RS packet on
          the sending node. It can be solved by applying the flow label
          reflection mechanism in the return NA/RA packet. Then the sending
          node can pair the reverse detect NS/RS packet with original NA/RA
          packet and response to the reverse detect NS/RS packet correctly.
          Only the NS/RS packet that passed the reverse detection validation
          will be accept by the node and the link-layer address within it will
          be cached.</t>
        </section>

        <section title="Improve the efficiency of PTB problem solution in load-balance environment">
          <t><xref target="I-D.v6ops-pmtud-ecmp-problem"></xref> introduces
          the Packet Too Big <xref target="RFC4443"></xref> problem in
          load-balance environment. The downstream packet from a server, which
          responses to a client request message, may meet a forwarding node
          that rejects the packet for "too big" reason. The PTB error ICMPv6
          message should be returned to the original server. However, it
          requests the load balancer to distribute the PTB error ICMPv6
          message based on the information of the invoking packet within the
          ICMPv6 packet, not the ICMPv6 packet itself. The load balancer needs
          to obtain the source IP address and transport port information
          within the invoking packet.</t>

          <t>However, if both the server and the forwarding node that
          generates the PTB message apply the flow label reflection mechanism,
          the PTB error ICMPv6 message would have the same flow label with the
          original client request message. Then, the load balancer, that
          follows <xref target="RFC7098"></xref>, could easily forward the PTB
          packet to same server without parsing the transport port in the
          invoking packet, thus increases the efficiency.</t>
        </section>
      </section>
    </section>

    <section title="Deployment Consideration">
      <t>The IPv6 flow label reflection mechanism requires the "Flow Label
      Reflection Device" to be stateful, store the flow label value and copy
      it to the corresponding return packet. Such change cannot be
      accomplished within a short term, and therefore the deployment of this
      mechanism will be accomplished gradually. During the incremental
      deployment period, the traditional recognition mechanisms, which are
      more expensive, would coexist. The traffics that could not be recognized
      by 3-tuple of {dest addr, source addr, flowlabel} could fall back to the
      traditional process or be skipped over by advanced services. The more
      devices support the flow label reflection mechanism, the less
      consumption for traffic recognition from the network management
      perspective, or the better coverage of advanced services that are based
      on the traffic recognition.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Security aspects of the flow label are discussed in <xref
      target="RFC6437"></xref>. A malicious source or man-in-the-middle could
      disturb the traffic recognition by manipulating flow labels. However,
      the worst case is that fall back to the current practice that an
      application session is often recognized as two separated IP traffics.
      The flow label does not significantly alter this situation.</t>

      <t>Specifically, the IPv6 flow label specification <xref
      target="RFC6437"></xref> states that "stateless classifiers should not
      use the flow label alone to control load distribution." This is answered
      by also using the source and destination addresses with flow label.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This draft does not request any IANA action.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thanks Brian Carpenter, who gave many
      useful advices. The authors would also like to thanks the valuable
      comments made by Fred Baker, Lee Howard, Mark ZZZ Smith, Jeroen Massar,
      Florent Fourcot and other members of V6OPS WG. Also, special thanks for
      Florent Fourcot, who have implemented the flow label reflection
      mechanims in the Linux.</t>

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

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.2629'?>

      <?rfc include='reference.RFC.4443'?>

      <?rfc include='reference.RFC.4861'?>

      <?rfc include='reference.RFC.6146'?>

      <?rfc include='reference.RFC.6437'?>

      <?rfc include='reference.RFC.6438'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.7098'?>

      <?rfc include='reference.I-D.v6ops-pmtud-ecmp-problem'?>

      <?rfc include='reference.RFC.4303'?>

      <?rfc include='reference.RFC.6333'?>
    </references>
  </back>
</rfc>
