One document matched: draft-ietf-6man-ext-transmit-02.xml

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

<!-- 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.) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!-- You need one entry like the following for each RFC referenced -->

<!ENTITY RFC2119 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2629 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY RFC2460 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml'>
<!ENTITY RFC2780 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2780.xml'>
<!ENTITY RFC5533 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5533.xml'>
<!ENTITY RFC6564 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6564.xml'>
<!ENTITY RFC5095 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5095.xml'>
<!ENTITY RFC4302 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4302.xml'>
<!ENTITY RFC4303 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4303.xml'>
<!ENTITY RFC5201 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5201.xml'>
<!ENTITY RFC6275 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml'>
<!ENTITY RFC6554 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6554.xml'>
<!ENTITY RFC4727 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4727.xml'>
<!ENTITY RFC3692 PUBLIC ''
  'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3692.xml'>





<!-- You need one entry like the following for each I-D referenced -->


<!ENTITY DRAFT-chain SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-oversized-header-chain.xml"> 
<!ENTITY DRAFT-fragdrop SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.taylor-v6ops-fragdrop.xml"> 


]>


<?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"?>


<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-ietf-6man-ext-transmit-02" category="std" updates="2460, 2780" >


<front>
<title abbrev="IPv6 Extension Header Transmission">Transmission of IPv6 Extension Headers</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." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>
      <address>
        <postal>
          <street>Q14, Huawei Campus</street>
          <street>No.156 Beiqing Road</street>
          <city>Hai-Dian District, Beijing</city>
          <code>100095</code>
          <country>P.R. China</country>
        </postal>
        <email>jiangsheng@huawei.com</email>
      </address>
    </author>


 


 <date day="8" month="August" year="2013" />

<area>Internet</area>
<workgroup>6man</workgroup>

 


<abstract>

<t>Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document
updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that
are defined in future. It also specifies how extension headers should be registered by IANA,
with a corresponding minor update to RFC 2780.
</t>
    
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction and Problem Statement">

<t>In IPv6, an extension header is any header that follows the
initial 40 bytes of the packet and precedes the upper layer header
(which might be a transport header, an ICMPv6 header, or a notional
"No Next Header"). </t>

<t>An initial set of IPv6 extension headers was defined by <xref target="RFC2460"/>,
which also described how they should be handled by intermediate nodes,
with the exception of the hop-by-hop options header:</t>

<figure><artwork>
"...extension headers are not examined or processed
by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header."
</artwork></figure>

<t>This provision meant that forwarding nodes should be completely transparent to 
extension headers. There was no provision for forwarding nodes to modify them, remove them,
insert them, or use them to affect forwarding behaviour. 
Thus, new extension headers could be introduced progressively, used only by hosts that
have been updated to create and interpret them. The extension header mechanism is
an important part of the IPv6 architecture, and several new extension headers
have been standardised since RFC 2460. </t>

<t>Today, packets are often forwarded not only by straightforward IP routers, but
also by a variety of intermediate nodes, often referred to as middleboxes, such as firewalls,
load balancers, or packet classifiers. Unfortunately, experience has showed that as a result,
the network is not transparent to IPv6 extension headers. 
Contrary to Section 4 of RFC 2460, middleboxes sometimes examine and process the 
entire IPv6 packet before making a decision to either forward or discard the packet.
This means that they need to traverse the chain of extension
headers, if present, until they find the transport header (or an encrypted payload). 
Unfortunately, because not all IPv6 extension headers follow a uniform TLV format, 
this process is clumsy and requires knowledge of each extension header's format. </t>

<t>The process is potentially slow as well as clumsy, possibly precluding its use in nodes
attempting to process packets at line speed. The present document does not intend to solve this
problem, which is caused by the fundamental architecture of IPv6 extension headers. 
This document focuses on clarifying how the header chain should be traversed
in the current IPv6 architecture. </t>

<t>If they encounter an unrecognised extension header type, some firewalls treat the packet as suspect and
drop it. Unfortunately, it is an established fact that several widely used firewalls do not
recognise some or all of the extension headers standardised since RFC 2460. It has also
been observed that certain firewalls do not even handle all the extension headers
standardised in RFC 2460, including the fragment header <xref target="I-D.taylor-v6ops-fragdrop"/>,
causing fundamental problems of connectivity. This applies in particular to firewalls
that attempt to inspect packets statelessly at very high speed, since they cannot
take the time to reassemble fragmented packets, especially when under a denial
of service attack. </t>

<t>Other types of middlebox, such as load balancers or packet
classifiers, might also fail in the presence of extension headers that
they do not recognise. </t> 

<t>A contributory factor to this problem is that, because extension headers
are numbered out of the existing IP Protocol Number space, there is no collected
list of them. For this reason, it is hard for an implementor to quickly identify
the full set of standard extension headers. An implementor who consults only RFC 2460
will miss all extension headers defined subsequently.  </t>

<t>This combination of circumstances creates a "Catch-22" situation <xref target="Heller"/>
for the deployment of any newly standardised extension header except for local use. It cannot be widely deployed,
because existing middleboxes will render large parts of the Internet opaque to it. However,
most middleboxes will not be updated to allow the new header to pass until it has been
proved safe and useful on the open Internet, which is impossible until the middleboxes
have been updated. </t>

<t>The uniform TLV format now defined for extension headers <xref target="RFC6564"/> 
will improve the situation, but only for future extensions. Some tricky and potentially
malicious cases will be avoided by forbidding very long chains of extension headers
that need to be fragmented <xref target="I-D.ietf-6man-oversized-header-chain"/>.
This will alleviate concerns that stateless firewalls cannot handle a complete header
chain as required by the present document. </t>

<t>However, these changes are insufficient to correct the underlying problem. 
The present document clarifies that the above requirement from
RFC 2460 applies to all types of node that forward IPv6 packets and to
all extension headers standardised now and in the future. It also requests IANA to
create a subsidiary registry that clearly identifies extension header types,
and updates RFC 2780 accordingly. Fundamental changes to the IPv6
extension header architecture are out of scope for this document. </t>

<t>Also, Hop-by-Hop options are not handled by many high speed routers, or are
processed only on a slow path. This document also updates the requirements for
processing the Hop-by-Hop options header to make them more realistic. </t>

<section title="Terminology">
<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>

<t>In the remainder of this document, the term "forwarding node" refers to any router,
firewall, load balancer, prefix translator, or any other device or middlebox that forwards IPv6
packets with or without examining the packet in any way. </t>
</section>
</section> <!-- intro -->

<section anchor="reqt" title="Requirement to Transmit Extension Headers">

<section title="All Extension Headers">
<t>Any forwarding node along an IPv6 packet's path, which forwards the packet for any reason,
SHOULD do so regardless of any extension headers that are present, as required by RFC 2460.
Exceptionally, if this node is designed to examine extension headers for any reason,
such as firewalling, it MUST recognise and deal appropriately with all standardised IPv6 extension header
types. The list of standardised extension header types is maintained by IANA (see <xref target="iana"/>)
and implementors are advised to check this list regularly for updates. </t>

<t>RFC 2460 requires destination hosts to discard packets containing unrecognised extension headers.
However, intermediate forwarding nodes SHOULD NOT do this by default, since that might cause them to
inadvertently discard traffic using a recently standardised extension header, not yet recognised by
the intermediate node. The only exceptions to this rule are discussed below. </t>

<t>As mentioned above, forwarding nodes that discard packets containing
extension headers are known to cause connectivity failures and deployment problems. Therefore,
it is important that forwarding nodes that inspect IPv6 extension headers can parse all standard headers
and are able to behave according to the above requirements. If a forwarding node
discards a packet containing a standard IPv6 extension header, it MUST be
the result of a configurable policy, and not just the result of a failure to
recognise such a header. This means that the discard policy for each
standardised type of extension header MUST be individually configurable. The default configuration
SHOULD allow all standardised extension headers except the experimental values 253 and 254
standardised by <xref target="RFC3692"/> and <xref target="RFC4727"/>. Forwarding nodes MUST be configurable to allow packets
containing unrecognised extension headers, but such packets MAY be dropped by default. </t>

<t>The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD NOT be used.
However, as specified in <xref target="RFC5095"/>, this does not mean that the
IPv6 Routing Header can be unconditionally dropped by forwarding nodes.
Packets containing standardised and undeprecated Routing Headers SHOULD be forwarded by default. 
At the time of writing, these include Type 2 <xref target="RFC6275"/>, Type 3 <xref target="RFC6554"/>,
and the experimental Routing Header Types 253 and 254 <xref target="RFC4727"/>.
Others may be defined in future. </t>
</section>

<section title="Hop-by-Hop Options">
<t>The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate forwarding nodes
as described in <xref target="RFC2460"/>.
However, it is to be expected that high performance routers will either
ignore it, or assign packets containing it to a slow processing path. Designers
planning to use a Hop-by-Hop option need to be aware of this likely behaviour. </t>

<t>As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options header, if present,
must be first. </t>
</section>

</section> <!-- reqt -->



<section anchor="security" title="Security Considerations">

<t>Forwarding nodes that operate as firewalls MUST conform to the requirements in the
previous section in order to respect the IPv6 extension header architecture.
In particular, packets containing standard extension headers are only to be discarded
as a result of a configurable policy. </t>

<t>When new extension headers are standardised in the future, those implementing and configuring
forwarding nodes, including firewalls, will need to take account of them. 
A newly defined header will exercise new code paths in a host that does recognise it,
so caution may be required. It is therefore to be expected that the deployment
process will be slow and will depend on satisfactory operational experience.
Until it is complete, the new extension will fail in some parts of the Internet.
This aspect needs to be considered when deciding to standardise a new extension. 
Specific security considerations for each new extension should be documented
in the document that defines it. </t>
 
</section> <!-- security -->


<section anchor="iana" title="IANA Considerations">

<t>IANA is requested to clearly mark in the Assigned Internet Protocol Numbers registry
those values which are also IPv6 Extension Header types defined by an IETF standards
action, for example by adding an extra
column to indicate this. This will also apply to any IPv6 Extension Header types 
standardised in the future. </t>

<t>Additionally, IANA is requested to replace the existing empty IPv6 Next Header Types
registry by an IPv6 Extension Header Types registry. It will contain only those protocol
numbers which are also marked as IPv6 Extension Header types in the Assigned 
Internet Protocol Numbers registry and were defined by an IETF standards action.
The initial list will be as follows: 

<list style="symbols">

<t>0, Hop-by-Hop Options, <xref target="RFC2460"/> </t>
<t>43, Routing, <xref target="RFC2460"/>, <xref target="RFC5095"/>  </t> 
<t>44, Fragment, <xref target="RFC2460"/> </t>
<t>50, Encapsulating Security Payload, <xref target="RFC4303"/> </t>
<t>51, Authentication, <xref target="RFC4302"/> </t>
<t>60, Destination Options, <xref target="RFC2460"/> </t>
<t>135, MIPv6, <xref target="RFC6275"/> </t>
<!-- <t>139, HIP, <xref target="RFC5201"/> </t> (Experimental) -->
<t>140, shim6, <xref target="RFC5533"/> </t>
<t>253, experimental use, <xref target="RFC3692"/>, <xref target="RFC4727"/> </t>
<t>254, experimental use, <xref target="RFC3692"/>, <xref target="RFC4727"/> </t>
</list> 
</t>

<t>This list excludes both type 59, No Next Header, <xref target="RFC2460"/>,
which is not an extension header as such,
and type 139, HIP, <xref target="RFC5201"/>, which is experimental. </t>

<t>The references to the IPv6 Next Header field in <xref target="RFC2780"/> are to be 
interpreted as also applying to the IPv6 Extension Header field. </t>


</section> <!-- iana -->




<section anchor="ack" title="Acknowledgements">

<t>
This document was triggered by mailing list discussions including
John Leslie, Stefan Marksteiner and others.

Valuable comments and contributions were made by
Dominique Barthel,
Tim Chown,
Lorenzo Colitti, 
Fernando Gont,
C. M. Heard,
Bob Hinden,
Ray Hunter,
Suresh Krishnan,
Marc Lampo,
Michael Richardson,
Dave Thaler,
Joe Touch,
Bjoern Zeeb,
and others.
 </t>

<t>Brian Carpenter was a visitor at the Computer Laboratory, Cambridge University during part of this work. </t>

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

</section> <!-- ack -->


<section anchor ="changes" title="Change log [RFC Editor: Please remove]">

<t>draft-ietf-6man-ext-transmit-02: explicit mention of header 
types 253 and 254, editorial fixes, 2013-08-06.</t>

<t>draft-ietf-6man-ext-transmit-01: tuned use of normative language, clarified that
only standardised extensions are covered (hence excluding HIP), 2013-05-29.</t>

<t>draft-ietf-6man-ext-transmit-00: first WG version, more clarifications, 2013-03-26.</t>

<t>draft-carpenter-6man-ext-transmit-02: clarifications following WG comments, recalibrated firewall requirements, 2013-02-22.</t>

<t>draft-carpenter-6man-ext-transmit-01: feedback at IETF85: clarify scope
and impact on firewalls, discuss line-speed processing and lack of uniform TLV format,
added references, restructured IANA considerations, 2012-11-13.</t>

<t>draft-carpenter-6man-ext-transmit-00: original version, 2012-08-14.</t>

</section> <!-- changes -->

</middle>

<back>

<references title="Normative References">

&RFC2119;
&RFC2460;
&RFC2780;
&RFC5533;
&RFC5095;
&RFC4302;
&RFC4303;
&RFC5201;
&RFC6275;
&RFC6564;
&RFC4727;
&RFC3692;



</references>

<references title="Informative References">

&RFC2629;
&RFC6554;
&DRAFT-chain;
&DRAFT-fragdrop;

<reference anchor='Heller'>
<front>
<title>Catch-22</title>
<author initials="J." surname="Heller" fullname="Joseph Heller"/>
<date year='1961'/>
</front>
<seriesInfo name="Simon and Schuster" value='' />
</reference>

</references>



</back>
</rfc>