Diff: rfc9868v5.txt - rfc9868.txt

	rfc9868v5.txt	rfc9868.txt

	Internet Engineering Task Force (IETF) J. Touch	Internet Engineering Task Force (IETF) J. Touch
	Request for Comments: 9868 Independent Consultant	Request for Comments: 9868 Independent Consultant
	Updates: 768 C. Heard, Ed.	Updates: 768 C. Heard, Ed.
	Category: Standards Track Unaffiliated	Category: Standards Track Unaffiliated

	ISSN: 2070-1721 September 2025	ISSN: 2070-1721 October 2025

	Transport Options for UDP	Transport Options for UDP

	Abstract	Abstract

	Transport protocols are extended through the use of transport header	Transport protocols are extended through the use of transport header
	options. This document updates RFC 768 (UDP) by indicating the	options. This document updates RFC 768 (UDP) by indicating the
	location, syntax, and semantics for UDP transport layer options	location, syntax, and semantics for UDP transport layer options
	within the surplus area after the end of the UDP user data but before	within the surplus area after the end of the UDP user data but before
	the end of the IP datagram.	the end of the IP datagram.

	skipping to change at line 175 ¶	skipping to change at line 175 ¶
	UNSAFE Options: UDP Options that are not designed to be safely	UNSAFE Options: UDP Options that are not designed to be safely
	ignored by a receiver that does not understand them. Such options	ignored by a receiver that does not understand them. Such options
	could alter the UDP user data or signal a change in what its	could alter the UDP user data or signal a change in what its
	contents represent, but there are restrictions on how they can be	contents represent, but there are restrictions on how they can be
	transmitted; these restrictions are noted in Sections 10 and 12.	transmitted; these restrictions are noted in Sections 10 and 12.

	User: The upper layer application, protocol, or service that	User: The upper layer application, protocol, or service that
	produces and consumes content that UDP transfers.	produces and consumes content that UDP transfers.

	User datagram: A UDP packet, composed of a UDP header and UDP	User datagram: A UDP packet, composed of a UDP header and UDP

	payload; as discussed herein, that payload need not extend to the	payload; as discussed herein, the UDP payload need not extend to
	end of the IP datagram. In this document, the original intent	the end of the IP datagram. In this document, the original intent
	that a UDP datagram corresponds to the user portion of a single IP	that a UDP datagram corresponds to the user portion of a single IP
	datagram is redefined, where a UDP datagram can span more than one	datagram is redefined, where a UDP datagram can span more than one
	IP datagram through UDP fragmentation.	IP datagram through UDP fragmentation.

	4. Background	4. Background

	Many protocols include a default, invariant header and an area for	Many protocols include a default, invariant header and an area for
	header options that varies from packet to packet. These options	header options that varies from packet to packet. These options
	enable the protocol to be extended for use in particular environments	enable the protocol to be extended for use in particular environments
	or in ways unforeseen by the original designers. Examples include	or in ways unforeseen by the original designers. Examples include

	skipping to change at line 934 ¶	skipping to change at line 934 ¶
	have been intentionally overwritten, e.g., by a middlebox to update	have been intentionally overwritten, e.g., by a middlebox to update
	embedded port numbers or IP addresses. Such overwrites could be	embedded port numbers or IP addresses. Such overwrites could be
	intentional and not widely known; defaulting to silent ignore ensures	intentional and not widely known; defaulting to silent ignore ensures
	that option-aware endpoints do not change how users or applications	that option-aware endpoints do not change how users or applications
	operate unless explicitly directed to do otherwise.	operate unless explicitly directed to do otherwise.

	>> UDP packets with unrecognized APC lengths MUST receive the same	>> UDP packets with unrecognized APC lengths MUST receive the same
	treatment as UDP packets with incorrect APC Option checksum fields.	treatment as UDP packets with incorrect APC Option checksum fields.

	Ensuring that unrecognized APC lengths are treated as incorrect	Ensuring that unrecognized APC lengths are treated as incorrect

	checksums enables future variants of APC to be treated like APC.	checksums enables future variants of APC to be treated similarly.

	The APC is reported to the user and useful only per-datagram, because	The APC is reported to the user and useful only per-datagram, because
	fragments have no UDP user data.	fragments have no UDP user data.

	11.4. Fragmentation (FRAG)	11.4. Fragmentation (FRAG)

	The Fragmentation (FRAG, Kind=3) Option supports UDP fragmentation	The Fragmentation (FRAG, Kind=3) Option supports UDP fragmentation
	and reassembly, which can be used to transfer UDP messages larger	and reassembly, which can be used to transfer UDP messages larger
	than allowed by the IP Effective MTU for Receiving (EMTU_R)	than allowed by the IP Effective MTU for Receiving (EMTU_R)
	[RFC1122]. FRAG includes a copy of the same UDP transport ports in	[RFC1122]. FRAG includes a copy of the same UDP transport ports in

	skipping to change at line 1317 ¶	skipping to change at line 1317 ¶

	>> Endpoints supporting UDP Options MUST support a local MRDS size of	>> Endpoints supporting UDP Options MUST support a local MRDS size of
	at least 2,926 bytes for IPv4 and 2,886 bytes for IPv6. Support for	at least 2,926 bytes for IPv4 and 2,886 bytes for IPv6. Support for
	larger values is encouraged.	larger values is encouraged.

	>> Endpoints supporting UDP Options MUST support a local MRDS segs	>> Endpoints supporting UDP Options MUST support a local MRDS segs
	value of at least 2. Support for larger values is encouraged.	value of at least 2. Support for larger values is encouraged.

	These parameters plus the Path MTU (PMTU) allow a sender to compute	These parameters plus the Path MTU (PMTU) allow a sender to compute
	the size of the largest pre-fragmentation UDP packet that a receiver	the size of the largest pre-fragmentation UDP packet that a receiver

	will guarantee to accept. Define MMS_S as the PMTU less the size of	will guarantee to accept. MMS_S is defined as the PMTU less the size
	the IP header and the UDP header, i.e., the maximum UDP message size	of the IP header and the UDP header, i.e., the maximum UDP message
	that can be successfully sent in a single UDP datagram if there are	size that can be successfully sent in a single UDP datagram if there
	no IP options or extension headers and no UDP per-fragment options.	are no IP options or extension headers and no UDP per-fragment
	Then, the size of the largest pre-fragmentation UDP packet that the	options. Given the above size definitions, the size of the largest
	receiver will guarantee to accept is the smaller of the MRDS size and	pre-fragmentation UDP packet that the receiver will guarantee to
		accept is the smaller of the MRDS size and the following:

	(MMS_S - 12) * (MRDS segs) - 2 - (Total Per-Frag IP/UDP Options) + 8	(MMS_S - 12) * (MRDS segs) - 2 - (Total Per-Frag IP/UDP Options) + 8


	where Total Per-Frag IP/UDP Options includes the size of all IP	In the above expression, the Total Per-Frag IP/UDP Options includes
	options and extension headers and all per-fragment UDP Options,	the size of all IP options and extension headers and all per-fragment
	except for OCS and FRAG, that are in the sequence of UDP fragments.	UDP Options, except for OCS and FRAG, that are in the sequence of UDP
		fragments.

	>> If no MRDS Option has been received, a sender MUST assume that	>> If no MRDS Option has been received, a sender MUST assume that
	MRDS size is 2,926 bytes for IPv4 and 2,886 bytes for IPv6 and that	MRDS size is 2,926 bytes for IPv4 and 2,886 bytes for IPv6 and that
	MRDS segs is 2, i.e., the minimum values allowed.	MRDS segs is 2, i.e., the minimum values allowed.

	MRDS is reported to the user, whether used per-datagram or per-	MRDS is reported to the user, whether used per-datagram or per-
	fragment (as defined in Section 11.4). When used per-fragment, the	fragment (as defined in Section 11.4). When used per-fragment, the
	reported value is the minimum of the MRDS values received per-	reported value is the minimum of the MRDS values received per-
	fragment.	fragment.


	skipping to change at line 1699 ¶	skipping to change at line 1701 ¶

	The design of the UNSAFE Options ensures that the resulting UDP data	The design of the UNSAFE Options ensures that the resulting UDP data
	will be silently dropped in both legacy receivers and options-aware	will be silently dropped in both legacy receivers and options-aware
	receivers that do not recognize those options. Again, note that this	receivers that do not recognize those options. Again, note that this
	still results in the delivery of a zero-length UDP packet.	still results in the delivery of a zero-length UDP packet.

	Options-aware receivers can drop UDP packets with option processing	Options-aware receivers can drop UDP packets with option processing
	errors via either an override of the default UDP processing or at the	errors via either an override of the default UDP processing or at the
	application layer.	application layer.


	That is, all options are treated the same, in that the transmitter	Put another way, all options are treated the same, in that the
	can add it as desired and the receiver has the option to require it	transmitter can add each option as desired and the receiver has the
	or not. Only if it is required (e.g., by API configuration) would	choice to require a given option or not. Only if a particular option
	the receiver require it being present and correct.	is indicated as mandatory by a receiver (e.g., by API configuration)
		would the receiver need to confirm it being present and correct.


	That is, for all options:	In summary, for all options:

	* if the option is not required by the receiver, then UDP packets	* if the option is not required by the receiver, then UDP packets
	missing the option are accepted.	missing the option are accepted.

	* if the option is required (e.g., by override of the default	* if the option is required (e.g., by override of the default
	behavior at the receiver) and missing or incorrectly formed,	behavior at the receiver) and missing or incorrectly formed,
	silently drop the UDP packet.	silently drop the UDP packet.

	* if the UDP packet is accepted (either because the option is not	* if the UDP packet is accepted (either because the option is not
	required or because it was required and correct), then pass the	required or because it was required and correct), then pass the

	skipping to change at line 2171 ¶	skipping to change at line 2174 ¶
	not expect to receive more than a few unknown option types per	not expect to receive more than a few unknown option types per
	packet.	packet.

	25.4. Considerations for Fragmentation	25.4. Considerations for Fragmentation

	UDP fragmentation introduces its own set of security concerns, which	UDP fragmentation introduces its own set of security concerns, which
	can be handled in a manner similar to IP reassembly or TCP segment	can be handled in a manner similar to IP reassembly or TCP segment
	reordering [CERT18]. In particular, the number of UDP packets	reordering [CERT18]. In particular, the number of UDP packets
	pending reassembly and effort used for reassembly is typically	pending reassembly and effort used for reassembly is typically
	limited. In addition, it could be useful to assume a reasonable	limited. In addition, it could be useful to assume a reasonable

	minimum fragment size, e.g., that non-terminal fragments are never be	minimum fragment size, e.g., that non-terminal fragments are never
	smaller than 500 bytes.	smaller than 500 bytes.

	>> Implementations concerned with the potential for UDP fragmentation	>> Implementations concerned with the potential for UDP fragmentation
	introducing a vulnerability SHOULD implement limits on the number of	introducing a vulnerability SHOULD implement limits on the number of
	pending fragments.	pending fragments.

	25.5. Considerations for Providing UDP Security	25.5. Considerations for Providing UDP Security

	UDP security is not intended to rely solely on transport layer	UDP security is not intended to rely solely on transport layer
	processing of options. UNSAFE Options are the only type that share	processing of options. UNSAFE Options are the only type that share

	skipping to change at line 2317 ¶	skipping to change at line 2320 ¶

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.	May 2017, <https://www.rfc-editor.org/info/rfc8174>.


	[RFC9869] Fairhurst, G. and T. Jones, "Datagram PLPMTUD for UDP	[RFC9869] Fairhurst, G. and T. Jones, "Datagram Packetization Layer
	Options", RFC 9869, DOI 10.17487/RFC9869, September 2025,	Path MTU Discovery (DPLPMTUD) for UDP Options", RFC 9869,
		DOI 10.17487/RFC9869, October 2025,
	<https://www.rfc-editor.org/info/rfc9869>.	<https://www.rfc-editor.org/info/rfc9869>.

	27.2. Informative References	27.2. Informative References

	[CERT18] CERT Coordination Center, "TCP implementations vulnerable	[CERT18] CERT Coordination Center, "TCP implementations vulnerable
	to Denial of Service", Vulnerability Note VU#962459,	to Denial of Service", Vulnerability Note VU#962459,
	Software Engineering Institute, CMU, 2018,	Software Engineering Institute, CMU, 2018,
	<https://www.kb.cert.org/vuls/id/962459>.	<https://www.kb.cert.org/vuls/id/962459>.

	[Fa18] Fairhurst, G., Jones, T., and R. Zullo, "Checksum	[Fa18] Fairhurst, G., Jones, T., and R. Zullo, "Checksum

	skipping to change at line 2545 ¶	skipping to change at line 2549 ¶
	[RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298,	[RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
	DOI 10.17487/RFC9298, August 2022,	DOI 10.17487/RFC9298, August 2022,
	<https://www.rfc-editor.org/info/rfc9298>.	<https://www.rfc-editor.org/info/rfc9298>.

	[RFC9648] Scharf, M., Jethanandani, M., and V. Murgai, "YANG Data	[RFC9648] Scharf, M., Jethanandani, M., and V. Murgai, "YANG Data
	Model for TCP", RFC 9648, DOI 10.17487/RFC9648, October	Model for TCP", RFC 9648, DOI 10.17487/RFC9648, October
	2024, <https://www.rfc-editor.org/info/rfc9648>.	2024, <https://www.rfc-editor.org/info/rfc9648>.

	[RFC9870] Boucadair, M. and T. Reddy.K, "Export of UDP Options	[RFC9870] Boucadair, M. and T. Reddy.K, "Export of UDP Options
	Information in IP Flow Information Export (IPFIX)",	Information in IP Flow Information Export (IPFIX)",

	RFC 9870, DOI 10.17487/RFC9870, September 2025,	RFC 9870, DOI 10.17487/RFC9870, October 2025,
	<https://www.rfc-editor.org/info/rfc9870>.	<https://www.rfc-editor.org/info/rfc9870>.

	[To18] Touch, J. D., "A TCP Authentication Option Extension for	[To18] Touch, J. D., "A TCP Authentication Option Extension for
	Payload Encryption", Work in Progress, Internet-Draft,	Payload Encryption", Work in Progress, Internet-Draft,
	draft-touch-tcp-ao-encrypt-09, 19 July 2018,	draft-touch-tcp-ao-encrypt-09, 19 July 2018,
	<https://datatracker.ietf.org/doc/html/draft-touch-tcp-ao-	<https://datatracker.ietf.org/doc/html/draft-touch-tcp-ao-
	encrypt-09>.	encrypt-09>.

	[To24] Touch, J. D., "The UDP Authentication Option", Work in	[To24] Touch, J. D., "The UDP Authentication Option", Work in
	Progress, Internet-Draft, draft-touch-tsvwg-udp-auth-opt-	Progress, Internet-Draft, draft-touch-tsvwg-udp-auth-opt-

End of changes. 10 change blocks.
	22 lines changed or deleted	26 lines changed or added
This html diff was produced by rfcdiff 1.48.