[support] MCoA send BUs via multiple interfaces

[Romain KUNTZ]

Hi Vilmos,

On 2010/02/05, at 11:03, Vilmos Nebehaj wrote:
>> 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.

Thanks, I've added them to the MCoA documentation. 

>> 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:-)

You may have interest in reading this paper, which describes the current MCoA design:
http://www.rkuntz.org/pub/papers/20061128-AINTEC-NEMO-MCoA-KuntzR-LorchatJ.pdf

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).  From an MCoA
>>>  viewpoint it would be more fortunate to pass the HoA instead, but this
>>>  requires a change in the XFRM data structure used to pass data between
>>>  user- and kernel space.
>>> - If we pass the destination option as ancillary data when sending the
>>>  mobility header, and set the source address to the CoA then the checksum
>>>  is not correct since in raw.c rawv6_push_pending_frames() uses the passed
>>>  source to compute the checksum, but the HoA should be used instead.  The
>>>  HA will drop these packets (unless checksum verification is disabled by
>>>  mip6d, but this is not an acceptable solution, since it will very likely cause
>>>  interoperability problems).
>>> 
>>> In the attached patch(es) to solve the issue we took the least offensive path:
>>> - Mip6d sets the source address to the CoA when sending BUs.
>>> - The destination option is added as ancillary data via sendmsg() in mip6d.
>>> - In the kernel we check for the destination option and use the HoA from the
>>>  option as the source address to compute the checksum.
>>> 
>>> On the long run I think it would be more fortunate to pass the HoA via XFRM,
>>> and mip6.c would only add this to the destination option without swapping
>>> the source address with the CoA, thus the kernel could keep adding this to
>>> the header.  This would also need proper XFRM policies to be set up by
>>> mip6d.
>>> 
>>> Introducing a separate case for MIP6 checksumming in raw.c is a bit ugly, but
>>> I was a little hesitant where to change flowi->src; it seems it should
>>> be done in
>>> raw.c anyway.
>>> 
>>> Regards,
>>> Vilmos
>>> <mcoa_bu_kernel.diff><mcoa_bu_mip6d.diff>_______________________________________________
>>> Support mailing list
>>> Support at ml.nautilus6.org
>>> http://ml.nautilus6.org/mailman/listinfo/support
>> 
>> 
>