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

[Miika Komu <[e-mail]>]

Ari Keränen wrote:

Hi,

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

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

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

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