Network Working Group F. L. Templin, Ed. Internet-Draft Boeing Research & Technology Updates: 6864, 8900 (if approved) 29 November 2023 Intended status: Standards Track Expires: 1 June 2024 IPv4 Identification Extension draft-templin-intarea-ipid-ext-25 Abstract The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification field in all packets, but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks. Even for Internet Protocol, version 6 (IPv6), the 32-bit Identification field included when a Fragment Header is present may be smaller than desired for some applications. This specification addresses these limitations by defining an IPv4 header option for Identification Extension. 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 1 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 Templin Expires 1 June 2024 [Page 1] Internet-Draft IP Identification Extension November 2023 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Relation to IPv6 Identification Extension . . . . . . . . . . 3 3. IPv4 ID Extension . . . . . . . . . . . . . . . . . . . . . . 3 4. IPv4 ID Advanced Extension . . . . . . . . . . . . . . . . . 4 5. IPv4 ID (Parcel) Index Extension . . . . . . . . . . . . . . 4 6. IPv4 ID Applications . . . . . . . . . . . . . . . . . . . . 5 7. Destination Qualification . . . . . . . . . . . . . . . . . . 5 8. Packet Too Big (PTB) Extensions . . . . . . . . . . . . . . . 6 9. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 12. Security Considerations . . . . . . . . . . . . . . . . . . . 8 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 14.1. Normative References . . . . . . . . . . . . . . . . . . 8 14.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Internet Protocol, version 4 (IPv4) header includes a 16-bit Identification in all packets [RFC0791], but this length is too small to ensure reassembly integrity even at moderate data rates in modern networks [RFC4963][RFC6864][RFC8900]. This document defines a new option for IPv4 that extends the Identification field to 32-bits (i.e., the same as for IPv6 packets that include a standard Fragment Header [RFC8200]) to support reassembly integrity at higher data rates. When an IPv4 packet includes this "Identification Extension" option, the value encoded in the IPv4 header Identification field represents the 2 least-significant octets while the option encodes the 2 most- significant octets of an extended 4-octet Identification. Nodes that recognize the option employ it for packet identification purposes in general and to fortify the IPv4 reassembly procedure in particular. This specification also supports an "advanced" mode that extends the IPv4 Identification field even further. This format may be useful for networks that engage fragmentation and reassembly at extreme data rates, or for cases when advanced packet Identification uniqueness assurance is critical. Templin Expires 1 June 2024 [Page 2] Internet-Draft IP Identification Extension November 2023 2. Relation to IPv6 Identification Extension As is often the case, extensions intended for IPv4 can be applied in similar fashion as for IPv6 (and vice-versa). The terminology used and the motivation for extending the Identification field for IPv4 is the same as for IPv6 Identification extension as specified in [I-D.templin-6man-ipid-ext]. All normative aspects of the IPv6 specification that can be applied for IPv4 apply also to this document. 3. IPv4 ID Extension IP Identification (IP ID) extension for IPv4 is based on a new IPv4 option [RFC0791]. This new IPv4 ID Extension (IDEXT) Option begins with an option-type octet with "copied flag" set to '1', "option class" set to '0' and "option number" set to TBD (see: IANA Considerations). The option-type octet is followed immediately by an option-length octet set to the constant value '4'. The option-length octet is then followed by a 2-octet "ID Extension" field that (when combined with the 2 least-significant octets found in the IPv4 packet header Identification field) includes the 2 most- significant octets of an extended 4-octet (32-bit) IP ID for the packet. The option format is shown in Figure 1: +--------+--------+--------+--------+ |100[TBD]|00000100| ID Extension | +--------+--------+--------+--------+ Type=TBD Length=4 Figure 1: IPv4 ID Extension (IDEXT) Option When a source wishes to supply a 4-octet extended IP ID for an IPv4 packet, it includes an IDEXT option in the IPv4 packet header options area, i.e., following the same rules as for including any IPv4 option. The source next writes the 2 least-significant octets in the IPv4 header Identification field and writes the 2 most-significant octets in the "ID Extension" field. The source then applies source fragmentation if necessary while including the extended IP ID value. During fragmentation, the source copies the ID Extension option into each resulting fragment and sets or clears the "Don't Fragment (DF)" flag as desired. Templin Expires 1 June 2024 [Page 3] Internet-Draft IP Identification Extension November 2023 The source then forwards each IPv4 packet/fragment to the next hop, where each successive intermediate system will direct them toward the destination. If an intermediate system on the path needs to apply network fragmentation, it copies the IDEXT option into each resulting fragment to provide the destination with the correct reassembly context. 4. IPv4 ID Advanced Extension When a source produces a sustained burst of IPv4 packets for a flow at extreme data rates, (e.g., ~1Tbps) or when the source plans to reset the IP ID starting sequence to a new pseudo-random value frequently, it can optionally extend the IP ID even further by supplying an 8/12/16 octet value instead of a 2/4-octet value. To apply this longer extensions, the source includes an IDEXT option with option-type set to TBD the same as above, but with option-length ("optlen") set to '8', '12' or '16' instead of '4' as shown in Figure 2: +--------+--------+--------+-~~~-+--------+ |100[TBD]| optlen | ID Extension | +--------+--------+--------+-~~~-+--------+ Type=TBD Length=8/12/16 Figure 2: IDEXT Option with Advanced Extension The option-data then includes a 6/10/14-octet ID Extension, with the most significant IP ID octets appearing in the extension in network byte order and with the 2 least significant octets appearing in the IPv4 Identification field. 5. IPv4 ID (Parcel) Index Extension [I-D.templin-intarea-parcels] specifies procedures for fragmenting and reassembling the constituent packets derived from IP parcels that have been opened somewhere along the path. Since each packet derived from the same parcel shares the same Identification value, an ancillary (Parcel) Index field is also necessary to differentiate the packets. [I-D.templin-intarea-parcels] re-purposes the IPv6 Fragment Header 8-bit Reserved field to encode a (Parcel) Index, but the IPv4 header does not provide sufficient space. With reference to Section 3 and Section 4, this document therefore specifies the following IDEXT option format with (Parcel) Index extension: Templin Expires 1 June 2024 [Page 4] Internet-Draft IP Identification Extension November 2023 +--------+--------+--------+-~~~-+--------+--------+ |100[TBD]| optlen | ID Extension | Index | +--------+--------+--------+-~~~-+--------+--------+ Type=TBD Length=5/9/13/17 Figure 3: IDEXT Option with (Parcel) Index Extension When the IPv4 TBD option-length is 5/9/13/17, the option-data instead includes 2/6/10/14 Identification extension octets followed by the (Parcel) Index extension octet. The (Parcel) Index extension octet field names and descriptions appear in [I-D.templin-intarea-parcels]. 6. IPv4 ID Applications [RFC6864] limits the use of the IPv4 ID field to only supporting the fragmentation and reassembly processes. When an IPv4 packet includes a TBD option, however, the source asserts that the IPv4 ID includes a well-managed extended-length value that can satisfy uniqueness properties useful for other purposes. This specification therefore updates [RFC6864] by permitting use of the extended IPv4 ID for purposes other than fragmentation and reassembly support. Note: The IDEXT option-length could conceivably encode any value up to and including 255, however implementations of this specification only honor those values specified in the previous two sections (future specifications may define different values). 7. Destination Qualification The source must have assurance that each destination will recognize and accept the IDEXT option before it can assume the extended IP ID uniqueness properties. This can be through operational assurances or protocol message feedback. An operational assurance example is through application of a common encapsulation format shared by all nodes within a limited domain network [RFC8799] for which recognition of the IDEXT option is mandatory (e.g., see: [I-D.templin-intarea-omni]). The scope of the IDEXT uniqueness then applies only within the boundaries of the limited domain. For open Internetworks and/or other networks with no operational assurances, the source must instead receive continuous feedback proving that the destination recognizes and applies the IDEXT option Templin Expires 1 June 2024 [Page 5] Internet-Draft IP Identification Extension November 2023 as long as the source sends packets/fragments with extended IP IDs at high data rates. (Note that continuous feedback rather than a one- time test is necessary in case the destination is anycast and routing redirects traffic to a new anycast destination that does not recognize the option.) Sources normally set the IDEXT option "option class" to '0' (control) for ordinary packets/fragments. To receive continuous feedback from the destination, the source can periodically set "option class" to '2' in a packet/fragment to be used as a probe. If the source receives an ICMPv4 Parameter Problem message with Code TBD2 [RFC0792], it has assurance that the destination (still) correctly recognizes the option. Destinations that receive IPv4 packets/fragments with an IDEXT option simply ignore the option if they do not recognize it. Destinations that recognize the option instead examine the "option class" value. If the value is '2', the destination returns an ICMPv4 Parameter Problem message with Code TBD2 to the source. The destination then accepts the packet/fragment for further processing. Intermediate systems that do not recognize the IDEXT option may be configured to ignore the option completely without taking the required action of copying the option into each fragment upon fragmentation [RFC7126]. Sources therefore SHOULD NOT set the DF bit to 0 for IPv4 packets that include the IDEXT option on open Internetworks outside of a limited domain [RFC8799]. Note: destinations that recognize and accept the IDEXT option are required to configure an EMTU_R of 65535 octets (see: Section 9). Therefore, sources that receive ICMPv4 Parameter Problem messages with code TBD2 can also regard them as confirmation of the destination's EMTU_R. 8. Packet Too Big (PTB) Extensions When an intermediate system attempts to forward an IP packet that exceeds the next hop link MTU but for which fragmentation is forbidden, it returns an ICMPv6 "Packet Too Big (PTB)" message with Code 0 [RFC8201] or an ICMPv4 "Destination Unreachable - Fragmentation Needed" message [RFC1191] to the source and discards the packet. This always results in wasted transmissions for which the source is required to reduce the size of the packets it is sending and retransmit. Templin Expires 1 June 2024 [Page 6] Internet-Draft IP Identification Extension November 2023 [I-D.templin-6man-ipid-ext] suggests that source and/or network fragmentation should instead be used to ensure that packets are delivered to the destination even if they exceed the path MTU. The document therefore defines new ICMPv6 PTB Code values to monitor and control the fragmentation and reassembly processes. Rather than define corresponding codes for ICMPv4, however, this document requires sources that send packets with IPv4 Identification Extension options to accept and take appropriate actions based on ICMPv6 PTB messages with one of the fragmentation/reassembly Code values defined in [I-D.templin-6man-ipid-ext]. This may require the intermediate or end system that sends the PTB message to employ UDP/ IPv4 encapsulation so that the ICMPv6 message can traverse IPv4 networks. 9. Requirements IPv4 intermediate systems MUST forward without dropping packets with IPv4 option-type TBD while copying the option during network fragmentation. Sources MUST include at most one IPv4 Identification Extension option in each packet. Intermediate systems and destinations SHOULD silently drop packets with multiple options. Destinations that recognize IPv4 option-type TBD MUST accommodate packets that include any extended IP ID format included by the source. Sources MUST transmit and destinations MUST process the octets of the extended IP ID in network byte order with the base IP ID field containing the least significant octets and the ID Extension field containing the most significant octets. Destinations MUST be capable of reassembling packets as large as the minimum Effective MTU to Receive (EMTU_R) specified for IPv4 ([RFC1122], Section 3.3.2). Destinations that accept flows that include extended IP IDs: * MUST configure a minimum EMTU_R of 65535 octets, * SHOULD advertise the largest possible EMTU_R in PTB messages and * MAY advertise a reduced EMTU_R during periods of congestion. Templin Expires 1 June 2024 [Page 7] Internet-Draft IP Identification Extension November 2023 10. Implementation Status In progress. 11. IANA Considerations The IANA is requested to assign a new IPv4 Option "IDEXT" with number "TBD" in the "IP Option Numbers" table in the 'ip-parameters' registry (registration procedures not defined). Two registry entries are inserted, where the first entry sets "Copy" to '1', "Class" to '0', "Number" to TBD and "Name" to "IDEXT" and the next entry sets "Copy" to '1', "Class" to '2', "Number" to TBD an "Name" to "IDEXT". The "Reference" for both entries is set to this document [RFCXXXX]. The IANA is requested to assign a new IPv4 Parameter Problem Code "TBD2" in the "Type 12 - Parameter Problem" table in the 'icmp- parameters-codes' registry (registration procedures IESG Approval or Standards Action). One registry entry is inserted that sets "Code" to "TBD2" and "Description" to "IDEXT Option Recognized". The "Reference" is set to this document [RFCXXXX]. 12. Security Considerations All aspects of IP security apply equally to this document, which does not introduce any new vulnerabilities. Moreover, when employed correctly the mechanisms in this document robustly address known IPv4 reassembly integrity concerns [RFC4963] and also provide an advanced degree of packet Identification uniqueness assurance. 13. Acknowledgements This work was inspired by continued DTN performance studies. Amanda Baber, Tom Herbert and Bob Hinden offered useful insights that helped improve the document. Honoring life, liberty and the pursuit of happiness. 14. References 14.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, . Templin Expires 1 June 2024 [Page 8] Internet-Draft IP Identification Extension November 2023 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, . 14.2. Informative References [I-D.templin-6man-ipid-ext] Templin, F., "IPv6 Identification Extension", Work in Progress, Internet-Draft, draft-templin-6man-ipid-ext-00, 28 November 2023, . [I-D.templin-dtn-ltpfrag] Templin, F., "LTP Fragmentation", Work in Progress, Internet-Draft, draft-templin-dtn-ltpfrag-16, 23 October 2023, . Templin Expires 1 June 2024 [Page 9] Internet-Draft IP Identification Extension November 2023 [I-D.templin-intarea-omni] Templin, F., "Transmission of IP Packets over Overlay Multilink Network (OMNI) Interfaces", Work in Progress, Internet-Draft, draft-templin-intarea-omni-51, 21 November 2023, . [I-D.templin-intarea-parcels] Templin, F., "IP Parcels and Advanced Jumbos (AJs)", Work in Progress, Internet-Draft, draft-templin-intarea- parcels-90, 20 November 2023, . [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, . [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", RFC 6864, DOI 10.17487/RFC6864, February 2013, . [RFC7126] Gont, F., Atkinson, R., and C. Pignataro, "Recommendations on Filtering of IPv4 Packets Containing IPv4 Options", BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 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, . Appendix A. Change Log << RFC Editor - remove prior to publication >> Differences from earlier versions: * First draft publication. Author's Address Templin Expires 1 June 2024 [Page 10] Internet-Draft IP Identification Extension November 2023 Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 United States of America Email: fltemplin@acm.org Templin Expires 1 June 2024 [Page 11]