Subject: [rrg] Hosts generating globally unique EUI-64 addresses from their hardware ID?

From: Robin Whittle <[email-masked]>
Date: Thu, 08 Jul 2010 15:22:09 +1000

In (msg07061 - "Re: [rrg] ILNPv6 Mobility problem") Steven Blake wrote:

> Name one modern device that doesn't have a unique hardware ID that
> could be used to form a global-scope EUI-64?

What really matters is whether this is a reasonable basis for the future.

Since not every host has or will have a MAC address, your proposed
algorithm would need to work from a variety of different types of
hardware ID.

How then to have an algorithm which partitions the namespace of the
64 bit result so that there's no way a host with MAC address XYZ will
create the same 64 bit Identifier as another host which doesn't have
a MAC address, but which has, for instance, a cell-phone identity
number, or perhaps a PSTN phone number, which your algorithm
processes to the same result as for the XYZ MAC address?

I guess it could be done, but you would need to divvy up the 2^64
member namespace carefully, and allow for all future types of
hardware ID which might be needed.

I think a better approach would be some kind of hierarchical system
of assigning Identifier space to organizations, just like IP address
space today.  Then each host can be configured to use a given
Identifier, or to obtain one from which ever organisation it uses for
the the purpose of gaining an Identifier.

But I am opposed to Identifiers anyway - so I won't argue the point.
 I just want to break it out of the previous thread.

To see why I oppose Locator Identifier Separation:

  "Overloading" of Loc & ID functions is good for hosts and should be
  maintained
  http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html

and:

    http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html

for my goals and attempt at writing a Recommendation.  No-one has yet
responded to these.

  - Robin

---

From: Tony Li <[email-masked]>
Date: Wed, 7 Jul 2010 22:36:58 -0700

> What really matters is whether this is a reasonable basis for the future.

This is reasonable now and for the foreseeable future.  

<chair>
You're just being silly.  Please cut it out.
</chair>

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Thu, 8 Jul 2010 14:49:57 +0900

>  http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html

There's one more supportive vote for this from me, if it is any worth
counting, though perhaps not exactly the same resultant structure. So,
you're not alone.

-- 
DY

---

From: Robin Whittle <[email-masked]>
Date: Thu, 08 Jul 2010 16:18:08 +1000

Hi Tony,

> You're just being silly.  Please cut it out.

I have no idea why you think my message was silly.

While I don't much care whether it is possible or not to do as Steve
suggested - now and presumably in the future have each IPv6 node
generate a unique 64 bit identifier based solely on identifying
numbers in its own hardware - I was trying to discuss what he wrote,
in a separate thread.

Do you think it is or would be practical to do this?  If so, how?

Or do you believe that this is irrelevant to the RRG?

  - Robin

---

From: Steven Blake <[email-masked]>
Date: Fri, 09 Jul 2010 01:44:17 -0400

> algorithm would need to work from a variety of different types of

All IEEE technologies have native EUI-48s (mappable to modified EUI-64)
or EUI-64s, to my knowledge.  That is not going to change in my
lifetime.  Home Plug and G.hn also appear to have MAC addresses, as does
Bluetooth.

Cellular has IMEI (3GPP technologies) or MEID (3GPP2 technologies).
Both are uniquely mappable to EUI-64 (see
http://tools.ietf.org/html/draft-dupont-ipv6-imei-10).  Not sure why
this didn't progress to RFC, but possibly because 3GPP and 3GPP2 have
put a mapping in their own specs.

ATM AALs do not have MAC addresses (boo hoo).  SONET/SDH/OTN does not
have a MAC address, but most SONET ports are not mobile.  You can be
sure that any box with a SONET port has a management Ethernet port.

Am I missing something?

It is IMHO reasonable to suppose that anyone designing new link layers
is going to try to accommodate IPv6 SLAAC.

Regards,

// Steve

---

From: Robin Whittle <[email-masked]>
Date: Fri, 09 Jul 2010 16:58:47 +1000

Hi Steven,

You probably know more than I do about various types of devices and
their various forms of device identifier being mapped to a unique
EUI-64 value.  So you may well be right about most hosts today being
able to synthesize a globally unique value based on something in
their hardware which uniquely identifies the host.

However . . .

  1 - I think it would be impossible to argue that this would be
      true of every conceivable device which might become an IPv6
      host in the future - or that this should be the case.

  2 - Even if every host could do this, there could be debate about
      how much we want to rely on the uniqueness of the EUI-64 value
      - given possible clashes with these device identifiers.

  3 - Roland Bless wrote (Re: [rrg] ILNPv6 Mobility problem):

       http://www.ietf.org/mail-archive/web/rrg/current/msg07078.html

        >> Name one modern device that doesn't have a unique hardware
        >> ID that could be used to form a global-scope EUI-64?
        >
        > Hmm, when considering the increasing use of virtual hosts,
        > we may get in trouble here: virtual hosts probably don't
        > have a unique hardware ID and usually generate a MAC
        > address (or multiple ones in case of several virtual
        > interfaces) at installation time.

     So I think it is quite feasible to argue that in the future
     there will be some or many widely used classes of host which do
     not have specific hardware identifiers - for instance because
     they are not based on a unique piece of hardware at all.

I may not discuss this further, because if I supported ILNP or any
other CEE (Locator / Identifier Separation) architecture, I would
think it is best to have hierarchical assignment of Identifiers which
have nothing to do with hardware or any other physical-host specific
mechanism.

  - Robin