Re: Last Call: <draft-ietf-6man-rfc4941bis-10.txt> (Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6) to Proposed Standard

Having read this document again, I have the following concerns.

1. I think it should not include section 3.3.2. The reason is that it
needlessly suggests an algorithm that is much more complex than simply
using an existing random number generator which all nodes likely already
have.
2. I think the text mentioning shorter IID lengths (3.3.1 bullet #2) is not
useful to implementers, because all it says is that it is possible to
implement a behaviour that for in all practical cases is forbidden by RFC
4291.
3. This normative text:

   1.  Process the Prefix Information Option as defined in [RFC4862],
       adjusting the lifetimes of existing temporary addresses.  If a
       received option may extend the lifetimes of temporary addresses,
       with the overall constraint that no temporary addresses should
       ever remain "valid" or "preferred" for a time longer than
       (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME -
       DESYNC_FACTOR) respectively.

does not seem to mean anything because the second sentence lacks a verb. If
a received option may extend the lifetime of temporary addressess... then
what should the implementation do? The text doesn't say.

4. This text:

   Note that, except for the
   transient period when a temporary address is being regenerated, in
   normal operation at most one temporary address per prefix should be
   in a non-deprecated state at any given time on a given interface.

seems excessive because it immediately makes all current implementations
non-compliant. It also does not seem like a good thing to limit the number
of temporary addresses in general. If an implementation wants to create
more than one for extra privacy (e.g., to use different IPv6 addresses for
different applications), it should be free to do so. This text is also not
true if a user changes TEMP_VALID_LIFETIME to a value that is not exactly
2x TEMP_PREFERRED_LIFETIME. Users are explicitly permitted to change these
values in section 3.8.

5. Should this text:

      The TEMP_PREFERRED_LIFETIME value MUST be less than the
      TEMP_VALID_LIFETIME value.

really say "less than"? Shouldn't it say "less than or equal to"?

On Thu, Sep 10, 2020 at 7:55 AM The IESG <iesg-secretary@ietf.org> wrote:

>
> The IESG has received a request from the IPv6 Maintenance WG (6man) to
> consider the following document: - 'Temporary Address Extensions for
> Stateless Address Autoconfiguration
>    in IPv6'
>   <draft-ietf-6man-rfc4941bis-10.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@ietf.org mailing lists by 2020-09-23. Exceptionally, comments
> may
> be sent to iesg@ietf.org instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document describes an extension that causes nodes to generate
>    global scope addresses with randomized interface identifiers that
>    change over time.  Changing global scope addresses over time limits
>    the window of time during which eavesdroppers and other information
>    collectors may trivially perform address-based network activity
>    correlation when the same address is employed for multiple
>    transactions by the same node.  Additionally, it reduces the window
>    of exposure of a node via an address that becomes revealed as a
>    result of active communication.  This document obsoletes RFC4941.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc4941bis/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>