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

[Ari Keranen <[e-mail]>]

Miika Komu wrote:
> Ari Keränen wrote:
>> 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.
> 
> I didn't mean that RFC2292 is not suitable. I merely questioned where 
> this functionality should be added and that we shouldn't be hasty in 
> adding new features that haven't been properly chewed first.

OK.

> We'd probably need also some socket options to turn hiccups on and off. 
> All of the requirements are not clear to me yet.

Yes, some HICCUPS API extensions would be useful too.

>> 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?
> 
> Any other opinions on this? What should we do about it?
> 
> I have submitted the final 08 version. I am fine with delaying if people 
> feel that source routing should be included, but I think it could also 
> be hosted in a different draft.

OK (more of this below).

>>> 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.
> 
> We left out RFC3484 related issues from the native API draft because it 
> was too immature for last call. If we started up a new draft, we could 
> include source HIT selection when a host has multiple HITs.

OK, so maybe there is need for such advanced API draft after all and the 
VIA extensions, as well as HICCUPS extensions, would fit there well. So, 
I guess there is no need to delay the WGLC of the current basic API draft.


Cheers,
Ari