Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

Nick Hilliard <nick@foobar.org> Thu, 23 February 2017 23:38 UTC

Return-Path: <nick@foobar.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 E2A86129C46 for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 15:38:31 -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, SPF_PASS=-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 iD5SEFB6AnaG for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 15:38:30 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82022129C55 for <ipv6@ietf.org>; Thu, 23 Feb 2017 15:38:27 -0800 (PST)
X-Envelope-To: ipv6@ietf.org
Received: from crumpet.foobar.org (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id v1NNcJrG029166 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Feb 2017 23:38:19 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.foobar.org
Message-ID: <58AF726A.3040302@foobar.org>
Date: Thu, 23 Feb 2017 23:38:18 +0000
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.10 (Macintosh/20170123)
MIME-Version: 1.0
To: james woodyatt <jhw@google.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com>
In-Reply-To: <902276E9-0521-4D4E-A42B-C45E64763896@google.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hLip5oNMxn6p-YcQJhDsLN82BCA>
Cc: 6man WG <ipv6@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, 23 Feb 2017 23:38:32 -0000

james woodyatt wrote:
> Hmm, since RFC 6164 is a Standards Track document, it’s already
> covered as a legitimate exception under the text I already proposed,
> which seemed mostly well received, except by people who seem to think
> it’s not enough to recognize standard IETF exceptions to the /64
> subnet prefix requirement.

What's your advice to vendors then?  To disable all interface netmasks
except /64 and /127?  Or to operators?  Are you really suggesting that
"thou shalt use only prescribed netmasks on your interfaces" is a viable
proposition?

This is not an idle question, btw.  Putting text into standards track
rfcs creates an expectation that the text will be built in production
code to be deployed on production networks.  What you're proposing is
straight-up Section 1 of rfc 6919.

This horse bolted 20 years ago and the shed door is long rotted.
Everyone understands that there are several situations where /64 is
mandatory, but it's terribly silly for the IETF to pretend that anyone
is going to pay the slightest attention to a requirement of this form.
They won't: vendors won't and operators won't, so we need to stop
pretending that this is a useful approach on this point.

> Some participants seem to be promising they will continue objecting
> to the promotion of RFC 4291 to full Standard until the /64 subnet
> prefix length requirement is dropped entirely. I think those
> objections should not block the advancement of this draft.

We'll need to disagree then.

Nick