IPv6 Hop-by-Hop Header Handling
Cisco Systems
Santa Barbara
93117
California
USA
fred@cisco.com
Internet
IPv6 Maintenance
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).
The IPv6 Specification 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 ,
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.
Fernando Gont, in his Observations on IPv6 EH
Filtering in the Real World, 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.
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.
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 .
In short, to avoid a punt to a software path, the Hop-by-Hop option
SHOULD be implemented in hardware when possible.
At this writing, there are three defined Hop-by-Hop options:
The PAD1 and PADn options define empty space.
The IPv6
Router Alert Option is intended to
force the punting of a datagram to software, in cases in which
RSVP or other protocols need that to happen.
While this is not true of older hardware, modern hardware (which is
to say, microcode) 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 hardware should be able to
identify and skip the PAD1 and PADn options, and punt the Router Alert
or other options to software only if configured by software to do so.
More generally, in routers that implement a fast path, the
processing of the Hop-by-Hop Extension Header (which must be performed
by every router a packet transits) MUST be performed in the fast path
unless there is a specific reason to punt to a slower path, including
that corresponding software exists in the implementation and is
configured to process the option.
Section 4.2 of 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
or .
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.
Such options must be marked appropriately (their option type is of
the form XX1XXXXX), and are excluded from checksum calculations in AH
and ESP.
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.
The interactions with the IP Authentication
Header and IP Encapsulating Security
Payload (ESP), 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.
This memo asks the IANA for no new parameters.
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 () 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. 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.
Data formats in this memo reveal no personally identifying
information.
This note grew out of a discussion among the author, Ole Troan, Mark
Townsley, Frank Brockners, and Shwetha Bhandari, and benefited from
comments by Brian Carpenter and Joe Touch.
Rate Control Protocol (RCP): Congestion control to make flows
complete quickly
Congestion control for high bandwidth-delay product
networks