Hi Christian,
I'll try to keep my response brief.
Christian Vogt wrote:
[cut]
Now going to specific points...
- its initial Router Solicitation after interface (re-)
initialization (D1) [RFC 2461bis] - joining the solicited-nodes
multicast address after interface (re-) initialization (D2) [RFC
2462bis] - joining the solicited-nodes multicast address before
starting DAD triggered on a multicast RA (D3) [RFC 2462bis]
Hmm..., regarding D2, it seems we can apply the same approach as D1 in
2461bis.
As far as I see, we should either do that, or RFC 2461bis' relaxation on
D1 for MNs would be useless in most situations.
It depends on whether or not the RA can be received after RS without
joining the multicast group.
If the RA can be received, then it doesn't matter so much if the
DAD has been performed at that time, or in the second after.
Please note that RFC2461bis doesn't assume optimistic DAD, and so
may allow RS transmission in this circumstance without a source
address only. This means that the arriving packets may reduce
movement or change detection time even if 30-70ms MIPv6 RA
intervals aren't implemented.
If the RA indicates that change has occurred, then we're already in
front, for mobile hosts (and so perhaps the inclusion of the rule
for RS's is valuable).
There may be a problem if optimistic DAD is being used, and an NS/NA
exchange is required to send a unicast RA back to the solicitor.
In that case, a DNA document can talk about the tradeoffs between timers
for MLD, DAD and RS.
I don't think there's a need to change the base documents further.
[cut]
Well, here is the scenario I am thinking of: A MN uses unsolicited
RAs---neither RSs, nor link-layer triggers---to detect IP-attachment
changes. Assuming that routers send their RAs every 50ms on average,
which is what RFC 3775 allows them to do, this movement-detection
strategy works better than sending RSs. The reason is the random delay
for solicited RAs, as you say. Even if the MN would use L2 triggers, it
would still have to send an RS and await the random RA-delay in order to
find out the new prefix(es).
So, RFC 3775's frequent (unsolicited) RAs can be leveraged for movement
detection quite nicely. But when it comes to configuring the new
address, the MN ends up having to wait for D2 or D3 to send the MLD
Report. In other words, eliminating D1 turns out to be useless as long
as D2 and D3 are still there.
The main issue here is that there's an unsolicited RA which many people
may have received, and no indication of movement from L2, so the host is
unsure why the change occurred.
In this case, the host should be conservative in what it sends, and
make use of a delay in order to prevent DAD contention with other
unknown configuring hosts.
The delay D1 is not applicable here (no L2 hint), but a single delay
for DAD NS and MLD may be applicable as you say.
I guessed that the new text in 2462bis covers this nicely, though.
I'm quite happy to look at this sort of feedback making it into DNA
documents though, since host movement is in scope for DNA, and
potentially less directly applicable to IPv6 WG.
Greg
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
