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

Pierre Pfister <> Fri, 24 February 2017 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBD2712949E for <>; Fri, 24 Feb 2017 10:38:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jCLDQEzT9cSr for <>; Fri, 24 Feb 2017 10:38:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF11D12949B for <>; Fri, 24 Feb 2017 10:38:43 -0800 (PST)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 0F716564B40; Fri, 24 Feb 2017 19:38:39 +0100 (CET)
From: Pierre Pfister <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1A75CEF9-FCCF-4800-AFEE-8322735A61F9"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
Date: Fri, 24 Feb 2017 19:38:38 +0100
In-Reply-To: <>
To: james woodyatt <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
X-AV-Checked: ClamAV using ClamSMTP at (Fri Feb 24 19:38:40 2017 +0100 (CET))
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 18:39:54 -0000

> Le 24 févr. 2017 à 19:11, james woodyatt <> a écrit :
> On Feb 24, 2017, at 03:11, Nick Hilliard < <>> wrote:
>> Let me be more specific then: are you proposing that vendors write code
>> to allow or disallow interface subnets which aren't /64 (or /127)? This
>> is a binary choice; a vendor needs to choose one way or another.
> I don’t know how I can be more clear about this: I insist that general purpose host operating system developers should be expressly permitted to write code that declines to accept subnet prefixes of any length other than /64 on the grounds that these are not used in general IPv6 networking and the successor to RFC 4291 continues to say so.

This has nothing to do with RFC4291 and does not require RFC4291 to say anything specific about that.
Support of SLAAC is already mandatory.
Support of stateful DHCP is not mandatory.
Devices that are not supposed to be configured manually can perfectly support SLAAC only over ethernet, and fail in all cases where SLAAC cannot be used. 
This does not need to be specifically allowed by RFC4291.

RFC4291 is applicable to *all* IPv6 devices, not a subset of them. So let's not put in there things that are specific to some use-cases and would be just a pain in other deployments.
There is plenty of literature about the use of /64 in home, enterprise or other specific networks already.


> I know there are operating systems with billions of units in the field today that do exactly this because RFC 4291 and its predecessors have for years given them clear license to do so, and I don’t want to see the publication of I-D.ietf-6man-rfc4291bis as RFC come to remove this license as a side effect of promoting IPv6 to full Standard category.
> You want to remove that license? I suppose we can continue discussing that, but I think you should try to do it in a separate draft once IPv6 is officially promoted.
> --james woodyatt < <>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> Administrative Requests:
> --------------------------------------------------------------------