IPv6 Hop-by-Hop Options Processing ProceduresCheck Point Software100 Oracle Parkway, Suite 800Redwood CityCA94065United States of Americabob.hinden@gmail.comUniversity of AberdeenSchool of EngineeringFraser Noble BuildingAberdeenAB24 3UEUnited Kingdomgorry@erg.abdn.ac.uk
INT
6manThis document specifies procedures for processing IPv6 Hop-by-Hop
options in IPv6 routers and hosts. It modifies the procedures specified
in the IPv6 Protocol Specification (RFC 8200) to make processing of the IPv6
Hop-by-Hop Options header practical with the goal of making IPv6
Hop-by-Hop options useful to deploy and use at IPv6 routers and hosts.
This document updates RFC 8200.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Requirements Language
. Terminology
. Background
. Hop-by-Hop Header Processing Procedures
. Processing the Extension Header Carrying Hop-by-Hop Options
IntroductionThis document specifies procedures for processing IPv6 Hop-by-Hop
options in IPv6 routers and hosts.
It modifies the procedures specified in the IPv6
Protocol Specification to make processing of the IPv6 Hop-by-Hop Options header
practical with the goal of making IPv6 Hop-by-Hop options useful to
deploy and use at IPv6 routers and hosts.An IPv6 packet includes Hop-by-Hop
options by including a Hop-by-Hop
Options header. The current list of defined Hop-by-Hop options can be found at .
The focus for this document is to set the minimum requirements
for router processing of Hop-by-Hop options. It also discusses
how Hop-by-Hop options are used by hosts.
This document
does not propose a specific bound to the number or size of Hop-by-Hop options
that ought to be processed.This document updates .Requirements Language
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 when, and only when, they appear in all capitals, as
shown here.
TerminologyThis document uses the following loosely defined
terms:
Forwarding Plane:
IPv6 routers exchange user or applications data through the
Forwarding Plane. Routers process fields contained in IPv6 packet
headers. However, they do not process information contained in packet
payloads.
Control Plane:
IPv6 routers exchange control
information through the
Control Plane. The Control Plane processes the management and routing
information exchanged with other routers.
Fast Path:
A path through a router that is optimized for
forwarding packets. The Fast Path
might be supported by Application-Specific Integrated Circuits (ASICs),
a Network Processor (NP),
or other special purpose hardware. This is the typical processing path
within a router taken by the Forwarding Plane.
Slow Path:
A path through a router that is capable of
general purpose processing and is not optimized for any particular
function. This processing path is used for packets that require
special processing or that differ from assumptions made in Fast Path
heuristics or to process router control protocols used by the Control
Plane.
Full Forwarding Rate:
The rate at which a router can
forward packets without adversely impacting the aggregate
forwarding rate. For example, a router could process packets
with Hop-by-Hop options at a rate that allows it to maintain the full
speed on its outgoing interfaces, which is sometimes called
"wire speed".
Source:
The node originating the packet.
NOTE: is an example of how designs can
separate Control Plane and Forwarding Plane
functions. The separation between hardware and software processing
described in does not apply to all router
architectures. However, a router that performs all or most processing
in software might still incur more processing cost when providing
special processing for Hop-by-Hop options.Background
In early versions of the IPv6 protocol specification
,
Hop-by-Hop options were
required to be processed by all nodes: routers and hosts. This proved to
not be practical in current high speed routers, as observed in : "it is to be expected that high-performance routers will
either ignore it or assign packets containing it to a slow processing
path". The reasons behind this include the following:
The inability to process Hop-by-Hop options at the Full Forwarding
Rate can result in issues.
In some cases, Hop-by-Hop options would be sent to the
control/management components that run on the Slow Path.
This could degrade a router's performance and also its ability to process
critical control traffic, both of which could be exploited as a
Denial-of-Service (DoS) attack against the router.
If a subset of packets within a flow includes Hop-by-Hop
options, it could lead to an increased number of reordered
packets and greater reordering distances for packets delivered to
the destination.
Such reordering could occur if the Hop-by-Hop
Options header is included
only in some packets or if a specific Hop-by-Hop option results
in different processing for some of the packets within the
flow. Significant reordering of packets within a flow can
negatively impact the performance of upper-layer protocols and
should therefore be avoided.
Packets could include multiple Hop-by-Hop options. Too many
options could make the
previous issues worse by increasing the resources required to process
them. The total size of the options determines the number of header bytes
that might need to be processed. Measurements show
that the probability of successful transmission across the
public Internet is currently
higher for packets that include Options that result in a short
total Extension Header (EH) Chain size (i.e., less than 40 bytes).
specifies a uniform format for new IPv6 Extension
Headers, and this update was incorporated into
(note that
obsoleted ).When the IPv6 protocol specification was updated and published in
July 2017 as
, the procedures relating to Hop-by-Hop options
were specified (paragraphs 5 and 6 of ) as follows:
The Hop-by-Hop Options header is not inserted or deleted, but may be
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. The Hop-by-Hop Options header, when present, must
immediately follow the IPv6 header. Its presence is indicated by the
value zero in the Next Header field of the IPv6 header.
NOTE: While required that all nodes
must examine and process the Hop-by-Hop Options header, it is now
expected that nodes along a packet's delivery path only examine
and process the Hop-by-Hop Options header if explicitly configured
to do so.
The changes meant that an implementation complied with the IPv6 protocol
specification even if it did not process Hop-by-Hop options and that
routers were expected to add configuration information to
control whether they process the Hop-by-Hop Options header.
In practice, routers may include configuration options to control
which Hop-by-Hop options they will process.The text regarding the processing of Hop-by-Hop options in was not intended to change the processing of these
options. It documented how they were being used in
the Internet at the time RFC 8200 was published (see ). This was a constraint on
publishing the IPv6 protocol specification as an IETF Standard.The main issues remain:
Routers can be configured
to drop transit packets containing Hop-by-Hop Options that
require processing by a processor that implements the Control Plane.
This could be done to protect against a DoS attack on the
router .
IPv6 packets that include a Hop-by-Hop Options header are dropped
by some Internet paths.
A survey in 2015 reported a high loss rate in transit Autonomous Systems (ASes) for packets that include
Hop-by-Hop options .
The operational implications of IPv6 packets that include
Extension Headers are discussed in .
Measurements taken in 2023 confirm this to still be the case for many types of
network paths .
Allowing multiple Hop-by-Hop options in a single packet in some cases
consumes more router resources to process these packets. It also adds
complexity to the number of permutations that might need to be
processed/configured.
Including larger or multiple Hop-by-Hop options in a
Hop-by-Hop Options header increases
the number of bytes that need to be processed in forwarding,
which in some designs can impact
the cost of processing a packet, and in turn could increase the probability of
drop . A larger Extension Header
could also reduce the probability of a router locating all
the header bytes required to successfully process
an access control list operating on fields after the Hop-by-Hop
Options header.
Any option that can be used to force packets into the
processor that implements the router's Control Plane can be
exploited as a DoS
attack on a transit router by saturating the resources needed for
router management protocols (routing protocols, network management
protocols, etc.), which could cause adverse router operation.
This is an issue for the
Router Alert Option , which
intentionally forwards packets to the Control Plane
as discussed in .
This impact could be mitigated by limiting
the use of Control Plane resources by a specific packet and/or
by using per-function rate-limiters for packets processed
by the Control Plane.
includes a summary of processing the IP Router Alert Option:
In a nutshell, the IP Router Alert Option does not provide a
convenient universal mechanism to accurately and reliably distinguish
between IP Router Alert packets of interest and unwanted IP Router
Alert packets. This, in turn, creates a security concern when the IP
Router Alert Option is used, because, short of appropriate
router-implementation-specific mechanisms, the router slow path is at risk
of being flooded by unwanted traffic.
This is an example of the need to limit the resources that can
be consumed when a particular function is executed and to avoid consuming
Control Plane resources
where support for a function has not been configured.There has been research that has discussed
the general problem with dropping packets containing IPv6 Extension
Headers, including the Hop-by-Hop Options header.
For example, states that "Dropping all
packets that contain Extension Headers is a bad practice" and that "The share
of traffic containing more than one EH however, is very small. For the
design of hardware able to handle the dynamic nature of EHs, we therefore
recommend to support at least one EH". Operational aspects of the topics
discussed in this section are further discussed in ."Transmission and Processing of IPv6 Extension Headers" clarifies how intermediate nodes should process
Extension Headers. This document is generally consistent with
and addresses an issue that was raised for
discussion when was updated and replaced by
. This document updates as described in the next section and consequently
clarifies the description in ,
using the language of BCP 14 .This document defines a set of procedures for the Hop-by-Hop
Options header that are intended to make the processing of Hop-by-Hop
options practical in modern routers. The common cases are
that some Hop-by-Hop options will be processed across the Internet,
while others will only be processed within a limited domain (e.g., where a specific service is made available
in that network segment that relies on one or more Hop-by-Hop
options).Hop-by-Hop Header Processing ProceduresThis section describes several changes to . describes the processing of
the Hop-by-Hop options Extension Header, and describes
the processing of individual Hop-by-Hop options.
These sections update the text in paragraph 6 of
and, as noted in , modify
.Processing the Extension Header Carrying Hop-by-Hop OptionsWhen a packet includes one or more Extension Headers, the Next Header
field of the IPv6 Header identifies the type of Extension Header.
It does not identify the transport protocol.The Extension Header used to carry Hop-by-Hop options
is defined in and is identified
by a Next Header value of 0 in the IPv6
header. requires this Hop-by-Hop
Options header to appear immediately after the IPv6 header. also requires that a Hop-by-Hop Options header
only appear at most once in a packet.The Hop-by-Hop Options header as defined in
can contain
one or more Hop-by-Hop options.Routers that process the Hop-by-Hop Options header SHOULD do
so using the method defined in this document.
Exceptions to this SHOULD include routers that are configured to
drop packets with a Hop-by-Hop Options header to protect
downstream devices that do not comply with this
specification (see ).Even if a router does not process the Hop-by-Hop Options
header (for example, when based on configuration), it MUST forward the
packet normally based on the remaining Extension Header(s) after
the Hop-by-Hop Options header. A router MUST NOT drop a packet
solely because it contains an Extension Header carrying
Hop-by-Hop options. A configuration could control whether normal
processing skips any or all of the Hop-by-Hop options carried in
the Hop-by-Hop Options header.It is expected that the Hop-by-Hop Options header will be
processed by the destination(s).
Hosts SHOULD process the Hop-by-Hop Options header in
received packets. A constrained host is an example of a node
that does not process the Hop-by-Hop Options header.
If a destination does not process the Hop-by-Hop Options header,
it MUST process the remainder of the packet normally.
Configuration Enabling Hop-by-Hop Header Processing allows a router to control its processing
of IPv6 Hop-by-Hop options by local configuration. The text is:
NOTE: While required that all nodes must examine and
process the Hop-by-Hop Options header, it is now expected that nodes
along the path only examine and process the
Hop-by-Hop Options header if explicitly configured to do so.
This document clarifies that a configuration could control whether
processing skips any specific Hop-by-Hop options carried in the Hop-
by-Hop Options header. A router that does not process the contents
of the Hop-by-Hop Options header does not process any of the
Option Types contained in the Hop-by-Hop Options header.
Hop-by-Hop Options ProcessingA Source creating packets with a Hop-by-Hop Options header SHOULD use
a method that is robust to network nodes selectively processing only
some of the Hop-by-Hop options that are included in the packet or that forward
packets without the option(s) being processed (see ).
A Source MAY, based on local configuration,
allow only one Hop-by-Hop option to be included in a packet,
or it could allow more than one Hop-by-Hop option
but limit their size to increase the likelihood of successful
transfer across a network path.
Because some routers might only process one or a limited number of
options in the Hop-by-Hop Options header, Sources are motivated to
order the placement of Hop-by-Hop options within the Hop-by-Hop
Options header in decreasing order of importance for their
processing by nodes on the path.
A router configuration needs to avoid vulnerabilities that
arise when it cannot process the first Hop-by-Hop option at the Full
Forwarding Rate. Therefore, a router SHOULD NOT be configured to
process the first Hop-by-Hop option if this adversely impacts the
aggregate forwarding rate. A router SHOULD process additional
Hop-by-Hop options, if configured to do so, providing that these
also do not adversely impact the aggregate forwarding rate.If a router is unable to process a specific Hop-by-Hop option
(or is not configured to do so), it
SHOULD behave in the same way specified for an unrecognized Option Type when the
action bits are set to "00", and it
SHOULD skip the remaining options
using the "Hdr Ext Len" field in the
Hop-by-Hop Options header. This field specifies the length of the Options
Header in 8-octet units. After skipping an option, the router continues
processing the remaining options in the header.
Skipped options do not need to be verified.The Router
Alert Option is an exception
to this because it is designed to tell a router
that the packet needs additional processing, which is usually done
in the Control Plane; see .
defines the Option Type identifiers as internally encoded such that their
highest-order 2 bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type. The text is:
00 - skip over this option and continue processing the header.
01 - discard the packet.
10 - discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address,
send an ICMP Parameter Problem, Code 2, message to the
packet's Source Address, pointing to the unrecognized
Option Type.
11 - discard the packet and, only if the packet's Destination
Address was not a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address,
pointing to the unrecognized Option Type.
This document modifies this behavior for the "01", "10", and
"11" action bits so that if a router is unable to process a specific Hop-by-Hop option
(or is not configured to do so), it SHOULD behave in the same way
specified for an unrecognized Option Type when the
action bits are set to "00".
It also modifies the behavior for values "10" and "11" in the case where
the packet is discarded and the
node MAY send an ICMP Parameter Problem, Code 2 ,
message to the packet's Source Address, pointing to the unrecognized Option Type.The modified text for values "01", "10", and "11" is:
01 - MAY discard the packet, if so configured. Nodes should not
rely on routers dropping these unrecognized Option Types.
10 - MAY discard the packet, if so configured, regardless of
whether or not the packet's Destination Address was a
multicast address. If the packet was discarded, an ICMP
Parameter Problem, Code 2, message MAY be sent to the
packet's Source Address, pointing to the unrecognized
Option Type.
11 - MAY discard the packet, if so configured. If the packet
was discarded and the packet's Destination Address was
not a multicast address, an ICMP Parameter Problem,
Code 2, message MAY be sent to the packet's Source
Address, pointing to the unrecognized Option Type.
When an ICMP Parameter Problem, Code 2, message is delivered to the
Source, it
indicates that at least one node on the
path has failed to recognize the option .
Generating any ICMP message
incurs additional router processing.
Reception of this message is
not guaranteed;
routers might be unable to be configured so that they do not generate
these messages,
and they are not always forwarded to the Source.
The motivation here is to loosen
the requirement to send an ICMPv6 Parameter Problem message when a router
forwards a packet without processing the list of all options.Router Alert OptionThe purpose of the Router Alert Option is to tell
a router that the packet needs additional processing in the Control Plane.
The Router Alert Option includes a two-octet Value field that
describes the protocol that is carried in the packet.
The
current specified values can
be found in the "IPv6 Router Alert Option Values" IANA registry .DISCUSSIONThe function of a Router Alert Option can result in the processing
that this specification is proposing to eliminate, that is,
instructing a router to process the packet in the Control Plane.
This processing causes concerns, which are discussed in .
One approach would be to deprecate this, because current usage
beyond the local network appears to be limited, and packets containing
Hop-by-Hop options are frequently dropped. Deprecation would allow
current implementations to continue, and its use could be phased out
over time.The Router Alert Option could potentially be used with new
functions that have to be processed in the Control Plane. Keeping
this as the single exception for processing in the Control Plane
with the restrictions that follow is a reasonable compromise to
allow future flexibility. These restrictions are compatible
with .
As noted in ,
"Implementations of the IP Router Alert Option
SHOULD offer the configuration option to simply ignore the presence
of 'IP Router Alert' in IPv4 and IPv6 packets."A node that is configured to process a Router Alert Option
MUST protect itself from an infrastructure attack
that could result from processing in the Control Plane. This might include
some combination of an access control list to only permit access from trusted nodes,
rate limiting of processing, or other methods .As specified in , the top two bits of the Option Type
for the Router Alert Option are always set to "00", indicating that the node
should skip over this option as if it does not recognize the Option
Type and continue processing the header.
An implementation that does recognize the Router Alert Option
SHOULD verify that the Router Alert Option contains a
protocol, as indicated by the Value field in the Router Alert Option,
that is configured as a protocol of interest to that
router. A verified packet SHOULD be sent to the Control Plane for further processing
. Otherwise, the router implementation SHOULD forward
this packet subject to all normal policies and forwarding rules.
Configuration of Hop-by-Hop Options ProcessingA router can be configured to process a specific Option. The set
of enabled options SHOULD be configurable by the operator of the
router.A possible approach to implementing this is to maintain a lookup
table based on an Option Type of the IPv6 options that can be
processed at the Full Forwarding Rate. This would allow a router to
quickly determine if an option is supported and can be processed.
If the option is not supported, then the router processes the
option as described in of this document.The actions of the lookup table should be configurable by the operator of
the router.Defining New Hop-by-Hop OptionsThis section updates .Any future new IPv6 Hop-by-Hop options should be designed to
be processed at the Full Forwarding Rate and should have the following characteristics:
New Hop-by-Hop options should
be designed to ensure the router can process the options at the Full
Forwarding Rate. That is, they should be simple to process.
New Hop-by-Hop options should be defined with the Action type (highest-order 2
bits of the Option Type) set to "00", which enables skipping over this option
and continuing with the processing of the header if a router does not recognize
the option.
The size of Hop-by-Hop options should not extend beyond what can be
expected to be executed at the Full Forwarding Rate. A larger Hop-by-Hop
Options header can increase the likelihood that a packet will be
dropped .
New Hop-by-Hop options should be designed with the expectation that a router
might be configured to only process a subset of Hop-by-Hop options (e.g., the first option) in the
Hop-by-Hop Options header.
The design of protocols that use new Hop-by-Hop options should consider
that a router may drop packets containing the new Hop-by-Hop option.
If a new Hop-by-Hop option does not meet
these criteria, its specification must include a detailed
explanation why that is the case and show that there
is a reasonable expectation that the option can still proceed at the Full
Forwarding Rate. This is consistent with [RFC6564].
This is consistent with .The general issue of robust operation of packets with new
Hop-by-Hop options is described in .Example of Robust UsageRecent measurement
surveys (e.g., )
show that packets that include Extension Headers can cause the packets to
be dropped by some
Internet paths. In a limited domain, routers can be configured or updated
to provide support for any required Hop-by-Hop options.The primary motivation of this document is to make it
more practical to use Hop-by-Hop options beyond such a limited domain, with the
expectation that applications can improve the
quality of or add new features to their offered service when
the path successfully forwards packets with the required Hop-by-Hop options
and otherwise refrains from using these options.
The focus is on incremental deployability.
A protocol feature (such as using Hop-by-Hop options) is incrementally
deployable if early adopters gain some
benefit on the paths being used, even though other paths do not support the
protocol feature.
A Source ought to order the Hop-by-Hop options that are carried
in the Hop-by-Hop Options header in decreasing order of
importance for processing by nodes on the path.
Methods can be developed that do not rely upon all routers
to implement a specific Hop-by-Hop option (e.g., )
and that are robust when the
current path drops packets that contain a Hop-by-Hop option (e.g.,
).For example, an application can be designed to first send
a test packet that includes the required option or combination
of options and then send other packets without including
the option. The application does not send additional
packets that include this option (or set of options) until the
test packet(s) is acknowledged.
The need for potential loss recovery when a path drops
these test packets can be avoided by choosing packets that do not
carry application data that needs to be reliably delivered.Since the set of nodes forming a path can change with time,
this discovery process ought to be repeated from time to time.
The process of sending packets both with and without a specific
header to discover whether a path can support a specific header
is sometimes called "racing". Transport protocol racing
is explained in ,
and A/B protocol feature testing is described in .IANA ConsiderationsThis document updates the processing of
Hop-by-Hop options.
IANA has added this document as an
additional reference for the "Destination Options and Hop-by-Hop Options" registry
in the "Internet Protocol Version 6 (IPv6) Parameters" registry group .Security ConsiderationsSecurity issues caused by including IPv6 Hop-by-Hop options are well known and have
been documented in several places, including
,
, , and
.
The main issue, as noted in , is that
any mechanism that can be used to force packets into the
router's Control Plane or Slow Path can be exploited as a DoS attack on a
router by saturating the resources needed for router management
(routing protocols, network management protocols, etc.), and this can
cause the router to fail or perform suboptimally. While Hop-by-Hop options are not required to be processed in the
Control Plane, the Router Alert Option is the one exception that is designed
to be processed in the Control Plane.Some IPv6 nodes implement features that access more of the protocol
information than a typical IPv6 router (e.g., ).
Examples are nodes that provide
DoS mitigation, firewall/access control, traffic engineering,
or traffic normalization. These nodes
could be configured to drop packets when they are unable to access
and process all Extension Headers or are unable to locate and process
the higher-layer packet information. This document provides guidance
on the requirements concerning Hop-by-Hop options. Finally, this document notes that Internet protocol processing needs to be robust for
malformed/malicious protocol fields.
For example, a packet with an
excessive number of options could consume significant resources;
inclusion of a large Extension Header could potentially cause an
on-path router to be unable to utilize hardware optimizations
to process later headers (e.g., to perform equal cost multipath
forwarding or port filtering).
This requirement is not specific to
Hop-by-Hop options. It is important that implementations
fail gracefully when a malformed or malicious Hop-by-Hop option is encountered.This document changes how the Hop-by-Hop Options header is processed,
which significantly reduces the attack surface. These changes include the following:
A router configuration needs to avoid vulnerabilities that
arise when it cannot process a Hop-by-Hop option at the Full
Forwarding Rate; therefore, it SHOULD NOT be configured to
process the Hop-by-Hop option if it adversely impacts the
aggregate forwarding rate. Instead, it
SHOULD behave in the same way specified for an unrecognized Option Type when the
action bits are set to "00", as specified in .
This document adds criteria for the Router Alert Option ()
to allow control over how it is
processed and describes how a node configured to support these options must
protect itself from attacks by using the Router Alert Option.
This document sets the expectation that if a packet
includes a Hop-by-Hop Options header, the packet will be forwarded across the network path.
A Source MAY include a single Hop-by-Hop option (based on
local configuration) or MAY be configured to include more
Hop-by-Hop options. The configuration of intermediate nodes determines
whether a node processes any of these options, and if so, which ones and how many.
This document adds guidance for the design of
any future new Hop-by-Hop option that reduces the
computational requirements and encourages a
limit to their size.
The intent of this document is to highlight that these changes significantly reduce the
security issues relating to processing the IPv6 Hop-by-Hop Options header
and enable Hop-by-Hop options to be safely used in the Internet.Normative ReferencesDestination Options and Hop-by-Hop OptionsIANAKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Internet Protocol, Version 6 (IPv6) SpecificationThis document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.Informative ReferencesInternet Measurements: IPv6 Extension Header EditionIEPG Meeting: IETF 116Is it possible to extend IPv6?Computer Communications, vol. 214, pp. 90-99Operational Issues with Processing of the Hop-by-Hop Options HeaderHuawei TechnologiesHuawei TechnologiesChina TelecomChina UnicomVerizon Inc. This document describes the processing of the Hop-by-Hop Options
Header (HBH) in current routers in the aspects of standards
specification, common implementations, and default operations. This
document outlines reasons why the Hop-by-Hop Options Header is rarely
utilized in current networks. In addition, this document describes
how HBH Options Header could be used as a powerful mechanism allowing
deployment and operations of new services requiring a more optimized
way to leverage network resources of an infrastructure. The purpose
of this draft is to document reasons why HBH Options Header is rarely
used within networks. It motivates the benefits and requirements
needed to enable wider use of HBH Options.
Work in ProgressThreats and Surprises behind IPv6 Extension HeadersUniversity of TwenteUniversity of TwenteUniversity of TwenteUniversity of TwenteUniversity of Twente2017 Network Traffic Measurement and Analysis Conference (TMA)IPv6 Router Alert Option ValuesIANAInternet Protocol, Version 6 (IPv6) SpecificationThis document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]Internet Protocol, Version 6 (IPv6) SpecificationThis document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK]IPv6 Router Alert OptionThis memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS-TRACK]Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) SpecificationThis document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]Protecting the Router Control PlaneThis memo provides a method for protecting a router's control plane from undesired or malicious traffic. In this approach, all legitimate router control plane traffic is identified. Once legitimate traffic has been identified, a filter is deployed in the router's forwarding plane. That filter prevents traffic not specifically identified as legitimate from reaching the router's control plane, or rate-limits such traffic to an acceptable level.Note that the filters described in this memo are applied only to traffic that is destined for the router, and not to all traffic that is passing through the router. This document is not an Internet Standards Track specification; it is published for informational purposes.IP Router Alert Considerations and UsageThe IP Router Alert Option is an IP option that alerts transit routers to more closely examine the contents of an IP packet. The Resource reSerVation Protocol (RSVP), Pragmatic General Multicast (PGM), the Internet Group Management Protocol (IGMP), Multicast Listener Discovery (MLD), Multicast Router Discovery (MRD), and General Internet Signaling Transport (GIST) are some of the protocols that make use of the IP Router Alert Option. This document discusses security aspects and usage guidelines around the use of the current IP Router Alert Option, thereby updating RFC 2113 and RFC 2711. Specifically, it provides recommendations against using the Router Alert in the end-to-end open Internet and identifies controlled environments where protocols depending on Router Alert can be used safely. It also provides recommendations about protection approaches for service providers. Finally, it provides brief guidelines for Router Alert implementation on routers. This memo documents an Internet Best Current Practice.A Uniform Format for IPv6 Extension HeadersIn IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the transport-layer header. There are a small number of such extension headers currently defined. This document describes the issues that can arise when defining new extension headers and discusses the alternate extension mechanisms in IPv6. It also provides a common format for defining any new IPv6 extension headers, if they are needed. [STANDARDS-TRACK]Transmission and Processing of IPv6 Extension HeadersVarious 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 the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.Observations on the Dropping of Packets with IPv6 Extension Headers in the Real WorldThis document presents real-world data regarding the extent to which packets with IPv6 Extension Headers (EHs) are dropped in the Internet (as originally measured in August 2014 and later in June 2015, with similar results) and where in the network such dropping occurs. The aforementioned results serve as a problem statement that is expected to trigger operational advice on the filtering of IPv6 packets carrying IPv6 EHs so that the situation improves over time. This document also explains how the results were obtained, such that the corresponding measurements can be reproduced by other members of the community and repeated over time to observe changes in the handling of packets with IPv6 EHs.Limited Domains and Internet ProtocolsThere is a noticeable trend towards network behaviors and semantics that are specific to a particular set of requirements applied within a limited region of the Internet. Policies, default parameters, the options supported, the style of network management, and security requirements may vary between such limited regions. This document reviews examples of such limited domains (also known as controlled environments), notes emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the need for a precise definition of "limited domain membership" and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes.This document is the product of the research of the authors. It has been produced through discussions and consultation within the IETF but is not the product of IETF consensus.Operational Implications of IPv6 Packets with Extension HeadersThis document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC 8200) and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet.IPv6 Minimum Path MTU Hop-by-Hop OptionThis document specifies a new IPv6 Hop-by-Hop Option that is used to record the Minimum Path MTU (PMTU) along the forward path between a source host to a destination host. The recorded value can then be communicated back to the source using the return Path MTU field in the Option.Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers at Transit RoutersThis document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary.Architecture and Requirements for Transport ServicesApple Inc.Google Switzerland GmbHKarlstad UniversityUniversity of AberdeenUniversity of GlasgowWork in ProgressTracking Transport-Layer Evolution with PATHspiderANRW '17: Proceedings of the 2017 Applied Networking Research WorkshopAcknowledgmentsHelpful comments were received from , , , , , , , , , , , , , , , , , , , ,
, ,
, , and
other members of the 6MAN Working Group.Authors' AddressesCheck Point Software100 Oracle Parkway, Suite 800Redwood CityCA94065United States of Americabob.hinden@gmail.comUniversity of AberdeenSchool of EngineeringFraser Noble BuildingAberdeenAB24 3UEUnited Kingdomgorry@erg.abdn.ac.uk