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

Joe Touch <> Tue, 07 February 2017 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C54B129E62; Tue, 7 Feb 2017 11:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KxKkV7ncjxCd; Tue, 7 Feb 2017 11:42:47 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEB4F129E5B; Tue, 7 Feb 2017 11:42:46 -0800 (PST)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v17JgVpO008880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Feb 2017 11:42:32 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
References: <> <> <> <> <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Tue, 07 Feb 2017 11:42:29 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------07D681C8AAE849D500F6504E"
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Cc: 6man WG <>, "" <>, "" <>, "" <>, "Eggert, Lars" <>, "" <>
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: Tue, 07 Feb 2017 19:42:48 -0000

On 2/7/2017 11:20 AM, wrote:
> Joe,
>>>>> 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.
>>>> What Fernando said: I'm certainly not opposed to lifting this to Standard, but it is painting an incorrect picture - PLPMTUD is de facto mandatory these days, and has been for years.
>>> While I'm all in favour of PLMTUD. It doesn't seem like a complete solution.
>>> PMTUD on the other hand supports all protocols on top of IP.
>> If by "supports" you mean "doesn't work", then yes. That's why we now
>> have PLPMTUD.
> PLMTUD is unfortunately not a (complete) replacement of PMTUD.

PLMTUD is a directive to protocols above the IP layer; it isn't a single
protocol, so it wouldn't replace anything.

>>> Looking just at our specifications, we cannot state that PLMTUD can replace PMTUD. Take RFC2473 (IPv6 tunnelling) for example.
>> See draft-ietf-intarea-tunnels, esp. v03 Section 5.5.2
>> (yes, that doc has expired while we're preparing the 04 update, which
>> should be issued shortly)
> Is this the paragraph you are referring to?
>    PLPMTUD requires a separate,
>    direct control channel from the egress to the ingress that provides
>    positive feedback; the direct channel is not blocked by policy
>    filters and the positive feedback ensures fail-safe operation if
>    feedback messages are lost [RFC4821].
That is nowhere near section 5.5.2.

5.5.2 indicates places where RFC2473 has errors, esp. in how it
interprets the MTU of the tunnel as being defined by the MTU of the path
within the tunnel, rather than by the tunnel egress reassembly limit.

> I'm very much in favour of working on better ways of doing Path MTU discovery.
> A blanket statement of "use "PLMTUD" seems very premature though.
The point is that this document fails to indicate the current state of
PMTUD. It correctly notes that:

   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.

IMO, it fails to note that this case - where ICMP messages are assured
along a path - is effectively a unicorn except within systems maintained
by a single entity.

> RFC1981 has 70 citations:
> Could you expand on your view of how this pertains to advancing RFC1981?
It's called last call input. My input is that this document needs to be
more realistic in noting that, for all intents, ICMP-based MTU discovery
isn't viable and that other methods need to be *expected*, not just that
they're available.