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

[Fernando Gont <[e-mail]>]

On 01/12/2017 09:19 AM, Lorenzo Colitti wrote:
> On Thu, Jan 12, 2017 at 8:29 PM, Fernando Gont <[e-mail]
> <mailto:[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.

Traditional slaac is based on such assumption. I'm not saying we should
keep that. I'm just saying that the documents we're revising have that
assumption in place. And if we want to change such assumption, there's
probably more to do than just "generate the iid with this other
algorithm, instead". That is, that'd be a change that goes further than
what we're doing here.



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

As noted, I'm fine with thes docs xplicitly noting that they talk about
stable addresses. That seems to make you have too, so....

(talking about what with temporary MAC addresses would be a different
thing, and seems to be "out of scope" of the *current* effort on these
bis documents. If you want such work to be expanded, such that these
documents also cover temp MACs, I certainly wouldn't oppose... but that
doesn't seem the direction in which these documents are going).

P.S.: I do thing that we need advice on what to do when... stable+temp?
stable only? temp only? there are certainly use cases for each of these
combinations...

-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492