Path MTU discovery solution space

Document Type Active Internet-Draft (individual)
Last updated 2018-09-28
Stream (None)
Intended RFC status (None)
Formats plain text pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           O. Troan
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                      September 28, 2018
Expires: April 1, 2019

                   Path MTU discovery solution space


   Path MTU discovery has turned out to be a thorny problem that has
   haunted the Internet community for decades.  Lately there has been
   some work both at the transport layer and at the network layer.  This
   memo lists the solutions the author is aware of from the perspective
   of the network layer.

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

   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 April 1, 2019.

Copyright Notice

   Copyright (c) 2018 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
   ( in effect on the date of
   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.

Troan                     Expires April 1, 2019                 [Page 1]
Internet-Draft                                            September 2018

1.  Introduction

   Path MTU discovery has turned out to be harder than expeced.  In IPv6
   we set out following the same model as for IPv4.  The sending host
   maintains a MTU cache, that is updated based on received ICMP PMTUD
   messages.  That solution has a few short-comings:

   o  Sending of ICMP PMTUD messages is throttled in routers [RFC4443]

   o  It's not efficient if links along the path have decreasingly
      smaller MTU, then multiple rounds of large packet, resulting ICMP
      PMTUD happens.

   o  ICMP might be ignored by host stacks / applications

   o  As ICMP looks different than application traffic, it might be
      blocked by routers.

   o  Doesn't work well in an anycast scenario (but what does).

2.  Requirements / Goals

   1.  Avoid MTU black-holes [RFC2923].

   2.  Detect the Path MTU in single round trip.

   3.  Adapt to varying MTU over the connection life time.

   4.  The signalling of the MTU back to the sender must be
       indistinguishable from application traffic to lessen risk of

   5.  Design a mechanism that ensures that neither MTU probes nor MTU
       signalling back to sender are more likely to be dropped than
       other application traffic.

   6.  Must be deployable and anchored in transport / application areas.

   7.  [Optional?]  Support neighbors on the same link which support
       higher MTU than link MTU see [I-D.van-beijnum-multi-mtu]

3.  Network layer solutions for Path MTU discovery

   o  PMTUD [RFC8201]

   o  On-path fragmentation, IPv4 style.  We know this one.

Troan                     Expires April 1, 2019                 [Page 2]
Internet-Draft                                            September 2018

   o  Packet truncation.  [I-D.leddy-6man-truncate].  The source sets a
      truncation elligble flag in the packet, routers on the path may
      truncate f the packet is too big, and sets a truncated done flag.
      Then the receiver signals the learnt forward MTU back to the
      sender.  Either via existing ICMP PMTUD or a transport layer
      option.  This is an example of a solution which does not require
      the sender having to accept packets from intermediate nodes.

   o  MTU recording.  Probe packets are sent, either as part of data
      packets, if those are guaranteed not to exceed MTU.  Some trigger
      in the header (ECN like flags) or a HBH option is required for the
      router to record the smallest MTU along the path.  Application /
      Transport would have to periodically include the probe trigger in
      data packets to detect changes in path MTU.

3.1.  Common problems

   How is the router along the path "triggered" to put this packet on
Show full document text