[support] MCoA send BUs via multiple interfaces

[Vilmos Nebehaj]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcoa_bu_kernel.diff
Type: application/octet-stream
Size: 1346 bytes
Desc: not available
Url : http://ml.nautilus6.org/pipermail/support/attachments/20100130/4f3d8c2f/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mcoa_bu_mip6d.diff
Type: application/octet-stream
Size: 5032 bytes
Desc: not available
Url : http://ml.nautilus6.org/pipermail/support/attachments/20100130/4f3d8c2f/attachment-0001.obj