Skip to main content

IPv6 Extended Fragment Header for IPv4
draft-templin-intarea-ipid-ext2-01

Document Type Active Internet-Draft (individual)
Author Fred Templin
Last updated 2024-02-19
Replaces draft-templin-intarea-ipid-ext
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-templin-intarea-ipid-ext2-01
Network Working Group                                 F. L. Templin, Ed.
Internet-Draft                              Boeing Research & Technology
Updates: 6864, 8900 (if approved)                       19 February 2024
Intended status: Standards Track                                        
Expires: 22 August 2024

                 IPv6 Extended Fragment Header for IPv4
                   draft-templin-intarea-ipid-ext2-01

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 adapting the IPv6 Extended Fragment
   Header for IPv4.

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 22 August 2024.

Copyright Notice

   Copyright (c) 2024 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 22 August 2024                 [Page 1]
Internet-Draft         IP Identification Extension         February 2024

   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.  Relation to IPv6  . . . . . . . . . . . . . . . . . . . . . .   2
   3.  IPv6 Extended Fragment Header for IPv4  . . . . . . . . . . .   3
   4.  Destination Qualification and Path MTU  . . . . . . . . . . .   4
   5.  Packet Too Big (PTB) Extensions . . . . . . . . . . . . . . .   5
   6.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

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 specification adapts the
   IPv6 Extended Fragment Header [I-D.templin-6man-ipid-ext2] for
   Identification extension and to support an alternate fragmentation
   and reassembly service for IPv4.

   When an IPv4 packet includes the IPv6 Extended Fragment Header, a
   "deep packet fragmentation" capability is enabled that supports
   Identification, fragmentation and reassembly services from deep
   within the packet independently of any IPv4 header level services.
   This may be useful for networks that engage fragmentation and
   reassembly at extreme data rates, or for cases when advanced IPv4
   packet Identification uniqueness assurance is critical.

2.  Relation to IPv6

   As is often the case, extensions intended for IPv6 can be applied in
   similar fashion as for IPv4 (and vice-versa).  The terminology used
   and the motivation for extending the Identification field for IPv4 is
   the same as for IPv6 Identification extension as specified in
   [I-D.templin-6man-ipid-ext2].  All normative aspects of the IPv6
   specification that can be applied for IPv4 apply also to this

Templin                  Expires 22 August 2024                 [Page 2]
Internet-Draft         IP Identification Extension         February 2024

   document.

3.  IPv6 Extended Fragment Header for IPv4

   IPv4 end systems and intermediate systems do not by default recognize
   the IP protocol numbers for IPv6 extension headers, as these are
   typically used to support IPv6 operations only.  However,
   implementations of this specification are required to recognize IP
   protocol number 0 and the IPv6 Minimum Path MTU Option formats as
   defined for the IPv6 Hop-by-Hop Options header per [RFC8200][RFC9268]
   as well as IP protocol number 60 and its associated header and option
   formats as defined for the IPv6 Destination Options header per
   [RFC8200].

   Implementations of this specification also recognize the IPv6
   Extended Fragment Header Option as specified in
   [I-D.templin-6man-ipid-ext2] when it appears in an IPv6 Destination
   Options Header following the IPv4 header.  Requirements for
   encapsulation of extension headers in IPv4 packets are introduced and
   discussed in [I-D.herbert-ipv4-eh].

   IPv4 sources insert an IPv6 Destination Option with an Extended
   Fragment Header in an IPv6 extension header chain that begins
   immediately after the end of the IPv4 header and ends immediately
   before the upper layer protocol header, e.g., TCP, UDP, etc.  The
   source then increments the IPv4 Total Length by the length of the
   extension headers, and sets the IPv4 Protocol field to the protocol
   number of the first extension header.  The source then sets the IPv6
   Destination Options Header Next Header field to the protocol number
   of the next extension header or the upper layer protocol number if
   there are no further extensions.

   The IPv4 source then applies fragmentation if necessary the same as
   for the IPv6 fragmentation procedures specified in
   [I-D.templin-6man-ipid-ext2].  This will produce a sequence of
   fragments each containing a copy of the IPv4 header followed by any
   Per-Fragment headers up to and including the Destination Options
   Header with IPv6 Extended Fragment Header Option (with Index,
   Fragment Offset, M and Identification set appropriately) followed by
   a fragment of the upper layer protocol payload.

   The IPv4 source then sends the fragments to the IPv4 destination
   which accepts and processes them only if it recognizes the IP
   Protocol value of the first extension header.  The destination then
   reassembles per the procedures specified in
   [I-D.templin-6man-ipid-ext2].

Templin                  Expires 22 August 2024                 [Page 3]
Internet-Draft         IP Identification Extension         February 2024

   IPv4 intermediate systems that recognize the IPv6 Destination Options
   Header in IPv4 packets forward packets or fragments that include the
   option if they are no larger than the next hop link MTU; otherwise,
   they drop the packet/fragment and return a PTB message.  Destinations
   that recognize the option perform reassembly and/or return PTB
   messages as necessary under the same conditions specified for the
   IPv6 Extended Fragment Header in [I-D.templin-6man-ipid-ext2].

4.  Destination Qualification and Path MTU

   IPv4 intermediate systems and destinations that do not recognize the
   IPv6 Destination Options Header with Extended Fragment Header Option
   appearing after the IPv4 header unconditionally drop the packet and
   SHOULD return an "ICMPv4 Destination Unreachable - Protocol
   Unreachable" message per [RFC0792].

   The source can therefore test whether the path up to and including
   the destination accepts the IPv6 Destination Options Header and
   Extended Fragment Header Option by occasionally sending "probe"
   packets that include them.  If the source receives an
   acknowledgement, it has assurance that the destination recognizes the
   protocol and that intermediate systems at least forward the protocol
   messages without dropping; the source can instead consider receipt of
   an ICMPv4 Destination Unreachable - Protocol Unreachable as a hint
   that some node in the path rejects the protocol.  The source should
   occasionally re-probe each destination in case routing redirects a
   flow to a different anycast destination.

   The source can also include IPv6 Minimum Path MTU Discovery Hop-by-
   Hop Options in packets/fragments sent to unicast, multicast or
   anycast destinations per [RFC9268].  The source inserts the Hop-by-
   Hop Options Header between the IPv4 header and the Destination
   Options header, then increments the IPv4 Total Length by 8 octets,
   sets the IPv4 Protocol field to 0 (i.e., the protocol number for the
   Hop-by-Hop Options header) and sets the Hop-by-Hop Options Header
   Next Header field to 60.  If the source receives acknowledgements
   that include a {TCP,UDP} MTU/Fragmentation Report Option, the source
   should regard the reported MTU as the largest potential fragment size
   for this destination under current path MTU conditions noting that
   the actual size may be smaller still for some paths.

Templin                  Expires 22 August 2024                 [Page 4]
Internet-Draft         IP Identification Extension         February 2024

5.  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 an ICMPv6 "Packet Too Big (PTB)" message with
   Code 0 [RFC4443] [RFC8201] or an ICMPv4 "Destination Unreachable -
   Fragmentation Needed" message [RFC1191] to the source and discards
   the packet.  This always results in wasted transmissions for which
   the source is required to reduce the size of the packets it is
   sending and retransmit.  (Note: IPv4 intermediate systems that
   recognize the IPv6 Destination Option header with Extended Fragment
   Header Option return ICMPv6 PTB messages instead of ICMPv4 messages.

   IPv4 intermediate systems and destinations that send Code 0 ICMPv6
   PTB messages must therefore employ OMNI UDP/IPv4 encapsulation of
   ICMPv6 messages with IPv4-compatible IPv6 addresses so the messages
   can traverse IPv4 networks [I-D.templin-intarea-omni2].  IPv4 sources
   that include the IPv6 Extended Fragment Header Option must therefore
   monitor the OMNI UDP port for UDP/IPv4-encapsulated ICMPv6 messages.

6.  Requirements

   All nodes that process an IPv6 Destination Options Header with
   Extended Fragment Header Option observe the extension header limits
   specified in [I-D.ietf-6man-eh-limits].

   Intermediate systems that recognize IPv6 extension headers MUST
   forward without dropping IPv4 packets that include a Destination
   Options Header with an Extended Fragment Header Option unless they
   detect a security policy threat through deeper inspection of the
   protocol data that follows.

   Sources MUST include at most one Extended Fragment Header in each
   IPv4 packet/fragment.  Intermediate systems and destinations SHOULD
   silently drop packets/fragments with multiples.

   Destinations that accept flows using Extended Fragment Headers MUST
   configure an EMTU_R of 65535 octets or larger.

   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 or
   singleton segments ranging in size from very small to very large, but
   they are not eligible for fragmentation at any size
   [I-D.templin-intarea-parcels2].

Templin                  Expires 22 August 2024                 [Page 5]
Internet-Draft         IP Identification Extension         February 2024

7.  Implementation Status

   In progress.

8.  IANA Considerations

   This document has no requirements for IANA.

9.  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 IPv4
   reassembly integrity concerns [RFC4963] and also provide an advanced
   degree of packet Identification uniqueness assurance.

   All other security aspects of the IPv6 Extended Fragment Header per
   [I-D.templin-6man-ipid-ext2] apply also to its use in IPv4.

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

11.  References

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

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, DOI 10.17487/RFC0792, September 1981,
              <https://www.rfc-editor.org/info/rfc792>.

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

Templin                  Expires 22 August 2024                 [Page 6]
Internet-Draft         IP Identification Extension         February 2024

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

11.2.  Informative References

   [I-D.herbert-ipv4-eh]
              Herbert, T., "IPv4 Extension Headers and Flow Label", Work
              in Progress, Internet-Draft, draft-herbert-ipv4-eh-02, 15
              December 2023, <https://datatracker.ietf.org/doc/html/
              draft-herbert-ipv4-eh-02>.

   [I-D.ietf-6man-eh-limits]
              Herbert, T., "Limits on Sending and Processing IPv6
              Extension Headers", Work in Progress, Internet-Draft,
              draft-ietf-6man-eh-limits-12, 18 December 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
              limits-12>.

   [I-D.templin-6man-ipid-ext2]
              Templin, F. L., "IPv6 Extended Fragment Header", Work in
              Progress, Internet-Draft, draft-templin-6man-ipid-ext2-00,
              19 February 2024,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              templin-6man-ipid-ext2/>.

Templin                  Expires 22 August 2024                 [Page 7]
Internet-Draft         IP Identification Extension         February 2024

   [I-D.templin-intarea-omni2]
              Templin, F. L., "Transmission of IP Packets over Overlay
              Multilink Network (OMNI) Interfaces", Work in Progress,
              Internet-Draft, draft-templin-intarea-omni2-01, 16
              February 2024,
              <https://datatracker.ietf.org/api/v1/doc/document/draft-
              templin-intarea-omni2/>.

   [I-D.templin-intarea-parcels2]
              Templin, F., "IPv4 Parcels and Advanced Jumbos (AJs)",
              Work in Progress, Internet-Draft, draft-templin-intarea-
              parcels2-00, 15 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-templin-
              intarea-parcels2-00>.

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

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

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

   [RFC9268]  Hinden, R. and G. Fairhurst, "IPv6 Minimum Path MTU Hop-
              by-Hop Option", RFC 9268, DOI 10.17487/RFC9268, August
              2022, <https://www.rfc-editor.org/info/rfc9268>.

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

Templin                  Expires 22 August 2024                 [Page 8]
Internet-Draft         IP Identification Extension         February 2024

   Email: fltemplin@acm.org

Templin                  Expires 22 August 2024                 [Page 9]