Identifier (structure) [Was: Agenda for Vienna]

[Erik Nordmark <Erik.Nordmark@sun.com>]

> > More detailed questions in this area are:
> >  - are identifiers flat or do they have internal structure?
> 
> We know that looking up stuff in a flat namespace isn't pretty. If we 
> truly want the identifier to be the identifier, then we need to be able 
> to look up stuff such as locators based on the identifier. 

Yep. It would be interesting to look at distributed hash tables for this,
even if it is probably unrealistic to do lookups on flat host identifiers.

> We can also 
> have something at an even higher level that is used as the "real" 
> identifier, I think this is what the HIP people do by mapping from the 
> FQDN to the crypto ID and the locators but not from the crypto ID 
> directly to the locators.

Yes, that is one approach.
It might make it more difficult for transition schemes where an unmodified
IPv6 host plus some "proxy" e.g. at the site border together implement things.
In such a case I think the IPv6 host (for transition purposes) would
send packets where IP source and destination are identifiers
thus the "proxy" would not see such higher level "real" identifiers.

Another issue to consider in this space is the goal to allow
applications already ported to IPv6 to continue to work when
the application uses getaddrinfo() followed by connect()/sendto().
This is at least easier to accomplish if the identifier fits in 128 bits.

So these are all important tradeoffs to try to understand better.

> >  - are (the fields of) the identifiers managed for uniqueness and other
> >    purposes or are they more or less random? (If there is internal 
> > structure
> >    potentially different fields can be different in this respect.)
> 
> I would like to make as few assumptions about the identifiers as 
> possible, so we can use different kinds of identifiers and not just 
> IPv6 addresses. FQDNs would make good identifiers. Cryptographic hashes 
> are also useful identifiers for some purposes. But that means we have 
> to design for the lowest common denominator = no real structure = hard 
> to look up.

Makes sense. 

If the identifier is split into "site identifier" plus "node within site ID"
then it might be feasable to build a distributed hash table for
the site identifier part. 
Some hard issues there is how to secure the DHT (the updates and the
information retrieved from it) - but that might not be that much different
than securing the source identifier received in a packet; solve one and the
other might fall out.

  Erik