IPv4 Extension Headers and Flow Label
draft-herbert-ipv4-eh-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Tom Herbert | ||
| Last updated | 2023-12-15 (Latest revision 2019-05-02) | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-herbert-ipv4-eh-02
Network Working Group T. Herbert
Internet-Draft SiPanda
Intended status: Standards Track 16 December 2023
Expires: 18 June 2024
IPv4 Extension Headers and Flow Label
draft-herbert-ipv4-eh-02
Abstract
This specification defines extension headers for IPv4 and a
definition of 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 18 June 2024.
Copyright Notice
Copyright (c) 2023 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 18 June 2024 [Page 1]
Internet-Draft IPv4 EH December 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. IPv4 extension headers . . . . . . . . . . . . . . . 4
1.1.2. IPv4 flow labels . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. IPv4 extension headers . . . . . . . . . . . . . . . . . . . 5
2.1. General Requirements . . . . . . . . . . . . . . . . . . 6
2.2. Extension Header Order . . . . . . . . . . . . . . . . . 7
2.3. Extension Header Options . . . . . . . . . . . . . . . . 7
2.4. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 8
2.5. Destination Options Header . . . . . . . . . . . . . . . 8
2.6. Routing Header . . . . . . . . . . . . . . . . . . . . . 9
2.7. Fragment Header . . . . . . . . . . . . . . . . . . . . . 9
2.8. Interaction with standard IPv4 mechanisms . . . . . . . . 10
2.8.1. IPv4 options and IPv4 extension headers . . . . . . . 10
2.8.2. IPv4 fragmentation and IPv4 extension headers . . . . 10
2.9. Extension Header Limits . . . . . . . . . . . . . . . . . 11
3. ICMPv4 Errors for Extension Headers . . . . . . . . . . . . . 12
3.1. Parameter Problem Codes . . . . . . . . . . . . . . . . . 12
3.2. Destination Unreachable codes . . . . . . . . . . . . . . 14
4. No Next Header . . . . . . . . . . . . . . . . . . . . . . . 15
5. The IPv4 flow label . . . . . . . . . . . . . . . . . . . . . 15
5.1. Sender Requirements . . . . . . . . . . . . . . . . . . . 15
5.2. Receiver Requirements . . . . . . . . . . . . . . . . . . 16
6. Deployability Considerations . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8.1. IPv4 Extension Header types . . . . . . . . . . . . . . . 17
8.2. Destination Options and Hop-by-Hop Options . . . . . . . 18
9. ICMP Parameters . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Parameter Problem codes . . . . . . . . . . . . . . . . . 18
9.2. Destination Unreachable codes . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
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
cognates of corresponding ICMPv6 messages [RFC8883].
Herbert Expires 18 June 2024 [Page 2]
Internet-Draft IPv4 EH December 2023
The 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.
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 may safely be used as a
flow label.
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:
1. Users benefit from forward looking features being actively
defined and developed for IPv6 without requiring them to
immediately transition to IPv6.
2. 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.
Herbert Expires 18 June 2024 [Page 3]
Internet-Draft IPv4 EH December 2023
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.bonica-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 mechanism of extension headers defined for IPv6. All
of these proposals, in some form, could be of value for use with
IPv4, however IPv4 does not have 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.
The document enables IPv4 packets to carry extension headers in the
same manner that IPv6 packets can 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 Fragment Header, IOAM and Path MTU 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 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, in the case of segment routing, the 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].
Herbert Expires 18 June 2024 [Page 4]
Internet-Draft IPv4 EH December 2023
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]. There is ongoing work to address the
deployability of IPv4 extension headers [I-D.ietf-6man-eh-limits]
[I-D.ietf-6man-hbh-processing].
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, Destination Options,
Authentication, 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 to visit could be adapted to carry
IPv4 addresses.
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
IPv4 extension headers are optional internet-layer information
encoded in separate headers that may be placed between the IPv4
header and the upper-layer header in a packet. IPv4 extension
headers are based on IPv6 extension headers and share the same basic
properties and semantics [RFC8200].
Extension headers are numbered from IANA IP Protocol Numbers
[IANA-PN], the same values SHOULD be used for IPv4 and IPv6. When
processing a sequence of Next Header values in an IPv4 packet, the
Herbert Expires 18 June 2024 [Page 5]
Internet-Draft IPv4 EH December 2023
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 (protocol number 59 [RFC8200]).
As illustrated in the examples below, an IPv4 packet MAY carry zero,
one, or more extension headers, each identified by Protocol field of
the IPv4 header or the Next Header field of a preceding extension
header:
+---------------+------------------------
| IPv4 header | TCP header + data
| |
| Protocol = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv4 header | Hop-by-Hop | TCP header + data
| | |
| Protocol = | Next Header = |
| Hop-by-Hop | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+-----------------
| IPv4 header | Hop-by-Hop | Fragment header | fragment of TCP
| | | | header + data
| Protocol = | Next Header = | Next Header = |
| Hop-by-Hop | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
2.1. General Requirements
IPv4 extension headers normatively assume the requirements of 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 18 June 2024 [Page 6]
Internet-Draft IPv4 EH December 2023
* 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.
* If a legacy IPv4 destination node, 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 (i.e. IPv4 Total Length minus the length of the IPv4
header).
2.2. Extension Header Order
IPv4 extension headers have the same RECOMMENDED ordering as that for
IPv6 Section 4.1 of [RFC8200].
IPv4 header
Hop-by-Hop Options header
Destination Options header (before Routing header)
Routing header
Fragment header
Authentication header
Encapsulating Security Payload header
Destination Options header (after Routing header)
Upper-Layer header
2.3. Extension Header Options
The Hop-by-Hop Options header and the Destination Options header
carry a variable number of "options" that are type-length-value
(TLV). IPv4 Hop-by-Hop and Destination options use the same encoding
and have the same requirements as IPv6 Options described in
Section 4.2 of [RFC8200]. Note that Pad1 and PadN are defined by
this document as IPv4 padding options with same types numbers as
those in IPv6.
Herbert Expires 18 June 2024 [Page 7]
Internet-Draft IPv4 EH December 2023
2.4. Hop-by-Hop Options Header
The format and semantics of IPv4 Hop-by-Hop Options are the same as
those defined for IPv6 in Section 4.3 of [RFC8200].
IPv4 variants of Ipv6 Hop-by-Hop Options can be defined with the
appropriate modifications to work with IPv6. As an example, consider
the Path MTU Option [RFC9268]. The Path MTU option is mostly
independent of IPv6 as the concept of MTU is independent of the IP
protocol version and the contents and processing of the option are
agnostic to the protocol as well. Perhaps the only material
difference between a Path MTU option for IPv4 and IPv6 is that
smaller MTU values can be reported in the IPv4 variant (the minimum
MTU in IPv6 is 1280 bytes, and in IPv6 the minimum MTU is 576 bytes).
Enabling the Path MTU option for use in IPv4 should be
straightforward.
Other than Pad1 and PadN, this specification does not specify any
IPv4 Hop-by-Hop options.
2.5. Destination Options Header
The format and semantics of IPv4 Destination Options are the same as
those defined for IPv6 in Section 4.6 of [RFC8200].
IPv4 variants of IPv6 Destinations Options can be defined with the
appropriate modifications to work with IPv6. As an example, consider
the Jumbo Payload option [RFC2675]. The Jumbo Payload option is
mostly independent of IPv6. The requirements for the option can be
adapted from those in Section 3 of [RFC2675] where instead of the
IPv6 Payload Length being zero, the IPv4 Total Length is set to the
length of the IPv4 header. The value in the Jumbo Payload Option
would be the length of the payload following the IPv4 header so that
the total length of the packet is the value in the IPv4 Total Length
(the length of the IPv4 header) plus the value in the Jumbo Payload
option. If the Jumbo Payload option processing results in an ICMP
error then an appropriate ICMPv4 message is sent (these ICMP messages
would have the corresponding types and codes as specified in
[RFC2675]).
Other than Pad1 and PadN, this specification does not specify any
IPv4 Destination options.
Herbert Expires 18 June 2024 [Page 8]
Internet-Draft IPv4 EH December 2023
2.6. Routing Header
Various types of Routing header types should be adaptable for use
with IPv4 by defining carrying IPv4 addresses in the route list
instead of IPv6 addresses. This specification does not define any
Routing Header types that work with IPv4.
2.7. Fragment Header
The format and semantics of the IPv4 Fragment Header are the same as
those in Section 4.5 of [RFC8200]. An advantage of using the IPv4
Fragment Header over standard IPv4 fragmentation is the
Identification fields is thirty-two bits instead of sixteens bits;
this addresses some know issues with the small sixteen bit
identification field in IPv4 [RFC8900].
Fragmentation and reassembly using the IPv4 Fragment Header follow
the procedures in Section 4.5 of [RFC8200] with the following
adaptations for use with IPv4.
* Similar to IPv4, fragmentation using IPv4 Fragment Header is only
performed by the source node.
* References to setting the Payload Length field in the IPv6 header
are interpreted to be setting the Total Length in the IPv4 header
taking into account the IPv4 header length.
* When creating or modifying IPv4 extension headers in packets, the
IPv4 header checksum MUST be set correctly.
* Different fragment packets MAY contain different IPv4 options. In
the reassembled packet, the IPv4 options are taken from the first
fragment packet (the one with fragment offset of zero).
* Different fragment packets MAY contain different extension headers
preceding the fragment header. In the reassembled packet, the
extension headers preceding the fragment header are taken from the
first fragment packet (the one with fragment offset zero).
* If reassembly results in an ICMP error message being sent, an
ICMPv4 message is sent [RFC792] with the corresponding codes and
type as those sent for IPv6 [RFC8200].
* If the first fragment does not include all headers through an
Upper-Layer header, then that fragment should be discarded and an
ICMP Parameter Problem for IPv4, Code 3, message should be sent to
the source of the fragment, with the Pointer field set to zero.
Herbert Expires 18 June 2024 [Page 9]
Internet-Draft IPv4 EH December 2023
* An original packet is reassembled only from fragment packets that
have the same IPv4 Source Address, IPv4 Destination Address, and
Fragment Identification.
2.8. 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.8.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.8.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.
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].
Herbert Expires 18 June 2024 [Page 10]
Internet-Draft IPv4 EH December 2023
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.
2.9. Extension Header Limits
[I-D.ietf-6man-eh-limits] describes the use of limits in processing
IPv6 extension headers in order to protect nodes from excessive
extension header options. These limits are adapted for applicability
with IPv4 extension headers.
Limits on IPv4 extension headers fall into the following categories:
* Limits on extension header length
* Limits on option length
* Limits on number of extension headers
* Limits on number of options
* Limits on padding for extension headers with options
* Limits on the length of the IPv4 header chain
With the exception of the limit on the length of the IPV4 header
chain, the requirements in each of these categories are the same as
those defined for IPv6 extension headers in [I-D.ietf-6man-eh-limits]
since these limits are independent of the IPv6 protocol. When a
limit is exceeded at a receiving node and the requirements specify
that an ICMP message may be sent, and ICMPv4 message is used with the
type as code Section 3 specified for the associated limit in
[I-D.ietf-6man-eh-limits].
The "IPv4 header chain" consists of the IPv4 header and the set of
following IPv4 Extension Headers that precede the upper layer in a
packet. The limits and requirements for the length of the IPv6
header chain in [I-D.ietf-6man-eh-limits] are adapted for IPv4
Extension Headers as:
* A sending source host SHOULD NOT send a packet with an IPv4 header
chain larger than 104 bytes unless it has explicit knowledge that
all possible routers, intermediate nodes, and the destination host
in the path are able to process a larger IPv4 header chain. If a
packet contains an IPsec header then this limit only applies
Herbert Expires 18 June 2024 [Page 11]
Internet-Draft IPv4 EH December 2023
through the end of the IPsec header (the IPsec header obfuscates
following headers so that they are unreadable by nodes in the
path).
* A receiving host or intermediate node MAY set a limit on the
maximum length of the IPv4 header chain. If the limit is set then
it SHOULD be greater than or equal to 104 bytes. If a packet is
received and the aggregate length of the IPv4 header chain exceeds
the limit, then the receiving node SHOULD discard the packet and
MAY send an ICMP Parameter Problem message with code 7 (Extension
Header Chain Too Long) to the packet's source address.
* If a router needs to parse the transport layer, for instance to
deduce the transport layer port numbers, it MUST be able to
correctly forward packets that contain an IPv6 header chain of 104
or fewer bytes.
3. ICMPv4 Errors for Extension Headers
ICMP errors are defined to be sent in response to errors that occur
in processing IPv4 extension headers. Six ICMPv4 Parameter Problem
codes are defined and one Destination Unreachable code is defined.
These codes are adaptations of ICMPv6 codes defined in [RFC4443] and
[RFC8883].
3.1. Parameter Problem Codes
The format for ICMP Parameter Problem errors related to extension
header employs a multi-part ICMPv4 message format as defined in
[RFC4884]. The extended structure contains a pointer to the octet
beyond the limit.
The format of the ICMPv4 Parameter Problem for extension headers 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 | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Herbert Expires 18 June 2024 [Page 12]
Internet-Draft IPv4 EH December 2023
IPv4 Fields:
* Destination Address: Copied from the Source Address field of the
invoking packet.
ICMPv4 Fields:
* Type
* 12 (Parameter Problem Message)
* Code (pertinent to this specification)
3 - Erroneous header field encountered
4 - Unrecognized Next Header type encountered
5 - Unrecognized IPv4 option encountered
6 - Extension header too big
7 - Extension header chain too long
8 - Too many options in extension header
* Length
Length of the padded "original datagram" field, measured in
32-bit word
* Pointer
Identifies the octet offset within the invoking packet where
the error was detected.
Codes 3, 4, and 5 are analogues of ICMPv6 Parameter Problem codes 0,
1, and 2 defined for IPv6 in [RFC4443]. Operation and semantics of
these codes are the same as their counterparts in [RFC4443] with the
following differences:
* The multi-part ICMP format of [RFC4884] is used and its fields are
set appropriately.
* The pointer to the offending byte in the invoking packet is
contained in the 32 bit Pointer field in the extended format.
Herbert Expires 18 June 2024 [Page 13]
Internet-Draft IPv4 EH December 2023
Codes 6, 7, and 8 are analogues of Parameter Problem codes 4, 5, and
6 defined for IPv6 in [RFC8883]. Operation and semantics of these
codes are the same as their counterparts in [RFC4443] with the
following differences:
* The multi-part ICMP format of [RFC4884] is used and its fields are
set appropriately.
* The pointer to the offending byte in the invoking packet is
contained in the 32 bit Pointer field in the extended format.
3.2. Destination Unreachable codes
This specification defines one IPv4 Destination Unreachable code for
aggregate header limits being exceeded as described in [RFC8883].
The error for aggregate header limits employs a multi-part ICMPv4
message format as defined in [RFC4884]. The extended structure
contains a pointer to the octet beyond the limit.
The format of the ICMPv4 message for an aggregate header limit
exceeded 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 | Length | unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Internet Header + leading octets of original datagram |
| |
| // |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Fields:
* Destination Address
Copied from the Source Address field of the invoking packet.
ICMPv4 Fields:
* Type
3 (Destination Unreachable Message)
Herbert Expires 18 June 2024 [Page 14]
Internet-Draft IPv4 EH December 2023
* Code (pertinent to this specification)
16 - Headers too long
* Length
Length of the padded "original datagram" field, measured in 32-
bit words.
* Pointer
Identifies the octet offset within the invoking packet where
the error was detected.
Code 16 is an analogue of Destination Unreachable code 8 defined in
[RFC8883]. Operation and semantics of the code should be the same as
the counterpart in [RFC8883].
4. No Next Header
The value 59 MAY be set in the Protocol field of the IPv4 header or
in the Next Header field of an IPv4 extension header. This indicates
that there is nothing following that header. The semantics of
setting this value are the same as that described in [RFC8200] with
adaptation for use with IPv4. If the Total Length field of the IPv4
header indicates the presence of octets past the end of a header
who's Next Header field contains 59, those octets must be ignored and
passed on unchanged if the packet is forwarded.
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."
This specification allows the IPv4 ID to be used as a flow label in
atomic datagrams where (DF==1) and (MF==0) and (frag_offset==0).
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
Herbert Expires 18 June 2024 [Page 15]
Internet-Draft IPv4 EH December 2023
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.
* If the IPv4 Identification field is not used as a flow label in
atomic fragments, the Identification field MUST 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.
5.2. Receiver Requirements
Receivers, including routers and intermediate 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.
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.
Herbert Expires 18 June 2024 [Page 16]
Internet-Draft IPv4 EH December 2023
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
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].
Herbert Expires 18 June 2024 [Page 17]
Internet-Draft IPv4 EH December 2023
+----------+--------------------------+----------------------------+
| Protocol | Description | Reference |
| number | | |
+----------+--------------------------+----------------------------+
| 0 | IPv4 Hop-by-Hop Options | [This document] |
| | | [RFC8200] |
+----------+--------------------------+----------------------------+
| 43 | Routing Header for IPv4 | [This document] |
| | | [RFC8200] |
+----------+--------------------------+----------------------------+
| 44 | Fragment Header for IPv4 | [This document] |
| | | [RFC8200] |
+----------+--------------------------+----------------------------+
| 50 | Encapsulating Security | [RFC4303] |
| | Payload | |
+----------+--------------------------+----------------------------+
| 51 | Authentication Header | [RFC4302] |
| | | |
+----------+--------------------------+----------------------------+
| 60 | Destination Options for | [This document] |
| | IPv4 | [RFC8200] |
+----------+--------------------------+----------------------------+
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] |
| | | | | | [RFC8200] |
+-----------+-----+-----+------+----------------+------------------+
| 0x01 | 00 | 0 | 0000 | PadN | [This document] |
| | | | | | [RFC8200] |
+-----------+-----+-----+------+----------------+------------------+
9. ICMP Parameters
9.1. Parameter Problem codes
IANA is requested to assign the following codes in "ICMP Type
Numbers" for type 12 "Parameter Problem":
Herbert Expires 18 June 2024 [Page 18]
Internet-Draft IPv4 EH December 2023
3 - Erroneous header field encountered
4 - Unrecognized Next Header type encountered
5 - Unrecognized IPv4 option encountered
6 - Extension header too big
7 - Extension header chain too long
8 - Too many options in extension header
9.2. Destination Unreachable codes
IANA is requested to assign the following codes in "ICMP Type
Numbers" for type 3 "Destination Unreachable":
16 - Headers too long
10. References
10.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>.
10.2. Informative References
[I-D.bonica-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-bonica-6man-comp-rtg-hdr-
31, 23 June 2023, <https://datatracker.ietf.org/doc/html/
draft-bonica-6man-comp-rtg-hdr-31>.
[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-eh-limits]
Herbert, T., "Limits on Sending and Processing IPv6
Extension Headers", Work in Progress, Internet-Draft,
draft-ietf-6man-eh-limits-11, 30 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-11>.
Herbert Expires 18 June 2024 [Page 19]
Internet-Draft IPv4 EH December 2023
[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-12, 21 November 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-12>.
[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>.
[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>.
[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 18 June 2024 [Page 20]
Internet-Draft IPv4 EH December 2023
[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>.
[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
"Extended ICMP to Support Multi-Part Messages", RFC 4884,
DOI 10.17487/RFC4884, April 2007,
<https://www.rfc-editor.org/info/rfc4884>.
[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>.
[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>.
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[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>.
[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>.
Herbert Expires 18 June 2024 [Page 21]
Internet-Draft IPv4 EH December 2023
[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 18 June 2024 [Page 22]