IPv6 Jumbograms
obsoletes
- rfc-2147 — TCP and UDP over IPv6 Jumbograms
Extracted elements (23)
The Jumbo Payload option is relevant only for nodes attached to links with MTU greater than 65,575 octets (65,535 + 40-byte IPv6 header), and need not be implemented by nodes that do not support such large-MTU links, keeping the option optional for most deployments.
The TCP Urgent Pointer problem could have been fixed by adding a new TCP Urgent Pointer Option, but since applications using jumbograms are unlikely to also use Urgent Pointers, a less intrusive change analogous to the MSS sentinel value (65,535 = infinity) was chosen instead.
The UDP Length field is set to zero (previously illegal, as minimum UDP packet length is 8) to signal a jumbogram, reusing an impossible value as a flag rather than adding a new extension header or option, minimizing protocol changes.
Nodes that do not understand the Jumbo Payload option respond differently to error conditions: for Payload Length=0 with Hop-by-Hop Next Header they send ICMPv6 Code 0, but for an unrecognized Jumbo Payload option with non-zero Payload Length they send Code 2 (unrecognized option) pointing to the Option Type field.
On links with configurable MTUs, the MTU must not be configured to a value greater than 65,575 octets if nodes attached to that link do not support the Jumbo Payload option and it cannot be guaranteed that jumbograms will not be sent to those nodes.
The 16-bit checksums used by UDP and TCP become less accurate as the length of data being checksummed increases; application designers using jumbograms should take this checksum degradation into consideration.
This document obsoletes RFC 2147 (TCP/UDP enhancements for jumbograms) and merges its content with the Jumbo Payload option specification previously in RFC 1883 (now superseded by RFC 2460 which removed the option).
An implementation of TCP or UDP on an IPv6 node that supports the Jumbo Payload option must include the enhancements specified in this document for handling jumbograms.
For generating or verifying a UDP jumbogram checksum, the actual length of the UDP header plus data (NOT zero) must be used in the checksum pseudo-header.
For TCP input, when a packet is received with the URG bit set and Urgent field of 65,535, the Urgent Pointer must be calculated using an offset equal to the length of the TCP data rather than the value in the Urgent field.
Higher-layer protocols that use the IPv6 Payload Length field to compute the Upper-Layer Packet Length in the checksum pseudo-header must instead use the Jumbo Payload Length field for packets carrying the Jumbo Payload option.
Nodes that understand the Jumbo Payload option are required to detect format errors and, if the erroneous packet was not destined to a multicast address, report the error by sending an ICMP Parameter Problem message to the packet's source.
The Jumbo Payload option MUST NOT be used in a packet that carries a Fragment header.
The Payload Length field in the IPv6 header MUST be set to zero in every packet that carries the Jumbo Payload option.
When determining the TCP MSS to send, if the MTU of the directly attached interface minus 60 is greater than or equal to 65,535, the MSS value must be set to 65,535.
When receiving a UDP packet with Length field of zero but no Jumbo Payload option present, the receiver must use the IPv6 Payload Length field in place of the Jumbo Payload Length field to calculate the actual UDP length.
When sending a UDP packet whose header plus data length exceeds 65,535 octets, the Length field in the UDP header MUST be set to zero; the actual length is conveyed via the Jumbo Payload Length field in the Hop-by-Hop option.
An MSS value of 65,535 received during TCP connection setup is to be treated as infinity. The actual MSS is determined by subtracting 60 from the Path MTU discovered via Path MTU Discovery over the path to the TCP peer.
For TCP Urgent Pointer with jumbograms: if the offset to the urgent data exceeds 65,535 and is greater than or equal to the TCP data length, set the Urgent field to 65,535. If it exceeds 65,535 but is less than the data length, split the TCP packet so the first piece ends within 65,534 bytes of the urgent pointer.
Four distinct format errors are defined for Jumbo Payload processing: (1) Payload Length=0 with Hop-by-Hop Next Header but no Jumbo Payload option present; (2) Payload Length!=0 with Jumbo Payload option present; (3) Jumbo Payload Length < 65,536; (4) Jumbo Payload option and Fragment header both present. Each specifies ICMPv6 Parameter Problem Code and Pointer values.
The Jumbo Payload option is an IPv6 Hop-by-Hop option carrying a 32-bit unsigned integer Jumbo Payload Length field, with Option Type 0xC2 and Opt Data Len of 4. It allows IPv6 packets with payloads between 65,536 and 4,294,967,295 octets. The option has an alignment requirement of 4n+2.
The Jumbo Payload option and TCP/UDP jumbograms do not introduce any known new security concerns.
The Jumbo Payload option wire format: Option Type (8-bit, value 0xC2), Opt Data Len (8-bit, value 4), Jumbo Payload Length (32-bit unsigned integer). The Jumbo Payload Length excludes the IPv6 header but includes the Hop-by-Hop Options header and any other extension headers present.