[support] MCoA send BUs via multiple interfaces

[Vilmos Nebehaj]

Hi Romain,

On Thu, Feb 4, 2010 at 10:07 AM, Romain KUNTZ <kuntz at unistra.fr> wrote:
> Hi Vilmos,
>
> Thanks for summarizing the issues and solutions, and sharing your patches here. I've already experienced this problem myself but never had the time to fix it.
>
> I won't have time in the near future to work on MCoA, nevertheless I was thinking to include a pointer to these 2 patches on our MCoA webpage, if you are OK with that.

Sure, go ahead.

> The current MCoA implementation is far from matching the current specification, and breaks several things (such as the use of IPsec). It's been a long time I would like to start it again from scratch, but that's a different story :)

I'm also thinking about refactoring the MCoA patch since it would be
very nice if
we had IPsec and policy routing of traffic from the MR work as well.  We depend
on MCoA quite heavily in our projects:-)

Best,
Vilmos


> Cheers,
> romain
>
> On 2010/01/30, at 18:10, Vilmos Nebehaj wrote:
>
>> Hi there,
>>
>> due to the way the MCoA patch works BUs are always sent from one
>> interface (the one via which the first default route is in the main routing
>> table), even though the index of the CoA's interface is set via
>> IPV6_PKTINFO.  Since we use MCoA in an environment where interfaces
>> may have only intermittent connectivity this might cause BUs to be lost.
>>
>> It seems the problem is manyfold and there's no straightforward way to
>> fix this:
>> - The kernel does not use the interface index in IPV6_PKTINFO if the
>>  source address is from a different interface.
>> - The kernel code adding the destination option with the HoA simply
>>  changes the original source address (which is set to the HoA by mip6d)
>>  to the CoA set via XFRM when adding the option.  Thus if mip6d specifies
>>  the CoA as the source address via IPV6_PKTINFO this may cause
>>  problems (though it also needs proper XFRM policies first).