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

Joe Touch <> Thu, 16 February 2017 18:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1ADC1129615; Thu, 16 Feb 2017 10:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gtceYG7Phd1o; Thu, 16 Feb 2017 10:47:33 -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 6067E12953E; Thu, 16 Feb 2017 10:47:33 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v1GIkr89013536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 10:46:54 -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: Thu, 16 Feb 2017 10:46:52 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Cc: "" <>, "" <>, 6man WG <>, "" <>, "" <>
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, 16 Feb 2017 18:47:35 -0000

Hi, Gorry  (et al.),

On 2/16/2017 6:04 AM, Gorry Fairhurst wrote:
> On 15/02/2017 21:25, Joe Touch wrote:
>> Hi, Gorry (et al.),
>> On 2/14/2017 9:23 AM, Gorry Fairhurst wrote:
>>> There is no mention that paths including tunnels can eat ICMPv6 PTB
>>> messages on the tunnel segment, blackholing them, which prevents
>>> reaching the destination.
>> Nor should there be, IMO.
>> A tunnel is a link layer to the network whose packets it transits.
>> ICMPs generated inside a tunnel aren't "eaten", so much as they operate
>> at a different layer for a different reason (e.g., to tune
>> ingress-egress source fragmentation of encapsulated packets).
>> PTB messages inside a tunnel are (IMO) most correctly interpreted by the
>> ingress (which is an *interface* on a router or host, most correctly
>> IMO) as changing the MTU of the tunnel as a link. If that MTU change
>> affects packets that arrive later, then it would be the router where the
>> ingress is attached that would generate the ICMP, never the (ingress)
>> interface whose MTU is insufficient.
>> Again, I'm in the process of updating draft-ietf-intarea-tunnels to be
>> much more clear on this point (the update should be issued in a day
>> or two).
>> Joe
> I really disagree Joe - not in what you say about how things need to
> be, nor the relevance of draft-ietf-intarea-tunnels.
> The point of disagreement, is that I think the text needs to explain
> enough that people do NOT blindly believe this always works. the
> current text mentions tunnels in more than one place, as if they are
> just another usage of PMTUD.
> Tunnels can make path MTU diiscovery unreliable, because many deployed
> tunnel ingresses do not propagate ICMPv6 PTB messages upstream to
> reflect the limits of the Tunnel MTU. 

I'll send you a preview of the updated tunnel text privately (it will be
posted in a few days). Even the last version, however, explains why
individual PTB messages should not be relayed directly upstream.

The solution is as follows: PTB messages should update the ingress's
link MTU (where the tunnel is a link and the ingress is a network
interface). Subsequent messages at a router where the ingress is
attached would already generate the correct ICMP errors when they
receive later packets that are larger than that updated MTU.

> draft-ietf-intarea-tunnels discusses how a tunnel should be
> implemented to effectively work with a Tunnel MTU.
The above is a brief summary of what it discusses.

This document doesn't need to do much on this matter at all, except NOT
provide contradictory advise or imply otherwise.

IMO, whether a tunnel works correctly or not is a tunnel issue, not an
issue for a network protocol, just as this doc shouldn't enumerate other
link layer issues, such as problems with the need for broadcast on NBMA
links, etc.