rfc9869v1.txt		rfc9869.txt
	Internet Engineering Task Force (IETF) G. Fairhurst		Internet Engineering Task Force (IETF) G. Fairhurst
	Request for Comments: 9869 T. Jones		Request for Comments: 9869 T. Jones
	Category: Standards Track University of Aberdeen		Category: Standards Track University of Aberdeen
	ISSN: 2070-1721 September 2025		ISSN: 2070-1721 October 2025
	Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP		Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP
	Options		Options
	Abstract		Abstract
	This document specifies how a UDP Options sender implements Datagram		This document specifies how a UDP Options sender implements Datagram
	Packetization Layer Path MTU Discovery (DPLPMTUD) as a robust method		Packetization Layer Path MTU Discovery (DPLPMTUD) as a robust method
	for Path MTU Discovery (PMTUD). This method uses the UDP Options		for Path MTU Discovery (PMTUD). This method uses the UDP Options
	packetization layer. It allows an application to discover the		packetization layer. It allows an application to discover the
	largest size of datagram that can be sent across a network path. It		largest size of datagram that can be sent across a network path. It
	also provides a way to allow the application to periodically verify		also provides a way to allow the application to periodically verify
	the current maximum packet size supported by a path and to update		the current Maximum Packet Size (MPS) supported by a path and to
	this when required.		update this when required.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	Internet Standards is available in Section 2 of RFC 7841.		Internet Standards is available in Section 2 of RFC 7841.
	skipping to change at line 87 ¶		skipping to change at line 87 ¶
	1. Introduction		1. Introduction
	The User Datagram Protocol (UDP) [RFC0768] offers a minimal transport		The User Datagram Protocol (UDP) [RFC0768] offers a minimal transport
	service on top of IP and is frequently used as a substrate for other		service on top of IP and is frequently used as a substrate for other
	protocols. Section 3.2 of UDP Guidelines [RFC8085] recommends that		protocols. Section 3.2 of UDP Guidelines [RFC8085] recommends that
	applications implement some form of Path MTU Discovery (PMTUD) to		applications implement some form of Path MTU Discovery (PMTUD) to
	avoid the generation of IP fragments:		avoid the generation of IP fragments:
	| Consequently, an application SHOULD either use the path MTU		| Consequently, an application SHOULD either use the path MTU
	| information provided by the IP layer or implement Path MTU		| information provided by the IP layer or implement Path MTU
	| Discovery (PMTUD) ...		| Discovery (PMTUD) itself [RFC1191] [RFC1981] [RFC4821] to
			| determine whether the path to a destination will support its
			| desired message size without fragmentation.
	The UDP API [RFC8304] offers calls for applications to receive ICMP		The UDP API [RFC8304] offers calls for applications to receive ICMP
	Packet Too Big (PTB) messages and to control the maximum size of		Packet Too Big (PTB) messages and to control the maximum size of
	datagrams that are sent, but it does not offer any automated		datagrams that are sent, but it does not offer any automated
	mechanisms for an application to discover the maximum packet size		mechanisms for an application to discover the MPS supported by a
	supported by a path. Upper Layer protocols, which include		path. Upper Layer protocols, which include applications, can
	applications, can implement mechanisms for PMTUD above the UDP API.		implement mechanisms for PMTUD above the UDP API.
	Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes		Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] describes
	a method for a bidirectional Packetization Layer (PL) to search for		a method for a bidirectional Packetization Layer (PL) to search for
	the largest Packetization Layer PMTU (PLPMTU) supported on a path.		the largest Packetization Layer PMTU (PLPMTU) supported on a path.
	DPLPMTUD [RFC8899] specifies this support for datagram transports.		DPLPMTUD [RFC8899] specifies this support for datagram transports.
	PLPMTUD and DPLPMTUD gain robustness by using a probing mechanism		PLPMTUD and DPLPMTUD gain robustness by using a probing mechanism
	that does not solely rely on ICMP PTB messages and works on paths		that does not solely rely on ICMP PTB messages and works on paths
	that drop ICMP PTB messages.		that drop ICMP PTB messages.
	UDP Options [RFC9868] supplies functionality that can be used to		UDP Options [RFC9868] supplies functionality that can be used to
	implement DPLPMTUD within the transport service or in an Upper Layer		implement DPLPMTUD within the transport service or in an Upper Layer
	protocol (including an application) that uses UDP Options. This		protocol (including an application) that uses UDP Options. This
	document specifies how DPLPMTUD using UDP Options is implemented		document specifies how DPLPMTUD using UDP Options is implemented
	(Section 6.1 of [RFC8899]) and requires support to be enabled at both		(Section 6.1 of [RFC8899]) and requires support to be enabled at both
	the sender and receiver.		the sender and receiver.
	Implementing DPLPMTUD within the transport service above UDP Options		Implementing DPLPMTUD within the transport service above UDP Options
	avoids the need for each Upper Layer protocol to implement the		avoids the need for each Upper Layer protocol to implement the
	DPLPMTUD method. It provides a standard method for applications to		DPLPMTUD method. It provides a standard method for applications to
	discover the current maximum packet size for a path and to detect		discover the current MPS for a path and to detect when this changes.
	when this changes. It can be used with Equal-Cost Multipath (ECMP)		It can be used with Equal-Cost Multipath (ECMP) routing and/or
	routing and/or multihoming. If multipath or multihoming is		multihoming. If multipath or multihoming is supported, a state
	supported, a state machine is needed for each path.		machine is needed for each path.
	DPLPMTUD is not specified for multicast. The method requires		DPLPMTUD is not specified for multicast. The method requires
	explicit acknowledgement of probe packets provided by UDP Options,		explicit acknowledgement of probe packets provided by UDP Options,
	which is primarily intended for unicast use (see Section 23 of		which is primarily intended for unicast use (see Section 23 of
	[RFC9868]).		[RFC9868]).
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	skipping to change at line 167 ¶		skipping to change at line 169 ¶
	DPLPMTUD can be implemented over UDP Options in two ways:		DPLPMTUD can be implemented over UDP Options in two ways:
	* Implementation within the UDP transport service.		* Implementation within the UDP transport service.
	* Implementation in an Upper Layer protocol (or application) that		* Implementation in an Upper Layer protocol (or application) that
	uses UDP Options.		uses UDP Options.
	When DPLPMTUD is implemented within the UDP transport service, the		When DPLPMTUD is implemented within the UDP transport service, the
	DPLPMTUD state machine is responsible for sending probe packets to		DPLPMTUD state machine is responsible for sending probe packets to
	determine a PLPMTU, as described in this document (and hence the		determine a PLPMTU, as described in this document. This determines
	Maximum Packet Size (MPS), the largest size of application data block		an MPS, the largest size of application data block that can be sent
	that can be sent across a network path using a single datagram). The		across a network path using a single datagram. The Upper Layer
	Upper Layer protocol is responsible for deciding when a session		protocol is responsible for deciding when a session enables DPLPMTUD.
	enables DPLPMTUD.
	The discovered PLPMTU can be used to either:		The discovered PLPMTU can be used to either:
	* set the maximum datagram size for the current path or		* set the maximum datagram size for the current path or
	* set the maximum fragment size when a sender uses the UDP		* set the maximum fragment size when a sender uses the UDP
	Fragmentation Option to divide a datagram into multiple UDP		Fragmentation Option to divide a datagram into multiple UDP
	fragments for transmission. The size of each UDP fragment is then		fragments for transmission. The size of each UDP fragment is then
	less than or equal to the size of the discovered largest IP packet		less than or equal to the size of the discovered largest IP packet
	that can be received across the current path.		that can be received across the current path.
	skipping to change at line 212 ¶		skipping to change at line 213 ¶
	^ | Messages (with UDP Options)		^ | Messages (with UDP Options)
	| | Send/Receive: Probes with Options		| | Send/Receive: Probes with Options
	| receive send v Events: ICMP, Interface MTU, etc.		| receive send v Events: ICMP, Interface MTU, etc.
	+---+----------------------------+		+---+----------------------------+
	| UDP Options Transport |		| UDP Options Transport |
	+---------------------------+----+		+---------------------------+----+
	^ | Datagrams (with UDP Options)		^ | Datagrams (with UDP Options)
	| | Fragmented Datagrams with UDP Options		| | Fragmented Datagrams with UDP Options
	| receive send v Events: ICMP, Interface MTU, etc.		| receive send v Events: ICMP, Interface MTU, etc.
	Note: UDP allows an Upper Layer protocol to send datagrams with or		| Note: UDP allows an Upper Layer protocol to send datagrams with
	without payload data (with or without UDP Options). These are		| or without payload data (with or without UDP Options). These
	delivered across the network to the remote Upper Layer. When		| are delivered across the network to the remote Upper Layer.
	DPLPMTUD is implemented within the UDP transport service, probe		| When DPLPMTUD is implemented within the UDP transport service,
	packets that include a REQ or RES UDP Option can be sent with no UDP		| probe packets that include a REQ or RES UDP Option can be sent
	payload. In this case, these probe packets were not generated by a		| with no UDP payload. In this case, these probe packets were
	sending application; therefore, the corresponding received datagrams		| not generated by a sending application; therefore, the
	are not delivered to the remote application.		| corresponding received datagrams are not delivered to the
			| remote application.
	When DPLPMTUD is instead implemented by an Upper Layer protocol, the		When DPLPMTUD is instead implemented by an Upper Layer protocol, the
	format and content of probe packets are determined by the Upper Layer		format and content of probe packets are determined by the Upper Layer
	protocol. This design is also permitted to use the REQ and RES		protocol. This design is also permitted to use the REQ and RES
	Options provided by UDP Options.		Options provided by UDP Options.
	If DPLPMTUD is active at more than one layer, then the values of the		If DPLPMTUD is active at more than one layer, then the values of the
	tokens used in REQ Options need to be coordinated with any values		tokens used in REQ Options need to be coordinated with any values
	used for other DPLPMTUD probe packets to ensure that each probe		used for other DPLPMTUD probe packets to ensure that each probe
	packet can be identified by a unique token. When configurable, a		packet can be identified by a unique token. When configurable, a
	skipping to change at line 317 ¶		skipping to change at line 319 ¶
	datagram with the REQ Option.		datagram with the REQ Option.
	The operation of DPLPMTUD can depend on the support at the remote UDP		The operation of DPLPMTUD can depend on the support at the remote UDP
	Options endpoint, the way in which DPLPMTUD is implemented, and in		Options endpoint, the way in which DPLPMTUD is implemented, and in
	some cases, the application data that is exchanged over the UDP		some cases, the application data that is exchanged over the UDP
	transport service. When UDP Options is not supported by the remote		transport service. When UDP Options is not supported by the remote
	receiver, DPLPMTUD will be unable to confirm the path or to discover		receiver, DPLPMTUD will be unable to confirm the path or to discover
	the PLPMTU. This will result in the minimum configured PLPMTU		the PLPMTU. This will result in the minimum configured PLPMTU
	(MIN_PLPMTU). More explanation of usage is provided in Section 6.		(MIN_PLPMTU). More explanation of usage is provided in Section 6.
	Note: A receiver that only responds when there is a datagram queued		| Note: A receiver that only responds when there is a datagram
	for transmission by the Upper Layer could potentially receive		| queued for transmission by the Upper Layer could potentially
	multiple datagrams with a REQ Option before it can respond. When		| receive multiple datagrams with a REQ Option before it can
	sent, the RES Option will only acknowledge the latest received token		| respond. When sent, the RES Option will only acknowledge the
	value. A sender would then conclude that any earlier REQ Options		| latest received token value. A sender would then conclude that
	were not successfully received. However, DPLPMTUD does not usually		| any earlier REQ Options were not successfully received.
	result in sending more than one probe packet per timeout interval,		| However, DPLPMTUD does not usually result in sending more than
	and a delay in responding will already have been treated as a failed		| one probe packet per timeout interval, and a delay in
	probe attempt. Therefore, this does not significantly impact		| responding will already have been treated as a failed probe
	performance, although a more prompt response would have resulted in		| attempt. Therefore, this does not significantly impact
	DPLPMTUD recording reception of all probe packets.		| performance, although a more prompt response would have
			| resulted in DPLPMTUD recording reception of all probe packets.
	4. DPLPMTUD Sender Procedures for UDP Options		4. DPLPMTUD Sender Procedures for UDP Options
	DPLPMTUD utilizes three types of probe. These are described in the		DPLPMTUD utilizes three types of probe. These are described in the
	following sections:		following sections:
	* Probes to confirm the path can support the BASE_PLPMTU		* Probes to confirm the path can support the BASE_PLPMTU
	(Section 5.1.4 of [RFC8899]).		(Section 5.1.4 of [RFC8899]).
	* Probes to detect whether the path can support a larger PLPMTU.		* Probes to detect whether the path can support a larger PLPMTU.
	skipping to change at line 363 ¶		skipping to change at line 366 ¶
	the reception of a packet of the probed size that has successfully		the reception of a packet of the probed size that has successfully
	traversed the path to the receiver. This also confirms that the		traversed the path to the receiver. This also confirms that the
	remote endpoint supports the RES Option.		remote endpoint supports the RES Option.
	4.2. Sending Probe Packets to Increase the PLPMTU		4.2. Sending Probe Packets to Increase the PLPMTU
	From time to time, DPLPMTUD enters the SEARCHING state, described in		From time to time, DPLPMTUD enters the SEARCHING state, described in
	Section 5.2 of [RFC8899], (e.g., after expiry of the		Section 5.2 of [RFC8899], (e.g., after expiry of the
	PMTU_RAISE_TIMER) to detect whether the current path can support a		PMTU_RAISE_TIMER) to detect whether the current path can support a
	larger PLPMTU. When the remote endpoint advertises a UDP Maximum		larger PLPMTU. When the remote endpoint advertises a UDP Maximum
	Datagram Size (MDS) option (see Section 11.5 of [RFC9868]), this		Datagram Size (MDS) Option (see Section 11.5 of [RFC9868]), this
	value MAY be used as a hint to initialize this search to increase the		value MAY be used as a hint to initialize this search to increase the
	PLPMTU.		PLPMTU.
	Probe packets seeking to increase the PLPMTU SHOULD NOT carry		Probe packets seeking to increase the PLPMTU SHOULD NOT carry
	application data (see "Probing using padding data" in Section 4.1 of		application data (see "Probing using padding data" in Section 4.1 of
	[RFC8899]), since they will be lost whenever their size exceeds the		[RFC8899]), since they will be lost whenever their size exceeds the
	actual PMTU. [RFC8899] requires a probe packet to elicit a positive		actual PMTU. [RFC8899] requires a probe packet to elicit a positive
	acknowledgement that the path has delivered a datagram of the		acknowledgement that the path has delivered a datagram of the
	specific probed size; therefore, when using [RFC9868], a probe packet		specific probed size; therefore, a probe packet MUST include the REQ
	MUST include the REQ Option.		Option when using transport options for UDP [RFC9868].
	At the receiver, a received probe packet that does not carry		At the receiver, a received probe packet that does not carry
	application data does not form a part of the end-to-end transport		application data does not form a part of the end-to-end transport
	data and is not delivered to the Upper Layer protocol (i.e.,		data and is not delivered to the Upper Layer protocol (i.e.,
	application or protocol layered above UDP). A zero-length payload		application or protocol layered above UDP). A zero-length payload
	notification could still be delivered to the application (see		notification could still be delivered to the application (see
	Section 5 of [RFC8085]), although Section 18 of [RFC9868] discusses		Section 5 of [RFC8085]), although Section 18 of [RFC9868] discusses
	the implications when using UDP Options.		the implications when using UDP Options.
	4.3. Validating the Path with UDP Options		4.3. Validating the Path with UDP Options
	A PL using DPLPMTUD MUST validate that a path continues to support		A PL using DPLPMTUD MUST validate that a path continues to support
	the PLPMTU discovered in a previous search for a suitable PLPMTU		the PLPMTU discovered in a previous search for a suitable PLPMTU
	value, as defined in Section 6.1.4 of [RFC8899]. This validation		value, as defined in Section 6.1.4 of [RFC8899]. This validation
	sends probe packets in the DPLPMTUD SEARCH_COMPLETE state to detect		sends probe packets in the DPLPMTUD SEARCH_COMPLETE state
	black-holing of data (Section 5.2 of [RFC8899], Section 4.3 of		(Section 5.2 of [RFC8899]) to detect black-holing of data
	[RFC8899] defines a DPLPMTUD black hole).		(Section 4.3 of [RFC8899] defines a DPLPMTUD black hole).
	Path validation can be implemented within UDP Options by generating a		Path validation can be implemented within UDP Options by generating a
	probe packet of size PLPMTU, which MUST include a REQ Option to		probe packet of size PLPMTU, which MUST include a REQ Option to
	elicit a positive confirmation that the path has delivered this probe		elicit a positive confirmation that the path has delivered this probe
	packet. A probe packet used to validate the path MAY use either		packet. A probe packet used to validate the path MAY use either
	"Probing using padding data" to construct a probe packet that does		"Probing using padding data" to construct a probe packet that does
	not carry any application data (see Section 4.1 of [RFC8899]) or		not carry any application data or "Probing using application data and
	"Probing using application data and padding data" (see Section 4.1 of		padding data"; see Section 4.1 of [RFC8899]. When using "Probing
	[RFC8899]). When using "Probing using padding data", the UDP Options		using padding data", the UDP Options API does not indicate receipt of
	API does not indicate receipt of the zero-length probe packet (see		the zero-length probe packet (see Section 6 of [RFC9868]).
	Section 6 of [RFC9868]).
	4.4. Probe Packets That Do Not Include Application Data		4.4. Probe Packets That Do Not Include Application Data
	A simple implementation of the method might be designed to only use		A simple implementation of the method might be designed to only use
	probe packets in a UDP datagram that includes no application data.		probe packets in a UDP datagram that includes no application data.
	The size of each probe packet is padded to the required probe size		The size of each probe packet is padded to the required probe size
	including the REQ Option. This implements "Probing using padding		including the REQ Option. This implements "Probing using padding
	data" (Section 4.1 of [RFC8899]) and avoids having to retransmit		data" (Section 4.1 of [RFC8899]) and avoids having to retransmit
	application data when a probe fails. This could be achieved by		application data when a probe fails. This could be achieved by
	setting a minimum datagram length, such that the options list ends in		setting a minimum datagram length, such that the options list ends in
	skipping to change at line 511 ¶		skipping to change at line 513 ¶
	When enabled, a DPLPMTUD endpoint that implements UDP Options		When enabled, a DPLPMTUD endpoint that implements UDP Options
	normally responds with a UDP datagram with a RES Option when		normally responds with a UDP datagram with a RES Option when
	requested by a sender.		requested by a sender.
	The following examples describe various possible receiver behaviors:		The following examples describe various possible receiver behaviors:
	* No DPLPMTUD receiver support: One case is when a sender supports		* No DPLPMTUD receiver support: One case is when a sender supports
	this specification, but no RES Option is received from the remote		this specification, but no RES Option is received from the remote
	endpoint. In this example, the method is unable to discover the		endpoint. In this example, the method is unable to discover the
	PLPMTU. This will result in using the minimum configured PLPMTU		PLPMTU. This will result in using the MIN_PLPMTU. Such a remote
	(MIN_PLPMTU). Such a remote endpoint might be not configured to		endpoint might be not configured to process UDP Options or might
	process UDP Options or might not return a datagram with a RES		not return a datagram with a RES Option for some other reason
	Option for some other reason (e.g., packet loss, insufficient		(e.g., packet loss, insufficient space to include the option,
	space to include the option, filtering on the path, etc.).		filtering on the path, etc.).
	* DPLPMTUD receiver uses application datagrams: In a second case,		* DPLPMTUD receiver uses application datagrams: In a second case,
	both the sender and receiver support DPLPMTUD using the		both the sender and receiver support DPLPMTUD using the
	specification, and the receiver only returns a RES Option with the		specification, and the receiver only returns a RES Option with the
	next UDP datagram that is sent to the requester. Therefore,		next UDP datagram that is sent to the requester. Therefore,
	reception of a REQ Option does not systematically trigger a		reception of a REQ Option does not systematically trigger a
	response. This allows DPLPMTUD to operate when there is a flow of		response. This allows DPLPMTUD to operate when there is a flow of
	datagrams in both directions, provided there is periodic feedback		datagrams in both directions, provided there is periodic feedback
	(e.g., one acknowledgement packet per RTT). It requires the		(e.g., one acknowledgement packet per RTT). It requires the
	PLPMTU at the receiver to be sufficiently large enough that the		PLPMTU at the receiver to be sufficiently large enough that the
	RES Option can be included in the feedback packets that are sent		RES Option can be included in the feedback packets that are sent
	in the return direction. This method avoids opportunities to		in the return direction. This method avoids opportunities to
	misuse the method as a DoS attack. However, when there is a low		misuse the method as a DoS attack. However, when there is a low
	rate of transmission (or no datagrams are sent) in the return		rate of transmission (or no datagrams are sent) in the return
	direction, this will prevent prompt delivery of the RES Option.		direction, this will prevent prompt delivery of the RES Option.
	At the DPLPMTUD sender, this results in probe packets failing to		At the DPLPMTUD sender, this results in probe packets failing to
	be acknowledged in time and could result in a smaller PLPMTU than		be acknowledged in time and could result in a smaller PLPMTU than
	is actually supported by the path or in using the minimum		is actually supported by the path or in using the MIN_PLPMTU.
	configured PLPMTU (MIN_PLPMTU).
	* Unidirectional transfer: Another case is where an application only		* Unidirectional transfer: Another case is where an application only
	transfers data in one direction (or predominantly in one		transfers data in one direction (or predominantly in one
	direction). In this case, the wait at the receiver for a datagram		direction). In this case, the wait at the receiver for a datagram
	to be queued before returning a RES Option could easily result in		to be queued before returning a RES Option could easily result in
	a probe timeout at the DPLPMTUD sender. In this case, DPLPMTUD		a probe timeout at the DPLPMTUD sender. In this case, DPLPMTUD
	could allow exchanging datagrams without a payload (as discussed		could allow exchanging datagrams without a payload (as discussed
	in earlier sections) to return the RES Option.		in earlier sections) to return the RES Option.
	* DPLPMTUD receiver permitted to send responses in UDP datagrams		* DPLPMTUD receiver permitted to send responses in UDP datagrams
	skipping to change at line 624 ¶		skipping to change at line 625 ¶
	[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>.
	[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.		[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
	Völker, "Packetization Layer Path MTU Discovery for		Völker, "Packetization Layer Path MTU Discovery for
	Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,		Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
	September 2020, <https://www.rfc-editor.org/info/rfc8899>.		September 2020, <https://www.rfc-editor.org/info/rfc8899>.
	[RFC9868] Touch, J. and C. Heard, Ed., "Transport Options for UDP",		[RFC9868] Touch, J. and C. Heard, Ed., "Transport Options for UDP",
	RFC 9868, DOI 10.17487/RFC9868, September 2025,		RFC 9868, DOI 10.17487/RFC9868, October 2025,
	<https://www.rfc-editor.org/info/rfc9868>.		<https://www.rfc-editor.org/info/rfc9868>.
	9.2. Informative References		9.2. Informative References
	[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	DOI 10.17487/RFC1191, November 1990,		DOI 10.17487/RFC1191, November 1990,
	<https://www.rfc-editor.org/info/rfc1191>.		<https://www.rfc-editor.org/info/rfc1191>.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,		Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
End of changes. 15 change blocks.
	54 lines changed or deleted		55 lines changed or added
This html diff was produced by rfcdiff 1.48.