draft-ietf-tsvwg-datagram-plpmtud-11.txt		draft-ietf-tsvwg-datagram-plpmtud-12.txt
	Internet Engineering Task Force G. Fairhurst		Internet Engineering Task Force G. Fairhurst
	Internet-Draft T. Jones		Internet-Draft T. Jones
	Updates4821 (if approved) University of Aberdeen		Updates4821 (if approved) University of Aberdeen
	Intended status: Standards Track M. Tuexen		Intended status: Standards Track M. Tuexen
	Expires: 23 May 2020 I. Ruengeler		Expires: 7 June 2020 I. Ruengeler
	T. Voelker		T. Voelker
	Muenster University of Applied Sciences		Muenster University of Applied Sciences
	20 November 2019		5 December 2019
	Packetization Layer Path MTU Discovery for Datagram Transports		Packetization Layer Path MTU Discovery for Datagram Transports
	draft-ietf-tsvwg-datagram-plpmtud-11		draft-ietf-tsvwg-datagram-plpmtud-12
	Abstract		Abstract
	This document describes a robust method for Path MTU Discovery		This document describes a robust method for Path MTU Discovery
	(PMTUD) for datagram Packetization Layers (PLs). It describes an		(PMTUD) for datagram Packetization Layers (PLs). It describes an
	extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path		extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path
	MTU Discovery for IPv4 and IPv6. The method allows a PL, or a		MTU Discovery for IPv4 and IPv6. The method allows a PL, or a
	datagram application that uses a PL, to discover whether a network		datagram application that uses a PL, to discover whether a network
	path can support the current size of datagram. This can be used to		path can support the current size of datagram. This can be used to
	detect and reduce the message size when a sender encounters a network		detect and reduce the message size when a sender encounters a network
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 23 May 2020.		This Internet-Draft will expire on 7 June 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 11, line 27 ¶		skipping to change at page 11, line 27 ¶
	7. Probing and congestion control: The DPLPMTUD sender treats		7. Probing and congestion control: The DPLPMTUD sender treats
	isolated loss of a probe packet (with or without a corresponding		isolated loss of a probe packet (with or without a corresponding
	PTB message) as a potential indication of a PMTU limit for the		PTB message) as a potential indication of a PMTU limit for the
	path. Loss of a probe packet SHOULD NOT be treated as an		path. Loss of a probe packet SHOULD NOT be treated as an
	indication of congestion. The loss of a probe packet SHOULD NOT		indication of congestion. The loss of a probe packet SHOULD NOT
	directly trigger a congestion control reaction [RFC4821] because		directly trigger a congestion control reaction [RFC4821] because
	this could result in unecessary reduction of the sending rate.		this could result in unecessary reduction of the sending rate.
	The interval between probe packets MUST be at least one RTT.		The interval between probe packets MUST be at least one RTT.
	8. Shared PLPMTU state: The PLPMTU value MAY also be stored with the		8. Shared PLPMTU state: The PLPMTU value MAY also be stored with the
	corresponding entry in the destination cache and used by other PL		corresponding entry associated with the destination in the IP
	instances. The specification of PLPMTUD [RFC4821] states: "If		layer cache, and used by other PL instances. The specification
	PLPMTUD updates the MTU for a particular path, all Packetization		of PLPMTUD [RFC4821] states: "If PLPMTUD updates the MTU for a
	Layer sessions that share the path representation (as described		particular path, all Packetization Layer sessions that share the
	in Section 5.2 of [RFC4821]) SHOULD be notified to make use of		path representation (as described in Section 5.2 of [RFC4821])
	the new MTU". Such methods MUST be robust to the wide variety of		SHOULD be notified to make use of the new MTU". Such methods
	underlying network forwarding behaviors. Section 5.2 of		MUST be robust to the wide variety of underlying network
	[RFC8201] provides guidance on the caching of PMTU information		forwarding behaviors. Section 5.2 of [RFC8201] provides guidance
	and also the relation to IPv6 flow labels.		on the caching of PMTU information and also the relation to IPv6
			flow labels.
	In addition, the following principles are stated for design of a		In addition, the following principles are stated for design of a
	DPLPMTUD method:		DPLPMTUD method:
	* MPS: A method is REQUIRED to signal an appropriate MPS to the		* MPS: A method is REQUIRED to signal an appropriate MPS to the
	higher layer using the PL. The value of the MPS can change		higher layer using the PL. The value of the MPS can change
	following a change to the path. It is RECOMMENDED that methods		following a change to the path. It is RECOMMENDED that methods
	avoid forcing an application to use an arbitrary small MPS		avoid forcing an application to use an arbitrary small MPS
	(PLPMTU) for transmission while the method is searching for the		(PLPMTU) for transmission while the method is searching for the
	currently supported PLPMTU. Datagram PLs do not necessarily		currently supported PLPMTU. Datagram PLs do not necessarily
	skipping to change at page 16, line 30 ¶		skipping to change at page 16, line 30 ¶
	A set of checks are intended to provide protection from a router that		A set of checks are intended to provide protection from a router that
	reports an unexpected PTB_SIZE. The PL also needs to check that the		reports an unexpected PTB_SIZE. The PL also needs to check that the
	indicated PTB_SIZE is less than the size used by probe packets and		indicated PTB_SIZE is less than the size used by probe packets and
	larger than minimum size accepted.		larger than minimum size accepted.
	This section provides a summary of how PTB messages can be utilized.		This section provides a summary of how PTB messages can be utilized.
	This processing depends on the PTB_SIZE and the current value of a		This processing depends on the PTB_SIZE and the current value of a
	set of variables:		set of variables:
	PTB_SIZE < MIN_MTU		PTB_SIZE < MIN_PMTU
	* Invalid PTB_SIZE see Section 4.5.1.		* Invalid PTB_SIZE see Section 4.5.1.
	* PTB message ought to be discarded without further processing		* PTB message ought to be discarded without further processing
	(e. g. PLPMTU not modified).		(e. g. PLPMTU not modified).
	* The information could be utilized as an input to trigger		* The information could be utilized as an input to trigger
	enabling a resilience mode.		enabling a resilience mode.
	MIN_PMTU < PTB_SIZE < BASE_PMTU		MIN_PMTU < PTB_SIZE < BASE_PMTU
	* A robust PL MAY enter an error state (see Section 5.2) for an		* A robust PL MAY enter an error state (see Section 5.2) for an
	IPv4 path when the PTB_SIZE reported in the PTB message is		IPv4 path when the PTB_SIZE reported in the PTB message is
	larger than or equal to 68 bytes and when this is less than the		larger than or equal to 68 bytes [RFC0791] and when this is
	BASE_PMTU.		less than the BASE_PMTU.
	* A robust PL MAY enter an error state (see Section 5.2) for an		* A robust PL MAY enter an error state (see Section 5.2) for an
	IPv6 path when the PTB_SIZE reported in the PTB message is		IPv6 path when the PTB_SIZE reported in the PTB message is
	larger than or equal to 1280 bytes and when this is less than		larger than or equal to 1280 bytes [RFC8200] and when this is
	the BASE_PMTU.		less than the BASE_PMTU.
	PTB_SIZE = PLPMTU		PTB_SIZE = PLPMTU
	* Completes the search for a larger PLPMTU.		* Completes the search for a larger PLPMTU.
	PTB_SIZE > PROBED_SIZE		PTB_SIZE > PROBED_SIZE
	* Inconsistent network signal.		* Inconsistent network signal.
	* PTB message ought to be discarded without further processing		* PTB message ought to be discarded without further processing
	(e. g. PLPMTU not modified).		(e. g. PLPMTU not modified).
	skipping to change at page 20, line 11 ¶		skipping to change at page 20, line 11 ¶
	MAX_PROBES: The MAX_PROBES is the maximum value of the PROBE_COUNT		MAX_PROBES: The MAX_PROBES is the maximum value of the PROBE_COUNT
	counter (see Section 5.1.3). MAX_PROBES represents the		counter (see Section 5.1.3). MAX_PROBES represents the
	limit for the number of consecutive probe attempts of		limit for the number of consecutive probe attempts of
	any size. The default value of MAX_PROBES is 3. This		any size. The default value of MAX_PROBES is 3. This
	value is greater than 1 to provide robustness to		value is greater than 1 to provide robustness to
	isolated packet loss.		isolated packet loss.
	MIN_PMTU: The MIN_PMTU is the smallest allowed probe packet size.		MIN_PMTU: The MIN_PMTU is the smallest allowed probe packet size.
	For IPv6, this value is 1280 bytes, as specified in		For IPv6, this value is 1280 bytes, as specified in
	[RFC2460]. For IPv4, the minimum value is 68 bytes.		[RFC8200]. For IPv4, the minimum value is 68 bytes.
	Note: An IPv4 router is required to be able to forward a		Note: An IPv4 router is required to be able to forward a
	datagram of 68 bytes without further fragmentation.		datagram of 68 bytes without further fragmentation.
	This is the combined size of an IPv4 header and the		This is the combined size of an IPv4 header and the
	minimum fragment size of 8 bytes. In addition,		minimum fragment size of 8 bytes. In addition,
	receivers are required to be able to reassemble		receivers are required to be able to reassemble
	fragmented datagrams at least up to 576 bytes, as stated		fragmented datagrams at least up to 576 bytes, as stated
	in section 3.3.3 of [RFC1122].		in section 3.3.3 of [RFC1122].
	MAX_PMTU: The MAX_PMTU is the largest size of PLPMTU. This has to		MAX_PMTU: The MAX_PMTU is the largest size of PLPMTU. This has to
	be less than or equal to the minimum of the local MTU of		be less than or equal to the minimum of the local MTU of
	the outgoing interface and the destination PMTU for		the outgoing interface and the destination PMTU for
	receiving. An application, or PL, MAY choose a smaller		receiving. An application, or PL, MAY choose a smaller
	MAX_PMTU when there is no need to send packets larger		MAX_PMTU when there is no need to send packets larger
	than a specific size.		than a specific size.
	BASE_PMTU: The BASE_PMTU is a configured size expected to work for		BASE_PMTU: The BASE_PMTU is a configured size expected to work for
	most paths. The size is equal to or larger than the		most paths. The size is equal to or larger than the
	MIN_PMTU and smaller than the MAX_PMTU. In the case of		MIN_PMTU and smaller than the MAX_PMTU. In the case of
	IPv6, this value is 1280 bytes [RFC2460]. When using		IPv6, this value is 1280 bytes [RFC8200]. When using
	IPv4, a size of 1200 bytes is RECOMMENDED.		IPv4, a size of 1200 bytes is RECOMMENDED.
	5.1.3. Variables		5.1.3. Variables
	This method utilizes a set of variables:		This method utilizes a set of variables:
	PROBED_SIZE: The PROBED_SIZE is the size of the current probe		PROBED_SIZE: The PROBED_SIZE is the size of the current probe
	packet. This is a tentative value for the PLPMTU,		packet. This is a tentative value for the PLPMTU,
	which is awaiting confirmation by an acknowledgment.		which is awaiting confirmation by an acknowledgment.
	skipping to change at page 21, line 33 ¶		skipping to change at page 21, line 33 ¶
	Section 5.2.		Section 5.2.
	+------+		+------+
	+------->| Base |----------------+ Connectivity		+------->| Base |----------------+ Connectivity
	| +------+ | or BASE_PMTU		| +------+ | or BASE_PMTU
	| | | confirmation failed		| | | confirmation failed
	| | v		| | v
	| | Connectivity +-------+		| | Connectivity +-------+
	| | and BASE_PMTU | Error |		| | and BASE_PMTU | Error |
	| | confirmed +-------+		| | confirmed +-------+
	| | |		| | | Consistent
	| v | Consistent connectivity		| v | connectivity
	PLPMTU | +--------+ | and BASE_PMTU		PLPMTU | +--------+ | and BASE_PMTU
	confirmation | | Search |<--------------+ confirmed		confirmation | | Search |<--------------+ confirmed
	failed | +--------+		failed | +--------+
	| ^ |		| ^ |
	| | |		| | |
	| Raise | | Search		| Raise | | Search
	| timer | | algorithm		| timer | | algorithm
	| expired | | completed		| expired | | completed
	| | |		| | |
	| | v		| | v
	skipping to change at page 28, line 49 ¶		skipping to change at page 28, line 49 ¶
	The current specifications of UDP [RFC0768] and UDP-Lite [RFC3828] do		The current specifications of UDP [RFC0768] and UDP-Lite [RFC3828] do
	not define a method in the RFC-series that supports PLPMTUD. In		not define a method in the RFC-series that supports PLPMTUD. In
	particular, the UDP transport does not provide the transport layer		particular, the UDP transport does not provide the transport layer
	features needed to implement datagram PLPMTUD.		features needed to implement datagram PLPMTUD.
	The DPLPMTUD method can be implemented as a part of an application		The DPLPMTUD method can be implemented as a part of an application
	built directly or indirectly on UDP or UDP-Lite, but relies on		built directly or indirectly on UDP or UDP-Lite, but relies on
	higher-layer protocol features to implement the method [RFC8085].		higher-layer protocol features to implement the method [RFC8085].
	Some primitives used by DPLPMTUD might not be available via the		Some primitives used by DPLPMTUD might not be available via the
	Datagram API (e.g., the ability to access the PLPMTU cache, or		Datagram API (e.g., the ability to access the PLPMTU from the IP
	interpret received PTB messages).		layer cache, or interpret received PTB messages).
	In addition, it is desirable that PMTU discovery is not performed by		In addition, it is desirable that PMTU discovery is not performed by
	multiple protocol layers. An application SHOULD avoid using DPLPMTUD		multiple protocol layers. An application SHOULD avoid using DPLPMTUD
	when the underlying transport system provides this capability. To		when the underlying transport system provides this capability. To
	use common method for managing the PLPMTU has benefits, both in the		use common method for managing the PLPMTU has benefits, both in the
	ability to share state between different processes and opportunities		ability to share state between different processes and opportunities
	to coordinate probing.		to coordinate probing.
	6.1.1. Application Request		6.1.1. Application Request
	skipping to change at page 34, line 11 ¶		skipping to change at page 34, line 11 ¶
	validation as specified in Section 5.2 of [RFC8085] therefore apply.		validation as specified in Section 5.2 of [RFC8085] therefore apply.
	In addition to UDP Port validation QUIC can validate an ICMP message		In addition to UDP Port validation QUIC can validate an ICMP message
	by looking for valid Connection IDs in the quoted packet.		by looking for valid Connection IDs in the quoted packet.
	7. Acknowledgements		7. Acknowledgements
	This work was partially funded by the European Union's Horizon 2020		This work was partially funded by the European Union's Horizon 2020
	research and innovation programme under grant agreement No. 644334		research and innovation programme under grant agreement No. 644334
	(NEAT). The views expressed are solely those of the author(s).		(NEAT). The views expressed are solely those of the author(s).
			Thanks to all that have commented or contributed, the TSVWG and QUIC
			working groups, and Mathew Calder and Julius Flohr for providing
			implementations.
	8. IANA Considerations		8. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	If there are no requirements for IANA, the section will be removed		If there are no requirements for IANA, the section will be removed
	during conversion into an RFC by the RFC Editor.		during conversion into an RFC by the RFC Editor.
	9. Security Considerations		9. Security Considerations
	The security considerations for the use of UDP and SCTP are provided		The security considerations for the use of UDP and SCTP are provided
	skipping to change at page 35, line 33 ¶		skipping to change at page 35, line 36 ¶
	Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed		Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
	and Secure Transport", draft-ietf-quic-transport-20 (work		and Secure Transport", draft-ietf-quic-transport-20 (work
	in progress), 23 April 2019,		in progress), 23 April 2019,
	<http://www.ietf.org/internet-drafts/draft-ietf-quic-		<http://www.ietf.org/internet-drafts/draft-ietf-quic-
	transport-20.txt>.		transport-20.txt>.
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	DOI 10.17487/RFC0768, August 1980,		DOI 10.17487/RFC0768, August 1980,
	<https://www.rfc-editor.org/info/rfc768>.		<https://www.rfc-editor.org/info/rfc768>.
			[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
			DOI 10.17487/RFC0791, September 1981,
			<https://www.rfc-editor.org/info/rfc791>.
	[RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery",		[RFC1191] Mogul, J.C. and S.E. Deering, "Path MTU discovery",
	RFC 1191, DOI 10.17487/RFC1191, November 1990,		RFC 1191, DOI 10.17487/RFC1191, November 1990,
	<https://www.rfc-editor.org/info/rfc1191>.		<https://www.rfc-editor.org/info/rfc1191>.
	[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>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <https://www.rfc-editor.org/info/rfc2460>.
	[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,		[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
	and G. Fairhurst, Ed., "The Lightweight User Datagram		and G. Fairhurst, Ed., "The Lightweight User Datagram
	Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July		Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
	2004, <https://www.rfc-editor.org/info/rfc3828>.		2004, <https://www.rfc-editor.org/info/rfc3828>.
	[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and		[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
	Parameter for the Stream Control Transmission Protocol		Parameter for the Stream Control Transmission Protocol
	(SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,		(SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
	<https://www.rfc-editor.org/info/rfc4820>.		<https://www.rfc-editor.org/info/rfc4820>.
	skipping to change at page 36, line 28 ¶		skipping to change at page 36, line 30 ¶
	<https://www.rfc-editor.org/info/rfc6951>.		<https://www.rfc-editor.org/info/rfc6951>.
	[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage		[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
	Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,		Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
	March 2017, <https://www.rfc-editor.org/info/rfc8085>.		March 2017, <https://www.rfc-editor.org/info/rfc8085>.
	[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>.
			[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", STD 86, RFC 8200,
			DOI 10.17487/RFC8200, July 2017,
			<https://www.rfc-editor.org/info/rfc8200>.
	[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,		[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
	"Path MTU Discovery for IP version 6", STD 87, RFC 8201,		"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
	DOI 10.17487/RFC8201, July 2017,		DOI 10.17487/RFC8201, July 2017,
	<https://www.rfc-editor.org/info/rfc8201>.		<https://www.rfc-editor.org/info/rfc8201>.
	[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,		[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
	"Datagram Transport Layer Security (DTLS) Encapsulation of		"Datagram Transport Layer Security (DTLS) Encapsulation of
	SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November		SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
	2017, <https://www.rfc-editor.org/info/rfc8261>.		2017, <https://www.rfc-editor.org/info/rfc8261>.
	skipping to change at page 41, line 9 ¶		skipping to change at page 41, line 17 ¶
	* Address comments from Lars Eggert		* Address comments from Lars Eggert
	* Reinforce that PROBE_COUNT is successive attempts to probe for any		* Reinforce that PROBE_COUNT is successive attempts to probe for any
	size		size
	* Redefine MAx_PROBES to 3		* Redefine MAx_PROBES to 3
	* Address PTB_SIZE of 0 or less that MIN_PMTU		* Address PTB_SIZE of 0 or less that MIN_PMTU
			Working group draft -11:
			* Restore a sentence removed in previous rev
			* De-acronymise QUIC
			* Address some nits
			Working group draft -12:
			* Add TSVWG, QUIC and implementers to acknowledgements
			* Shorten a diagram line
			* Address nits from Julius and Wes
			* Be clearer when talking about IP layer caches
	Authors' Addresses		Authors' Addresses
	Godred Fairhurst		Godred Fairhurst
	University of Aberdeen		University of Aberdeen
	School of Engineering, Fraser Noble Building		School of Engineering, Fraser Noble Building
	Aberdeen		Aberdeen
	AB24 3UE		AB24 3UE
	United Kingdom		United Kingdom
	Email: gorry@erg.abdn.ac.uk		Email: gorry@erg.abdn.ac.uk
End of changes. 17 change blocks.
	28 lines changed or deleted		56 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/