Hi everybody,
one comment concerning RFCs 2461bis and 2462bis. The documents define
that a node must delay...
- 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]
RFC 2461bis explicitly mentions, in section 6.3.7, that the delay for
Router Solicitations (D1) can be omitted by mobile nodes. This helps to
detect movement more quickly.
However, RFC 2462bis has no equivalent rule with respect to the delay
for sending a MLD Report (D2, D3). So, when it comes to configuring a
new address through DAD, nodes must still delay joining the
solicited-nodes multicast address, which in turn delays DAD.
As a consequence, mobile nodes can get a RA quickly by avoiding (D1),
but they are still stuck with (D2) or (D3). This prevents rapid
re-attachment after a handover.
Besides, RFC 2461bis's relaxation of (D1) for mobile nodes has no
effect---at least not to the extent it should---if you still have (D2)
and (D3).
To make this story short: Even at the risk of suggesting something that
has been discussed on the IPv6 mailing list before, I propose to remove
delays (D2) and (D3) in RFC 2462bis for mobile nodes. I know there is
an issue with contention when a multicast RA triggers multiple MLD
Reports. The question is how likely that is, and how much more often
delays (D2) and (D3) would be disruptive to mobile nodes.
Bye for now,
- Christian
PS: One side note about recovery: Nodes will recover from MLD Report
collisions. But if an MLD Report fails, and two nodes simultaneously
attempt to configure the same IPv6 address at that time, this
duplication won't be detected. And nodes would not recover either.
PPS: As an alternative to relaxing (D2) and (D3), one may think about a
relaxation on the requirement to join the solicited-nodes multicast
address *prior* to DAD. After all, DAD does work if the initiator has
not joined the group, because any NAs will be sent to the all-nodes
multicast address. The only issue is a situation in which two nodes
attempt to configure the same address at the same time. The question is
how likely that is...
PPPS: As far as I see, the ODAD draft does not mention or tackle the
delay for MLD Reports either. Maybe that should be changed, too. Nick?
--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------