Network Working Group F. L. Templin, Ed. Internet-Draft Boeing Research & Technology Updates: 8200, 8900 (if approved) 30 November 2023 Intended status: Standards Track Expires: 2 June 2024 IPv6 Extended Fragment Header draft-templin-6man-ipid-ext-02 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 IPv6 Destination Option for an Extended Fragment Header that includes a 64-bit Identification field; it further defines control messaging services for fragmentation and reassembly congestion management. 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 2 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. Templin Expires 2 June 2024 [Page 1] Internet-Draft IPv6 Extended Fragment Header November 2023 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. IPv6 Extended Fragment Header . . . . . . . . . . . . . . . . 5 5. Destination Qualification . . . . . . . . . . . . . . . . . . 7 6. IPv6 Network Fragmentation . . . . . . . . . . . . . . . . . 7 7. Packet Too Big (PTB) Extensions . . . . . . . . . . . . . . . 8 8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 9 9. A Note on Fragmentation Considered Harmful . . . . . . . . . 10 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 14.1. Normative References . . . . . . . . . . . . . . . . . . 11 14.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. L2 Encapsulation with OMNI . . . . . . . . . . . . . 13 Appendix B. Multicast and Anycast . . . . . . . . . . . . . . . 16 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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]. For Internet Protocol, version 6 (IPv6), the Identification field is only present in packets that include a Fragment Header where its standard length is 32-bits [RFC8200], but even this length may be too small for some applications. This document therefore defines a means to extend the IPv6 Identification length through the introduction of a new IPv6 Destination option that defines an Extended Fragment Header. Templin Expires 2 June 2024 [Page 2] Internet-Draft IPv6 Extended Fragment Header November 2023 The IPv6 Extended Fragment Header 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. The specification further defines a messaging service for adaptive realtime response to congestion related to fragmentation and reassembly. Together, these extensions support robust fragmentation and reassembly services as well as packet Identification uniqueness for IPv6. 2. Terminology 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 extended form. The terms "Maximum Transmission Unit (MTU)", "Effective MTU to Receive (EMTU_R)", "Effective MTU to Send (EMTU_S)" and "Maximum Segment Lifetime (MSL)" are used exactly the same as for standard Internetworking terminology [RFC1122]. The term MSL is equivalent to the term "maximum datagram lifetime (MDL)" defined in [RFC0791][RFC6864]. The term "Packet Too Big (PTB)" refers to an IPv6 "Packet Too Big" [RFC8201][RFC4443] message. The term "flow" refers to a sequence of packets sent from a particular source to a particular unicast, anycast or multicast destination [RFC6437]. The term "source" refers to either the original end system that produces an IP packet or an encapsulation ingress intermediate system on the path. The term "destination" refers to either a decapsulation egress intermediate system on the path or the final end system that consumes an IP packet. The term "intermediate system" refers to a node on the path from the (original) source to the (final) destination that forward packets not addressed to itself. Intermediate systems that decrement the IP header TTL/Hop Limit are also known as "routers". 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. Templin Expires 2 June 2024 [Page 3] Internet-Draft IPv6 Extended Fragment Header November 2023 3. Motivation Studies over many decades have shown that upper layer protocols often 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 4-octet (32-bit) IPv6 Identification field may be too small to ensure reassembly integrity at sufficiently high data rates, especially when the source resets the starting sequence number often to maintain an unpredictable profile [RFC7739]. 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 substantial performance increases 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 validates the Internet architecture which includes fragmentation and reassembly as core functions. 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 smaller 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 follows that IPv4 fragmentation and reassembly can support higher data rates than IPv6 when full (uncompressed) headers are used, while the rates may be comparable when IPv6 header compression is applied. Templin Expires 2 June 2024 [Page 4] Internet-Draft IPv6 Extended Fragment Header November 2023 In addition to accommodating 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 to aid detection of potential duplicates (note however that the network layer must not incorrectly flag intentional lower layer retransmissions as duplicates). 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 sequence number window for a flow as potential spurious transmissions. 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 IPv6 ID to better support these services through the introduction of an IPv6 Extended Fragment Header Destination Option. 4. IPv6 Extended Fragment Header For a standard 4-octet IPv6 Identification, the source can simply include an ordinary IPv6 Fragment Header as specified in [RFC8200] with the "Fragment Offset" field and "M" flag set either to values appropriate for a fragmented packet or the value '0' for an unfragmented packet. The source then includes a 4-octet Identification value for the packet. For an extended Identification, this specification permits the source to instead include a new IPv6 Extended Fragment Header to appear in the first set of Destination Options immediately following the Hop- by-Hop Options (if present) and immediately before the Routing Header (if present) - see Section 4.1 of [RFC8200]. The IPv6 Extended Fragment Header is formatted as shown in Figure 1: Templin Expires 2 June 2024 [Page 5] Internet-Draft IPv6 Extended Fragment Header November 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Index |P|S| Fragment Offset |Res|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+- Identification (64 bits) -+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 8-bit value '001[TBD1]'. Opt Data Len 8-bit value 12. Next Header encodes the Next Header value that appears immediately following the Routing Header (if present); otherwise, the next header immediately following the Destination Option. Index, P, S a control octet that identifies the components of an IP Parcel [I-D.templin-intarea-parcels]. Fragment Offset, the same fragmentation control fields that Res, M appear in the standard IPv6 Fragment Header. Identification an 8-octet unsigned integer Identification, in network byte order. Figure 1: IPv6 Extended Fragment Header The Extended Fragment Header Destination Option is therefore identified by Option Type TBD1 (see: IANA Considerations) and the Identification field is 8 octets in length. The header may appear either in an unfragmented IPv6 packet or in one for which IPv6 fragmentation is applied (after which, the header appears in each fragment). The source applies fragmentation using the Extended Fragment Header Destination Option in exactly the same fashion as for the standard IPv6 Fragment Header, except that the Destination Option itself is included in the Per-Fragment Headers - see: Section 4.5 of [RFC8200]. For each fragment produced during fragmentation, the source also resets the Destination Option Next Header field to "No Next Header" when no Routing Header is present; when a Routing Header is present, the source instead resets the Routing Header Next Header field to "No Next Header". Templin Expires 2 June 2024 [Page 6] Internet-Draft IPv6 Extended Fragment Header November 2023 The destination reassembles the same as specified in Section 4.5 of [RFC8200]. Following reassembly, if the Routing Header is present the destination resets the Routing Header Next Header field to the value cached in the Extended Fragment Header. If no Routing Header is present, the destination instead resets the Destination Option Next Header field. Intermediate systems that forward packets fragmented in this way will therefore interpret the data that follows the per-fragment headers as undefined data (by virtue of the No Next Header) instead of attempting to interpret it as the data of a specific protocol. 5. Destination Qualification Destinations that do not recognize the Extended Fragment Header ignore the option and process the packet further according to the remaining extension header chain. For packets fragmented according to the Extended Fragment Header, since the Next Header field in the final per-fragment extension header will encode "No Next Header", the destination will simply discard the fragment. This allows the source to test whether a destination recognizes the Extended Fragment Header by occasionally sending a fragmented packet using the option. If the source receives an acknowledgement, it has assurance that the destination has successfully applied reassembly. The source should continually test each destination in case routing redirects a flow to a different anycast destination. 6. IPv6 Network Fragmentation When an IPv6 network intermediate system forwards a packet that includes a Destination Option in the extension header order where the Extended Fragment Header is permitted to occur, the intermediate system can optionally parse the Destination Option to determine if the Extended Fragment Header is present. If the packet is too large to traverse the next hop toward the destination, the intermediate system can then apply (further) fragmentation based on the Extended Fragment Header parameters included by the original source while using the same fragmentation procedures as for source fragmentation discussed above. For this reason, the Extended Fragment Header option contents may change in the path; hence the option "chg" flag is '1'. This specification therefore updates [RFC8200] by permitting network fragmentation for IPv6 under the above conditions. Templin Expires 2 June 2024 [Page 7] Internet-Draft IPv6 Extended Fragment Header November 2023 7. 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 a "Packet Too Big (PTB)" message to the source [RFC4443][RFC8201] and discards the packet. This always results in wasted transmissions by the source and all intermediate systems on the path toward the one with the restricting link. Conversely, when network fragmentation is permitted the network will perform (further) fragmentation if necessary allowing the packet to reach the destination without loss due to a size restriction. This results in an internetwork that is adaptive to dynamic MTU fluctuations and not subject to wasted transmissions. While the fragmentation and reassembly processes eliminate wasted transmissions and support significant performance gains by accommodating upper layer protocol segment sizes that exceed the path MTU, the processes sometimes represent pain points that should be communicated to the source. The source should then take measures to reduce the size of the packets/fragments that it sends. The IPv6 PTB format includes a "Code" field 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 end systems and intermediate systems that recognize the Extended Fragment Header according to this specification, the following additional PTB unused/Code values are defined: 1 (suggested) Sent by an intermediate system (subject to rate limiting) when it performs fragmentation on a packet with an Extended Fragment Header. The intermediate system sends the PTB message 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 as an indication for the source to reduce its (source) fragment sizes. This size will often be considerably smaller than the current EMTU_R advertised by the destination. 2 (suggested) The same as for Code 1, except that the intermediate system drops the packet instead of fragmenting and forwarding. This message type represents a hard error indicating loss. In one possible strategy, the intermediate system could begin sending Code 1 PTBs then revert to sending Code 2 PTBs if the source fails to reduce its fragment sizes. 3 (suggested) Sent by the destination (subject to rate limiting) Templin Expires 2 June 2024 [Page 8] Internet-Draft IPv6 Extended Fragment Header November 2023 when it performs reassembly on a packet with an Extended Fragment Header during periods of reassembly congestion. The destination sends the PTB message while still reassembling and accepting the packet. The MTU field of the PTB message includes the largest desired receive packet size (less than or equal to the EMTU_R) under current reassembly buffer congestion constraints as an indication for the source to begin sending smaller packets if necessary. This size will often be considerably larger than the path MTU and must be no smaller than the IPv6 minimum EMTU_R. 4 (suggested) The same as for Code 3, except that the destination drops the packet instead of reassembling and accepting. This message type represents a hard error indicating loss. In one possible strategy, the destination could begin sending Code 3 PTBs then revert to dropping packets while sending Code 4 PTBs if the source fails to reduce its packet sizes. 8. Requirements Intermediate systems MUST forward without dropping packets that include a Destination Option with an Extended Fragment Header whether or not they recognize the option. Sources MUST include at most one IPv6 Standard or Extended Fragment Header in each packet/fragment. Intermediate systems and destinations SHOULD silently drop packets/fragments with multiples. Destinations MUST be capable of reassembling packets as large as the minimum Effective MTU to Receive (EMTU_R) specified for IPv6 ([RFC8200], section 5). Destinations that accept flows using Extended Fragment Headers: * MUST configure a minimum EMTU_R of 65535 octets, * SHOULD advertise the largest possible receive packet size (i.e., as large as EMTU_R) in PTB messages, and * MAY advertise a reduced receive packet size in PTB messages during periods of congestion. While a source has assurance that the destination(s) will recognize and correctly process the Extended Fragment Header, it can continue to send fragmented or fragmentable packets as large as the EMTU_R at rates within the MSL/MDL wraparound threshold for the extended IP ID length; otherwise, the source honors the MSL/MDL threshold for the non-extended Identification field length [RFC6864]. Templin Expires 2 June 2024 [Page 9] Internet-Draft IPv6 Extended Fragment Header November 2023 Note: IP fragmentation can only be applied for conventional packets as large as 65535 octets. IP parcels and Advanced Jumbos (AJs) provide a means for efficiently packaging and shipping multiple large segments or truly large singleton segments in packets that may exceed this size [I-D.templin-intarea-parcels]. 9. A Note on Fragmentation Considered Harmful During the earliest days of internetworking, researchers asserted that fragmentation should be deemed "harmful" based on empirical observations in the ARPANET, DARPA Internet and other internetworks of the day [KENT87]. These assertions somehow inspired an engineering discipline known as "Path MTU Discovery" within a new community that evolved to become the Internet Engineering Task Force (IETF). In more recent times, the IETF amplified these assertions in "IP Fragmentation Considered Fragile" [RFC8900]. Rather than encourage timely course corrections, however, the IETF somehow forgot that IP fragmentation and reassembly still serve as essential internetworking functions. This has resulted in a modern Internet where path MTU discovery (including its recent derivatives) provides a poor service for conventional packet sizes especially in dynamic networks with path MTU diversity. This document introduces a more robust solution based on a properly functioning IP fragmentation and reassembly service as intended in the original architecture. Although the IP fragmentation and reassembly services provide an appropriate solution for conventional packet sizes as large as 65535 octets, the services cannot be applied for IP parcels and AJs that exceed this size. Instead, modern path MTU discovery methods provide the only possible solution to accommodate these larger sizes. This means that a combined solution with fragmentation and reassembly applied for conventional packets and path MTU discovery applied for jumbos provides the necessary combination for Internetworking futures. This document therefore updates [RFC8900]. 10. Implementation Status In progress. 11. IANA Considerations The IANA is requested to assign a new IPv6 Destination Option type "TBD1" in the 'ipv6-parameters' registry (registration procedures IESG Approval, IETF Review or Standards Action). The option sets "act" to '00', "chg" to '1', "rest" to TBD1, "Description" to "IPv6 Extended Fragment Header" and "Reference" to this document [RFCXXXX]. Templin Expires 2 June 2024 [Page 10] Internet-Draft IPv6 Extended Fragment Header November 2023 The IANA is further instructed to assign new Code values in the "ICMPv6 Code Fields: Type 2 - Packet Too Big" table of the 'icmpv6-parameters' registry (registration procedure is Standards Action or IESG Approval). The registry should appear as follows: Code Name Reference --- ---- --------- 0 PTB Hard Error [RFC4443] 1 (suggested) Fragmentation Needed (soft) [RFCXXXX] 2 (suggested) Fragmentation Needed (hard) [RFCXXXX] 3 (suggested) Reassembly Needed (soft) [RFCXXXX] 4 (suggested) Reassembly Needed (hard) [RFCXXXX] Figure 2: ICMPv6 Code Fields: Type 2 - Packet Too Big Values 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 IP 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, Bob Hinden and Eric Vyncke 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, . [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Templin Expires 2 June 2024 [Page 11] Internet-Draft IPv6 Extended Fragment Header November 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, . [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.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.templin-dtn-ltpfrag] Templin, F., "LTP Fragmentation", Work in Progress, Internet-Draft, draft-templin-dtn-ltpfrag-16, 23 October 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, . Templin Expires 2 June 2024 [Page 12] Internet-Draft IPv6 Extended Fragment Header November 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, . [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, 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, . [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. L2 Encapsulation with OMNI For paths that reject packets that include certain IPv6 extension headers or options, an encapsulation service is necessary to avoid middlebox filtering. The source can elect to engage encapsulation if the first alternative IP ID extension method fails or advance immediately to engaging encapsulation if it has reason to believe there is better opportunity for success. The encapsulation employs UDP, IP and/or Ethernet headers recognized by intermediate/end systems within a limited domain [RFC8799]. The OMNI specification [I-D.templin-intarea-omni] defines an encapsulation format in which UDP/IP headers that use UDP port 8060 serve as a "Layer 2 (L2)" encapsulation for OMNI IPv6-encapsulated IP packets. The UDP header is then followed by a chain of IPv6 Templin Expires 2 June 2024 [Page 13] Internet-Draft IPv6 Extended Fragment Header November 2023 extension headers including a Fragment Header and a HBH header with an IPv6 ID Extension option which together form an extended IP ID. The extension header chain is then followed by an OMNI IPv6 encapsulation header in full/compressed form followed by any OMNI IPv6 extensions followed by the original IP packet as shown in Figure 3: +---------------------------+ | L2 IP/Ethernet Header | +---------------------------+ | L2 UDP Header (port 8060) | +---------------------------+ ~ L2 IPv6 Extension Headers ~ +---------------------------+ | OMNI IPv6 Encapsulation | +---------------------------+ ~ OMNI IPv6 Extensions ~ +---------------------------+ | | ~ ~ ~ Original IP Packet ~ ~ ~ | | +---------------------------+ Figure 3: OMNI L2 Fragmentation and Reassembly The OMNI interface encapsulates each original IP packet in an IPv6 encapsulation header as an OMNI Adaptation Layer (OAL) encapsulation. The interface next encapsulates this "OAL packet" in UDP/IP headers as "L2" encapsulations. When the packet requires L2 fragmentation and/or any other extension header processing, the OMNI interface instead performs the following operations: * If the L2 header is IPv4 or Ethernet, convert it to an IPv6 header while converting the IPv4/EUI source and destination addresses to IPv4-compatible IPv6 addresses per [I-D.templin-intarea-omni]. * Encapsulate the OAL packet in this L2 IPv6 header with any necessary IPv6 extension headers per [I-D.templin-intarea-omni], then perform normal extension header processing including fragmentation according to the IPv6 Extended Fragment Header specification in this document. Templin Expires 2 June 2024 [Page 14] Internet-Draft IPv6 Extended Fragment Header November 2023 * For each fragment, insert a UDP header between the L2 IPv6 header and L2 IPv6 extension headers, then adjust the Next Header field of each successive extension header per [I-D.templin-intarea-omni]. * If the original L2 header was IPv4 or Ethernet, re-convert the IPv6 header back to IPv4/Ethernet. * If the L2 header was IP, change {Protocol, Next Header} to '17' (UDP), set the remaining UDP/IP header fields to the correct values for each fragment, then transmit each fragment to the L2 destination. When the L2 destination receives these (concealed) fragments, it first notices the OMNI-encoded L2 IPv6 extension headers immediately following the L2 OMNI UDP header. The destination then removes the L2 UDP header and (for IPv4) also converts the L2 IPv4 header to IPv6. The destination then applies any necessary OMNI L2 IPv6 extension header processing, including reassembly. Following reassembly, the destination discards the L2 headers to arrive at the original OAL packet/fragment for further processing by the adaptation layer. For L2 encapsulations that do not include a UDP header (e.g., IP- only), these fragments will include the L2 IPv6 extension headers immediately after the L2 IP header. The L2 IP header must then set its IP {Protocol, Next Header} to the protocol number reserved for OMNI [I-D.templin-intarea-omni]. For L2 encapsulations that do not include UDP/IP headers (e.g., Ethernet-only), these fragments will include the L2 IPv6 extension headers immediately after the true L2 header. The L2 header must then set its L2 type to the EtherType reserved for OMNI [I-D.templin-intarea-omni]. Note: on the wire, these encapsulated IPv6 fragments will include an extended IP ID but will appear as ordinary packets to network middleboxes that inspect headers. This allows network middleboxes to make consistent forwarding decisions for each fragment of the same original OAL packet and without first attempting virtual fragment reassembly since each fragment appears as a whole packet. Note: the above procedures can also be applied to ordinary TCP/UDP datagrams. In that case, the L2 IPv6 extension headers are immediately followed by a TCP/UDP header instead of an OMNI IPv6 encapsulation header. Templin Expires 2 June 2024 [Page 15] Internet-Draft IPv6 Extended Fragment Header November 2023 Appendix B. Multicast and Anycast Although unicast flows are assumed throughout this document, similar considerations apply for flows in which the destination is a multicast group or an anycast address. In order to send fragmented/fragmentable packets with IPv6 Extended Fragment Headers to a multicast group, the source must have prior assurance that all group members will correctly recognize and process them. This assurance is normally through use of a UDP port number, IP protocol number and/or Ethernet type encapsulation for which extended IP ID processing is mandatory (see: Appendix A). When a source sends fragmented/fragmentable packets with IPv6 Extended Fragment Headers to a multicast group, the packets/fragments may be replicated in the network such that a single transmission may reach N destinations over as many as N different paths. Intermediate systems in each such path may return a Code 1/2 PTB message if (further) fragmentation is needed, and each such destination may return a Code 3/4 PTB message if it experiences reassembly congestion. While the source receives these PTB messages, it should reduce the fragment/packet sizes that it sends to the multicast group even if only one or a few paths or destinations are currently experiencing congestion. This means that transmissions to a multicast group will converge to the performance characteristics of the lowest common denominator group member destinations and/or paths. When a source sends fragmented/fragmentable packets with IPv6 Extended Fragment Headers to an anycast address, routing may direct initial fragments of the same packet to a first destination that configures the address while directing the remaining fragments to other destinations that configure the address. These wayward fragments will simply result in incomplete reassemblies at each such anycast destination which will soon purge the fragments from the reassembly buffer. The source will eventually retransmit, and all resulting fragments should eventually reach a single reassembly target. Appendix C. Change Log << RFC Editor - remove prior to publication >> Differences from earlier versions: * First draft publication. Templin Expires 2 June 2024 [Page 16] Internet-Draft IPv6 Extended Fragment Header November 2023 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 2 June 2024 [Page 17]