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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
