Re: sockets APIs extensions for Host Identity Protocol

[Keith Moore <[e-mail]>]

>> offhand, I think you need to support both.  HITs aren't very useful to
>> apps unless they are visible to them and globally-scoped.  HIP is still
>> useful without HIT visibility, but less useful.
>
> It does not mean that the HIT fingerprint, or preferably even the
> corresponding public key, are completely invisible to the application
> with locally-scoped identifiers. It is just a question of an extra
> function call that translates the local-scope identifier to the
> desired format (HIT or public key).
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.

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

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.