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,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
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,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[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,
<https://www.rfc-editor.org/info/rfc8201>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-12>.
[I-D.templin-dtn-ltpfrag]
Templin, F., "LTP Fragmentation", Work in Progress,
Internet-Draft, draft-templin-dtn-ltpfrag-16, 23 October
2023, <https://datatracker.ietf.org/doc/html/draft-
templin-dtn-ltpfrag-16>.
[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, <https://datatracker.ietf.org/doc/html/draft-
templin-intarea-omni-51>.
[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,
<https://datatracker.ietf.org/doc/html/draft-templin-
intarea-parcels-90>.
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,
<https://www.rfc-editor.org/info/rfc4963>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field",
RFC 6864, DOI 10.17487/RFC6864, February 2013,
<https://www.rfc-editor.org/info/rfc6864>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <https://www.rfc-editor.org/info/rfc7739>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[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,
<https://www.rfc-editor.org/info/rfc8900>.
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]