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, . [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . 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, . [I-D.herbert-fast] Herbert, T., "Firewall and Service Tickets", Work in Progress, Internet-Draft, draft-herbert-fast-07, 7 October 2023, . [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, . [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, . [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, . [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, . 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, . [IANA-EH] "IPv6 Extension Header Types", . [IANA-PN] "Assigned Internet Protocol Numbers", . [IANA-RH] "IPv6 Extension Header Types", . [IPNOOP] Fonseca, R., Manning Porter, G., Katz, R., Shenker, S., and I. Ion Stoica, "IP Options are not an option", December 2005, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, DOI 10.17487/RFC2675, August 1999, . [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, . [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, . [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, . 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, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871, May 2010, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, . [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, . [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013, . [RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016, . [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, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, . 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, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to Processing Limits", RFC 8883, DOI 10.17487/RFC8883, September 2020, . [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, . [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, . [RFC9268] Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop- by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August 2022, . [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, . [V6STATE] Kuerbis, B. and M. Mueller, "The Hidden Standards War: Economic Factors Affecting IPv6 Deployment", December 2020, . Author's Address Tom Herbert SiPanda Santa Clara, CA, United States of America Email: tom@herbertland.com Herbert Expires 26 August 2024 [Page 47]