Comment on draft-ietf-ipv6-optimistic-dad-06.txt

[Christian Vogt <[e-mail]>]

Hi Nick, hi everybody.

First of all, I take up the cudgels for this draft.  It defines an
optimization which is going to be a prerequisite for efficient mobility
support.  The draft is in excellent shape, too.  Overall, very good work!

One thing, though.  Section 3.3 of the draft says:

>> * (modifies 5.4)  As soon as the initial Neighbor Solicitation is
>>   sent, the Optimistic Address is configured on the interface and
>>   available for use immediately.  The address MUST be flagged as
>>   'Optimistic'.

Requiring the initial NS to be transmitted *before* the Optimistic
Address (OA) becomes operable can imply delays that defeat the purpose
of ODAD.

Specifically, if the initial NS would be the Optimistic Node's (ON)
first message on that link, the ON would have to send an MLD Report
prior to that NS [1].  The MLD Report, in turn, would have to be delayed
by up to a second.  A similar thing happens when configuration of the OA
was triggered by a multicast RA.

The MLD Report ensures that ODAD works over links with snooping
switches.  Its delay serves to avoid collisions when multiple nodes
configure simultaneously [1].

Note that these delays apply, e.g., to mobile nodes handing off to a new
link and configuring a new Mobile IPv6 care-of address by means of ODAD.

We wrote a draft with more details about this issue and also some
solutions [2].  The easiest solution seems to be to allow use of the OA
already prior to transmission of the inital NS.  There has also been a
discussion on the this mailing list [3] and the DNA mailing list [4].

Presumably the reason why the draft currently says that the first NS
must be sent prior to OA configuration is that you want to get the ODAD
process going before the OA is ready for use.  This ensures that the OA
will be in Optimistic state for a pre-defined time period only.  But
there are other ways to limit the duration of the Optimistic state.

Another reason for having to send the initial NS prior to OA
configuration might be that a collision could be revealed before
upper-layer communications make use of the OA.  But since an application
can seize the OA immediately, there is a race condition anyway.
Furthermore, the NS might get lost, which is why Optimistic DAD sends
multiple NSs.

Let me know what you think about this.

Best regards,

- Christian


[1]  IPv6 Stateless Address Autoconfiguration, RFC 2462bis, section
5.4.2, http://www.watersprings.org/pub/id/draft-ietf-ipv6-rfc2462bis-08.txt

[2]  Analysis of IPv6 Relocation Delays,
http://www.ietf.org/internet-drafts/draft-vogt-dna-relocation-01.txt

[3]  "Comment on RFCs 2461bis and 2462bis", Discussion
on the IPv6 mailing list, May 27, 2005,
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05084.html

[4]  "DAD and MLD Interaction", Discussion on the DNA
mailing list, June 13, 2005,
http://webcamserver.eng.monash.edu.au/~warchive/dna/2005-06/msg00098.html

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------