Internet DRAFT - draft-herbert-ipv4-eh
draft-herbert-ipv4-eh
Network Working Group T. Herbert
Internet-Draft SiPanda
Intended status: Standards Track 23 February 2024
Expires: 26 August 2024
IPv4 Extension Headers and Flow Label
draft-herbert-ipv4-eh-03
Abstract
This specification defines extension headers for IPv4 and an IPv4
flow label. The goal is to provide a uniform and feasible method of
extensibility that is common between IPv4 and IPv6.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 August 2024.
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 (https://trustee.ietf.org/
license-info) 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.
Herbert Expires 26 August 2024 [Page 1]
Internet-Draft IPv4 EH February 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. IPv4 extension headers . . . . . . . . . . . . . . . 5
1.1.2. IPv4 flow labels . . . . . . . . . . . . . . . . . . 6
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. IPv4 Extension Headers . . . . . . . . . . . . . . . . . . . 6
2.1. Adapting IPv6 Extension headers . . . . . . . . . . . . . 6
2.2. General requirements . . . . . . . . . . . . . . . . . . 7
2.3. Extension Header Order . . . . . . . . . . . . . . . . . 9
2.4. Options . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 13
2.5.1. Hop-by-Hop Options format . . . . . . . . . . . . . . 13
2.5.2. Hop-by-Hop Options Processing . . . . . . . . . . . . 14
2.6. Routing Header . . . . . . . . . . . . . . . . . . . . . 15
2.7. Fragment Header . . . . . . . . . . . . . . . . . . . . . 17
2.7.1. Fragment Header format . . . . . . . . . . . . . . . 17
2.7.2. Procedures . . . . . . . . . . . . . . . . . . . . . 17
2.7.3. Rules for reassembly . . . . . . . . . . . . . . . . 21
2.8. Destination Options Header . . . . . . . . . . . . . . . 23
2.9. No Next Header . . . . . . . . . . . . . . . . . . . . . 25
2.10. Interaction with standard IPv4 mechanisms . . . . . . . . 25
2.10.1. IPv4 options and IPv4 extension headers . . . . . . 25
2.10.2. IPv4 fragmentation and IPv4 extension headers . . . 25
3. ICMPv4 messages for extension headers . . . . . . . . . . . . 26
3.1. Ext-hdr Time Exceeded Message . . . . . . . . . . . . . . 26
3.2. Ext-hdr Parameter Problem Message . . . . . . . . . . . . 27
3.2.1. Erroneous header field encountered (Code 0) . . . . . 28
3.2.2. Unrecognized Next Header type encountered (Code 1) . 29
3.2.3. Unrecognized IPv4 option encountered (Code 2) . . . . 29
3.2.4. IPv4 First Fragment has incomplete IPv4 Header Chain
(Code 3) . . . . . . . . . . . . . . . . . . . . . . 29
3.2.5. Unrecognized Next Header Type Encountered by
Intermediate Node (Code 5) . . . . . . . . . . . . . 29
3.2.6. Extension Header Too Big (Code 6) . . . . . . . . . . 29
3.2.7. Extension Header Chain Too Long (Code 7) . . . . . . 30
3.2.8. Too Many Extension Headers (Code 8) . . . . . . . . . 30
3.2.9. Too Many Options in Extension Header (Code 9) . . . . 30
3.2.10. Option Too Big (Code 10) . . . . . . . . . . . . . . 30
4. Inflight Removal of IPv4 Hop-by-Hop and Routing Headers . . . 31
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 31
4.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1. Removing a Hop-by-Hop Options Header . . . . . . . . 32
4.2.2. Removing a Routing Header . . . . . . . . . . . . . . 34
4.2.3. Removing both a Hop-by-Hop Options and a Routing
header . . . . . . . . . . . . . . . . . . . . . . . 36
5. The IPv4 flow label . . . . . . . . . . . . . . . . . . . . . 38
Herbert Expires 26 August 2024 [Page 2]
Internet-Draft IPv4 EH February 2024
5.1. Sender Requirements . . . . . . . . . . . . . . . . . . . 38
5.2. Receiver Requirements . . . . . . . . . . . . . . . . . . 39
6. Deployability Considerations . . . . . . . . . . . . . . . . 40
7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
8.1. IPv4 Extension Header types . . . . . . . . . . . . . . . 41
8.2. Destination Options and Hop-by-Hop Options . . . . . . . 41
8.3. ICMP Parameters . . . . . . . . . . . . . . . . . . . . . 41
8.3.1. Ext-hdr Time Exceeded . . . . . . . . . . . . . . . . 42
8.3.2. Ext-hdr Parameter Problem . . . . . . . . . . . . . . 42
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Normative References . . . . . . . . . . . . . . . . . . 43
9.2. Informative References . . . . . . . . . . . . . . . . . 43
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction
This specification defines extension headers for IPv4 as well as an
IPv4 flow label. The motivation is to provide extensible protocol
mechanisms in IPv4 that are unified with IPv6, thus leveraging common
protocol and implementation for extensibility between the two
versions of the Internet Protocol. Additionally, this specification
defines ICMPv4 messages related to extension headers that are
equivalents of corresponding ICMPv6 messages.
This specification allows the core extension headers defined in
[RFC8200] to be used with IPv4. These extension headers include Hop-
by-Hop Options, Destination Options, Routing Header, and Fragment
Header. Note that Authentication Header [RFC4302] and Encapsulating
Security Payload [RFC4303] are already usable with IPv4.
Additionally, No Next Header (protocol number 59) [RFC8200] is
specified to be usable in IPv4 packets. In addition to enabling the
use of extension headers in IPv4, messages are defined in ICMPv4 for
reporting errors related to IPv4 extension headers; the ICMP types
and codes for these messages are adapted from corresponding ICMPv6
messages [RFC4443] [RFC8883].
The IPv4 flow label is similarly derived from the definition of the
IPv6 flow label. There is no flow label defined in the IPv4 header
[RFC791], however under specific circumstances this specification
allows the sixteen bit Identification field in the IPv4 header to be
safely used as a flow label.
Herbert Expires 26 August 2024 [Page 3]
Internet-Draft IPv4 EH February 2024
1.1. Motivation
IPv6 is intended to become the standard protocol of the Internet,
however it is clear that there is a large segment of users that will
be using IPv4 for the foreseeable future. This is particularly true
in many enterprises where a business case for transitioning to IPv6
hasn't yet emerged [V6STATE].
In lieu of sun-setting IPv4 and expecting all users to move to IPv6
in some time frame that is unlikely to be met, this specification
suggests an alternative which is to extend IPv4 with IPv6 features.
The idea is to "backport" useful features of IPv6 into IPv4,
essentially making IPv4 look more like IPv6. The rationale for this
is:
1) Users benefit from forward looking features being actively
defined and developed for IPv6 without requiring them to
immediately transition to IPv6.
2) This approach encourages common implementation of protocol
features that can be shared between IPv6 and IPv4.
3) In making IPv4 look more like IPv6, the work required to
complete a future transition to IPv6 may be reduced or
simplified.
Various standards and proposals using IPv6 extension headers are
currently being deployed or discussed in IETF. These include Segment
Routing Header [RFC8754], Compressed Routing Header
[I-D.ietf-6man-comp-rtg-hdr], Path MTU Option [RFC9268], In-situ OAM
[RFC9486], Service-aware IPv6 Network
[I-D.li-6man-app-aware-ipv6-network], and Firewall and Service
Tickets [I-D.herbert-fast]. These protocols leverage the
extensibility of extension headers defined for IPv6. All of these
proposals, in some form, could be of value for use with IPv4, however
IPv4 lacks an extensibility mechanism that meets the requirements for
supporting them.
Of particular interest is enabling use of the Fragment Header in IPv4
for IP fragmentation. While IPv4 includes fragmentation as part of
the core protocol, it uses a sixteen bit Identification value that is
considered too small and not sufficiently robust [RFC8900]. The
Fragment Header defines a thirty-two bit Identification field that
addresses this concern if the Fragment Header can be used with IPv4
to perform fragmentation.
Herbert Expires 26 August 2024 [Page 4]
Internet-Draft IPv4 EH February 2024
This document enables IPv4 packets to carry extension headers in the
same manner that IPv6 packets carry extension headers including Hop-
by-Hop and Destination options. In doing so, the various extensions
and options defined for IPv6 can be used with IPv4. In many cases,
such as the Fragment Header, Path MTU Hop-by-Hop option, and IOAM
Hop-by-Hop options; extension headers or options are mostly protocol
agnostic and would be applicable and usable with IPv4 with little or
no change. In other cases, such as Segment Routing, the extension
header might be IPv6 specific, for example the Segment Routing Header
contains a list of IPv6 addresses. With some modification to the
extension header definition, it is conceivable that these may work
with IPv4. For instance, the Segment Routing Header could be adapted
for use with IPv4 by defining a routing header format that contains
IPv4 addresses instead of IPv6 addresses.
1.1.1. IPv4 extension headers
IPv4 options were defined in [RFC791] as the means of extending the
IP protocol. IPv4 options have not been successful. Early router
implementations, and even those today, either don't process IPv4
options or relegate them to a slow path effectively making them
unusable for serious applications. IPv4 options are limited to forty
bytes length and, unlike TCP options, no IP options have been defined
that are critical to communications. The upshot is that IPv4 options
have long not been considered an option for deployment [IPNOOP].
IPv6 took a different approach. Extensibility of IPv6 is provided by
extension headers. Optional internet-layer information is encoded in
separate headers that may be placed between the IPv6 header and the
upper-layer header in a packet [RFC8200]. IPv6 extension headers
have had mixed success in deployment, especially in the open Internet
because some intermediate devices have trouble processing them
[RFC7872] [RFC9098]. However, there is ongoing work to address the
deployability of IPv6 extension headers
[I-D.ietf-6man-hbh-processing] [I-D.ietf-6man-eh-limits]
[I-D.ietf-v6ops-hbh].
Using extension headers with IPv4 is logically straightforward. The
IPv4 Protocol field is effectively re-designated to be a Next Header
field with the same meaning and semantics as the IPv6 Next Header
field. In this manner, an IPv4 packet can contain IPv6 extension
headers that are recast as IPv4 extension headers. These include
Hop-by-Hop Options, Routing Header, Fragment Header, Destination
Options, Authentication Header, and Encapsulating Security Payload.
In cases where an extension header contains IPv6 specific
information, the extension header can be adapted for use with IPv4.
For instance, a Routing Header carrying IPv6 addresses in the route
list could be adapted to carry IPv4 addresses.
Herbert Expires 26 August 2024 [Page 5]
Internet-Draft IPv4 EH February 2024
There are a number of messages defined in ICMPv6 for reporting errors
related to extension headers. The types for these errors are Time
Exceeded and Parameter Problem. This document defines "Ext-hdr Time
Exceeded" and "Ext-hdr Parameter Problem" types in ICMPv4 for
reporting errors concerning IPv4 extension headers. The same ICMP
codes related to extension headers in the corresponding ICMPv6 types
are used in the ICMPv4 messages.
1.1.2. IPv4 flow labels
IPv6 [RFC8200] introduced the concept of a flow label that has proven
quite useful for flow classification, such as that needed by Equal-
Cost Multipath (ECMP). The base IPv4 header does not have reserved
bits that could be allocated as a flow label, however this
specification allows the sixteen bit Identification field to be used
as a flow label in atomic datagrams [RFC6864].
1.2. Terminology
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 [RFC2119].
2. IPv4 Extension Headers
In IPv4, optional internet-layer information is encoded in separate
headers that may be placed between the IPv4 header and the upper-
layer header in a packet. There is a small number of such extension
headers, each one identified by a distinct Next Header value.
2.1. Adapting IPv6 Extension headers
IPv4 extension headers are adapted from IPv6 extension headers as
defined in Section 4 of [RFC8200], with the following modifications:
* References to the IPv6 header are replaced by references to the
IPv4 header.
* ICMP errors sent in the course of processing extension headers use
ICMPv4 instead of ICMPv6. Applicable ICMPv4 errors for extension
header processing are specified in Section 3.
* The IPv4 header Protocol field assumes the same role and semantics
with respect to extension headers as the IPv6 Next Header field.
Herbert Expires 26 August 2024 [Page 6]
Internet-Draft IPv4 EH February 2024
* If a legacy IPv4 destination host, one that does not support IPv4
extension headers, receives a packet with extension headers then
the packet will be processed as having an unknown protocol. It is
expected that the packet will be discarded and an ICMP error may
be generated.
* Extension headers or options that carry IPv6 specific data or are
otherwise specific to IPv6 MUST NOT be used with IPv4 (Segment
Routing [RFC8754] for example). IPv4 variants of these MAY be
defined if achieving the same functionality in IPv4 is desirable.
* References to the Payload Length, for instance in reassembly
procedures, are reinterpreted as being the computed IPv4 payload
length, that is IPv4 Total Length minus the length of the IPv4
header.
* The Hop-by-Hop Options header is used to carry optional
information that MAY be examined and processed by any node along a
packet's delivery path.
* The IPv4 Hop-by-Hop Options header MAY be processed by routers.
For routers that support IPv4 Hop-by-Hop options, processing of
the header SHOULD be configurable where the default SHOULD be not
to process the Hop-by-Hop Options header. If a router is
configured to process IPv4 Hop-by-Hop Options then processing
procedures in Section 2.5.2 SHOULD be followed and limits on
router processing of Hop-by-Hop Options in
[I-D.ietf-6man-eh-limits] SHOULD be configurable.
* If a router that does not recognize IPv4 extension headers
receives a packet with an extension header then it SHOULD forward
the packet normally based on the addresses in the IPv4 header.
Note that this is the same expected behavior for routers that
receive a packet with any IP protocol they don't recognize.
2.2. General requirements
Extension headers are numbered from IANA IP Protocol Numbers
[IANA-PN], the same values used for IPv4 and IPv6. When processing a
sequence of Next Header values in a packet, the first one that is not
an extension header [IANA-EH] indicates that the next item in the
packet is the corresponding upper-layer header. A special "No Next
Header" value is used if there is no upper-layer header
(Section 2.9).
As illustrated in these examples, an IPv4 packet MAY carry zero, one,
or more extension headers, each identified by the Next Header field
of the preceding header:
Herbert Expires 26 August 2024 [Page 7]
Internet-Draft IPv4 EH February 2024
+---------------+------------------------
| IPv4 header | TCP header + data
| |
| Protocol = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv4 header | Routing header | TCP header + data
| | |
| Protocol = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+-----------------
| IPv4 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Protocol = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
Extension headers (except for the Hop-by-Hop Options header and the
Routing Header) MUST NOT processed, inserted, or deleted 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 IPv4 header.
The Hop-by-Hop Options header MUST NOT inserted by any node, 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 IPv4 header. The Hop-by-Hop Options header MAY be removed from a
packet by a node in the delivery path as specified in Section 4.
The Hop-by-Hop Options header, when present, MUST immediately follow
the IPv4 header. Its presence is indicated by the value zero in the
Protocol field of the IPv4 header. A router MUST only examine and
process a Hop-by-Hop Options header if it is configured to do so. If
a router is not configured to process Hop-by-Hop Options header then
it SHOULD forward packets containing a Hop-by-Hop Options header
normally.
The Routing Header header MUST NOT inserted or processed by any node,
but MAY be removed from the packet by a node in the delivery path as
specified in Section 4.
Herbert Expires 26 August 2024 [Page 8]
Internet-Draft IPv4 EH February 2024
At the destination node, normal demultiplexing on the Protocol field
of the IPv4 header invokes the module to process the first extension
header, or the upper-layer header if no extension header is present.
The contents and semantics of each extension header determine whether
or not to proceed to the next header. Therefore, extension headers
MUST be processed strictly in the order they appear in the packet; a
receiver MUST NOT, for example, scan through a packet looking for a
particular kind of extension header and process that header prior to
processing all preceding ones.
If, as a result of processing a header, the destination node is
required to proceed to the next header but the Protocol field in the
IPv4 header or Next Header value in the current extension header is
unrecognized by the node, it SHOULD discard the packet and MAY send
an ICMP Ext-hdr Parameter Problem message to the source of the
packet, with an ICMP Code value of 1 ("unrecognized Next Header type
encountered") and the ICMP Pointer field containing the offset of the
unrecognized value within the original packet (Section 3). The same
action SHOULD be taken if a node encounters a Next Header value of
zero in any header other than the Protocol field of the IPv4 header.
Each extension header is an integer multiple of 8 octets long, in
order to retain 8-octet alignment for subsequent headers. Multi-
octet fields within each extension header are aligned on their
natural boundaries, i.e., fields of width n octets are placed at an
integer multiple of n octets from the start of the header, for n = 1,
2, 4, or 8.
An implementation of IPv4 may support the following IPv4 extension
headers:
Hop-by-Hop Options
Fragment
Destination Options
Routing
Authentication
Encapsulating Security Payload
The first four are specified in this document; the last two are
specified in [RFC4302] and [RFC4303], respectively. The current list
of IPv4 extension headers can be found at [IANA-EH].
2.3. Extension Header Order
When more than one extension header is used in the same packet, it is
RECOMMENDED that those headers appear in the following order:
IPv4 header
Herbert Expires 26 August 2024 [Page 9]
Internet-Draft IPv4 EH February 2024
Hop-by-Hop Options header
Destination Options header (note 1)
Routing header
Fragment header
Authentication header (note 2)
Encapsulating Security Payload header (note 2)
Destination Options header (note 3)
Upper-Layer header
note 1: for options to be processed by the first destination
that appears in the IPv4 Destination Address field plus
subsequent destinations listed in the Routing header.
note 2: additional recommendations regarding the relative order
of the Authentication and Encapsulating Security Payload
headers are given in [RFC4303].
note 3: for options to be processed only by the final
destination of the packet.
Each extension header SHOULD occur at most once, except for the
Destination Options header, which SHOULD occur at most twice (once
before a Routing header and once before the upper-layer header).
If the upper-layer header is another IPv4 header (in the case of IPv4
being tunneled over or encapsulated in IPv4), it MAY be followed by
its own extension headers, which are separately subject to the same
ordering recommendations.
If and when other extension headers are defined, their ordering
constraints relative to the above listed headers MUST be specified.
IPv4 nodes MUST accept and attempt to process extension headers in
any order and occurring any number of times in the same packet,
except for the Hop-by-Hop Options header, which is restricted to
appear immediately after an IPv4 header only. Nonetheless, it is
strongly RECOMMENDED that sources of IPv4 packets adhere to the above
recommended order until and unless subsequent specifications revise
that recommendation.
2.4. Options
Two of the currently defined extension headers specified in this
document -- the Hop-by-Hop Options header and the Destination Options
header -- carry a variable number of "options" that are type-length-
value (TLV) encoded in the following format:
Herbert Expires 26 August 2024 [Page 10]
Internet-Draft IPv4 EH February 2024
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type 8-bit identifier of the type of option.
Opt Data Len 8-bit unsigned integer. Length of the
Option Data field of this option, in
octets.
Option Data Variable-length field. Option-Type-
specific data.
The sequence of options within a header MUST be processed strictly in
the order they appear in the header; a receiver MUST NOT, for
example, scan through the header looking for a particular kind of
option and process that option prior to processing all preceding
ones.
The Option Type identifiers are internally encoded such that their
highest-order 2 bits specify the action that MUST be taken if the
processing IPv4 node does not recognize the Option Type:
00 - SHOULD skip over this option and continue processing the
header.
01 - MAY discard the packet.
10 - MAY discard the packet and, regardless of whether or not the
packet's Destination Address was a multicast address, MAY
send an ICMP Ext-hdr Parameter Problem, Code 2, message to
the packet's Source Address, pointing to the unrecognized
Option Type.
11 - MAY discard the packet and, only if the packet's Destination
Address was not a multicast address, MAY send an ICMP Ext-
hdr Parameter Problem, Code 2, message to the packet's
Source Address, pointing to the unrecognized Option Type.
The third-highest-order bit of the Option Type specifies whether or
not the Option Data of that option can change en route to the
packet's final destination. When an Authentication header is present
in the packet, for any option whose data may change en route, its
entire Option Data field MUST be treated as zero-valued octets when
computing or verifying the packet's authenticating value.
0 - Option Data does not change en route
Herbert Expires 26 August 2024 [Page 11]
Internet-Draft IPv4 EH February 2024
1 - Option Data may change en route
The three high-order bits described above are to be treated as part
of the Option Type, not independent of the Option Type. That is, a
particular option is identified by a full 8-bit Option Type, not just
the low-order 5 bits of an Option Type.
The same Option Type numbering space is used for both the Hop-by-Hop
Options header and the Destination Options header. However, the
specification of a particular option MAY restrict its use to only one
of those two headers.
Individual options may have specific alignment requirements, to
ensure that multi-octet values within Option Data fields fall on
natural boundaries. The alignment requirement of an option is
specified using the notation xn+y, meaning the Option Type must
appear at an integer multiple of x octets from the start of the
header, plus y octets. For example:
2n means any 2-octet offset from the start of the header.
8n+2 means any 8-octet offset from the start of the header, plus
2 octets.
There are two padding options that are used when necessary to align
subsequent options and to pad out the containing header to a multiple
of 8 octets in length. These padding options MUST be recognized by
all IPv4 implementations that support extension headers:
Pad1 option (alignment requirement: none)
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
NOTE! the format of the Pad1 option is a special case -- it does not
have length and value fields.
The Pad1 option is used to insert 1 octet of padding into the Options
area of a header. If more than one octet of padding is required, the
PadN option, described next, SHOULD be used, rather than multiple
Pad1 options.
PadN option (alignment requirement: none)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Herbert Expires 26 August 2024 [Page 12]
Internet-Draft IPv4 EH February 2024
The PadN option is used to insert two or more octets of padding into
the Options area of a header. For N octets of padding, the Opt Data
Len field contains the value N-2, and the Option Data consists of N-2
zero-valued octets.
Appendix A of [RFC8200] contains applicable formatting guidelines for
designing new options.
2.5. Hop-by-Hop Options Header
The Hop-by-Hop Options header is used to carry optional information
that MAY be examined and processed by any node along a packet's
delivery path. The Hop-by-Hop Options header is identified by a
Protocol value of 0 in the Protocol field of the IPv4 header.
2.5.1. Hop-by-Hop Options format
The Hop-by-Hop Options header has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of
header immediately following the Hop-by-
Hop Options header. Uses the same values
as the IPv4 Protocol field [IANA-PN].
Hdr Ext Len 8-bit unsigned integer. Length of the
Hop-by-Hop Options header in 8-octet
units, not including the first 8 octets.
Options Variable-length field, of length such
that the complete Hop-by-Hop Options
header is an integer multiple of 8 octets
long. Contains one or more TLV-encoded
options, as described in Section 2.4.
The only hop-by-hop options defined in this document are the Pad1 and
PadN options specified in Section 2.4.
Herbert Expires 26 August 2024 [Page 13]
Internet-Draft IPv4 EH February 2024
2.5.2. Hop-by-Hop Options Processing
The requirements in this section are adapted from the IPv6
requirements for extension header processing in [RFC8200],
[I-D.ietf-6man-hbh-processing], and [I-D.ietf-6man-eh-limits].
Routers that support IPv4 extension headers SHOULD process the Hop-
by-Hop Options header using the method defined in this document. If
a router does not process the Hop-by-Hop Options header, it SHOULD
forward the packet normally based on the remaining Extension Header
after the Hop-by-Hop Option header (i.e., a router SHOULD NOT drop a
packet solely because it contains an Extension Header carrying Hop-
by-Hop options). A configuration could control that normal
processing skips any or all of the Hop-by-Hop options carried in the
Hop-by-Hop Options header.
In the case of a legacy router that doesn't recognize a Hop-by-Hop
Options header it is expected that the router will forward packets
with Hop-by-Hop Options based on the contents of the IPv4 header;
this is the same behavior for routers that forwarded packets of any
IP protocol they don't recognize.
It is expected that the Hop-by-Hop Options header will be processed
by the Destination. 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 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.
A source MAY limit the its use of Hop-by-Hop Options, either by the
number of options or size of the Hop-by-Hop Options header, to
increase the likelihood of successful transit across a network path
as specified in [I-D.ietf-6man-eh-limits]. Because some routers
might only process a limited number of options in the Hop-by-Hop
Option 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 Hop-by-Hop options at full forwarding rate. A
router MAY apply limits specified in [I-D.ietf-6man-eh-limits] to
Hop-by-Hop processing to ensure it can meet the targeted forwarding
rate.
If a router is unable to process any Hop-by-Hop option (or is not
configured to do so), it SHOULD behave in the way specified for an
unrecognized Option Type when the action bits were set to "00".
Herbert Expires 26 August 2024 [Page 14]
Internet-Draft IPv4 EH February 2024
If a router is unable to process further Hop-by-Hop options (or is
not configured to do so), the router 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 Option 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.
When a node sends an ICMP message in response to a multicast packet,
this could be exploited as an amplification attack. This is
particularly problematic when the source address is not valid (which
can be mitigated when using a reverse path forwarding (RPF) check).
A node SHOULD only send ICMP messages in response to a multicast
address when this is enabled for the specific source and/or the group
destination address.
When an ICMP Ext-hdr Parameter Problem, Code 2, message is delivered
to the source, the source can become aware that at least one node on
the path has failed to recognize the option. Generating an 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.
2.6. Routing Header
The Routing header is used by an IPv4 source to list one or more
intermediate nodes to be "visited" on the way to a packet's
destination. The Routing header is identified by a Protocol or Next
Header value of 43 in the immediately preceding header and has the
following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of
header immediately following the Routing
header. Uses the same values as the IPv4
Protocol field [IANA-PN].
Hdr Ext Len 8-bit unsigned integer. Length of the
Herbert Expires 26 August 2024 [Page 15]
Internet-Draft IPv4 EH February 2024
Routing header in 8-octet units, not
including the first 8 octets.
Routing Type 8-bit identifier of a particular Routing
header variant.
Segments Left 8-bit unsigned integer. Number of route
segments remaining, i.e., number of
explicitly listed intermediate nodes
still to be visited before reaching the
final destination.
type-specific data Variable-length field, of format
determined by the Routing Type, and of
length such that the complete Routing
header is an integer multiple of 8 octets
long.
If, while processing a received packet, a node encounters a Routing
header with an unrecognized Routing Type value, the required behavior
of the node depends on the value of the Segments Left field, as
follows:
If Segments Left is zero, the node must ignore the Routing
header and proceed to process the next header in the packet,
whose type is identified by the Next Header field in the
Routing header.
If Segments Left is non-zero, the node must discard the
packet and send an ICMP Ext-hdr Parameter Problem, Code 0,
message to the packet's Source Address, pointing to the
unrecognized Routing Type.
If, after processing a Routing header of a received packet, an
intermediate node determines that the packet is to be forwarded onto
a link whose link MTU is less than the size of the packet, the node
must discard the packet and send an ICMP Packet Too Big message to
the packet's Source Address.
The currently defined IPv4 Routing Headers and their status can be
found at [IANA-RH]. Allocation guidelines for IPv4 Routing Headers
can be derived from [RFC5871].
Herbert Expires 26 August 2024 [Page 16]
Internet-Draft IPv4 EH February 2024
2.7. Fragment Header
The Fragment header is used by an IPv4 source to send a packet larger
than would fit in the path MTU to its destination. (Note: unlike
standard IPv4, fragmentation using the Fragment Header is performed
only by source nodes, not by routers along a packet's delivery path)
2.7.1. Fragment Header format
The Fragment header is identified by a Next Header value of 44 in the
immediately preceding header and has the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the initial header
type of the Fragmentable Part of the original
packet (defined below). Uses the same values
as the IPv4 Protocol field [IANA-PN].
Reserved 8-bit reserved field. Initialized to zero for
transmission; ignored on reception.
Fragment Offset 13-bit unsigned integer. The offset, in
8-octet units, of the data following this
header, relative to the start of the
Fragmentable Part of the original packet.
Res 2-bit reserved field. Initialized to zero for
transmission; ignored on reception.
M flag 1 = more fragments; 0 = last fragment.
Identification 32 bits. See description below.
2.7.2. Procedures
In order to send a packet that is too large to fit in the MTU of the
path to its destination, a source node may divide the packet into
fragments and send each fragment as a separate packet, to be
reassembled at the receiver.
For every packet that is to be fragmented, the source node generates
an Identification value. The Identification must be different than
that of any other fragmented packet sent recently* with the same
Herbert Expires 26 August 2024 [Page 17]
Internet-Draft IPv4 EH February 2024
Source Address and Destination Address. If a Routing header is
present, the Destination Address of concern is that of the final
destination.
* "recently" means within the maximum likely lifetime of a
packet, including transit time from source to destination and
time spent awaiting reassembly with other fragments of the same
packet. However, it is not required that a source node knows
the maximum packet lifetime. Rather, it is assumed that the
requirement can be met by implementing an algorithm that
results in a low identification reuse frequency. Examples of
algorithms that can meet this requirement are described in
[RFC7739].
The initial, large, unfragmented packet is referred to as the
"original packet", and it is considered to consist of three parts, as
illustrated:
original packet:
+------------------+-------------------------+---//----------------+
| Per-Fragment | Extension & Upper-Layer | Fragmentable |
| Headers | Headers | Part |
+------------------+-------------------------+---//----------------+
The Per-Fragment headers must consist of the IPv4 header plus any
extension headers that must be processed by nodes en route to the
destination, that is, all headers up to and including the Routing
header if present, else the Hop-by-Hop Options header if present,
else no extension headers.
The Extension headers are all other extension headers that are not
included in the Per-Fragment headers part of the packet. For this
purpose, the Encapsulating Security Payload (ESP) is not
considered an extension header. The Upper-Layer header is the
first upper-layer header that is not an IPv4 extension header.
Examples of upper-layer headers include TCP, UDP, IPv4, IPv6,
ICMPv4, and as noted ESP.
The Fragmentable Part consists of the rest of the packet after the
upper-layer header or after any header (i.e., initial IPv4 header
or extension header) that contains a Next Header value of No Next
Header.
Herbert Expires 26 August 2024 [Page 18]
Internet-Draft IPv4 EH February 2024
The Fragmentable Part of the original packet is divided into
fragments. The lengths of the fragments must be chosen such that the
resulting fragment packets fit within the MTU of the path to the
packet's destination(s). Each complete fragment, except possibly the
last ("rightmost") one, is an integer multiple of 8 octets long.
The fragments are transmitted in separate "fragment packets" as
illustrated:
original packet:
+-----------------+-----------------+--------+--------+-//-+--------+
| Per-Fragment |Ext & Upper-Layer| first | second | | last |
| Headers | Headers |fragment|fragment|....|fragment|
+-----------------+-----------------+--------+--------+-//-+--------+
fragment packets:
+------------------+---------+-------------------+----------+
| Per-Fragment |Fragment | Ext & Upper-Layer | first |
| Headers | Header | Headers | fragment |
+------------------+---------+-------------------+----------+
+------------------+--------+-------------------------------+
| Per-Fragment |Fragment| second |
| Headers | Header | fragment |
+------------------+--------+-------------------------------+
o
o
o
+------------------+--------+----------+
| Per-Fragment |Fragment| last |
| Headers | Header | fragment |
+------------------+--------+----------+
The first fragment packet is composed of:
(1) The Per-Fragment headers of the original packet, with the
Total Length of the original IPv4 header changed to contain
the length of this fragment packet only plus the length of
the IPv4 header itself, and the Next Header field of the last
header of the Per-Fragment headers changed to 44.
(2) A Fragment header containing:
The Next Header value that identifies the first header
after the Per-Fragment headers of the original packet.
Herbert Expires 26 August 2024 [Page 19]
Internet-Draft IPv4 EH February 2024
A Fragment Offset containing the offset of the fragment,
in 8-octet units, relative to the start of the
Fragmentable Part of the original packet. The Fragment
Offset of the first ("leftmost") fragment is 0.
An M flag value of 1 as this is the first fragment. The
Identification value generated for the original packet.
(3) Extension headers, if any, and the Upper-Layer header. These
headers must be in the first fragment. Note: This restricts
the size of the headers through the Upper-Layer header to the
MTU of the path to the packet's destinations(s).
(4) The first fragment.
The subsequent fragment packets are composed of:
(1) The Per-Fragment headers of the original packet, with the
Total Length of the original IPv4 header changed to contain
the length of this fragment packet including the length of
the IPv4 header itself, and the Next Header field of the last
header of the Per-Fragment headers changed to 44.
(2) A Fragment header containing:
The Next Header value that identifies the first header
after the Per-Fragment headers of the original packet.
A Fragment Offset containing the offset of the fragment,
in 8-octet units, relative to the start of the
Fragmentable Part of the original packet.
An M flag value of 0 if the fragment is the last
("rightmost") one, else an M flag value of 1.
The Identification value generated for the original
packet.
(3) The fragment itself.
Fragments MUST NOT be created that overlap with any other fragments
created from the original packet.
At the destination, fragment packets are reassembled into their
original, unfragmented form, as illustrated:
reassembled original packet:
Herbert Expires 26 August 2024 [Page 20]
Internet-Draft IPv4 EH February 2024
+---------------+-----------------+---------+--------+-//--+--------+
| Per-Fragment |Ext & Upper-Layer| first | second | | last |
| Headers | Headers |frag data|fragment|.....|fragment|
+---------------+-----------------+---------+--------+-//--+--------+
2.7.3. Rules for reassembly
The following rules govern reassembly:
An original packet is reassembled only from fragment packets that
have the same Source Address, Destination Address, and Fragment
Identification.
The Per-Fragment headers of the reassembled packet consist of all
headers up to, but not including, the Fragment header of the first
fragment packet (that is, the packet whose Fragment Offset is
zero), with the following two changes:
The Next Header field of the last header of the Per-Fragment
headers is obtained from the Next Header field of the first
fragment's Fragment header.
The Total Length of the reassembled packet is computed from the
payload length of the Per-Fragment headers, the payload length
and offset of the last fragment, and the length of the IP
header for the reassembled packet. For example, a formula for
computing the Total Length of the reassembled original packet
is:
TL.orig = IPHL.orig + PL.first - FL.first - 8 + (8 *
FO.last) + FL.last
where
IPHL.orig = The length of the IP header for the reassembled
packet (derived from the first fragment
packet).
TL.orig = Total Length field of reassembled packet.
PL.first = payload length of first fragment packet (Total
Length minus length of the IP header of the
first fragment packet).
FL.first = length of fragment following Fragment header of
first fragment packet.
FO.last = Fragment Offset field of Fragment header of
last fragment packet.
FL.last = length of fragment following Fragment header of
last fragment.
Herbert Expires 26 August 2024 [Page 21]
Internet-Draft IPv4 EH February 2024
The Fragmentable Part of the reassembled packet is constructed
from the fragments following the Fragment headers in each of
the fragment packets. The length of each fragment is computed
by subtracting from the packet's Total Length the length of the
headers, including the IPv4 header, that precede fragment
itself; its relative position in Fragmentable Part is computed
from its Fragment Offset value.
The Fragment header is not present in the final, reassembled
packet.
If the fragment is a whole datagram (that is, both the Fragment
Offset field and the M flag are zero), then it does not need
any further reassembly and should be processed as a fully
reassembled packet (i.e., updating Next Header, adjust Total
Length, removing the Fragment header, etc.). Any other
fragments that match this packet (i.e., the same IPv4 Source
Address, IPv4 Destination Address, and Fragment Identification)
should be processed independently.
The following error conditions may arise when reassembling fragmented
packets:
o If insufficient fragments are received to complete reassembly
of a packet within 60 seconds of the reception of the first-
arriving fragment of that packet, reassembly of that packet
MUST be abandoned and all the fragments that have been received
for that packet must be discarded. If the first fragment
(i.e., the one with a Fragment Offset of zero) has been
received, an ICMP Ext-hdr Time Exceeded -- Fragment Reassembly
Time Exceeded message MAY be sent to the source of that
fragment.
o If the length of a fragment, as derived from the fragment
packet's Payload Length field, is not a multiple of 8 octets
and the M flag of that fragment is 1, then that fragment MUST
be discarded and an ICMP Ext-hdr Parameter Problem, Code 0,
message MAY be sent to the source of the fragment, pointing to
the Payload Length field of the fragment packet.
o If the length and offset of a fragment are such that the Total
Length of the packet reassembled from that fragment would
exceed 65,535 octets, then that fragment MUST be discarded and
an ICMP Ext-hdr Parameter Problem, Code 0, message MAY be sent
to the source of the fragment, pointing to the Fragment Offset
field of the fragment packet.
o If the first fragment does not include all headers through an
Herbert Expires 26 August 2024 [Page 22]
Internet-Draft IPv4 EH February 2024
Upper-Layer header, then that fragment SHOULD be discarded and
an ICMP Ext-hdr Parameter Problem, Code 3, message MAY be sent
to the source of the fragment, with the Pointer field set to
zero.
o If any of the fragments being reassembled overlap with any
other fragments being reassembled for the same packet,
reassembly of that packet MUST be abandoned and all the
fragments that have been received for that packet MUST be
discarded, and no ICMP error messages MAY be sent.
o It should be noted that fragments may be duplicated in the
network. Instead of treating these exact duplicate fragments
as overlapping fragments, an implementation MAY choose to
detect this case and drop exact duplicate fragments while
keeping the other fragments belonging to the same packet.
The following conditions are not expected to occur frequently but are
not considered errors if they do:
The number and content of the headers preceding the Fragment
header of different fragments of the same original packet may
differ. Whatever headers are present, preceding the Fragment
header in each fragment packet, are processed when the packets
arrive, prior to queueing the fragments for reassembly. Only
those headers in the Offset zero fragment packet are retained in
the reassembled packet.
The Next Header values in the Fragment headers of different
fragments of the same original packet may differ. Only the value
from the Offset zero fragment packet is used for reassembly.
Other fields in the IPv4 header may also vary across the fragments
being reassembled. Specifications that use these fields may
provide additional instructions if the basic mechanism of using
the values from the Offset zero fragment is not sufficient. For
example, Section 5.3 of [RFC3168] describes how to combine the
Explicit Congestion Notification (ECN) bits from different
fragments to derive the ECN bits of the reassembled packet.
2.8. Destination Options Header
The Destination Options header is used to carry optional information
that need be examined only by a packet's destination node(s). The
Destination Options header is identified by a Next Header value of 60
in the immediately preceding header and has the following format:
Herbert Expires 26 August 2024 [Page 23]
Internet-Draft IPv4 EH February 2024
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the type of header
immediately following the Destination Options
header. Uses the same values as the IPv4
Protocol field [IANA-PN].
Hdr Ext Len 8-bit unsigned integer. Length of the
Destination Options header in 8-octet units,
not including the first 8 octets.
Options Variable-length field, of length such that the
complete Destination Options header is an
integer multiple of 8 octets long. Contains
one or more TLV-encoded options, as described
in Section 2.4.
The only destination options defined in this document are the Pad1
and PadN options specified in Section 2.4.
Note that there are two possible ways to encode optional destination
information in an IPv4 packet: either as an option in the Destination
Options header or as a separate extension header. The Fragment
header and the Authentication header are examples of the latter
approach. Which approach can be used depends on what action is
desired of a destination node that does not understand the optional
information:
* If the desired action is for the destination node to discard the
packet and, only if the packet's Destination Address is not a
multicast address, send an ICMP Ext-hdr Parameter Problem with
Code 2 for Unrecognized Option Type message to the packet's Source
Address, then the information may be encoded either as a separate
header or as an option in the Destination Options header whose
Option Type has the value 11 in its highest-order 2 bits. The
choice may depend on such factors as which takes fewer octets, or
which yields better alignment or more efficient parsing.
Herbert Expires 26 August 2024 [Page 24]
Internet-Draft IPv4 EH February 2024
* If any other action is desired, the information must be encoded as
an option in the Destination Options header whose Option Type has
the value 00, 01, or 10 in its highest-order 2 bits, specifying
the desired action (see Section 2.4).
2.9. No Next Header
The value 59 in the Protocol field of an IPv4 header or any extension
header indicates that there is nothing following that header. If the
Total Length field of the IPv4 header indicates the presence of
octets past the end of a header whose Next Header field contains 59,
those octets MUST be ignored and passed on unchanged if the packet is
forwarded.
2.10. Interaction with standard IPv4 mechanisms
IPv4 extension headers MAY be used concurrently with IPv4 mechanisms
such as IPv4 options and IPv4 fragmentation. This section discusses
the interactions.
2.10.1. IPv4 options and IPv4 extension headers
An IPv4 packet MAY contain both IPv4 options and extension headers.
IPv4 options are independent of IPv4 extension headers. IPv4 options
MUST be processed before processing any extension headers per normal
requirements of processing the IP header before the IP payload.
2.10.2. IPv4 fragmentation and IPv4 extension headers
An IPv4 packet MAY be fragmented both by using a Fragment extension
header as well as by standard IPv4 fragmentation. The Fragment
header can only be set at the source, however intermediate devices
can fragment packets using standard IPv4 fragmentation. Standard
IPv4 fragmentation at a source node MUST be done only after any
extension headers are set in a packet or the packet was fragmented
using the Fragment header. Specifically, fragmentation using the
extension header MUST NOT be done on packet fragments created by
standard IPv4 fragmentation. However, a packet fragment that
contains a Fragment header MAY itself be fragmented by standard IPv4
fragmentation. There is no correlation between standard IPv4
fragmentation and the IPv4 Fragment header, the fragment
identification number space for each are unrelated and reassembly
procedures are independent.
At a destination, if a received packet was fragmented by standard
IPv4 fragmentation then it MUST be reassembled before processing any
IPv4 extension headers. This requirement ensures that standard IPv4
reassembly is done before reassembly for the Fragment header.
Herbert Expires 26 August 2024 [Page 25]
Internet-Draft IPv4 EH February 2024
If an IPv4 packet containing Hop-by-Hop options is fragmented using
standard IPv4 fragmentation, the Hop-by-Hop options are not set in
each of the packet fragments. An intermediate node MAY process the
Hop-by-Hop options in the first fragment if the complete Hop-by-Hop
extension header is contained within the fragment. If the Fragment
header is used with IPv4 then the DF bit (Don't Fragment) bit SHOULD
be set and Path MTU discovery mechanisms SHOULD be used [RFC4821].
It is RECOMMENDED to only use IPv4 extensions in atomic datagrams.
Atomic datagrams [RFC6864] are IPv4 packets for which the Don't
Fragment bit set, More Fragment bit is not set, and Fragment Offset
is zero. In this case the packet will not be subject to IPv4
fragmentation, the Fragment header can alternatively be used for
fragmentation.
3. ICMPv4 messages for extension headers
This section defines two ICMPv4 types for reporting errors concerning
IPv4 extension headers: Ext-hdr Time Exceeded and Ext-hdr Parameter
Problem. The same codes related to extension header errors in ICMPv6
Time Exceeded and ICMPv6 Parameter Problem are defined for Ext-hdr
Time Exceeded and Ext-hdr Parameter Problem [RFC4443][RFC8883].
Receiver processing for these ICMP messages MUST be conformant with
the requirements for processing ICMP errors as specified in [RFC792].
3.1. Ext-hdr Time Exceeded Message
The format of an Ext-hdr Time Exceeded Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv4 packet +
| exceeding the minimum IPv4 MTU [RFC791] |
IPv4 Fields:
Destination Address Copied from the Source Address field of the
invoking packet.
ICMPv4 Fields:
Herbert Expires 26 August 2024 [Page 26]
Internet-Draft IPv4 EH February 2024
Type 44 (TBD)
Code 1 - Fragment reassembly time exceeded
Unused This field is unused for all code values. It must be
initialized to zero by the originator and ignored by the
receiver.
Description
An ICMPv4 Ext-hdr Time Exceeded message with Code 1 is used to report
fragment reassembly timeout, as specified in Section 2.7.3.
Upper Layer Notification
An incoming Time Exceeded message MUST be passed to the upper-layer
process if the relevant process can be identified.
3.2. Ext-hdr Parameter Problem Message
The format of an Ext-hdr Parameter Problem Message is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| As much of invoking packet |
+ as possible without the ICMPv4 packet +
| exceeding the minimum IPv4 MTU [RFC791] |
IPv4 Fields:
Destination Address Copied from the Source Address field of the
invoking packet.
ICMPv4 Fields:
Type 45 (TBD)
Code 0 - Erroneous header field encountered
1 - Unrecognized Next Header type encountered
2 - Unrecognized IPv4 option encountered
3 - IPv4 First Fragment has incomplete IPv4 Header Chain
5 - Unrecognized Next Header type encountered by
intermediate node
Herbert Expires 26 August 2024 [Page 27]
Internet-Draft IPv4 EH February 2024
6 - Extension header too big
7 - Extension header chain too long
8 - Too many extension headers
9 - Too many options in extension header
10 - Option too big
Pointer Identifies the octet offset within the invoking packet where
the error was detected.
The pointer will point beyond the end of the ICMPv4 packet
if the field in error is beyond what can fit in the maximum
size of an ICMPv4 error message.
Description
If an IPv4 node processing a packet finds a problem with a field in
the IPv4 extension headers such that it cannot complete processing
the packet, it MUST discard the packet and MAY originate an ICMPv4
Ext-hdr Parameter Problem message to the packet's source, indicating
the type and location of the problem.
Codes 1 through 3 and 5 through 10 are more informative than Code 0
and SHOULD be used when possible.
The pointer identifies the octet of the original packet's header
where the error was detected. For example, an ICMPv4 message with a
Type field of 45 (TBD), Code field of 1, and Pointer field of 20
would indicate that the IPv4 extension header following the typical
twenty byte IPv4 header of the original packet holds an unrecognized
Next Header field value.
Upper Layer Notification
A node receiving this ICMPv4 message MUST notify the upper-layer
process if the relevant process can be identified.
3.2.1. Erroneous header field encountered (Code 0)
An ICMPv4 Ext-hdr Parameter Problem with code for "Erroneous header
field encountered" MAY be sent when a node discards a packet because
of an issue with an extension header. This is a general error, and
SHOULD only be used if there is not a more specific and informative
code for the problem. The ICMPv4 Pointer field is set to the offset
of data in error.
Herbert Expires 26 August 2024 [Page 28]
Internet-Draft IPv4 EH February 2024
3.2.2. Unrecognized Next Header type encountered (Code 1)
An ICMPv4 Ext-hdr Parameter Problem with code for "Unrecognized Next
Header type encountered" MAY be sent when a node discards a packet
because a Next Header in an extension header is unrecognized. The
ICMPv4 Pointer field is set to the offset of the unrecognized Next
Header field in an extension header.
3.2.3. Unrecognized IPv4 option encountered (Code 2)
An ICMPv4 Ext-hdr Parameter Problem with code for "Unrecognized IPv4
option encountered" MAY be sent when a node discards a packet because
an option type is unrecognized and the higher order two bits of the
option type are not 00. The ICMPv4 Pointer field is set to the
offset of the unrecognized option type.
3.2.4. IPv4 First Fragment has incomplete IPv4 Header Chain (Code 3)
An ICMPv4 Ext-hdr Parameter Problem with code for "IPv4 First
Fragment has incomplete IPv4 Header Chain" MAY be sent when a node
discards a packet because the IPv4 header chain for a fragmented
packet is not completely contained in the first fragment. The ICMPv4
Pointer field MUST be set zero. The format for the ICMPv4 error
message is the same regardless of whether a host or intermediate
system originates it.
3.2.5. Unrecognized Next Header Type Encountered by Intermediate Node
(Code 5)
This code MAY be sent by an intermediate node that discards a packet
because it encounters a Next Header type that is unknown in its
examination. The ICMPv4 Pointer field is set to the offset of the
unrecognized Next Header value within the original packet.
Note that this code is sent by intermediate nodes and SHOULD NOT be
sent by a final destination. If a final destination node observes an
unrecognized header, then it SHOULD send an ICMP Ext-hdr Parameter
Problem message with an ICMP Code value of 1 ("unrecognized Next
Header type encountered") as specified in [RFC8200].
3.2.6. Extension Header Too Big (Code 6)
An ICMPv4 Ext-hdr Parameter Problem with code for "Extension header
too big" SHOULD be sent when a node discards a packet because the
size of an extension header exceeds its processing limit. The ICMPv4
Pointer field is set to the offset of the first octet in the
extension header that exceeds the limit.
Herbert Expires 26 August 2024 [Page 29]
Internet-Draft IPv4 EH February 2024
3.2.7. Extension Header Chain Too Long (Code 7)
An ICMPv4 Ext-hdr Parameter Problem with code for "Extension header
chain too long" SHOULD be sent when a node discards a packet with an
extension header chain that exceeds a limit on the total size in
octets of the header chain. The ICMPv4 Pointer is set to the first
octet beyond the limit.
3.2.8. Too Many Extension Headers (Code 8)
An ICMPv4 Ext-hdr Parameter Problem with code for "Too many extension
headers" SHOULD be sent when a node discards a packet with an
extension header chain that exceeds a limit on the number of
extension headers in the chain. The ICMPv4 Pointer is set to the
offset of the first octet of the first extension header that is
beyond the limit.
3.2.9. Too Many Options in Extension Header (Code 9)
An ICMPv4 Ext-hdr Parameter Problem with code for "Too many options
in extension header" SHOULD be sent when a node discards a packet
with an extension header that has a number of options that exceeds
the processing limits of the node. This code is applicable for
Destination Options and Hop-by-Hop Options. The ICMPv4 Pointer field
is set to the first octet of the first option that exceeds the limit.
3.2.10. Option Too Big (Code 10)
An ICMPv4 Ext-hdr Parameter Problem with code for "Option too big" is
sent in two different cases: when the length of an individual Hop-by-
Hop or Destination Option exceeds a limit, or when the length or
number of consecutive Hop-by-Hop or Destination padding options
exceeds a limit. In a case where the length of an option exceeds a
processing limit, the ICMPv4 Pointer field is set to the offset of
the first octet of the option that exceeds the limit. In cases where
the length or number of padding options exceeds a limit, the ICMPv4
Pointer field is set to the offset of the first octet of the padding
option that exceeds the limit.
Possible limits related to padding include
[RFC8504][I-D.ietf-6man-eh-limits]:
* The number of consecutive PAD1 options in Destination Options or
Hop-by-Hop Options is limited to seven octets.
* The length of PADN options in Destination Options or Hop-by-Hop
Options is limited to seven octets.
Herbert Expires 26 August 2024 [Page 30]
Internet-Draft IPv4 EH February 2024
* The aggregate length of a set of consecutive PAD1 or PADN options
in Destination Options or Hop-by-Hop Options is limited to seven
octets.
4. Inflight Removal of IPv4 Hop-by-Hop and Routing Headers
Under certain circumstances the IPv4 Hop-by-Hop Options and Routing
Headers MAY be removed from a packet while it's in-flight. The
motivations for dropping Hop-by-Hop Options and Routing Headers are
outlined in [I-D.herbert-eh-inflight-removal].
This section describes the procedures and requirements for removing a
Hop-by-Hop Options header, removing a Routing header, and removing a
Hop-by-Hop Options and a Routing header at the same time. The
requirements and procedures are derived from those in
[I-D.herbert-eh-inflight-removal].
4.1. Requirements
An router MAY remove a Hop-by-Hop Options header from a packet if the
following conditions are met:
* The packet does not contain an Authentication header. If the
packet contains and Authentication header then the Hop-by-Hop
Options header MUST NOT be removed
* The Total Length of the packet is greater then the IP header
lengths Hop-by-Hop options does not include a Jumbo Payload Option
[RFC2675] (assuming the Jumbo Payload option is allowed for use
with IPv4). If the packet contains a Jumbo Payload option then
the Total Length should be equal to the length of the IP header.
A router MAY remove a Routing header extension header from a packet
if the following conditions are met:
* The Destination Address has been set to the address of the final
destination and the Segments Left field is zero
* The packet does not contain an Authentication header
* There are no extension headers the precede the Routing header in
the packet. An exception is if the Routing header immediately
follow a Hop-by-Hop Options header that is also being removed
* The final destination is not required to process or validate the
Routing header
* The Routing header does not contain options (segment routing TLVs
Herbert Expires 26 August 2024 [Page 31]
Internet-Draft IPv4 EH February 2024
for instance), or the destination host doesn't need to process or
validate the options.
4.2. Procedures
4.2.1. Removing a Hop-by-Hop Options Header
The procedures for removing a Hop-by-Hop Options header are:
1. Save the value in the Next Header field of the Hop-by-Hop Options
header in a temporary variable
2. Determine the length of the Hop-by-Hop header and save in a
temporary variable. This is equal to the value of the Hdr Ext
Len field times eight plus eight
3. Determine the offset of the first byte following the Hop-by-Hop
Options header. This is equal to the length of the IP header
plus the length of the Hop-by-Hop Options header derived in step
2
4. Copy the IPv4 header with its derived length to the offset
derived in step 3 minus the length of the IPv4 header. Reset the
starting offset of the packet to be the offset of the copied IPv4
header
5. Set the Protocol field in the copied IPv4 header to the value
saved in step 1
6. Subtract the length of the Hop-by-Hop Options header, determined
in step 2, from the Total Length in the copied IPv4 header. Set
the result as the Total Length in the copied IPv4 header
An example of removing Hop-by-Hop Options header is shown in the
diagrams below.
The diagram below illustrates shows an example TCP/IPv4 packet with a
Hop-by-Hop Options header; the Total Length is 1220 bytes and the
length of the Hop-by-Hop Options header is sixty-four bytes.
Herbert Expires 26 August 2024 [Page 32]
Internet-Draft IPv4 EH February 2024
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
| 0x4 |IHL=5 |Type of Service| Total Length = 1220 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
| Identification |Flags| Fragment Offset | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| Time to Live | Protocol = 0 | Header Checksum | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source IPv4 Address | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
| Destination IPv4 Address | r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
| Next Hdr = 6 | EH Len = 7 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. TCP packet and payload .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The diagram below illustrates the packet after the Hop-by-Hop Options
header has been removed. Note that the Total Length is now 1,156
bytes which is the original total length minus the length of the Hop-
by-Hop Options header that was removed.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
| 0x4 |IHL=5 |Type of Service| Total Length = 1156 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
| Identification |Flags| Fragment Offset | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| Time to Live | Protocol = 6 | Header Checksum | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source IPv4 Address | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
| Destination IPv4 Address | r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
| |
. .
. TCP packet and payload .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Herbert Expires 26 August 2024 [Page 33]
Internet-Draft IPv4 EH February 2024
4.2.2. Removing a Routing Header
As discussed in [I-D.herbert-eh-inflight-removal] a Routing Header
MAY be removed from a packet by a router when Segments Left is equal
to zero.
The procedures for removing a Routing header are:
1. Save the value in the Next Header field of the Routing header in
a temporary variable
2. Determine the length of the Routing header and save in a
temporary variable. This is equal to the value of the Hdr Ext
Len field times eight plus eight
3. Determine the offset of the first byte following the Routing
header. This is equal to length of the IP header plus the length
of the Routing header derived in step 2
4. Copy the IPv4 header with its derived length to the offset
derived in step 3 minus the length of the IPv4 header. Reset the
starting offset of the packet to be the offset of the copied IPv4
header
5. Set the Protocol field in the copied IPv4 header to the value
saved in step 1
6. Subtract the length of the Routing header, determined in step 2,
from the Total Length in the copied IPv4 header. Set the result
as the Total Length in the copied IPv4 header
An example of removing a Routing header is shown in the diagrams
below.
The diagram below illustrates shows an example TCP/IPv4 packet with a
Routing header; the Total Length is 1,420 bytes and the length of the
Routing header is 160 bytes. The Segments Left field is set to zero
so that the Routing header may be removed.
Herbert Expires 26 August 2024 [Page 34]
Internet-Draft IPv4 EH February 2024
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
| 0x4 |IHL=5 |Type of Service| Total Length = 1420 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
| Identification |Flags| Fragment Offset | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| Time to Live | Protocol = 43 | Header Checksum | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source IPv4 Address | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
| Destination IPv4 Address | r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
| Next Hdr = 17| EH Len = 19 | Routing Type | Segs Left = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. UDP packet and payload .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The diagram below illustrates the packet after the Routing header has
been removed. Note that the Payload Length is now 1,260 bytes which
is the original total length minus the length of the Routing header
that was removed.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
| 0x4 |IHL=5 |Type of Service| Total Length = 1260 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
| Identification |Flags| Fragment Offset | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| Time to Live | Protocol = 17 | Header Checksum | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source IPv4 Address | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
| Destination IPv4 Address | r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
| |
. .
. UDP packet and payload .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Herbert Expires 26 August 2024 [Page 35]
Internet-Draft IPv4 EH February 2024
4.2.3. Removing both a Hop-by-Hop Options and a Routing header
As discussed in [I-D.herbert-eh-inflight-removal] both Routing Header
and Hop-by-Hop Options MAY be removed from a packet by a ingress or
egress router when Segments Left is equal to zero and there are no
extension headers between the Hop-by-Hop Options header and the
Routing header.
The procedures for removing both a Hop-by-Hop Options and a Routing
header are:
1. Save the value in the Next Header field of the Routing header
extension header in a temporary variable
2. Determine the length of the Hop-by-Hop Options header and save in
a temporary variable. This is equal to the value of the Hdr Ext
Len field times eight plus eight
3. Determine the length of the Routing header and save in a
temporary variable. This is equal to the value of the Hdr Ext
Len field times eight plus eight
4. Determine the offset of the first byte in the packet following
the Routing header. This is equal to the length of the IP header
plus the length of the Hop-by-Hop Options header derived in step
2 plus the length of the Routing header derived in step 3
5. Copy the IPv4 header with its derived length to the offset
derived in step 3 minus the length of the IPv4 header. Reset the
starting offset of the packet to be the offset of the copied IPv4
header
6. Set the Protocol field in the copied IPv4 header to the value
saved in step 1
7. Subtract the length of the Hop-by-Hop Options header plus the
length of the Routing header (values determined in step 2 and
step 3) from the Total Length in the copied IPv4 header. Set the
result as the Total Length in the copied IPv4 header
An example of removing a Hop-by-Hop Options header a Routing header
is shown in the diagrams below.
The diagram below illustrates an example TCP/IPv4 packet with both a
Hop-by-Hop Options and a Routing header; the Total Length is 1,320
bytes, the length of the Hop-by-Hop Options header is sixty-four
bytes, the length of the Routing header is 160 bytes. The Segments
Left field is set to zero so that the Routing header may be removed.
Herbert Expires 26 August 2024 [Page 36]
Internet-Draft IPv4 EH February 2024
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
| 0x4 |IHL=5 |Type of Service| Total Length = 1320 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
| Identification |Flags| Fragment Offset | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| Time to Live | Protocol = 0 | Header Checksum | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source IPv4 Address | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
| Destination IPv4 Address | r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
| Next Hdr = 43 | EH Len = 7 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hdr = 6 | EH Len = 19 | Routing Type | Segs Left = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. TCP packet and payload .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The diagram below illustrates the packet after the Hop-by-Hop Options
header and the Routing header have been removed. Note that the
Payload Length is now 1,096 bytes which is the original total length
minus the length of the Hop-by-Hop Options header and the Routing
header that were removed.
Herbert Expires 26 August 2024 [Page 37]
Internet-Draft IPv4 EH February 2024
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
| 0x4 |IHL=5 |Type of Service| Total Length = 1096 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
| Identification |Flags| Fragment Offset | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| Time to Live | Protocol = 6 | Header Checksum | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source IPv4 Address | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
| Destination IPv4 Address | r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
| |
. .
. TCP packet and payload .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. The IPv4 flow label
The Identification field of the IPv4 header is re-purposed to be the
IPv4 flow label in atomic datagrams. As stated in [RFC6864]:
">> Originating sources MAY set the IPv4 ID field of atomic
datagrams to any value."
That requirement allows the Identification field to be used as a flow
label in atomic datagrams, however it also allows that legacy
implementations might set the Identification field to arbitrary
values. A receiver should take this into account when considering
interpreting the Identification field as a flow label (some guidance
is provided below).
This specification allows the IPv4 ID to be used as a flow label in
atomic datagrams.
5.1. Sender Requirements
An origin host MAY set the IPv4 Identification field as a flow label
in atomic datagram packets. The IPv4 flow label is set following the
same procedures for setting the IPv6 flow label as described in
[RFC6437] with the following modifications:
* The Identification field MUST only be used as a flow label in
atomic datagrams. That is Don't Fragment (DF) bit MUST be set,
More Fragment (MF) bit MUST NOT be set, and Fragment Offset MUST
be zero.
Herbert Expires 26 August 2024 [Page 38]
Internet-Draft IPv4 EH February 2024
* If the IPv4 Identification field is not used as a flow label in
atomic fragments, the Identification field SHOULD be set to zero.
* Only stateless flow labels can be set.
* The value to set, e.g. from a hash computation over packet
headers, is truncated to sixteen bits (the size of the Fragment
Identification field).
* Intermediate nodes MUST NOT set the Fragment Identification field
in atomic datagrams.
* If a an IPv4 extension header, other than ESP or AH, is present in
an atomic datagram then the Identification field MUST either be
set as a flow label or set to a value of zero. In the case of ESP
or AH, an implementation SHOULD set the Identification field to a
flow label or set to a value of zero (the exception to this is
legacy implementations that may be setting the Identification
field to some arbitrary value).
5.2. Receiver Requirements
Receivers, including routers and hosts, MAY process a non-zero
Identification field in the IPv4 header of atomic datagrams as being
a flow label. The IPv4 flow label for instance can be used as input
to ECMP as described in [RFC6438].
If the Identification field is zero or the packet is not an atomic
datagram (either the More Fragment bit is set, the Don't Fragment bit
is not set, or Fragment Offset is non-zero) then the Identification
field MUST NOT be considered as a flow label.
If a receiver receives and atomic datagram containing an IPv4
extension header other than ESP or AH, then the receiver can assume
that a non-zero Identification field is a valid flow label. The
Identification field can safely be used as input to the ECMP hash and
the router would not need to parse into the transport layer to
extract port information as input to the hash computation.
If a receiver receives an atomic datagram containing an ESP or AH
header and no other IPv4 extension headers, then the receiver may
assume that a non-zero Identification field is a valid flow label.
The Identification field may be used as input to the ECMP hash,
however if a router parses the ESP is or AH to extract flow entropy
then that information should be used as input to the flow hash
calculation instead of the value in the Identification field.
Herbert Expires 26 August 2024 [Page 39]
Internet-Draft IPv4 EH February 2024
If a receiver receives an atomic datagram then a non-zero
Identification may be used as a flow label. The value in the
Identification field should only be considered for use as input to
the ECMP hash computation if there is not other means to extract flow
entropy in the packet. In particular, if a router receives a TCP,
UDP, DCCP packet where the upper layer protocol immediately follows
the IP header, then the router should extract the transport layer
port numbers as input to the ECMP hash calculation and can ignore the
value in the Identification field.
6. Deployability Considerations
If a legacy host device receives an IPv4 packet with IPv4 extension
headers, the packet will be treated as having an unknown protocol and
should be dropped. Intermediate devices might also see packets with
a protocol unknown to them and will forward the packet inasmuch as
they would forward any packet with an unknown protocol.
In the Internet, it is well known that there are some intermediate
nodes that will drop packets with protocols that are unknown to them
(firewalls would commonly do this for instance). Therefore, it is
unlikely that packets with IPv4 extension headers can be ubiquitously
deployed over the Internet.
In a limited domain [RFC8799], an operator would have control over
intermediate nodes and could ensure that at a minimum they properly
forward packets with IPv4 extension headers. Routers in a limited
domain can be updated to process IPv4 Hop-by-Hop Options or Routing
headers to provide the functionality of features like IOAM and
Segment Routing in IPv4. Similarly, they could be updated to support
the IPv4 flow label to provide flow based ECMP in the same manner
that the IPv6 flow label is used for ECMP [RFC6438].
7. Security Considerations
This specification enables use of IPv6 extension headers in IPv4.
Related security mechanisms of IPv6 extension headers can be applied
for use with IPv4 extension headers.
The IPv4 flow label has similar security properties as the IPv6 flow
label.
8. IANA Considerations
Herbert Expires 26 August 2024 [Page 40]
Internet-Draft IPv4 EH February 2024
8.1. IPv4 Extension Header types
In the "Internet Protocol Version 4 (IPv4) Parameters", registry IANA
is requested to create the "IPv4 Extension Headers Types" sub-
registry. The initial entries are for the core extension header
types defined in [RFC8200].
+----------+--------------------------+----------------------------+
| Protocol | Description | Reference |
| number | | |
+----------+--------------------------+----------------------------+
| 0 | IPv4 Hop-by-Hop Options | [This document] |
+----------+--------------------------+----------------------------+
| 43 | Routing Header for IPv4 | [This document] |
+----------+--------------------------+----------------------------+
| 44 | Fragment Header for IPv4 | [This document] |
+----------+--------------------------+----------------------------+
| 50 | Encapsulating Security | [RFC4303] |
+----------+--------------------------+----------------------------+
| 51 | Authentication Header | [RFC4302] |
+----------+--------------------------+----------------------------+
| 60 | Destination Options for | [This document] |
+----------+--------------------------+----------------------------+
8.2. Destination Options and Hop-by-Hop Options
In the "Internet Protocol Version 4 (IPv4) Parameters" registry, IANA
is requested to create the "Destination Options and Hop-by-Hop
Options" sub-registry. The initial entries consist of Pad1 and PadN
options.
------------+------------------+----------------+------------------+
| Hex value | Binary value | Description | Reference |
| | act | chg | rest | | |
+-----------+-----+-----+------+----------------+------------------+
| 0x00 | 00 | 0 | 0000 | Pad1 | [This document] |
+-----------+-----+-----+------+----------------+------------------+
| 0x01 | 00 | 0 | 0000 | PadN | [This document] |
+-----------+-----+-----+------+----------------+------------------+
8.3. ICMP Parameters
IANA is requested to assign the following two ICMPv4 types in the
"Internet Control Message Protocol (ICMP) Parameters" registry.
Herbert Expires 26 August 2024 [Page 41]
Internet-Draft IPv4 EH February 2024
------------+-----------------------------------+------------------+
| Type | Description | Reference |
+-----------+-----------------------------------+------------------+
| 44 (TBD) | Ext-hdr Time Exceeded | [This document] |
+-----------+-----+-----+------+----------------+------------------+
| 45 (TBD) | Ext-hdr Parameter Problem | [This document] |
+-----------+-----------------------------------+------------------+
8.3.1. Ext-hdr Time Exceeded
IANA is requested to assign the following code to the "Ext-hdr Time
Exceeded" type. Note that the specific number assignment
intentionally corresponds to the equivalent code in ICMPv6 Time
Exceeded type.
+-----------+-----------------------------------+------------------+
| Code | Description | Reference |
+-----------+-----------------------------------+------------------+
| 1 | fragment reassembly time exceeded | [This document] |
+-----------+-----------------------------------+------------------+
8.3.2. Ext-hdr Parameter Problem
IANA is requested to assign the following codes to the "Ext-hdr
Parameter Problem" type. Note that the specific number assignments
intentionally correspond to equivalent codes in ICMPv6 Time Exceeded
type.
Herbert Expires 26 August 2024 [Page 42]
Internet-Draft IPv4 EH February 2024
------------+-----------------------------------+------------------+
| Code | Description | Reference |
+-----------+-----------------------------------+------------------+
| 0 | Erroneous header field | [This document] |
| | encountered | |
+-----------+-----+-----+------+----------------+------------------+
| 1 | Unrecognized Next Header type | [This document] |
| | encountered | |
+-----------+-----------------------------------+------------------+
| 2 | unrecognized IPv4 option | [This document] |
| | encountered | |
+-----------+-----------------------------------+------------------+
| 3 | IPv4 First Fragment has | [This document] |
| | incomplete IPv4 Header Chain | |
+-----------+-----------------------------------+------------------+
| 5 | Unrecognized Next Header type | [This document] |
| | encountered | |
+-----------+-----------------------------------+------------------+
| 6 | Extension header too big | [This document] |
+-----------+-----------------------------------+------------------+
| 7 | Extension header chain too long | [This document] |
+-----------+-----------------------------------+------------------+
| 8 | Too many extension headers | [This document] |
+-----------+-----------------------------------+------------------+
| 9 | Too many options in extension | [This document] |
| | header | |
+-----------+-----------------------------------+------------------+
| 10 | Option too big | [This document] |
+-----------+-----------------------------------+------------------+
9. References
9.1. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
9.2. Informative References
Herbert Expires 26 August 2024 [Page 43]
Internet-Draft IPv4 EH February 2024
[I-D.herbert-eh-inflight-removal]
Herbert, T., "Infight Removal of IPv6 Hop-by-Hop and
Routing Headers", Work in Progress, Internet-Draft, draft-
herbert-eh-inflight-removal-03, 20 December 2023,
<https://datatracker.ietf.org/doc/html/draft-herbert-eh-
inflight-removal-03>.
[I-D.herbert-fast]
Herbert, T., "Firewall and Service Tickets", Work in
Progress, Internet-Draft, draft-herbert-fast-07, 7 October
2023, <https://datatracker.ietf.org/doc/html/draft-
herbert-fast-07>.
[I-D.ietf-6man-comp-rtg-hdr]
Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L.
Jalil, "The IPv6 Compact Routing Header (CRH)", Work in
Progress, Internet-Draft, draft-ietf-6man-comp-rtg-hdr-03,
18 January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-6man-comp-rtg-hdr-03>.
[I-D.ietf-6man-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6
Extension Headers", Work in Progress, Internet-Draft,
draft-ietf-6man-eh-limits-12, 18 December 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-12>.
[I-D.ietf-6man-hbh-processing]
Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
Processing Procedures", Work in Progress, Internet-Draft,
draft-ietf-6man-hbh-processing-13, 18 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-13>.
[I-D.ietf-v6ops-hbh]
Peng, S., Li, Z., Xie, C., Qin, Z., and G. S. Mishra,
"Operational Issues with Processing of the Hop-by-Hop
Options Header", Work in Progress, Internet-Draft, draft-
ietf-v6ops-hbh-10, 16 February 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
hbh-10>.
Herbert Expires 26 August 2024 [Page 44]
Internet-Draft IPv4 EH February 2024
[I-D.li-6man-app-aware-ipv6-network]
Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu,
P., Liu, C., and K. Ebisawa, "Application-aware IPv6
Networking (APN6) Encapsulation", Work in Progress,
Internet-Draft, draft-li-6man-app-aware-ipv6-network-03,
22 February 2021, <https://datatracker.ietf.org/doc/html/
draft-li-6man-app-aware-ipv6-network-03>.
[IANA-EH] "IPv6 Extension Header Types",
<https://www.iana.org/assignments/ipv6-parameters>.
[IANA-PN] "Assigned Internet Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers/
protocol-numbers.xhtml>.
[IANA-RH] "IPv6 Extension Header Types",
<https://www.iana.org/assignments/ipv6-parameters>.
[IPNOOP] Fonseca, R., Manning Porter, G., Katz, R., Shenker, S.,
and I. Ion Stoica, "IP Options are not an option",
December 2005,
<https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-
2005-24.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, DOI 10.17487/RFC2675, August 1999,
<https://www.rfc-editor.org/info/rfc2675>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
Herbert Expires 26 August 2024 [Page 45]
Internet-Draft IPv4 EH February 2024
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<https://www.rfc-editor.org/info/rfc4821>.
[RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871,
May 2010, <https://www.rfc-editor.org/info/rfc5871>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<https://www.rfc-editor.org/info/rfc6438>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013,
<https://www.rfc-editor.org/info/rfc6864>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,
"Observations on the Dropping of Packets with IPv6
Extension Headers in the Real World", RFC 7872,
DOI 10.17487/RFC7872, June 2016,
<https://www.rfc-editor.org/info/rfc7872>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
Herbert Expires 26 August 2024 [Page 46]
Internet-Draft IPv4 EH February 2024
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to
Processing Limits", RFC 8883, DOI 10.17487/RFC8883,
September 2020, <https://www.rfc-editor.org/info/rfc8883>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile",
BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
<https://www.rfc-editor.org/info/rfc8900>.
[RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
G., and W. Liu, "Operational Implications of IPv6 Packets
with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
September 2021, <https://www.rfc-editor.org/info/rfc9098>.
[RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
2022, <https://www.rfc-editor.org/info/rfc9268>.
[RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
In Situ Operations, Administration, and Maintenance
(IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,
<https://www.rfc-editor.org/info/rfc9486>.
[V6STATE] Kuerbis, B. and M. Mueller, "The Hidden Standards War:
Economic Factors Affecting IPv6 Deployment", December
2020,
<https://www.emerald.com/insight/content/doi/10.1108/DPRG-
10-2019-0085/full/html>.
Author's Address
Tom Herbert
SiPanda
Santa Clara, CA,
United States of America
Email: tom@herbertland.com
Herbert Expires 26 August 2024 [Page 47]
