No subject

>> =C2=A0viewpoint it would be more fortunate to pass the HoA instead, but =
this
>> =C2=A0requires a change in the XFRM data structure used to pass data bet=
ween
>> =C2=A0user- and kernel space.
>> - If we pass the destination option as ancillary data when sending the
>> =C2=A0mobility header, and set the source address to the CoA then the ch=
ecksum
>> =C2=A0is not correct since in raw.c rawv6_push_pending_frames() uses the=
 passed
>> =C2=A0source to compute the checksum, but the HoA should be used instead=
. =C2=A0The
>> =C2=A0HA will drop these packets (unless checksum verification is disabl=
ed by
>> =C2=A0mip6d, but this is not an acceptable solution, since it will very =
likely cause
>> =C2=A0interoperability 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 mip=
6d.
>> - In the kernel we check for the destination option and use the HoA from=
 the
>> =C2=A0option as the source address to compute the checksum.
>>
>> On the long run I think it would be more fortunate to pass the HoA via X=
FRM,
>> and mip6.c would only add this to the destination option without swappin=
g
>> the source address with the CoA, thus the kernel could keep adding this =
to
>> the header. =C2=A0This 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
>
>