Re: sockets APIs extensions for Host Identity Protocol

Chris Newman <Chris.Newman@Sun.COM> Mon, 07 May 2007 21:31 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1HlAnx-0006IT-9P; Mon, 07 May 2007 17:31:37 -0400
Received: from discuss by with local (Exim 4.43) id 1HlAnw-0006IO-1q for; Mon, 07 May 2007 17:31:36 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1HlAnv-0006IF-OU for; Mon, 07 May 2007 17:31:35 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1HlAnu-0003V2-5f for; Mon, 07 May 2007 17:31:35 -0400
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id l47LVXRj024604 for <>; Mon, 7 May 2007 21:31:33 GMT
Received: from by (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <> (original mail from Chris.Newman@Sun.COM) for; Mon, 07 May 2007 15:31:33 -0600 (MDT)
Received: from [] ([]) by (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <>; Mon, 07 May 2007 15:31:33 -0600 (MDT)
Date: Mon, 07 May 2007 14:31:31 -0700
From: Chris Newman <Chris.Newman@Sun.COM>
Subject: Re: sockets APIs extensions for Host Identity Protocol
In-reply-to: <>
To: Miika Komu <>,
Message-id: <31BC7A8C1A51004A84E08DEF@[]>
MIME-version: 1.0
X-Mailer: Mulberry/3.1.6 (Mac OS X)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
References: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: Thomas Henderson <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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:
> --
> Miika & Tom