IPv4 Parcels and Advanced Jumbos (AJs)

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 a parcel/AJ/probe. (Note that this represents a parcel/AJ-specific requirement for IPv4 routers, since [RFC1812] permits other TTL decrement values.)¶

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 a node performs packetization on a {TCP,UDP}/IPv4 parcel, it inserts a Parcel Parameters {TCP,UDP} option the same as for IPv6 [I-D.templin-6man-parcels].¶

The IPv4 destination then performs restoration by gathering up IPv4 packets that arrive with the same upper layer 5-tuple and with Parcel Parameters information including the same Identification. The Parcel Parameters Index then 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 {TCP,UDP} Parcel Parameters option, it simply processes the packet as a singleton IPv4 packet. This would result in correct behavior, but with Generic Receive Offload (GRO) disabled.)¶

3.6. Parcel Probing

When an IPv4 router or destination receives an intact parcel probe, it processes the probe the same as specified for IPv6 [I-D.templin-6man-parcels].¶

When an IPv4 router forwards the parcel probe, it MUST decrement the TTL by exactly 1 the same as specified for the IPv6 Hop Limit.¶

When an IPv4 destination receives a parcel probe, it should return a Parcel Parameters option in any {TCP,UDP}/IPv4 packet to be returned to the source the same as for IPv6.¶

When the IPv4 source receives a {TCP,UDP} packet that includes a Parcel Parameters option it matches the Identification value with its recently-transmitted probes. If there is a match, the source accepts the MTU and Parcel Limit values found in the Parcel Parameters option.¶

The same as for IPv6, the source should send "companion" probes with one including only the IPv4 header followed by the Hop-by-Hop header and the other including an OMNI protocol UDP encapsulation. The source should again accept the more conservative value received for the Residual Path MTU.¶

3.7. Parcel/Jumbo Replys

When an IPv4 router returns a Parcel/Jumbo Reply, it prepares the message in exactly the same way for IPv6 (i.e., including the ICMPv6 message body and Authentication Header encapsulation) then wraps the message in UDP/IPv4 headers for transmission to the source.¶

3.8. 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 maximal reuse of widely deployed code while ensuring interoperability.¶

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      IPv4 Source Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    IPv4 Destination Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      zero     |  Next Header  |        Segment Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Index   |C|S|D|           Parcel Payload Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note: The same as for IPv6, the "Index/C/SD" 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.¶