Re: sockets APIs extensions for Host Identity Protocol

[Keith Moore <[e-mail]>]

>> It strikes me that if I'm using opportunistic HIP, then I probably want
>> to use normal sockaddr_in* structures and do a setsockopt() that says
>> "give me HIP if both ends support it" before doing connect() or
>> listen().  In that case I'd want getpeername() to still return the
>> peer's (current) IP address, but I'd want additional functions to return
>> the peer's HIT.  In that case I don't see any real value in having
>> locally-scoped pseudo-HITs.  The reason for doing things this way is
>> that it would require fewer changes to legacy code to support
>> opportunistic HIP.
>
> We have implemented opportunistic mode in the HIPL implementation in
> the way you described. It required some tricks under the sockets API
> hood to get it working, but it is great for legacy apps. Even
> referrals work, assuming that you are behind a NAT or a firewall :)
in other words, they don't work. :)
> 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)

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


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

more generally, getaddrinfo() sucks so bad that any excuse to get rid of
it is worth considering.
>> 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.