Re: Updated IID length text Fri, 20 January 2017 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA9CF129C68 for <>; Fri, 20 Jan 2017 10:55:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.335
X-Spam-Status: No, score=-1.335 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_SOFTFAIL=0.665] autolearn=no 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 7Ca9fyxN2cLc for <>; Fri, 20 Jan 2017 10:55:11 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id C255E129C63 for <>; Fri, 20 Jan 2017 10:55:11 -0800 (PST)
Received: from ([]) by with ESMTP; 20 Jan 2017 10:30:35 +0000
Received: from (localhost []) by (Postfix) with ESMTP id EC983D7899; Fri, 20 Jan 2017 02:30:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=qApS3NYIbwPRq6MCxxiOwHNFa/Q=; b=Xb/30EXIC11Pf5iL41 3zoDcsZDHSadPPiP3MvLN/6Ktf74tkaFEJq5kyhqCFbL7ii0LJ/gwpADVxMj+T3p 0SsEANgEjMbui4YFCnf/sDNtxc23+ElZjRxwFMz7zAJe4PukwYGxdN3f0qkP5WrO Fi5L+w4mNEufIuybj3TIiYQv4=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=adSMM/rzo9twqZ09ILFDhwngrax1GIC7g3wl/2sCpzCNaMPWCJw SO8bj6wCmagL4T/b5kxDvcZpIStrdRfBFIAdOZ9ozwgPmxYQ1aabx9t+3EaRDczn wqcW3V7XyFv3+QU1DL4B0ufRnIQSES13elOtoyLnOmCdUcelMpmFQMW4=
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 C0B6ED7893; Fri, 20 Jan 2017 02:29:12 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 00C7C79889D2; Fri, 20 Jan 2017 11:29:09 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Updated IID length text
In-Reply-To: <>
Date: Fri, 20 Jan 2017 11:29:09 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <2A5073777007277764473D78@PSB> <> <> <> <> <> <> <> <> <> <> <>
To: Brian E Carpenter <>
X-Mailer: Apple Mail (2.3259)
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, 20 Jan 2017 18:55:13 -0000


>>> By changing "For all unicast addresses" to "all currently allocated unicast
>>> addresses",
>>> Are you proposing to reverse the decision that was made back when RFC3513
>>> updated RFC2373?
>>> Change log:
>>> -  Revised sections 2.4 and 2.5.6
>>> to simplify and clarify how
>>>      different address types  are identified.  This was done to insure
>>>      that implementations do not build in any knowledge about global
>>>      unicast format prefixes.  Changes include:
>>>         o  Removed Format Prefix (FP) terminology
>>>         o  Revised list of address types to only include exceptions to
>>>            global unicast and a singe entry that identifies everything
>>>            else as Global Unicast.
>> Not speaking for Brian, my reaction to the RFC 3513 text would be that Brian's new text better responds to "This was done to insure that implementations do not build in any knowledge about global unicast format prefixes."
>> We have a pragmatic requirement of 64-bit IIDs, for the existing (minority) of assigned global unicast addresses. But we don't want to reverse the intention for CIDR, stated in RFC 3513. This is the "tension" with CIDR, which has existed for too many years.
> Indeed. I've taken out the explicit text that people objected to, but if another /3
> is released to IANA and the RIRs, don't we want to keep our options open?

This isn't the right place to change the consensus that has held since 3513.
Making this change would require a much deeper analysis of why the reasons outlined above don't apply anymore.
You are essentially proposing to redefine the meaning of "Global Unicast".

And please note that 4291 already has provisions for this:
Section 2.4:
   Future specifications may redefine one or more sub-ranges of the
   Global Unicast space for other purposes, but unless and until that
   happens, implementations must treat all addresses that do not start
   with any of the above-listed prefixes as Global Unicast addresses.