Subject: EUI-64s and DAD (Re: <draft-ietf-6man-rfc4291bis-08.txt>)

From: Mark Smith <[email-masked]>
Date: Sat, 1 Jul 2017 13:24:55 +1000

On 29 June 2017 at 19:35, Philip Homburg <[email-masked]> wrote:
> In your letter dated Wed, 28 Jun 2017 21:38:27 +0000 you wrote:
>> There is no
>> logical rationale for insisting that the IID be anything more than
>> locally unique. The fact that in the past, one form of IIU (i.e.
>> EUI-64) was *presumed* to be globally unique created this odd
>> concept, of multiple different uniqueness requirments for the IID.
>> It was a mere artifact of EUI-64.
>
> Historically, EUI-64 IIDs were not assumed to be globally unique.
>

I think they probably were assumed to be or globally unique enough at the time.

> When EUI-64 was introduced as IID, manufacturing defects in ethernet cards
> were common enough that any attempt to use them as world wide unique identifiers
> was assumed to fail. Note that DAD was required from early on because it was
> assumed that ethernet addresses are not always unique.
>

I think DAD was introduced because IPv6 supported more than using
EUI-64s for IIDs e.g., static addresses.

Having had a Novell IPX background, I found the use of EUI-64s in
combination with Neighbor Discovery a bit confusing for a while. The
reason is that if you use link-layer addresses for layer 3 addresses,
you don't need any form of layer 3 to layer 2 mapping protocol such as
ARP or ND - the layer 2 address is directly available in the layer 3
address, so you can literally copy the layer 3 address into the layer
2 destination address field. This is how IPX (and I think XNS work)
and why IPX doesn't have an ARP or ND equivalent.

So in the case of IPv6, the use of EUI-64s for IIDs was a convenience
rather than a requirement, and used to get a likely link unique IID to
start with.

DAD could have probably been made optional for EUI-64 derived
addresses, however I think there is still value in performing it for
all addresses. I'd much rather a device check and then refuse to work
because there is a detectable problem rather than have to troubleshoot
an intermittent and partial failure. (A link-layer DAD protocol would
be great ...)

I'm not sure DAD would be actually that useful for detecting duplicate
IIDs due to duplicate MAC addresses, as it is likely that the
duplicate MAC addresses would be causing frame transmission failures
at layer 2 before DAD gets a chance to work effectively.

Fortunately it was easy to abandon EUI-64s (per RFC8064) for IIDs
after realising their security and privacy problems because a layer 3
to layer 2 mapping discovery protocol had already been developed and
deployed.

> Beyond that, it is possible to interprate the IEEE standard such that a
> device as a whole needs a unique ethernet address but can use that address
> on multiple ports.
>
> As far as I know, Sun was one of the first companies to do this. Which caused
> all kinds of interesting issues in switches that assumed ethernet address would
> be unique.
>

"48-bit Absolute Internet and Ethernet Host Numbers" explains that
addresses were intended to be per-device rather than per interface,
and if a device had multiple interfaces, the same address was to be
used on all of them. That precludes multiple interfaces being attached
to the same segment.

Early Sun hosts were conforming with this design. I expect it evolved
into per-interface MAC addresses because when NICs were added to a
host that didn't understand Ethernet, the address came on the NIC, and
then it was simpler to burn addresses onto each individual NIC rather
than trying to have them check to see if there was already a NIC and
therefore an existing MAC address to use.

It also explains that 48 bit globally unique addresses were chosen for
operational convenience of not having to set them, even though an
Ethernet segment was limited to 1024 nodes. It might be the first time
that address size was chosen based on providing benefits beyond the
direct protocol operational requirement.

It's an excellent paper and well worth the read.

"48-bit Absolute Internet and Ethernet Host Numbers", Yogen K. Dalal,
Robert Printis, July 1981.
http://ethernethistory.typepad.com/papers/HostNumbers.pdf

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 Jul 2017 14:09:32 +1000

>> In your letter dated Wed, 28 Jun 2017 21:38:27 +0000 you wrote:

<snip>

> and why IPX doesn't have an ARP or ND equivalent.

And as a bit of Internet Protocol trivia, this is how IP originally
worked - link-layer addresses were embedded in the lower 24 bits of
the IP address, while the upper 8 bits identified the network. This
was before classes and subnets were introduced and Ethernet with its
addresses that were larger than IP addresses came along.

"ADDRESS MAPPINGS", August 1979.

https://www.rfc-editor.org/ien/ien115.txt

" An internet  address  is a 32 bit quantity,  divided  into an  8  bit
   network number and a 24 bit local address as shown below.

      +--------+--------+--------+--------+
      |    Net |      Local  Address      |
      +--------+--------+--------+--------+

   The local address  carries  information  to address  a  host  in  the
   network  identified  by the network number.  Since each network has a
   particular address format and length, the following section describes
   the mapping  between  internet local addresses and the actual address
   format used in the particular network."

RFC796 (September 1981) replaced IEN115. Address classes had been
introduced by then, however the above mappings still applied because
all of the former networks became Class A networks.

https://tools.ietf.org/rfc/rfc796.txt

ARP was then developed to support 48 bit Ethernet addresses (RFC826,
November 1982) that could not be embedded in the lower IP address
Local Address bits.

Regards,
Mark.