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

james woodyatt <> Fri, 24 February 2017 00:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EE04127601 for <>; Thu, 23 Feb 2017 16:06:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bl88pC-VXXIc for <>; Thu, 23 Feb 2017 16:05:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6E1E1204D9 for <>; Thu, 23 Feb 2017 16:05:59 -0800 (PST)
Received: by with SMTP id b129so2916576pgc.2 for <>; Thu, 23 Feb 2017 16:05:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id o71mr11282117pfk.70.1487894759168; Thu, 23 Feb 2017 16:05:59 -0800 (PST)
Received: from ([]) by with ESMTPSA id d78sm11732347pfb.43.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Feb 2017 16:05:58 -0800 (PST)
From: james woodyatt <>
Message-Id: <>
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: <>
To: Nick Hilliard <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: 6man WG <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Feb 2017 00:06:01 -0000

On Feb 23, 2017, at 15:38, Nick Hilliard <> 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 < <>>