headers
Miika Komu | 4 May 17:28
Picon
Picon
Favicon

sockets APIs extensions for Host Identity Protocol

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
Permalink | Reply | 52 comments |
headers
Stephane Bortzmeyer | 7 May 10:27
Picon

Re: sockets APIs extensions for Host Identity Protocol

On Fri, May 04, 2007 at 06:28:30PM +0300,
 Miika Komu <miika <at> iki.fi> wrote 
 a message of 27 lines which said:

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

One important thing: this is only for the C programming language. In
most (all?) other languages, programmers no longer handle directly IP
addresses and thus are shielded from things like IPv4 vs. IPv6 or
addresses vs. handles.

> This latter observation makes me wonder whether there have been such
> considerations previously in the applications area?

The big advice should be: use a high-level language (or, in C, a
high-level library, like Neon - http://www.webdav.org/neon/ - or cURL
- http://curl.haxx.se/) and you're safe from the changes in IETF
fashions.
Permalink | Reply | 41 comments |
headers
Chris Newman | 7 May 23:31
Picon

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.

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
(Continue reading)

Permalink | Reply | 9 comments |
headers
der Mouse | 8 May 00:07
Picon

Re: sockets APIs extensions for Host Identity Protocol

> Application software wants to work with strings.  [...]

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

Something wrong with getaddrinfo()?  It certainly could use something
HIPish under the hood, if some implementor decided to.

>> A potential benefit of the handles is that it would make the API
>> future-proof againts changes to the HIT size.

getaddrinfo() already is...or at least, it is when used correctly, and
in this respect it's easier to use it correctly than incorrecetly
(which is about all you can expect).  It's a slightly broken API, true,
but the problems with it are not in areas that any putative HIP/HIT
stuff would fix.

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

That concept *has* been available for the past twenty years; it's
called a "socket".  What hasn't been available is a socket
implementation that doesn't expose the underlying addressing details to
the application.  This could be - and arguably should be - fixed
entirely under the socket-layer hood, not by inventing new protocols
and exposing *them* to the application.  I speculate that the major
reason this hasn't been done is tradition - sockets have traditionally
been a fairly direct interface into the kernel, and preserving that
(Continue reading)

Permalink | Reply | 5 comments |
headers
Keith Moore | 9 May 05:19
Picon

Re: sockets APIs extensions for Host Identity Protocol

Stephane Bortzmeyer wrote:
>> 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.
>>     
>
> One important thing: this is only for the C programming language. In
> most (all?) other languages, programmers no longer handle directly IP
> addresses and thus are shielded from things like IPv4 vs. IPv6 or
> addresses vs. handles.
>   

In those cases, the programmers are also crippled and prevented from
dealing effectively with various cases that are now increasingly common
in the Intenet today: NATs,  multiple addresses for source and
destination (not all of which work equally well), IPv4 vs IPv6 (for
which the default address selection rules are woefully inadequate),
multi-faced DNS, LLMNR, etc.
> The big advice should be: use a high-level language (or, in C, a
> high-level library, like Neon - http://www.webdav.org/neon/ - or cURL
> - http://curl.haxx.se/) and you're safe from the changes in IETF
> fashions.
>   

only if you want to limit the deployability and/or efficiency of your
application.

Keith
(Continue reading)

Permalink | Reply | 39 comments |
headers
Keith Moore | 9 May 05:22
Picon

Re: sockets APIs extensions for Host Identity Protocol


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

If you can figure out how to write that kind of code in a way that works
well for a wide variety of applications, with different requirements for
bandwidth, stability, mobility, etc. all of which affect address
selection, interface selection, etc., and do all of that efficiently and
in the absence of routing information from the network, you should
probably get a prize of some sort.

Granted that programmers want a simple interface, but the more complex
the network gets, the more apps will be expected to do jobs that were
supposed to be done at layer 3.

Keith
Permalink | Reply | 1 comment |
headers
Keith Moore | 9 May 05:24
Picon

Re: sockets APIs extensions for Host Identity Protocol


> Something wrong with getaddrinfo()?  It certainly could use something
> HIPish under the hood, if some implementor decided to.
>   

getaddrinfo() is a disaster.  not only is it the most baroque call in
the entire sockets API, it also invites implementors to abuse its
semantics in numerous ways (for instance, looking up SRV records for
apps that weren't intended to use SRV records).

Keith
Permalink | Reply | 0 comments |
headers
Stephane Bortzmeyer | 9 May 14:17
Picon

Re: sockets APIs extensions for Host Identity Protocol

On Tue, May 08, 2007 at 11:19:51PM -0400,
 Keith Moore <moore <at> cs.utk.edu> wrote 
 a message of 29 lines which said:

> In those cases, the programmers are also crippled and prevented from
> dealing effectively with various cases that are now increasingly
> common in the Intenet today: NATs, multiple addresses for source and
> destination (not all of which work equally well), IPv4 vs IPv6 (for
> which the default address selection rules are woefully inadequate),
> multi-faced DNS, LLMNR, etc.

I strongly object to the idea of application programmers dealing with
NAT, IPv4 vs. IPv6 or source address selection for the eternity. The
wiring of level-3 details in the applications is precisely what makes
the transition to IPv6 so difficult. Applications should not have to
be "ported to IPv6". They should work the same with both level-3
protocols (and, indeed, they do, in every language but C).

If the IPv6 problems are to be useful, it is in showing that there is
ZERO probability of splitting the identifier and the locator if we
have to change the applications.

I also really doubt that the typical application programmer is able to
do a better job than the kernel / libraries to, choose the source
address or other level-3 features. Plus, IMHO, if someone must
influence this selection, it should be the system and network
administrator, not the application programmer.

> only if you want to limit the deployability and/or efficiency of
> your application.
(Continue reading)

Permalink | Reply | 37 comments |
headers
Keith Moore | 9 May 15:19
Picon

Re: sockets APIs extensions for Host Identity Protocol


>> In those cases, the programmers are also crippled and prevented from
>> dealing effectively with various cases that are now increasingly
>> common in the Intenet today: NATs, multiple addresses for source and
>> destination (not all of which work equally well), IPv4 vs IPv6 (for
>> which the default address selection rules are woefully inadequate),
>> multi-faced DNS, LLMNR, etc.
>>     
>
> I strongly object to the idea of application programmers dealing with
> NAT, IPv4 vs. IPv6 or source address selection for the eternity. The
> wiring of level-3 details in the applications is precisely what makes
> the transition to IPv6 so difficult. Applications should not have to
> be "ported to IPv6". They should work the same with both level-3
> protocols (and, indeed, they do, in every language but C).
>   

In a sense, I agree with you that we don't want most applications having
to deal with these things, and we certainly don't want to saddle the
application with having to deal with these problems forever.  However, I
do not reach the same conclusion about the API that you appear to reach,
for a few reasons. 

First is that there will always be some applications (such as diagnostic
tools) that need to know more about the network, so it is necessary to
have an API that allows those applications to function.

Second, I don't share the view that many seem to have that applications
in general should be IP version agnostic.  IPv4 with NAT is far too
brain-damaged, and has such limited reach, so there is a strong case to
(Continue reading)

Permalink | Reply | 34 comments |
headers
John C Klensin | 9 May 15:20

FWD: Re: Comments on Unicode Format for Network Interchange

FYI, in the hope of _not_ having two separate discussions going
on.
     john

---------- Forwarded Message ----------
Date: Wednesday, 09 May, 2007 08:06 -0400
From: John C Klensin <klensin+unicore <at> jck.com>
To: Doug Ewell <dewell <at> adelphia.net>
Cc: UnicoRe Mailing List <unicore <at> unicode.org>, "Magda Danish
\\\\(Unicode\\\\)" <v-magdad <at> microsoft.com>, Mike Padlipsky
<the.map <at> alum.mit.edu>, Chris Newman <chris.newman <at> sun.com>,
Lisa Dusseault <lisa <at> osafoundation.org>
Subject: Re: Comments on Unicode Format for Network Interchange

Doug, Benson, Markus, and L2 and UTC members,

My thanks for your input (and for that of Frank Ellermann, which
I don't believe was copied to the Unicore/ L2 list -- see
below).  I appreciate informed and thoughtful comments from any
source and, while I cannot speak in any formal way for the IETF,
the IETF generally does too.  I have two observations on this
thread, the second of which is a procedural issue but one that
may be of some importance.  I apologize in advance for the
length of this note, but it seems useful to put both sets of
issues to rest.

Doug's comments appear to me to exactly reflect the
considerations and IETF experience that went into
draft-klensin-net-utf8-03c.  We tried to review and explain
those considerations in the fairly extensive historical material
(Continue reading)

Permalink | Reply | 9 comments |

Gmane