Internet-Draft IP Parcels December 2023
Templin Expires 15 June 2024 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-templin-intarea-parcels-92
Published:
Intended Status:
Standards Track
Expires:
Author:
F. L. Templin, Ed.
Boeing Research & Technology

IPv4 Parcels and Advanced Jumbos (AJs)

Abstract

IPv6 Parcels and Advanced Jumbos (AJs) present new data packaging constructs and a new link model for Internetworking. As is often the case, technologies developed in the IPv6 space can also be applied in IPv4 and vice-versa. This document presents the adaptations necessary to support Parcels and AJs in 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 15 June 2024.

Table of Contents

1. Introduction

IPv6 Parcels and Advanced Jumbos (AJs) [I-D.templin-6man-parcels] present new data packaging constructs and a new link model for Internetworking. As is often the case, technologies developed in the IPv6 space [RFC8200] can also be applied in IPv4 [RFC0791] and vice-versa. This document presents the differences that need to be addressed to adapt IPv6 Parcels and AJs to IPv4.

All aspects of IPv6 Parcels and AJs, including the use of IPv6 extension headers and control messaging, apply also to IPv4. Only differences in the IP header format and some control option encapsulations need to be accounted for as discussed below. This document therefore specifies IPv4 parcels and AJs.

2. Requirements

IPv4 parcels and AJs observe all requirements established for IPv6 [I-D.templin-6man-parcels] including the use of IPv6 Hop-by-Hop and Destination Options headers. This means that nodes that recognize IPv4 parcels/AJs MUST recognize and correctly process IP protocol 0 (Hop-by-Hop) and IP protocol 60 (Destination) option headers the same as for IPv6 when they occur in an extension header chain following the IPv4 header but before the upper layer payload.

When an IPv4 router or destination end system processes a parcel or AJ for which the IPv4 Protocol field encodes an unrecognized value (such as 0 for Hop-by-Hop or 60 for Destination Options), it drops the parcel/AJ and returns an ICMPv4 "Destination Unreachable - Protocol Unreachable" message [RFC0792]. The source SHOULD regard any such messages as an advisory indication that parcels/AJs may not be supported along this path.

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.

3. IPv4 Parcels and Advanced Jumbos (AJs)

All aspects of [I-D.templin-6man-parcels] are imported as normative specifications for IPv4 parcels and AJs, with the exception of the following differences:

3.1. IPv4 Total Length

The IPv6 header includes a "Payload Length" field defined as the: "Length of the IPv6 payload, i.e., the rest of the packet following this IPv6 header, in octets". The IPv4 header instead includes a "Total Length" field defined as: "the length of the datagram, measured in octets, including internet header and data".

These differences have no bearing for parcels/AJs, for which both the IPv6 Payload Length and IPv4 Total Length values carry identical codes. The same as for IPv6, IPv4 parcels encode the length "L" of the first segment in Total Length, while IPv4 AJs encode a jumbo type value in Total Length.

3.2. IPv4 Time To Live (TTL)

The IPv4 "Time To Live (TTL)" and IPv6 "Hop Limit" values are treated in exactly the same way in both protocol versions. In particular, the source sets the TTL/Hop Limit to an initial value and each router in the path to the destination decrements the TTL/Hop Limit by 1 when it forwards the parcel/AJ.

3.3. IPv4 Parcel/Jumbo Payload Length

The same as for IPv6, the Parcel Payload Length field in the Parcel Payload Option and the Jumbo Payload Length field in the Jumbo Payload Option of IPv4 parcels/AJs encode the length of the IPv6 extension headers plus the length of the {TCP,UDP} header plus the combined length of all concatenated segments with their per-segment headers/trailers.

Therefore, the length of the IPv4 header itself is not included in the Parcel/Jumbo Payload Length field the same as for IPv6. The IPv4 header length for IPv4 parcels and AJs is instead calculated from the IPv4 header Internet Header Length (IHL) field the same as for ordinary IPv4 packets.

3.4. IPv4-Compatible IPv6 Addresses

Whenever an IPv4 address needs to be coded in an IPv6 address field, the address is coded as an IPv4-compatible IPv6 address as specified in [RFC4291].

3.5. IPv4 Parcel Packetization/Restoration

When IPv6 parcels become subject to packetization, the node performing packetization inserts an IPv6 Extended Fragment Header in each packet produced to allow the final destination to restore the original parcel. Since some IPv4 paths may not be able to forward a packet that includes an IPv6 Destination Options header with an Extended Fragment Header option, and since IPv4 destinations that do not recognize the option may be inclined to drop the packet, the Identification field and Parcel Index/P/S codes must be encoded in a different way for IPv4.

For each IPv4 packet created during packetization, the node instead includes a single 8-octet Identification Extension "pseudo-option" at the end of the IPv4 header, where the first octet encodes option Type value '0' ("End of Option List") [RFC0791], the next octet encodes the Index/P/S octet the same as for IPv6 (see: [I-D.templin-6man-parcels]) and the final 6 octets encode the 6 most significant octets of the parcel Identification. The node then writes the 2 least significant octets of the parcel Identification into the IPv4 header Identification field and sets the Don't Fragment (DF) flag to 1.

The IPv4 destination then performs restoration by gathering up IPv4 packets that arrive with the same upper layer 5-tuple and with a pseudo-option coded as above where the Identification components in the IPv4 header and final 6 octets of the pseudo-option both match the other packets. The pseudo-option Index field determines the ordinal position of each packet segment to be concatenated into the restoration buffer, i.e., the same as for IPv6. (Note: if the IPv4 destination does not recognize the pseudo-option encoding, it simply processes the packet as a singleton IPv4 packet. This would result in correct behavior, but would fail to take advantage of Generic Receive Offload (GRO) benefits.)

3.6. Parcel/Jumbo Replys and MTU Reports

When an IPv4 router or destination receives an intact Parcel/Jumbo probe, it can return an immediate Parcel/Jumbo Reply if necessary in an ICMPv6 Packet Too Big (PTB) message prepared the same as for IPv6 but wrapped in UDP/IPv4 encapsulation headers. The Reply will then traverse the IPv4 network on the reverse path to the source.

When an IPv4 destination receives an intact Parcel/Jumbo probe, it should instead return an MTU Report "pseudo-option" in any IPv4 packet to be returned to the source. For each such IPv4 packet, the node includes a single 12-octet option at the end of the IPv4 header where the first two octets encode the option Type value '0' ("End of Option List") [RFC0791], the next 4 octets encode the MTU value to report to the source (i.e., the same as for IPv6) and the final 6 octets encode the 6 most significant octets of the probe Identification. The destination then writes the 2 least significant octets of the probe Identification into the IPv4 header Identification field then sets the Don't Fragment (DF) flag to 1.

When the IPv4 source receives a packet that includes an MTU Report pseudo-option prepared as above, it first matches the IPv4 header Identification field with the least-significant 16 bits of the probe Identification. If the bits match, the source proceeds to match the most-significant 48 bits of the probe Identification with the value found in the final 6 octets of the pseudo-option. If these bits also match, the source then marks the destination as "Parcels/Jumbos supported" and records the MTU value found in the pseudo-option as the path MTU.

3.7. Integrity

To support the IPv4 parcel/AJ header checksum calculation, the network layer uses modified versions of the {TCP,UDP}/IPv4 pseudo-header found in [RFC9293]. Note that while the contents of the two IP protocol version-specific pseudo-headers beyond the address fields are the same, the order in which the contents are arranged differs and must be honored according to the specific IP protocol version.

The IPv6 pseudo-header is found in [I-D.templin-6man-parcels], while the IPv4 pseudo-header is shown in Figure 1. The similarities between the two pseudo-headers allows for maximum reuse of widely deployed code while ensuring interoperability.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      IPv4 Source Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    IPv4 Destination Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      zero     |  Next Header  |        Segment Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Index   |P|S|            Parcel Payload Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: {TCP,UDP}/IPv4 Parcel/AJ Pseudo-Header Format

Note: The same as for IPv6, the Index/P/S and Parcel Payload Length fields in the IPv4 parcel pseudo-header are replaced by the single 4-octet Jumbo Payload Length field in the IPv4 AJ pseudo-header.

4. Implementation Status

An early prototype of UDP/IPv4 parcels (draft version -15) has been implemented relative to the linux-5.10.67 kernel and ION-DTN ion-open-source-4.1.0 source distributions. Patch distribution found at: "https://github.com/fltemplin/ip-parcels.git".

5. IANA Considerations

This document does not include any IANA instructions.

6. Security Considerations

Security Considerations are the same as for IPv6 as found in [I-D.templin-6man-parcels].

7. Acknowledgements

This work was inspired by ongoing AERO/OMNI/DTN investigations. The concepts were further motivated through discussions with colleagues.

Honoring life, liberty and the pursuit of happiness.

8. References

8.1. Normative References

[I-D.templin-6man-parcels]
Templin, F., "IPv6 Parcels and Advanced Jumbos (AJs)", Work in Progress, Internet-Draft, draft-templin-6man-parcels-00, , <https://datatracker.ietf.org/doc/html/draft-templin-6man-parcels-00>.
[RFC0768]
Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, , <https://www.rfc-editor.org/info/rfc768>.
[RFC0791]
Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, , <https://www.rfc-editor.org/info/rfc791>.
[RFC0792]
Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, , <https://www.rfc-editor.org/info/rfc792>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC4291]
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <https://www.rfc-editor.org/info/rfc4291>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <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, , <https://www.rfc-editor.org/info/rfc8200>.
[RFC9293]
Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, , <https://www.rfc-editor.org/info/rfc9293>.

8.2. Informative References

Appendix A. Change Log

<< RFC Editor - remove prior to publication >>

Changes from earlier versions:

Author's Address

Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
United States of America