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.
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.
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.
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@xxxxxxxx> 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@xxxxxxxx mailing lists by 2020-09-23. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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@xxxxxxxx
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
