Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04

"C. M. Heard" <heard@pobox.com> Sat, 11 February 2017 04:29 UTC

Return-Path: <heard@pobox.com>
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 07C631296C7; Fri, 10 Feb 2017 20:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.202
X-Spam-Level:
X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.com
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 E5Qaokb2pXGX; Fri, 10 Feb 2017 20:29:17 -0800 (PST)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A79771296C5; Fri, 10 Feb 2017 20:29:17 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 0EA2568668; Fri, 10 Feb 2017 23:29:16 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=J7x pklY1odrNjGqVtYjz9B4uWZY=; b=yXaBLrCPnxLafx7D0qum3k4NbB8+xyx7iEz 00imc1/3MTaNr3bcUq02dfnDzEMOdyxbjLuWZiGp4yb3b4fEtmXVNUikXp59fIV0 vUPAYFrx6q8UJYHIUc34hr9PNn6SEZGLbcN1P2Mp14BWtR558buoJY7tKuDDQsfk Ib5UGjoY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= smNhL4F9gBpktzecOhqVX2/Y/pcw8ZnrULbK3OzIXeZHwMIv5jNzwV9JbH7WPbpF gw3wimCUVKgp4KhiA/bAN+PN+TKoI56z7iZnLsCdQEprXP/FaPOe57K398AG4hVF BrjS0x+IeYwf4FwJT/gRD6T8FkIvXGtT/uCnmLcZmeY=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 047F168667; Fri, 10 Feb 2017 23:29:16 -0500 (EST)
Received: from mail-qk0-f169.google.com (unknown [209.85.220.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 6C89868664; Fri, 10 Feb 2017 23:29:15 -0500 (EST)
Received: by mail-qk0-f169.google.com with SMTP id 11so58490805qkl.3; Fri, 10 Feb 2017 20:29:15 -0800 (PST)
X-Gm-Message-State: AMke39lwbW0OzJwPBXJ578D/czmoj6CgBusemGyn2JSypeqMnxPbF/2P4Vy6/W3vgl9MqZsHq+UyKUG6dqBVGg==
X-Received: by 10.55.119.1 with SMTP id s1mr12786187qkc.81.1486787354703; Fri, 10 Feb 2017 20:29:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.18.106 with HTTP; Fri, 10 Feb 2017 20:28:54 -0800 (PST)
From: "C. M. Heard" <heard@pobox.com>
Date: Fri, 10 Feb 2017 20:28:54 -0800
X-Gmail-Original-Message-ID: <CACL_3VEyOriSb6fjvGbYvG5a3gKOYPEe89-w7B9C_A5y_A9O9Q@mail.gmail.com>
Message-ID: <CACL_3VEyOriSb6fjvGbYvG5a3gKOYPEe89-w7B9C_A5y_A9O9Q@mail.gmail.com>
Subject: Re: [Gen-art] Review of draft-ietf-6man-rfc1981bis-04
To: IETF <ietf@ietf.org>
Content-Type: text/plain; charset=UTF-8
X-Pobox-Relay-ID: A54B2766-F012-11E6-98C3-A7617B1B28F4-06080547!pb-smtp2.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/zTDYqhFatF218HWNVzOUe3tCxto>
Cc: Stewart Bryant <stewart@g3ysx.org.uk>, Gen-ART <gen-art@ietf.org>, 6man WG <ipv6@ietf.org>, draft-ietf-6man-rfc1981bis.all@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: Sat, 11 Feb 2017 04:29:19 -0000

On Fri, 10 Feb 2017 11:45 -0800 , Brian E Carpenter wrote:
> On 10/02/2017 23:20, Stewart Bryant wrote:
> > On 10/02/2017 03:25, Brian E Carpenter wrote:
> > > On 10/02/2017 04:19, Stewart Bryant wrote:
> > > > I wonder if we would best serve both our future and our heritage
> > > > if we declared RFC1981 as historic, and either left the idea there,
> > > > or declared it as historic and wrote a new text from a clean start?
> > >
> > > I don't see that. It's a stable, widely deployed, interoperable
> > > mechanism. That is rather orthogonal to the issue that has been raised,
> > > which is that faulty ICMPv6 filtering blocks it on many, many paths
> > > across the Internet.
> >
> > I will not debate whether it is faulty or not,
>
> It's faulty by the standard of RFC4890 (which is Informational).
>
> > but it seems that in practice the Internet breaks the mechanism.
> > However it breaks it is a way that seems disruptive to some user
> > traffic. The document is really guidance one how hosts might use
> > ICMP for optimization, and arguabl[y] need not be a standard at all.
>
> I think that's a mischaracterisation of the mechanism (and the draft).
> PMTUD is not an optimisation. Without it, you get black holes.

Actually, no. You do not have to use PMTUD to avoid black holes.
Other options include:

- Send packets no larger than 1280 bytes (this is always an option)
- Use PLPMTUD (for transports that do their own packetization and
  that can detect packet loss)

> > My remark about heritage is that this vintage draft is very much a
> > product of its time, and really needs modernizing, and after
> > modernizing ought to look quite different, and thus maybe we
> > should employ a procedure other than a simple replacement.

I am afraid that I have to agree with this. Classic PMTUD by itself
is today not enough, but it can be a very useful optimization to
augment other techniques.

> It's proposed for Internet Standard. That means it must replace the
> PS document and must specify the same thing, plus corrections,
> minus unused features.

All true, and my conclusion is that is it should not be promoted to IS.
I would have no problem with republishing at PS to correct the errata
and aid the eventual advance of RFC 4821 (PLPMTUD).

If this document does go forward, the words in Appendix B (Changes
Since RFC 1981) relating to RFC 4821 should be removed, since
there was no mention of RFC 4821 in RFC 1981.

Mike Heard