On Wed, 2 Jun 2004, Erik Nordmark wrote: > > 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. > > RFC 3590 does allow the unspecified source for MLD messages during DAD, > so the parallel for RS works quite fine.
That must be allowed (more or less) for MLD because there is no choice if there are MLD snoopers out there.. > > 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. > > What type of filtering do you have in mind? > What problem would such filtering solve? I'm mainly thinking of xDSL systems where all the customers appear to be on the same subnet (e.g. a shared IPv4 /19 prefix), but are filtered so that they are actually separate from each other (sorry, I can't describe it much better). I would also imagine that minimizing the use of the unspecified address might make SEND-like mechanisms easier, because the unspecified address does not belong to just one node, and you cannot distinguish the different nodes using the unspecified address. > > 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. > > Is this an implementation concern i.e. that the code which decides > whether to do optimistic DAD might not know whether the address was > assigned by the DHCP client or manually by an administrator? This can be fixed by the implementation, of course, by appropriate flags for adding new addresses. A question is should this feature be spelled out if it's required by oDAD. > That implementation concern is easy to handle; I even know an implementation > which sets IFF_DHCPRUNNING for the addresses that are managed by the > dhcp client. On addresses? Aren't IFF flags typically per interface, not per address? > > Are you sure DHCP servers check that no duplicates are given? > > Am I sure that the IEEE and the vendors don't hand out duplicate > blocks/adresses? No - life is full of different probabilities. :-) -- I meant whether the DHCP specs state that this kind of thing should be done, rather than us depending on the implementations to do that (some probably do, many probably don't). > > 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.. > > But such a DHCP server doesn't work well with laptops which might be > temporarily disconnected while the DAD occurs. Thus a good DHCP server would > retain state about its leases in stable storage to minimize the risk of > crashes or reconfiguration resulting in handing out duplicate > addresses. Actually at least DHCPv4 spec has a MUST that the leases must be kept in a stable storage. But I'm not sure if that this the same scenario.. -- 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 --------------------------------------------------------------------
