[Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting

pekka.nikander@nomadiclab.com (Pekka Nikander) Mon, 23 August 2004 09:46 UTC

From: pekka.nikander@nomadiclab.com (Pekka Nikander)
Date: Mon Aug 23 09:46:00 2004
Subject: [Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting
In-Reply-To: <41218639.8060303@isi.edu>
References: <6938661A6EDA8A4EA8D1419BCE46F24C045223EE@xch-nw-27.nw.nos.boeing.com> <Pine.GSO.4.58.0408161501130.1778@kekkonen.cs.hut.fi> <41218639.8060303@isi.edu>
Message-ID: <A4DD7898-F513-11D8-BD49-00306571BE62@nomadiclab.com>

>> Some question were raised in the hipsec-rg meeting in San Diego and 
>> I'd
>> like comment them briefly:
>>>
>>> Lars Eggert:  Why are you binding to a src interface rather than
>>> address?...
>
> You can bind to the endpoint descriptor, but the association must be 
> with an interface/address pair. Otherwise, there's no way to control:
>
> 	1- when you have one interface with multiple addresses:
> 		which address to use (under app, transport, or net
> 		control)
>
> 	2- when you have one address on multiple interfaces:
> 		which interface to use (again under app, transport,
> 		or net control
>
> (1) is aliasing, and (2) s more common with multicast addresses, but 
> can also occur with unicast.

I like this argument.

>  Both can change - e.g., inserting PCMCIA cards, USB interfaces, etc.

Right.  But see below.

> In conventional multihomed situations, apps can want control over 
> which IP address is used as the source. The corrollary in this case is 
> control over which interface/IP address pair is used. I.e., _both_ are 
> required.

Right.  But in the mobile multi-homed situation, where at least I would
consider HIP very useful, the interfaces are more stable than the
addresses.  Hence our motivation for binding locally to interfaces,
not addresses.

However, thinking more widely, yes, you need both.  Furthermore,
you need a notification API that tells your application whenever there
is a change in the available interfaces and/or addresses.

--Pekka