One document matched: draft-ietf-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-ietf-6man-hbh-header-handling-03"
ipr="trust200902" updates="2460,7045">
<front>
<title abbrev="">IPv6 Hop-by-Hop Options Extension Header</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>
<author fullname="Ron Bonica" initials="R. " surname="Bonica">
<organization>Juniper Networks</organization>
<address>
<postal>
<street/>
<city>Herndon</city>
<code>20171</code>
<region>Virginia</region>
<country>USA</country>
</postal>
<email>rbonica@juniper.net</email>
</address>
</author>
<date day="16" month="March" year="2016"/>
<area>Internet</area>
<workgroup>IPv6 Maintenance</workgroup>
<abstract>
<t>This document clarifies requirements for IPv6 routers with respect to
the Hop-by-Hop (HBH) Options Extension Header. These requirements are
applicable to all IPv6 routers, regardless of whether they maintain a
strict separation between forwarding and control plane hardware. In this
respect, this document updates RFC 2460 and RFC 7045.</t>
<t>This document also describes forwarding plane procedures for
processing the HBH Options Extension Header. These procedures are
applicable to implementations that maintain a strict separation between
forwarding and control plane implementations.</t>
<t>The procedures described herein satisfy the above mentioned
requirements by processing HBH Options on the forwarding plane to the
greatest degree possible. If a packet containing HBH Options must be
dispatched to the control plane, it is rate limited before dispatching.
In order to comply with the requirements of this specification,
implementations may execute the procedures described herein or any other
procedures that result in compliant behavior.</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>In <xref target="RFC2460">IPv6</xref>, optional Internet-layer
information is encoded in extension headers that may be placed between
the IPv6 header and the upper-layer header. Currently, eleven extension
headers are defined. Among them is the Hop-by-Hop (HBH) Options
Extension header. Unlike any other extension header, the HBH Options
Extension header is examined by every node that a packet visits en route
to its destination.</t>
<t>The HBH Extension Header contains one or more HBH Options. Each HBH
Option contains a type identifier. <xref target="section-4.2"/> of this
document provides a list of currently defined HBH options.</t>
<t>Some HBH Options contain information that is useful to a router's
forwarding plane. In this document, we call these options "HBH
forwarding options". Among these is the <xref target="RFC2675">Jumbo
Payload Option</xref>. The Jumbo Payload Option indicates the payload
length of the packet that carries it. While this information is required
to forward the packet, it can be discarded as soon as the packet has
been forwarded.</t>
<t>By contrast, other HBH Options contain information that is useful to
a router's control plane. In this document, we call these options "HBH
control options". Among these is the <xref target="RFC2711">Router Alert
Option</xref>. The Router Alert Option informs transit routers that the
packet carrying it contains information to be consumed by the router's
control plane. In many cases, this information is used to forward
subsequent packets.</t>
<t>Finally, the Pad and Pad1 options contain no information at all.
These are included to ensure word-alignment of subsequent options and
headers.</t>
<t>Many modern routers maintain a strict separation between forwarding
plane hardware and control plane hardware. In these routers, forwarding
plane bandwidth is plentiful, while control plane bandwidth is
constrained. In order to protect scarce control plane resources, these
routers enforce policies the restrict access from the from the
forwarding plane to the control plane. Effective policies address
packets containing the HBH Options Extension header, because HBH control
options require access from the forwarding plane to the control
plane.</t>
<t>Many network operators perceive HBH Options to be a breach of the
separation between the forwarding and control planes <xref
target="I-D.ietf-v6ops-ipv6-ehs-in-real-world"/>. Therefore, some
network operators discard all packets containing the HBH Options
Extension Header, while others forward the packets but ignore the HBH
Options. Still other operators severely rate-limit packets containing
the HBH Options Extension Header. In addition, some (notably older)
implementations send all packets containing a HBH header to the control
plane even if they contain only pad options, resulting in an effect DoS
on the router and inconsistent drops among those packets due to rate
limiting or other factors.</t>
<t><xref target="RFC7045"/> legitimizes the current state of affairs,
severely limiting the utility of HBH options. In the words of RFC 7045:
<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>This document clarifies requirements for IPv6 routers with respect to
the HBH Options Extension Header. These requirements are applicable to
all IPv6 routers, regardless of whether they maintain a strict
separation between forwarding and control plane hardware. In this
respect, this document updates RFC 2460 and RFC 7045.</t>
<t>This document also describes forwarding plane procedures for
processing the HBH Options Extension Header. These procedures are
applicable to implementations that maintain a strict separation between
forwarding and control plane hardware.</t>
<t>The procedures described herein satisfy the above mentioned
requirements by processing HBH Options on the forwarding plane to the
greatest degree possible. If a packet containing HBH Options must be
dispatched to the control plane, it is rate limited before dispatching.
In order to comply with the requirements of this specification,
implementations can execute the procedures described herein or any other
procedures that result in compliant behavior.</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="requirements" title="Requirements">
<t>This section clarifies requirements for IPv6 routers with respect to
the HBH Options Extension Header. These requirements are applicable to
all IPv6 routers, regardless of whether they maintain a strict
separation between forwarding and control plane hardware.</t>
<t><list style="symbols">
<t>REQ1: Implementations MUST NOT discard otherwise forwardable
packets because they contain the HBH Options Extension header.
However, an implementation MAY be configured to discard packets
containing the HBH Options Extension Header, so long as this is not
the default behavior.</t>
<t>REQ 2: Implementations MUST process unrecognized HBH Options as
described in Section 4.2 of RFC 2460. If an implementation receives
a packet that contains an unrecognized HBH Option, that
implementation MUST examine the first two bits of the HBH Option
Type indicator. Those bits determine whether the implementation a)
continues to process the packet, b) discards the packet without
sending an ICMP message or c) discards the packet and sends an ICMP
message.</t>
<t>REQ 3: Unrecognized HBH Options MUST be evaluated sequentially.
For example, assume that an implementation receives a packet that
carries two unrecognized HBH Options. The Type indicator of the
first unrecognized option begins with 01 while the Type indicator of
the second unrecognized option begins with 10. In this case, the
implementation MUST discard the packet without sending an ICMP
message to the source. However, if the Type indicator of the first
unrecognized option begins with 10 and the Type indicator of the
second unrecognized option begins with 01, the implementation MUST
discard the packet and send and ICMP Parameter Problem message to
the source.</t>
<t>REQ 4: Implementations MUST protect themselves against denial of
service attacks that are propagated through HBH Options. These
protections MUST be enabled by default, without special
configuration.</t>
<t>REQ 5: The originator of a packet MAY insert the HBH Options
Extension header between the IPv6 header and the upper-layer header.
It MAY also insert HBH Options inside of the HBH Options header.
Transit routers MUST NOT insert the HBH Options Extension header
between the IPv6 header and the upper-layer header. Furthermore,
they MUST NOT add or delete HBH Options inside of the HBH Options
Extension header.</t>
<t>REQ 6: Implementations SHOULD support a configuration option that
limits the set of HBH Options that they recognize. For example,
assume that an implementation recognizes a particular HBH Option.
Using this configuration option, an operator can cause the
implementation to behave as if it does not recognize that option.
This MAY be configured a side effect of other functionality. For
example, an implementation might not recognize the Router Alert
Option unless a protocol that relies on the Router Alert Option
(e.g., RSVP) is configured.</t>
<t>REQ 7: The HBH Options Extension Header can contain as many as
2056 bytes. Some implementation are not capable of processing
extension headers of that length <xref
target="I-D.gont-v6ops-ipv6-ehs-packet-drops"/>. When an
implementation receives a packet that it cannot process due to its
HBH Options Extension Header length, the implementation MUST discard
the packet and send an ICMP Parameter Problem message to the packet
source. ICMP Parameter Problem Code MUST be "Long Extension Header"
(value TBD) and the ICMP Parameter Problem Pointer MUST contain the
offset of HBH Options Extension Header.</t>
</list></t>
</section>
<section anchor="procedures" title="Proposed Procedures">
<t>This section describes forwarding plane procedures for processing the
HBH Options Extension Header. These procedures are applicable to
implementations that maintain a strict separation between forwarding and
control plane hardware.</t>
<t>The procedures described below process HBH Options on the forwarding
plane to the greatest degree possible. If a packet containing HBH
Options must be dispatched to the control plane, it is rate limited
before dispatching. In order to comply with the requirements of <xref
target="requirements"/>, implementations can execute the procedures
described herein or any other procedures that result in compliant
behavior.</t>
<t>Having received a packet containing the HBH Options Extension header,
the forwarding plane determines whether the HBH Options Extension Header
is too long for it to process. If so, the forwarding plane discards the
packet and sends an ICMP Parameter Problem message to the packet source.
ICMP Parameter Problem Code is set to "Long Extension Header" and the
ICMP Parameter Problem Pointer is set to the offset of HBH Options
Extension Header.</t>
<t>If the HBH Options Extension Header is not too long to process, the
forwarding plane hardware scans the header, assigning it to one of the
following classes:</t>
<t><list style="symbols">
<t>Discard</t>
<t>Dispatch to control plane</t>
<t>Forward, ignoring all HBH Option</t>
<t>Forward, processing selected HBH Options</t>
</list>Forwarding plane hardware discards the packet if the HBH
Options Extension Header contains an unrecognized option whose Type
indicator begins with 01, 10 or 11. Forwarding plane hardware sends an
ICMP message if required. See <xref target="requirements"/> REQ 2 and
REQ 3 for details.</t>
<t>If the packet is not discarded, and the HBH Options Extension header
contains at least one recognized control option, the forwarding plane
subjects the packet to a rate-limit and dispatches it to the control
plane</t>
<t>Otherwise, if the HBH Options Extension header contains only the
following option types, the packet is forwarded without further HBH
Option processing:</t>
<t><list style="symbols">
<t>Pad or Pad1</t>
<t>Unrecognized options whose Type indicator begins with 00</t>
</list>Otherwise, the forwarding plane process forwarding options and
forwards the packet</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA is requested to assign a new entry to the ICMP Parameter Problem
Code registry. The name of this code is "Long Extension Header".</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document contributes to the security of IPv6 routers, by
defining forwarding plane procedures for the processing of HBH Options.
These procedures are applicable to implementations that maintain a
strict separation between forwarding and control plane hardware.</t>
<t>The procedures described below process HBH Options on the forwarding
plane to the greatest degree possible. If a packet containing HBH
Options must be dispatched to the control plane, it is rate limited
before dispatching.</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. Thanks to Fernando Gont for his thoughtful
review.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include='reference.RFC.7045'?>
</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.I-D.ietf-6man-rfc2460bis" ?>
<?rfc include='reference.I-D.gont-v6ops-ipv6-ehs-packet-drops'?>
<?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 ?>
</references>
<section anchor="log" title="Change Log">
<t>RFC Editor: this section need not be published in any RFC. <list
style="hanging">
<t hangText="Initial Version:">October 2015: text copied from
draft-baker-6man-hbh-header-handling-03.txt and discussed in IETF
94</t>
<t hangText="IETF 94 Update:">Sections 2.2, 2..3, and 2.4 moved to
an appendix reflecting (negative) working group viewpoint on the
modification of packet length in flight. <vspace blankLines="1"/>
The content of this document is likely to be subsumed into <xref
target="I-D.ietf-6man-rfc2460bis">2460bis</xref>, but is held
separate for the present discussion. <vspace blankLines="1"/> A new
section 2.2 added detailing conceptual processing model for HBH
options.</t>
<t hangText="version 2">Addressed editorial comments<vspace
blankLines="1"/></t>
</list></t>
</section>
<section anchor="section-4.2" title="HBH 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 <xref
target="RFC2460"/></t>
<t hangText="Router Alert Option:">The <xref target="RFC2711">IPv6
Router Alert Option</xref> <xref target="RFC6398"/></t>
<t hangText="Jumbo Payload:"><xref target="RFC2675"/></t>
<t hangText="RPL Option:"><xref target="RFC6553"/></t>
<t hangText="Quickstart Option"><xref target="RFC4782"/></t>
<t hangText="Common Architecture Label IPv6 Security Option:"><xref
target="RFC5570"/></t>
<t hangText="SMF Option:"><xref target="RFC6621"/></t>
<t hangText="MPL Option:"><xref
target="I-D.ietf-roll-trickle-mcast"/></t>
<t hangText="DFF Option:"><xref target="RFC6971"/></t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:53:48 |