Re: <draft-ietf-6man-default-iids> update to rfc2464bis

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

On 13/01/2017 00:29, Fernando Gont wrote:
> On 01/12/2017 08:08 AM, Lorenzo Colitti wrote:
>> On Thu, Jan 12, 2017 at 7:25 PM, Fernando Gont <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>     > I don't see why we should forbid this. It's a legitimate implementation
>>     > choice, and has excellent privacy properties :-)
>>
>>     I'm not saying we should forbid this -- actually, there are scenarios
>>     where it should probably be the recommended approach.
>>
>>     But that's not the operating model we have right now -- that's the
>>     point.
>>
>> The point I am making is that according to current and
>> about-to-be-published specs, a node is free to create addresses that
>> change over time, since nothing forbids it.
> 
> I guess you're allowed. That does change the operating assumptions, and
> I wouldn't be surprised to see breakage.

It will break on sites that choose a managed addressing policy (as
Tim told us they do at CERN). I wonder what Android users at CERN do?

   Brian

> 
> 
> 
>>     > Sure. If you can find rough consensus to say all other methods of
>>     > generating IIDs are bad and should not be used, the IETF will publish a
>>     > document saying that. My bet is that you won't.
>>
>>     I'm not saying that. For instance, if you want temp addresses, and you
>>     decide to send the 64 bits with a PRNG of your choice, that's fine. If
>>     your goal is privacy and you decide to waste 18 bits 'cause you want to
>>     stick to modified-eui64, you're doing a lousy job.
>>
>> Good, then we agree that a node is free to create addresses that change
>> over time using schemes that are not described in RFC 7217, RFC 4941, or
>> any other document.
> 
> Yes, you're "free" to do your own proprietary thing, which does not
> follow any IETF stds, I guess.
> 
> 
> 
>>     > To get back to the original point: in the current state of the documents
>>     > that we have published or are about to publish (e.g., the default-iids
>>     > draft), as reflecting the consensus call sin th it's not true that
>>     > modified EUI-64 is not recommended. It's only not recommended if you use
>>     > stable link-layer addresses.
>>     >
>>     > Bob, Ole, Suresh: can we also amend or remove this text in 4291bis
>>     > before we publish it? I think it's an oversight because there was clear
>>     > consensus in 6man (Fernando being in the rough) that it was OK to use
>>     > modified EUI-64 with non-stable MAC addresses:
>>     >
>>     >    Earlier versions of this document described a method of forming
>>     >    interface identifiers derived from IEEE MAC-layer addresses call
>>     >    Modified EUI-64 format.  These are described in Appendix A and are no
>>     >    longer recommended.
>>
>>     All these documents are about generating stable addresses, not temporary
>>     addresses. So I'm not sure why the text should be removed. The text in
>>     all this documents ae about stable addresses. IETF-wise, the only doc
>>     that is about temporary addresses is RFC4941. Hence the text seems
>>     correct to me.
>>
>>
>> If instead of removing that text we can clarify that it only applies to
>> stable addresses, that works for me. Suggestion: change "These are
>> described in Appendix A and are no longer recommended." to ""These are
>> described in Appendix A and are no longer recommended for stable addresses."
> 
> Fine. Isn't the assumption in all these RFCs that the addresses are
> stable, and that the MAC addresses are unique?
> 
> 
> 
>> The reason the text needs to be changed is because during the discussion
>> of default-iids there was substantial discussion of the use case of
>> using EUI-64 with randomized MAC addresses. There was consensus that
>> this is a use case we want to support, and as a result, the working
>> group concluded that we should change every occurrence of the phrase
>> "based on a link-layer address" to "based on a stable link-layer
>> address" in the default-iids draft.
> 
> My read of the discussion is that you didn't want default-iids to ban
> this case (and maybe there was not more than one or two voices in this
> direction), and we simply decided to have default-iids fous on stable
> addresses to be able to do progress on something. Claiming that doing
> temp adderesses by doing MOdified-EUI64 is streching that outcome quite
> a bit, IMO.
> 
> 
> 
>> We should make the same distinction
>> in 4291bis and 2464bis: EUI-64 is not recommended for use with stable
>> link-layer addresses, but it can be used with non-stable link-layer
>> addresses.
> 
> All this documents talk about stable addresses. Discussing temp
> addresses in them is actually talking about stuff that simply wasn't
> there, with operating conditions different from those assummed so far.
> 
> Again, I sympathize with temp only in scenarios where they make sense.
> But things like that don't seem within what has been specified so far
> (i.e., there's work to be done, including analyzing what might break).
> 
> Thanks,
>