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

Joe Touch <touch@isi.edu> Thu, 16 February 2017 18:47 UTC

Return-Path: <touch@isi.edu>
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 1ADC1129615; Thu, 16 Feb 2017 10:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtceYG7Phd1o; Thu, 16 Feb 2017 10:47:33 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6067E12953E; Thu, 16 Feb 2017 10:47:33 -0800 (PST)
Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (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
To: gorry@erg.abdn.ac.uk
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> <8fbc3cbd-ff2d-f2c6-ccd7-13a20c6aa5ca@erg.abdn.ac.uk>
From: Joe Touch <touch@isi.edu>
Message-ID: <935cf01c-a0f2-af0c-b60b-89ff04091eb2@isi.edu>
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: <8fbc3cbd-ff2d-f2c6-ccd7-13a20c6aa5ca@erg.abdn.ac.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GHmDUURP_dZV-D5-tWHqWRpScF8>
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
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 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.

Joe