Comments in line...
At 10:48 AM 6/3/2004 +0300, Pekka Savola wrote:
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 imagine such filtering and proxying is more likely to be done on the basis of physical port or MAC address rather than source address...
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.
But it seems like there will be situations where the host has no choice but to use the unspecified address? Would text to the effect of "only use the unspecified address if no other address is available" be appropriate?
> > 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.
Doesn't seem necessary - the draft text is "Optimistic algorithm SHOULD NOT be used on manually configured addresses," which seems sufficient without telling the implementor that some method to differentiate "manually configured addresses" is required.
> 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).
RFC 3315, section 18.18, requires the use of DAD by the client: "The client SHOULD perform duplicate address detection on each of the addresses [...] it receives [...]." The DHCP server is presumed to operate correctly and not hand out duplicate addresses to its clients. DAD is more reliable than any check the DHCP server could make to detect conflict with addresses not assigned by the server.
> > 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..
Is the scenario:
* DHCP server assigns IP1 to A * A configures its interface with IP1 * Operator removes A from DHCP server configuration, returning IP1 to pool of available addresses * DHCP server assigns IP1 to B * B configures its interface with IP1 * A and B have an address conflict
If I have that right, I would consider that scenario to be Operator Error...
- Ralph
-- 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 --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
