Network Working Group F. L. Templin, Ed. Internet-Draft Boeing Research & Technology Updates: 6864, 8200, 8900 (if approved) 6 September 2023 Intended status: Standards Track Expires: 9 March 2024 Identification Extension Options for the Internet Protocol draft-templin-intarea-ipid-ext-06 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 intended uses. This specification addresses these limitations by defining both an IPv4 header option and an IPv6 Extended Fragment Header 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 9 March 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 9 March 2024 [Page 1] Internet-Draft IP Identification Extension September 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. IPv4 ID Extension . . . . . . . . . . . . . . . . . . . . . . 4 5. IPv4 ID Hyper-Extension . . . . . . . . . . . . . . . . . . . 5 6. IPv6 ID Extension . . . . . . . . . . . . . . . . . . . . . . 6 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 8. IPv4 ID Applications . . . . . . . . . . . . . . . . . . . . 7 9. IPv4 Parcel Index Extension . . . . . . . . . . . . . . . . . 8 10. IPv6 Network Fragmentation . . . . . . . . . . . . . . . . . 8 11. Packet Too Big (PTB) Extensions . . . . . . . . . . . . . . . 9 12. A Note on Fragmentation Considered Harmful . . . . . . . . . 11 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 11 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 17.1. Normative References . . . . . . . . . . . . . . . . . . 12 17.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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. Hosts and routers that recognize the option employ it for packet identification purposes in general and to fortify the IPv4 reassembly procedure in particular. Templin Expires 9 March 2024 [Page 2] Internet-Draft IP Identification Extension September 2023 This specification also supports a "hyper-extended" mode that extends the Identification field further for both IPv4 and IPv6. This format may be useful for networks that operate at extreme data rates, or for other cases when Identification uniqueness assurance is critical. Together, these extensions ensure robust reassembly integrity as well as Identification uniqueness for the Internet. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the term "IP" to refer generically to either protocol version (i.e., IPv4 or IPv6), and uses the term "IP ID" to refer generically to the IP Identification field whether in simple or (hyper-)extended form. The terms "Maximum Transmission Unit (MTU)", "Effective MTU to Receive (EMTU_R)" and "Maximum Segment Lifetime (MSL)" are used exactly the same as for standard Internetworking terminology. The term "Packet Too Big (PTB)" refers to either an IPv6 "Packet Too Big" [RFC8201][RFC4443] or an IPv4 "Destination Unreachable - Fragmentation Needed" [RFC1191] message. 3. Motivation Studies over many decades have shown that upper layer protocols can achieve greater performance by configuring segment sizes that exceed the path Maximum Transmission Unit (MTU). When the segment size exceeds the path MTU, IP fragmentation at some layer is a natural consequence. However, the 2-octet (16-bit) IPv4 and 4-octet (32-bit) IPv6 Identification fields may be too short to support reassembly integrity at sufficiently high data rates. This specification therefore proposes to fortify the IP ID by extending its length. A recent study [I-D.templin-dtn-ltpfrag] proved that configuring segment sizes that cause IPv4 packets to exceed the path MTU (thereby invoking IPv4 fragmentation and reassembly) provides a multiplicative performance increase at high data rates in comparison with using smaller segment sizes as long as fragment loss is negligible. This contradicts decades of unfounded assertions to the contrary and proves that the original design of the Internet which included fragmentation and reassembly as core functions was the correct one. Templin Expires 9 March 2024 [Page 3] Internet-Draft IP Identification Extension September 2023 An alternative to extending the IP ID was also examined in which IPv4 packets were first encapsulated in IPv6 headers then subjected to IPv6 fragmentation where a 4-octet Identification field already exists. While this IPv4-in-IPv6 encapsulation followed by IPv6 fragmentation also showed a performance increase for larger segment sizes in comparison with using MTU-sized or smaller segments, the magnitude of increase was significantly less than for invoking IP fragmentation directly without first applying encapsulation. Widely deployed implementations also often employ a common code base for both IPv4 and IPv6 fragmentation/reassembly since their algorithms are so similar. It therefore seems reasonable to conclude that IPv4 fragmentation and reassembly can support higher data rates than IPv6 when full (uncompressed) headers are used. In addition to enabling higher data rates in the presence of fragmentation and reassembly, extending the IP ID can enable other important services. For example, an extended IP ID can support a duplicate packet detection service in which the network remembers recent IP ID values for a flow and excludes any packets that repeat recently-used values. An extended IP ID can also provide a packet sequence number that allows communicating peers to exclude any packets with IP ID values outside of a current window as potential spurious transmissions. These and other cases also hold true even if the source frequently resets its starting IP ID sequence numbers to maintain an unpredictable profile. For these reasons, it is clear that a robust IP fragmentation and reassembly service can provide a useful tool for performance maximization in the Internet and that an extended IP ID can provide greater uniqueness assurance. This document therefore presents a means to extend the IP ID to better support these services. 4. IPv4 ID Extension IP ID extension for IPv4 is achieved by introducing a new IPv4 option. This new IPv4 ID Extension (IDEXT) Option begins with an option-type octet with "copied flag" set to '1', "option class" set to '00' and "option number" set to TBD. The option-type octet is followed immediately by an option-length octet set to the constant value '4'. The option-type 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: Templin Expires 9 March 2024 [Page 4] Internet-Draft IP Identification Extension September 2023 +--------+--------+--------+--------+ |100[TBD]|00000100| ID Extension | +--------+--------+--------+--------+ Type=TBD Length=4 Figure 1: IPv4 ID Extension (IDEXT) Option When an IPv4 source node (i.e., an original source or an IPv4 encapsulation ingress) wishes to supply a 4-octet extended IP ID for the packet, it includes an IDEXT option in the IPv4 packet header options area, i.e., based on 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. The source copies the ID Extension option to each resulting fragment and sets or clears the "Don't Fragment (DF)" flag as desired. (In the limiting case, the source can set DF to disable network fragmentation and replicate the conditions experienced for IPv6.) The source then forwards each packet/fragment to the next hop, where IPv4 forwarding will direct them toward the final destination. If an IPv4 router on the path needs to apply network fragmentation, it copies the IDEXT option into each resulting fragment to provide the final destination with the correct reassembly context. 5. IPv4 ID Hyper-Extension When an IPv4 source produces a sustained burst of IPv4 packets that use the same source address, destination address and protocol at extreme data rates (e.g., in excess of 1Tbps), or when the source plans to reset the IP ID starting sequence to a new pseudo-random value frequently, it can optionally "hyper-extend" the IP ID by supplying an 8-octet (64-bit) value instead of a 2/4-octet value. To apply hyper-extension, the source includes an IDEXT option with option-type set to TBD the same as above, but with option-length set to '8' instead of '4' as shown in Figure 2: +--------+--------+--------+--------+ |100[TBD]|00001000| ID Extension | +--------+--------+--------+--------+ | ID Extension | +--------+--------+--------+--------+ Figure 2: IDEXT Option with Hyper-Extension Templin Expires 9 March 2024 [Page 5] Internet-Draft IP Identification Extension September 2023 The option will then include a 6-octet ID Extension, with the 6 most significant IP ID octets appearing in network byte order in the option-data and with the 2 least significant octets appearing in the IPv4 Identification field. The combined 8-octet IP ID can then fit properly within the longest word length for modern 64-bit architectures. 6. IPv6 ID Extension Techniques that improve IPv4 often also apply in a corresponding fashion for IPv6 (and vice-versa). This document therefore defines a new IPv6 Extended Fragment Header that extends the length of the Identification field. The IPv6 Extended Fragment Header is identified by the Next Header type value 'TBD2' (see: IANA Considerations) and the format is shown in Figure 3: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Reserved | Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Identification (12 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPv6 Extended Fragment Header In the above format, the control values in the first four octets are interpreted exactly the same as for the standard IPv6 Fragment Header specified in [RFC8200], while the Identification field is 12 octets in length and encodes a 96-bit value in network byte order. 7. Requirements IPv4 routers MUST forward without dropping any packets with IPv4 option-type TBD while copying the option during network fragmentation, and IPv6 routers MUST forward without dropping any packets with IPv6 HBH Option Type TBD2. Destinations that recognize IPv4 option-type TBD MUST accommodate packets that include all extended and hyper-extended IP ID formats based on any 4-octet or 8-octet value included by the source. Templin Expires 9 March 2024 [Page 6] Internet-Draft IP Identification Extension September 2023 Sources MUST transmit and destinations MUST process the octets of the extended IP ID in network byte order with the base IP header Identification field containing the least significant octets and the ID (Hyper-)Extension field containing the most significant octets. When the ID (Hyper-)Extension field is absent, implementations consider its value to be 0. Implementations should therefore maintain the IP ID as an 8-octet (64-bit) integer with any most significant octets not covered by an extension set to 0. 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) or IPv6 ([RFC8200], section 5). Destinations that recognize extended IP IDs SHOULD configure and advertise the largest possible EMTU_R (65535 octets maximum) and MAY dynamically advertise a reduced EMTU_R during periods of reassembly buffer congestion (see: Section 11). When a destination reassembles an IP packet with an extended IP ID that arrived as fragments, it returns an EMTU_R indication to the source (subject to rate limiting) according to its current reassembly buffer congestion conditions (see: Section 11). While a source continues to receive these indications, it can continue to send fragmented packets no larger than the EMTU_R at rates within the Maximum Segment Lifetime (MSL) wraparound threshold for the extended IP ID length; otherwise, the source must assume the MSL threshold for the non-extended Identification field length [RFC6864]. Option formats supported by this specification include only the mandatory-to-implement (hyper-)extended formats which are differentiated by the option-length value for IPv4 or the extension header type for IPv6. Future documents may specify additional formats with different option length values. Note: IP fragmentation can only be applied for packet lengths up to a maximum of 65535 octets. IP parcels and advanced jumbos provide a means for efficiently packaging and shipping multiple large segments or truly large singleton segments in IP packets that may exceed this size [I-D.templin-intarea-parcels]. 8. 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. Templin Expires 9 March 2024 [Page 7] Internet-Draft IP Identification Extension September 2023 This specification therefore updates [RFC6864] by permitting use of the extended IPv4 ID for purposes other than support for fragmentation and reassembly. 9. IPv4 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 Index field is also necessary to differentiate the packets. The IPv6 Fragment Header includes an 8-bit Reserved field that can be re-purposed to encode an Index, but the IPv4 header does not provide sufficient space. With reference to Section 4 and Section 5, this document therefore specifies the following IPv4 ID Parcel Index extension octet: +-+-+-+-+-+-+-+-+ | Index |P|S| +-+-+-+-+-+-+-+-+ Figure 4: IPv4 ID Parcel Index Extension Octet When option-length is '3', the option-data includes 2 Identification extension octets followed by the Parcel Index extension octet. When option-length is '7', the option-data instead includes 6 Identification extension octets followed by the Parcel Index extension octet. The Parcel Index octet field names and descriptions appear in [I-D.templin-intarea-parcels]. 10. IPv6 Network Fragmentation When an IPv6 router forwards a packet that includes an Extended Fragment Header, it applies (further) fragmentation if the next hop link MTU is insufficient. The presence of the TBD2 Extended Fragment Header therefore provides a "network fragmentation permitted" indication for IPv6 in the same spirit as for IPv4 packets that set the "Don't Fragment (DF)" flag to 0 (conversely, IPv6 routers treat all other packets as DF=1). This allows IPv6 routers to apply fragmentation on packets that already include an Extended Fragment Header, but never to insert a Fragment Header of any kind themselves. Templin Expires 9 March 2024 [Page 8] Internet-Draft IP Identification Extension September 2023 This specification therefore updates [RFC8200] by permitting network fragmentation for IPv6 under the above conditions. 11. Packet Too Big (PTB) Extensions When a node forwards an IP packet that exceeds the next hop link MTU but for which fragmentation is forbidden, it drops the packet and returns a "Packet Too Big (PTB)" message to the original source [RFC1191][RFC4443][RFC8201]. This always results in wasted retransmissions by the source as well as all intermediate systems on the path toward the node with the restricting link. Conversely, when a packet includes an extended IP ID the network will perform fragmentation if necessary allowing the packet to reach the final destination without loss due to a size restriction. While the fragmentation and reassembly processes eliminate wasted retransmissions and can also support significant performance gains through transmissions of upper layer protocol segment sizes that exceed the path MTU, the processes sometimes represent pain points that should be communicated to the original source. The original source should then take measures to reduce the pain. The IPv4 PTB format includes an "unused" field while the IPv6 PTB format includes a "Code" field, with both fields set to the value "0" for ordinary PTB messages. The value "0" signifies a "classic" PTB and always denotes that the subject packet was unconditionally dropped due to a size restriction. For IP packets that include an IP ID Extension option (and also a Fragment Header for IPv6) other PTB unused/Code values are defined as follows: 1 - Sent by an intermediate system when it performs fragmentation on an IP packet that could instead have been fragmented to a smaller fragment size by the original source. The system sends the PTB message subject to rate limiting while still fragmenting and forwarding the packet. The MTU field of the PTB message includes the maximum fragment size that can pass through the restricting link. This value will often be considerably smaller than the maximum packet size that can be reassembled by the final destination. 2 - The same as for value 1, except that the intermediate system drops the packet instead of fragmenting and forwarding. This message type represents a hard error. 3 - Sent by the final destination when it performs reassembly on a packet with an extended IP ID subject to rate limiting. The destination sends the PTB message while still reassembling and accepting the packet. The MTU field of the PTB message includes Templin Expires 9 March 2024 [Page 9] Internet-Draft IP Identification Extension September 2023 the largest possible EMTU_R value under current reassembly buffer congestion constraints. This value must be no smaller than the minimum EMTU_R for the IP protocol version and will often be considerably larger than the path MTU. 4 - The same as for value 3, except that the final destination drops the packet instead of reassembling and accepting. This message type represents a hard error. 5 - Parcel Report - Sent by an intermediate system or final destination in response to an IP parcel that triggered the event (see: [I-D.templin-intarea-parcels]). 6 - Jumbo Report - Sent by an intermediate system or final destination in response to an IP advanced jumbo that triggered the event (see: [I-D.templin-intarea-parcels]). When the original source receives an authentic Code 1 or 2 PTB, it begins to perform source fragmentation using the fragment size indicated in the MTU field which may be smaller than the first hop link MTU. This reduces the burden on intermediate systems in the path which will see a reduced dependence on network fragmentation. When the original source receives a Code 3 or 4 PTB, it limits the size of the packets it sends based on the EMTU_R size found in the MTU field which may be larger than the path MTU. When the original source ceases to receive Code 3 or 4 PTB messages, it must assume that the destination no longer recognizes IP ID extensions and must then impose rate limiting based on the wraparound threshold for a non-extended Identification within the MSL [RFC6864]. These rate limitations can be relaxed when the source can include an integrity check which the destination can verify. When an intermediate system or destination returns a Code 1-6 PTB, it prepares an ICMPv6 PTB message [RFC4443] and with MTU set as discussed above. The node then writes its own IP address as the PTB source and writes the source address of the packet that invoked the report as the PTB destination (for IPv4, the node writes the PTB address as an IPv4-Compatible IPv6 address [RFC4291]). The node next copies as much of the leading portion of the invoking packet as possible (beginning with the IP header) into the "packet in error" field without causing the entire PTB (beginning with the IPv6 header) to exceed 256 octets in length. The node then sets the ICMPv6 Checksum field to 0 instead of calculating and setting a true checksum since the UDP checksum (see below) already provides an integrity check. Templin Expires 9 March 2024 [Page 10] Internet-Draft IP Identification Extension September 2023 Since IPv6 packets cannot transit IPv4 paths, and since middleboxes often filter ICMPv6 messages as they transit IPv6 paths, the node next wraps the ICMPv6 PTB message in UDP/IP headers of the correct IP version with the IP source and destination addresses copied from the PTB and with UDP port numbers set to the OMNI UDP port number [I-D.templin-intarea-omni]. The node then calculates and sets the UDP Checksum (and for IPv4 clears the DF bit). The node finally sends the prepared PTB to the original source. Note: This implies that original sources that send packets with extended IP IDs must be capable of accepting and processing these OMNI protocol UDP messages. A source that sends packets with extended IP IDs must therefore implement enough of the OMNI interface to be able to recognize and process these messages. 12. A Note on Fragmentation Considered Harmful During the earliest days of the Internet, researchers made the profound statement that fragmentation should be deemed "harmful" based on empirical observations in the ARPAnet, DARPA Internet and other internetworks of the day [KENT87]. These observations somehow inspired a discipline known as "Path MTU Discovery" within a new community known as the Internet Engineering Task Force (IETF). In more recent times, the IETF amplified these earlier assertions in "IP Fragmentation Considered Fragile" [RFC8900]. Rather than encourage implementation corrections from the very beginning, however, the IETF somehow forgot that IP fragmentation and reassembly were still fundamental elements of the Internet architecture. This has resulted in a modern Internet where path MTU discovery (including its more recent derivatives) provides a poor service especially for dynamic networks with path MTU diversity. This document offers a better solution based on a properly functioning IP fragmentation and reassembly service as intended by the original architects. This document therefore updates [RFC8900]. 13. Implementation Status In progress. 14. IANA Considerations IANA is requested to assign a new IPv4 Option named "IDEXT" in the 'ip-parameters' registry (registration procedures not defined). The option sets "Copy" to '1', "Class" to '00' and "Number" to TBD. Templin Expires 9 March 2024 [Page 11] Internet-Draft IP Identification Extension September 2023 IANA is further requested to assign a new Protocol Number TBD2 in the in the 'protocol-numbers' registry (registration procedures IESG Approval or Standards Action). The registry sets Decimal to "TBD2", Keyword to "IPv6-XFrag", Protocol to "Extended Fragment Header for IPv6" and IPv6 Extension Header to "Y". The IANA is instructed to assign new Code values in the "ICMPv6 Code Fields: Type 2 - Packet Too Big" registry (registration procedure is Standards Action or IESG Approval). The registry should appear as follows: Code Name Reference --- ---- --------- 0 PTB Hard Error [RFC4443] 1 Fragmentation Needed (soft) [RFCXXXX] 2 Fragmentation Needed (hard) [RFCXXXX] 3 Reassembly Needed (soft) [RFCXXXX] 4 Reassembly Needed (hard) [RFCXXXX] 5 Parcel Report [RFCXXXX] 6 Jumbo Report [RFCXXXX] Figure 5: ICMPv6 Code Fields: Type 2 - Packet Too Big Values (Note: this registry also defines values for the "unused" field of ICMPv4 "Destination Unreachable - Fragmentation Needed" messages.) 15. 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 a known IPv4 reassembly integrity concern [RFC4963] and also provide an advanced degree of packet uniqueness assurance. 16. Acknowledgements This work was inspired by continued DTN performance studies. Bob Hinden and Tom Herbert offered useful insights that helped improve the document. 17. References 17.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . Templin Expires 9 March 2024 [Page 12] Internet-Draft IP Identification Extension September 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, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [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, . 17.2. Informative References [I-D.templin-dtn-ltpfrag] Templin, F., "LTP Fragmentation", Work in Progress, Internet-Draft, draft-templin-dtn-ltpfrag-10, 5 May 2023, . Templin Expires 9 March 2024 [Page 13] Internet-Draft IP Identification Extension September 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-31, 5 July 2023, . [I-D.templin-intarea-parcels] Templin, F., "IP Parcels and Advanced Jumbos", Work in Progress, Internet-Draft, draft-templin-intarea-parcels- 67, 30 August 2023, . [KENT87] Kent, C. and J. Mogul, ""Fragmentation Considered Harmful", SIGCOMM '87: Proceedings of the ACM workshop on Frontiers in computer communications technology, DOI 10.1145/55482.55524, http://www.hpl.hp.com/techreports/ Compaq-DEC/WRL-87-3.pdf.", August 1987. [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, DOI 10.17487/RFC4963, July 2007, . [RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4 Options", RFC 6814, DOI 10.17487/RFC6814, November 2012, . [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, . [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: Templin Expires 9 March 2024 [Page 14] Internet-Draft IP Identification Extension September 2023 * First draft publication. Author's Address Fred L. Templin (editor) Boeing Research & Technology P.O. Box 3707 Seattle, WA 98124 United States of America Email: fltemplin@acm.org Templin Expires 9 March 2024 [Page 15]