Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard Thu, 16 February 2017 09:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 897861299DC; Thu, 16 Feb 2017 01:09:29 -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 UaPik42AklZw; Thu, 16 Feb 2017 01:09:28 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id EBC1D129554; Thu, 16 Feb 2017 01:09:27 -0800 (PST)
Received: from ([]) by with ESMTP; 16 Feb 2017 09:09:27 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 887D4D788D; Thu, 16 Feb 2017 01:09:27 -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=wMh8D9NcT1rWDNlztaAbV+hEljc=; b= dxwLN40S3Tp1pRu0jU6ljlBvpSu5IaVn/FgpN9pIh7TrQx06EdHCV7G6f1uHqZD2 DKVpC3qzBfF2whIzU1gmUps/073X6G6j2i1bQek11Zx/FWYOLD9bYwvoTdEZnVfm dO0rWtxiR+1nAlj555GoAKySay5PYphPphC95GipgHQ=
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=U3hWir+uxsIVSjEnaviurnr hjlY9vXuFJKjIj1+Kh5R27BcCL46i1lbhTZnzZG6mehdRYzE3XhuwaGPj0k+/l1D TPvol/jwBIlEfnLQ5L+k3LmT71aX98JvynPlJz7NNkJg8qwOBSbJkiJzo/Ui2WdH 54LSoVV+OlubiTFRXlzQ=
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 12B2AD788B; Thu, 16 Feb 2017 01:09:27 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4C64B8BD9ACD; Thu, 16 Feb 2017 10:09:40 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_299F18D2-B57A-46AA-9616-80990B180740"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Date: Thu, 16 Feb 2017 10:09:39 +0100
In-Reply-To: <>
To: Randy Bush <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: 6man WG <>, IETF-Discussion Discussion <>,,
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: Thu, 16 Feb 2017 09:09:29 -0000

Dear Randy,

>>>> If your statement is that we only have the 64 bit boundary because of
>>>> SLAAC I believe you are wrong.
>>> cite, please.  what else actually needs it?
> that excuses it.  cite where it is actually needed to do something
> useful other than slaac.

"something useful" makes it subjective.

If you only care about technical issues, then:
SLAAC, NPT66, ILNP are the biggest one that I can think of.
Trivial to make SLAAC work with variable length prefixes of course.
As well as we don't know the consequences for implementations.
7421 seems to indicate it mostly works.

But then you have people who write code like this:

Where it clearly will not work with a longer prefix than 64.
Feel free to contribute a patch, but make sure to count the cycles spent through that code.

I expect you'll find that most implementations deal with variable prefix length reasonably well, as long as you stay away from any of the above technologies.

There are many other issues here though, do we want to keep the option of an identifier and locator split open? Do the collective we trust the collective you to not put us into the same situation we had with IPv4 were users are forced to pay per address and instead chooses to deploy NAT?

It is upon you to provide evidence and justification for a proposed change. Not the other way around. Write a draft.

Best regards,