Transport Options for UDP
updates
- rfc-768 — User Datagram Protocol
Extracted elements (29)
FRAG is classified as SAFE (Kind=3, within the 0–191 range) despite modifying what UDP user data means, because FRAG is only ever present on fragments with zero-length UDP user data (UDP Length=8). Legacy receivers simply receive zero-length UDP packets and pass them to the application, which is the same behavior as without FRAG.
No static maximum length is imposed on the UDP options area. Past experience with TCP options and IPv4 address limits shows that static bounds are always eventually exceeded. Implementations may impose their own limits, but the specification deliberately avoids codifying one.
The SAFE/UNSAFE distinction is based on whether an option alters UDP user data. Kinds 0–191 are SAFE (ignorable without affecting user data semantics); Kinds 192–255 are UNSAFE (may transform user data). UNSAFE options are restricted to use within FRAG payloads, ensuring legacy receivers see only empty UDP packets and silently discard the modified payload.
UDP's own Length field — unlike TCP/SCTP/DCCP which infer payload size from IP — creates a redundancy with the IP-indicated payload size. This specification exploits that redundancy: setting UDP Length smaller than the IP transport payload creates the surplus area used for options without changing the UDP header format or requiring IP-layer changes.
By default, the UDP option mechanism must produce identical behavior to that experienced by a legacy receiver: all packets (except fragments) are delivered to the application even when OCS, APC, or authentication fails. Option-aware endpoints change behavior only when explicitly configured by the application or upper-layer protocol.
UDP Options do not apply to UDP-Lite (RFC 3828) because UDP-Lite repurposes the UDP Length field to indicate checksum coverage length, which is incompatible with this document's use of that field to delimit the surplus area.
Endpoints supporting UDP Options MUST be capable of fragmenting and reassembling at least two fragments each fitting within the Ethernet MTU of 1,500 bytes. MRDS size MUST be at least 2,926 bytes for IPv4 and 2,886 bytes for IPv6; MRDS segs MUST be at least 2. If no MRDS has been received, a sender MUST assume these minimum values.
Endpoints supporting UDP Options MUST support the eight 'must-support' options: EOL (Kind=0), NOP (Kind=1), APC (Kind=2), FRAG (Kind=3), MDS (Kind=4), MRDS (Kind=5), REQ (Kind=6), and RES (Kind=7). This includes both recognizing and being able to generate each option when configured to do so. New options are not eligible for must-support designation.
Must-support options other than NOP and EOL MUST be placed by the transmitter before all other SAFE UDP Options. AUTH and UENC MUST NOT be used concurrently, because UENC subsumes AUTH's services. Options other than OCS, AUTH, and UENC MUST NOT include fields whose values depend on the contents of the surplus area.
The OCS MUST be non-zero when the UDP checksum is non-zero, and UDP Option implementations MUST default to using a non-zero OCS. If OCS validation fails, all options MUST be silently discarded; however, UDP user data validated by a correct UDP checksum MUST still be delivered to the application unless explicitly configured otherwise.
The UDP Length field MUST be at least 8 (the UDP header length) and no larger than the IP transport payload length. Datagrams with values outside this range MUST be silently dropped and logged. All logging SHOULD be rate limited to prevent resource overloading.
UDP fragments MUST NOT overlap. If overlapping fragments are detected during reassembly, the entire reassembly MUST be abandoned and all fragments discarded without generating ICMP errors. The default reassembly expiration timeout SHOULD be no more than 2 minutes, and reassembly space SHOULD be limited and SHOULD NOT be shared across socket pairs.
UDP Options MUST be processed in the order they appear in the surplus area. Except for FRAG, NOP, EXP, and UEXP, each option SHOULD NOT appear more than once; if duplicated, a receiver MUST interpret only the first instance and MUST ignore subsequent instances.
When UNSAFE Options (Kind 192–255) are present, the UDP user data MUST be empty and any transport payload MUST be carried inside a FRAG Option. Receivers encountering an unsupported UNSAFE option MUST terminate all option processing and MUST silently drop all UDP Options in that datagram.
The UDP surplus area is the region of the IP transport payload that follows the end of the UDP user data, created when the UDP Length field indicates a smaller payload than the IP header implies. This document repurposes the surplus area entirely for UDP Options, effectively redefining the UDP Length field as a 'trailer options offset'.
IANA creates a 'UDP Option Kind Numbers' registry (Expert Review). Kinds 0–7 are assigned as must-support SAFE options; Kind 8 is TIME; Kind 9 is RESERVED for AUTH; Kinds 10–126 are unassigned SAFE; Kind 127 is EXP; Kinds 128–191 are Reserved; Kinds 192–193 are Reserved for UCMP/UENC; Kinds 194–253 are unassigned UNSAFE; Kind 254 is UEXP; Kind 255 is Reserved-UNSAFE. UNSAFE option nicknames must begin with capital 'U'.
Large numbers of UDP Options — whether valid, unknown, or repeating — constitute a DoS attack vector. Requiring must-support options to appear first enables implementations to apply resource limits early. Receivers persistently seeing more than seven consecutive NOPs SHOULD log such events as potential DoS indicators.
On-path attackers can inject, modify, or replay UDP Options since they carry no intrinsic authentication. The OCS detects only accidental errors and errant middleboxes — it is not designed to prevent attacks. The reserved AUTH option is intended to address authentication in a future specification.
Some middleboxes incorrectly compute the UDP checksum over the entire IP payload rather than just the UDP header and payload. The OCS is designed so that, when non-zero, it effectively cancels out the erroneous contribution of the surplus area to the UDP checksum, ensuring traversal compatibility with such middleboxes.
UDP fragmentation and reassembly introduce resource exhaustion risks. Reassembly space SHOULD be limited and SHOULD NOT be shared across socket pairs to prevent cross-socket DoS. Reassembly expiration MUST NOT generate ICMP errors to avoid amplification.
Receiver processing order: (1) If UDP checksum fails, drop entire packet. (2) If OCS is non-zero and fails, or OCS is zero but UDP checksum is non-zero, deliver user data but ignore all options (legacy emulation). (3) If OCS passes or both checksums are zero, deliver user data after parsing and processing all options regardless of whether each succeeds.
APC (Kind=2, Len=6) carries a 4-byte CRC32c of the UDP user data payload only (excluding IP pseudoheader, UDP header, and surplus area) in network byte order. There are no reserved values including zero; the option is simply omitted to indicate 'not used'.
EXP (Kind=127) uses a format of Kind (1 byte) + Len (≥4) + 16-bit ExID + option contents. A Length of 255 triggers the extended format with a 16-bit Extended Length. ExIDs are shared with TCP experimental options and assigned by IANA from a combined TCP/UDP ExID registry.
FRAG (Kind=3) has two formats: non-terminal (Len=10) contains Frag.Start (2 bytes), Identification (4 bytes), Frag.Offset (2 bytes); terminal (Len=12) appends a Reassembled Datagram Option Start (RDOS, 2 bytes) pointer. The 32-bit Identification field combined with the socket 4-tuple uniquely identifies the original datagram.
MDS (Kind=4, Len=4) carries a 16-bit hint of the largest receivable UDP packet or fragment without IP fragmentation. MRDS (Kind=5, Len=5) carries a 16-bit maximum reassembled datagram size and an 8-bit maximum fragment count (MRDS segs). Both are based on the receiver's EMTU_R.
REQ (Kind=6) and RES (Kind=7) each have Len=6 with a 4-byte opaque token field used for UDP packet-level acknowledgment by upper layer protocols such as DPLPMTUD. The token in a RES MUST be a token previously received in a REQ by the transmitter.
The surplus area begins with a 2-byte Option Checksum (OCS) field, aligned to the first 2-byte boundary (relative to the IP datagram start) of the surplus area. Zero padding bytes before OCS must be zero; any non-zero alignment bytes cause all options to be discarded. TLV-encoded UDP options follow immediately after OCS.
TIME (Kind=8, Len=10) carries two 4-byte unsigned timestamp fields: TSval (sender's local monotonic time) and TSecr (echo reply). Zero is reserved to indicate 'not set'; TIME values MUST NOT use zero as a valid time value.
UDP Options use a default format: Kind (1 byte) + Length (1 byte, covering the entire option including Kind and Length, valid for lengths ≤254) + value bytes. When Length=255, an extended format applies: Kind (1 byte) + 0xFF (1 byte) + Extended Length (16-bit, network byte order) + value bytes.