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

james woodyatt <jhw@google.com> Fri, 24 February 2017 00:06 UTC

Return-Path: <jhw@google.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 2EE04127601 for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 16:06:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Bl88pC-VXXIc for <ipv6@ietfa.amsl.com>; Thu, 23 Feb 2017 16:05:59 -0800 (PST)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 D6E1E1204D9 for <ipv6@ietf.org>; Thu, 23 Feb 2017 16:05:59 -0800 (PST)
Received: by mail-pg0-x22f.google.com with SMTP id b129so2916576pgc.2 for <ipv6@ietf.org>; Thu, 23 Feb 2017 16:05:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LD/ae2jKS8jkxoCHaAd/qaJcgSe6gAmvKJ9ZMT2uYKk=; b=RX1Y8YAB2I+Lts3k5g2/8zSOfbDQUuhRSYmSwortUBGZXYJOrXjqsOJ+MWibqchGTi WEhVigD36UFv72RtPVd2SB6Nkt4cDpdVXzTgBz+fIABX5IcxhgbzDBQmW4nIliz6vmWY o++Ykb8A/YQIsHJZ10Hx1xVvajrmfWHMqRV2pU/BZiGmvRjebSQjz2b/3Pp8/Ti4iAUn 2RZSwUlZ9PzVweRA/dPi6PiqxTG2yUBcf1xwDs8+p91z/7aYvYvJ0a8SCcni7Wtf6Qxt LFCXS44Vg7YB++QxRhMWU69wwdz7Pw5a4lyNhyfc0zi/pljLCRqJvK7e9KeUtB9VqhNZ 2/yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LD/ae2jKS8jkxoCHaAd/qaJcgSe6gAmvKJ9ZMT2uYKk=; b=la1RIjbFdAyAr0OAaNXTd9wc13zN5phxGocYTM3hTcOR1vRE4t0GgVbrE59VbqUypp ipGFKutaJua03oT6YjPD/K59MchTVaz0ROqfGDy0zYwCvImtsM7pTk1650Rxz28+bSaM x4yt1QAAab4QXeUXFDfUMldXwA5wSnjq1U4PZyxEuwf+eWxO1wcHkre5J4uuJiCnRmr9 UZOA9zilAKHOw9+6frSVwD27LD4IesUwlhhvchpu9VjIArXSZkZ9EmYEsjNxK/430Ws/ SrGPBEG+2UAb2rOLqr6hpZq+IXS1ON3BGruWQ6n8WElCN+fYXBHHNdIDdPEbybyPocAW 2SRQ==
X-Gm-Message-State: AMke39keTI039u5bbAzijzHGbHqrV+Bck6/wtSyJqQqIIpGfrMGojjoNh7kmxtcNbZE5FZF0
X-Received: by 10.98.138.202 with SMTP id o71mr11282117pfk.70.1487894759168; Thu, 23 Feb 2017 16:05:59 -0800 (PST)
Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id d78sm11732347pfb.43.2017.02.23.16.05.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 16:05:58 -0800 (PST)
From: james woodyatt <jhw@google.com>
Message-Id: <F7C230DE-4759-4B78-ABF2-6799F85B3C62@google.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AA711A4A-DF7D-4A84-8188-9E5768C83F50"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
Date: Thu, 23 Feb 2017 16:05:57 -0800
In-Reply-To: <58AF726A.3040302@foobar.org>
To: Nick Hilliard <nick@foobar.org>
References: <20170223134026.GI5069@gir.theapt.org> <9277BC0B-04F3-4FC1-901E-F83A8F0E02D7@google.com> <58AF6429.70809@foobar.org> <902276E9-0521-4D4E-A42B-C45E64763896@google.com> <58AF726A.3040302@foobar.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_h_1vWSPpu5qvwQJrJxQwPgR0aw>
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: Fri, 24 Feb 2017 00:06:01 -0000

On Feb 23, 2017, at 15:38, Nick Hilliard <nick@foobar.org> wrote:
> 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?

I am aware of at least one major vendor, whose devices in the field number well into the billions, devices that simply do not accept any subnet prefix other than /64. Seems to work fine for them because none of their devices are intended to be deployed in any of the standard scenarios where prefixes other than /64 are recommended by IETF.

My advice to vendors is pretty simple.

	1. Always support /64 subnets in general usage scenarios.
	2. Assume misconfiguration in general usage scenarios where subnets are not /64.
	3. Support /127 subnets if your device will be deployed under RFC 6164.
	4. Support any other standards as necessary, where limitations caused by non-/64 subnet prefixes are acceptable.

The text I proposed would allow vendors of host operating system the necessary cover to follow that advice. Dropping the requirement would mean my advice would have to change.

	1. Always prefer /64 subnets where available.
	2. Accept limitations entailed by necessity of accepting non-/64 subnets.
	3. Drop all features that depend on always receiving a /64 subnet.

Some of those features are pretty important to me, so that’s why I’m engaged in this debate.

> Are you really suggesting that "thou shalt use only prescribed netmasks on your interfaces" is a viable proposition? […]

In general usage scenarios? Yes. I am. I have a device in my pocket that does exactly that. Everyone in my family does. Those devices would not work very well if the /64 subnet requirement were dropped and operators felt free to ignore it, and adapting them to function on subnets with longer prefixes would entail making those devices less functional.


--james woodyatt <jhw@google.com <mailto:jhw@google.com>>