Re: sockets APIs extensions for Host Identity Protocol

[Miika Komu <[e-mail]>]

On Fri, 11 May 2007, Keith Moore wrote:

>> What about "native" HIP applications that are aware of HIP? The whole
>> point of the locally scoped identifier was to provide single, unified
>> end-point token to applications. Is it acceptable to handle both
>> sockaddr_in and sockaddr_hip structures in HIP aware apps? I think a
>> single identifier type would be simpler.
>
> I don't know why a HIP-aware app would use sockaddr_in* for any socket
> on which it wanted to use HIP.  Such an app might want to use
> sockaddr_in for some sockets if it had a reason to not use HIP on
> specific sockets.  (say for diagnostic purposes)

Sorry, I meant sockaddr_in6 in this case.

> I must have missed the point of locally-scoped identifiers.  I thought
> it was so that you could fit a pseudo-HIT into 32 bits and pretend it
> was an IPv4 address for the sake of backward compatibility.

Yes. There can be two types of "pseudo-HITs":

Local Scope Identifier (HIP legacy apps draft):
* Looks like an IPv4 address
* Might even have a locally configured prefix to separate between a LSI
   and non-LSI address

Endpoint descriptor (HIP native apps draft):
* Looks more like a FD (increasing or random number)
* No prefix

> But if your application was written to be HIP-aware, it would be cleaner 
> to use HIP-specific sockaddrs.  And in that case, why use a 
> locally-scoped identifier when you can use a globally-scoped one?  (and 
> if your application wasn't originally written to use HIP it's probably 
> the case that the best you can hope for with small mods to your code is 
> opportunistic HIP anyway.)

Yes, but how to do opportunistic mode in a new application that wants to 
use opportunistic mode for some connections and normal mode for others?

>>> OTOH, if I'm doing "real" HIP then I want to use something like a
>>> sockaddr_hip structure that lets me specify both the HIT (as the
>>> "address") and a variable number of IP addresses (including both IPv4
>>> and IPv6 addresses) at which the peer named by the HIT might be
>>> reachable (or at which a redirect to the actual peer might be
>>> obtainable).
>>
>> The is certainly possible. One could also implement opportunistic mode
>> by leaving out the HIT from sockaddr_hip and by specifying only the
>> IP. However, there is an inherent problem with this approach as
>> described below.
>>
>>> And then you probably want a HIP-specific replacement for
>>> getaddrinfo() that will return not only addresses but also the HIT
>>> associated with a DNS name and whatever other information is useful in a
>>> form that's easily stuffed into a sockaddr_hip.
>>
>> Why this can't be done in the current resolver by specifying a flag?
>
> for starters, the addrinfo structure doesn't have a field for a HIT, and
> in a HIP aware app you'd certainly want to specify which HIT you wanted
> to talk to.   neither does addrinfo have any way of representing things
> that are quite reasonable - like a single DNS name mapping to multiple
> HITs, each of which maps to multiple IP addresses, where some of those
> addresses are addresses at which the peer might reasonably be found, and
> others are for redirect servers.

The addrinfo structure has the generic sockaddr *ai_addr field which can 
be used for encapsulating a HIT, LSI or ED.

One of reasons for the local-scope identifier was to hide the "which HIT 
maps to which IP" complexity from the application. This does not prevent 
the application rearranging the identifiers behind the locally-scoped
identifiers using a separate function call.

What kind of redirect servers are we talking about?

> more generally, getaddrinfo() sucks so bad that any excuse to get rid of
> it is worth considering.

How would a new resolver work in your opinion? I guess there has not been 
any prior work on this in the IETF.

>>> really you want to be able to map a DNS name into multiple HITs, each of
>>> which can have zero or more IPv* addresses associated with it.... and
>>> you want a standard data structure that consists of a HIT + IP addresses
>>> that can be passed around in referrals.
>>
>> The problem with this approach is that it will encourage developers to
>> use the IP address directly from the socket address structure. The
>> host corresponding to the HIT may have changed it's IP address at that
>> point (independently of whether the structure describes the local or
>> remote host). I believe that it is be much better to "force" the
>> developer to obtain a valid IP address using a separate function call
>> (see draft-ietf-shim6-multihome-shim-api). An extra call should not be
>> a problem in a HIP aware application.
>
> it's certainly the case that DNS-to-HIT mapping might change
> independently of a HIT-to-IP mapping.  that, and when there are multiple
> HITs associated with a single DNS name, a single routine might end up
> doing several different lookups for the HIT-to-IP mappings, which could
> take a lot of time.   so on reflection I agree that it makes sense to do
> the lookups separately.

Ok, but what do you think about exposing the IP address to the 
applications in a sockaddr_hip structure? My point was not really about 
the lookup process, but more like what is going to happen after initial 
contact between two hosts. After establishing communications, a host 
moves to another network, detects that its IP address has changed and 
communicates its new location to the peer. At this point, the IP address 
that was originally received from the resolver is depracated.

-- 
Miika Komu                                       http://www.iki.fi/miika/