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
>> 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.
>
> 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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
