Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-6man-rfc4941bis-12

I support Benjamin's DISCUSS.

The shepherd writeup says "The original authors from RFC4941 have not been reachable", but those were S. Krishnan, R. Draves, and T. Narten, who are three of the authors of this document.  I'm confused.

I support Ben Kaduk’s DISCUSS position around the need for clarity on what “statistically different” means (per Section 3).

I also strongly concur with Ben’s guidance on the construction of the RID in Section 3.3.1

** Section 3.*.  The guidance uses the language of “deprecate”.  This to me would suggest some notion of state being kept where I know I’ve used an address before and I won’t use it again.  However, that doesn’t seem right here.

** Section 3.1.  Per “it must be difficult for an outside entity …”, what’s the rough thinking on the workload for “difficult” or is there more precise language.  I ask because Section 2.1 

** Section 3.3. The subsections present two different algorithms.  Is there an MTI approach?

** Section 3.3.2.  This section suggests that use of SHA-256, but is there normative guidance on an MTI algorithm?

** Section 3.3.2.  If the hash algorithm output length exceeds the needed identifier length, how should truncations be handled?

** Editorial
-- Section 1.2.  Nit.  For consistency, s/on-link/on path/

Thank you for the work put into this document. It is an important topic and it had stimulated a lot of hot discussions on the 6MAN list ;-)

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.

Please find below a couple of non-blocking COMMENT points and nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

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.

-- Section 1 --
First sentence, should "or by static configuration" be added ?

Should a reference to DHCPv6 be added ?

-- Section 1.2 --
Should IPPIX collectors also be mentioned in the first bullet list ?

On path attacker (really close to the node though !) can also do the correlation based on the layer-2 address. Should this be added to the 2nd list ?

-- Section 2.2 --
I find the focus on DNS as 'rendez-vous' a little limiting. Why not mentioning DNS-SD or SIP proxy or ... Perhaps, prefixing the explanation with "When DNS is used" rather than using "machine would need a DNS name" (and BTW, it is also limiting to refer to a 'machine' as per container IPv6 address could be used)

-- Section 3.1 --
Point 5) the 2nd and 3rd sentences are really repeating themselves and not bringing a lot of value. Let's keep only one of the 2 or even none as the last sentence is really clear.

-- Section 3.4 --
Should the text be clear on whether optimistic DAD may be used?

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

-- Section 6 --
If only this was not 'future work' but I agree, this is not up to this document to specify such kernel API/implementation.

-- Section 9 --
Should the ingress filtering be also part of the section 4 (implications) ?

-- Section 11.2 --
I am afraid that RFC 7721 should be normative (introducing a downref though) as it is used in section 1.1 (terminology).

§3.3 (Generation of Randomized Interface Identifiers) starts by saying that the "subsections specify example algorithms".  Are these algorithms just examples?  Digging through the archive, it looks like they are: "It's one possible algorithm, and not necessarily the recommended one." [1]

However, §3.4 (Generating Temporary Addresses) says this:

   6.  New temporary addresses MUST be created by appending a randomized
       interface identifier (generated as described in Section 3.3 of
       this document) to the prefix that was received.

IOW, it makes the algorithms in §3.3 mandatory ("MUST...as described in Section 3.3").  


Please clarify the text one way or the other: by eliminating "examples" from §3.3, or removing the text in parenthesis in §3.4.


[1] https://mailarchive.ietf.org/arch/msg/ipv6/OVdexfOXgdDM4r1QZ3iQcA_oWVQ

I support Ben's DISCUSS.

I understand that this is an update of an older document resolving several important issues. However, what was advanced traffic analysis 10 years ago is not as advanced today. The security consideration discuss some of the weakness. To me it appears that there are significant risks of correlation old temporary address passed preferred life time with the new preferred temporary address. Especially if an attacker can trigger an endpoint reconnecting to a site where the previous temporary address was used and thus correlate the attempt to force reconnection combined detected use of a new temporary address to the same destination. It might even be another destination but associated with the same remote site. 

I have not putt this on discuss level, but my impression is that although beneficial the strength of its protection might be overstated in the various statements.