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

Re: optimistic dad comments

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

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

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

No, it's all implementation. Just making the document clear should be

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

Solaris diverged from BSD on this point 10+ years ago.
Instead of aliases under a single interface name the
multiple IP addresses are "named" with logical interface names such
as hme0:1. See 


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6