Subject: Identification

From: "Bound, Jim" <[email-masked]>
Date: Mon, 17 Mar 2003 01:16:41 -0500

Identification:
 
Identifiers will be both mobile and stationary?
 
Identifiers should be able to communicate with other identifiers through
multiple locations?
 
Identifiers should be able to change their location?
 
But we cannot hard code identifiers in silicon?
 
Can identifiers be within the context of Location?
 
/jim

---

From: David Conrad <[email-masked]>
Date: Sun, 16 Mar 2003 22:45:48 -0800

Jim,

You seem to be implicitly assuming something, but I'm not quite sure 
what.

To me, identifiers are values that uniquely and globally (at least 
within the context of an internet) identify communication end points.  
 From this definition, I'll hazard a guess at answers to your questions:

> Identifiers will be both mobile and stationary?

Identifiers are independent of location, thus they can be either.

>  Identifiers should be able to communicate with other identifiers 
> through multiple locations?

Yes.

>  Identifiers should be able to change their location?

Of course.

>  But we cannot hard code identifiers in silicon?

There is no _technical_ reason this couldn't be done.  People concerned 
about privacy might get uptight about this though.

>  Can identifiers be within the context of Location?

Not sure what this means.  Reachability to a given identifier depends 
on its locator, so perhaps I'd say yes.

Rgds,
-drc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Mar 2003 09:48:27 +0100 (CET)

> within the context of an internet) identify communication end points.

This is old-style thinking.  :-)

What makes a good identifier? Not something like an EUI64 identifier,
for the following reasons:

1. no usable hierarchy, hard to create a distributed database
2. when I replace my network card, I haven't changed my identity
3. It would be extremely hard to make sure each EUI64 is only used once
   globally
4. I could very well be using several network cards but it's still
   always "me"

So we need to identify hosts rather than interfaces. But we can be even
more radical if we want to: an identity could be assigned to a service
or other resource that lives on more than one host. If I want to connect
to www.cnn.com, do I care whether I get www4.cnn.com or www7.cnn.com? On
the other hand, when i have a connection, I want to keep communicating
with the same host for the life time of the connection.

I feel FQDNs are the ideal identifiers. They have a good hierarchy and
the past 10 years or so have shown that building a distributed database
to look up properties associated with them can work well. Also, it is
possible to map arbitrary stuff (IPv4 or IPv6 addresses, phone numbers)
to FQDNs so it should still be possible to adopt "better" identifiers
later. (Or "inferior" ones first for backward compatibility.)

(But maybe I'm getting ahead of things.)

> There is no _technical_ reason this couldn't be done.

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.

Iljitsch

---

From: David Conrad <[email-masked]>
Date: Mon, 17 Mar 2003 08:30:27 -0800

Iljitsch,

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

No.  An identifier can have hierarchy if desired.  What is important is 
that the identifier hierarchy is independent of the location hierarchy.

> 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.

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

See the comment above.

> 4. I could very well be using several network cards but it's still

See the comment above.

> 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.

> I feel FQDNs are the ideal identifiers.

Fine.

Yes.

> 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.

Rgds,
-drc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Mar 2003 18:50:02 +0100 (CET)

> 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.)

> 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.

> See the comment above.

Your comment doesn't address this.

> 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.)

> nybbles and append a TLD, say eui64,arpa.  This name could map into a

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