With respect to the simple solution, I think there are some
basic
requirements that it needs to meet. These are summarized in
RFC 4436
Section 1.1 (paraphrased to fit DNAv6):
o DNAv6 is a performance optimization. Its purpose
is to speed
up a process that may require as much as a few
hundred
milliseconds (DHCPv6), as well as to reduce multi-
second conflict detection delays when a host
changes networks.
o As a performance optimization, it must not
sacrifice
correctness. In other words, false positives are
not
acceptable. DNAv6 must not conclude that a host
has returned
to a previously visited link where it has an
operable IP
address if this is not in fact the case.
o As a performance optimization, false negatives are
acceptable.
It is not an absolute requirement that this
optimization
correctly recognize a previously visited link in
all possible
cases. This is acceptable as long as the
host still operates correctly as it did without
DNAv6, just
without the performance benefit.
o As a performance optimization, where DNAv6 fails to
provide a
benefit, it should add little or no delay compared
to today's
RS/RA and DHCPv6 processing. In practice, this
implies that this
processing needs to proceed in parallel. Waiting
for DNAv6 to
fail before beginning RS/RA and DHCPv6 processing
can greatly
increase
total processing time, the opposite of the desired
effect.
o Trials are inexpensive. Assuming that DNAv6
performs its
checks using small unicast packets (NS/ND), the
cost of an unsuccessful attempt is small, whereas
the cost of a
missed opportunity (having the right address
available as a
candidate and choosing not to try it for some
reason) is large.
As a result, the best strategy is often to try all
available
candidate configurations, rather than try to
determine which
candidates, if any, may be correct for this link,
based on
heuristics or hints. For a heuristic to offer the
prospect of
being a potentially useful way to eliminate
inappropriate
configurations from the candidate list, that
heuristic has to
(a) be fast and inexpensive to compute, as compared
to sending
a small unicast packet, and (b) have high
probability of not
falsely eliminating a candidate configuration that
could be
found to be the correct one.
Today, I do not believe that either the "simple
solution" or the "advanced
solution" meet these requirements.
> Thanks for the comments. I agree with you as well. I
will be submitting
>a new version of the simple DNA that addresses few of
the concerns raised
>with version -00.
|
