Re: Re: DAD question

[Ray Hunter <[e-mail]>]

I agree with you that there's a potential problem, and treating the MAC 
address as one source of a seed is a potential solution.

I think the discussion would benefit if there was a clear distinction 
made between the BIA (burned in address aka native address that is 
supposedly guaranteed to be unique by the delegated authority from the 
IEEE to the OUI) and a locally administered address (g/l bit).

DECnet IV used the latter, and hence avoiding duplicate MAC addresses 
would depend on actions of local administrators. If admins don't do 
their job correctly they will certainly not be unique, as the MAC 
address is strongly tied to the DECnet IV area and node addresses. The 
IPv6 stack would theoretically still have the former BIA available to 
the drivers to either act as a seed or to use for SLAAC.

Similar situation for Cisco HSRP, VRRP, HP HACMP etc. where there is a 
deliberate duplication of MAC addresses, and some higher layer protocol 
ensures only one is active at any one time. These machines still all 
have a native MAC and IP address, as well as the floating virtual MAC 
address and IP address.

VM's would not generally have any unique globally assigned BIA, and only 
have a locally administered MAC address generated by the local VM code, 
plus perhaps access to one or more global physical NIC adapter 
address(es) (shared with the host OS).

I agree tight bidirectional coupling of L2 address & L3 address is 
generally a bad idea (IPX over FDDI, Token Ring, + Ethernet), but it 
could have avoided many ND resource depletion problems/ potential DoS 
vectors.

I have thought of posting something on VLSM/SLAAC, where the interface 
identifier is simply an automatically assigned semi-random number like 
the Appletalk node address in LLAP. That would potentially be beneficial 
in avoiding duplicate MAC addresses, for encapsulations on systems 
without a MAC address, and also in reducing resources required for ND 
and any other processes that need to log/track non-existent nodes such 
as firewalls and security scanners (there would be no hard link to /64 
any more, and so admins would be free to assign longer prefix lengths). 
VLSM worked quite well in IPv4.

regards,
RayH

Fred Baker (fred) wrote:
> On Aug 14, 2012, at 4:41 AM, Francis Dupont wrote:
>
>> I remember (perhaps the first detected duplicate?) a very early occurrence
>> before 1995 with a DEC box using a cloned full config. Same Decnet address
>> so same MAC address so same IPv6 link-local address…
>
> Where I'm coming from in this is an expectation on my part that appears to not be shared. If duplicate MAC addresses are unusual but reasonably common (happen with some probability like .01% or whatever), there's a reasonable expectation that there would be a work-around for the issue. The work-around, I suggest, would be to have the station use a privacy address instead of a MAC-based address when a duplicate MAC address is detected.
>
> I've said before that I find the fixation an MAC addresses strange; not all devices have MAC addresses in the first place, and having built an EID from a MAC address, there is no case in which we try to derive the MAC address from it. Not all devices, believe it or not, have Ethernet or WiFi interfaces, and one with a WiFi and something else, such as your telephone, would only use the WiFi MAC address for the EID on that interface. What do I mean by "deriving the MAC from the EID"? There was a proposal in CLNS at one point (which failed for several reasons) to not need ES-IS and instead simply use the MAC address of an interface as the host identifier part of an NSAP - a router could pull it out and simply forward the datagram to the derived MAC address - and that model was used in XNS and IPX as well. But for the same reasons that OSI didn't go with that model, we have not chosen to go with that model in IPv6.
>
> So the MAC address is at most a seed for building an EID, one of many, and to my small mind if it doesn't result in a unique one, the obvious recovery action is to pick another by a different algorithm.
>
> I gather nobody agrees with me.