Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard

Fernando Gont <> Thu, 02 February 2017 10:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B698B129437; Thu, 2 Feb 2017 02:16:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gbk0VQYzUp0t; Thu, 2 Feb 2017 02:16:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB784129422; Thu, 2 Feb 2017 02:16:52 -0800 (PST)
Received: from [IPv6:2001:1291:200:42e::2] ( [IPv6:2001:1291:200:42e::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id EAA2782BA4; Thu, 2 Feb 2017 11:16:46 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
To: "Eggert, Lars" <>, "" <>
References: <> <>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 2 Feb 2017 06:54:16 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Feb 2017 10:16:58 -0000

Hi, Lars,

On 02/02/2017 06:37 AM, Eggert, Lars wrote:
> Hi,
> the last paragraph of the introduction reads:
> An extension to Path MTU Discovery defined in this document can be 
> found in [RFC4821].  It defines a method for Packetization Layer
> Path MTU Discovery (PLPMTUD) designed for use over paths where
> delivery of ICMP messages to a host is not assured.
> Given that ICMP delivery cannot be assured over the vast majority of
> paths in the current Internet, should this document make a
> recommendation to implement RFC4821?

I think that RFC4821 should be recommended, at least for dealing with
ICMP blackholes (i.e., use ICMP if you can, but be able to deal with
scenarios in which you don't receive them).

> Also, even if ICMP delivery is assured, there are additional
> complications for UDP, which has been seeing a lot of interest both
> as a tunneling encapsulation and for applications (e.g., QUIC). Many
> platforms do not provide UDP-sending applications any information
> about arriving ICMP messages that were triggered by their
> transmissions. So even if the path delivers ICMP, the OS makes
> ICMP-based PMTUD for UDP often impossible. Another reason to
> recommend 4821?

Agreed... although in this case this would be more of an app-layer
implementation than one at the transport layer?

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492