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
--------------------------------------------------------------------

Reply via email to