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]