Re: Identifier (structure) [Was: Agenda for Vienna]

[marcelo bagnulo <marcelo@it.uc3m.es>]

Hi Erik,


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

Do you think that the identifier name space should be the same that the
locator address space or should be a separate one?

I mean, we could use the IPv6 address space to contain both locators and
identifiers and that any address could be used both as an identifier or
as locator.

The other option is to split the IPv6 address space and reserve a part
of it to identifiers

Finally, we could use a completely separate 128 bit address space 

I guess that there are some clear benefits in all the cases, for
instance: if we create a completely new address space, we can use it
fits better to our needs. The first option can provide us with good
backward compatibility, since old hosts can just use the address bothas
identifier and locator and no mapping (i.e. additional security) is
needed. But i am sure that there is much more here for me to
understand...   

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

Fully agree, 

A really good approach to this issue is JNC's Endpoint and endpoint
names (can be found http://users.exis.net/~jnc/tech/endpoints.txt) for
those few of you who has not read it yet :-)
I would even say that this should become a wg document

regards, marcelo


> > >  - 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
> 
-- 
marcelo bagnulo <marcelo@it.uc3m.es>
uc3m