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

[Lorenzo Colitti <[e-mail]>]

On Thu, Jan 12, 2017 at 8:29 PM, Fernando Gont <[e-mail]>
wrote:

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

Yes, those documents were written when randomized MAC addresses did not yet
exist, yes. But those assumptions are not valid today; randomized MAC
addresses are not only in use, there are standards track documents that
assume their use (e.g., RFC7844). Since we're now republishing these
documents, we need to make them reflect the state of the world as it is
today, and the revised documents must not assume that MAC addresses are
unique and static.


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

Funny... my read of the discussion is that everyone wanted to support this
case and only you didn't (and maybe there was not more than one or two
voices in this direction". :-P

But seriously: regardless of which of the two interpretations above is
correct (likely neither), the fact of the matter is that the text in
default-iids says "stable" and that did not happen by chance, but through
explicit working group discussion. We have to respect that here.

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: we are republish these documents and we have to do so taking into
account things as they are today. Today, the fact of the matter today is
that MAC addresses are in use and the documents have to reflect that.