Network Working Group T. Herbert Internet-Draft SiPanda Intended status: Standards Track 16 December 2023 Expires: 18 June 2024 IPv4 Extension Headers and Flow Label draft-herbert-ipv4-eh-02 Abstract This specification defines extension headers for IPv4 and a definition of an IPv4 flow label. The goal is to provide a uniform and feasible method of extensibility that is common between IPv4 and IPv6. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 June 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Herbert Expires 18 June 2024 [Page 1] Internet-Draft IPv4 EH December 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. IPv4 extension headers . . . . . . . . . . . . . . . 4 1.1.2. IPv4 flow labels . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. IPv4 extension headers . . . . . . . . . . . . . . . . . . . 5 2.1. General Requirements . . . . . . . . . . . . . . . . . . 6 2.2. Extension Header Order . . . . . . . . . . . . . . . . . 7 2.3. Extension Header Options . . . . . . . . . . . . . . . . 7 2.4. Hop-by-Hop Options Header . . . . . . . . . . . . . . . . 8 2.5. Destination Options Header . . . . . . . . . . . . . . . 8 2.6. Routing Header . . . . . . . . . . . . . . . . . . . . . 9 2.7. Fragment Header . . . . . . . . . . . . . . . . . . . . . 9 2.8. Interaction with standard IPv4 mechanisms . . . . . . . . 10 2.8.1. IPv4 options and IPv4 extension headers . . . . . . . 10 2.8.2. IPv4 fragmentation and IPv4 extension headers . . . . 10 2.9. Extension Header Limits . . . . . . . . . . . . . . . . . 11 3. ICMPv4 Errors for Extension Headers . . . . . . . . . . . . . 12 3.1. Parameter Problem Codes . . . . . . . . . . . . . . . . . 12 3.2. Destination Unreachable codes . . . . . . . . . . . . . . 14 4. No Next Header . . . . . . . . . . . . . . . . . . . . . . . 15 5. The IPv4 flow label . . . . . . . . . . . . . . . . . . . . . 15 5.1. Sender Requirements . . . . . . . . . . . . . . . . . . . 15 5.2. Receiver Requirements . . . . . . . . . . . . . . . . . . 16 6. Deployability Considerations . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8.1. IPv4 Extension Header types . . . . . . . . . . . . . . . 17 8.2. Destination Options and Hop-by-Hop Options . . . . . . . 18 9. ICMP Parameters . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Parameter Problem codes . . . . . . . . . . . . . . . . . 18 9.2. Destination Unreachable codes . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction This specification defines extension headers for IPv4 as well as an IPv4 flow label. The motivation is to provide extensible protocol mechanisms in IPv4 that are unified with IPv6, thus leveraging common protocol and implementation for extensibility between the two versions of the Internet Protocol. Additionally, this specification defines ICMPv4 messages related to extension headers that are cognates of corresponding ICMPv6 messages [RFC8883]. Herbert Expires 18 June 2024 [Page 2] Internet-Draft IPv4 EH December 2023 The specification allows the core extension headers defined in [RFC8200] to be used with IPv4. These extension headers include Hop- by-Hop Options, Destination Options, Routing Header, and Fragment Header. Note that Authentication Header [RFC4302] and Encapsulating Security Payload [RFC4303] are already usable with IPv4. Additionally, No Next Header (protocol number 59) [RFC8200] is specified to be usable in IPv4 packets. The IPv4 flow label is similarly derived from the definition of the IPv6 flow label. There is no flow label defined in the IPv4 header [RFC791], however under specific circumstances this specification allows the sixteen bit Identification field may safely be used as a flow label. 1.1. Motivation IPv6 is intended to become the standard protocol of the Internet, however it is clear that there is a large segment of users that will be using IPv4 for the foreseeable future. This is particularly true in many enterprises where a business case for transitioning to IPv6 hasn't yet emerged [V6STATE]. In lieu of sun-setting IPv4 and expecting all users to move to IPv6 in some time frame that is unlikely to be met, this specification suggests an alternative which is to extend IPv4 with IPv6 features. The idea is to "backport" useful features of IPv6 into IPv4, essentially making IPv4 look more like IPv6. The rationale for this: 1. Users benefit from forward looking features being actively defined and developed for IPv6 without requiring them to immediately transition to IPv6. 2. Encourages common implementation of protocol features that can be shared between IPv6 and IPv4. 3. In making IPv4 look more like IPv6, the work required to complete a future transition to IPv6 may be reduced or simplified. Herbert Expires 18 June 2024 [Page 3] Internet-Draft IPv4 EH December 2023 Various standards and proposals using IPv6 extension headers are currently being deployed or discussed in IETF. These include Segment Routing Header [RFC8754], Compressed Routing Header [I-D.bonica-6man-comp-rtg-hdr], Path MTU Option [RFC9268], In-situ OAM [RFC9486], Service-aware IPv6 Network [I-D.li-6man-app-aware-ipv6-network], and Firewall and Service Tickets [I-D.herbert-fast]. These protocols leverage the extensibility mechanism of extension headers defined for IPv6. All of these proposals, in some form, could be of value for use with IPv4, however IPv4 does not have an extensibility mechanism that meets the requirements for supporting them. Of particular interest is enabling use of the Fragment Header in IPv4 for IP fragmentation. While IPv4 includes fragmentation as part of the core protocol, it uses a sixteen bit Identification value that is considered too small and not sufficiently robust [RFC8900]. The Fragment Header defines a thirty-two bit Identification field that addresses this concern if the Fragment Header can be used with IPv4 to perform fragmentation. The document enables IPv4 packets to carry extension headers in the same manner that IPv6 packets can carry extension headers including Hop-by-Hop and Destination options. In doing so, the various extensions and options defined for IPv6 can be used with IPv4. In many cases, such as Fragment Header, IOAM and Path MTU Hop-by-Hop options, extension headers or options are mostly protocol agnostic and would be applicable and usable with IPv4 with little or no change. In other cases, such as segment routing, the extension might be IPv6 specific, for example the segment routing header contains a list of IPv6 addresses. With some modification to the extension header definition, it is conceivable that these may work with IPv4. For instance, in the case of segment routing, the routing header could be adapted for use with IPv4 by defining a routing header format that contains IPv4 addresses instead of IPv6 addresses. 1.1.1. IPv4 extension headers IPv4 options were defined in [RFC791] as the means of extending the IP protocol. IPv4 options have not been successful. Early router implementations, and even those today, either don't process IPv4 options or relegate them to a slow path effectively making them unusable for serious applications. IPv4 options are limited to forty bytes length and, unlike TCP options, no IP options have been defined that are critical to communications. The upshot is that IPv4 options have long not been considered an option for deployment [IPNOOP]. Herbert Expires 18 June 2024 [Page 4] Internet-Draft IPv4 EH December 2023 IPv6 took a different approach. Extensibility of IPv6 is provided by extension headers. Optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet [RFC8200]. IPv6 extension headers have had mixed success in deployment, especially in the open Internet because some intermediate devices have trouble processing them [RFC7872] [RFC9098]. There is ongoing work to address the deployability of IPv4 extension headers [I-D.ietf-6man-eh-limits] [I-D.ietf-6man-hbh-processing]. Using extension headers with IPv4 is logically straightforward. The IPv4 Protocol field is effectively re-designated to be a Next Header field with the same meaning and semantics as the IPv6 Next Header field. In this manner, an IPv4 packet can contain IPv6 extension headers that are recast as IPv4 extension headers. These include Hop-by-Hop Options, Routing Header, Fragment, Destination Options, Authentication, and Encapsulating Security Payload. In cases where an extension header contains IPv6 specific information, the extension header can be adapted for use with IPv4. For instance, a Routing Header carrying IPv6 addresses to visit could be adapted to carry IPv4 addresses. 1.1.2. IPv4 flow labels IPv6 [RFC8200] introduced the concept of a flow label that has proven quite useful for flow classification, such as that needed by Equal- Cost Multipath (ECMP). The base IPv4 header does not have reserved bits that could be allocated as a flow label, however this specification allows the sixteen bit Identification field to be used as a flow label in atomic datagrams [RFC6864]. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. IPv4 extension headers IPv4 extension headers are optional internet-layer information encoded in separate headers that may be placed between the IPv4 header and the upper-layer header in a packet. IPv4 extension headers are based on IPv6 extension headers and share the same basic properties and semantics [RFC8200]. Extension headers are numbered from IANA IP Protocol Numbers [IANA-PN], the same values SHOULD be used for IPv4 and IPv6. When processing a sequence of Next Header values in an IPv4 packet, the Herbert Expires 18 June 2024 [Page 5] Internet-Draft IPv4 EH December 2023 first one that is not an extension header [IANA-EH] indicates that the next item in the packet is the corresponding upper-layer header. A special "No Next Header" value is used if there is no upper-layer header (protocol number 59 [RFC8200]). As illustrated in the examples below, an IPv4 packet MAY carry zero, one, or more extension headers, each identified by Protocol field of the IPv4 header or the Next Header field of a preceding extension header: +---------------+------------------------ | IPv4 header | TCP header + data | | | Protocol = | | TCP | +---------------+------------------------ +---------------+----------------+------------------------ | IPv4 header | Hop-by-Hop | TCP header + data | | | | Protocol = | Next Header = | | Hop-by-Hop | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | IPv4 header | Hop-by-Hop | Fragment header | fragment of TCP | | | | header + data | Protocol = | Next Header = | Next Header = | | Hop-by-Hop | Fragment | TCP | +---------------+----------------+-----------------+----------------- 2.1. General Requirements IPv4 extension headers normatively assume the requirements of IPv6 extension headers as defined in Section 4 of [RFC8200], with the following modifications: * References to the IPv6 header are replaced by references to the IPv4 header. * ICMP errors sent in the course of processing extension headers use ICMPv4 instead of ICMPv6. Applicable ICMPv4 errors for extension header processing are specified in Section 3. * The IPv4 header Protocol field assumes the same role and semantics with respect to extension headers as the IPv6 Next Header field. Herbert Expires 18 June 2024 [Page 6] Internet-Draft IPv4 EH December 2023 * The Hop-by-Hop Options header is used to carry optional information that MAY be examined and processed by any node along a packet's delivery path. * If a legacy IPv4 destination node, one that does not support IPv4 extension headers, receives a packet with extension headers then the packet will be processed as having an unknown protocol. It is expected that the packet will be discarded and an ICMP error may be generated. * Extension headers or options that carry IPv6 specific data or are otherwise specific to IPv6 MUST NOT be used with IPv4 (Segment Routing [RFC8754] for example). IPv4 variants of these may be defined if achieving the same functionality in IPv4 is desirable. * References to the Payload Length, for instance in reassembly procedures, are reinterpreted as being the computed IPv4 payload length (i.e. IPv4 Total Length minus the length of the IPv4 header). 2.2. Extension Header Order IPv4 extension headers have the same RECOMMENDED ordering as that for IPv6 Section 4.1 of [RFC8200]. IPv4 header Hop-by-Hop Options header Destination Options header (before Routing header) Routing header Fragment header Authentication header Encapsulating Security Payload header Destination Options header (after Routing header) Upper-Layer header 2.3. Extension Header Options The Hop-by-Hop Options header and the Destination Options header carry a variable number of "options" that are type-length-value (TLV). IPv4 Hop-by-Hop and Destination options use the same encoding and have the same requirements as IPv6 Options described in Section 4.2 of [RFC8200]. Note that Pad1 and PadN are defined by this document as IPv4 padding options with same types numbers as those in IPv6. Herbert Expires 18 June 2024 [Page 7] Internet-Draft IPv4 EH December 2023 2.4. Hop-by-Hop Options Header The format and semantics of IPv4 Hop-by-Hop Options are the same as those defined for IPv6 in Section 4.3 of [RFC8200]. IPv4 variants of Ipv6 Hop-by-Hop Options can be defined with the appropriate modifications to work with IPv6. As an example, consider the Path MTU Option [RFC9268]. The Path MTU option is mostly independent of IPv6 as the concept of MTU is independent of the IP protocol version and the contents and processing of the option are agnostic to the protocol as well. Perhaps the only material difference between a Path MTU option for IPv4 and IPv6 is that smaller MTU values can be reported in the IPv4 variant (the minimum MTU in IPv6 is 1280 bytes, and in IPv6 the minimum MTU is 576 bytes). Enabling the Path MTU option for use in IPv4 should be straightforward. Other than Pad1 and PadN, this specification does not specify any IPv4 Hop-by-Hop options. 2.5. Destination Options Header The format and semantics of IPv4 Destination Options are the same as those defined for IPv6 in Section 4.6 of [RFC8200]. IPv4 variants of IPv6 Destinations Options can be defined with the appropriate modifications to work with IPv6. As an example, consider the Jumbo Payload option [RFC2675]. The Jumbo Payload option is mostly independent of IPv6. The requirements for the option can be adapted from those in Section 3 of [RFC2675] where instead of the IPv6 Payload Length being zero, the IPv4 Total Length is set to the length of the IPv4 header. The value in the Jumbo Payload Option would be the length of the payload following the IPv4 header so that the total length of the packet is the value in the IPv4 Total Length (the length of the IPv4 header) plus the value in the Jumbo Payload option. If the Jumbo Payload option processing results in an ICMP error then an appropriate ICMPv4 message is sent (these ICMP messages would have the corresponding types and codes as specified in [RFC2675]). Other than Pad1 and PadN, this specification does not specify any IPv4 Destination options. Herbert Expires 18 June 2024 [Page 8] Internet-Draft IPv4 EH December 2023 2.6. Routing Header Various types of Routing header types should be adaptable for use with IPv4 by defining carrying IPv4 addresses in the route list instead of IPv6 addresses. This specification does not define any Routing Header types that work with IPv4. 2.7. Fragment Header The format and semantics of the IPv4 Fragment Header are the same as those in Section 4.5 of [RFC8200]. An advantage of using the IPv4 Fragment Header over standard IPv4 fragmentation is the Identification fields is thirty-two bits instead of sixteens bits; this addresses some know issues with the small sixteen bit identification field in IPv4 [RFC8900]. Fragmentation and reassembly using the IPv4 Fragment Header follow the procedures in Section 4.5 of [RFC8200] with the following adaptations for use with IPv4. * Similar to IPv4, fragmentation using IPv4 Fragment Header is only performed by the source node. * References to setting the Payload Length field in the IPv6 header are interpreted to be setting the Total Length in the IPv4 header taking into account the IPv4 header length. * When creating or modifying IPv4 extension headers in packets, the IPv4 header checksum MUST be set correctly. * Different fragment packets MAY contain different IPv4 options. In the reassembled packet, the IPv4 options are taken from the first fragment packet (the one with fragment offset of zero). * Different fragment packets MAY contain different extension headers preceding the fragment header. In the reassembled packet, the extension headers preceding the fragment header are taken from the first fragment packet (the one with fragment offset zero). * If reassembly results in an ICMP error message being sent, an ICMPv4 message is sent [RFC792] with the corresponding codes and type as those sent for IPv6 [RFC8200]. * If the first fragment does not include all headers through an Upper-Layer header, then that fragment should be discarded and an ICMP Parameter Problem for IPv4, Code 3, message should be sent to the source of the fragment, with the Pointer field set to zero. Herbert Expires 18 June 2024 [Page 9] Internet-Draft IPv4 EH December 2023 * An original packet is reassembled only from fragment packets that have the same IPv4 Source Address, IPv4 Destination Address, and Fragment Identification. 2.8. Interaction with standard IPv4 mechanisms IPv4 extension headers may be used concurrently with IPv4 mechanisms such as IPv4 options and IPv4 fragmentation. This section discusses the interactions. 2.8.1. IPv4 options and IPv4 extension headers An IPv4 packet MAY contain both IPv4 options and extension headers. IPv4 options are independent of IPv4 extension headers. IPv4 options MUST be processed before processing any extension headers per normal requirements of processing the IP header before the IP payload. 2.8.2. IPv4 fragmentation and IPv4 extension headers An IPv4 packet MAY be fragmented both by using a Fragment extension header as well as by standard IPv4 fragmentation. The Fragment header can only be set at the source, however intermediate devices can fragment packets using standard IPv4 fragmentation. Standard IPv4 fragmentation at a source node MUST be done only after any extension headers are set in a packet or the packet was fragmented using the Fragment header. Specifically, fragmentation using the extension header MUST NOT be done on packet fragments created by standard IPv4 fragmentation. However, a packet fragment that contains a Fragment header MAY itself be fragmented by standard IPv4 fragmentation. There is no correlation between standard IPv4 fragmentation and the IPv4 Fragment header, the fragment identification number space for each are unrelated and reassembly procedures are independent. At a destination, if a received packet was fragmented by standard IPv4 fragmentation then it MUST be reassembled before processing any IPv4 extension headers. This requirement ensures that standard IPv4 reassembly is done before reassembly for the Fragment header. If an IPv4 packet containing Hop-by-Hop options is fragmented using standard IPv4 fragmentation, the Hop-by-Hop options are not set in each of the packet fragments. An intermediate node MAY process the Hop-by-Hop options in the first fragment if the complete Hop-by-Hop extension header is contained within the fragment. If the Fragment header is used with IPv4 then the DF bit (Don't Fragment) bit SHOULD be set and Path MTU discovery mechanisms SHOULD be used [RFC4821]. Herbert Expires 18 June 2024 [Page 10] Internet-Draft IPv4 EH December 2023 It is RECOMMENDED to only use IPv4 extensions in atomic datagrams. Atomic datagrams [RFC6864] are IPv4 packets for which the Don't Fragment bit set, More Fragment bit is not set, and Fragment Offset is zero. In this case the packet will not be subject to IPv4 fragmentation, the Fragment header can alternatively be used for fragmentation. 2.9. Extension Header Limits [I-D.ietf-6man-eh-limits] describes the use of limits in processing IPv6 extension headers in order to protect nodes from excessive extension header options. These limits are adapted for applicability with IPv4 extension headers. Limits on IPv4 extension headers fall into the following categories: * Limits on extension header length * Limits on option length * Limits on number of extension headers * Limits on number of options * Limits on padding for extension headers with options * Limits on the length of the IPv4 header chain With the exception of the limit on the length of the IPV4 header chain, the requirements in each of these categories are the same as those defined for IPv6 extension headers in [I-D.ietf-6man-eh-limits] since these limits are independent of the IPv6 protocol. When a limit is exceeded at a receiving node and the requirements specify that an ICMP message may be sent, and ICMPv4 message is used with the type as code Section 3 specified for the associated limit in [I-D.ietf-6man-eh-limits]. The "IPv4 header chain" consists of the IPv4 header and the set of following IPv4 Extension Headers that precede the upper layer in a packet. The limits and requirements for the length of the IPv6 header chain in [I-D.ietf-6man-eh-limits] are adapted for IPv4 Extension Headers as: * A sending source host SHOULD NOT send a packet with an IPv4 header chain larger than 104 bytes unless it has explicit knowledge that all possible routers, intermediate nodes, and the destination host in the path are able to process a larger IPv4 header chain. If a packet contains an IPsec header then this limit only applies Herbert Expires 18 June 2024 [Page 11] Internet-Draft IPv4 EH December 2023 through the end of the IPsec header (the IPsec header obfuscates following headers so that they are unreadable by nodes in the path). * A receiving host or intermediate node MAY set a limit on the maximum length of the IPv4 header chain. If the limit is set then it SHOULD be greater than or equal to 104 bytes. If a packet is received and the aggregate length of the IPv4 header chain exceeds the limit, then the receiving node SHOULD discard the packet and MAY send an ICMP Parameter Problem message with code 7 (Extension Header Chain Too Long) to the packet's source address. * If a router needs to parse the transport layer, for instance to deduce the transport layer port numbers, it MUST be able to correctly forward packets that contain an IPv6 header chain of 104 or fewer bytes. 3. ICMPv4 Errors for Extension Headers ICMP errors are defined to be sent in response to errors that occur in processing IPv4 extension headers. Six ICMPv4 Parameter Problem codes are defined and one Destination Unreachable code is defined. These codes are adaptations of ICMPv6 codes defined in [RFC4443] and [RFC8883]. 3.1. Parameter Problem Codes The format for ICMP Parameter Problem errors related to extension header employs a multi-part ICMPv4 message format as defined in [RFC4884]. The extended structure contains a pointer to the octet beyond the limit. The format of the ICMPv4 Parameter Problem for extension headers is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | Length | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + leading octets of original datagram | | | | // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Herbert Expires 18 June 2024 [Page 12] Internet-Draft IPv4 EH December 2023 IPv4 Fields: * Destination Address: Copied from the Source Address field of the invoking packet. ICMPv4 Fields: * Type * 12 (Parameter Problem Message) * Code (pertinent to this specification) 3 - Erroneous header field encountered 4 - Unrecognized Next Header type encountered 5 - Unrecognized IPv4 option encountered 6 - Extension header too big 7 - Extension header chain too long 8 - Too many options in extension header * Length Length of the padded "original datagram" field, measured in 32-bit word * Pointer Identifies the octet offset within the invoking packet where the error was detected. Codes 3, 4, and 5 are analogues of ICMPv6 Parameter Problem codes 0, 1, and 2 defined for IPv6 in [RFC4443]. Operation and semantics of these codes are the same as their counterparts in [RFC4443] with the following differences: * The multi-part ICMP format of [RFC4884] is used and its fields are set appropriately. * The pointer to the offending byte in the invoking packet is contained in the 32 bit Pointer field in the extended format. Herbert Expires 18 June 2024 [Page 13] Internet-Draft IPv4 EH December 2023 Codes 6, 7, and 8 are analogues of Parameter Problem codes 4, 5, and 6 defined for IPv6 in [RFC8883]. Operation and semantics of these codes are the same as their counterparts in [RFC4443] with the following differences: * The multi-part ICMP format of [RFC4884] is used and its fields are set appropriately. * The pointer to the offending byte in the invoking packet is contained in the 32 bit Pointer field in the extended format. 3.2. Destination Unreachable codes This specification defines one IPv4 Destination Unreachable code for aggregate header limits being exceeded as described in [RFC8883]. The error for aggregate header limits employs a multi-part ICMPv4 message format as defined in [RFC4884]. The extended structure contains a pointer to the octet beyond the limit. The format of the ICMPv4 message for an aggregate header limit exceeded is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | unused | Length | unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internet Header + leading octets of original datagram | | | | // | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Fields: * Destination Address Copied from the Source Address field of the invoking packet. ICMPv4 Fields: * Type 3 (Destination Unreachable Message) Herbert Expires 18 June 2024 [Page 14] Internet-Draft IPv4 EH December 2023 * Code (pertinent to this specification) 16 - Headers too long * Length Length of the padded "original datagram" field, measured in 32- bit words. * Pointer Identifies the octet offset within the invoking packet where the error was detected. Code 16 is an analogue of Destination Unreachable code 8 defined in [RFC8883]. Operation and semantics of the code should be the same as the counterpart in [RFC8883]. 4. No Next Header The value 59 MAY be set in the Protocol field of the IPv4 header or in the Next Header field of an IPv4 extension header. This indicates that there is nothing following that header. The semantics of setting this value are the same as that described in [RFC8200] with adaptation for use with IPv4. If the Total Length field of the IPv4 header indicates the presence of octets past the end of a header who's Next Header field contains 59, those octets must be ignored and passed on unchanged if the packet is forwarded. 5. The IPv4 flow label The Identification field of the IPv4 header is re-purposed to be the IPv4 flow label in atomic datagrams. As stated in [RFC6864]: ">> Originating sources MAY set the IPv4 ID field of atomic datagrams to any value." This specification allows the IPv4 ID to be used as a flow label in atomic datagrams where (DF==1) and (MF==0) and (frag_offset==0). 5.1. Sender Requirements An origin host MAY set the IPv4 Identification field as a flow label in atomic datagram packets. The IPv4 flow label is set following the same procedures for setting the IPv6 flow label as described in [RFC6437] with the following modifications: * The Identification field MUST only be used as a flow label in Herbert Expires 18 June 2024 [Page 15] Internet-Draft IPv4 EH December 2023 atomic datagrams. That is Don't Fragment (DF) bit MUST be set, More Fragment (MF) bit MUST NOT be set, and Fragment Offset MUST be zero. * If the IPv4 Identification field is not used as a flow label in atomic fragments, the Identification field MUST be set to zero. * Only stateless flow labels can be set. * The value to set, e.g. from a hash computation over packet headers, is truncated to sixteen bits (the size of the Fragment Identification field). * Intermediate nodes MUST NOT set the Fragment Identification field in atomic datagrams. 5.2. Receiver Requirements Receivers, including routers and intermediate hosts, MAY process a non-zero Identification field in the IPv4 header of atomic datagrams as being a flow label. The IPv4 flow label for instance can be used as input to ECMP as described in [RFC6438]. If the Identification field is zero or the packet is not an atomic datagram (either the More Fragment bit is set, the Don't Fragment bit is not set, or Fragment Offset is non-zero) then the Identification field MUST NOT be considered as a flow label. 6. Deployability Considerations If a legacy host device receives an IPv4 packet with IPv4 extension headers, the packet will be treated as having an unknown protocol and should be dropped. Intermediate devices might also see packets with a protocol unknown to them and will forward the packet inasmuch as they would forward any packet with an unknown protocol. In the Internet, it is well known that there are some intermediate nodes that will drop packets with protocols that are unknown to them (firewalls would commonly do this for instance). Therefore, it is unlikely that packets with IPv4 extension headers can be ubiquitously deployed over the Internet. Herbert Expires 18 June 2024 [Page 16] Internet-Draft IPv4 EH December 2023 In a limited domain [RFC8799], an operator would have control over intermediate nodes and could ensure that at a minimum they properly forward packets with IPv4 extension headers. Routers in a limited domain can be updated to process IPv4 Hop-by-Hop Options or Routing headers to provide the functionality of features like IOAM and Segment Routing in IPv4. Similarly, they could be updated to support the IPv4 flow label to provide flow based ECMP in the same manner that the IPv6 flow label is used for ECMP [RFC6438]. 7. Security Considerations This specification enables use of IPv6 extension headers in IPv4. Related security mechanisms of IPv6 extension headers can be applied for use with IPv4 extension headers. The IPv4 flow label has similar security properties as the IPv6 flow label. 8. IANA Considerations 8.1. IPv4 Extension Header types In the "Internet Protocol Version 4 (IPv4) Parameters", registry IANA is requested to create the "IPv4 Extension Headers Types" sub- registry. The initial entries are for the core extension header types defined in [RFC8200]. Herbert Expires 18 June 2024 [Page 17] Internet-Draft IPv4 EH December 2023 +----------+--------------------------+----------------------------+ | Protocol | Description | Reference | | number | | | +----------+--------------------------+----------------------------+ | 0 | IPv4 Hop-by-Hop Options | [This document] | | | | [RFC8200] | +----------+--------------------------+----------------------------+ | 43 | Routing Header for IPv4 | [This document] | | | | [RFC8200] | +----------+--------------------------+----------------------------+ | 44 | Fragment Header for IPv4 | [This document] | | | | [RFC8200] | +----------+--------------------------+----------------------------+ | 50 | Encapsulating Security | [RFC4303] | | | Payload | | +----------+--------------------------+----------------------------+ | 51 | Authentication Header | [RFC4302] | | | | | +----------+--------------------------+----------------------------+ | 60 | Destination Options for | [This document] | | | IPv4 | [RFC8200] | +----------+--------------------------+----------------------------+ 8.2. Destination Options and Hop-by-Hop Options In the "Internet Protocol Version 4 (IPv4) Parameters" registry, IANA is requested to create the "Destination Options and Hop-by-Hop Options" sub-registry. The initial entries consist of Pad1 and PadN options. ------------+------------------+----------------+------------------+ | Hex value | Binary value | Description | Reference | | | act | chg | rest | | | +-----------+-----+-----+------+----------------+------------------+ | 0x00 | 00 | 0 | 0000 | Pad1 | [This document] | | | | | | | [RFC8200] | +-----------+-----+-----+------+----------------+------------------+ | 0x01 | 00 | 0 | 0000 | PadN | [This document] | | | | | | | [RFC8200] | +-----------+-----+-----+------+----------------+------------------+ 9. ICMP Parameters 9.1. Parameter Problem codes IANA is requested to assign the following codes in "ICMP Type Numbers" for type 12 "Parameter Problem": Herbert Expires 18 June 2024 [Page 18] Internet-Draft IPv4 EH December 2023 3 - Erroneous header field encountered 4 - Unrecognized Next Header type encountered 5 - Unrecognized IPv4 option encountered 6 - Extension header too big 7 - Extension header chain too long 8 - Too many options in extension header 9.2. Destination Unreachable codes IANA is requested to assign the following codes in "ICMP Type Numbers" for type 3 "Destination Unreachable": 16 - Headers too long 10. References 10.1. Normative References [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . 10.2. Informative References [I-D.bonica-6man-comp-rtg-hdr] Bonica, R., Kamite, Y., Alston, A., Henriques, D., and L. Jalil, "The IPv6 Compact Routing Header (CRH)", Work in Progress, Internet-Draft, draft-bonica-6man-comp-rtg-hdr- 31, 23 June 2023, . [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-eh-limits] Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-11, 30 November 2023, . Herbert Expires 18 June 2024 [Page 19] Internet-Draft IPv4 EH December 2023 [I-D.ietf-6man-hbh-processing] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", Work in Progress, Internet-Draft, draft-ietf-6man-hbh-processing-12, 21 November 2023, . [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", . [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, . [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 18 June 2024 [Page 20] Internet-Draft IPv4 EH December 2023 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, . [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, . [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, . [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [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, . Herbert Expires 18 June 2024 [Page 21] Internet-Draft IPv4 EH December 2023 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [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 18 June 2024 [Page 22]