Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Wed, 01 March 2017 10:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4F2B1298D3 for <>; Wed, 1 Mar 2017 02:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7A5feRv8bj9d for <>; Wed, 1 Mar 2017 02:58:54 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id 91B101298D0 for <>; Wed, 1 Mar 2017 02:58:54 -0800 (PST)
Received: from ([]) by with ESMTP; 01 Mar 2017 10:58:54 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 54997D788D; Wed, 1 Mar 2017 02:58:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=5OU3MpwBbQ0PAgUI1ND/iEiJiCU=; b= Em6r6kxAOOwoiSGnwVVm094XCUbB5hRloorBmEWL9uhxoazOcplV/N1oAVqhDSra y++tlCmF1hdw9b5OrfmQqa5Hq4gbEzPJf+ztyrk9ZRT/+i/+4JxMOBThk1Mg/GxJ P8LX5PHWSyRU/ZzBERyn9URM4PCMRlUdbu1sQP4ILsE=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=dQRwxxlQ29ZKMx8XE2oqG7+ NcI+8MRF3JICaZNB4CqCKkhtwE3OKogHj1vdNrG5QEVLbOebT4kJnXoJ/UJG4paC oFZZOPtFvatUjJobm/TXE0XXYEpvXK2qUxgE+DmdADw7+g8e/mGzOKCZnC2njfTJ tUrUCkiyLaL+cwNdY7/4=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id D4418D788A; Wed, 1 Mar 2017 02:58:53 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 47B9A9198679; Wed, 1 Mar 2017 11:58:52 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_2F7BC571-A93A-4BFE-BC50-4468B31C2779"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
Date: Wed, 1 Mar 2017 11:58:51 +0100
In-Reply-To: <>
To: Greg Hankins <>
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: Wed, 01 Mar 2017 10:58:56 -0000


>>> 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.
>> The word "change" is incorrect here, because the standard that was current
>> when Nokia wrote its implementation had pretty much exactly the same
>> requirement. (The reason for that is that *all* past standards have
>> contained this language except for RFC 1884, which specified /80, which
>> won't work in the real world.)
>> Could you reword your position to take into account that fact?
> Call it whatever you want, the point again is that we have customers who have
> deployed whatever addressing architecture meets their requirements, and we
> can't force them to change it.  It's their network and their address space.
> You are correct that other standards had the same requirement, which my
> current and all of my former employer's* implementations also ignored for
> the same reasons that have been mentioned.  This is a good opportunity
> for the -bis revision to reflect the state of operational deployments that
> have proven the assumptions in the original standard to be impractical.
> Is anyone aware of any implementations that comply with this requirement?

There might be some misunderstanding here.
This last call is about a document requested to be elevated from draft standard (deprecated) to Internet standard.

This document cannot be elevated to Internet standard if we added a change that would affect interoperability or require changes in implementations.

What we are arguing over is finding text that balances between ensuring that implementations do the right thing (support all prefix lengths) and allowing existing (SLAAC, NPT66, ILNP) and new mechanisms that assume the 64 bit boundary to exist / be invented. Combine that with trying to enforce the policy boundary of giving half the bits to the network and the other half of bits to the users.

Best regards,