draft-ietf-tsvwg-datagram-plpmtud-18.txt   draft-ietf-tsvwg-datagram-plpmtud-19.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: 4 October 2020 T. Voelker Expires: 5 October 2020 T. Voelker
Muenster University of Applied Sciences Muenster University of Applied Sciences
2 April 2020 3 April 2020
Packetization Layer Path MTU Discovery for Datagram Transports Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-18 draft-ietf-tsvwg-datagram-plpmtud-19
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
black hole (where packets are discarded). The method can probe a black hole (where packets are discarded). The method can probe a
network path with progressively larger packets to discover whether network path with progressively larger packets to discover whether
the maximum packet size can be increased. This allows a sender to the maximum packet size can be increased. This allows a sender to
determine an appropriate packet size, providing functionality for determine an appropriate packet size, providing functionality for
datagram transports that is equivalent to the Packetization Layer datagram transports that is equivalent to the Packetization Layer
PMTUD specification for TCP, specified in RFC 4821. PMTUD specification for TCP, specified in RFC 4821.
The document updates RFC 4821 to specify the method for datagram PLs, This document updates RFC 4821 to specify the method for datagram
and updates RFC 8085 as the method to use in place of RFC 4821 with PLs, and updates RFC 8085 as the method to use in place of RFC 4821
UDP datagrams. Section 7.3 of RFC4960 recommends an endpoint apply with UDP datagrams. Section 7.3 of RFC4960 recommends an endpoint
the techniques in RFC 4821 on a per-destination-address basis. RFC apply the techniques in RFC 4821 on a per-destination-address basis.
4960, RFC 6951 and RFC 8261 are updated to recommend that SCTP, SCTP RFC 4960, RFC 6951 and RFC 8261 are updated to recommend that SCTP,
encapsulated in UDP and SCTP encapsulated in DTLS use the method SCTP encapsulated in UDP and SCTP encapsulated in DTLS use the method
specified in this document instead of the method in RFC 4821. specified in this document instead of the method in RFC 4821.
The document also provides implementation notes for incorporating The document also provides implementation notes for incorporating
Datagram PMTUD into IETF datagram transports or applications that use Datagram PMTUD into IETF datagram transports or applications that use
datagram transports. datagram transports.
When published, this specification updates RFC 4960, RFC 4821, RFC When published, this specification updates RFC 4960, RFC 4821, RFC
8085 and RFC 8261. 8085 and RFC 8261.
Status of This Memo Status of This Memo
skipping to change at page 2, line 15 skipping to change at page 2, line 15
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 4 October 2020. This Internet-Draft will expire on 5 October 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 38 skipping to change at page 2, line 38
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . 10 3. Features Required to Provide Datagram PLPMTUD . . . . . . . . 11
4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 13 4. DPLPMTUD Mechanisms . . . . . . . . . . . . . . . . . . . . . 14
4.1. PLPMTU Probe Packets . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . 15 4.3. Black Hole Detection and Reducing the PLPMTU . . . . . . 15
4.4. The Maximum Packet Size (MPS) . . . . . . . . . . . . . . 16 4.4. The Maximum Packet Size (MPS) . . . . . . . . . . . . . . 16
4.5. Disabling the Effect of PMTUD . . . . . . . . . . . . . . 17 4.5. Disabling the Effect of PMTUD . . . . . . . . . . . . . . 17
4.6. Response to PTB Messages . . . . . . . . . . . . . . . . 17 4.6. Response to PTB Messages . . . . . . . . . . . . . . . . 18
4.6.1. Validation of PTB Messages . . . . . . . . . . . . . 17 4.6.1. Validation of PTB Messages . . . . . . . . . . . . . 18
4.6.2. Use of PTB Messages . . . . . . . . . . . . . . . . . 18 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
5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 22 5.1.3. Variables . . . . . . . . . . . . . . . . . . . . . . 23
5.1.4. Overview of DPLPMTUD Phases . . . . . . . . . . . . . 23 5.1.4. Overview of DPLPMTUD Phases . . . . . . . . . . . . . 24
5.2. State Machine . . . . . . . . . . . . . . . . . . . . . . 25 5.2. State Machine . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Search to Increase the PLPMTU . . . . . . . . . . . . . . 28 5.3. Search to Increase the PLPMTU . . . . . . . . . . . . . . 29
5.3.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 28 5.3.1. Probing for a larger PLPMTU . . . . . . . . . . . . . 29
5.3.2. Selection of Probe Sizes . . . . . . . . . . . . . . 29 5.3.2. Selection of Probe Sizes . . . . . . . . . . . . . . 30
5.3.3. Resilience to Inconsistent Path Information . . . . . 29 5.3.3. Resilience to Inconsistent Path Information . . . . . 30
5.4. Robustness to Inconsistent Paths . . . . . . . . . . . . 30 5.4. Robustness to Inconsistent Paths . . . . . . . . . . . . 31
6. Specification of Protocol-Specific Methods . . . . . . . . . 30 6. Specification of Protocol-Specific Methods . . . . . . . . . 31
6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 30 6.1. Application support for DPLPMTUD with UDP or UDP-Lite . . 31
6.1.1. Application Request . . . . . . . . . . . . . . . . . 31 6.1.1. Application Request . . . . . . . . . . . . . . . . . 32
6.1.2. Application Response . . . . . . . . . . . . . . . . 31 6.1.2. Application Response . . . . . . . . . . . . . . . . 32
6.1.3. Sending Application Probe Packets . . . . . . . . . . 31 6.1.3. Sending Application Probe Packets . . . . . . . . . . 32
6.1.4. Initial Connectivity . . . . . . . . . . . . . . . . 31 6.1.4. Initial Connectivity . . . . . . . . . . . . . . . . 32
6.1.5. Validating the Path . . . . . . . . . . . . . . . . . 31 6.1.5. Validating the Path . . . . . . . . . . . . . . . . . 32
6.1.6. Handling of PTB Messages . . . . . . . . . . . . . . 31 6.1.6. Handling of PTB Messages . . . . . . . . . . . . . . 33
6.2. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 32 6.2. DPLPMTUD for SCTP . . . . . . . . . . . . . . . . . . . . 33
6.2.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 32 6.2.1. SCTP/IPv4 and SCTP/IPv6 . . . . . . . . . . . . . . . 33
6.2.1.1. Initial Connectivity . . . . . . . . . . . . . . 32 6.2.1.1. Initial Connectivity . . . . . . . . . . . . . . 33
6.2.1.2. Sending SCTP Probe Packets . . . . . . . . . . . 32 6.2.1.2. Sending SCTP Probe Packets . . . . . . . . . . . 33
6.2.1.3. Validating the Path with SCTP . . . . . . . . . . 33 6.2.1.3. Validating the Path with SCTP . . . . . . . . . . 34
6.2.1.4. PTB Message Handling by SCTP . . . . . . . . . . 33 6.2.1.4. PTB Message Handling by SCTP . . . . . . . . . . 34
6.2.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 33 6.2.2. DPLPMTUD for SCTP/UDP . . . . . . . . . . . . . . . . 34
6.2.2.1. Initial Connectivity . . . . . . . . . . . . . . 33 6.2.2.1. Initial Connectivity . . . . . . . . . . . . . . 35
6.2.2.2. Sending SCTP/UDP Probe Packets . . . . . . . . . 34 6.2.2.2. Sending SCTP/UDP Probe Packets . . . . . . . . . 35
6.2.2.3. Validating the Path with SCTP/UDP . . . . . . . . 34 6.2.2.3. Validating the Path with SCTP/UDP . . . . . . . . 35
6.2.2.4. Handling of PTB Messages by SCTP/UDP . . . . . . 34 6.2.2.4. Handling of PTB Messages by SCTP/UDP . . . . . . 35
6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 34 6.2.3. DPLPMTUD for SCTP/DTLS . . . . . . . . . . . . . . . 35
6.2.3.1. Initial Connectivity . . . . . . . . . . . . . . 34 6.2.3.1. Initial Connectivity . . . . . . . . . . . . . . 35
6.2.3.2. Sending SCTP/DTLS Probe Packets . . . . . . . . . 34 6.2.3.2. Sending SCTP/DTLS Probe Packets . . . . . . . . . 35
6.2.3.3. Validating the Path with SCTP/DTLS . . . . . . . 34 6.2.3.3. Validating the Path with SCTP/DTLS . . . . . . . 36
6.2.3.4. Handling of PTB Messages by SCTP/DTLS . . . . . . 35 6.2.3.4. Handling of PTB Messages by SCTP/DTLS . . . . . . 36
6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 35 6.3. DPLPMTUD for QUIC . . . . . . . . . . . . . . . . . . . . 36
6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 35 6.3.1. Initial Connectivity . . . . . . . . . . . . . . . . 36
6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 35 6.3.2. Sending QUIC Probe Packets . . . . . . . . . . . . . 36
6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 36 6.3.3. Validating the Path with QUIC . . . . . . . . . . . . 37
6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 36 6.3.4. Handling of PTB Messages by QUIC . . . . . . . . . . 37
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 41 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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 7, line 10 skipping to change at page 7, line 10
(PLPMTUD) [RFC4821] introduced a method that does not rely upon (PLPMTUD) [RFC4821] introduced a method that does not rely upon
reception and validation of PTB messages. It is therefore more reception and validation of PTB messages. It is therefore more
robust than Classical PMTUD. This has become the recommended robust than Classical PMTUD. This has become the recommended
approach for implementing discovery of the PMTU [RFC8085]. approach for implementing discovery of the PMTU [RFC8085].
It uses a general strategy where the PL sends probe packets to search It uses a general strategy where the PL sends probe packets to search
for the largest size of unfragmented datagram that can be sent over a for the largest size of unfragmented datagram that can be sent over a
network path. Probe packets are sent to explore using a larger network path. Probe packets are sent to explore using a larger
packet size. If a probe packet is successfully delivered (as packet size. If a probe packet is successfully delivered (as
determined by the PL), then the PLPMTU is raised to the size of the determined by the PL), then the PLPMTU is raised to the size of the
successful probe. If no response is received to a probe packet, the successful probe. If a black hole is detected (e.g., where packets
method then reduces the PLPMTU. of size PLPMTU are consistently not received), the method reduces the
PLPMTU.
Datagram PLPMTUD introduces flexibility in implementation. At one Datagram PLPMTUD introduces flexibility in implementation. At one
extreme, it can be configured to only perform Black Hole Detection extreme, it can be configured to only perform Black Hole Detection
and recovery with increased robustness compared to Classical PMTUD. and recovery with increased robustness compared to Classical PMTUD.
At the other extreme, all PTB processing can be disabled, and PLPMTUD At the other extreme, all PTB processing can be disabled, and PLPMTUD
replaces Classical PMTUD. replaces Classical PMTUD.
PLPMTUD can also include additional consistency checks without PLPMTUD can also include additional consistency checks without
increasing the risk that data is lost when probing to discover the increasing the risk that data is lost when probing to discover the
Path MTU. For example, information available at the PL, or higher Path MTU. For example, information available at the PL, or higher
skipping to change at page 8, line 11 skipping to change at page 8, line 14
The Datagram Congestion Control Protocol (DCCP) [RFC4340] requires The Datagram Congestion Control Protocol (DCCP) [RFC4340] requires
implementations to support Classical PMTUD and states that a DCCP implementations to support Classical PMTUD and states that a DCCP
sender "MUST maintain the MPS allowed for each active DCCP session". sender "MUST maintain the MPS allowed for each active DCCP session".
It also defines the current congestion control MPS (CCMPS) supported It also defines the current congestion control MPS (CCMPS) supported
by a network path. This recommends use of PMTUD, and suggests use of by a network path. This recommends use of PMTUD, and suggests use of
control packets (DCCP-Sync) as path probe packets, because they do control packets (DCCP-Sync) as path probe packets, because they do
not risk application data loss. The method defined in this not risk application data loss. The method defined in this
specification can be used with DCCP. specification can be used with DCCP.
Section 4 and Section 5 define the protocol mechanisms and
specification for Datagram Packetization Layer Path MTU Discovery
(DPLPMTUD).
Section 6 specifies the method for datagram transports and provides Section 6 specifies the method for datagram transports and provides
information to enable the implementation of PLPMTUD with other information to enable the implementation of PLPMTUD with other
datagram transports and applications that use datagram transports. datagram transports and applications that use datagram transports.
Section 6 also provides updated recommendations for [RFC6951] and Section 6 also provides updated recommendations for [RFC6951] and
[RFC8261]. [RFC8261].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 9, line 28 skipping to change at page 9, line 34
EMTU_S: The Effective MTU for sending (EMTU_S) is defined in EMTU_S: The Effective MTU for sending (EMTU_S) is defined in
[RFC1122] as "the maximum IP datagram size that may be sent, for a [RFC1122] as "the maximum IP datagram size that may be sent, for a
particular combination of IP source and destination addresses...". particular combination of IP source and destination addresses...".
EMTU_R: The Effective MTU for receiving (EMTU_R) is designated in EMTU_R: The Effective MTU for receiving (EMTU_R) is designated in
[RFC1122] as "the largest datagram size that can be reassembled". [RFC1122] as "the largest datagram size that can be reassembled".
Link: A Link is a communication facility or medium over which nodes Link: A Link is a communication facility or medium over which nodes
can communicate at the link layer, i.e., a layer below the IP can communicate at the link layer, i.e., a layer below the IP
layer. Examples are Ethernet LANs and Internet (or higher) layer layer. Examples are Ethernet LANs and Internet (or higher) layer
and tunnels. tunnels.
Link MTU: The Link Maximum Transmission Unit (MTU) is the size in Link MTU: The Link Maximum Transmission Unit (MTU) is the size in
bytes of the largest IP packet, including the IP header and bytes of the largest IP packet, including the IP header and
payload, that can be transmitted over a link. Note that this payload, that can be transmitted over a link. Note that this
could more properly be called the IP MTU, to be consistent with could more properly be called the IP MTU, to be consistent with
how other standards organizations use the acronym. This includes how other standards organizations use the acronym. This includes
the IP header, but excludes link layer headers and other framing the IP header, but excludes link layer headers and other framing
that is not part of IP or the IP payload. Other standards that is not part of IP or the IP payload. Other standards
organizations generally define the link MTU to include the link organizations generally define the link MTU to include the link
layer headers. This specification continues the requirement in layer headers. This specification continues the requirement in
skipping to change at page 10, line 5 skipping to change at page 10, line 12
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. DPLPMTUD will attempt to use.
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. DPLPMTUD will attempt to use.
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.
MSL: Maximum Segment Lifetime (MSL) The maximum delay a packet is
expected to experience across a path, taken as 2 minutes
[RFC8085].
Packet: A Packet is the IP header plus the IP payload. Packet: A Packet is the IP header 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 DTLS or functions. Examples of a PL include: TCP, SCTP, SCTP over DTLS or
QUIC. QUIC.
Path: The Path is the set of links and routers traversed by a packet Path: The Path is the set of links and routers traversed by a packet
between a source node and a destination node by a particular flow. between a source node and a destination node by a particular flow.
skipping to change at page 11, line 7 skipping to change at page 11, line 18
The principles expressed in [RFC4821] apply to the use of the The principles expressed in [RFC4821] apply to the use of the
technique with any PL. TCP PLPMTUD has been defined using standard technique with any PL. TCP PLPMTUD has been defined using standard
TCP protocol mechanisms. Unlike TCP, a datagram PL requires TCP protocol mechanisms. Unlike TCP, a datagram PL requires
additional mechanisms and considerations to implement PLPMTUD. additional mechanisms and considerations to implement PLPMTUD.
The requirements for datagram PLPMTUD are: The requirements for datagram PLPMTUD are:
1. Managing the PLPMTU: For datagram PLs, the PLPMTU is managed by 1. Managing the PLPMTU: For datagram PLs, the PLPMTU is managed by
DPLPMTUD. A PL MUST NOT send a datagram (other than a probe DPLPMTUD. A PL MUST NOT send a datagram (other than a probe
packet) with a size at the PL layer that is larger than the packet) with a size at the PL that is larger than the current
current PLPMTU. PLPMTU.
2. Probe packets: On request, a DPLPMTUD sender is REQUIRED to be 2. Probe packets: The network interface below PL is REQUIRED to
able to transmit a packet larger than the PLMPMTU. This is used provide a way to transmit a probe packet that is larger than the
to send a probe packet. In IPv4, a probe packet MUST be sent PLMPMTU. In IPv4, a probe packet MUST be sent with the Don't
with the Don't Fragment (DF) bit set in the IP header, and Fragment (DF) bit set in the IP header, and without network
without network layer endpoint fragmentation. In IPv6, a probe layer endpoint fragmentation. In IPv6, a probe packet is always
packet is always sent without source fragmentation (as specified sent without source fragmentation (as specified in section 5.4
in section 5.4 of [RFC8201]). of [RFC8201]).
3. Reception feedback: The destination PL endpoint is REQUIRED to 3. Reception feedback: The destination PL endpoint is REQUIRED to
provide a feedback method that indicates to the DPLPMTUD sender provide a feedback method that indicates to the DPLPMTUD sender
when a probe packet has been received by the destination PL when a probe packet has been received by the destination PL
endpoint. Section 6 provides examples of how a PL can provide endpoint. Section 6 provides examples of how a PL can provide
this acknowledgment of received probe packets. this acknowledgment of received probe packets.
4. Probe loss recovery: It is RECOMMENDED to use probe packets that 4. Probe loss recovery: It is RECOMMENDED to use probe packets that
do not carry any user data that would require retransmission if do not carry any user data that would require retransmission if
lost. Most datagram transports permit this. If a probe packet lost. Most datagram transports permit this. If a probe packet
skipping to change at page 14, line 10 skipping to change at page 14, line 24
probe packets by choosing to appropriately segment data being sent probe packets by choosing to appropriately segment data being sent
[RFC4821]. In contrast, a datagram PL that constructs a probe packet [RFC4821]. In contrast, a datagram PL that constructs a probe packet
has to either request an application to send a data block that is has to either request an application to send a data block that is
larger than that generated by an application, or to utilize padding larger than that generated by an application, or to utilize padding
functions to extend a datagram beyond the size of the application functions to extend a datagram beyond the size of the application
data block. Protocols that permit exchange of control messages data block. Protocols that permit exchange of control messages
(without an application data block) can generate a probe packet by (without an application data block) can generate a probe packet by
extending a control message with padding data. The total size of a extending a control message with padding data. The total size of a
probe packet includes all headers and padding added to the payload probe packet includes all headers and padding added to the payload
data being sent (e.g., including protocol option fields, security- data being sent (e.g., including protocol option fields, security-
related fields such as an AEAD tag and TLS record layer padding). related fields such as an Authenticated Encryption with Associated
Data (AEAD) tag and TLS record layer padding).
A receiver is REQUIRED to be able to distinguish an in-band data A receiver is REQUIRED to be able to distinguish an in-band data
block from any added padding. This is needed to ensure that any block from any added padding. This is needed to ensure that any
added padding is not passed on to an application at the receiver. added padding is not passed on to an application at the receiver.
This results in three possible ways that a sender can create a probe This results in three possible ways that a sender can create a probe
packet: packet:
Probing using padding data: A probe packet that contains only Probing using padding data: A probe packet that contains only
control information together with any padding, which is needed to control information together with any padding, which is needed to
skipping to change at page 15, line 26 skipping to change at page 15, line 40
probe packet. probe packet.
A PL that does not acknowledge data reception (e.g., UDP and UDP- A PL that does not acknowledge data reception (e.g., UDP and UDP-
Lite) is unable itself to detect when the packets that it sends are Lite) is unable itself to detect when the packets that it sends are
discarded because their size is greater than the actual PMTU. These discarded because their size is greater than the actual PMTU. These
PLs need to rely on an application protocol to detect this loss. PLs need to rely on an application protocol to detect this loss.
Section 6 specifies this function for a set of IETF-specified Section 6 specifies this function for a set of IETF-specified
protocols. protocols.
4.3. Black Hole Detection 4.3. Black Hole Detection and Reducing the PLPMTU
The description that follows uses the set of constants defined in The description that follows uses the set of constants defined in
Section 5.1.2 and variables defined in Section 5.1.3. Section 5.1.2 and variables defined in Section 5.1.3.
Black Hole Detection is triggered by an indication that the network Black Hole Detection is triggered by an indication that the network
path could be unable to support the current PLPMTU size. path could be unable to support the current PLPMTU size.
There are three ways to detect black holes: There are three indicators that can detect black holes:
* A validated PTB message can be received that indicates a * A validated PTB message can be received that indicates a
PL_PTB_SIZE less than the current PLPMTU. A DPLPMTUD method MUST PL_PTB_SIZE less than the current PLPMTU. A DPLPMTUD method MUST
NOT rely solely on this method. NOT rely solely on this method.
* A PL can use the DPLPMTUD probing mechanism to periodically * A PL can use the DPLPMTUD probing mechanism to periodically
generate probe packets of the size of the current PLPMTU (e.g., generate probe packets of the size of the current PLPMTU (e.g.,
using the confirmation timer Section 5.1.1). A timer tracks using the confirmation timer Section 5.1.1). A timer tracks
whether acknowledgments are received. Successive loss of probes whether acknowledgments are received. Successive loss of probes
is an indication that the current path no longer supports the is an indication that the current path no longer supports the
skipping to change at page 16, line 8 skipping to change at page 16, line 23
receiving an acknowledgment, PROBE_COUNT, becomes greater than receiving an acknowledgment, PROBE_COUNT, becomes greater than
MAX_PROBES). MAX_PROBES).
* A PL can utilize an event that indicates the network path no * A PL can utilize an event that indicates the network path no
longer sustains the sender's PLPMTU size. This could use a longer sustains the sender's PLPMTU size. This could use a
mechanism implemented within the PL to detect excessive loss of mechanism implemented within the PL to detect excessive loss of
data sent with a specific packet size and then conclude that this data sent with a specific packet size and then conclude that this
excessive loss could be a result of an invalid PLPMTU (as in excessive loss could be a result of an invalid PLPMTU (as in
PLPMTUD for TCP [RFC4821]). PLPMTUD for TCP [RFC4821]).
The three methods can result in different transmission patterns for
packet probes and are expected to result in different responsiveness
following a change in the actual PMTU.
A PL MAY inhibit sending probe packets when no application data has A PL MAY inhibit sending probe packets when no application data has
been sent since the previous probe packet. A PL preferring to use an been sent since the previous probe packet. A PL that resumes sending
up-to-data PLPMTU once user data is sent again MAY choose to continue user data MAY continue PLPMTU discovery for each path. This allows
PLPMTU discovery for each path. However, this could result in it to use an up-to-date PLPMTU. However, this could result in
additional packets being sent. additional packets being sent.
When the method detects the current PLPMTU is not supported, DPLPMTUD When the method detects the current PLPMTU is not supported, DPLPMTUD
sets a lower PLPMTU, and sets a lower MPS. The PL then confirms that sets a lower PLPMTU, and sets a lower MPS. The PL then confirms that
the new PLPMTU can be successfully used across the path. A probe the new PLPMTU can be successfully used across the path. A probe
packet could need to have a size less than the size of the data block packet could need to have a size less than the size of the data block
generated by the application. generated by the application.
4.4. The Maximum Packet Size (MPS) 4.4. The Maximum Packet Size (MPS)
skipping to change at page 17, line 42 skipping to change at page 18, line 19
message depends on the PL_PTB_SIZE calculated from the PTB_SIZE in message depends on the PL_PTB_SIZE calculated from the PTB_SIZE in
the PTB message, the state of the PLPMTUD state machine, and the IP the PTB message, the state of the PLPMTUD state machine, and the IP
protocol being used. protocol being used.
Section 4.6.1 first describes validation for both IPv4 ICMP Section 4.6.1 first describes validation for both IPv4 ICMP
Unreachable messages (type 3) and ICMPv6 Packet Too Big messages, Unreachable messages (type 3) and ICMPv6 Packet Too Big messages,
both of which are referred to as PTB messages in this document. both of which are referred to as PTB messages in this document.
4.6.1. Validation of PTB Messages 4.6.1. Validation of PTB Messages
This section specifies utilization of PTB messages. This section specifies utilization and validation of PTB messages.
* A simple implementation MAY ignore received PTB messages and in * A simple implementation MAY ignore received PTB messages and in
this case the PLPMTU is not updated when a PTB message is this case the PLPMTU is not updated when a PTB message is
received. received.
* A PL that supports PTB messages MUST validate these messages * A PL that supports PTB messages MUST validate these messages
before they are further processed. before they are further processed.
A PL that receives a PTB message from a router or middlebox performs A PL that receives a PTB message from a router or middlebox performs
ICMP validation as specified in Section 5.2 of [RFC8085][RFC8201]. ICMP validation as specified in Section 5.2 of [RFC8085][RFC8201].
skipping to change at page 18, line 27 skipping to change at page 19, line 4
The validation SHOULD utilize information that it is not simple for The validation SHOULD utilize information that it is not simple for
an off-path attacker to determine [RFC8085]. For example, it could an off-path attacker to determine [RFC8085]. For example, it could
check the value of a protocol header field known only to the two PL check the value of a protocol header field known only to the two PL
endpoints. A datagram application that uses well-known source and endpoints. A datagram application that uses well-known source and
destination ports ought to also rely on other information to complete destination ports ought to also rely on other information to complete
this validation. this validation.
These checks are intended to provide protection from packets that These checks are intended to provide protection from packets that
originate from a node that is not on the network path. A PTB message originate from a node that is not on the network path. A PTB message
that does not complete the validation MUST NOT be further utilized by that does not complete the validation MUST NOT be further utilized by
the DPLPMTUD method. the DPLPMTUD method, as discussed in the Security Considerations
section.
PTB messages that have been validated MAY be utilized by the DPLPMTUD PTB messages that have been validated MAY be utilized by the DPLPMTUD
algorithm, but MUST NOT be used directly to set the PLPMTU. The algorithm, but MUST NOT be used directly to set the PLPMTU. The
PL_PTB_SIZE is smaller than the PTB_SIZE because it is reduced by PL_PTB_SIZE is smaller than the PTB_SIZE because it is reduced by
headers below the PL including any IP options or extensions added to headers below the PL including any IP options or extensions added to
the PL packet. A method that utilizes these PTB messages can improve the PL packet. A method that utilizes these PTB messages can improve
the speed at which the algorithm detects an appropriate PLPMTU by the speed at which the algorithm detects an appropriate PLPMTU by
triggering an immediate probe for the PL_PTB_SIZE (resulting in a triggering an immediate probe for the PL_PTB_SIZE (resulting in a
network-layer packet of size PTB_SIZE), compared to one that relies network-layer packet of size PTB_SIZE), compared to one that relies
solely on probing using a timer-based search algorithm. solely on probing using a timer-based search algorithm.
skipping to change at page 18, line 49 skipping to change at page 19, line 27
4.6.2. Use of PTB Messages 4.6.2. Use of PTB Messages
Before using the size reported in the PTB message it must first be Before using the size reported in the PTB message it must first be
converted to a PL_PTB_SIZE. A set of checks are intended to provide converted to a PL_PTB_SIZE. A set of checks are intended to provide
protection from a router that reports an unexpected PTB_SIZE. The PL protection from a router that reports an unexpected PTB_SIZE. The PL
also needs to check that the indicated PL_PTB_SIZE is less than the also needs to check that the indicated PL_PTB_SIZE is less than the
size used by probe packets and at least the minimum size accepted. size used by probe packets and at least the 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 PL_PTB_SIZE and the current value of a (This uses the set of constants defined in section 5.1.2). This
set of variables: processing depends on the PL_PTB_SIZE and the current value of a set
of variables:
PL_PTB_SIZE < MIN_PLPMTU PL_PTB_SIZE < MIN_PLPMTU
* Invalid PL_PTB_SIZE see Section 4.6.1. * Invalid PL_PTB_SIZE see Section 4.6.1.
* PTB message ought to be discarded without further processing * PTB message ought to be discarded without further processing
(i.e., PLPMTU is not modified). (i.e., PLPMTU is not modified).
* The information could be utilized as an input that triggers * The information could be utilized as an input that triggers
enabling a resilience mode (see Section 5.3.3). enabling a resilience mode (see Section 5.3.3).
skipping to change at page 21, line 44 skipping to change at page 22, line 24
to the period a PL sender waits before confirming the current to the period a PL sender waits before confirming the current
PLPMTU is still supported. This is less than the PMTU_RAISE_TIMER PLPMTU is still supported. This is less than the PMTU_RAISE_TIMER
and used to decrease the PLPMTU (e.g., when a black hole is and used to decrease the PLPMTU (e.g., when a black hole is
encountered). Confirmation needs to be frequent enough when data encountered). Confirmation needs to be frequent enough when data
is flowing that the sending PL does not black hole extensive is flowing that the sending PL does not black hole extensive
amounts of traffic. Guidance on selection of the timer value are amounts of traffic. Guidance on selection of the timer value are
provided in section 3.1.1 of the UDP Usage Guidelines [RFC8085]. provided in section 3.1.1 of the UDP Usage Guidelines [RFC8085].
DPLPMTUD MAY inhibit sending probe packets when no application DPLPMTUD MAY inhibit sending probe packets when no application
data has been sent since the previous probe packet. A PL data has been sent since the previous probe packet. A PL
preferring to use an up-to-data PMTU once user data is sent again, preferring to use an up-to-date PMTU once user data is sent again,
can choose to continue PMTU discovery for each path. However, can choose to continue PMTU discovery for each path. However,
this could result in sending additional packets. this could result in sending additional packets.
The various timers could be implemented using a single timer The various timers could be implemented using a single timer
5.1.2. Constants 5.1.2. Constants
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
skipping to change at page 22, line 40 skipping to change at page 23, line 18
interface MTU). When known, this also ought to be less than the interface MTU). When known, this also ought to be less than the
maximum size of PL packet that can be received by the remote maximum size of PL packet that can be received by the remote
endpoint (constrained by EMTU_R). It can be limited by the design endpoint (constrained by EMTU_R). It can be limited by the design
or configuration of the PL being used. An application, or PL, MAY or configuration of the PL being used. An application, or PL, MAY
choose a smaller MAX_PLPMTU when there is no need to send packets choose a smaller MAX_PLPMTU when there is no need to send packets
larger than a specific size. larger than a specific size.
BASE_PLPMTU: The BASE_PLPMTU is a configured size expected to work BASE_PLPMTU: The BASE_PLPMTU is a configured size expected to work
for most paths. The size is equal to or larger than the for most paths. The size is equal to or larger than the
MIN_PLPMTU and smaller than the MAX_PLPMTU. In the case of IPv6, MIN_PLPMTU and smaller than the MAX_PLPMTU. In the case of IPv6,
this value is 1280 bytes [RFC8200]. When using IPv4, a size of this value is derived from the IPv6 minimum link MTU of 1280 bytes
1200 bytes is RECOMMENDED. [RFC8200]. When using IPv4, there is no currently equivalent size
specified and a default BASE_PLPMTU 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, which is packet. This is a tentative value for the PLPMTU, which is
awaiting confirmation by an acknowledgment. awaiting confirmation by an acknowledgment.
PROBE_COUNT: The PROBE_COUNT is a count of the number of successive PROBE_COUNT: The PROBE_COUNT is a count of the number of successive
skipping to change at page 24, line 51 skipping to change at page 25, line 12
probe packet of size BASE_PLPMTU and confirming that this is probe packet of size BASE_PLPMTU and confirming that this is
received. received.
A probe packet of size BASE_PLPMTU can be sent immediately on the A probe packet of size BASE_PLPMTU can be sent immediately on the
initial entry to the Base Phase (following a connectivity check). initial entry to the Base Phase (following a connectivity check).
A PL that does not wish to support a path with a PLPMTU less than A PL that does not wish to support a path with a PLPMTU less than
BASE_PLPMTU can simplify the phase into a single step by BASE_PLPMTU can simplify the phase into a single step by
performing the connectivity checks with a probe of the BASE_PLPMTU performing the connectivity checks with a probe of the BASE_PLPMTU
size. size.
Once confirmed, DPLPMTUD enters the Search Phase. If this phase Once confirmed, DPLPMTUD enters the Search Phase. If the Base
fails to confirm, DPLPMTUD enters the Error Phase. Phase fails to confirm the BASE_PLPMTU, DPLPMTUD enters the Error
Phase.
Search: The Search Phase utilizes a search algorithm to send probe Search: The Search Phase utilizes a search algorithm to send probe
packets to seek to increase the PLPMTU. The algorithm concludes packets to seek to increase the PLPMTU. The algorithm concludes
when it has found a suitable PLPMTU, by entering the Search when it has found a suitable PLPMTU, by entering the Search
Complete Phase. Complete Phase.
A PL could respond to PTB messages using the PTB to advance or A PL could respond to PTB messages using the PTB to advance or
terminate the search, see Section 4.6. terminate the search, see Section 4.6.
Search Complete: The Search Complete Phase is entered when the Search Complete: The Search Complete Phase is entered when the
skipping to change at page 27, line 28 skipping to change at page 28, line 28
Each time a probe packet is sent, the PROBE_TIMER is started. The Each time a probe packet is sent, the PROBE_TIMER is started. The
state is exited when the probe packet is acknowledged, and the PL state is exited when the probe packet is acknowledged, and the PL
sender enters the SEARCHING state. sender enters the SEARCHING state.
The state is also left when the PROBE_COUNT reaches MAX_PROBES or The state is also left when the PROBE_COUNT reaches MAX_PROBES or
a received PTB message is validated. This causes the PL sender to a received PTB message is validated. This causes the PL sender to
enter the ERROR state. enter the ERROR state.
SEARCHING: The SEARCHING state is the main probing state. This SEARCHING: The SEARCHING state is the main probing state. This
state is entered when probing for the BASE_PLPMTU was successful. state is entered when probing for the BASE_PLPMTU completes.
Each time a probe packet is acknowledged, the PROBE_COUNT is set Each time a probe packet is acknowledged, the PROBE_COUNT is set
to zero, the PLPMTU is set to the PROBED_SIZE and then the to zero, the PLPMTU is set to the PROBED_SIZE and then the
PROBED_SIZE is increased using the search algorithm. PROBED_SIZE is increased using the search algorithm (as described
in Section 5.3.
When a probe packet is sent and not acknowledged within the period When a probe packet is sent and not acknowledged within the period
of the PROBE_TIMER, the PROBE_COUNT is incremented and a new probe of the PROBE_TIMER, the PROBE_COUNT is incremented and a new probe
packet is transmitted. packet is transmitted.
The state is exited to enter SEARCH_COMPLETE when the PROBE_COUNT The state is exited to enter SEARCH_COMPLETE when the PROBE_COUNT
reaches MAX_PROBES, a validated PTB is received that corresponds reaches MAX_PROBES, a validated PTB is received that corresponds
to the last successfully probed size (PL_PTB_SIZE = PLPMTU), or a to the last successfully probed size (PL_PTB_SIZE = PLPMTU), or a
probe of size MAX_PLPMTU is acknowledged (PLPMTU = MAX_PLPMTU). probe of size MAX_PLPMTU is acknowledged (PLPMTU = MAX_PLPMTU).
When a black hole is detected in the SEARCHING state, this causes When a black hole is detected in the SEARCHING state, this causes
the PL sender to enter the BASE state. the PL sender to enter the BASE state.
SEARCH_COMPLETE: The SEARCH_COMPLETE state indicates a successful SEARCH_COMPLETE: The SEARCH_COMPLETE state indicates that a search
end to the SEARCHING state. DPLPMTUD remains in this state until has completed. This is the normal maintenance state, where the PL
either the PMTU_RAISE_TIMER expires or a black hole is detected. is not probing to update the PLPMTU. DPLPMTUD remains in this
state until either the PMTU_RAISE_TIMER expires or a black hole is
detected.
When DPLPMTUD uses an unacknowledged PL and is in the When DPLPMTUD uses an unacknowledged PL and is in the
SEARCH_COMPLETE state, a CONFIRMATION_TIMER periodically resets SEARCH_COMPLETE state, a CONFIRMATION_TIMER periodically resets
the PROBE_COUNT and schedules a probe packet with the size of the the PROBE_COUNT and schedules a probe packet with the size of the
PLPMTU. If MAX_PROBES successive PLPMTUD sized probes fail to be PLPMTU. If MAX_PROBES successive PLPMTUD sized probes fail to be
acknowledged the method enters the BASE state. When used with an acknowledged the method enters the BASE state. When used with an
acknowledged PL (e.g., SCTP), DPLPMTUD SHOULD NOT continue to acknowledged PL (e.g., SCTP), DPLPMTUD SHOULD NOT continue to
generate PLPMTU probes in this state. generate PLPMTU probes in this state.
ERROR: The ERROR state represents the case where either the network ERROR: The ERROR state represents the case where either the network
skipping to change at page 30, line 46 skipping to change at page 31, line 48
needed to implement datagram PLPMTUD. 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 from the IP Datagram API (e.g., the ability to access the PLPMTU from the IP
layer cache, or 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 recommended that PMTU discovery is not performed
multiple protocol layers. An application SHOULD avoid using DPLPMTUD by multiple protocol layers. An application SHOULD avoid using
when the underlying transport system provides this capability. To DPLPMTUD when the underlying transport system provides this
use common method for managing the PLPMTU has benefits, both in the capability. To use common method for managing the PLPMTU has
ability to share state between different processes and opportunities benefits, both in the ability to share state between different
to coordinate probing. processes and opportunities to coordinate probing.
6.1.1. Application Request 6.1.1. Application Request
An application needs an application-layer protocol mechanism (such as An application needs an application-layer protocol mechanism (such as
a message acknowledgment method) that solicits a response from a a message acknowledgment method) that solicits a response from a
destination endpoint. The method SHOULD allow the sender to check destination endpoint. The method SHOULD allow the sender to check
the value returned in the response to provide additional protection the value returned in the response to provide additional protection
from off-path insertion of data [RFC8085]. Suitable methods include from off-path insertion of data [RFC8085]. Suitable methods include
a parameter known only to the two endpoints, such as a session ID or a parameter known only to the two endpoints, such as a session ID or
initialized sequence number. initialized sequence number.
skipping to change at page 45, line 29 skipping to change at page 46, line 29
consistent separation of PMTU and PLPMTU. consistent separation of PMTU and PLPMTU.
* Adopted US-style English throughout. * Adopted US-style English throughout.
Working group draft -18: Working group draft -18:
* Updated text and address nits from OPSDIR, ART and IESG reviews. * Updated text and address nits from OPSDIR, ART and IESG reviews.
* Order PTB processing based on PL_PTB_SIZE * Order PTB processing based on PL_PTB_SIZE
Working group draft -19:
* Updated text and address nits based on comments from Tim Chown and
Murray S. Kucherawy.
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. 31 change blocks. 
100 lines changed or deleted 126 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/