Subject: [RAM] [Fwd: sockets APIs extensions for Host Identity Protocol]

From: Eliot Lear <[email-masked]>
Date: Sun, 06 May 2007 11:34:48 +0200

For those not on the application area discuss list, this might be of 
some relevance.

Eliot

Subject: sockets APIs extensions for Host Identity Protocol
From: Miika Komu <[email-masked]>
To: [email-masked]
Cc: Thomas Henderson <[email-masked]>
Date: Fri, 4 May 2007 18:28:30 +0300 (EEST)
List-Id: general discussion of application-layer protocols <discuss.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

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram