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

otroan@employees.org Tue, 07 February 2017 20:06 UTC

Return-Path: <otroan@employees.org>
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 8BC53129479; Tue, 7 Feb 2017 12:06:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 5w2zLhM_smVV; Tue, 7 Feb 2017 12:06:56 -0800 (PST)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id ED6A3129469; Tue, 7 Feb 2017 12:06:55 -0800 (PST)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 07 Feb 2017 20:06:55 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id BCE0DD788B; Tue, 7 Feb 2017 12:06:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=jOU8v6ZBAvPbtl+xZiGNGsoCG4s=; b= id8bWcgjCeedR41fu2d0c8Inq+V3XePcaJJCJHX94JbiWqurVopCAoQ4+uha+M/7 ITV8X7YLUSI77BlxzY4BXGRAAXaNq6sn06u1I7bc22CROJwW2E2FdIegs+Gc6pfM D0KgoF9JEXO/q/sqkBmjDlx0YhowllTB9LKzml46WYQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=OqLXn/wzV+DhONXHo/wG+dn B1HalaZxtELShFeSmpkZ/PmZsE/JgIg77/KqV/9SCNYV+smyH61lbFYbPjoJ1f7+ B7FDd8d9ssOidLENTyzLPrYx8MVor8U4XBPg9ffRPPj6XzRsW1LAYacuk6w76ck/ TlhR6Y+lGJkvYEV08XvY=
Received: from h.hanazo.no (96.51-175-103.customer.lyse.net [51.175.103.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 5C3DED788A; Tue, 7 Feb 2017 12:06:54 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 5AE32865EDDD; Tue, 7 Feb 2017 21:06:52 +0100 (CET)
From: otroan@employees.org
Message-Id: <E11F9A4D-DE9E-4BFD-8D0D-252842719FC5@employees.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_8956E3FC-51F0-4D13-B11D-5926009E0DE7"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
Date: Tue, 07 Feb 2017 21:06:51 +0100
In-Reply-To: <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu>
To: Joe Touch <touch@isi.edu>
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>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tMq3x_VufeivcfK8PHR8dnaNXm8>
Cc: 6man WG <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-6man-rfc1981bis@ietf.org" <draft-ietf-6man-rfc1981bis@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "Eggert, Lars" <lars@netapp.com>, "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 20:06:57 -0000

Joe,

[...]

>>> 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.

No, but it was unfortunately all that was written about how to use PLMTUD for tunnels.

> 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:
>> 
>> http://www.arkko.com/tools/allstats/citations-rfc1981.html
>> 
>> 
>> 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.

Right, but if you are correct that ICMP-based MTU discovery is not viable then this document should not be advanced.
At the same time for many protocols we have nothing else. An operator can break any protocol if that's their policy. And that's the breakage we're talking about here, not any issues with the protocol specification.

There is a philosophical aspect of this. (Which I'm not the best person to represent as I skipped my University studies in philosophy and used the student loan to buy a motorcycle... (and only read the art of motorcycle maintenance years later) )
This is a tussle. The IETF specifies protocols under the assumption that operators treat those protocols largely as specified. The 5-10% failure of PMTUD messages may be caused by misconfiguration, misunderstanding or mis-intent... Many of our protocols are suffering from the same fate. Should the IETF adjust all its protocols to be as middlebox friendly as possible? You can make this argument about IPv6 fragments, any packet with IPv6 extension headers, IPv4 fragments. Or anything but TCP port 443/80 and UDP port 53 for that matter. Are we as the IETF going to continue standardising protocols to work as best as they possible can, ignoring protocol abuse, or are we going to bend over and do whatever it takes to make it work for those 5-10% who've actively broken the protocol? What about the 90-90% where the protocols work as expected?

Best regards,
Ole