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

Fernando Gont <> Fri, 03 February 2017 19:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B47C1294D5; Fri, 3 Feb 2017 11:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.851
X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZuRCYLoEHChk; Fri, 3 Feb 2017 11:05:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BD401296AD; Fri, 3 Feb 2017 11:05:57 -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 1F1288362C; Fri, 3 Feb 2017 20:05:51 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
To: Brian E Carpenter <>, "Eggert, Lars" <>, "" <>
References: <> <> <> <>
From: Fernando Gont <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Thu, 2 Feb 2017 23:00:27 -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=utf-8
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: Fri, 03 Feb 2017 19:06:00 -0000

On 02/02/2017 09:18 PM, Brian E Carpenter wrote:
> On 02/02/2017 22:54, Fernando Gont wrote:
>> 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).
> Many people think that, but this draft is constrained by the rules in
> RFC6410 about "high degree of technical maturity" and "widespread
> deployment" in the move from PS to Standard. Adding new stuff is not
> supposed to happen. If I recall correctly, the WG tuned the language
> to its present state for that reason.

My apologies: my comments were probably misleading. Certainly, this
document is simply RFC1981 to Std, and hence recommending RFC4821 would
be kind of ou of scope, here.

That say, one might wonder to what extent, and for the general Internet,
RFC1981 can be considered succesful (given the filtering of ICMP
messages). -- i.e., at this point in time you wouldn't rely on RFC1981
(icmp-based pmtud) for path-mtu discovery.


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