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

Brian E Carpenter <> Fri, 03 February 2017 00:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB5B41299DC; Thu, 2 Feb 2017 16:18:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MyQ7SYhwKxGT; Thu, 2 Feb 2017 16:18:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2EFD129A2A; Thu, 2 Feb 2017 16:18:24 -0800 (PST)
Received: by with SMTP id e4so267740pfg.0; Thu, 02 Feb 2017 16:18:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=deEYrmpBvg11+JzjNRtxwV1Tsp8gPqKR4oNoJgnXoEA=; b=QYspm/+IdJmfnewoCYU3yPRcVN6etvbqMQd3yqmU6QjdJOdcS68S6fHBYgHI/f+EFF T5FAoYqFHNV0TWyhOyPYqEYX7U4XtfD4GcuT7ZaAC1U4oaO0V/Y5QSkEsDfjJ1rbg3YM qttkm8a7QLAQnEHC/qwGzs3EHJP7tMe0S8+BpQGvy1B31IsTSFw90JBy/isAWFlmZ+kg eeiSD36uPz4Yv6YL+SFTWofseuH1M8P2KjDB1MG2KRYGrjulJvJ58pwIS5D0cOPBGTv/ YVN0K/LcRGwoR5En0Tn+ZT+lp8nIBAMhONPXTViD2j8JGu+zOuqkbqYsRsT9OWZZdSbF G4Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=deEYrmpBvg11+JzjNRtxwV1Tsp8gPqKR4oNoJgnXoEA=; b=OPk7eWVaYwnsBDYoofn3GfzemG9aMG1oF89SngmCYTQBK3QHNWcKY7cCHpbmPx37XF UpwsEnQFOQVfHQ8c+t/XvVi0BH5QOG91uBBbB+wghhrtxDiAgJnBSntG3EejBLzH0MVo sCAGtLLkf50vVJ8JW0yhYZpH2ziall3UjI/byPDKwkQbND3qyBoD4AFdzZ4Py0QsdyJ+ bC/lfrzBED28n3ndghB7+cx4E8b0IQR9W/Oq5BI+JiNXhfX66aNoU7mfU+wb3gsTI6lf bHh67g2/bbMGxm90ufaXTojkEHnX5TpE8bh1CsHWUrXb6fdmoIhzuBvfQP1L7P+l/Rsw fXdg==
X-Gm-Message-State: AIkVDXIyOlk57oSEBbBVCxcTESvvEhZvyARlyi7oXEjXzffH0sUwbXdEuyTxXksVjjjZDw==
X-Received: by with SMTP id p7mr14096551pgn.125.1486081104103; Thu, 02 Feb 2017 16:18:24 -0800 (PST)
Received: from ?IPv6:2406:e007:7909:1:28cc:dc4c:9703:6781? ([2406:e007:7909:1:28cc:dc4c:9703:6781]) by with ESMTPSA id p6sm61393109pfg.6.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Feb 2017 16:18:23 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
To: Fernando Gont <>, "Eggert, Lars" <>, "" <>
References: <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Fri, 3 Feb 2017 13:18:27 +1300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
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 00:18:27 -0000

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.