Le 10/09/2020 à 21:21, Fernando Gont a écrit :
On 10/9/20 11:26, Lorenzo Colitti wrote:
On Thu, Sep 10, 2020 at 10:27 PM Fernando Gont <fgont@xxxxxxxxxxxxxxx
<mailto: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.
Point taken. I'll wait for others to weigh in
It is true that the text repeats a requirement from elsewhere, and that
shorter text can be obtained by elimination, and it is easier.
If one wants to keep the text, then it should be improved.
At a point the text says that entropy is reduced if IID len is shorter
than 64; the text should also say that the entropy augmented if the IID
len is longer.
Alex
-- me, I don't mind
removing the text (at the end of the day, the text repeats a requirement
from elswhere, plus notes that this mechanism can be uses for non-64
prefixes (which should be obvious), plus notes the possible consequences
of that, which are probably also rather obvious).
> 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...".
Good. I'd just s/defined/specified/
> 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"?
How about:
"The TEMP_PREFERRED_LIFETIME value MUST be less than the
TEMP_VALID_LIFETIME value to avoid the pathological case where an
address is employed for new communications, but becomes invalid in less
than 1 second, disrupting those communications."
(i.e., disrupting long-lived existing connections that simply span past
the lifetime of the temp address is okay and somehow expected behavior)
(After checking RFC4861, I realize that this could also happen for
regular stable addresses, as RFC4861 allows for PL >= VL -- and in a
way, if you do some really dumb config... well.. that's what you get).
-- Although all rfc4941 implementations I know of perform some basic
sanity checks on the temp_pl and temp_vl.
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.
After crafting, reviewing, and discarding :-) text a few times, it would
seem to me that such case is somehow prevented, since the spec for
DESYNC_FACTOR essentially says that:
DESYNC_FACTOR < TEMP_PREFERRED_LIFETIME - REGEN_ADVANCE
since DESYNC_FACTOR is anywhere between 0 and ten minutes, we know that,
at the very least, TEMP_PREFERRED_LIFETIME will always be larger than or
equal to REGEN_ADVANCE. So in the "worst" case, where they are equal, as
soon as you configure a new temporary address (i.e. it becomes
preferred) you would start the process of creating a new one (i.e.,
producing a tentative one, and doing DAD).
That said, the text I had proposed accommodated multiple DAD
retransmits, but failed to accommodate the possibility where DAD fails,
and you need to retry the process.
In that case, it would seem that the best way would be to tweak the text
as:
---- cut here ----
TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be
able to override the default value.
Note:
The TEMP_PREFERRED_LIFETIME value MUST be less than the
TEMP_VALID_LIFETIME value to avoid the pathological case where an
address is employed for new communications, but becomes invalid in
less than 1 second, disrupting those communications.
REGEN_ADVANCE -- 2 + (TEMP_IDGEN_RETRIES * DupAddrDetectTransmits *
RetransTimer / 1000)
Notes:
This parameter is specified as a function of other protocol
parameters, to account for the time possibly spent in Duplicate
Address Detection (DAD) in the worst-case scenario of
TEMP_IDGEN_RETRIES. This prevents the pathological case
where the generation of a new temporary address is not started
with enough anticipation such that a new preferred address is
generated before the currently-preferred temporary address becomes
deprecated.
DupAddrDetectTransmits and RetransTimer are specified in
[RFC4861].
---- cut here ----
Please do check if I got it right (fwiw, for the default values, the
above expression shields 5)
Thanks!
Regards,
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
