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

[Fernando Gont <[e-mail]>]

Hello, Lorenzo,

Thanks so much for your feedback! In-line....

On 10/9/20 08:26, Lorenzo Colitti wrote:
> 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.

FWIW, the algorithm in Section 3.3.2 explicitly ties the MAC address to 
the resulting IID, such that a change in the MAC address (e.g. MAC 
address randomization) results in a different IID.

It's one possible algorithm, and not necessarily the recommended one.

(for instance, I did the Linux implementation of rfc4941bis, and 
employed the algorithm in Section 3.3.1, because it was simpler).

I think it can be of value, and it doesn't hurt to have it. That said, 
if there's consensus to remove it, I don't mind, either.



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

Just double-checking: Are you arguing that this:

"         We note that [RFC4291] requires that the Interface IDs of all
           unicast addresses (except those that start with the binary
           value 000) be 64 bits long.  However, the method discussed in
           this document could be employed for generating Interface IDs
           of any arbitrary length, albeit at the expense of reduced
           entropy (when employing Interface IDs smaller than 64 bits)
           and increased likelihood of collision.  The privacy
           implications of the IID length are discussed in [RFC7421]."

should be removed?



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

Good grief.

Looks like the proper fix is to s/If a received/A received/

Thoughts?



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

Not sure what you mean. This text is borrowed verbatim from Section 3.4 
of RFC4941.


> 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 document is an update to rfc4941, where addresses are created by 
the system, and not by an app (for instance, unfortunately I know of no 
API that allows that). i.e., it is not mean contrain apps from using 
multiple addresses.

If you had multiple preferred addresses -- as would be the case in the 
hypothetical scenario where you could create multiple temporary 
addresses -- you'd really need to explicitly bind the newly created 
address (or the API should automatically do that for you), since 
otherwise you'd not have control over which address get selected as a 
source address since you'd have multiple preferred addresses from the 
same prefixes (most likely all apps would use the same one, otherwise).
In which case, the "preferred" status would be rather irrelevant.


> This 
> text is also not true if a user changes TEMP_VALID_LIFETIME to a value 
> that is not exactly 2x TEMP_PREFERRED_LIFETIME. 

Note that the text above talks about addresses in *non-deprecated* state 
-- i.e., "preferred". if you change the TEMP_VALID_LIFETIME to something 
that's not 2x TEMP_PREFERRED_LIFETIME, you'll still have one preferred 
address (i.e., non-deprecated) and multiple in the deprecated state.




> 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"?

Tricky question :-) I guess that, strictly speaking, you could argue 
that it should be "less than or equal to". Although that would assume 
that you could be in a situation where your communications need to 
succeed and complete in a time T anywhere  T <= 1 seconds & T > 0 
seconds.  (e.g., right before the VL is decremented to 0, an app 
establishes a new connection, employing the soon-to-be-invalidated 
address).  --- this would only be a problem if DESYNC_FACTOR just 
happens to be 0, though.


Now, having looked back at this doc to answer your question, it would 
seem to me that there's a bit of ambiguity in this respect:

* Section 3,3, item 5 kind of implies that a new address is generated 
REGEN_ADVANCE seconds before the current one becomes deprecated.

* Section 3.4 says:
"  The node SHOULD start the address regeneration process
    REGEN_ADVANCE time units before a temporary address would actually be
    deprecated."

implying that this is recommended, but not really mandatory.


It would seem to me that the quoted text from Section 3.4 should be 
removed, since otherwise, as Section 3.3 item 7 require nodes to perform 
DAD, if you start to generate a temporary address once the previous one 
has been deprecated then (assuming the case where DESYNC_FACTOR = 0), 
while performing DAD for the new temporary address, the only preferred 
address for this prefix will probably be the *stable* address -- and 
clearly, if you are employing temporary addresses, you don't really want 
the stable address to be employed for outgoing communications.

Thoughts?


Also, a side comment:

REGEN_ADVANCE is specified as "5 seconds" (this comes from RFC4941). 
However, if DESYNC_FACTOR happens to be 0, and DupAddrDetectTransmits 
and RetransTimer are overriden, there could be "problematic" scenarios.

e.g. consider the case where DupAddrDetectTransmits is set to 5, and 
RetransTimer is set to 1000 ms: DAD would take 10 seconds to complete. 
So if the node starts regenerating a temporary address 5 seconds before 
the current preferred address is deprecated, then there will be a period 
of 5 seconds with no temporary addresses.

In that light, I wonder if one should specify REGEN_ADVANCE as something 
along the lines of:

REGEN_ADVANCE = 4 + (DupAddrDetectTransmits * RetransTimer / 1000)

With the default values, REGEN_ADVANCE would be "5", as in the current spec.

Or, alternatively, change the specification of DESYNC_FACTOR factor such 
that it is in the range of (DupAddrDetectTransmits * RetransTimer / 
1000) seconds and MAX_DESYNC_FACTOR.

Thoughts?

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