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

["Eric Vyncke (evyncke)" <[e-mail]>]

Fernando

Sorry for belated reply... See in-line for EV-2>

Enjoy your W-E ;-) (my European Friday is mostly over now...)

-éric

-----Original Message-----
From: Fernando Gont <[e-mail]>
Date: Wednesday, 21 October 2020 at 16:39
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Ole Trøan <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-6man-rfc4941bis-11: (with COMMENT)

    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?

EV-2> Not really in section 3.7. I put the two sentences in a single paragraph but they are not actually linked together. RFC 7721 should be commented briefly in the introduction or somewhere as it is important to mention the differences.


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

EV-2> of course if you do MAC randomization you should also do IPv6 temporary, I guess we agree. Perhaps, I was not clear. The MAC and IPv6 (global _and_ link-local) addresses randomizations are orthogonal but we should aim for doing both. So, it is worth stating this in the document. BTW, I am not too in favor of multiple LLA (not even sure whether it is 'allowed')

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

EV-2> I also consider 'ULA' as 'global' for this document, I was really wondering about LLA

    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