Re: sockets APIs extensions for Host Identity Protocol

[Miika Komu <[e-mail]>]

On Fri, 11 May 2007, Keith Moore wrote:

Hi Keith,

> Miika Komu wrote:
>> On Fri, 11 May 2007, Keith Moore wrote:
>>
>>> please no.  don't try to hide this stuff from the app in the low-level
>>> API.   the rest of the network keeps trying to force routing decisions
>>> on the apps in the absence of routing information.  ideally, the app
>>> shouldn't have to be doing any routing or address selection or
>>> anything.  but at present, how to cope with this kind of world is an
>>> unsolved problem, and the only place where experimentation can be done
>>> towards learning how to solve that problem is at layer 7.    if you
>>> cripple the API, you prevent that kind of experimentation (at worst) or
>>> (at best) increase the burden on the app writer by forcing him to write
>>> his own kernel extensions.
>>>
>>> that, and you still need to expose IP addresses for diagnostic purposes.
>>>
>>> what do you gain from trying to hide the IP addresses?
>>
>> First, to discourage the use of IP addresses as referrals because
>> application developer would have to fetch them using a separate
>> function call. But maybe this is a weak justification... Second, the
>> socket address structure is constrained to 255 bytes. It will fit
>> "only" 1 HIT and 15 addresses. Is this enough for e.g. routers?
>
> perhaps strangely, the latter justification makes more sense to me.  no,
> 15 addresses is not enough.  but it's not acceptable to have the IP
> addresses passed implicitly from the resolver to the socket.

Actually, the addresses passed from the resolver would be system level 
"hints" rather than bound to a specific socket because getaddrinfo 
resolver does not know anything about the sockets. What is the exact
reason why you see this as an bad idea?

> offhand, I'd say that a good compromise would be to allow some 
> reasonable number of addresses to be specified using sockaddr_hip and to 
> allow more peer addresses to be added using a setsockopt() call.

I don't see how this would work with the resolver? I guess the only way 
would be to output several HITs redundantly, but with different IP 
addresses. Would this work for you?

I thought about size limitations in more detail. A naive version of 
sockaddr_hip structure and its fields could look as follows based on the 
discussion:

struct sockaddr_hip {
    uint8_t             sinh_len;       /* 1 byte    */
    sa_family_t         sinh_family;    /* 1 byte    */
    in_port_t           sinh_port;      /* 2 bytes   */
    struct in6_addr     sinh_hit;       /* 16 bytes  */
    struct sockaddr_in6 sinh_loc[2];    /* 2 * 112 bytes */
} /* total: 244 bytes (note: maximum size 255 bytes) */

Here I just put two IPv6 addresses inside the structure and assume that we 
use IPv4 address in IPv4-in-IPv6 format. I know that we could insert more 
than two in_addr structures, but it is more complicated to handle. Also, I 
think it is important to have the flowlabels etc for IPv6 addresses, so we 
don't use in6_addr for locators. The port is defined twice; we could use 
the locator port to set the ESP-IN-UDP port number.

The HIT takes 16 bytes. For future extensions purposes, I would actually 
suggest to take the "back-up" locator away and reuse its space with 
16 bytes of reserved space just after the HIT. This way, we could have 
future expansion space for 256 bit HITs? And the single locator would fit 
nicely to the resolver scheme described above.

What about datagram oriented communications? What should happen when the 
HIT and socket remain the same, but locator changes between two sendto() 
calls? I guess it could be used for enforcing an handover.

There also some other protocols around with their own socket address 
structures (un, ipx, atmpvc, ax25, irda, rose, tipc, ash, ec). Perhaps it 
would be more wiser to fix IPv6 format at the API layer and define the 
sinh_loc just as an generic sockaddr.

Does this make sense? I guess this is getting quite specific already, so 
it may be a better idea to move the discussion to HIP mailing lists?

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