Re: sockets APIs extensions for Host Identity Protocol

[Miika Komu <[e-mail]>]

On Wed, 9 May 2007, Keith Moore wrote:

Hi,

>>> Fourth, for a variety of reasons, DNS names are not and have never been
>>> adequate as general purpose endpoint identifiers, and this situation is
>>> getting worse rather than better.  One reason is that DNS names are not
>>> equivalent to host names, and emphatically not equivalent to
>>> distinguished host names, and haven't been so at least since the web
>>> came into existence.  A given DNS name might be bound to a single host,
>>> multiple hosts having more-or-less equivalent function, a service, a
>>> community of users, or whatever; the binding might be stable or
>>> ephemeral; and the name might or might not be suitable as a
>>> distinguished name (one chosen preferentially over others for use in
>>> indicating that host, group of hosts, service, whatever).  There's no
>>> way to tell.
>>
>> All of this is true for IP addresses as well.
>>
>
> good point.  though if you collect multiple hosts under the same IP
> address, without considering how this will affect the apps that run on
> those hosts, you pretty much deserve to lose.
>
> neither DNS names nor IP addresses work very well as endpoint identifiers.

thanks for the good points! However, it is not still clear to me what to 
do in the case of HIP aware applications. I hope we can agree that 
something needs to be done at the sockets API layer? At the minimum, we 
want to make the application to use HIP (either by using HITs directly or 
indirectly through locally-scoped identifiers), and provide a way for the 
application to determine that it is using HIP.

My exact question is that what to put into the socket address structures 
when we have HIP-aware applications. Based on the discussion, I think we 
can leave socket address structures based on DNS names out of the scope 
and concentrate on two alternatives: globally scoped HITs and locally 
scoped idenfiers (endpoint descriptors).

The use of globally-scoped HITs has the following trade-offs:
+ No extra translation step from local id to global id
+ Smaller transition step to convert a legacy app to a HIP aware app?
- Opportunistic HIP mode, where the server's HIT is not known before hand,
   will require a locally-scoped identifier anyway. This is similar to
   IN6ADDR_ANY, but it is used for the remote host, i.e.,
   connect(UNKOWN_HIT) where only the locator is known.
- No future proofing against the HIT size

Locally-scoped identifiers have the reverse properties:
- Extra translation step from local id to global id
- Bigger transition step to convert a legacy app to a HIP aware app?
+ All identifiers are of the same type (also in opportunistic HIP mode)
+ Future proofing against changes in the HIT size

If you had to choose between these two, what would you choose and why? 
Do the proposed trade-offs make sense and would have something to add?

P.S. Please notice that the HITs are basically "free" of the NAT burden 
because they are globally scoped, end-to-end identifiers.

-- 
Miika Komu                                       http://www.iki.fi/miika/