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: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
