Re: 6man w.g. last call for <draft-ietf-6man-default-iids-11.txt>

[[e-mail]]

[...]

> I've been unwilling to propose text as I didn't even understand the
> authors' actual intent, but if it's actually that "it says what an
> implementation SHOULD do _iff_ a stable IID is to be generated", I'd
> suggest revising the above paragraph as follows:
> 
>   The recommendations in this document apply only in cases where
>   implementations otherwise would have configured a stable IPv6 IID
>   containing a link layer address.  For example, this document does
>   not change any existing recommendations concerning the use of
>   temporary addresses as specified in [RFC4941], nor do the
>   recommendations apply to cases where the link layer address is not
>   stable (e.g., it is periodically randomized) in the first place,
>   nor does it introduce any new requirements regarding when stable
>   addresses are to be configured.  Thus, the recommendations in this
>   document simply improve the security and privacy properties of
>   stable addresses.
> 
> If the intent of this document is really just that it applies iff a
> stable IID is to be generated and does not make any judgment on, e.g.,
> use of randomized link-layer addresses, this proposed text shouldn't
> be a problem for anyone. (for some, it may seem to say the obvious and
> therefore redundant, but given that whether randomized LL address is
> good or bad was so controversial here, I think it's helpful to
> explicitly clarify that).  But I was not sure if it's really
> acceptable, especially for the authors, by seeing opinions like
> the "extremely bad" comment.

I think we have an assumption embedded in most of our documents that a stable IID is generated on all interfaces.
I don't think this document is the place to to clarify that there might be interfaces with only short-lived IIDs.

This document tries to improve the security and privacy of the default IID generation mechanism. I think it is clear on that. It's in the title, it is in the abstract. I'm not sure how much clearer it is possible to make it.

The other consequence of this document is that it forces changes in implementations that don't necessarily benefit from the privacy improvements. Public servers, router interfaces and so on. Is a consequence of updating 2464 that I now have to go and retrofit 7217 style IID generation in lots of code? I'm not sure I want to accept the collateral damage.

> To be clear, I'm not particularly an advocator of the use of
> randomized link-layer addresses.  But I've seen this as one central
> point concerning how to move forward for this document, so I believe
> we should be at least clear on this in the document text.

With regards to random MAC addresses, I see the arguments that we in general shouldn't couple the L3 address with the L2 address.
In that aspect randomized MAC should not have any implication on this document.
On the other hand I do see how it would make for a very easy implementation change to do random MACs (which you probably have to do on certain devices anyway), and keep the current IID generation mechanism.

I have to admit that I'm unsure of what the right thing to do is. I'm uncomfortable with removing the existing mechanism from all the IPv6 over foo documents. I'm not convinced that we are in a position to make a recommendation for all scenarios and all devices at this point.Î

cheers,
Ole