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

[Fernando Gont <[e-mail]>]

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.



>     > 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,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492