One document matched: draft-baker-6man-hbh-header-handling-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-6man-hbh-header-handling-03"
ipr="trust200902" updates="2460,7045">
<front>
<title abbrev="">IPv6 Hop-by-Hop Header Handling</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date/>
<area>Internet</area>
<workgroup>IPv6 Maintenance</workgroup>
<abstract>
<t>This note updates the IPv6 Specification (RFC 2460), specifically
commenting on the Hop-by-Hop Options Header (section 4.3) and option
format and handling (section 4.2).</t>
<t>It also updates RFC 7045, which noted that RFC 2460 is widely
violated in this respect, but merely legitimized this situation with a
SHOULD. The present document tries to address the issue more
fundamentally.</t>
<t/>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>The <xref target="RFC2460">IPv6 Specification</xref> specifies a
number of extension headers. These, and the ordering considerations
given, were defined based on experience with IPv4 options. They were,
however, prescient with respect to their actual use - the IETF community
did not know how they would be used. In at least one case, the
Hop-by-Hop option, most if not all implementations implement it by
punting to a software path. In the words of <xref target="RFC7045"/>,
<list style="empty">
<t>The IPv6 Hop-by-Hop Options header SHOULD be processed by
intermediate forwarding nodes as described in [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>
</list></t>
<t>Fernando Gont, in his <xref
target="I-D.ietf-v6ops-ipv6-ehs-in-real-world">Observations on IPv6 EH
Filtering in the Real World</xref>, and the operational community in
IPv6 Operations, consider any punt to a software path to be an attack
vector. Hence, IPv6 packets containing the Hop-by-Hop Extension Header
(and in some cases, any extension header) get dropped in transit.</t>
<t>The subject of this document is implementation approaches to obviate
or mitigate the attack vector, and updating the Hop-by-Hop option with
respect to current issues.</t>
<section 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"/>.</t>
</section>
</section>
<section anchor="proposal"
title="Handling of options in extension headers">
<t>Packets containing the Hop-by-Hop Extension Header SHOULD be
processed at substantially the same rate as packets that do not.</t>
<t>If a hop-by-hop header option is not implemented, or is not in use,
in a given system (such as, for example, an interface that is not
configured for RSVP receiving an RSVP Alert Option), the option MUST be
skipped.</t>
<t>If a hop-by-hop header is present in a packet's extension header
chain and it is not the first extension header, the packet MUST be
discarded by the first system that observes the fact (Section 2.2 of
<xref target="RFC7045"/>). This will normally be in the system using the
IPv6 address in the Destination Address, as <xref target="RFC2460"/>
precludes other routers from parsing the header chain. The only obvious
exception to that is a router or firewall configured to parse the IPv6
header chain.</t>
<section anchor="section-4.2" title="Hop-by_hop Options">
<t>At this writing, there are several defined Hop-by-Hop options:</t>
<t><list style="hanging">
<t hangText="PAD Options:">The PAD1 and PADn options <xref
target="RFC2460"/> define empty space.</t>
<t hangText="Router Alert Option:">The <xref target="RFC2711">IPv6
Router Alert Option</xref> <xref target="RFC6398"/> is intended to
force the punting of a datagram to software, in cases in which
RSVP or other protocols need that to happen.</t>
<t hangText="Jumbo Payload:">Carries a length field for a packet
whose length exceeds 0xFFFF octets. <xref target="RFC2675"/></t>
<t hangText="RPL Option:">The RPL option carries routing
information used in a RPL network<xref target="RFC6553"/></t>
<t hangText="Quickstart Option">Identifies TCP quick-start
configuration, and allows an intermediate router to reduce the
configuration parameters as appropriate. <xref
target="RFC4782"/></t>
<t
hangText="Common Architecture Label IPv6 Security Option:">Encodes
security labels on packets <xref target="RFC5570"/></t>
<t hangText="SMF Option:">Simplified Multicast Forwarding
Option<xref target="RFC6621"/></t>
<t hangText="MPL Option:">Supports multicast in an RPL network
<xref target="I-D.ietf-roll-trickle-mcast"/></t>
<t hangText="DFF Option:">Depth-First Forwarding <xref
target="RFC6971"/></t>
</list></t>
<t>There are also options that have been defined for the Destination
Options header. These are not listed here.</t>
<t>While this is not true of older implementations, modern equipment is
capable of parsing the Extension Header chain, and can be extended to
perform at least a cursory examination of the Hop-by-Hop options. For
example, such implementations SHOULD be able to identify and skip the PAD1
and PADn options, and perform more complicated processing only if
configured by software to do so.
More to the point: it isn't clear what the purpose of the JumboFrame option is if not to be understood by anyone that looks at it.
<list style="empty">
<t>Question asked by a reviewer: "Is this configurable? How will
router know that HbH needs to be skipped on one interface and not
on others."</t>
<t>Answer: the system knows whether RSVP has been configured on an
interface. When such configuration is present, it can configure
the hardware with what it wants done with the Router Alert. In the
absence of such configuration, hardware should be configured to
skip the option if found.</t>
</list></t>
</section>
<section anchor="changes" title="Changing options in transit">
<t>Section 4.2 of <xref target="RFC2460"/> explicitly allows for
options that may be updated in transit. It is likely that the original
authors intended that to be very simple, such as having the
originating end system provide the container, and having intermediate
systems update it - perhaps performing some calculation, and in any
event storing the resulting value. Examples of such a use might be in
<xref target="XCP"/> or <xref target="RCP"/>.</t>
<t>As a side comment, the Routing Header, which is an extension header
rather than a list of options, is treated similarly; when a system is
the destination of a packet and not the last one in the Routing
Header's list, it swaps the destination address with the indicated
address in the list, and updates the hop count and the list depth
accordingly.</t>
<t>Such options must be marked appropriately (their option type is of
the form XX1XXXXX), and are excluded from checksum calculations in AH
and ESP.</t>
</section>
<section anchor="length" title="Adding headers or options in transit">
<t>Use cases under current consideration take this a step further: a
router or middleware process MAY add an extension header, MAY add an
option to the header, which may extend the length of the Hop-by-Hop
Extension Header, or MAY process such an option in a manner that
extends both the length of the option and the Extension Header
containing it. The obvious implication is that other equipment in the
network may not understand or implement the new option type. As such,
the Option Type value of such an option MUST indicate that it is to be
skipped by a system that does not understand it. Since, by definition,
it is being updated in transit and not included in any AH or ESP
integrity check if present, the Option Type MUST also indicate that it
may be updated in transit, and so is excluded from AH and ESP
processing. By implication, such an Option Type MUST be of the form
001XXXXX.</t>
</section>
<section anchor="security-interaction"
title="Interactions with the Security Extension Header">
<t>The interactions with the <xref target="RFC4302">IP Authentication
Header</xref> and <xref target="RFC4303">IP Encapsulating Security
Payload (ESP)</xref>, as in the case of existing option uses, is
minimally defined. AH and ESP call for the exclusion of mutable data
in their calculations by zeroing it out prior to performing the
integrity check calculation. However, in the case that network
operation has changed the length of the option or the extension
header, that may still cause the integrity check to fail.
Specifications that define such options SHOULD consider the
implications of this for AH and ESP. An option whose insertion would
affect the integrity check MUST be removed prior to the integrity
check, and as a result the packet restored to its state as originally
sent.</t>
</section>
</section>
<section anchor="interoperation" title="Interoperation with RFC 2460">
<t>There are four possible modes of interaction with routers that don't
implement the Hop-By-Hop Option in the fast path: <list style="numbers">
<t>Presume that they cannot handle the Hop-By-Hop option at close to
wire speed, and that's OK.</t>
<t>Presume that they will drop traffic containing Hop-By-Hop
options.</t>
<t>Presume that they can handle the Hop-By-Hop option at or close to
wire speed, and are configured to do so.</t>
<t>Presume that they don't exist, perhaps because older routers are
configured to ignore all Hop-by-Hop options.</t>
</list></t>
<t>If the first model actually works in a given network, it may be
acceptable in that domain. It is not a model that will work in the
general Internet, however.</t>
<t>The second model (which is most probable at this writing) is a
description of the general Internet in 2015.</t>
<t>The third and fourth models, if applicable in a given context, are
what one might hope for. Vendors are in a position to either have an
option to ignore the Hop-By-Hop header in older equipment, or add such
an option in upgraded software (fourth model). New equipment is expected
to follow the third model by implementing the recommendations in <xref
target="proposal"/>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>In general, modification of a datagram in transit is considered very
closely from the viewpoint of the End-to-End Principle, which in this
context may be summarized as "the network should do nothing that is of
concern to the communicating applications or introduces operational
issues." The concept of changing the length of an Extension Header or an
option contained within it (<xref target="length"/>) is of concern in
that context. The obvious concern is around the interaction with AH or
ESP, and a less obvious concern relates to Path MTU, which might change
if the size of an underlying header changes. <xref
target="security-interaction"/> is intended to mitigate that issue.
However, some ramifications, such as with Path MTU, may not be
completely solvable in the general Internet, but require use cases to be
confined to a network or set of consenting networks.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>Data formats in this memo reveal no personally identifying
information.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This note grew out of a discussion among the author, Ole Troan, Mark
Townsley, Frank Brockners, and Shwetha Bhandari, and benefited from
comments by Dennis Ferguson, Brian Carpenter, Panos Kampanakis, JINMEI
Tatuya, and Joe Touch.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-roll-trickle-mcast" ?>
<?rfc include="reference.I-D.ietf-v6ops-ipv6-ehs-in-real-world" ?>
<?rfc include="reference.RFC.2675" ?>
<?rfc include="reference.RFC.2711" ?>
<?rfc include="reference.RFC.4302" ?>
<?rfc include="reference.RFC.4303" ?>
<?rfc include="reference.RFC.4782" ?>
<?rfc include="reference.RFC.5570" ?>
<?rfc include="reference.RFC.6398" ?>
<?rfc include="reference.RFC.6553" ?>
<?rfc include="reference.RFC.6621" ?>
<?rfc include="reference.RFC.6971" ?>
<?rfc include="reference.RFC.7045" ?>
<reference anchor="RCP">
<front>
<title>Rate Control Protocol (RCP): Congestion control to make flows
complete quickly</title>
<author fullname="Nandita Dukkipati" initials="N"
surname="Dukkipati">
<organization/>
</author>
<date year="2006"/>
</front>
<seriesInfo name="Stanford University" value=""/>
</reference>
<reference anchor="XCP">
<front>
<title>Congestion control for high bandwidth-delay product
networks</title>
<author fullname="Dina Katabi" initials="D" surname="Katabi">
<organization/>
</author>
<author fullname="Mark Handley" initials="M" surname="Handley">
<organization/>
</author>
<author fullname="Charlie Rohrs" initials="C" surname="Rohrs">
<organization/>
</author>
<date year="2002"/>
</front>
<seriesInfo name="SIGCOMM Symposium proceedings on Communications architectures and protocols"
value=""/>
</reference>
</references>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">June 2015</t>
<t hangText="01 Version:">June 2015, responding to list discussion</t>
<t hangText="02 Version:">July 2015, discussed at IETF 93</t>
<t hangText="03 Version:">October 2015</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:45:45 |