Re: sockets APIs extensions for Host Identity Protocol

[Keith Moore <[e-mail]>]

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

there are lots of reasons.  one is that it unnecessarily couples the
resolver routines with the socket routines, and thereby imposes a
dependency that isn't there now and shouldn't be there.  in other words,
you shouldn't be expected to use the system resolver (e.g. maybe you
want to use an asynchronous DNS library).  another reason is that it
requires the kernel and/or library to manage state that's invisible and
inaccessible to the application - and yet there will probably be
situations that will cause the application to fail if the invisible
state isn't managed like the application expects.  for instance,
consider an app that uses HITs for referrals layered on top of a kernel
that keeps HIT-to-IP mappings only for a limited time before discarding
them.  if the app tries to send to a HIT after that time, the kernel
isn't going to have the mapping any longer.
>> 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 don't think I understand the question.   You're going to need
different routines to look up HITs, and HIT-to-IP mappings anyway.
>
> 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.
given that the flow label field in the sockaddr_in6 field isn't even
used in the implementations I've seen (my understanding is that it's not
supposed to be copied to the IPv6 packet), this seems like overkill. 
I'd just put a list of in6_addrs in there.

it bugs me a little bit that there's a port field in there, since HIP is
a layer on top of IP, and there might be IP protocols that don't have
ports.  what if someone wants to run SCTP over HIP?
> 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.
interesting question.  actually I think that a HIP association should be
able to exist between two hosts independently of any transport-level
connection, and it might be appropriate to have calls to setup and
discard such associations independently of any connection setup.  that
would yield two cases for datagram communications: in one case the HIP
association would exist and the HIT-to-IP mappings would have been
maintained to keep them current.  in that case the sendto() would just
work, since the sending host would already know how to route to that
HIT. in the other case either there would be no association or no usable
HIT-to-IP mappings (say there had been a network outage and all of the
mappings had expired).   in that case the sendto() would fail with
something like "no route to host" and it would be up to the application
to supply new mappings to the kernel.
> 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?
somehow I think it would be better if the API details were hashed out
here, where they can get wider exposure within the apps area.

Keith