Re: sockets APIs extensions for Host Identity Protocol

[Chris Newman <[e-mail]>]

Speaking as a technical participant, not as an area director...

Application software wants to work with strings.  When I want to make a network 
connection, I have a string which says what I want to connect to.  It might be 
a DNS name, an IPv4 address literal, and IPv6 address literal, the field after 
the "//" in a URL or whatever the string format for a HIP endpoint is going to 
be.  As an application developer I don't want to care what that string means. 
I might want a way to turn that string into an opaque object (or objects) and 
back (with a timeout) and then use that opaque object in something equivalent 
to connect and/or bind.

I also want a way to enumerate the string representations of the local 
interfaces on a server so that I can offer the administrator a choice of which 
interface(s) the listen ports bind to.  I don't want to care whether those are 
IPv4, IPv6 or HIP or something else.

The only reason I might care what the string or opaque object refers to is for 
debugging/logging/diagnostic purposes.

If I change my "connectbyname" code again, I will change it once more to use a 
new OS API that hides all the v4 vs. v6 vs. HIP vs. whatever junk, preferably 
to something much simpler than the code today.  If such an API isn't produced, 
I will be very reluctant to change that code no matter how cool HIP might or 
might not be.

So the API described in your document is one I plan to never use if at all 
possible.  That might have consequences for HIP deployment, just as the present 
state of IPv6 C socket APIs has not been great for IPv6 deployment.

                - Chris

Miika Komu wrote on 5/4/07 18:28 +0300:

> Hi all,
>
> we are contemplating a level of indirection in naming hosts to future-proof
> the Host Identity Protocol (HIP). The proposed sockets API extensions use
> locally-scoped "handles" instead of Host Identity Tags (HITs, that is,
> cryptographically generated IPv6-like addresses). One could conceive that
> such a level of indirection could be used more generally outside of HIP, to
> enable applications to be more compatible across IP versions, for instance.
> What are the benefits and costs that you see about migrating the basic socket
> API calls towards end-system handles rather than explicit end-system
> addresses?
>
> A potential benefit of the handles is that it would make the API future-proof
> againts changes to the HIT size. Similarly, one might argue that the IPv6
> transition would have been a lot easier for applications if the concept of
> endpoint descriptor were already available for the past twenty years; IPv6
> could have been hidden in the system.  This latter observation makes me
> wonder whether there have been such considerations previously in the
> applications area?
>
> The sockets API extensions are defined here:
>
> http://www.ietf.org/internet-drafts/draft-ietf-hip-native-api-01.txt
>
> --
> Miika & Tom
>
>
>