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

Joe Touch <touch@isi.edu> Tue, 07 February 2017 19:53 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 554FC12947F; Tue, 7 Feb 2017 11:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 bWP9F8RG3rNQ; Tue, 7 Feb 2017 11:53:22 -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 ED6F2129E5E; Tue, 7 Feb 2017 11:53:21 -0800 (PST)
Received: from [128.9.184.104] ([128.9.184.104]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v17JqW93010479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 7 Feb 2017 11:52:34 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, "otroan@employees.org" <otroan@employees.org>, "Eggert, Lars" <lars@netapp.com>
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> <ac0876415348463296df9bc4ca171141@XCH15-06-08.nw.nos.boeing.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <9836c58c-e533-a69f-a1b7-ed20ce4801e6@isi.edu>
Date: Tue, 7 Feb 2017 11:52:33 -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: <ac0876415348463296df9bc4ca171141@XCH15-06-08.nw.nos.boeing.com>
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/uGUwX6I4i9pT7BNdFuT-ia7LJQM>
Cc: 6man WG <ipv6@ietf.org>, "draft-ietf-6man-rfc1981bis@ietf.org" <draft-ietf-6man-rfc1981bis@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@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: Tue, 07 Feb 2017 19:53:23 -0000

Hi, Fred,

This is a separate issue with RFC4821, though.

My point for 1981bis is that it needs to be more clear that ICMP
blocking renders this technique ineffective for the most part. I'm not
saying that PLPMTUD is perfect or the only alternative, but this doc
should be more clear about its own viability.

Joe


On 2/7/2017 11:45 AM, Templin, Fred L wrote:
> Hi Joe,
>
> In my understanding, RFC4821 does not adequately address scenarios where the
> probe packets may (for legitimate reasons) take a different path than the data
> packets, e.g., when Equal-Cost Multi Path (ECMP) is present. This is not only a
> consideration for tunnels, but also for path MTU sharing between transport layer
> sessions where an MTU learned by a first session is shared with a second session
> bound for the same destination. In that case, the probes of the first session may
> take a different path than the data packets of the second session, and a black
> hole is possible.
>
> Thanks - Fred
> fred.l.templin@boeing.com
>
>> -----Original Message-----
>> From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Joe Touch
>> Sent: Tuesday, February 07, 2017 10:26 AM
>> To: otroan@employees.org; Eggert, Lars <lars@netapp.com>
>> Cc: tsv-area@ietf.org; 6man-chairs@ietf.org; 6man WG <ipv6@ietf.org>rg>; ietf@ietf.org; draft-ietf-6man-rfc1981bis@ietf.org
>> Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
>>
>>
>>
>> On 2/4/2017 10:40 AM, otroan@employees.org wrote:
>>> Lars,
>>>
>>>>> 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.
>>
>>> 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)
>>
>> Joe
>>
>