Re: Identification

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Mon, 17 Mar 2003, David Conrad wrote:

> > 1. no usable hierarchy, hard to create a distributed database

> No.  An identifier can have hierarchy if desired.

Sure, an identifier can. But an EUI64 can't. (Note that the vendor/other
part distinction is of no use here.)

> > 2. when I replace my network card, I haven't changed my identity

> Whether you've changed 'your' identity depends on what you are calling
> the endpoint of communication.  If the endpoint is a toaster and the
> network connector dies, it is likely you'll be replacing the toaster,
> thus the identity has changed.

I was thinking more along the lines of computers. If I change a NIC, I
don't want the box to change its behavior other than that the network
connection is now better.

> > 3. It would be extremely hard to make sure each EUI64 is only used once
> >    globally

> See the comment above.

Your comment doesn't address this.

> > So we need to identify hosts rather than interfaces.

> Using your argument above, what if I move to a different host?  If
> identity is mapped to higher level constructs, I would want
> communications to move with me.

Fair enough. I think we should keep an open mind about this. However, I
see no reasonable way to accomplish it. A service moving from one host
to another is a different matter, though. I think a next generation
identifier should definately support that. (But not necessarily without
breaking sessions.)

> > Again, how are you going to look them up? Without some form of hierarchy
> > you need a centralized database. This is unworkable on a global scale.

> One (not the only) obvious solution, using your ideal identifiers: play
> the ENUM game.  If you have a EUI64 identifier, ASCII encode the
> nybbles and append a TLD, say eui64,arpa.  This name could map into a
> set of locators.

What does that buy us? That means that either you have to cooperate with
the people who bought NICs with the same high order 60 bits as you and
together run a server that provides the mapping from your identifier to
the locators you use.

Alternatively, the eui64.arpa people have to manage 2^64 delegations.

> > Sure, it's possible to repair all these problems, but why exactly were
> > we doing this in the first place again...? Hardware addresses make bad
> > identifiers. Just give me 64 bytes of NVRAM so I can burn in the
> > identifier of my choice.

> And how will you be assuring that 64 bytes is globally unique?

I won't. However, this 64 bytes should be more than enough to store a
globally or subnet unique value that the host can use at boot time, even
if it doesn't have (access to) permanent storage. This way, I can make
sure my boxes keep using the same address without having to use a
configuration server even if I swap some hardware around.

Iljitsch