[support] MCoA send BUs via multiple interfaces

[Romain KUNTZ]

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.

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

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