Re: sockets APIs extensions for Host Identity Protocol

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

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlAnx-0006IT-9P; Mon, 07 May 2007 17:31:37 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1HlAnw-0006IO-1q for discuss-confirm+ok@megatron.ietf.org; Mon, 07 May 2007 17:31:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlAnv-0006IF-OU for discuss@apps.ietf.org; Mon, 07 May 2007 17:31:35 -0400
Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlAnu-0003V2-5f for discuss@apps.ietf.org; Mon, 07 May 2007 17:31:35 -0400
Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l47LVXRj024604 for <discuss@apps.ietf.org>; Mon, 7 May 2007 21:31:33 GMT
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JHO00101WTGCU00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for discuss@apps.ietf.org; Mon, 07 May 2007 15:31:33 -0600 (MDT)
Received: from [10.0.1.21] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JHO008J6X4I6330@mail-amer.sun.com>; 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: <Pine.SOL.4.64.0705041801060.14418@kekkonen.cs.hut.fi>
To: Miika Komu <miika@iki.fi>, discuss@apps.ietf.org
Message-id: <31BC7A8C1A51004A84E08DEF@[10.1.110.5]>
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: <Pine.SOL.4.64.0705041801060.14418@kekkonen.cs.hut.fi>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: Thomas Henderson <thomas.r.henderson@boeing.com>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

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