Hi Ville, On Wed, Aug 02, 2006 at 10:58:49AM +0300, Ville Nuorvala wrote: > To name just one issue: the chicken and egg problem of source address > selection and source address based routing. I solved this problem by > letting policy rules (with a source prefix) add additional constraints > to the address selection. This did however mean the source address > selection had to be moved inside the routing code.
To tell you the truth i don't know what MIPL does in terms of policy
management. In my implementation, all routing policies go into
Subtrees without any kind of extra routing tables. I also had the
problem you describe, but i opted for what i think is a simpler
solution:
- Access router default routes are installed with a source-address,
the address that was generated from the announced prefix (which to
be fair degenerates to several entries if a single router announces
multiple prefixes). This is based on the assumption that access
routers do perform source-based ingress filtering so you may only
use a particular access router for global connectivity using a
particular address.
- The default home route is installed without a source-address for
the "default" Home address (i may have several).
This means Linux's source address selection works without
modifications: if no address is specified, it will pick the default
home route and then the Home address (which has a preference as well).
In this sense, subtrees have worked fine for me.
> But route optimization is just one form of packet transform; it just
> adds a Routing Header type 2 and/or Home Address Option Destination
> Header to the outgoing packet. Isn't xfrm just the right place for this?
>
> You are right that we (HUT and USAGI) have mostly just looked at the
> xfrm framework from a MIPv6+IPsec perspective, but even this has helped
> us pinpoint several shortcomings in the current only IPsec specific
> framework.
XFRM is indeed the right place for this; i just would rather not have
the mode exposed and prefer wrapping any mode-specific stuff into
optional callbacks. It might not be as performant but would allow
adding new modes more easily.
Hugo
signature.asc
Description: Digital signature
