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

[神明達哉 <[e-mail]>]

At Fri, 20 May 2016 09:04:09 +0200,
[e-mail] wrote:

> > > Let's all always keep in mind that the current text of the draft says that
> > > on every network, hosts SHOULD configure an IPv6 address that never changes
> > > until the end of time. I think that recommendation is irresponsible.
> >
> > Thus, I'm continuing to run my laptop with only an RFC4941 address for a few
> > days to see whether it has any negative impact at all. So far, so good.
> >
> > Excellent! Now, if we can only make this draft stop saying that that you SHOULD NOT do that...  :-)
>
> Everything has to be read in context. My reading of this document is that it says what an implementation SHOULD do _iff_ a stable IID is to be generated. It says nothing about what to do if a stable IID is not required.
>
> I find the current text quite clear on that, but clearly you don't.

It's not clear to me either.  I commented on this exact point in my
first response to the last call.  Its followup discussion actually
confused me further:
http://www.ietf.org/mail-archive/web/ipv6/current/msg24391.html

In this discussion, I suggested "clarifying that this recommendation
is only for environments where address stability is needed".  The
response to that part of comment refers to a paragraph of the
introduction section:

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link layer address.  That is, this document does not
   change any existing recommendations concerning the use of temporary
   addresses as specified in [RFC4941], 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.

At least to me, this is not the same as "this recommendation is only
for environments where address stability is needed".  So I tried to
understand the actual intent with followup questions, but the
subsequent discussions only introduced more confusion for me (because
of discussions on other points like whether using randomized
link-layer address is "extremely bad").

> Would it help with some sort of clearer applicability statement in
> this document? Can you propose text?

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.

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.

--
JINMEI, Tatuya