DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=
 content-type:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to; q=dns; s=
 selector1; b=UiPp/ARlrsyh0j9TrR1VRwiJexG75RyhdB6JK3cTy8YhdJdSC5m
 /iPdmGb7hy5SldmaOcRU5Z+7htRBDACRHUA5xJ7fk4IdkpQkgE2O2I6GCNlnFOaj
 2DCyF/fNNRUiUv705yQU2OQ7lNLuHpmH1JcOPAdPRcHnAKC2n8DVsQ2k=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Updated IID length text
From: otroan@employees.org
In-Reply-To: <4c052d3c-7c57-c0b3-1dd3-de764eb99c13@gmail.com>
Date: Sat, 21 Jan 2017 15:25:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F43722A-B1DF-4FAE-94CA-DFD58A0F1609@employees.org>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com>
 <m2lguffnco.wl-randy@psg.com>
 <CAKD1Yr1TrTiPRdyutobmb_77XJ7guNzLrg=H_p7qi4BfQ8V=GA@mail.gmail.com>
 <m2d1frfm6m.wl-randy@psg.com>
 <CAKD1Yr2Njjd8_Mr+6TRFF6C5pdcX4yFgpFVyEkykDuytu2B8mg@mail.gmail.com>
 <2A5073777007277764473D78@PSB>
 <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com>
 <CAN-Dau06R3iYRpYLADhvHox4C9qdsJCuxFsJapRhOQcWT4qk_g@mail.gmail.com>
 <CAO42Z2weZcoHiBzN94QAQ9WGhWR16PmMMFNg=5YLmr_dhPjjpA@mail.gmail.com>
 <fcc7f136-b5da-527e-b495-5a2d7f7a3ce8@gmail.com>
 <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com>
 <bb79ce41f2cc465dab0a7f26466be26f@XCH15-06-11.nw.nos.boeing.com>
 <ed9fe2df-0dce-0ddc-bdee-561217d089bb@gmail.com>
 <e8b4d426-55b4-bd2e-ea4f-f8e56e831d44@gmail.com>
 <54AD315E-301D-4052-9F0F-5E085C026094@employees.org>
 <6b8fad1360774881903d7a1aecb7950b@XCH15-06-11.nw.nos.boeing.com>
 <5401ebda-9f6a-fd20-6ecc-3ed5e5701957@gmail.com>
 <C52CCF93-7DB0-4E72-AC7F-7D8E4E378C82@employees.org>
 <4c052d3c-7c57-c0b3-1dd3-de764eb99c13@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/qvxWjwwgGQI-PPGS7fNKam6qDOc>
Cc: 6man WG <ipv6@ietf.org>
Precedence: list

Brian, et al,

>>>>> By changing "For all unicast addresses" to "all currently =
allocated unicast
>>>>> addresses",
>>>>>=20
>>>>> 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.
>>>>=20
>>>> 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."
>>>>=20
>>>> 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.
>>>=20
>>> 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?
>>=20
>> This isn't the right place to change the consensus that has held =
since 3513.
>=20
> I agree with that, and it isn't my intention.

Ah, excellent that wasn't clear to me.

>> 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".
>=20
> Well, I don't agree. I was just trying to confirm that the current =
rule applies
> to the whole of 2000::/3, without closing off future options.
>=20
> Actually it might have been better if this magic number had been left =
out
> of the addressing architecture and included in the SLAAC =
specification, but
> it's years too late to change that.

 - There is no magic number in 4291 (The format prefix was removed in =
2373 -> 3513.)
 - The global unicast address space is defined as everything else than =
(000, etc)
 - The 64-bit boundary applies to _all_ of the global unicast address =
space
 - SLAAC is _not_ restricted to only 2000::/3
 - IANA only assigns addresses out of 2000::/3

There was an explicit change to avoid implementations building in =
knowledge about global unicast format prefixes.
That means that today, all of the global unicast address space (the =
7/8ths) has the 64-bit boundary and of course can be used by SLAAC.

If we got the addressing model (and the 64-bit boundary) wrong:
- the safety valve is that addresses are only currently assigned from =
2000::/3.
- a new document replacing 4291 would be required
- implementations would have to be updated and a new format prefix would =
be used

Can the 64-bit boundary be changed within 2000::/3?
Possibly, but someone would have to write a draft on that.
This isn't a change that can be snuck in between working group last call =
and IETF last call.

>> 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.
>=20
> Right. So 4000::1234 is clearly a unicast address, but if not used for
> SLAAC, it doesn't need a defined IID length. That's where we have =
muddled
> things a bit between the addressing architecture and the SLAAC spec.

As currently specified, if the IETF's action was only to make  e.g. =
4000::/3 available for the IANA for assignment, it would be address =
space behaving exactly like 2000::/3.

Ole=