Re: [Hipsec] ROUTE_VIA and _DST support for HIP native API

[Ari Keränen <[e-mail]>]

On Wed, 29 Jul 2009, Miika Komu wrote:
> Ari Keranen wrote:
>> Sorry that this comes a bit late in the process, but I think it would make 
>> sense to have support for the source routing & route recording ROUTE_DST 
>> and ROUTE_VIA parameters [1] in the HIP native API. They are needed for HIP 
>> BONE but likely they have use also in other contexts and then an 
>> application would need an API for using them.
>> 
>> Maybe the API that RFC 2292 [2] defines for IPv6 routing header could be 
>> re-used for this purpose.
>> 
>> 
>> Cheers,
>> Ari
>> 
>> [1] http://tools.ietf.org/html/draft-camarillo-hip-via-00
>> [2] http://tools.ietf.org/html/rfc2292#section-8
>
> I had a brief look a the routing header options and I think this would 
> require a lot more work. I think we just can't tell "use IPv6 routing header 
> for route recording" because we need to dig out the differences with orchid 
> vs. IPv6 routing and flesh out all the details. The current time schedule is 
> quite tight for this too.
>

Actually my idea was not that you would use IPv6 routing header for the 
route recording, but you could perhaps re-use the API -- if it makes 
sense. The actual (HIP) route recording and source routing would be done 
with the ROUTE_{VIA,DST} parameters. If some other API than what RFC 2292 
proposes is better, that's perfectly fine for me. Based on your comments, 
some other form of API is probably better.

Essentially an application would need to be able to give a HIP socket a 
list of HITs (for source routing), set option to enable route recording 
and symmetric routing, and be able to read a recorded route (i.e., a list 
of HITs). I think a quite simple API extension would be sufficient for 
this.

But by tight schedule are you referring to WGLC? I guess it's OK to 
postpone that a couple of days/weeks, if necessary?

> Currently, the native API draft defines "Basic Socket Interface Extensions 
> for Host Identity Protocol (HIP)". I believe the hiccups extensions belong to 
> the category of "advanced" and the reference to [2] is also "Advanced Sockets 
> API for IPv6".
>
> I would propose that we'd introduce another document for orchid routing or 
> add them to the VIA draft. Please comment this proposal ASAP so that I'll 
> have more time to hack this over the night if people want to see the changes 
> in the native API.
>

This is not really a HICCUPS extension, but I see your point. If we have 
more "advanced" features, a new API draft could make sense, but probably 
not for just this extension. Also the VIA draft does not seem like a right 
place for API documentation.


Cheers,
Ari