draft-ietf-tsvwg-datagram-plpmtud-21.txt   draft-ietf-tsvwg-datagram-plpmtud-22.txt 
Internet Engineering Task Force G. Fairhurst Internet Engineering Task Force G. Fairhurst
Internet-Draft T. Jones Internet-Draft T. Jones
Updates: 4821, 4960, 6951, 8085, 8261 (if University of Aberdeen Updates: 4821, 4960, 6951, 8085, 8261 (if University of Aberdeen
approved) M. Tuexen approved) M. Tuexen
Intended status: Standards Track I. Ruengeler Intended status: Standards Track I. Ruengeler
Expires: 13 November 2020 T. Voelker Expires: 12 December 2020 T. Voelker
Muenster University of Applied Sciences Muenster University of Applied Sciences
12 May 2020 10 June 2020
Packetization Layer Path MTU Discovery for Datagram Transports Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-21 draft-ietf-tsvwg-datagram-plpmtud-22
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 packet detect and reduce the message size when a sender encounters a packet
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 13 November 2020. This Internet-Draft will expire on 12 December 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 2, line 47 skipping to change at page 2, line 47
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4 1.1. Classical Path MTU Discovery . . . . . . . . . . . . . . 4
1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6 1.2. Packetization Layer Path MTU Discovery . . . . . . . . . 6
1.3. Path MTU Discovery for Datagram Services . . . . . . . . 7 1.3. Path MTU Discovery for Datagram Services . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 11 3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 11
4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 14 4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 14
4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 14 4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 14
4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 15 4.2. Confirmation of Probed Packet Size . . . . . . . . . . . 15
4.3. Black Hole Detection and Reducing the PLPMTU . . . . . . 16 4.3. Black Hole Detection and Reducing the PLPMTU . . . . . . 15
4.4. The Maximum Packet Size (MPS) . . . . . . . . . . . . . . 17 4.4. The Maximum Packet Size (MPS) . . . . . . . . . . . . . . 17
4.5. Disabling the Effect of PMTUD . . . . . . . . . . . . . . 18 4.5. Disabling the Effect of PMTUD . . . . . . . . . . . . . . 18
4.6. Response to PTB Messages . . . . . . . . . . . . . . . . 18 4.6. Response to PTB Messages . . . . . . . . . . . . . . . . 18
4.6.1. Validation of PTB Messages . . . . . . . . . . . . . 18 4.6.1. Validation of PTB Messages . . . . . . . . . . . . . 18
4.6.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 19 4.6.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 19
5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 20 5. Datagram Packetization Layer PMTUD . . . . . . . . . . . . . 20
5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 21 5.1. DPLPMTUD Components . . . . . . . . . . . . . . . . . . . 21
5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 21 5.1.1. Timers . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 22 5.1.2. Constants . . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 3, line 42 skipping to change at page 3, line 42
6.2.2.1. Initial Connectivity . . . . . . . . . . . . . . 35 6.2.2.1. Initial Connectivity . . . . . . . . . . . . . . 35
6.2.2.2. Sending SCTP/UDP Probe Packets . . . . . . . . . 35 6.2.2.2. Sending SCTP/UDP Probe Packets . . . . . . . . . 35
6.2.2.3. Validating the Path with SCTP/UDP . . . . . . . . 35 6.2.2.3. Validating the Path with SCTP/UDP . . . . . . . . 35
6.2.2.4. Handling of PTB Messages by SCTP/UDP . . . . . . 35 6.2.2.4. Handling of PTB Messages by SCTP/UDP . . . . . . 35
6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 35 6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 35
6.2.3.1. Initial Connectivity . . . . . . . . . . . . . . 35 6.2.3.1. Initial Connectivity . . . . . . . . . . . . . . 35
6.2.3.2. Sending SCTP/DTLS Probe Packets . . . . . . . . . 36 6.2.3.2. Sending SCTP/DTLS Probe Packets . . . . . . . . . 36
6.2.3.3. Validating the Path with SCTP/DTLS . . . . . . . 36 6.2.3.3. Validating the Path with SCTP/DTLS . . . . . . . 36
6.2.3.4. Handling of PTB Messages by SCTP/DTLS . . . . . . 36 6.2.3.4. Handling of PTB Messages by SCTP/DTLS . . . . . . 36
6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 36 6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 36
6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 36 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 37 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 37 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 41
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
The IETF has specified datagram transport using UDP, SCTP, and DCCP, The IETF has specified datagram transport using UDP, SCTP, and DCCP,
as well as protocols layered on top of these transports (e.g., SCTP/ as well as protocols layered on top of these transports (e.g., SCTP/
UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP UDP, DCCP/UDP, QUIC/UDP), and direct datagram transport over the IP
network layer. This document describes a robust method for Path MTU network layer. This document describes a robust method for Path MTU
Discovery (PMTUD) that can be used with these transport protocols (or Discovery (PMTUD) that can be used with these transport protocols (or
the applications that use their transport service) to discover an the applications that use their transport service) to discover an
appropriate size of packet to use across an Internet path. appropriate size of packet to use across an Internet path.
skipping to change at page 10, line 15 skipping to change at page 10, line 11
MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU that MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU that
DPLPMTUD will attempt to use (see the constants defined in DPLPMTUD will attempt to use (see the constants defined in
Section 5.1.2). Section 5.1.2).
MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that
DPLPMTUD will attempt to use (see the constants defined in DPLPMTUD will attempt to use (see the constants defined in
Section 5.1.2). Section 5.1.2).
MPS: The Maximum Packet Size (MPS) is the largest size of MPS: The Maximum Packet Size (MPS) is the largest size of
application data block that can be sent across a network path by a application data block that can be sent across a network path by a
PL using a single Datagram. PL using a single Datagram (see Section 4.4).
MSL: Maximum Segment Lifetime (MSL) The maximum delay a packet is MSL: Maximum Segment Lifetime (MSL) The maximum delay a packet is
expected to experience across a path, taken as 2 minutes [BCP145]. expected to experience across a path, taken as 2 minutes [BCP145].
Packet: A Packet is the IP header(s) and any extension headers/ Packet: A Packet is the IP header(s) and any extension headers/
options plus the IP payload. options plus the IP payload.
Packetization Layer (PL): The PL is a layer of the network stack Packetization Layer (PL): The PL is a layer of the network stack
that places data into packets and performs transport protocol that places data into packets and performs transport protocol
functions. Examples of a PL include: TCP, SCTP, SCTP over UDP, functions. Examples of a PL include: TCP, SCTP, SCTP over UDP,
skipping to change at page 22, line 49 skipping to change at page 22, line 49
The following constants are defined: The following constants are defined:
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 limit for counter (see Section 5.1.3). MAX_PROBES represents the limit for
the number of consecutive probe attempts of any size. Search the number of consecutive probe attempts of any size. Search
algorithms benefit from a MAX_PROBES value greater than 1 because algorithms benefit from a MAX_PROBES value greater than 1 because
this can provide robustness to isolated packet loss. The default this can provide robustness to isolated packet loss. The default
value of MAX_PROBES is 3. value of MAX_PROBES is 3.
MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that
DPLPMTUD will attempt to use. For IPv6, this size is greater than DPLPMTUD will attempt to use. An endpoint could need to be
or equal to the size at the PL that results in an 1280 byte IPv6 configure the MIN_PLPMTU to provide space for extension headers
packet, as specified in [RFC8200]. For IPv4, this size is greater and other encapsulations at layers below the PL. This value can
than or equal to the size at the PL that results in an 68 byte be interface and path dependent. For IPv6, this size is greater
IPv4 packet. Note: An IPv4 router is required to be able to than or equal to the size at the PL that results in an 1280 byte
IPv6 packet, as specified in [RFC8200]. For IPv4, this size is
greater than or equal to the size at the PL that results in an 68
byte IPv4 packet. Note: An IPv4 router is required to be able to
forward a datagram of 68 bytes without further fragmentation. forward a datagram of 68 bytes without further fragmentation.
This is the combined size of an IPv4 header and the minimum This is the combined size of an IPv4 header and the minimum
fragment size of 8 bytes. In addition, receivers are required to fragment size of 8 bytes. In addition, receivers are required to
be able to reassemble fragmented datagrams at least up to 576 be able to reassemble fragmented datagrams at least up to 576
bytes, as stated in section 3.3.3 of [RFC1122]. bytes, as stated in section 3.3.3 of [RFC1122].
MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU. This has MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU. This has
to be less than or equal to the maximum size of the PL packet that to be less than or equal to the maximum size of the PL packet that
can be sent on the outgoing interface (constrained by the local can be sent on the outgoing interface (constrained by the local
interface MTU). When known, this also ought to be less than the interface MTU). When known, this also ought to be less than the
skipping to change at page 36, line 26 skipping to change at page 36, line 26
the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
6.2.3.4. Handling of PTB Messages by SCTP/DTLS 6.2.3.4. Handling of PTB Messages by SCTP/DTLS
[RFC4960] does not specify a way to validate SCTP/DTLS ICMP message [RFC4960] does not specify a way to validate SCTP/DTLS ICMP message
payload and neither does this document. This can prevent processing payload and neither does this document. This can prevent processing
of PTB messages at the PL. of PTB messages at the PL.
6.3. DPLPMTUD for QUIC 6.3. DPLPMTUD for QUIC
QUIC [I-D.ietf-quic-transport] is a UDP-based transport that provides QUIC [I-D.ietf-quic-transport] is a UDP-based PL that provides
reception feedback. The UDP payload includes the QUIC packet header, reception feedback. The UDP payload includes a QUIC packet header, a
protected payload, and any authentication fields. QUIC depends on a protected payload, and any authentication fields. It supports
PMTU of at least 1280 bytes. padding and packet coalescence that can be used to construct probe
packets. From the perspective of DPLPMTUD, QUIC can function as an
Section 14 of [I-D.ietf-quic-transport] describes the path acknowledged PL. [I-D.ietf-quic-transport] describes the method for
considerations when sending QUIC packets. It recommends the use of using DPLPMTUD with QUIC packets.
PADDING frames to build the probe packet. Pure probe-only packets
are constructed with PADDING frames and PING frames to create a
padding only packet that will elicit an acknowledgment. Such padding
only packets enable probing without affecting the transfer of other
QUIC frames.
The recommendation for QUIC endpoints implementing DPLPMTUD is that a
MPS is maintained for each combination of local and remote IP
addresses [I-D.ietf-quic-transport]. If a QUIC endpoint determines
that the PMTU between any pair of local and remote IP addresses has
fallen below the size required for an acceptable MPS, it immediately
ceases to send QUIC packets on the affected path. This could result
in termination of the connection if an alternative path cannot be
found [I-D.ietf-quic-transport].
6.3.1. Initial Connectivity
The base protocol is specified in [I-D.ietf-quic-transport]. This
provides an acknowledged PL. A sender can therefore enter the BASE
state as soon as connectivity has been confirmed.
QUIC provides an acknowledged PL, a sender can therefore enter the
BASE state as soon as the connection handshake has been completed and
the endpoint has an 1-RTT key established.
6.3.2. Sending QUIC Probe Packets
Probe packets consist of a QUIC Header and a payload containing a
PING Frame and multiple PADDING Frames. A PADDING Frame is
represented by a single octet (0x00). Several PADDING Frames are
used together to control the length of the probe packet. The PING
Frame is used to trigger generation of an acknowledgement.
The current specification of QUIC sets the following:
* BASE_PLPMTU: A QUIC sender pads initial packets to confirm the
path can support packets of the required size, which sets the
BASE_PLPMTU and MIN_PLPMTU.
* MIN_PLPMTU: A QUIC sender that determines the MIN_PLPMTU has
fallen MUST immediately stop sending on the affected path.
6.3.3. Validating the Path with QUIC
QUIC provides an acknowledged PL, therefore a sender does not
implement the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state.
6.3.4. Handling of PTB Messages by QUIC
QUIC validates ICMP PTB messages. In addition to UDP Port
validation, QUIC can validate an ICMP message by using other PL
information (e.g., validation of connection identifiers (CIDs) in the
quoted packet of any received ICMP message).
7. Acknowledgments 7. Acknowledgments
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 Thanks to all that have commented or contributed, the TSVWG and QUIC
working groups, and Mathew Calder and Julius Flohr for providing working groups, and Mathew Calder and Julius Flohr for providing
early implementations. early implementations.
skipping to change at page 39, line 42 skipping to change at page 38, line 40
10. References 10. References
10.1. Normative References 10.1. Normative References
[BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, March 2017. Guidelines", BCP 145, RFC 8085, March 2017.
<https://www.rfc-editor.org/info/bcp145> <https://www.rfc-editor.org/info/bcp145>
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-27, 21 February 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-27.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, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <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,
skipping to change at page 41, line 26 skipping to change at page 40, line 16
fragile-17, 30 September 2019, <http://www.ietf.org/ fragile-17, 30 September 2019, <http://www.ietf.org/
internet-drafts/draft-ietf-intarea-frag-fragile-17.txt>. internet-drafts/draft-ietf-intarea-frag-fragile-17.txt>.
[I-D.ietf-intarea-tunnels] [I-D.ietf-intarea-tunnels]
Touch, J. and M. Townsley, "IP Tunnels in the Internet Touch, J. and M. Townsley, "IP Tunnels in the Internet
Architecture", Work in Progress, Internet-Draft, draft- Architecture", Work in Progress, Internet-Draft, draft-
ietf-intarea-tunnels-10, 12 September 2019, ietf-intarea-tunnels-10, 12 September 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-intarea- <http://www.ietf.org/internet-drafts/draft-ietf-intarea-
tunnels-10.txt>. tunnels-10.txt>.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-27, 21 February 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-27.txt>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981, RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>. <https://www.rfc-editor.org/info/rfc792>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
skipping to change at page 47, line 5 skipping to change at page 45, line 52
* Address nits and comments from IESG * Address nits and comments from IESG
* Refer to BCP 145 rather than RFC 8085 in most places. * Refer to BCP 145 rather than RFC 8085 in most places.
* Update probing method text for SCTP and QUIC. * Update probing method text for SCTP and QUIC.
Working group draft -21: Working group draft -21:
* Update QUIC text for skipping into BASE state. * Update QUIC text for skipping into BASE state.
Working group draft -22:
* Add a section reference to MPS
* Clarify MIN_PLPMTU text
* Remove most QUIC text
* Make QUIC reference informative.
Authors' Addresses Authors' Addresses
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen Aberdeen
AB24 3UE AB24 3UE
United Kingdom United Kingdom
 End of changes. 12 change blocks. 
90 lines changed or deleted 46 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/