Re: Updated IID length text

[Brian E Carpenter <[e-mail]>]

On 20/01/2017 10:43, Peter Dordal wrote:
> On 01/19/2017 02:30 PM, Manfredi, Albert E wrote:
>> Brian, I'm completely on board with your text below. I think that this should satisfy even the objections, by avoiding any "speculation."
>>
>> Bert
>> NEW NEW
>>     IPv6 routing is based on prefixes of any valid length up to 128 [BCP198].
>>     For example, [RFC6164] standardises 127 bit prefixes on point-to-point
>>     links. However, correct use of Stateless Address Autoconfiguration
>>     (SLAAC)[RFC4862] requires all interfaces on a link to use the same length
>>     of Interface ID. Furthermore, to guarantee robust interoperability of SLAAC,
>>     a consistent length of Interface ID is desirable. For this reason, the
>>     Interface ID of all currently allocated unicast addresses, except those that
>>     start with the binary value 000, is required to be 64 bits long. Background
>>     on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].
>>
> I intend no quarrel with this wording, and I think it is unfortunate 
> this 64 debate has come up again.
> Say whatever needs to be said, and ship it.
> 
> However, the text above states that SLAAC is *the* reason for 64-bit 
> IIDs. 

No, it says it's the reason for needing a *consistent* length of IID, that's
all. As others have pointed out, we wouldn't pick e.g. 8, for other reasons
including the ones you give.

   Brian

> This is only
> partly true: 64-bit IIDs also have security and privacy implications.
> 
> Security, because an attacker can't realistically probe a site that uses 
> randomized
> 64-bit IIDs. A site that uses /120 prefixes, on the other hand, is quite 
> exposed.
> 
> Privacy, because creating temporary IIDs becomes harder and harder as 
> the number
> of bits goes down. In the IPv4 world, privacy is one reason we have NAT.
> 
> Peter Dordal
> Loyola University Chicago CS Dept
> .
>