Identification Extension Options for the Internet Protocol
draft-templin-intarea-ipid-ext-00

Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Intended status: Standards Track                            28 July 2023
Expires: 29 January 2024

       Identification Extension Options for the Internet Protocol
                   draft-templin-intarea-ipid-ext-00

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 may be smaller than desired for some intended
   uses.  This document addresses these limitations by defining both an
   Identification Extension option for IPv4 and a corresponding
   Destination Option for IPv6.

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 29 January 2024.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Templin                  Expires 29 January 2024                [Page 1]
Internet-Draft         IP Identification Extension             July 2023

   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
   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.  IP ID Extension . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  IP ID Hyper-Extension . . . . . . . . . . . . . . . . . . . .   5
   6.  IP ID Ultra-Extension . . . . . . . . . . . . . . . . . . . .   6
   7.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   9
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     12.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The Internet Protocol, version 4 (IPv4) header includes a 16 bit
   Identification in all packets [RFC0791], but this length is too small
   to ensure reassembly integrity even at moderate data rates in modern
   networks [RFC4963] [RFC6864].  This document defines a new option for
   IPv4 that extends the Identification field to 32 bits (i.e., the same
   as the length specified for Internet Protocol, version 6 (IPv6)
   [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 IP ID.  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 29 January 2024                [Page 2]
Internet-Draft         IP Identification Extension             July 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 future networks that operate at still higher
   data rates, or for source nodes that frequently reset the starting
   Identification sequence numbers of flows.  Finally, for truly extreme
   environments, an optional "ultra-extended" mode that extends the
   Identification field to 128 bits is also supported.

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
   extended form.

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.

   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.

   An alternative to fortifying the IPv4 ID was also considered and
   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.

   An observation offered without supporting evidence is that common
   implementations base both IPv4 and IPv6 fragmentation and reassembly
   off a common code base since their algorithms are so similar.  It

Templin                  Expires 29 January 2024                [Page 3]
Internet-Draft         IP Identification Extension             July 2023

   therefore seems reasonable to conclude that IPv4 fragmentation and
   reassembly can support higher data rates than IPv6 when full
   (uncompressed) headers are used.

   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.  This document therefore presents a
   means to fortify the IP ID to support such a service.

4.  IP 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 IP ID for the packet.  The
   option format is shown in Figure 1:

      +--------+--------+--------+--------+
      |100[TBD]|00000100|  ID Extension   |
      +--------+--------+--------+--------+
       Type=TBD Length=4

                 Figure 1: IPv4 ID Extension (IDEXT) Option

   When 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., while following the same rules as for including
   any IPv4 option.  The source next writes the 2 least-significant
   octets in the IPv4 header Identification field and writes the 2 most-
   significant octets in the "ID Extension" field.

   The source then applies source fragmentation if necessary while
   including the extended IP ID value.  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.)

Templin                  Expires 29 January 2024                [Page 4]
Internet-Draft         IP Identification Extension             July 2023

   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.  IP 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 frequently or even pseudo-
   randomly, it can optionally "hyper-extend" the IP ID by supplying an
   8-octet 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 Hyper-Extension        |
      +--------+--------+--------+--------+

                   Figure 2: IDEXT Option Hyper-Extension

   The option-data will then include the 2-octet ID Extension to be
   applied to the IPv4 Identification field as above, plus a 4-octet ID
   Hyper-Extension that includes the 4 most significant octets of the
   hyper-extended ID.  The combined 8-octet IP ID can then fit properly
   within the longest word length for modern 64-bit architectures.

   Techniques that improve IPv4 often also apply in a similar fashion
   for IPv6 (and vice-versa).  This document therefore defines a new
   Destination Option for IPv6 that includes an IPv6 ID Hyper-Extension
   for the base Identification value found in the IPv6 Fragment Header.
   The option is processed only if the Fragment Header is also present;
   otherwise the option is ignored.  The IPv6 ID Hyper-Extension option
   format is shown in Figure 3:

Templin                  Expires 29 January 2024                [Page 5]
Internet-Draft         IP Identification Extension             July 2023

                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  |  Opt Data Len |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    IPv6 ID Hyper-Extension                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Option Type           8-bit value TBD2.

     Opt Data Len          8-bit value 4.

     IPv6 ID Extension     32-bit unsigned integer. The option data
                           includes a 4-octet extension to the (4-octet)
                           IPv6 Fragment Header Identification field.

                 Figure 3: IPv6 ID Hyper-Extension Option

   All aspects of applying and processing the IPv6 ID Hyper-Extension
   option follow exactly the same as for IPv4, with the exception that
   only source fragmentation is permitted since network fragmentation is
   deprecated in IPv6.

6.  IP ID Ultra-Extension

   To support truly extreme environments (e.g., where IP ID duplication
   in ultra-high speed networks carries severe consequences and/or where
   sophisticated adversaries actively try to guess IP ID values), an
   optional "ultra-extension" mode is also supported that extends the IP
   ID to 16 octets.

   Nodes invoke ultra-extension mode by replacing the "Hyper-Extension"
   fields in Figure 2 and Figure 3 with an "Ultra-Extension" field
   containing the most significant 12 octets of a 16-octet ultra-
   extended IP ID.  For IPv4, the option sets option-length to 16 and,
   for IPv6, the option sets Opt Data Len to 12.

   Nodes process the IP ID ultra-extension format the same as for the
   other extension forms, except that the option contains 12 octets in
   network byte order that form the most significant octets of a 16
   octet IP ID.  The combined 16-octet IP ID can then fit properly
   within two words under the longest word length for modern 64-bit
   architectures.

Templin                  Expires 29 January 2024                [Page 6]
Internet-Draft         IP Identification Extension             July 2023

   Since processing two long words instead of a single word may require
   extra machine instructions even in modern architectures, and since
   transporting longer ultra-extended IP IDs consumes additional network
   bandwidth, ultra-extended mode performance may be less than for
   extended/hyper-extended modes under modern day architectures.
   However, these issues may be overcome by future architectures that
   support 128-bit instruction sets natively over ultra-high speed
   networks.

   Due to the added complexity and overhead, nodes are not required to
   support ultra-extended mode natively.  Destination nodes that
   implement the extended/hyper-extended modes but do not support ultra-
   extended mode unconditionally drop packets that include an ultra-
   extended IP ID.  After first testing for basic IP ID extension
   support (see: Section 7) source nodes can therefore test for ultra-
   extension support by sending a 'ping' packet that includes an ultra-
   extended option.  If the source receives a ping response, it can
   begin sending packets with ultra-extended IP IDs.

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 Option Type TBD2.

   Destinations that recognize IPv4 option-type TBD and/or IPv6 Option
   Type TBD2 MUST accommodate packets that include all simple, extended
   and hyper-extended IP ID formats based on any 2-, 4- or 8-octet value
   included by the source.  Destinations that implement the OPTIONAL
   ultra-extended IP ID format MUST accommodate packets with ultra-
   extended 16-octet IP IDs, while destinations that implement only the
   required extended IP ID formats MUST drop packets that include an
   ultra-extended IP ID.

   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, the ID
   Extension field (when present) containing the next most significant
   octets and the ID Hyper/Ultra-Extension field (when present)
   containing the most significant octets.  When either or both
   extension fields are absent, implementations consider their values to
   be "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

Templin                  Expires 29 January 2024                [Page 7]
Internet-Draft         IP Identification Extension             July 2023

   or more fragments containing different pseudo-random values in the
   combined extension fields of an ID Hyper-Extension option (the source
   can first send an ordinary 'ping' to test reachability).  If the
   destination responds to a fragmented ping sent with mismatched
   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 extended/hyper-extended formats and optional
   ultra-extended format.  The formats are differentiated by the option-
   length value for IPv4 or the Option Length value for IPv6.  Future
   documents may specify additional formats that use different option
   length values.

   Note: IP fragmentation can only be applied for packet lengths up to a
   maximum of 65535 octets.  IP parcels and advanced jumbos provide a
   means for efficiently packaging and shipping multiple large segments
   or truly large singleton segments in IP packets that may exceed this
   size [I-D.templin-intarea-parcels].

8.  Implementation Status

   In progress.

9.  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.

   Note: IANA could alternatively re-assign a deprecated IPv4 option
   instead of allocating a new option; for example, the "Extended
   Internet Protocol (EIP)" option which still appears as option
   "Number" 17 with "Value" 145.  Earlier works formalized deprecation
   of the EIP option [RFC6814], while [RFC7126] took the further step of
   advising routers to drop packets that include the option.

Templin                  Expires 29 January 2024                [Page 8]
Internet-Draft         IP Identification Extension             July 2023

10.  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.

11.  Acknowledgements

   This work was inspired by continued DTN performance studies.

12.  References

12.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>.

   [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>.

   [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>.

12.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>.

Templin                  Expires 29 January 2024                [Page 9]
Internet-Draft         IP Identification Extension             July 2023

   [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>.

Appendix A.  Change Log

   << RFC Editor - remove prior to publication >>

   Differences from earlier versions:

   *  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 29 January 2024               [Page 10]