<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" ".//reference.RFC.2119.xml">
]>
<!-- WK: Set category, IPR, docName -->
<rfc category="bcp" docName="draft-wkumari-long-headers-03" 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"?>

  <?rfc compact="yes" ?>

  <front>
    <!-- WK: Set long title. -->

    <title abbrev="long-v6-headers">Operational Issues Associated With Long
    IPv6 Header Chains</title>

    <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google</organization>

      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>

          <city>Mountain View, CA</city>

          <code>94043</code>

          <country>US</country>
        </postal>

        <email>warren@kumari.net</email>
      </address>
    </author>

    <author fullname="Joel Jaeggli" initials="J." surname="Jaeggli">
      <organization>Zynga</organization>

      <address>
        <postal>
          <street>675 East Middlefield</street>

          <city>Mountain View</city>

          <region>CA</region>

          <country>USA</country>
        </postal>

        <email>jjaeggli@zynga.com</email>
      </address>
    </author>

    <author fullname="Ronald P Bonica" initials="R." surname="Bonica">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>2251 Corporate Park Drive</street>

          <city>Herndon</city>

          <region>VA</region>

          <country>USA</country>
        </postal>

        <email>rbonica@juniper.net</email>
      </address>
    </author>
    <author fullname="J. Linkova" initials="J." surname="Linkova">
      <organization abbrev="Google">Google</organization>

      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city>
          <region>CA 94043</region>
          <country>USA</country>
        </postal>

        <email>furry@google.com</email>
      </address>
    </author>

    <date day="15" month="June" year="2015"/>

    <area>template</area>

    <workgroup>6MAN</workgroup>

    <abstract>
      <t>This memo specifies requirements for IPv6 forwarders as they process
      packets with long header chains.  It also provides guidance for
      application developers whose applications might rely on long headers
      chains.</t>

      <t>As background, this memo explains how many ASIC-based IPv6 forwarders
      process packets and why processing of packets with long header chains
      might be problematic.</t>
    </abstract>

    <note title="Requirements Language">
      <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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>IPv6 <xref target="RFC2460"/> forwarders can acquire information from the following sources:</t>

      <t><list style="symbols">
          <t>The IPv6 header</t>

          <t>One or more IPv6 extension headers</t>

          <t>An upper-layer header</t>
        </list>Section 2 of this document explains how IPv6 forwarders use
      information from the IPv6 header and IPv6 extension headers to
      provide traditional forwarding services.  It also explains how IPv6
      forwarders use information from the upper-layer header to provide
      enhanced forwarding services.</t>	

      <t>When a software-based forwarder processes an IPv6 datagram, it parses
      the header chain, regardless of its length, acquires the required	
      information and makes a forwarding decision.  Typically, software-
      based forwarders process a relatively small number of packets per
      second.  Therefore, they can perform the above mentioned procedure
      within the constraints of their processing budget.</t>

      <t>By contrast, ASIC-based forwarders process many more packets per
      second.  In order to fulfill this requirement, ASIC-based forwarders
      copy a fixed number of bytes from the beginning of the packet to on-
      chip memory.  Forwarders do this because they can access on-chip
      memory much more quickly than they can access off-chip memory.  Once
      the beginning of the packet has been transferred to on-chip memory,
      subsequent processing can proceed very quickly.</t>

      <t>The act of copying bytes from the beginning of a packet to on-chip
      memory consumes:</t>

      <t><list style="symbols">
          <t>Processor cycles</t>

          <t>On-chip memory</t>

          <t>Wall-time</t>
        </list>Therefore, the number of bytes copied to on-chip memory must be
      chosen wisely. If a forwarder copies more bytes than it needs, it wastes
      resources and adversely impacts performance. If it copies too few bytes,
      it may not have sufficient information to make a correct forwarding
      decision.</t>

      <t>The IPv6 header chain is a variable-length data structure, whose size
      can exceed 64 kilobytes.  However, packets with header chains
      exceeding 256 bytes are rarely observed on the Internet.  Therefore,
      most ASIC-based forwarders copy a relatively small number of bytes
      from the beginning of a packet into on-chip memory.  While this small
      number varies from platform to platform, it is generally much closer
      to 256 bytes than it is to 64 kilobytes.</t>

      <t>IPv6 forwarders MUST behave in a predictable manner when they process
      a packet whose header chain length exceeds the number of bytes copied
      to on-chip memory.  Section 3 of this memo defines required
      behaviors.</t>

      <t>Application developers should be aware of how ASIC-based forwarders
      process packets with long extension header chains.  Therefore,
      Section 4 of this document provides guidance to application
      developers.</t>

      <section anchor="chain" title="Termnology">
        <t>For the purposes of this document, the terms "header chain" and
        "upper-layer" header are used as defined in <xref target="RFC7112"/>.</t>

        <t>This document also introduces the following terms:</t>

        <t><list style="symbols">
          <t>forwarding service - a service that accepts a packet from one
          interface and forwards it through another</t>

          <t>traditional forwarding service - a forwarding service in which all
          parameters to the forwarding algorithm are drawn from the IPv6
          header, the hop-by-hop extension header, and the routing extension
          header</t>

          <t>enhanced forwarding service - a forwarding service in which
          parameters to the forwarding algorithm can be drawn from any
          portion of the IPv6 header chain</t>
        </list></t>
      </section>
    </section>

    <section anchor="upper" title="Forwarder Information Requirements">
      <t>When an IPv6 forwarder provides traditional forwarding services, it
      extracts all information required by the forwarding algorithm from
      the IPv6 header, the hop-by-hop extension header (if present), and
      the routing extension header (if present).  In the nominal case, the
      IPv6 header contains all information required by the forwarding
      algorithm.  However, the hop-by-hop and routing extension headers can
      also impact forwarding behavior.</t>

      <t>Section 4.2 of <xref target="RFC2460"/> explains how the hop-by-hop extension header
      impacts forwarding behavior.  When the forwarder processes a hop-by-
      hop extension header, it examines each option contained by the
      header.  If forwarder encounters an unrecognized hop-by-hop option,
      and the high-order bits of the option type are "00", the forwarder
      skips over the option and continues to process subsequent options.
      However, if an forwarder encounters an unrecognized option, and the
      high-order bits of the option type are "01", "10" or "11", the
      forwarder discards the packet.</t>

      <t>Section 4.4 of <xref target="RFC2460"/> explains how the routing extension header
      impacts forwarding behavior.  When the forwarder processes a packet
      whose destination address is local to itself, it scans the header
      chain, searching for a routing extension header.  If the packet
      contains a routing extension header and the forwarder recognizes the
      routing header type, it processes the header.  If the forwarder does
      not recognize the routing header type, the required behavior depends
      upon the Segments Left field.  If the Segments Left field is equal to
      zero, the forwarder ignores the routing extension header.  Otherwise,
      the forwarder discards the packet. <xref target="RFC6275"/> and <xref target="RFC6554"/> describe
      currently defined routing extension header types.</t>

      <t>Some IPv6 forwarders provide enhanced forwarding services, such as
      firewall filtering, rate limiting and load balancing.  In order to
      provide these services, the forwarder requires access to an upper
      layer header.  The following are examples of enhanced services that
      require the forwarder to examine the upper layer header:</t>

      <t><list style="symbols">
          <t>Discard all packets directed to TCP port 25</t>

          <t>Rate limit packets destined for a particular address whose payload
          is TCP and have the TCP SYN bit set</t>

          <t>Load balance packets across parallel links so that all packet
          belonging to particular TCP session traverse the same link.</t>
         </list></t>
    </section>

    <section title="Requirements For IPv6 Forwarders">
      <t>The following requirements apply to all IPv6 forwarders:</t>

      <t><list style="symbols">
          <t>REQ-1: By default an IPv6 forwarder SHOULD NOT discard a valid packet because
          of its header chain length.  However, the forwarder MAY support a
          configuration option that causes it to discard packets whose
      	  header chain length exceeds a specified value.</t>
     
          <t>REQ-2: When processing packet that contains a hop-by-hop extension
          header, an IPv6 forwarder MUST process the entire hop-by-hop
          extension header, regardless of its length.  The forwarder MUST
          process each option as specified in Section 4.2 of <xref target="RFC2460"/>.
          If an IPv6 forwarder is not able to process the entire hop-by-hop
          extension header, it MUST discard the packet and SHOULD
          originate an ICMPv6 Parameter Problem message to the packet's source.
          The forwarder MAY have a configurable policy for sending ICMPv6 messages
          such as rate limiting or completely disabling them
          If an IPv6 forwarder is not able to process the entire hop-by-hop
          extension header, it MUST discard the packet and SHOULD
          originate an ICMPv6 Parameter Problem message to the packet's source.
          The forwarder MAY have a configurable policy for sending ICMPv6 messages
          such as rate limiting or completely disabling them.</t>

          <t>REQ-3: When processing a packet whose destination address is local
          to itself, an IPv6 forwarder MUST scan the entire header chain,
          regardless of its length, in order to determine whether the packet
          contains a routing extension header.  If the packet contains a
          routing extension header, the forwarder MUST process routing
          extension header as specified in Section 4.4 of <xref target="RFC2460"/>.
          If an IPv6 forwarder is not able to process the entire routing 
          extension header, it MUST discard the packet and SHOULD
          originate an ICMPv6 Parameter Problem message to the packet's source.
          The forwarder MAY have a configurable policy for sending ICMPv6 messages
          such as rate limiting or completely disabling them.</t>
        </list>The length of the IPv6 header plus the length of the hop-by-hop
        extension header can exceed the number of bytes that an ASIC-based
        forwarder copies into on-chip memory.  Therefore, in order to support
        REQ-2, ASIC-based forwarders typically support a special processing
        mechanism for packets containing hop-by-hop extensions.</t>

        <t>Also, the combined length of all headers preceding the routing
        extension header may exceed the number of bytes that an ASIC-based
        forwarder copies into on-chip memory.  Therefore, in order to support
        REQ-3, ASIC-based forwarders typically support a special processing
        mechanism for packets whose IPv6 destination address is local to the
        forwarder.  This forwarding mechanism is capable of processing the
        routing extension header, even if it begins beyond of the portion of
        the packet that was copied to on-chip memory.</t>

        <t>The following requirements apply to IPv6 forwarders that provide
   enhanced forwarding services:</t>

      <t><list style="symbols">
	 <t>REQ-4: If a forwarder's ability to deliver enhanced services is
         limited in any way by extension header length, that limitation
         MUST be reflected in user documentation.  For example, assume that
         a forwarder provides a load balancing service, and that it
         acquires information required by the service from the IPv6 header
         and the upper-layer header.  If the service behaves in one manner
         when all required information is contained by the first N bytes of
         the header chain and in another manner when all required
         information is not contained by the first N bytes of the header
         chain, user documentation MUST reflect both behaviors as well as
         the value of N.</t>

         <t>REQ-5: If a forwarder's ability to deliver an enhanced service is
         limited by extension header length, the policy specification
         language used to configure the enhanced service MUST be
         sufficiently robust to address the limitation.  For example,
         assume that the forwarder provides a firewall service.  The
         firewall service is capable of filtering packets directed to a
         particular TCP port, but only if the TCP header is contained by
         the first N bytes of the header chain.  In this case, it MUST be
         possible to configure one policy for packets directed to the
         specified port, another policy for packet not directed to the
         specified port, and a third policy for packets whose TCP
         destination port is unknown.</t>
         </list></t>

    </section>

    <section title="Recommendations For Application Developers">
       <t>Applications developers should be aware that many ISPs and
       enterprises filter or severely rate limit packets containing long
       header chains.  They do this because of limitations imposed by the
       ASIC-based forwarders deployed at their edges.  ISPs and enterprises
       accept these limitations as part of an engineering trade off, in
       which high-speed forwarding is achieved at the cost of limiting
       enhanced services for packets with long extension headers.</t>

       <t>For example, assume that an enterprise deploys the following firewall
       filtering policy at its edge:</t>

      <t><list style="symbols">
         <t>Permit all packets whose destination is TCP port 80</t>

         <t>Discard all packets whose destination is not TCP port 80</t>

         <t>Discard all packets whose header chain is so long that TCP port
         information is not accessible to the filtering function</t>

         </list></t>
    
       <t>In this case, the enterprise discards all packets whose destination
       cannot be determined by the filtering function.</t>

       <t>Aside from the issue of header chain length, operators may filter
       packets containing extension headers that may either compromise the
       network's security posture or require inordinate processing
       resources.</t>

       <t>This memo does not specify a maximum header chain length.  However,
       this memo does note that at the time of its publication, the number
       of bytes that ASIC-based forwarders copy from the beginning of a
       packet to on-chip memory varies from platform to platform.  Typical
       platforms copy between 128 and 384 bytes.  Therefore, application
       developers should avoid sending packets who header chain length is in
       that range, unless they have some assurance that their packets will
       not be discarded.</t> 
    </section>

    <section title="IANA Considerations">
      <t>This document makes no requests of the IANA</t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>TBD</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors wish to thank Paul Hoffman, KK and Fernando Gont. The
      authors also express their gratitude to an anonymous donor, without whom
      this document would not have been written.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119' ?>
      <?rfc include='reference.RFC.2460' ?>
      <?rfc include='reference.RFC.2474' ?>
      <?rfc include="reference.RFC.7112'?>
    </references>
    <references title="Informative References">
      <?rfc include='reference.RFC.6275' ?>
      <?rfc include='reference.RFC.6554' ?>
    </references>

    <section title="Changes / Author Notes.">
      <t>[RFC Editor: Please remove this section before publication ]</t>

      <t>Template to -00</t>

      <t><list style="symbols">
          <t>Initial submission.</t>

          <t/>
        </list></t>

      <t>-00 to -01</t>

      <t><list style="symbols">
          <t>Added maximum header chain recommendation.</t>

          <t>Rewrite the forwarding description.</t>
        </list></t>

      <t>-02 to -03</t>
        
        <t><list style="symbols">
          <t> Updating REQ2 and REQ3 with sending ICMPv6 messages part.</t>
        </list></t>
 
    </section>
  </back>
</rfc>
