[support] About other possible patch for MCoA in the near future?

[Romain KUNTZ]

Hello,

On 2009/06/26, at 12:29, Angel Bartomeu Bonillo wrote:
> Lately I see that new patches are comming up fixing some of the bugs/ 
> limitations that the MIPv6 implementation used to have.

The latest MCoA patches were just an update of the patch so that it  
can apply to the latest NEPL patches, no features have been added.

> One of the limitations that have not been fixed yet is that the  
> traffic policies are only applicable to the forwarding traffic so  
> the localy generated traffic cannot benefit from the use of MCoA.
> Will this issue be fixed in the near future? If not, do you think it  
> would be very difficult to fix it myself? I mean, will I need to  
> change too many things?

I don't have any plan to work on the MCoA implementation in the near  
future, so I'm afraid that such feature won't be available unless  
someone else takes care of it.

Before going further in the details, let me explain in short how  
traffic policies work with the current implementation :
- packets are marked with the netfilter rules installed by the user,
- for each forwared packet, a lookup in the routing policy database  
(RPDB) gives the routing table to lookup,
- the lookup in that routing table gives the output tunnel,
- the tunnel interface gives the source and dst address of the outer  
header

The last time I checked (on kernels < 2.6.20), policies for locally  
generated traffic were tricky to handle because (if I remember  
correctly), the netfilter lookup is done after the routing decision  
for the locally generated traffic. However, kernels > 2.6.20 seem to  
have an extra lookup (called "ip6_route_me_harder()") after going  
through the netfilter OUTPUT chain. I didn't have a chance to test it  
though, but this could lead to some source address selection issue.

Another issue with the current solution is that it does not work for  
the traffic that transit in the IPsec tunnel, because in such case  
packets are first transformed with XFRM (where source and dst of the  
tunnel endpoints are chosen) then the lookup in the RPDB and routing  
table are performed to get the next hop.

So with the current design, the output interface may be chosen  
correctly, but the source address of the outer header will in most  
case be wrong. I tried to find a solution that could solve both issues  
(policies for locally generated traffic and/or for IPsec traffic), and  
one solution I found implied to redesign completely the MCoA  
implementation and even redesign the tunneling mechanism currently  
used. I'll give the details below.

First, "tunneling" would be done with XFRM instead of using the  
current virtual tunnel interface: the XFRM framework would take care  
of adding the extra IPv6 header to the outgoing packets. Then, UMIP  
would install the proper XFRM policies and states that have the BID  
info AND the correct source address associated to that BID. When the  
XFRM policy lookup is done for each local or forwarded packet, the  
packet mark would be lookuped, then the correct XFRM policy would be  
chosen, and transformation would be operated by adding the outer IPv6  
header with the correct source address.

This is however a pretty big change in the implementation. Not  
mentioning the fact that using XFRM for IP/IP encapsulation would  
certainly raise some objections because the "normal" way to do it is  
by using ip6tnl interfaces (but I think using XFRM for such purpose  
would certainly improve performances - and it would also simplify  
implementations of other protocols such as DSMIP, but that's another  
story).

The above was just an idea, I couldn't have a chance to test if this  
is really feasible.

As a side note, I'd like to point out that the current MCoA  
implementation is not compliant with the latest MCoA draft, a lot of  
new features have been added in the specification since then (such as  
the bulk registration, the usage of the home and foreign link at the  
same time, ...).

Cheers,
romain