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

[Fernando Gont <[e-mail]>]

Jinmei,

On 05/20/2016 12:04 PM, 神明達哉 wrote:
>>> 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".

FWIW, that's fine with me (including Lorenzo's suggestion of
"OPTIONAL"). The only thing I tried to note is that saying so goes
beyond the original intent of this ID: we were just improving stable
addresses, without saying any word regarding whether you should use
them, whether they are optional, or whatever.


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

We were not saying that because the current specs say/assume that they
are always needed, and "changing" that was ging one step further. That
said, I'm not opposed to this document going that step further.


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

That's orthogonal. Again, please read:
draft-gont-predictable-numeric-ids-00



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

Yes, that's the intent of this I-D (but please note my comment above
regarding the *current* specs assumming stable addresses are always there).



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

The root of this problem is reusing a link-yaer ID at layer-3. THat's
bad, and we have to recommend against that.

Brian already provided an example of IPv6/IPX traffic correlation... and
there could be other protocols reusing the MAC address which, even if
randomized, allows for correlation.

REusing IDs a different places, ifor different scopes, etc., is bad, and
is the root of all of this. Please check:
draft-gont-predictable-numeric-ids-00



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

We don't care about what you do at layer-2. Randomie as much as you
want. Just don't include layer-2 IDs in layer-3 IIDs.



> To be clear, I'm not particularly an advocator of the use of 
> randomized link-layer addresses.

I'm fine with layer-2 adddr randomization. Could even consider myself
and advocator of that (in a number of scenarios). HOwever, I'm against
reusing numeric IDs in different places, for the reasons stated above.

Thughts?

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