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

[Lorenzo Colitti <[e-mail]>]

On Thu, Jan 12, 2017 at 7:25 PM, Fernando Gont <[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.


> > 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.


> > 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."

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. 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.

You're certainly entitled to your opinion that using EUI-64 with random MAC
addresses is not a good idea, but IETF documents are not based on the
opinion of one participants, they are based on rough consensus.