On 2004-02-23, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: > Here are comments on draft-moore-ipv6-optimistic-dad-04.txt. I have > one relatively-substantial comment and several editorial ones.
Thanks heaps for your careful reading ... I won't comment on _all_ the editorial stuff here, but it's appreciated and I'll make sure the changes end up in the next draft. ----- > The relatively-substantial comment is: > I don't see the strong need for the unsolicited neighbor > advertisements described in Section 3.1: [...] > In particular, I don't understand why we SHOULD send the unsolicited > NA in the latter case. Yep. They're there to bootstrap the neighbour cache of the access router in the case of a predictive handover. But you're right, they should be MAYs and I need to add some text to explain why the mobile node would bother with the extra signalling. They could also be unicast to the AR or multicast to All-Routers rather than LL broadcast, I guess. Actually, since they're not generally applicable, maybe they shouldn't be in Opti-DAD at all, and I should leave it to those doing predictive handovers to say 'send an NA as soon as you can'. (Opti-DAD clause 3.2 (iii) still says O MUST= 0 though). > Well-Distributed Address - Address suffixes used for Optimistic DAD > should be well distributed, eg: there should be an equal > probability of any given suffix occuring. This minimizes the > probability of an address collision. > > I would say this is a requirement, not a definition. I'd also like > to point out "well distributed" is not really clear in a > definition, but this is probably a minor issue (I can live with the > wording). Yep, down in 3.3 (iii) the draft requires: | | * Otherwise, or when creating a new address in the case of a | collision, a well-distributed suffix MUST be chosen. ... and I was seeking to define "well-distributed" for those who hadn't heard the term. I've noted that I need to improve that definition. A lot :-). Earlier versions of the draft spoke of 'strongly random' generators, but I changed it in order to be explicitly compatible with SEND CGA, whose hash-generated suffixes are well-distributed but not at all random. > I guess MN stands for "mobile node" (see my first comment BTW), but I > don't see why we need to use this word here. As far as I can see, > there is nothing specific to a mobile node in this context. Yep, that's another artifact of my work with MobileIP, the terminology has crawled into my ear. I'll make sure I get rid of it all. > * (modifies 5.5) If an initial suffix is not supplied, a new suffix > SHOULD be generated as per "Address Generation" below. > > What does "initial suffix" mean? RFC2462 (or its bis) doesn't use > this wording. Ah, I need to reorder some bits of 3. It's a reference to 3.3 (ii). > What does "a fixed interface identifier" mean? (e.g.) An interface > identifier derived from a hardware address like EUI-64? FYI, > the latest rfc2462bis draft contains the following sentence in Section > 5.4.5: > > If the address is a link-local address > formed from an interface identifier based on the hardware address > (e.g., EUI-64), the interface SHOULD be disabled. I'll adopt that wording. > This is not very clear to me. What exactly does "a supposedly > globally unique" mean? For instance, is an EUI-64 based IPv6 address > supposedly globally unique? Yep, that's what I meant. I'll clarify it. > 9. In Section 3.3 [...] > Does more than once mean "two times or more" (the answer should be yes > in the literal sense)? If so, why don't we need a delay after the > first failure? It was my intention that if it failed once, it should be allowed to retry immediately, but if it fails again it should fall back to only trying every RETRANS_TIMER (since multiple failures are so astronomically unlikely that it's almost certainly DoS.) > 10. In Section 3.4 > > ... In order to minimize the probability of an undetected > address collision, it would seem prudent to always configure and > check the link-local address for any given suffix as well as checking > the actual address being configured. > > I'm not really sure what "the actual address" means. Do you mean "non > link-local address"? Yeah. I should be clearer there. > 11. In Section 4.2 > > ... An NA with O=0,S=0 and no LLAO may [Note 1], > however cause the NC entry to be set to STALE, causing NUD to be > performed on the address. > > Shouldn't the "no LLAO" really be "with LLAO"? If not, what is the > purpose of this NA (O=0,S=0, no LLAO)? Yes, you are right :-) NA(O=0,S=0,no LLAO) will do nothing! I've updated that. ----- Thanks again for all this input, I will followup soon with my proposed changes. This kind of debugging is exactly why I want Optimistic DAD to be looked at in this WG! -----Nick -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
