Replying to both in one go.. On Wed, 2 Jun 2004, Nick 'Sharkey' Moore wrote: > On 2004-06-01, Erik Nordmark wrote: > > [Pekka Savola wrote:] > > > > > > 1) The draft specifies that instead of using a tentative address as the > > > source address for RS, another address or the unspecified address should be > > > used instead. To me, using the unspecified address would seem shortsighted, > > > so I'd like to disallow its use in this context. (This might cause a > > > problem, though, because I don't think the nodes typically have an another > > > address they can use...) > > > > But RFC 2461 explicitly allows sending RS with an unspecified source. > > Is there a bug in RFC 2461 in this area? > > I don't think it's a bug ... > > "A router MAY choose to unicast the response directly to > the soliciting host's address (if the solicitation's > source address is not the unspecified address), but the > usual case is to multicast the response to the all-nodes > group" [RFC2461 6.2.6] > > ... it's a feature, asking the router "please be sure to > broadcast the response back to me since I don't have an address > I'm sure of yet".
My concern with using the unspecified address comes from the experience we had in MAGMA where we had to specify which source address to use in the MLDv1 packets. Further, some might want to perform some kind of filtering based on the link-local source address, and using the unspecified address makes this impossible. That's why I'd prefer to encourage using other means (if possible) than sending RS's.. You already say: The ON will immediately send out a Neighbour Solicitation to determine if its new address is already in use, and a Neighbour Advertisement (with the Override flag cleared) for the address. This NA allows communication with neighbours to begin immediately. I read this so that if you just sent an NS and an NA, you could immediately afterwards send the RS from the "optimistic" address? Maybe this was not clear enough.. > > > What might be useful is specifying with which kind of addresses > > > oDAD should be assumed: [...] Manual addresses or DHCPv6 in > > > particular should be disallowed. > > > > [...] > > But is also isn't clear to me that the probability, even in the > > manual case, is high enough to warrant pessimistic mode. > > I (personally) tend to agree, but I (editorially) am trying to steer > a course between paranoia and recklessness :-) Sure, but the main concerns about the need for DAD have come from the manually configured addresses, so with them, we might say for example that the optimistic mode SHOULD NOT be used, and if it is still enabled by default, there MUST be a way to disable it (or whatever). So, if vendors or operators would believe optimistic behaviour for everything is a good one, they could still go for it, but we might want to stick to the original DAD plan for those addresses where the collision probability is not (practically) zero. I don't feel strongly about this either way, but I think this was an important argument from those people who were resisting DAD optimizations in the first place.. [Erik:] > But why do we think this is the case for DHCP assigned ones? > The DHCP server will check that the address isn't already in its > list of leases before handing it out, so a collision at DAD time would > be very low probability. I mentioned only because DHCP assigned addresses are probably indistinguishable (depends on where they sit) from the manual addresses, but depending on the deployment, I guess DHCP could be giving the EUI64 addresses as well. Are you sure DHCP servers check that no duplicates are given? Another potential scenario might be that the DHCP server is reconfigured (one node removed, another added with the same address), but the removed node still keeps its address and the new node will be on the same link.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
