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

[Lorenzo Colitti <[e-mail]>]

On Thu, Sep 10, 2020 at 10:27 PM Fernando Gont <[e-mail]>
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.