Internet DRAFT - draft-herbert-ipv4-eh

draft-herbert-ipv4-eh







Network Working Group                                         T. Herbert
Internet-Draft                                                   SiPanda
Intended status: Standards Track                        23 February 2024
Expires: 26 August 2024


                 IPv4 Extension Headers and Flow Label
                        draft-herbert-ipv4-eh-03

Abstract

   This specification defines extension headers for IPv4 and an IPv4
   flow label.  The goal is to provide a uniform and feasible method of
   extensibility that is common between IPv4 and IPv6.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 26 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.






Herbert                  Expires 26 August 2024                 [Page 1]

Internet-Draft                   IPv4 EH                   February 2024


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  IPv4 extension headers  . . . . . . . . . . . . . . .   5
       1.1.2.  IPv4 flow labels  . . . . . . . . . . . . . . . . . .   6
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  IPv4 Extension Headers  . . . . . . . . . . . . . . . . . . .   6
     2.1.  Adapting IPv6 Extension headers . . . . . . . . . . . . .   6
     2.2.  General requirements  . . . . . . . . . . . . . . . . . .   7
     2.3.  Extension Header Order  . . . . . . . . . . . . . . . . .   9
     2.4.  Options . . . . . . . . . . . . . . . . . . . . . . . . .  10
     2.5.  Hop-by-Hop Options Header . . . . . . . . . . . . . . . .  13
       2.5.1.  Hop-by-Hop Options format . . . . . . . . . . . . . .  13
       2.5.2.  Hop-by-Hop Options Processing . . . . . . . . . . . .  14
     2.6.  Routing Header  . . . . . . . . . . . . . . . . . . . . .  15
     2.7.  Fragment Header . . . . . . . . . . . . . . . . . . . . .  17
       2.7.1.  Fragment Header format  . . . . . . . . . . . . . . .  17
       2.7.2.  Procedures  . . . . . . . . . . . . . . . . . . . . .  17
       2.7.3.  Rules for reassembly  . . . . . . . . . . . . . . . .  21
     2.8.  Destination Options Header  . . . . . . . . . . . . . . .  23
     2.9.  No Next Header  . . . . . . . . . . . . . . . . . . . . .  25
     2.10. Interaction with standard IPv4 mechanisms . . . . . . . .  25
       2.10.1.  IPv4 options and IPv4 extension headers  . . . . . .  25
       2.10.2.  IPv4 fragmentation and IPv4 extension headers  . . .  25
   3.  ICMPv4 messages for extension headers . . . . . . . . . . . .  26
     3.1.  Ext-hdr Time Exceeded Message . . . . . . . . . . . . . .  26
     3.2.  Ext-hdr Parameter Problem Message . . . . . . . . . . . .  27
       3.2.1.  Erroneous header field encountered (Code 0) . . . . .  28
       3.2.2.  Unrecognized Next Header type encountered (Code 1)  .  29
       3.2.3.  Unrecognized IPv4 option encountered (Code 2) . . . .  29
       3.2.4.  IPv4 First Fragment has incomplete IPv4 Header Chain
               (Code 3)  . . . . . . . . . . . . . . . . . . . . . .  29
       3.2.5.  Unrecognized Next Header Type Encountered by
               Intermediate Node (Code 5)  . . . . . . . . . . . . .  29
       3.2.6.  Extension Header Too Big (Code 6) . . . . . . . . . .  29
       3.2.7.  Extension Header Chain Too Long (Code 7)  . . . . . .  30
       3.2.8.  Too Many Extension Headers (Code 8) . . . . . . . . .  30
       3.2.9.  Too Many Options in Extension Header (Code 9) . . . .  30
       3.2.10. Option Too Big (Code 10)  . . . . . . . . . . . . . .  30
   4.  Inflight Removal of IPv4 Hop-by-Hop and Routing Headers . . .  31
     4.1.  Requirements  . . . . . . . . . . . . . . . . . . . . . .  31
     4.2.  Procedures  . . . . . . . . . . . . . . . . . . . . . . .  32
       4.2.1.  Removing a Hop-by-Hop Options Header  . . . . . . . .  32
       4.2.2.  Removing a Routing Header . . . . . . . . . . . . . .  34
       4.2.3.  Removing both a Hop-by-Hop Options and a Routing
               header  . . . . . . . . . . . . . . . . . . . . . . .  36
   5.  The IPv4 flow label . . . . . . . . . . . . . . . . . . . . .  38



Herbert                  Expires 26 August 2024                 [Page 2]

Internet-Draft                   IPv4 EH                   February 2024


     5.1.  Sender Requirements . . . . . . . . . . . . . . . . . . .  38
     5.2.  Receiver Requirements . . . . . . . . . . . . . . . . . .  39
   6.  Deployability Considerations  . . . . . . . . . . . . . . . .  40
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  40
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  40
     8.1.  IPv4 Extension Header types . . . . . . . . . . . . . . .  41
     8.2.  Destination Options and Hop-by-Hop Options  . . . . . . .  41
     8.3.  ICMP Parameters . . . . . . . . . . . . . . . . . . . . .  41
       8.3.1.  Ext-hdr Time Exceeded . . . . . . . . . . . . . . . .  42
       8.3.2.  Ext-hdr Parameter Problem . . . . . . . . . . . . . .  42
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  43
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  43
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  43
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  47

1.  Introduction

   This specification defines extension headers for IPv4 as well as an
   IPv4 flow label.  The motivation is to provide extensible protocol
   mechanisms in IPv4 that are unified with IPv6, thus leveraging common
   protocol and implementation for extensibility between the two
   versions of the Internet Protocol.  Additionally, this specification
   defines ICMPv4 messages related to extension headers that are
   equivalents of corresponding ICMPv6 messages.

   This specification allows the core extension headers defined in
   [RFC8200] to be used with IPv4.  These extension headers include Hop-
   by-Hop Options, Destination Options, Routing Header, and Fragment
   Header.  Note that Authentication Header [RFC4302] and Encapsulating
   Security Payload [RFC4303] are already usable with IPv4.
   Additionally, No Next Header (protocol number 59) [RFC8200] is
   specified to be usable in IPv4 packets.  In addition to enabling the
   use of extension headers in IPv4, messages are defined in ICMPv4 for
   reporting errors related to IPv4 extension headers; the ICMP types
   and codes for these messages are adapted from corresponding ICMPv6
   messages [RFC4443] [RFC8883].

   The IPv4 flow label is similarly derived from the definition of the
   IPv6 flow label.  There is no flow label defined in the IPv4 header
   [RFC791], however under specific circumstances this specification
   allows the sixteen bit Identification field in the IPv4 header to be
   safely used as a flow label.









Herbert                  Expires 26 August 2024                 [Page 3]

Internet-Draft                   IPv4 EH                   February 2024


1.1.  Motivation

   IPv6 is intended to become the standard protocol of the Internet,
   however it is clear that there is a large segment of users that will
   be using IPv4 for the foreseeable future.  This is particularly true
   in many enterprises where a business case for transitioning to IPv6
   hasn't yet emerged [V6STATE].

   In lieu of sun-setting IPv4 and expecting all users to move to IPv6
   in some time frame that is unlikely to be met, this specification
   suggests an alternative which is to extend IPv4 with IPv6 features.
   The idea is to "backport" useful features of IPv6 into IPv4,
   essentially making IPv4 look more like IPv6.  The rationale for this
   is:

      1)  Users benefit from forward looking features being actively
          defined and developed for IPv6 without requiring them to
          immediately transition to IPv6.

      2)  This approach encourages common implementation of protocol
          features that can be shared between IPv6 and IPv4.

      3)  In making IPv4 look more like IPv6, the work required to
          complete a future transition to IPv6 may be reduced or
          simplified.

   Various standards and proposals using IPv6 extension headers are
   currently being deployed or discussed in IETF.  These include Segment
   Routing Header [RFC8754], Compressed Routing Header
   [I-D.ietf-6man-comp-rtg-hdr], Path MTU Option [RFC9268], In-situ OAM
   [RFC9486], Service-aware IPv6 Network
   [I-D.li-6man-app-aware-ipv6-network], and Firewall and Service
   Tickets [I-D.herbert-fast].  These protocols leverage the
   extensibility of extension headers defined for IPv6.  All of these
   proposals, in some form, could be of value for use with IPv4, however
   IPv4 lacks an extensibility mechanism that meets the requirements for
   supporting them.

   Of particular interest is enabling use of the Fragment Header in IPv4
   for IP fragmentation.  While IPv4 includes fragmentation as part of
   the core protocol, it uses a sixteen bit Identification value that is
   considered too small and not sufficiently robust [RFC8900].  The
   Fragment Header defines a thirty-two bit Identification field that
   addresses this concern if the Fragment Header can be used with IPv4
   to perform fragmentation.






Herbert                  Expires 26 August 2024                 [Page 4]

Internet-Draft                   IPv4 EH                   February 2024


   This document enables IPv4 packets to carry extension headers in the
   same manner that IPv6 packets carry extension headers including Hop-
   by-Hop and Destination options.  In doing so, the various extensions
   and options defined for IPv6 can be used with IPv4.  In many cases,
   such as the Fragment Header, Path MTU Hop-by-Hop option, and IOAM
   Hop-by-Hop options; extension headers or options are mostly protocol
   agnostic and would be applicable and usable with IPv4 with little or
   no change.  In other cases, such as Segment Routing, the extension
   header might be IPv6 specific, for example the Segment Routing Header
   contains a list of IPv6 addresses.  With some modification to the
   extension header definition, it is conceivable that these may work
   with IPv4.  For instance, the Segment Routing Header could be adapted
   for use with IPv4 by defining a routing header format that contains
   IPv4 addresses instead of IPv6 addresses.

1.1.1.  IPv4 extension headers

   IPv4 options were defined in [RFC791] as the means of extending the
   IP protocol.  IPv4 options have not been successful.  Early router
   implementations, and even those today, either don't process IPv4
   options or relegate them to a slow path effectively making them
   unusable for serious applications.  IPv4 options are limited to forty
   bytes length and, unlike TCP options, no IP options have been defined
   that are critical to communications.  The upshot is that IPv4 options
   have long not been considered an option for deployment [IPNOOP].

   IPv6 took a different approach.  Extensibility of IPv6 is provided by
   extension headers.  Optional internet-layer information is encoded in
   separate headers that may be placed between the IPv6 header and the
   upper-layer header in a packet [RFC8200].  IPv6 extension headers
   have had mixed success in deployment, especially in the open Internet
   because some intermediate devices have trouble processing them
   [RFC7872] [RFC9098].  However, there is ongoing work to address the
   deployability of IPv6 extension headers
   [I-D.ietf-6man-hbh-processing] [I-D.ietf-6man-eh-limits]
   [I-D.ietf-v6ops-hbh].

   Using extension headers with IPv4 is logically straightforward.  The
   IPv4 Protocol field is effectively re-designated to be a Next Header
   field with the same meaning and semantics as the IPv6 Next Header
   field.  In this manner, an IPv4 packet can contain IPv6 extension
   headers that are recast as IPv4 extension headers.  These include
   Hop-by-Hop Options, Routing Header, Fragment Header, Destination
   Options, Authentication Header, and Encapsulating Security Payload.
   In cases where an extension header contains IPv6 specific
   information, the extension header can be adapted for use with IPv4.
   For instance, a Routing Header carrying IPv6 addresses in the route
   list could be adapted to carry IPv4 addresses.



Herbert                  Expires 26 August 2024                 [Page 5]

Internet-Draft                   IPv4 EH                   February 2024


   There are a number of messages defined in ICMPv6 for reporting errors
   related to extension headers.  The types for these errors are Time
   Exceeded and Parameter Problem.  This document defines "Ext-hdr Time
   Exceeded" and "Ext-hdr Parameter Problem" types in ICMPv4 for
   reporting errors concerning IPv4 extension headers.  The same ICMP
   codes related to extension headers in the corresponding ICMPv6 types
   are used in the ICMPv4 messages.

1.1.2.  IPv4 flow labels

   IPv6 [RFC8200] introduced the concept of a flow label that has proven
   quite useful for flow classification, such as that needed by Equal-
   Cost Multipath (ECMP).  The base IPv4 header does not have reserved
   bits that could be allocated as a flow label, however this
   specification allows the sixteen bit Identification field to be used
   as a flow label in atomic datagrams [RFC6864].

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  IPv4 Extension Headers

   In IPv4, optional internet-layer information is encoded in separate
   headers that may be placed between the IPv4 header and the upper-
   layer header in a packet.  There is a small number of such extension
   headers, each one identified by a distinct Next Header value.

2.1.  Adapting IPv6 Extension headers

   IPv4 extension headers are adapted from IPv6 extension headers as
   defined in Section 4 of [RFC8200], with the following modifications:

   *  References to the IPv6 header are replaced by references to the
      IPv4 header.

   *  ICMP errors sent in the course of processing extension headers use
      ICMPv4 instead of ICMPv6.  Applicable ICMPv4 errors for extension
      header processing are specified in Section 3.

   *  The IPv4 header Protocol field assumes the same role and semantics
      with respect to extension headers as the IPv6 Next Header field.







Herbert                  Expires 26 August 2024                 [Page 6]

Internet-Draft                   IPv4 EH                   February 2024


   *  If a legacy IPv4 destination host, one that does not support IPv4
      extension headers, receives a packet with extension headers then
      the packet will be processed as having an unknown protocol.  It is
      expected that the packet will be discarded and an ICMP error may
      be generated.

   *  Extension headers or options that carry IPv6 specific data or are
      otherwise specific to IPv6 MUST NOT be used with IPv4 (Segment
      Routing [RFC8754] for example).  IPv4 variants of these MAY be
      defined if achieving the same functionality in IPv4 is desirable.

   *  References to the Payload Length, for instance in reassembly
      procedures, are reinterpreted as being the computed IPv4 payload
      length, that is IPv4 Total Length minus the length of the IPv4
      header.

   *  The Hop-by-Hop Options header is used to carry optional
      information that MAY be examined and processed by any node along a
      packet's delivery path.

   *  The IPv4 Hop-by-Hop Options header MAY be processed by routers.
      For routers that support IPv4 Hop-by-Hop options, processing of
      the header SHOULD be configurable where the default SHOULD be not
      to process the Hop-by-Hop Options header.  If a router is
      configured to process IPv4 Hop-by-Hop Options then processing
      procedures in Section 2.5.2 SHOULD be followed and limits on
      router processing of Hop-by-Hop Options in
      [I-D.ietf-6man-eh-limits] SHOULD be configurable.

   *  If a router that does not recognize IPv4 extension headers
      receives a packet with an extension header then it SHOULD forward
      the packet normally based on the addresses in the IPv4 header.
      Note that this is the same expected behavior for routers that
      receive a packet with any IP protocol they don't recognize.

2.2.  General requirements

   Extension headers are numbered from IANA IP Protocol Numbers
   [IANA-PN], the same values used for IPv4 and IPv6.  When processing a
   sequence of Next Header values in a packet, the first one that is not
   an extension header [IANA-EH] indicates that the next item in the
   packet is the corresponding upper-layer header.  A special "No Next
   Header" value is used if there is no upper-layer header
   (Section 2.9).

   As illustrated in these examples, an IPv4 packet MAY carry zero, one,
   or more extension headers, each identified by the Next Header field
   of the preceding header:



Herbert                  Expires 26 August 2024                 [Page 7]

Internet-Draft                   IPv4 EH                   February 2024


   +---------------+------------------------
   |  IPv4 header  | TCP header + data
   |               |
   | Protocol =    |
   |      TCP      |
   +---------------+------------------------

   +---------------+----------------+------------------------
   |  IPv4 header  | Routing header | TCP header + data
   |               |                |
   | Protocol =    |  Next Header = |
   |    Routing    |      TCP       |
   +---------------+----------------+------------------------

   +---------------+----------------+-----------------+-----------------
   |  IPv4 header  | Routing header | Fragment header | fragment of TCP
   |               |                |                 |  header + data
   | Protocol =    |  Next Header = |  Next Header =  |
   |    Routing    |    Fragment    |       TCP       |
   +---------------+----------------+-----------------+-----------------

   Extension headers (except for the Hop-by-Hop Options header and the
   Routing Header) MUST NOT processed, inserted, or deleted by any node
   along a packet's delivery path, until the packet reaches the node (or
   each of the set of nodes, in the case of multicast) identified in the
   Destination Address field of the IPv4 header.

   The Hop-by-Hop Options header MUST NOT inserted by any node, but MAY
   be examined or processed by any node along a packet's delivery path,
   until the packet reaches the node (or each of the set of nodes, in
   the case of multicast) identified in the Destination Address field of
   the IPv4 header.  The Hop-by-Hop Options header MAY be removed from a
   packet by a node in the delivery path as specified in Section 4.

   The Hop-by-Hop Options header, when present, MUST immediately follow
   the IPv4 header.  Its presence is indicated by the value zero in the
   Protocol field of the IPv4 header.  A router MUST only examine and
   process a Hop-by-Hop Options header if it is configured to do so.  If
   a router is not configured to process Hop-by-Hop Options header then
   it SHOULD forward packets containing a Hop-by-Hop Options header
   normally.

   The Routing Header header MUST NOT inserted or processed by any node,
   but MAY be removed from the packet by a node in the delivery path as
   specified in Section 4.






Herbert                  Expires 26 August 2024                 [Page 8]

Internet-Draft                   IPv4 EH                   February 2024


   At the destination node, normal demultiplexing on the Protocol field
   of the IPv4 header invokes the module to process the first extension
   header, or the upper-layer header if no extension header is present.
   The contents and semantics of each extension header determine whether
   or not to proceed to the next header.  Therefore, extension headers
   MUST be processed strictly in the order they appear in the packet; a
   receiver MUST NOT, for example, scan through a packet looking for a
   particular kind of extension header and process that header prior to
   processing all preceding ones.

   If, as a result of processing a header, the destination node is
   required to proceed to the next header but the Protocol field in the
   IPv4 header or Next Header value in the current extension header is
   unrecognized by the node, it SHOULD discard the packet and MAY send
   an ICMP Ext-hdr Parameter Problem message to the source of the
   packet, with an ICMP Code value of 1 ("unrecognized Next Header type
   encountered") and the ICMP Pointer field containing the offset of the
   unrecognized value within the original packet (Section 3).  The same
   action SHOULD be taken if a node encounters a Next Header value of
   zero in any header other than the Protocol field of the IPv4 header.

   Each extension header is an integer multiple of 8 octets long, in
   order to retain 8-octet alignment for subsequent headers.  Multi-
   octet fields within each extension header are aligned on their
   natural boundaries, i.e., fields of width n octets are placed at an
   integer multiple of n octets from the start of the header, for n = 1,
   2, 4, or 8.

   An implementation of IPv4 may support the following IPv4 extension
   headers:

      Hop-by-Hop Options
      Fragment
      Destination Options
      Routing
      Authentication
      Encapsulating Security Payload

   The first four are specified in this document; the last two are
   specified in [RFC4302] and [RFC4303], respectively.  The current list
   of IPv4 extension headers can be found at [IANA-EH].

2.3.  Extension Header Order

   When more than one extension header is used in the same packet, it is
   RECOMMENDED that those headers appear in the following order:

      IPv4 header



Herbert                  Expires 26 August 2024                 [Page 9]

Internet-Draft                   IPv4 EH                   February 2024


      Hop-by-Hop Options header
      Destination Options header (note 1)
      Routing header
      Fragment header
      Authentication header (note 2)
      Encapsulating Security Payload header (note 2)
      Destination Options header (note 3)
      Upper-Layer header

      note 1:   for options to be processed by the first destination
                that appears in the IPv4 Destination Address field plus
                subsequent destinations listed in the Routing header.

      note 2:   additional recommendations regarding the relative order
                of the Authentication and Encapsulating Security Payload
                headers are given in [RFC4303].

      note 3:   for options to be processed only by the final
                destination of the packet.

   Each extension header SHOULD occur at most once, except for the
   Destination Options header, which SHOULD occur at most twice (once
   before a Routing header and once before the upper-layer header).

   If the upper-layer header is another IPv4 header (in the case of IPv4
   being tunneled over or encapsulated in IPv4), it MAY be followed by
   its own extension headers, which are separately subject to the same
   ordering recommendations.

   If and when other extension headers are defined, their ordering
   constraints relative to the above listed headers MUST be specified.

   IPv4 nodes MUST accept and attempt to process extension headers in
   any order and occurring any number of times in the same packet,
   except for the Hop-by-Hop Options header, which is restricted to
   appear immediately after an IPv4 header only.  Nonetheless, it is
   strongly RECOMMENDED that sources of IPv4 packets adhere to the above
   recommended order until and unless subsequent specifications revise
   that recommendation.

2.4.  Options

   Two of the currently defined extension headers specified in this
   document -- the Hop-by-Hop Options header and the Destination Options
   header -- carry a variable number of "options" that are type-length-
   value (TLV) encoded in the following format:





Herbert                  Expires 26 August 2024                [Page 10]

Internet-Draft                   IPv4 EH                   February 2024


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
      |  Option Type  |  Opt Data Len |  Option Data
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

           Option Type         8-bit identifier of the type of option.

           Opt Data Len        8-bit unsigned integer.  Length of the
                               Option Data field of this option, in
                               octets.

           Option Data         Variable-length field.  Option-Type-
                               specific data.

   The sequence of options within a header MUST be processed strictly in
   the order they appear in the header; a receiver MUST NOT, for
   example, scan through the header looking for a particular kind of
   option and process that option prior to processing all preceding
   ones.

   The Option Type identifiers are internally encoded such that their
   highest-order 2 bits specify the action that MUST be taken if the
   processing IPv4 node does not recognize the Option Type:

      00 -  SHOULD skip over this option and continue processing the
            header.

      01 -  MAY discard the packet.

      10 -  MAY discard the packet and, regardless of whether or not the
            packet's Destination Address was a multicast address, MAY
            send an ICMP Ext-hdr Parameter Problem, Code 2, message to
            the packet's Source Address, pointing to the unrecognized
            Option Type.

      11 -  MAY discard the packet and, only if the packet's Destination
            Address was not a multicast address, MAY send an ICMP Ext-
            hdr Parameter Problem, Code 2, message to the packet's
            Source Address, pointing to the unrecognized Option Type.

   The third-highest-order bit of the Option Type specifies whether or
   not the Option Data of that option can change en route to the
   packet's final destination.  When an Authentication header is present
   in the packet, for any option whose data may change en route, its
   entire Option Data field MUST be treated as zero-valued octets when
   computing or verifying the packet's authenticating value.

      0 -  Option Data does not change en route




Herbert                  Expires 26 August 2024                [Page 11]

Internet-Draft                   IPv4 EH                   February 2024


      1 -  Option Data may change en route

   The three high-order bits described above are to be treated as part
   of the Option Type, not independent of the Option Type.  That is, a
   particular option is identified by a full 8-bit Option Type, not just
   the low-order 5 bits of an Option Type.

   The same Option Type numbering space is used for both the Hop-by-Hop
   Options header and the Destination Options header.  However, the
   specification of a particular option MAY restrict its use to only one
   of those two headers.

   Individual options may have specific alignment requirements, to
   ensure that multi-octet values within Option Data fields fall on
   natural boundaries.  The alignment requirement of an option is
   specified using the notation xn+y, meaning the Option Type must
   appear at an integer multiple of x octets from the start of the
   header, plus y octets.  For example:

   2n        means any 2-octet offset from the start of the header.
   8n+2      means any 8-octet offset from the start of the header, plus
             2 octets.

   There are two padding options that are used when necessary to align
   subsequent options and to pad out the containing header to a multiple
   of 8 octets in length.  These padding options MUST be recognized by
   all IPv4 implementations that support extension headers:

   Pad1 option (alignment requirement: none)

         +-+-+-+-+-+-+-+-+
         |       0       |
         +-+-+-+-+-+-+-+-+

   NOTE! the format of the Pad1 option is a special case -- it does not
   have length and value fields.

   The Pad1 option is used to insert 1 octet of padding into the Options
   area of a header.  If more than one octet of padding is required, the
   PadN option, described next, SHOULD be used, rather than multiple
   Pad1 options.

   PadN option (alignment requirement: none)

         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
         |       1       |  Opt Data Len |  Option Data
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -




Herbert                  Expires 26 August 2024                [Page 12]

Internet-Draft                   IPv4 EH                   February 2024


   The PadN option is used to insert two or more octets of padding into
   the Options area of a header.  For N octets of padding, the Opt Data
   Len field contains the value N-2, and the Option Data consists of N-2
   zero-valued octets.

   Appendix A of [RFC8200] contains applicable formatting guidelines for
   designing new options.

2.5.  Hop-by-Hop Options Header

   The Hop-by-Hop Options header is used to carry optional information
   that MAY be examined and processed by any node along a packet's
   delivery path.  The Hop-by-Hop Options header is identified by a
   Protocol value of 0 in the Protocol field of the IPv4 header.

2.5.1.  Hop-by-Hop Options format

   The Hop-by-Hop Options header has the following format:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Next Header  |  Hdr Ext Len  |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                                                               |
       .                                                               .
       .                            Options                            .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Next Header         8-bit selector.  Identifies the type of
                               header immediately following the Hop-by-
                               Hop Options header.  Uses the same values
                               as the IPv4 Protocol field [IANA-PN].

           Hdr Ext Len         8-bit unsigned integer.  Length of the
                               Hop-by-Hop Options header in 8-octet
                               units, not including the first 8 octets.

           Options             Variable-length field, of length such
                               that the complete Hop-by-Hop Options
                               header is an integer multiple of 8 octets
                               long.  Contains one or more TLV-encoded
                               options, as described in Section 2.4.

   The only hop-by-hop options defined in this document are the Pad1 and
   PadN options specified in Section 2.4.





Herbert                  Expires 26 August 2024                [Page 13]

Internet-Draft                   IPv4 EH                   February 2024


2.5.2.  Hop-by-Hop Options Processing

   The requirements in this section are adapted from the IPv6
   requirements for extension header processing in [RFC8200],
   [I-D.ietf-6man-hbh-processing], and [I-D.ietf-6man-eh-limits].

   Routers that support IPv4 extension headers SHOULD process the Hop-
   by-Hop Options header using the method defined in this document.  If
   a router does not process the Hop-by-Hop Options header, it SHOULD
   forward the packet normally based on the remaining Extension Header
   after the Hop-by-Hop Option header (i.e., a router SHOULD NOT drop a
   packet solely because it contains an Extension Header carrying Hop-
   by-Hop options).  A configuration could control that normal
   processing skips any or all of the Hop-by-Hop options carried in the
   Hop-by-Hop Options header.

   In the case of a legacy router that doesn't recognize a Hop-by-Hop
   Options header it is expected that the router will forward packets
   with Hop-by-Hop Options based on the contents of the IPv4 header;
   this is the same behavior for routers that forwarded packets of any
   IP protocol they don't recognize.

   It is expected that the Hop-by-Hop Options header will be processed
   by the Destination.  Hosts SHOULD process the Hop-by-Hop Options
   header in received packets.  A constrained host is an example of a
   node that does not process Hop-by-Hop Options header.  If a
   Destination does not process the Hop-by-Hop Options header, it MUST
   process the remainder of the packet normally.

   A source MAY limit the its use of Hop-by-Hop Options, either by the
   number of options or size of the Hop-by-Hop Options header, to
   increase the likelihood of successful transit across a network path
   as specified in [I-D.ietf-6man-eh-limits].  Because some routers
   might only process a limited number of options in the Hop-by-Hop
   Option header, sources are motivated to order the placement of Hop-
   by-Hop options within the Hop-by-Hop Options header in decreasing
   order of importance for their processing by nodes on the path.

   A router configuration needs to avoid vulnerabilities that arise when
   it cannot process Hop-by-Hop options at full forwarding rate.  A
   router MAY apply limits specified in [I-D.ietf-6man-eh-limits] to
   Hop-by-Hop processing to ensure it can meet the targeted forwarding
   rate.

   If a router is unable to process any Hop-by-Hop option (or is not
   configured to do so), it SHOULD behave in the way specified for an
   unrecognized Option Type when the action bits were set to "00".




Herbert                  Expires 26 August 2024                [Page 14]

Internet-Draft                   IPv4 EH                   February 2024


   If a router is unable to process further Hop-by-Hop options (or is
   not configured to do so), the router SHOULD skip the remaining
   options using the "Hdr Ext Len" field in the Hop-by-Hop Options
   header.  This field specifies the length of the Option Header in
   8-octet units.  After skipping an option, the router continues
   processing the remaining options in the header.  Skipped options do
   not need to be verified.

   When a node sends an ICMP message in response to a multicast packet,
   this could be exploited as an amplification attack.  This is
   particularly problematic when the source address is not valid (which
   can be mitigated when using a reverse path forwarding (RPF) check).
   A node SHOULD only send ICMP messages in response to a multicast
   address when this is enabled for the specific source and/or the group
   destination address.

   When an ICMP Ext-hdr Parameter Problem, Code 2, message is delivered
   to the source, the source can become aware that at least one node on
   the path has failed to recognize the option.  Generating an ICMP
   message incurs additional router processing.  Reception of this
   message is not guaranteed, routers might be unable to be configured
   so that they do not generate these messages, and they are not always
   forwarded to the Source.

2.6.  Routing Header

   The Routing header is used by an IPv4 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   destination.  The Routing header is identified by a Protocol or Next
   Header value of 43 in the immediately preceding header and has the
   following format:

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                       type-specific data                      .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Next Header         8-bit selector.  Identifies the type of
                               header immediately following the Routing
                               header.  Uses the same values as the IPv4
                               Protocol field [IANA-PN].

           Hdr Ext Len         8-bit unsigned integer.  Length of the



Herbert                  Expires 26 August 2024                [Page 15]

Internet-Draft                   IPv4 EH                   February 2024


                               Routing header in 8-octet units, not
                               including the first 8 octets.

           Routing Type        8-bit identifier of a particular Routing
                               header variant.

           Segments Left       8-bit unsigned integer.  Number of route
                               segments remaining, i.e., number of
                               explicitly listed intermediate nodes
                               still to be visited before reaching the
                               final destination.

           type-specific data  Variable-length field, of format
                               determined by the Routing Type, and of
                               length such that the complete Routing
                               header is an integer multiple of 8 octets
                               long.

   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

           If Segments Left is zero, the node must ignore the Routing
           header and proceed to process the next header in the packet,
           whose type is identified by the Next Header field in the
           Routing header.

           If Segments Left is non-zero, the node must discard the
           packet and send an ICMP Ext-hdr Parameter Problem, Code 0,
           message to the packet's Source Address, pointing to the
           unrecognized Routing Type.

   If, after processing a Routing header of a received packet, an
   intermediate node determines that the packet is to be forwarded onto
   a link whose link MTU is less than the size of the packet, the node
   must discard the packet and send an ICMP Packet Too Big message to
   the packet's Source Address.

   The currently defined IPv4 Routing Headers and their status can be
   found at [IANA-RH].  Allocation guidelines for IPv4 Routing Headers
   can be derived from [RFC5871].









Herbert                  Expires 26 August 2024                [Page 16]

Internet-Draft                   IPv4 EH                   February 2024


2.7.  Fragment Header

   The Fragment header is used by an IPv4 source to send a packet larger
   than would fit in the path MTU to its destination.  (Note: unlike
   standard IPv4, fragmentation using the Fragment Header is performed
   only by source nodes, not by routers along a packet's delivery path)

2.7.1.  Fragment Header format

   The Fragment header is identified by a Next Header value of 44 in the
   immediately preceding header and has the following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header         8-bit selector.  Identifies the initial header
                          type of the Fragmentable Part of the original
                          packet (defined below).  Uses the same values
                          as the IPv4 Protocol field [IANA-PN].

      Reserved            8-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      Fragment Offset     13-bit unsigned integer.  The offset, in
                          8-octet units, of the data following this
                          header, relative to the start of the
                          Fragmentable Part of the original packet.

      Res                 2-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      M flag              1 = more fragments; 0 = last fragment.

      Identification      32 bits.  See description below.

2.7.2.  Procedures

   In order to send a packet that is too large to fit in the MTU of the
   path to its destination, a source node may divide the packet into
   fragments and send each fragment as a separate packet, to be
   reassembled at the receiver.

   For every packet that is to be fragmented, the source node generates
   an Identification value.  The Identification must be different than
   that of any other fragmented packet sent recently* with the same



Herbert                  Expires 26 August 2024                [Page 17]

Internet-Draft                   IPv4 EH                   February 2024


   Source Address and Destination Address.  If a Routing header is
   present, the Destination Address of concern is that of the final
   destination.

 
      *  "recently" means within the maximum likely lifetime of a
         packet, including transit time from source to destination and
         time spent awaiting reassembly with other fragments of the same
         packet.  However, it is not required that a source node knows
         the maximum packet lifetime.  Rather, it is assumed that the
         requirement can be met by implementing an algorithm that
         results in a low identification reuse frequency.  Examples of
         algorithms that can meet this requirement are described in
         [RFC7739].

   The initial, large, unfragmented packet is referred to as the
   "original packet", and it is considered to consist of three parts, as
   illustrated:

   original packet:

    +------------------+-------------------------+---//----------------+
    |  Per-Fragment    | Extension & Upper-Layer |   Fragmentable      |
    |    Headers       |       Headers           |      Part           |
    +------------------+-------------------------+---//----------------+

      The Per-Fragment headers must consist of the IPv4 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

      The Extension headers are all other extension headers that are not
      included in the Per-Fragment headers part of the packet.  For this
      purpose, the Encapsulating Security Payload (ESP) is not
      considered an extension header.  The Upper-Layer header is the
      first upper-layer header that is not an IPv4 extension header.
      Examples of upper-layer headers include TCP, UDP, IPv4, IPv6,
      ICMPv4, and as noted ESP.

      The Fragmentable Part consists of the rest of the packet after the
      upper-layer header or after any header (i.e., initial IPv4 header
      or extension header) that contains a Next Header value of No Next
      Header.







Herbert                  Expires 26 August 2024                [Page 18]

Internet-Draft                   IPv4 EH                   February 2024


   The Fragmentable Part of the original packet is divided into
   fragments.  The lengths of the fragments must be chosen such that the
   resulting fragment packets fit within the MTU of the path to the
   packet's destination(s).  Each complete fragment, except possibly the
   last ("rightmost") one, is an integer multiple of 8 octets long.

   The fragments are transmitted in separate "fragment packets" as
   illustrated:

   original packet:

   +-----------------+-----------------+--------+--------+-//-+--------+
   |  Per-Fragment   |Ext & Upper-Layer|  first | second |    |  last  |
   |    Headers      |    Headers      |fragment|fragment|....|fragment|
   +-----------------+-----------------+--------+--------+-//-+--------+

   fragment packets:

    +------------------+---------+-------------------+----------+
    |  Per-Fragment    |Fragment | Ext & Upper-Layer |  first   |
    |    Headers       | Header  |   Headers         | fragment |
    +------------------+---------+-------------------+----------+

    +------------------+--------+-------------------------------+
    |  Per-Fragment    |Fragment|    second                     |
    |    Headers       | Header |   fragment                    |
    +------------------+--------+-------------------------------+
                          o
                          o
                          o
    +------------------+--------+----------+
    |  Per-Fragment    |Fragment|   last   |
    |    Headers       | Header | fragment |
    +------------------+--------+----------+

   The first fragment packet is composed of:

      (1)  The Per-Fragment headers of the original packet, with the
           Total Length of the original IPv4 header changed to contain
           the length of this fragment packet only plus the length of
           the IPv4 header itself, and the Next Header field of the last
           header of the Per-Fragment headers changed to 44.

      (2)  A Fragment header containing:

              The Next Header value that identifies the first header
              after the Per-Fragment headers of the original packet.




Herbert                  Expires 26 August 2024                [Page 19]

Internet-Draft                   IPv4 EH                   February 2024


              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              Fragmentable Part of the original packet.  The Fragment
              Offset of the first ("leftmost") fragment is 0.

              An M flag value of 1 as this is the first fragment.  The
              Identification value generated for the original packet.

      (3)  Extension headers, if any, and the Upper-Layer header.  These
           headers must be in the first fragment.  Note: This restricts
           the size of the headers through the Upper-Layer header to the
           MTU of the path to the packet's destinations(s).

      (4)  The first fragment.

   The subsequent fragment packets are composed of:

      (1)  The Per-Fragment headers of the original packet, with the
           Total Length of the original IPv4 header changed to contain
           the length of this fragment packet including the length of
           the IPv4 header itself, and the Next Header field of the last
           header of the Per-Fragment headers changed to 44.

      (2)  A Fragment header containing:

              The Next Header value that identifies the first header
              after the Per-Fragment headers of the original packet.

              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              Fragmentable Part of the original packet.

              An M flag value of 0 if the fragment is the last
              ("rightmost") one, else an M flag value of 1.

              The Identification value generated for the original
              packet.

      (3)  The fragment itself.

   Fragments MUST NOT be created that overlap with any other fragments
   created from the original packet.

   At the destination, fragment packets are reassembled into their
   original, unfragmented form, as illustrated:

   reassembled original packet:




Herbert                  Expires 26 August 2024                [Page 20]

Internet-Draft                   IPv4 EH                   February 2024


   +---------------+-----------------+---------+--------+-//--+--------+
   | Per-Fragment  |Ext & Upper-Layer|  first  | second |     | last   |
   |    Headers    |     Headers     |frag data|fragment|.....|fragment|
   +---------------+-----------------+---------+--------+-//--+--------+

2.7.3.  Rules for reassembly

   The following rules govern reassembly:

      An original packet is reassembled only from fragment packets that
      have the same Source Address, Destination Address, and Fragment
      Identification.

      The Per-Fragment headers of the reassembled packet consist of all
      headers up to, but not including, the Fragment header of the first
      fragment packet (that is, the packet whose Fragment Offset is
      zero), with the following two changes:

         The Next Header field of the last header of the Per-Fragment
         headers is obtained from the Next Header field of the first
         fragment's Fragment header.

         The Total Length of the reassembled packet is computed from the
         payload length of the Per-Fragment headers, the payload length
         and offset of the last fragment, and the length of the IP
         header for the reassembled packet.  For example, a formula for
         computing the Total Length of the reassembled original packet
         is:

            TL.orig =    IPHL.orig + PL.first - FL.first - 8 + (8 *
                         FO.last) + FL.last

            where

            IPHL.orig =  The length of the IP header for the reassembled
                         packet (derived from the first fragment
                         packet).
            TL.orig =    Total Length field of reassembled packet.
            PL.first =   payload length of first fragment packet (Total
                         Length minus length of the IP header of the
                         first fragment packet).
            FL.first =   length of fragment following Fragment header of
                         first fragment packet.
            FO.last =    Fragment Offset field of Fragment header of
                         last fragment packet.
            FL.last =    length of fragment following Fragment header of
                         last fragment.




Herbert                  Expires 26 August 2024                [Page 21]

Internet-Draft                   IPv4 EH                   February 2024


         The Fragmentable Part of the reassembled packet is constructed
         from the fragments following the Fragment headers in each of
         the fragment packets.  The length of each fragment is computed
         by subtracting from the packet's Total Length the length of the
         headers, including the IPv4 header, that precede fragment
         itself; its relative position in Fragmentable Part is computed
         from its Fragment Offset value.

         The Fragment header is not present in the final, reassembled
         packet.

         If the fragment is a whole datagram (that is, both the Fragment
         Offset field and the M flag are zero), then it does not need
         any further reassembly and should be processed as a fully
         reassembled packet (i.e., updating Next Header, adjust Total
         Length, removing the Fragment header, etc.).  Any other
         fragments that match this packet (i.e., the same IPv4 Source
         Address, IPv4 Destination Address, and Fragment Identification)
         should be processed independently.

   The following error conditions may arise when reassembling fragmented
   packets:

      o  If insufficient fragments are received to complete reassembly
         of a packet within 60 seconds of the reception of the first-
         arriving fragment of that packet, reassembly of that packet
         MUST be abandoned and all the fragments that have been received
         for that packet must be discarded.  If the first fragment
         (i.e., the one with a Fragment Offset of zero) has been
         received, an ICMP Ext-hdr Time Exceeded -- Fragment Reassembly
         Time Exceeded message MAY be sent to the source of that
         fragment.

      o  If the length of a fragment, as derived from the fragment
         packet's Payload Length field, is not a multiple of 8 octets
         and the M flag of that fragment is 1, then that fragment MUST
         be discarded and an ICMP Ext-hdr Parameter Problem, Code 0,
         message MAY be sent to the source of the fragment, pointing to
         the Payload Length field of the fragment packet.

      o  If the length and offset of a fragment are such that the Total
         Length of the packet reassembled from that fragment would
         exceed 65,535 octets, then that fragment MUST be discarded and
         an ICMP Ext-hdr Parameter Problem, Code 0, message MAY be sent
         to the source of the fragment, pointing to the Fragment Offset
         field of the fragment packet.

      o  If the first fragment does not include all headers through an



Herbert                  Expires 26 August 2024                [Page 22]

Internet-Draft                   IPv4 EH                   February 2024


         Upper-Layer header, then that fragment SHOULD be discarded and
         an ICMP Ext-hdr Parameter Problem, Code 3, message MAY be sent
         to the source of the fragment, with the Pointer field set to
         zero.

      o  If any of the fragments being reassembled overlap with any
         other fragments being reassembled for the same packet,
         reassembly of that packet MUST be abandoned and all the
         fragments that have been received for that packet MUST be
         discarded, and no ICMP error messages MAY be sent.

      o  It should be noted that fragments may be duplicated in the
         network.  Instead of treating these exact duplicate fragments
         as overlapping fragments, an implementation MAY choose to
         detect this case and drop exact duplicate fragments while
         keeping the other fragments belonging to the same packet.

   The following conditions are not expected to occur frequently but are
   not considered errors if they do:

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.

      Other fields in the IPv4 header may also vary across the fragments
      being reassembled.  Specifications that use these fields may
      provide additional instructions if the basic mechanism of using
      the values from the Offset zero fragment is not sufficient.  For
      example, Section 5.3 of [RFC3168] describes how to combine the
      Explicit Congestion Notification (ECN) bits from different
      fragments to derive the ECN bits of the reassembled packet.

2.8.  Destination Options Header

   The Destination Options header is used to carry optional information
   that need be examined only by a packet's destination node(s).  The
   Destination Options header is identified by a Next Header value of 60
   in the immediately preceding header and has the following format:





Herbert                  Expires 26 August 2024                [Page 23]

Internet-Draft                   IPv4 EH                   February 2024


       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Next Header  |  Hdr Ext Len  |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                                                               |
       .                                                               .
       .                            Options                            .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Next Header         8-bit selector.  Identifies the type of header
                          immediately following the Destination Options
                          header.  Uses the same values as the IPv4
                          Protocol field [IANA-PN].

      Hdr Ext Len         8-bit unsigned integer.  Length of the
                          Destination Options header in 8-octet units,
                          not including the first 8 octets.

      Options             Variable-length field, of length such that the
                          complete Destination Options header is an
                          integer multiple of 8 octets long.  Contains
                          one or more TLV-encoded options, as described
                          in Section 2.4.

   The only destination options defined in this document are the Pad1
   and PadN options specified in Section 2.4.

   Note that there are two possible ways to encode optional destination
   information in an IPv4 packet: either as an option in the Destination
   Options header or as a separate extension header.  The Fragment
   header and the Authentication header are examples of the latter
   approach.  Which approach can be used depends on what action is
   desired of a destination node that does not understand the optional
   information:

   *  If the desired action is for the destination node to discard the
      packet and, only if the packet's Destination Address is not a
      multicast address, send an ICMP Ext-hdr Parameter Problem with
      Code 2 for Unrecognized Option Type message to the packet's Source
      Address, then the information may be encoded either as a separate
      header or as an option in the Destination Options header whose
      Option Type has the value 11 in its highest-order 2 bits.  The
      choice may depend on such factors as which takes fewer octets, or
      which yields better alignment or more efficient parsing.






Herbert                  Expires 26 August 2024                [Page 24]

Internet-Draft                   IPv4 EH                   February 2024


   *  If any other action is desired, the information must be encoded as
      an option in the Destination Options header whose Option Type has
      the value 00, 01, or 10 in its highest-order 2 bits, specifying
      the desired action (see Section 2.4).

2.9.  No Next Header

   The value 59 in the Protocol field of an IPv4 header or any extension
   header indicates that there is nothing following that header.  If the
   Total Length field of the IPv4 header indicates the presence of
   octets past the end of a header whose Next Header field contains 59,
   those octets MUST be ignored and passed on unchanged if the packet is
   forwarded.

2.10.  Interaction with standard IPv4 mechanisms

   IPv4 extension headers MAY be used concurrently with IPv4 mechanisms
   such as IPv4 options and IPv4 fragmentation.  This section discusses
   the interactions.

2.10.1.  IPv4 options and IPv4 extension headers

   An IPv4 packet MAY contain both IPv4 options and extension headers.
   IPv4 options are independent of IPv4 extension headers.  IPv4 options
   MUST be processed before processing any extension headers per normal
   requirements of processing the IP header before the IP payload.

2.10.2.  IPv4 fragmentation and IPv4 extension headers

   An IPv4 packet MAY be fragmented both by using a Fragment extension
   header as well as by standard IPv4 fragmentation.  The Fragment
   header can only be set at the source, however intermediate devices
   can fragment packets using standard IPv4 fragmentation.  Standard
   IPv4 fragmentation at a source node MUST be done only after any
   extension headers are set in a packet or the packet was fragmented
   using the Fragment header.  Specifically, fragmentation using the
   extension header MUST NOT be done on packet fragments created by
   standard IPv4 fragmentation.  However, a packet fragment that
   contains a Fragment header MAY itself be fragmented by standard IPv4
   fragmentation.  There is no correlation between standard IPv4
   fragmentation and the IPv4 Fragment header, the fragment
   identification number space for each are unrelated and reassembly
   procedures are independent.

   At a destination, if a received packet was fragmented by standard
   IPv4 fragmentation then it MUST be reassembled before processing any
   IPv4 extension headers.  This requirement ensures that standard IPv4
   reassembly is done before reassembly for the Fragment header.



Herbert                  Expires 26 August 2024                [Page 25]

Internet-Draft                   IPv4 EH                   February 2024


   If an IPv4 packet containing Hop-by-Hop options is fragmented using
   standard IPv4 fragmentation, the Hop-by-Hop options are not set in
   each of the packet fragments.  An intermediate node MAY process the
   Hop-by-Hop options in the first fragment if the complete Hop-by-Hop
   extension header is contained within the fragment.  If the Fragment
   header is used with IPv4 then the DF bit (Don't Fragment) bit SHOULD
   be set and Path MTU discovery mechanisms SHOULD be used [RFC4821].

   It is RECOMMENDED to only use IPv4 extensions in atomic datagrams.
   Atomic datagrams [RFC6864] are IPv4 packets for which the Don't
   Fragment bit set, More Fragment bit is not set, and Fragment Offset
   is zero.  In this case the packet will not be subject to IPv4
   fragmentation, the Fragment header can alternatively be used for
   fragmentation.

3.  ICMPv4 messages for extension headers

   This section defines two ICMPv4 types for reporting errors concerning
   IPv4 extension headers: Ext-hdr Time Exceeded and Ext-hdr Parameter
   Problem.  The same codes related to extension header errors in ICMPv6
   Time Exceeded and ICMPv6 Parameter Problem are defined for Ext-hdr
   Time Exceeded and Ext-hdr Parameter Problem [RFC4443][RFC8883].

   Receiver processing for these ICMP messages MUST be conformant with
   the requirements for processing ICMP errors as specified in [RFC792].

3.1.  Ext-hdr Time Exceeded Message

   The format of an Ext-hdr Time Exceeded Message is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Unused                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      +               as possible without the ICMPv4 packet           +
      |               exceeding the minimum IPv4 MTU [RFC791]         |

   IPv4 Fields:

   Destination Address  Copied from the Source Address field of the
      invoking packet.

   ICMPv4 Fields:




Herbert                  Expires 26 August 2024                [Page 26]

Internet-Draft                   IPv4 EH                   February 2024


   Type     44 (TBD)

   Code     1 -  Fragment reassembly time exceeded

   Unused   This field is unused for all code values.  It must be
            initialized to zero by the originator and ignored by the
            receiver.

   Description

   An ICMPv4 Ext-hdr Time Exceeded message with Code 1 is used to report
   fragment reassembly timeout, as specified in Section 2.7.3.

   Upper Layer Notification

   An incoming Time Exceeded message MUST be passed to the upper-layer
   process if the relevant process can be identified.

3.2.  Ext-hdr Parameter Problem Message

   The format of an Ext-hdr Parameter Problem Message is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Pointer                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    As much of invoking packet                 |
      +               as possible without the ICMPv4 packet           +
      |               exceeding the minimum IPv4 MTU [RFC791]         |

   IPv4 Fields:

   Destination Address  Copied from the Source Address field of the
      invoking packet.

   ICMPv4 Fields:

   Type     45 (TBD)

   Code     0 -  Erroneous header field encountered
            1 -  Unrecognized Next Header type encountered
            2 -  Unrecognized IPv4 option encountered
            3 -  IPv4 First Fragment has incomplete IPv4 Header Chain
            5 -  Unrecognized Next Header type encountered by
                 intermediate node



Herbert                  Expires 26 August 2024                [Page 27]

Internet-Draft                   IPv4 EH                   February 2024


            6 -  Extension header too big
            7 -  Extension header chain too long
            8 -  Too many extension headers
            9 -  Too many options in extension header
            10 -  Option too big

   Pointer  Identifies the octet offset within the invoking packet where
            the error was detected.

            The pointer will point beyond the end of the ICMPv4 packet
            if the field in error is beyond what can fit in the maximum
            size of an ICMPv4 error message.

   Description

   If an IPv4 node processing a packet finds a problem with a field in
   the IPv4 extension headers such that it cannot complete processing
   the packet, it MUST discard the packet and MAY originate an ICMPv4
   Ext-hdr Parameter Problem message to the packet's source, indicating
   the type and location of the problem.

   Codes 1 through 3 and 5 through 10 are more informative than Code 0
   and SHOULD be used when possible.

   The pointer identifies the octet of the original packet's header
   where the error was detected.  For example, an ICMPv4 message with a
   Type field of 45 (TBD), Code field of 1, and Pointer field of 20
   would indicate that the IPv4 extension header following the typical
   twenty byte IPv4 header of the original packet holds an unrecognized
   Next Header field value.

   Upper Layer Notification

   A node receiving this ICMPv4 message MUST notify the upper-layer
   process if the relevant process can be identified.


3.2.1.  Erroneous header field encountered (Code 0)

   An ICMPv4 Ext-hdr Parameter Problem with code for "Erroneous header
   field encountered" MAY be sent when a node discards a packet because
   of an issue with an extension header.  This is a general error, and
   SHOULD only be used if there is not a more specific and informative
   code for the problem.  The ICMPv4 Pointer field is set to the offset
   of data in error.






Herbert                  Expires 26 August 2024                [Page 28]

Internet-Draft                   IPv4 EH                   February 2024


3.2.2.  Unrecognized Next Header type encountered (Code 1)

   An ICMPv4 Ext-hdr Parameter Problem with code for "Unrecognized Next
   Header type encountered" MAY be sent when a node discards a packet
   because a Next Header in an extension header is unrecognized.  The
   ICMPv4 Pointer field is set to the offset of the unrecognized Next
   Header field in an extension header.

3.2.3.  Unrecognized IPv4 option encountered (Code 2)

   An ICMPv4 Ext-hdr Parameter Problem with code for "Unrecognized IPv4
   option encountered" MAY be sent when a node discards a packet because
   an option type is unrecognized and the higher order two bits of the
   option type are not 00.  The ICMPv4 Pointer field is set to the
   offset of the unrecognized option type.

3.2.4.  IPv4 First Fragment has incomplete IPv4 Header Chain (Code 3)

   An ICMPv4 Ext-hdr Parameter Problem with code for "IPv4 First
   Fragment has incomplete IPv4 Header Chain" MAY be sent when a node
   discards a packet because the IPv4 header chain for a fragmented
   packet is not completely contained in the first fragment.  The ICMPv4
   Pointer field MUST be set zero.  The format for the ICMPv4 error
   message is the same regardless of whether a host or intermediate
   system originates it.

3.2.5.  Unrecognized Next Header Type Encountered by Intermediate Node
        (Code 5)

   This code MAY be sent by an intermediate node that discards a packet
   because it encounters a Next Header type that is unknown in its
   examination.  The ICMPv4 Pointer field is set to the offset of the
   unrecognized Next Header value within the original packet.

   Note that this code is sent by intermediate nodes and SHOULD NOT be
   sent by a final destination.  If a final destination node observes an
   unrecognized header, then it SHOULD send an ICMP Ext-hdr Parameter
   Problem message with an ICMP Code value of 1 ("unrecognized Next
   Header type encountered") as specified in [RFC8200].

3.2.6.  Extension Header Too Big (Code 6)

   An ICMPv4 Ext-hdr Parameter Problem with code for "Extension header
   too big" SHOULD be sent when a node discards a packet because the
   size of an extension header exceeds its processing limit.  The ICMPv4
   Pointer field is set to the offset of the first octet in the
   extension header that exceeds the limit.




Herbert                  Expires 26 August 2024                [Page 29]

Internet-Draft                   IPv4 EH                   February 2024


3.2.7.  Extension Header Chain Too Long (Code 7)

   An ICMPv4 Ext-hdr Parameter Problem with code for "Extension header
   chain too long" SHOULD be sent when a node discards a packet with an
   extension header chain that exceeds a limit on the total size in
   octets of the header chain.  The ICMPv4 Pointer is set to the first
   octet beyond the limit.

3.2.8.  Too Many Extension Headers (Code 8)

   An ICMPv4 Ext-hdr Parameter Problem with code for "Too many extension
   headers" SHOULD be sent when a node discards a packet with an
   extension header chain that exceeds a limit on the number of
   extension headers in the chain.  The ICMPv4 Pointer is set to the
   offset of the first octet of the first extension header that is
   beyond the limit.

3.2.9.  Too Many Options in Extension Header (Code 9)

   An ICMPv4 Ext-hdr Parameter Problem with code for "Too many options
   in extension header" SHOULD be sent when a node discards a packet
   with an extension header that has a number of options that exceeds
   the processing limits of the node.  This code is applicable for
   Destination Options and Hop-by-Hop Options.  The ICMPv4 Pointer field
   is set to the first octet of the first option that exceeds the limit.

3.2.10.  Option Too Big (Code 10)

   An ICMPv4 Ext-hdr Parameter Problem with code for "Option too big" is
   sent in two different cases: when the length of an individual Hop-by-
   Hop or Destination Option exceeds a limit, or when the length or
   number of consecutive Hop-by-Hop or Destination padding options
   exceeds a limit.  In a case where the length of an option exceeds a
   processing limit, the ICMPv4 Pointer field is set to the offset of
   the first octet of the option that exceeds the limit.  In cases where
   the length or number of padding options exceeds a limit, the ICMPv4
   Pointer field is set to the offset of the first octet of the padding
   option that exceeds the limit.

   Possible limits related to padding include
   [RFC8504][I-D.ietf-6man-eh-limits]:

   *  The number of consecutive PAD1 options in Destination Options or
      Hop-by-Hop Options is limited to seven octets.

   *  The length of PADN options in Destination Options or Hop-by-Hop
      Options is limited to seven octets.




Herbert                  Expires 26 August 2024                [Page 30]

Internet-Draft                   IPv4 EH                   February 2024


   *  The aggregate length of a set of consecutive PAD1 or PADN options
      in Destination Options or Hop-by-Hop Options is limited to seven
      octets.

4.  Inflight Removal of IPv4 Hop-by-Hop and Routing Headers

   Under certain circumstances the IPv4 Hop-by-Hop Options and Routing
   Headers MAY be removed from a packet while it's in-flight.  The
   motivations for dropping Hop-by-Hop Options and Routing Headers are
   outlined in [I-D.herbert-eh-inflight-removal].

   This section describes the procedures and requirements for removing a
   Hop-by-Hop Options header, removing a Routing header, and removing a
   Hop-by-Hop Options and a Routing header at the same time.  The
   requirements and procedures are derived from those in
   [I-D.herbert-eh-inflight-removal].

4.1.  Requirements

   An router MAY remove a Hop-by-Hop Options header from a packet if the
   following conditions are met:

   *  The packet does not contain an Authentication header.  If the
      packet contains and Authentication header then the Hop-by-Hop
      Options header MUST NOT be removed

   *  The Total Length of the packet is greater then the IP header
      lengths Hop-by-Hop options does not include a Jumbo Payload Option
      [RFC2675] (assuming the Jumbo Payload option is allowed for use
      with IPv4).  If the packet contains a Jumbo Payload option then
      the Total Length should be equal to the length of the IP header.

   A router MAY remove a Routing header extension header from a packet
   if the following conditions are met:

   *  The Destination Address has been set to the address of the final
      destination and the Segments Left field is zero

   *  The packet does not contain an Authentication header

   *  There are no extension headers the precede the Routing header in
      the packet.  An exception is if the Routing header immediately
      follow a Hop-by-Hop Options header that is also being removed

   *  The final destination is not required to process or validate the
      Routing header

   *  The Routing header does not contain options (segment routing TLVs



Herbert                  Expires 26 August 2024                [Page 31]

Internet-Draft                   IPv4 EH                   February 2024


      for instance), or the destination host doesn't need to process or
      validate the options.

4.2.  Procedures

4.2.1.  Removing a Hop-by-Hop Options Header

   The procedures for removing a Hop-by-Hop Options header are:

   1.  Save the value in the Next Header field of the Hop-by-Hop Options
       header in a temporary variable

   2.  Determine the length of the Hop-by-Hop header and save in a
       temporary variable.  This is equal to the value of the Hdr Ext
       Len field times eight plus eight

   3.  Determine the offset of the first byte following the Hop-by-Hop
       Options header.  This is equal to the length of the IP header
       plus the length of the Hop-by-Hop Options header derived in step
       2

   4.  Copy the IPv4 header with its derived length to the offset
       derived in step 3 minus the length of the IPv4 header.  Reset the
       starting offset of the packet to be the offset of the copied IPv4
       header

   5.  Set the Protocol field in the copied IPv4 header to the value
       saved in step 1

   6.  Subtract the length of the Hop-by-Hop Options header, determined
       in step 2, from the Total Length in the copied IPv4 header.  Set
       the result as the Total Length in the copied IPv4 header

   An example of removing Hop-by-Hop Options header is shown in the
   diagrams below.

   The diagram below illustrates shows an example TCP/IPv4 packet with a
   Hop-by-Hop Options header; the Total Length is 1220 bytes and the
   length of the Hop-by-Hop Options header is sixty-four bytes.












Herbert                  Expires 26 August 2024                [Page 32]

Internet-Draft                   IPv4 EH                   February 2024


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
     |  0x4  |IHL=5  |Type of Service|       Total Length = 1220     | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
     |         Identification        |Flags|      Fragment Offset    | P
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
     |  Time to Live | Protocol = 0  |        Header Checksum        | 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                       Source IPv4 Address                     | h
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
     |                     Destination IPv4 Address                  | r
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
     |  Next Hdr = 6 |   EH Len = 7  |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     .                                                               .
     .                            Options                            .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                    TCP packet and payload                     .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The diagram below illustrates the packet after the Hop-by-Hop Options
   header has been removed.  Note that the Total Length is now 1,156
   bytes which is the original total length minus the length of the Hop-
   by-Hop Options header that was removed.

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
     |  0x4  |IHL=5  |Type of Service|       Total Length = 1156     | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
     |         Identification        |Flags|      Fragment Offset    | P
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
     |  Time to Live | Protocol = 6  |        Header Checksum        | 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                       Source IPv4 Address                     | h
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
     |                     Destination IPv4 Address                  | r
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
     |                                                               |
     .                                                               .
     .                    TCP packet and payload                     .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Herbert                  Expires 26 August 2024                [Page 33]

Internet-Draft                   IPv4 EH                   February 2024


4.2.2.  Removing a Routing Header

   As discussed in [I-D.herbert-eh-inflight-removal] a Routing Header
   MAY be removed from a packet by a router when Segments Left is equal
   to zero.

   The procedures for removing a Routing header are:

   1.  Save the value in the Next Header field of the Routing header in
       a temporary variable

   2.  Determine the length of the Routing header and save in a
       temporary variable.  This is equal to the value of the Hdr Ext
       Len field times eight plus eight

   3.  Determine the offset of the first byte following the Routing
       header.  This is equal to length of the IP header plus the length
       of the Routing header derived in step 2

   4.  Copy the IPv4 header with its derived length to the offset
       derived in step 3 minus the length of the IPv4 header.  Reset the
       starting offset of the packet to be the offset of the copied IPv4
       header

   5.  Set the Protocol field in the copied IPv4 header to the value
       saved in step 1

   6.  Subtract the length of the Routing header, determined in step 2,
       from the Total Length in the copied IPv4 header.  Set the result
       as the Total Length in the copied IPv4 header

   An example of removing a Routing header is shown in the diagrams
   below.

   The diagram below illustrates shows an example TCP/IPv4 packet with a
   Routing header; the Total Length is 1,420 bytes and the length of the
   Routing header is 160 bytes.  The Segments Left field is set to zero
   so that the Routing header may be removed.













Herbert                  Expires 26 August 2024                [Page 34]

Internet-Draft                   IPv4 EH                   February 2024


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
     |  0x4  |IHL=5  |Type of Service|       Total Length = 1420     | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
     |         Identification        |Flags|      Fragment Offset    | P
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
     |  Time to Live | Protocol = 43 |        Header Checksum        | 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                       Source IPv4 Address                     | h
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
     |                     Destination IPv4 Address                  | r
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
     |  Next Hdr = 17|  EH Len = 19  |  Routing Type | Segs Left = 0 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                       type-specific data                      .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                    UDP packet and payload                     .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The diagram below illustrates the packet after the Routing header has
   been removed.  Note that the Payload Length is now 1,260 bytes which
   is the original total length minus the length of the Routing header
   that was removed.

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
     |  0x4  |IHL=5  |Type of Service|       Total Length = 1260     | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
     |         Identification        |Flags|      Fragment Offset    | P
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
     |  Time to Live | Protocol = 17 |         Header Checksum       | 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                       Source IPv4 Address                     | h
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
     |                     Destination IPv4 Address                  | r
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
     |                                                               |
     .                                                               .
     .                    UDP packet and payload                     .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Herbert                  Expires 26 August 2024                [Page 35]

Internet-Draft                   IPv4 EH                   February 2024


4.2.3.  Removing both a Hop-by-Hop Options and a Routing header

   As discussed in [I-D.herbert-eh-inflight-removal] both Routing Header
   and Hop-by-Hop Options MAY be removed from a packet by a ingress or
   egress router when Segments Left is equal to zero and there are no
   extension headers between the Hop-by-Hop Options header and the
   Routing header.

   The procedures for removing both a Hop-by-Hop Options and a Routing
   header are:

   1.  Save the value in the Next Header field of the Routing header
       extension header in a temporary variable

   2.  Determine the length of the Hop-by-Hop Options header and save in
       a temporary variable.  This is equal to the value of the Hdr Ext
       Len field times eight plus eight

   3.  Determine the length of the Routing header and save in a
       temporary variable.  This is equal to the value of the Hdr Ext
       Len field times eight plus eight

   4.  Determine the offset of the first byte in the packet following
       the Routing header.  This is equal to the length of the IP header
       plus the length of the Hop-by-Hop Options header derived in step
       2 plus the length of the Routing header derived in step 3

   5.  Copy the IPv4 header with its derived length to the offset
       derived in step 3 minus the length of the IPv4 header.  Reset the
       starting offset of the packet to be the offset of the copied IPv4
       header

   6.  Set the Protocol field in the copied IPv4 header to the value
       saved in step 1

   7.  Subtract the length of the Hop-by-Hop Options header plus the
       length of the Routing header (values determined in step 2 and
       step 3) from the Total Length in the copied IPv4 header.  Set the
       result as the Total Length in the copied IPv4 header

   An example of removing a Hop-by-Hop Options header a Routing header
   is shown in the diagrams below.

   The diagram below illustrates an example TCP/IPv4 packet with both a
   Hop-by-Hop Options and a Routing header; the Total Length is 1,320
   bytes, the length of the Hop-by-Hop Options header is sixty-four
   bytes, the length of the Routing header is 160 bytes.  The Segments
   Left field is set to zero so that the Routing header may be removed.



Herbert                  Expires 26 August 2024                [Page 36]

Internet-Draft                   IPv4 EH                   February 2024


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
     |  0x4  |IHL=5  |Type of Service|       Total Length = 1320     | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
     |         Identification        |Flags|      Fragment Offset    | P
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
     |  Time to Live | Protocol = 0  |         Header Checksum       | 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                       Source IPv4 Address                     | h
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
     |                     Destination IPv4 Address                  | r
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
     |  Next Hdr = 43 |   EH Len = 7 |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     .                                                               .
     .                            Options                            .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Hdr = 6 |  EH Len = 19  |  Routing Type | Segs Left = 0 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                       type-specific data                      .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                    TCP packet and payload                     .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The diagram below illustrates the packet after the Hop-by-Hop Options
   header and the Routing header have been removed.  Note that the
   Payload Length is now 1,096 bytes which is the original total length
   minus the length of the Hop-by-Hop Options header and the Routing
   header that were removed.












Herbert                  Expires 26 August 2024                [Page 37]

Internet-Draft                   IPv4 EH                   February 2024


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\\
     |  0x4  |IHL=5  |Type of Service|       Total Length = 1096     | |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
     |         Identification        |Flags|      Fragment Offset    | P
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
     |  Time to Live | Protocol = 6  |         Header Checksum       | 4
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
     |                       Source IPv4 Address                     | h
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
     |                     Destination IPv4 Address                  | r
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
     |                                                               |
     .                                                               .
     .                    TCP packet and payload                     .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.  The IPv4 flow label

   The Identification field of the IPv4 header is re-purposed to be the
   IPv4 flow label in atomic datagrams.  As stated in [RFC6864]:

      ">> Originating sources MAY set the IPv4 ID field of atomic
      datagrams to any value."

   That requirement allows the Identification field to be used as a flow
   label in atomic datagrams, however it also allows that legacy
   implementations might set the Identification field to arbitrary
   values.  A receiver should take this into account when considering
   interpreting the Identification field as a flow label (some guidance
   is provided below).

   This specification allows the IPv4 ID to be used as a flow label in
   atomic datagrams.

5.1.  Sender Requirements

   An origin host MAY set the IPv4 Identification field as a flow label
   in atomic datagram packets.  The IPv4 flow label is set following the
   same procedures for setting the IPv6 flow label as described in
   [RFC6437] with the following modifications:

   *  The Identification field MUST only be used as a flow label in
      atomic datagrams.  That is Don't Fragment (DF) bit MUST be set,
      More Fragment (MF) bit MUST NOT be set, and Fragment Offset MUST
      be zero.




Herbert                  Expires 26 August 2024                [Page 38]

Internet-Draft                   IPv4 EH                   February 2024


   *  If the IPv4 Identification field is not used as a flow label in
      atomic fragments, the Identification field SHOULD be set to zero.

   *  Only stateless flow labels can be set.

   *  The value to set, e.g. from a hash computation over packet
      headers, is truncated to sixteen bits (the size of the Fragment
      Identification field).

   *  Intermediate nodes MUST NOT set the Fragment Identification field
      in atomic datagrams.

   *  If a an IPv4 extension header, other than ESP or AH, is present in
      an atomic datagram then the Identification field MUST either be
      set as a flow label or set to a value of zero.  In the case of ESP
      or AH, an implementation SHOULD set the Identification field to a
      flow label or set to a value of zero (the exception to this is
      legacy implementations that may be setting the Identification
      field to some arbitrary value).

5.2.  Receiver Requirements

   Receivers, including routers and hosts, MAY process a non-zero
   Identification field in the IPv4 header of atomic datagrams as being
   a flow label.  The IPv4 flow label for instance can be used as input
   to ECMP as described in [RFC6438].

   If the Identification field is zero or the packet is not an atomic
   datagram (either the More Fragment bit is set, the Don't Fragment bit
   is not set, or Fragment Offset is non-zero) then the Identification
   field MUST NOT be considered as a flow label.

   If a receiver receives and atomic datagram containing an IPv4
   extension header other than ESP or AH, then the receiver can assume
   that a non-zero Identification field is a valid flow label.  The
   Identification field can safely be used as input to the ECMP hash and
   the router would not need to parse into the transport layer to
   extract port information as input to the hash computation.

   If a receiver receives an atomic datagram containing an ESP or AH
   header and no other IPv4 extension headers, then the receiver may
   assume that a non-zero Identification field is a valid flow label.
   The Identification field may be used as input to the ECMP hash,
   however if a router parses the ESP is or AH to extract flow entropy
   then that information should be used as input to the flow hash
   calculation instead of the value in the Identification field.





Herbert                  Expires 26 August 2024                [Page 39]

Internet-Draft                   IPv4 EH                   February 2024


   If a receiver receives an atomic datagram then a non-zero
   Identification may be used as a flow label.  The value in the
   Identification field should only be considered for use as input to
   the ECMP hash computation if there is not other means to extract flow
   entropy in the packet.  In particular, if a router receives a TCP,
   UDP, DCCP packet where the upper layer protocol immediately follows
   the IP header, then the router should extract the transport layer
   port numbers as input to the ECMP hash calculation and can ignore the
   value in the Identification field.

6.  Deployability Considerations

   If a legacy host device receives an IPv4 packet with IPv4 extension
   headers, the packet will be treated as having an unknown protocol and
   should be dropped.  Intermediate devices might also see packets with
   a protocol unknown to them and will forward the packet inasmuch as
   they would forward any packet with an unknown protocol.

   In the Internet, it is well known that there are some intermediate
   nodes that will drop packets with protocols that are unknown to them
   (firewalls would commonly do this for instance).  Therefore, it is
   unlikely that packets with IPv4 extension headers can be ubiquitously
   deployed over the Internet.

   In a limited domain [RFC8799], an operator would have control over
   intermediate nodes and could ensure that at a minimum they properly
   forward packets with IPv4 extension headers.  Routers in a limited
   domain can be updated to process IPv4 Hop-by-Hop Options or Routing
   headers to provide the functionality of features like IOAM and
   Segment Routing in IPv4.  Similarly, they could be updated to support
   the IPv4 flow label to provide flow based ECMP in the same manner
   that the IPv6 flow label is used for ECMP [RFC6438].

7.  Security Considerations

   This specification enables use of IPv6 extension headers in IPv4.
   Related security mechanisms of IPv6 extension headers can be applied
   for use with IPv4 extension headers.

   The IPv4 flow label has similar security properties as the IPv6 flow
   label.

8.  IANA Considerations








Herbert                  Expires 26 August 2024                [Page 40]

Internet-Draft                   IPv4 EH                   February 2024


8.1.  IPv4 Extension Header types

   In the "Internet Protocol Version 4 (IPv4) Parameters", registry IANA
   is requested to create the "IPv4 Extension Headers Types" sub-
   registry.  The initial entries are for the core extension header
   types defined in [RFC8200].

   +----------+--------------------------+----------------------------+
   | Protocol | Description              | Reference                  |
   | number   |                          |                            |
   +----------+--------------------------+----------------------------+
   | 0        | IPv4 Hop-by-Hop Options  | [This document]            |
   +----------+--------------------------+----------------------------+
   | 43       | Routing Header for IPv4  | [This document]            |
   +----------+--------------------------+----------------------------+
   | 44       | Fragment Header for IPv4 | [This document]            |
   +----------+--------------------------+----------------------------+
   | 50       | Encapsulating Security   | [RFC4303]                  |
   +----------+--------------------------+----------------------------+
   | 51       | Authentication Header    | [RFC4302]                  |
   +----------+--------------------------+----------------------------+
   | 60       | Destination Options for  | [This document]            |
   +----------+--------------------------+----------------------------+

8.2.  Destination Options and Hop-by-Hop Options

   In the "Internet Protocol Version 4 (IPv4) Parameters" registry, IANA
   is requested to create the "Destination Options and Hop-by-Hop
   Options" sub-registry.  The initial entries consist of Pad1 and PadN
   options.

   ------------+------------------+----------------+------------------+
   | Hex value | Binary value     | Description    | Reference        |
   |           | act | chg | rest |                |                  |
   +-----------+-----+-----+------+----------------+------------------+
   | 0x00      | 00  | 0   | 0000 | Pad1           | [This document]  |
   +-----------+-----+-----+------+----------------+------------------+
   | 0x01      | 00  | 0   | 0000 | PadN           | [This document]  |
   +-----------+-----+-----+------+----------------+------------------+

8.3.  ICMP Parameters

   IANA is requested to assign the following two ICMPv4 types in the
   "Internet Control Message Protocol (ICMP) Parameters" registry.







Herbert                  Expires 26 August 2024                [Page 41]

Internet-Draft                   IPv4 EH                   February 2024


   ------------+-----------------------------------+------------------+
   | Type      | Description                       | Reference        |
   +-----------+-----------------------------------+------------------+
   | 44 (TBD)  | Ext-hdr Time Exceeded             | [This document]  |
   +-----------+-----+-----+------+----------------+------------------+
   | 45 (TBD)  | Ext-hdr Parameter Problem         | [This document]  |
   +-----------+-----------------------------------+------------------+

8.3.1.  Ext-hdr Time Exceeded

   IANA is requested to assign the following code to the "Ext-hdr Time
   Exceeded" type.  Note that the specific number assignment
   intentionally corresponds to the equivalent code in ICMPv6 Time
   Exceeded type.

   +-----------+-----------------------------------+------------------+
   | Code      | Description                       | Reference        |
   +-----------+-----------------------------------+------------------+
   | 1         | fragment reassembly time exceeded | [This document]  |
   +-----------+-----------------------------------+------------------+

8.3.2.  Ext-hdr Parameter Problem

   IANA is requested to assign the following codes to the "Ext-hdr
   Parameter Problem" type.  Note that the specific number assignments
   intentionally correspond to equivalent codes in ICMPv6 Time Exceeded
   type.
























Herbert                  Expires 26 August 2024                [Page 42]

Internet-Draft                   IPv4 EH                   February 2024


   ------------+-----------------------------------+------------------+
   | Code      | Description                       | Reference        |
   +-----------+-----------------------------------+------------------+
   | 0         | Erroneous header field            | [This document]  |
   |           | encountered                       |                  |
   +-----------+-----+-----+------+----------------+------------------+
   | 1         | Unrecognized Next Header type     | [This document]  |
   |           | encountered                       |                  |
   +-----------+-----------------------------------+------------------+
   | 2         | unrecognized IPv4 option          | [This document]  |
   |           | encountered                       |                  |
   +-----------+-----------------------------------+------------------+
   | 3         | IPv4 First Fragment has           | [This document]  |
   |           | incomplete IPv4 Header Chain      |                  |
   +-----------+-----------------------------------+------------------+
   | 5         | Unrecognized Next Header type     | [This document]  |
   |           | encountered                       |                  |
   +-----------+-----------------------------------+------------------+
   | 6         | Extension header too big          | [This document]  |
   +-----------+-----------------------------------+------------------+
   | 7         | Extension header chain too long   | [This document]  |
   +-----------+-----------------------------------+------------------+
   | 8         | Too many extension headers        | [This document]  |
   +-----------+-----------------------------------+------------------+
   | 9         | Too many options in extension     | [This document]  |
   |           |  header                           |                  |
   +-----------+-----------------------------------+------------------+
   | 10        | Option too big                    | [This document]  |
   +-----------+-----------------------------------+------------------+

9.  References

9.1.  Normative References

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC792]   Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <https://www.rfc-editor.org/info/rfc792>.

9.2.  Informative References








Herbert                  Expires 26 August 2024                [Page 43]

Internet-Draft                   IPv4 EH                   February 2024


   [I-D.herbert-eh-inflight-removal]
              Herbert, T., "Infight Removal of IPv6 Hop-by-Hop and
              Routing Headers", Work in Progress, Internet-Draft, draft-
              herbert-eh-inflight-removal-03, 20 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-herbert-eh-
              inflight-removal-03>.

   [I-D.herbert-fast]
              Herbert, T., "Firewall and Service Tickets", Work in
              Progress, Internet-Draft, draft-herbert-fast-07, 7 October
              2023, <https://datatracker.ietf.org/doc/html/draft-
              herbert-fast-07>.

   [I-D.ietf-6man-comp-rtg-hdr]
              Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L.
              Jalil, "The IPv6 Compact Routing Header (CRH)", Work in
              Progress, Internet-Draft, draft-ietf-6man-comp-rtg-hdr-03,
              18 January 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-6man-comp-rtg-hdr-03>.

   [I-D.ietf-6man-eh-limits]
              Herbert, T., "Limits on Sending and Processing IPv6
              Extension Headers", Work in Progress, Internet-Draft,
              draft-ietf-6man-eh-limits-12, 18 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
              limits-12>.

   [I-D.ietf-6man-hbh-processing]
              Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
              Processing Procedures", Work in Progress, Internet-Draft,
              draft-ietf-6man-hbh-processing-13, 18 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              hbh-processing-13>.

   [I-D.ietf-v6ops-hbh]
              Peng, S., Li, Z., Xie, C., Qin, Z., and G. S. Mishra,
              "Operational Issues with Processing of the Hop-by-Hop
              Options Header", Work in Progress, Internet-Draft, draft-
              ietf-v6ops-hbh-10, 16 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
              hbh-10>.










Herbert                  Expires 26 August 2024                [Page 44]

Internet-Draft                   IPv4 EH                   February 2024


   [I-D.li-6man-app-aware-ipv6-network]
              Li, Z., Peng, S., Li, C., Xie, C., Voyer, D., Li, X., Liu,
              P., Liu, C., and K. Ebisawa, "Application-aware IPv6
              Networking (APN6) Encapsulation", Work in Progress,
              Internet-Draft, draft-li-6man-app-aware-ipv6-network-03,
              22 February 2021, <https://datatracker.ietf.org/doc/html/
              draft-li-6man-app-aware-ipv6-network-03>.

   [IANA-EH]  "IPv6 Extension Header Types",
              <https://www.iana.org/assignments/ipv6-parameters>.

   [IANA-PN]  "Assigned Internet Protocol Numbers",
              <https://www.iana.org/assignments/protocol-numbers/
              protocol-numbers.xhtml>.

   [IANA-RH]  "IPv6 Extension Header Types",
              <https://www.iana.org/assignments/ipv6-parameters>.

   [IPNOOP]   Fonseca, R., Manning Porter, G., Katz, R., Shenker, S.,
              and I. Ion Stoica, "IP Options are not an option",
              December 2005,
              <https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-
              2005-24.html>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, DOI 10.17487/RFC2675, August 1999,
              <https://www.rfc-editor.org/info/rfc2675>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/info/rfc3168>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              DOI 10.17487/RFC4302, December 2005,
              <https://www.rfc-editor.org/info/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <https://www.rfc-editor.org/info/rfc4303>.






Herbert                  Expires 26 August 2024                [Page 45]

Internet-Draft                   IPv4 EH                   February 2024


   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
              Control Message Protocol (ICMPv6) for the Internet
              Protocol Version 6 (IPv6) Specification", STD 89,
              RFC 4443, DOI 10.17487/RFC4443, March 2006,
              <https://www.rfc-editor.org/info/rfc4443>.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
              <https://www.rfc-editor.org/info/rfc4821>.

   [RFC5871]  Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
              the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871,
              May 2010, <https://www.rfc-editor.org/info/rfc5871>.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437,
              DOI 10.17487/RFC6437, November 2011,
              <https://www.rfc-editor.org/info/rfc6437>.

   [RFC6438]  Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
              for Equal Cost Multipath Routing and Link Aggregation in
              Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
              <https://www.rfc-editor.org/info/rfc6438>.

   [RFC6864]  Touch, J., "Updated Specification of the IPv4 ID Field",
              RFC 6864, DOI 10.17487/RFC6864, February 2013,
              <https://www.rfc-editor.org/info/rfc6864>.

   [RFC7739]  Gont, F., "Security Implications of Predictable Fragment
              Identification Values", RFC 7739, DOI 10.17487/RFC7739,
              February 2016, <https://www.rfc-editor.org/info/rfc7739>.

   [RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
              "Observations on the Dropping of Packets with IPv6
              Extension Headers in the Real World", RFC 7872,
              DOI 10.17487/RFC7872, June 2016,
              <https://www.rfc-editor.org/info/rfc7872>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node
              Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
              January 2019, <https://www.rfc-editor.org/info/rfc8504>.





Herbert                  Expires 26 August 2024                [Page 46]

Internet-Draft                   IPv4 EH                   February 2024


   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
              <https://www.rfc-editor.org/info/rfc8754>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

   [RFC8883]  Herbert, T., "ICMPv6 Errors for Discarding Packets Due to
              Processing Limits", RFC 8883, DOI 10.17487/RFC8883,
              September 2020, <https://www.rfc-editor.org/info/rfc8883>.

   [RFC8900]  Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
              and F. Gont, "IP Fragmentation Considered Fragile",
              BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
              <https://www.rfc-editor.org/info/rfc8900>.

   [RFC9098]  Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston,
              G., and W. Liu, "Operational Implications of IPv6 Packets
              with Extension Headers", RFC 9098, DOI 10.17487/RFC9098,
              September 2021, <https://www.rfc-editor.org/info/rfc9098>.

   [RFC9268]  Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
              by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
              2022, <https://www.rfc-editor.org/info/rfc9268>.

   [RFC9486]  Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
              In Situ Operations, Administration, and Maintenance
              (IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023,
              <https://www.rfc-editor.org/info/rfc9486>.

   [V6STATE]  Kuerbis, B. and M. Mueller, "The Hidden Standards War:
              Economic Factors Affecting IPv6 Deployment", December
              2020,
              <https://www.emerald.com/insight/content/doi/10.1108/DPRG-
              10-2019-0085/full/html>.

Author's Address

   Tom Herbert
   SiPanda
   Santa Clara, CA,
   United States of America
   Email: tom@herbertland.com






Herbert                  Expires 26 August 2024                [Page 47]