Skip to main content

Packetization Layer Path MTU Discovery for Datagram Transports
draft-fairhurst-tsvwg-datagram-plpmtud-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Gorry Fairhurst , Tom Jones , Michael Tüxen , Irene Ruengeler
Last updated 2017-07-03
Replaced by draft-ietf-tsvwg-datagram-plpmtud, RFC 8899
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-fairhurst-tsvwg-datagram-plpmtud-00
Internet Engineering Task Force                             G. Fairhurst
Internet-Draft                                                  T. Jones
Intended status: Standards Track                  University of Aberdeen
Expires: January 4, 2018                                       M. Tuexen
                                                            I. Ruengeler
                                 Muenster University of Applied Sciences
                                                           July 03, 2017

     Packetization Layer Path MTU Discovery for Datagram Transports
             draft-fairhurst-tsvwg-datagram-plpmtud-00.txt

Abstract

   This document describes a robust method for Path MTU Discovery
   (PMTUD) for datagram packetization layers.  It allows these layers to
   probe an Internet path with progressively larger packets to determine
   a maximum packet size This method is described as an extension to RFC
   1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP
   versions 4 and 6.  The document provides functionally for datagram
   transports that is equivalent to the packetization layer PMTUD
   specification for TCP, specified in RFC4821.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 4, 2018.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of

Fairhurst, et al.        Expires January 4, 2018                [Page 1]
Internet-Draft              Datagram PLPMTUD                   July 2017

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  PMTU Probing Methods  . . . . . . . . . . . . . . . . . .   7
   4.  Specification of PMTUD for Packetization Layers . . . . . . .   7
   5.  Specification or Protocol Specific Methods  . . . . . . . . .   7
     5.1.  UDP and UDP-Lite  . . . . . . . . . . . . . . . . . . . .   8
       5.1.1.  UDP Options . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  SCTP  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.2.1.  SCTP/IP4 and SCTP/IPv6  . . . . . . . . . . . . . . .   8
         5.2.1.1.  Probing . . . . . . . . . . . . . . . . . . . . .   8
         5.2.1.2.  PTB Message Handling  . . . . . . . . . . . . . .   9
       5.2.2.  SCTP/UDP  . . . . . . . . . . . . . . . . . . . . . .   9
         5.2.2.1.  Probing . . . . . . . . . . . . . . . . . . . . .   9
         5.2.2.2.  PTB Message Handling  . . . . . . . . . . . . . .   9
       5.2.3.  SCTP/DTLS . . . . . . . . . . . . . . . . . . . . . .   9
         5.2.3.1.  Probing . . . . . . . . . . . . . . . . . . . . .   9
         5.2.3.2.  PTB Message Handling  . . . . . . . . . . . . . .   9
     5.3.  DCCP  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.3.1.  DCCP/UDP  . . . . . . . . . . . . . . . . . . . . . .  10
     5.4.  QUIC  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Revision Notes . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   The IETF has specified datagram transport using UDP, SCTP, SCTP/UDP,
   DCCP, and DCCP/UDP as well as upper layer protocols layered on top of
   these transports.

   Classical Path MTU Discovery (PMTUD) can be used with any transport
   that is able to process ICMP Packet Too Big (PTB) messages (e.g.,
   [RFC1191][I-D.ietf-6man-rfc1981bis]).  It adjusts the Effective Path

Fairhurst, et al.        Expires January 4, 2018                [Page 2]
Internet-Draft              Datagram PLPMTUD                   July 2017

   MTU (PMTU), based on reception of ICMP PTB messages to decrease the
   PMTU when this is larger than the value supported along a path, and a
   method that increases the packet size in attempt to discover an
   increase in the supported PMTU.  However, ICMP messages are being
   increasingly filtered by middleboxes (including Firewalls) [RFC4890].
   Classical PMTUD is therefore subject to protocol failures (e.g.,
   traffic using a packet size larger than the actual supported PMTU is
   blackholed when ICMP PTB messages are not delivered for some reason
   [RFC2923]).

   Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not
   rely upon network or transport support for ICMP messages and is
   therefore considered more robust than Classical PMTUD.  This has
   become the preferred approach for TCP traffic.  The general strategy
   is for the Packetization Layer to find an appropriate PMTU by sending
   probe packets along the path with a progressively larger packet size.
   If a probe packet is successfully delivered (as determined by the
   PL), then the effective Path MTU is raised to the probe size.
   PLPMTUD introduces flexibility in the implementation of classical
   PMTUD.  It can be configured to only perform ICMP black hole recovery
   to increase the robustness of classical PMTUD, or at the other
   extreme, all ICMP processing can be disabled and PLPMTUD can
   completely replace classical Path MTU Discovery.  Using PLPMTUD,
   classical Path MTU Discovery can also be modified to include
   additional consistency checks without increasing the risk of
   connection hangs due to spurious failures of the additional checks.

   The UDP-Guidelines [RFC8085] state "an application SHOULD either use
   the path MTU information provided by the IP layer or implement Path
   MTU Discovery (PMTUD)", but does not provide a mechanism for
   discovering the largest size of unfragmented datagram than can be
   used on a path.  This specification describes how these datagram
   transports perform PLPMTUD.  This mechanism has not currently been
   specified for UDP, while Section 10.2 of [RFC4821] specifies a
   recommended PLPMTUD probing method for SCTP.

   Section Section 4 of this document presents a set of algorithms for
   datagram protocols to discover the maximum transmission unit possible
   on a path at the packetization layer.  The methods described rely on
   features of transport protocols and apply to transport protocols over
   IPv4 and IPv6.  They do not require cooperation from the lower layers
   (except that they are consistent about which packet sizes are
   acceptable) or from peers.

Fairhurst, et al.        Expires January 4, 2018                [Page 3]
Internet-Draft              Datagram PLPMTUD                   July 2017

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Other terminology is directly copied from [RFC4821], the EMTU
   definitions are from [RFC1122].

   Address:  An IP Layer identifier for an interface or a set of
      interfaces.

   Classical Path MTU Discovery:  The process described in [RFC1191] and
      [I-D.ietf-6man-rfc1981bis], in which nodes rely on ICMP PTB
      messages to learn the MTU of a path.

   Datagram:  A transport-layer protocol data unit, transmitted in the
      payload of an IP packet.

   Effective PMTU:  The current estimated value for PMTU used by a
      Packetization Layer.

   EMTU_S:  The Effective MTU for sending (EMTU_S) is designated in
      [RFC1122] as " the maximum IP datagram size that may be sent, for
      a particular combination of IP source and destination
      addresses..."

   EMTU_R:  The Effective MTU for receiving (EMTU_R) is designated in
      [RFC1122] as "the largest datagram size that can be reassembled by
      EMTU_R ("Effective MTU to receive")"

   Interface:  A node's attachment to a link.

   Link:  A communication facility or medium over which nodes can
      communicate at the link layer, i.e., the layer immediately below
      IP.  Examples are Ethernet LANs and Internet (or higher) layer and
      tunnels.

   Link MTU:  Maximum Transmission Unit, the size in bytes of the
      largest IP packet, including the IP header and payload, that can
      be transmitted on a link or path.  Note that this could more
      properly be called the IP MTU, to be consistent with how other
      standards organizations use the acronym MTU.  This includes the IP
      header, but excludes link layer headers and other framing that is
      not part of IP or the IP payload.  Be aware that other standards
      organizations generally define link MTU to include the link layer
      headers.

Fairhurst, et al.        Expires January 4, 2018                [Page 4]
Internet-Draft              Datagram PLPMTUD                   July 2017

   Packet:  An IP header plus the IP payload.

   Packetization Layer:  The layer of the network stack that places data
      into packets and performs transport protocol functions.

   Path:  The set of links traversed by a packet between a source node
      and a destination node.

   Path MTU, or PMTU:  The minimum link MTU of all the links in a path
      between a source node and a destination node.

   PLPMTUD:  Packetization Layer Path MTU Discovery, the method
      described in this document, which is an extension to classical
      PMTU Discovery.

3.  Requirements

   All of the requirements in [RFC4821] apply.  There are also a number
   of design constraints imposed by datagram transports.  TCP PLPMTUD
   has been defined using standard TCP protocol mechanism.  Unlike TCP,
   some datagram transports require additional or optional mechanisms to
   implement PLPMTUD.  This can place constraints on deployment when
   only one end supports the new method.

   There are eight functions that any Datagram PLPMTUD mechanisms needs
   to perform:

   1.  PMTU parameters: A method MUST utilize information about the
       maximum size of packet that can be transmitted by the sender on
       the local link (Link MTU) and MAY utilize similar information
       about the receiver link, when this is supplied (note this may be
       less than EMTU_R).  Some applications also have a maximum
       transport protocol data unit (PDU) size, in which case there may
       be no benefit from probing for a size larger than this (unless a
       transport offers benefit from multiplexing multiple applications
       PDUs into the same datagram.)

   2.  Effective PMTU: A datagram applications MUST be able to choose
       the size of datagrams sent to the network, based on the effective
       MTU.  This value is managed by the PMTUD method, and sets the
       maximum size of datagram that an application can send.  The
       effective PMTU (specified in Section 1 of [RFC1191]) is
       equivalent to the EMTU_S (specified in [RFC1122]).

   3.  Processing ICMP PTB messages: A method MAY optionally utilize
       ICMP PTB information from the network layer to help identify when
       a path does not support a message size (i.e. reduce the effective
       PMTU).  The validity of PTB messages SHOULD to be verified before

Fairhurst, et al.        Expires January 4, 2018                [Page 5]
Internet-Draft              Datagram PLPMTUD                   July 2017

       they are used to update the path MTU discovery information
       [I-D.ietf-6man-rfc1981bis].

   4.  Path validation: An endpoint needs to confirm the current path
       support the current effective datagram size, without relying
       solely on ICMP PTB messages.  In this respect, the mechanism MUST
       be robust to path changes that could have occurred since the path
       characteristics were last confirmed.  A method MUST also be
       robust to the possibility that a flow encounters reordering, or
       has the traffic divided over more than one network path.

   5.  When to probe: An endpoint method SHOULD determine whether the
       path capacity has increased since it last measured the path
       characteristics.  The endpoint needs a method to determine when a
       probe datagram is transmitted, and it MUST cache the values
       between probes.  This method needs to consider the disruption
       that may be incurred by an unsuccessful probe - both upon the
       flow that incurs a probe loss, and other flows that experience
       the effect of additional probe traffic.

   6.  Reception feedback: An endpoint MUST provide a feedback method to
       indicate when a probe message has been received by the remote
       endpoint.  If the data in the probe message needs to be sent
       reliably, the transport needs to arrange retransmission/repair of
       any resulting loss.  The method also needs to be robust in the
       case where probe messages are lost due to other reasons than a
       PMTU exceeded (e.g., link transmission error, congestion).  The
       isolated loss of a probe packet (with or without an ICMP Packet
       Too Big message) is treated as an indication of an MTU limit, and
       not as a congestion indicator.  In this case alone, the
       Packetization Protocol is permitted to retransmit any missing
       data without adjusting the congestion window.

   7.  Shared state: The specification of PLPMTUD [RFC4821] states: "If
       PLPMTUD updates the MTU for a particular path, all Packetization
       Layer sessions that share the path representation (as described
       in Section 5.2 of RFC821) SHOULD be notified to make use of the
       new MTU and make the required congestion control adjustments".
       Such methods need to robust to the wide variety of underlying
       network forwarding behaviours.  Considerations about caching have
       been noted [I-D.ietf-6man-rfc1981bis].

   8.  Not interfere with congestion control: If the transport protocol
       implements a congestion control, the loss of a probe packet
       SHOULD NOT affect the congestion control if the probe packets are
       not contain user data.

Fairhurst, et al.        Expires January 4, 2018                [Page 6]
Internet-Draft              Datagram PLPMTUD                   July 2017

3.1.  PMTU Probing Methods

   Many datagram protocols provide mechanisms to distinguish in-band
   data from padding.  In contrast, TCP to generate probes by
   appropriately segmenting data.  There are three ways of creating
   probes, using application data, using application data and padding
   and padding only:

   o  A probe datagram can contain only padding (these probes consume
      capacity, but do not require retransmission of user data) and
      control data.

   o  A probe datagram can contain user data that is combined with
      control data and padding to inflate the length of the datagram to
      the size required for the probe.  A loss of this probe could
      require retransmission/repair of the data if required by the
      application/transport.

   o  A probe datagram can contain data supplied by an application that
      matches the size required for the probe.  This requires a method
      to request the application to issue a packet of the desired probe
      size.  A loss of this probe could require retransmission/repair of
      the data if required by the application/transport.

   Three approaches are possible for providing datagram reliability:

   1.  A transport/application does not require a probe datagram to be
       retransmitted in the event of the loss of a probe.

   2.  A transport/application requires retransmission of the data part
       of a probe in the event of a loss.

   3.  A transport/application is allowed to replicate the data sent in
       a probe in a packet (or packets) less than the size current
       effective PMTU to reduce the need for retransmission.

4.  Specification of PMTUD for Packetization Layers

   << Fill in a generic algorithm based on sending probe packets,
   receiving success indications and possibly handling PTB messages.
   These three operations are protocol specific and are described in
   Section 5 for various protocols.  >>

5.  Specification or Protocol Specific Methods

   << In future revisions of this document, this section may be divided
   into PMTUD and PLPMTUD methods >>

Fairhurst, et al.        Expires January 4, 2018                [Page 7]
Internet-Draft              Datagram PLPMTUD                   July 2017

5.1.  UDP and UDP-Lite

   UDP and UDP-LIte [RFC3828] do not provide a method that allows
   padding to be added to a datagram.

   << This section will be completed in a future revision of this ID >>

5.1.1.  UDP Options

   UDP places additional design requirements on an application that
   wishes to use PLPMTUD.  UDP Options permits padding to be added to
   UDP datagrams [I-D.ietf-tsvwg-udp-options], and can be used to
   provide reception feedback.  Therefore, UDP-Options can be used to
   assist UDP applications by supplying the additional functionality and
   using this to provide a Datagram PMTUD service similar to that
   offered by other transports.

   << This section will be completed in a future revision of this ID >>

5.2.  SCTP

   Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing
   method for SCTP.  It recommends use of the PAD chunk, defined in
   [RFC4820] to be attached to a minimum length HEARTBEAT chunk to build
   a probe packet.  This allows to perform probing without affecting the
   transfer of user messages and without interfering with congestion
   control.  Therefore it is preferred to the use of DATA chunks (with
   padding as required) to serve as path probes.

   << We might define a parameter contained in the INIT and INIT ACK
   chunk to indicated the MTU to the peer.  However, multihoming makes
   this a bit complex, so it might not be worth doing. >>

5.2.1.  SCTP/IP4 and SCTP/IPv6

   The base protocol is specified in [RFC4960].

5.2.1.1.  Probing

   Probe packets consist of an SCTP common header followed by a
   HEARTBEAT chunk and a PAD chunk.  The PAD chunk is used to control
   the length of the probe packet.  The HEARTBEAT chunk is used to
   trigger the sending of a HEARTBEAT ACK chunk.  The reception of the
   HEARTBEAT ACK chunk signals the successful probing.

Fairhurst, et al.        Expires January 4, 2018                [Page 8]
Internet-Draft              Datagram PLPMTUD                   July 2017

5.2.1.2.  PTB Message Handling

   Normal ICMP verification MUST be performed as specified in Appendix C
   of [RFC4960].  This requires that the first 8 bytes of the SCTP
   common header are contained in the ICMP packet, which is normally
   fulfilled by ICMPv4 and ICMPv6.

5.2.2.  SCTP/UDP

   The UDP encapsulation of SCTP is specified in [RFC6951].

5.2.2.1.  Probing

   The probing can be performed as specified in Section 5.2.1.1.

5.2.2.2.  PTB Message Handling

   Normal ICMP verification has to be performed as specified in
   [RFC4960].  However, this might not be possible for ICMPv4, since it
   is not guaranteed that the ICMP packet contains the first 8 bytes of
   the SCTP common header.  ICMPv6 packets should contain enough
   information to perform the required verification.

5.2.3.  SCTP/DTLS

   The DTLS encapsulation of SCTP is specified in
   [I-D.ietf-tsvwg-sctp-dtls-encaps].  It is used for data channels in
   WebRTC implementations.

5.2.3.1.  Probing

   The probing can be done as specified in Section 5.2.1.1.

5.2.3.2.  PTB Message Handling

   Normal ICMP verification can not be performed as specified in
   [RFC4960], since even if the ICMP contains enough information, the
   reflected SCTP common header would be encrypted.  Therefore it is not
   possible to process ICMP PTB messages.

5.3.  DCCP

   DCCP [RFC4340] implementations are required to support classical
   PMTUD and states that a DCCP sender "MUST maintain the maximum packet
   size (MPS) allowed for each active DCCP session" and also defines
   "current congestion control mechanism (CCMPS), the maximum packet
   size supported by the path's links".  It recommends use of PMTUD, and
   suggests use of DCCP-Sync packets as path probes, because they do not

Fairhurst, et al.        Expires January 4, 2018                [Page 9]
Internet-Draft              Datagram PLPMTUD                   July 2017

   risk application data loss.  It does not currently specify the use of
   PLPMTUD methods that could work independently of the ability to
   utilise ICMP PTB messages.

   << This section will be completed in a future revision of this ID >>

5.3.1.  DCCP/UDP

   DCCP/UDP is a UDP-based transport that permits padding to be added to
   datagrams, and can provide reception feedback.

   << This section will be completed in a future revision of this ID >>

5.4.  QUIC

   QUIC is a UDP-based transport that provides reception feedback
   [draft-ietf-quic-transport].

   << This section will be completed in a future revision of this ID >>

6.  Acknowledgements

   This work was partially funded by the European Union's Horizon 2020
   research and innovation programme under grant agreement No. 644334
   (NEAT).  The views expressed are solely those of the author(s).

7.  IANA Considerations

   This memo includes no request to IANA.

   If there are no requirements for IANA, the section will be removed
   during conversion into an RFC by the RFC Editor.

8.  Security Considerations

   The security considerations for the use of UDP and SCTP are provided
   in the references RFCs.  Security guidance for applications using UDP
   is provided in the UDP-Guidelines [RFC8085].

   ICMP PTB messages could potentially be used to cause a node to
   inappropriately reduce the PMTU.  A node supporting PLPMTUD SHOULD
   appropriately validate the payload of ICMP PTB messages to ensure
   these are received in response to transmitted traffic (i.e., a
   reported error condition that corresponds to a datagram actually sent
   by the path layer.

Fairhurst, et al.        Expires January 4, 2018               [Page 10]
Internet-Draft              Datagram PLPMTUD                   July 2017

9.  References

9.1.  Normative References

   [I-D.ietf-6man-rfc1981bis]
              <>, J., <>, S., <>, J., and R. Hinden, "Path MTU Discovery
              for IP version 6", draft-ietf-6man-rfc1981bis-08 (work in
              progress), May 2017.

   [I-D.ietf-tsvwg-sctp-dtls-encaps]
              Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
              Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
              dtls-encaps-09 (work in progress), January 2015.

   [I-D.ietf-tsvwg-udp-options]
              Touch, J., "Transport Options for UDP", draft-ietf-tsvwg-
              udp-options-01 (work in progress), June 2017.

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <http://www.rfc-editor.org/info/rfc1122>.

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

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
              and G. Fairhurst, Ed., "The Lightweight User Datagram
              Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
              2004, <http://www.rfc-editor.org/info/rfc3828>.

   [RFC4820]  Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
              Parameter for the Stream Control Transmission Protocol
              (SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
              <http://www.rfc-editor.org/info/rfc4820>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <http://www.rfc-editor.org/info/rfc4960>.

   [RFC6951]  Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
              Control Transmission Protocol (SCTP) Packets for End-Host
              to End-Host Communication", RFC 6951,
              DOI 10.17487/RFC6951, May 2013,
              <http://www.rfc-editor.org/info/rfc6951>.

Fairhurst, et al.        Expires January 4, 2018               [Page 11]
Internet-Draft              Datagram PLPMTUD                   July 2017

   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <http://www.rfc-editor.org/info/rfc8085>.

9.2.  Informative References

   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
              DOI 10.17487/RFC1191, November 1990,
              <http://www.rfc-editor.org/info/rfc1191>.

   [RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery",
              RFC 2923, DOI 10.17487/RFC2923, September 2000,
              <http://www.rfc-editor.org/info/rfc2923>.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340,
              DOI 10.17487/RFC4340, March 2006,
              <http://www.rfc-editor.org/info/rfc4340>.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
              <http://www.rfc-editor.org/info/rfc4821>.

   [RFC4890]  Davies, E. and J. Mohacsi, "Recommendations for Filtering
              ICMPv6 Messages in Firewalls", RFC 4890,
              DOI 10.17487/RFC4890, May 2007,
              <http://www.rfc-editor.org/info/rfc4890>.

Appendix A.  Revision Notes

   Note to RFC-Editor: please remove this entire section prior to
   publication.

   Individual draft -00:

   o  This is the first version.  Comments and corrections are welcome
      directly to the authors or via the IETF TSVWG working group
      mailing list.

Authors' Addresses

Fairhurst, et al.        Expires January 4, 2018               [Page 12]
Internet-Draft              Datagram PLPMTUD                   July 2017

   Godred Fairhurst
   University of Aberdeen
   School of Engineering
   Fraser Noble Building
   Fraser Noble Building Aberdeen  AB24 3UE
   UK

   Email: gorry@erg.abdn.ac.uk

   Tom Jones
   University of Aberdeen
   School of Engineering
   Fraser Noble Building
   Aberdeen  AB24 3UE
   UK

   Email: tom@erg.abdn.ac.uk

   Michael Tuexen
   Muenster University of Applied Sciences
   Stegerwaldstrasse 39
   Steinfurt  48565
   DE

   Email: tuexen@fh-muenster.de

   Irene Ruengeler
   Muenster University of Applied Sciences
   Stegerwaldstrasse 39
   Steinfurt  48565
   DE

   Email: i.ruengeler@fh-muenster.de

Fairhurst, et al.        Expires January 4, 2018               [Page 13]