[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

Too early for me to have any opinion - I think we need to understand both the
weak and strong id/loc separation and see what the tradeoffs are.

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

That is what I've seen others call a weak split.
Similar in nature to mobile IPv6 where in some cases an address is
a locator and in other cases an identifier and you can't tell (based on 
its syntax or based on where it appears in packets) which one it is.

> 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 think both of these, including an identifier which doesn't fit in 128 bits,
is what I'd call strong separation.

One of many tradeoffs in this space is that if the identifier is 128 bits
in length there might be transition benefits to being able to tell whether
a 128 bit chunk is an identifier or a locator.
For instance, that would allow applications which do getaddrinfo() followed
by connect()/sendto() to receive locators for old peers (those that don't
have an IP identifier and don't do whatever new protocol we come up with)
and receive identifiers for new peers.
Then the stack under connect()/sendto() can look at some leading bits
of the 128 to tell whether it needs to do an ID->locator mapping, or
just send a packet.
But as I said, I think this is only one of the tradeoffs.

> 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

There is also the NSRG report to look at. It at least
specifies a granularity for the "stack names" which seems like a useful one
to me.

  Erik