Skip to main content

Path MTU Discovery for IP version 6

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: The IESG <>,, Ole Troan <>,,,,,
Subject: Protocol Action: 'Path MTU Discovery for IP version 6' to Internet Standard (draft-ietf-6man-rfc1981bis-08.txt)

The IESG has approved the following document:
- 'Path MTU Discovery for IP version 6'
  (draft-ietf-6man-rfc1981bis-08.txt) as Internet Standard

This document is the product of the IPv6 Maintenance Working Group.

The IESG contact persons are Suresh Krishnan and Terry Manderson.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

   This document describes Path MTU Discovery for IP version 6.  It is
   largely derived from RFC 1191, which describes Path MTU Discovery for
   IP version 4.  It obsoletes RFC1981.

Working Group Summary

   The 6MAN working started working on advancing the IPv6 core
   specifications to Internet Standard at IETF93 July 2015.  See: The
   working group identified three RFCs to update (RFC2460, RFC4291, and
   RFC1981) by incorporating updates from other RFCs and Errata, and
   three to advance in place RFC4443, RFC3596, and RFC4941.  After
   further analysis, the w.g. decided to not reclassify RFC4941 at this
   The working followed the requirements in RFC6410 for advancing a Draft
   Standard to Internet Standard.  While RFC6410 describes how to handle
   Errata, it doesn't say anything about Updated-By RFCs.  The working
   group, with the advice of our AD, incorporated the changes from the
   the Updated-By RFC and verified there was interoperability of the

   All of the Updated-By and errata were brought into the new draft in
   small steps to allow thorough review of all of the changes.  A summary
   and link to diff from the previous version was sent to the mailing
   list.  All of the changes to each draft were also discussed in detail
   at IETF94, IETF95, IETF96, and IETF97.  All of the changes from
   RFC1981 are summarized in Appendix B and are ordered by the Internet
   Draft that brought the change in.

   This document is an update to RFC1981 that was published prior to
   RFC2119 being published.  Consequently while it does use "should/must"
   style language in upper and lower case, the document does not cite the
   RFC2119 definitions.  Since the changes in this update were very
   limited, the w.g. concluded to not change any of this language.
   A working group last call for moving this and the other two documents
   to Internet Standard was started on 30 May 2016.  Reviews were also
   requested.  Issues found during the last call and reviews were entered
   into the 6MAN ticket system.  These are now closed.

Document Quality

   IPv6 is implemented on most platforms (hosts, routers, servers, etc.),
   including proprietary and open source.  A list of products that have
   received the IPV6 Ready logo can be found at:

   Most major ISP now support IPv6, as well as many mobile

   Google’s IPv6 stats at show they are
   seeing now about 15% of their overall user traffic is IPv6. Country
   adoption is 29% in the US, Germany 27%, Finland 12%, Japan 14%, Brazil
   11%.  IPv6 users per AS can be found at

   The University of New Hampshire InterOperability Laboratory (UNH)
   analyzed the incorporated updates to insure they were implemented and
   interoperable.  No problems were found.  Their report can be found at:

   No MIB, Media, or other expert reviews are required.


   Document Shepherd: Ole Trøan
   Responsible AD: Suresh Krishnan

IETF Last Call Summary

  The document received lots of comments during IETF last call. The two main classes of issues that were brought up were transport layer related issues and security related issues. These issues have been fixed in the latest version of the document. There was also some concern raised about the effects of ICMPv6 filtering on the Internet on the PMTUD protocol. To address this, text was added to the introduction to describe the effects of ICMPv6 filtering.

RFC Editor Note

RFC Editor Note


 Alternatively, the retransmission could be done in immediate response
 to a notification that the Path MTU was decreased, but only for the
 specific connection specified by the Packet Too Big message, but only 
 based on the message and connection.


 Alternatively, the retransmission could be done in immediate response
 to a notification that the Path MTU was decreased, but only for the
 specific connection specified by the Packet Too Big message.