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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 16 February 2017 14:04 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD161295F9; Thu, 16 Feb 2017 06:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZZZls4XwHuD; Thu, 16 Feb 2017 06:04:32 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 056501295E3; Thu, 16 Feb 2017 06:04:32 -0800 (PST)
Received: from dhcp-207-155.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:b82b:6073:afb4:ddb0]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 701411B00055; Thu, 16 Feb 2017 16:02:18 +0000 (GMT)
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <f8291774-409e-2948-3b29-83dbb09d39d9@si6networks.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <C0A114C1-5E4A-4B8E-A408-55AF1E30873F@netapp.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <E11F9A4D-DE9E-4BFD-8D0D-252842719FC5@employees.org> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <da3de0a5-fe7f-c874-db1d-da2684619213@si6networks.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <e201c72e-b7c1-5a5f-eacb-93896cd7a7bb@si6networks.com> <58A33D08.4090505@erg.abdn.ac.uk> <196e8c39-784a-3a25-b6ab-d7eaa664f0fa@isi.edu>
To: Joe Touch <touch@isi.edu>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683.
Message-ID: <8fbc3cbd-ff2d-f2c6-ccd7-13a20c6aa5ca@erg.abdn.ac.uk>
Date: Thu, 16 Feb 2017 14:04:28 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <196e8c39-784a-3a25-b6ab-d7eaa664f0fa@isi.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_gMkghPJQL_uuZXxo2p0bkp1fYM>
Cc: "tsv-area@ietf.org" <tsv-area@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-6man-rfc1981bis@ietf.org" <draft-ietf-6man-rfc1981bis@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2017 14:04:34 -0000

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. draft-ietf-intarea-tunnels 
discusses how a tunnel should be implemented to effectively work with a 
Tunnel MTU.

Gorry