Network Working Group F. L. Templin, Ed.
Internet-Draft Boeing Research & Technology
Updates: rfc6864, rfc8200, rfc8900 (if approved) 31 August 2023
Intended status: Standards Track
Expires: 3 March 2024
Identification Extension Options for the Internet Protocol
draft-templin-intarea-ipid-ext-04
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 Hop-by-Hop Option for Identification Extension.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 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 3 March 2024 [Page 1]
Internet-Draft IP Identification Extension August 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 . . . . . . . . . . . . . . . . . . . . . . . . 7
8. IPv4 ID Applications . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
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 Fragment Header
[RFC8200]) to support reassembly integrity at high 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 3 March 2024 [Page 2]
Internet-Draft IP Identification Extension August 2023
This specification also supports a "hyper-extended" mode that extends
the Identification field to 64-bits for both IPv4 and IPv6. This
format may be useful for networks that operate at still higher data
rates, or for other cases when Identification uniqueness assurance is
critical. Together, these IP options 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 term "Maximum Transmission Unit (MTU)" is 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 transport layer protocols
often achieve greater performance by setting 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 16-bit IPv4 and 32-bit
Identification fields may be too short to support reassembly
integrity at sufficiently high data rates. We therefore propose
fortifying the IP ID by extending its length.
A recent study [I-D.templin-dtn-ltpfrag] proved that setting 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 a core function was the correct one.
Templin Expires 3 March 2024 [Page 3]
Internet-Draft IP Identification Extension August 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 32-bit 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 3 March 2024 [Page 4]
Internet-Draft IP Identification Extension August 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 3 March 2024 [Page 5]
Internet-Draft IP Identification Extension August 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 ID Extension Hop-by-Hop (HBH) Option for IPv6 that
(hyper-)extends the base IPv6 ID.
IPv6 packets that include a Fragment Header already have a 4-octet
(32-bit) IPv6 ID , while those that do not include a Fragment Header
have a 0-octet (0-bit) IPv6 ID. The IPv6 ID Extension HBH Option
format is shown in Figure 3:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ IPv6 ID Extension ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type 8-bit value '000[TBD2]'.
Opt Data Len 8-bit value 0, 4 or 8.
IPv6 ID Extension 0 octets, or a 4/8-octet unsigned integer
that encodes the extension, in network byte
order.
Figure 3: IPv6 ID Extension HBH Option
When an IPv6 packet that includes the IPv6 ID Extension HBH Option
does not include a Fragment Header, the Option Data Length must be
either '4' or '8', and the option body correspondingly includes the
full 4-octet or 8-octet IPv6 ID for the packet in network byte order.
When an IPv6 packet that includes the IPv6 ID Extension HBH Option
also includes a Fragment Header, the option length must be either '0'
or '4', and the option body correspondingly includes the 0 or 4 most
significant IPv6 ID octets in network byte order while the Fragment
Header includes the 4 least significant octets.
Templin Expires 3 March 2024 [Page 6]
Internet-Draft IP Identification Extension August 2023
7. Requirements
IPv4 routers MUST forward without dropping any packets with IPv4
option-type TBD while copying the option during (router)
fragmentation, and IPv6 routers MUST forward without dropping any
packets with IPv6 HBH Option Type TBD2.
Destinations that recognize IPv4 option-type TBD and/or IPv6 HBH
Option Type TBD2 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.
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.
Since the option is included only by the source and reassembly is
performed only by the destination, the source can test whether the
path and/or destination are compliant by sending a fragmented 'ping'
packet with the same IP Identification in all fragments but with two
or more fragments containing different pseudo-random values in the
option (hyper-)extension fields (the source can first send an
ordinary 'ping' to test reachability). If the destination responds
to a fragmented ping sent with mismatched (hyper-)extended IP IDs
(proving that reassembly was performed without honoring the option)
the source can infer that the destination and/or some router on the
path does not recognize the option.
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 Option Data
Length value 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].
Templin Expires 3 March 2024 [Page 7]
Internet-Draft IP Identification Extension August 2023
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 4/8-octet value that can satisfy uniqueness properties
useful for other purposes.
This specification therefore updates [RFC6864] by permitting use of
the extended IPv4 ID for purposes other than 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 both an IPv6 HBH
Option with type TBD2 and a Fragment Header, it applies (further)
fragmentation if the next hop link MTU is insufficient.
Templin Expires 3 March 2024 [Page 8]
Internet-Draft IP Identification Extension August 2023
The presence of both the TBD2 HBH Option and 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 an IPv6 router to apply fragmentation
on packets that already include a Fragment Header, but never to
insert a Fragment Header themselves.
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 routers on the path
toward the node with the restricting link. Conversely, when a packet
includes an IP ID Extension option (and also a Fragment Header for
IPv6) 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 a router when it performs fragmentation on an IP packet
that could instead have been fragmented by the original source.
The router 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.
Templin Expires 3 March 2024 [Page 9]
Internet-Draft IP Identification Extension August 2023
2 The same as for value 1, except that the router 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 an IP
packet under periods of reassembly buffer congestion. The
destination sends the PTB message subject to rate limiting while
still reassembling and accepting the packet. The MTU field of the
PTB message includes a reduced total packet size to ease current
reassembly buffer congestion. This value 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 a router or final destination in response
to an IP parcel that triggered the event (see:
[I-D.templin-intarea-parcels]).
6 Jumbo Report - Sent by a router 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 routers in the path which will
no longer need to perform network fragmentation.
When the original source receives a Code 3 or 4 PTB, it reduces the
size of the packets it sends based on the packet size indicted in the
MTU field which may be larger than the path MTU. This reduces the
burden on the final destination which will no longer need to
reassemble such large packets.
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 false science known as "Path MTU Discovery" within a new
community that would become known as the Internet Engineering Task
Force (IETF). In more recent times, the IETF amplified these earlier
assertions through the publication of "Fragmentation Considered
Fragile" [RFC8900].
Templin Expires 3 March 2024 [Page 10]
Internet-Draft IP Identification Extension August 2023
Rather than encourage implementation corrections from the very
beginning, however, the IETF somehow made a case that the
fragmentation and reassembly aspects of the IP architecture were
flawed. 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 asserts that a better solution depends 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.
IANA is further requested to assign a new IPv6 Destination Option
with description "IPv6 ID Extension" in the 'ipv6-parameters'
registry (registration procedures IESG Approval, IETF Review or
Standards Action). The option sets "act" to '00', "chg" to '0' and
"rest" to TBD2.
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.)
Templin Expires 3 March 2024 [Page 11]
Internet-Draft IP Identification Extension August 2023
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.
17. References
17.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>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[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>.
[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>.
Templin Expires 3 March 2024 [Page 12]
Internet-Draft IP Identification Extension August 2023
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,
<https://datatracker.ietf.org/doc/html/draft-templin-dtn-
ltpfrag-10>.
[I-D.templin-intarea-parcels]
Templin, F., "IP Parcels and Advanced Jumbos", Work in
Progress, Internet-Draft, draft-templin-intarea-parcels-
66, 26 July 2023, <https://datatracker.ietf.org/doc/html/
draft-templin-intarea-parcels-66>.
[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>.
[RFC6814] Pignataro, C. and F. Gont, "Formally Deprecating Some IPv4
Options", RFC 6814, DOI 10.17487/RFC6814, November 2012,
<https://www.rfc-editor.org/info/rfc6814>.
[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>.
[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,
<https://www.rfc-editor.org/info/rfc7126>.
[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. Change Log
<< RFC Editor - remove prior to publication >>
Differences from earlier versions:
Templin Expires 3 March 2024 [Page 13]
Internet-Draft IP Identification Extension August 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 3 March 2024 [Page 14]