sockets APIs extensions for Host Identity Protocol

Miika Komu <miika@iki.fi> Sat, 05 May 2007 15:19 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 1HkM2W-0005wi-Uy; Sat, 05 May 2007 11:19:16 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1Hjzi2-0008Cq-Is for discuss-confirm+ok@megatron.ietf.org; Fri, 04 May 2007 11:28:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hjzi2-0008Ci-99 for discuss@apps.ietf.org; Fri, 04 May 2007 11:28:38 -0400
Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hjzi0-0002A5-UT for discuss@apps.ietf.org; Fri, 04 May 2007 11:28:38 -0400
Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id AE1CD2CAA; Fri, 4 May 2007 18:28:31 +0300 (EEST)
X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322
X-Spam-Niksula: No
Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id E84B82CA6; Fri, 4 May 2007 18:28:30 +0300 (EEST)
Date: Fri, 4 May 2007 18:28:30 +0300 (EEST)
From: Miika Komu <miika@iki.fi>
X-X-Sender: mkomu@kekkonen.cs.hut.fi
To: discuss@apps.ietf.org
Subject: sockets APIs extensions for Host Identity Protocol
Message-ID: <Pine.SOL.4.64.0705041801060.14418@kekkonen.cs.hut.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
X-Mailman-Approved-At: Sat, 05 May 2007 11:19:15 -0400
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

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