One document matched: draft-carpenter-6man-ext-transmit-00.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'>



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


<!ENTITY DRAFT-ecmp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-flow-ecmp.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-carpenter-6man-ext-transmit-00" 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="14" month="August" year="2012" />

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

 


<abstract>

<t>Various IPv6 extension headers have been defined since the IPv6 standard was first published. This document
updates RFC 2460 to describe 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">

<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 allowed for the addition of new extension headers, since it
means that forwarding nodes should be completely transparent to them. Thus, new
extension headers could be introduced progressively, used only by hosts that
have been updated to create and interpret them. Several such extension headers
have been defined since RFC 2460. </t>

<t>Unfortunately, experience has showed that the network is not transparent to 
these headers. The main reason for this is that some firewalls attempt to inspect
the transport payload. This means that they traverse the chain of extension
headers, if present, until they find the payload. If they encounter an unknown
extension header type, some of these firewalls treat the packet as suspect and
drop it. It is an established fact that several widely used firewalls do not
recognise some or all of the extension headers defined since RFC 2460. It has also
been observed that a few firewalls do not even recognise all the extension headers
in RFC 2460, including the fragment header, causing fundamental problems
of connectivity. </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 valid extension headers. An implementor who consults only RFC 2460
will miss all extension headers defined subsequently.  </t>

<t><xref target="RFC6564"/> improves the situation by defining
a uniform format for any future extension headers, but this in itself is
insufficient. 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 defined now and in the future. It also requests IANA to
create a subsidiary registry that clearly identifies valid extension header types,
and updates RFC 2780 accordingly. </t>

<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> <!-- intro -->

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

<t>[NOTE IN DRAFT: These requirements may look controversial compared to RFC 2460,
and are presented for discussion in the WG. In reality, hop-by-hop options are
not handled by many high speed routers, or are processed only on a slow path. Also,
many firewalls inspect and filter extension headers. The following text is intended to
deal with those realities.] </t>

<t>The IPv6 Hop-by-Hop Options header SHOULD be processed by intermediate nodes
as described in <xref target="RFC2460"/>.
However, it is to be expected that some 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 should be aware of this likely behaviour. </t>

<t>Apart from that, any node along an IPv6 packet's path, which forwards it for any reason,
SHOULD do so regardless of any extension headers that are present, as described in 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 valid IPv6 extension header types. The list of currently
valid extension header types is maintained by IANA (see <xref target="iana"/>). </t>

<t>RFC 2460 requires destination hosts to discard packets containing unrecognised extension headers.
However, intermediate forwarding nodes MUST NOT do this by default, since that might cause them to
inadvertently discard traffic using a recently defined extension header, not yet recognised by
the intermediate node. </t>

<t>As mentioned above, firewalls that violate RFC 2460 by discarding packets containing
valid extension headers are known to cause connectivity failures. Therefore, it is
important that firewalls behave according to the above requirements. If a firewall
chooses to discard a packet containing a valid IPv6 extension header, it MUST be
the result of an explicit firewall policy, and not just the result of a failure to
recognise such a header. </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 undeprecated Routing Headers MUST be forwarded by default. </t>

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



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

<t>Firewall devices MUST conform to the requirements in the previous section. 
In particular, packets containing specific extension headers are only to be discarded
as a result of explicit policy, and never by default. </t>

 
</section> <!-- security -->


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

<t>IANA is requested to replace the existing empty IPv6 Next Header Types registry by an
IPv6 Extension Header Types registry, clearly marked as subsidiary to the existing Assigned 
Internet Protocol Numbers registry. It will contain only those protocol
numbers which are also IPv6 Extension Header types. 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>58, ICMPv6, <xref target="RFC2460"/> </t>
<t>59, No Next Header, <xref target="RFC2460"/> </t>
<t>60, Destination Options, <xref target="RFC2460"/> </t>
<t>135, MIPv6, <xref target="RFC6275"/> </t>
<t>139, HIP, <xref target="RFC5201"/> </t>
<t>140, shim6, <xref target="RFC5533"/> </t>

</list> 
</t>


<t>Any future IPv6 Extension Header types will be added to this registry
as well as to the Assigned Internet Protocol Numbers registry. </t>

<t>The reference to the IPv6 Next Header field in <xref target="RFC2780"/> applies equally
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
TBD
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-carpenter-6man-ext-transmission-00: original version, 2012-08-14.</t>

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

</middle>

<back>

<references title="Normative References">

&RFC2119;
&RFC2460;
&RFC2780;
&RFC5533;
&RFC5095;
&RFC4302;
&RFC4303;
&RFC5201;
&RFC6275;


</references>

<references title="Informative References">

&RFC2629;
&RFC6564;

</references>



</back>
</rfc>