[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: optimistic dad comments

Replying to both Erik and Ralph..

On Thu, 3 Jun 2004, Erik Nordmark wrote:
> > 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).
> As Ralph said, isn't this done by filtering on the source MAC address
> (with only one MAC address being allowed by each subscriber).
> That is at least how I think cable modem setups work.

No, each subscriber is allowed to have multiple MAC addresses (but 
each of those MAC addresses get their own IP address and are isolated 
from the others) -- at least for xDSL.

But you're still correct, using MAC address or a port is more reliable 
than trying to filter based on the 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?

Yes, this is good enough for me.  The text doesn't quite say that at 
the moment.
> > 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.
> Using the unspecified source address to cause a state or behavioral
> change in a neighboring node would be problematic in the place where
> SEND is used. But the RS case doesn't do this. It is just "send me some
> public information". (And the MLD report isn't either; the multicast
> router ignores it, and the MLD snooping switches actually act on
> the port/MAC address from which the packet came.)

True -- this should not be a problem for SEND because state is not 

[snip implementation-specific issues]

> 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.

True -- as long as the DHCP server knows that the addresses it's 
handing out would be duplicates, see below:

> 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...

Precisely this scenario.  Manually misconfiguring an address is also
an operator error, which DAD is intended to protect from.  Because
here the DHCP server cannot know that it should not hand out out IP1
quite yet, it might make sense for the clients to do DAD on the

Doing DAD also protects from misbehaving/buggy DHCP server
implementations (if any).

We probably agree that the probability of collision with DHCP-assigned
addresses is significantly higher than with SLAAC'ed addresses, but
somewhat lower than with manually configured addresses.  Whether this
warrants a pessimistic DAD mode is open to the debate, and I don't
have too strong opinions either way.

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