RE: sockets APIs extensions for Host Identity Protocol

"Henderson, Thomas R" <> Thu, 10 May 2007 18:48 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1HmDgo-0007Y4-3O; Thu, 10 May 2007 14:48:34 -0400
Received: from discuss by with local (Exim 4.43) id 1HlSpT-0000oK-Fe for; Tue, 08 May 2007 12:46:23 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1HlSpT-0000oA-5w for; Tue, 08 May 2007 12:46:23 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1HlSpH-0008LP-U1 for; Tue, 08 May 2007 12:46:23 -0400
Received: from ( []) by (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l48Gk9QQ028957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 May 2007 09:46:10 -0700 (PDT)
Received: from (localhost []) by (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l48Gk8DH003445; Tue, 8 May 2007 09:46:09 -0700 (PDT)
Received: from ( []) by (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l48Gjdv3001656; Tue, 8 May 2007 09:45:47 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 09:43:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: sockets APIs extensions for Host Identity Protocol
Date: Tue, 8 May 2007 09:43:45 -0700
Message-ID: <>
In-Reply-To: <31BC7A8C1A51004A84E08DEF@[]>
Thread-Topic: sockets APIs extensions for Host Identity Protocol
Thread-Index: AceQ7xcdhsjtI3MlRdGtmzkgAaIFsAAnuoYQ
From: "Henderson, Thomas R" <>
To: "Chris Newman" <Chris.Newman@Sun.COM>, "Miika Komu" <>, <>
X-OriginalArrivalTime: 08 May 2007 16:43:46.0102 (UTC) FILETIME=[0BB41D60:01C79190]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
X-Mailman-Approved-At: Thu, 10 May 2007 14:48:33 -0400
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


> -----Original Message-----
> From: Chris Newman [mailto:Chris.Newman@Sun.COM] 
> Sent: Monday, May 07, 2007 2:32 PM
> To: Miika Komu;
> Cc: Henderson, Thomas R
> Subject: Re: sockets APIs extensions for Host Identity Protocol
> 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.

Is the IETF in the business of defining this new API?  Or is the IETF
scope limited to sockets, and the APIs that you seek are defined by
library and OS developers?

As a HIP WG participant, I see that there has been a history of RFCs for
sockets API extensions (2292, 2960, 4584, etc.).  We could do a similar
one for HIP, but Miika has proposed that we go for a more future-proof
API and build in some abstraction.  It seems to me that there is support
for defining such an API and it has already been done successfully for

(note also that there has been discussion on the RAM list this week on
this topic).