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 ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------