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

Greg Hankins <> Wed, 01 March 2017 07:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFEDF1294BC for <>; Tue, 28 Feb 2017 23:28:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Status: No, score=-2.72 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); domainkeys=pass (384-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eFc30A3zYcCR for <>; Tue, 28 Feb 2017 23:27:59 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A059F1294A7 for <>; Tue, 28 Feb 2017 23:27:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327;; b=tyDMHOBgDh89AYMPRzHHhRQ/m1IIqKQHE/UOrbrWAy9LqkvwMOjyIjcpLo15xs91; h=X-Authentication-Warning:Date:From:To:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:X-ELNK-Trace:X-Originating-IP;
Received: from [] ( by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <>) id 1ciyfz-00048e-Ca for; Wed, 01 Mar 2017 02:27:56 -0500
Received: from ( []) by (8.14.4/8.12.11) with ESMTP id v217RoBv010663 for <>; Wed, 1 Mar 2017 02:27:51 -0500
Received: (from ghankins@localhost) by (8.14.4/8.14.4/Submit) id v217RlLS010659 for; Wed, 1 Mar 2017 02:27:47 -0500
X-Authentication-Warning: ghankins set sender to using -f
Date: Wed, 1 Mar 2017 02:27:47 -0500
From: Greg Hankins <>
To: 6man WG <>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.19 (2009-01-05)
X-ELNK-Trace: 176464c9115cf5b39c7f779228e2f6aeda0071232e20db4d8cb60d7fea6f77b525321ea1a5dd30be350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Archived-At: <>
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: Wed, 01 Mar 2017 07:28:01 -0000

On Tue, Feb 28, 2017 at 09:46:06AM -0600, David Farmer wrote:
>I think we should be saying OS MAY allow configurations other than /64, at
>least with manual configuration, and maybe DHCPv6 too.  Further, operators
>should be allowed do configure other than /64, when they know all devices
>on a network can support such a configuration.  If they don't know this for
>sure they SHOULD configure /64.
>Saying that /64 is required is a false imperative, at best it is an
>aspirational statement not an actual requirement, at it's worst it creates
>confusion and incompatibilities. The fact that RAs allow other lengths
>means this has always been a parameter.  We have defined this as a
>parameter not as a constant. Trying to redefine it as a constant, only
>confuses people.  Saying that this is a parameter that is recommended to be
>64 makes sense.  I'd even include the consequences of not using 64.   But,
>saying it's a parameter that is required to be 64, sound like it's a
>constant or at least masquerading as a constant, and only confuses people.

I strongly agree with this statement that the text should be revised to be
a recommendation instead of a strict requirement that prevents operators
from choosing an addressing scheme that best suits their needs.  The way
I read section 2.4 is that it's a /64 requirement, even though we have
other standards (/127) and clear evidence from operators that they have
a number of other mask lengths deployed.

Speaking for my employer's (Nokia) implementation of IPv6, where I am the
product manager responsible for our IPv6 feature set, we allow customers
to configure a mask length of their choice.  We can never change our
implementation to be compliant with the proposed text because of the
operational havoc it would create for our customers.  It's simply infeasible
to impose these kind of addressing restrictions.

Kind regards,

Greg Hankins <>