On Thu, Sep 10, 2020 at 10:27 PM Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
\> 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?
Yes.
> 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?
I think that might be interpreted as "A received option may extend temporary addresses... or not, if the implementer doesn't feel like it", which is not the intent. Maybe just "Process the Prefix Information Option as defined in [RFC4862], adjusting the lifetimes of existing temporary addresses, with the overall constraint that...".
> 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.
Sorry, I was misreading. Ignore this comment.
> 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.
Ok, so maybe clarify to say "The TEMP_PREFERRED_LIFETIME value must be less than the TEMP_VALID_LIFETIME value to avoid disrupting existing connections when the TEMP_PREFERRED_LIFETIME expires"?
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)
That seems better if the values are small, but if the operator does something silly and sets DupAddrDetectTransmits to 1000 and TEMP_PREFERRED_LIFETIME to 600 the algorithm will also not work. Maybe we can just cap REGEN_ADVANCE to half of TEMP_PREFERRED_LIFETIME.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
