Re: Éric Vyncke's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

[Fernando Gont <[e-mail]>]

Bonjour, Eric,

On 21/10/20 10:57, Eric Vyncke (evyncke) wrote:
> Buenos dias Fernando,
> 
> As you know, all my COMMENT points were non-blocking; therefore, I
> really appreciate your replies and your proposed changes (I agree
> with all of them + one preference for an alternative text) => this
> should improve the document quality!

I'm all for improvements! -- thanks for your suggestions!


[....]
> On 20/10/20 10:49, Éric Vyncke via Datatracker wrote: [....]
> 
>> I also appreciate the new section 3.7 where an admin can disable
>> the mechanism. Is there a reason why this document does not briefly
>> compare its addresses with RFC 7217 (stable address) ? It could be
>> helpful for the reader.
> 
> Such topic has been discussed at length in RFC7721.  That's why
> we've referenced such document instead of trying to rehash the
> discussion.
> 
> EV> I agree that this document should not spend too much time in the
> comparison; but, when doing my IESG review I failed to see *where* in
> the document is the reference to this discussion in RFC 7721.

Do you mean we might want to reference RFC7721 from Section 3.7?




> ...%<....%<......
>> 
>> Should link-local address generation also be considered here ?
>> While the text is clear about 'global', there is no clear
>> indication that this document does not apply to link-local
>> addresses.
> 
> The idea of this document was to revise RFC4941, addressing
> shortcomings in said RFC. That's why the document remains the same
> wrt link-locals.
> 
> That said, link-locals are a different problem space. e.g., there's
> not much of a point in doing temporary addresses for link-locals if
> you don't randomize link-layer addresses. For some technologies,
> randomizing link layer addresses might force a network disconnect,
> etc.
> 
> EV> I still believe that it is worth mentioning even if only to avoid
> the EUI-64 based on MAC address for link-local (done in most OS AFAIK
> :-) ) but also keeping the same LLA when randomizing the MAC address
> is also kind of defeating the layer-2 privacy. 

The thing here is that it would be RFC8064/RFC7217 (rather than RFC4941) 
affecting this case. i.e., if you do MAC address randomization, , you 
probably want to make sure that your stable addresses are ... *not* 
stable :-).   Put another way: even if this document (rfc4941bis) was 
suggesting the generation of temporary addresses for link-local 
addresses, the potential problem in this respect is that the node might 
be doing RFC7217 for link-locals, in which case you'd have both stable 
link-locals (which wouldn't change, and would defeat MAC address 
randomization), plus the temporary link-local addresses.


> We could talk for ever
> on this topic of course but my I kindly suggest to change the title
> of this document into " Temporary *Global* Address Extensions" (the
> abstract is clear about the coverage) and adding a few words on the
> importance of LLA ?

To make things more complicated :-), this document does accommodate 
temporary addresses for ULAs (it even mentions them explicitly in one 
example), which are global (globally unique), but not globally-reachable.

Thoughts?




> ...%<....%<.....
> 
>> -- Section 1.2 -- Should IPPIX collectors also be mentioned in the
>> first bullet list ?
> 
> WOuldn't that be somewhat included in bullet #1?
> 
> EV> up to you as authors, but for me the collector (== receive of
> IPFIX records) is not the monitor (== the node in bullet #1)

My bad! -- Will do.




>> -- Section 3.6 -- Last paragraph "when an interface connects to a
>> new (different) link, a new set of temporary addresses MUST be
>> generated immediately" seems to imply more than 1 temporary address
>> with the use of 'set' and the plural form. Unsure whether it is the
>> right behavior (esp if no RA-PIO are received yet).
> 
> How about
[...]
> 
> Xor, one might be more specific as in:
> 
> NEW: Finally, when an interface connects to a new (different) link, 
> existing temporary addresses for that interface MUST be eliminated,
> and new temporary addresses MUST be generated immediately for use on
> the new link, according to the algorithm in Section 3.4. If a device
> moves from one link to another, this will ensure that the device uses
> different randomized interface identifiers for the temporary
> addresses associated with the two links, making it more difficult to
> correlate addresses from the two different links as being from the
> same node.
> 
> 
> Thoughts?
> 
> EV> I prefer the 2nd alternative but the 1st one is also good IMHO

Will apply the second one, then!

Thanks!

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