Subject: Re: Summer of Code: Policy routing / Implement IPv6 ipflow_fastforward
To: NetBSD Network Mailing List <tech-net@NetBSD.org>
From: David Young <dyoung@pobox.com>
List: tech-net
Date: 06/18/2005 01:11:45
On Fri, Jun 17, 2005 at 10:02:15AM +0200, Ivo Vachkov wrote:
> On 6/17/05, Miles Nordin <carton@ivy.net> wrote:
> > >>>>> "iv" == Ivo Vachkov <ivo.vachkov@gmail.com> writes:
> >
> >     iv> Policy Routing: - extend "struct rtentry" to include
> >     iv> additional information for TOS fields, Source based routing,
> >     iv> maybe even protocol based routing, ttl routing, packet lenght
> >     iv> routing - add support in /sys/net/route.c - add support in
> >     iv> /sbin/route/route.c and alike
> >
> > another way to do this would be to fix the policy routing that's been
> > built into the firewalls for a long time.  ipfilter and PF both have
> > fastroute/route-to and dup-to keywords.  PF also has a
> > reply-to/keepstate keyword for strong ES.  However in both ipfilter
> > and PF these keywords panic the kernel if you try to use them.
> 
> I used that features before on other OSs (FreeBSD and OpenBSD) and it
> seemed to me that they worked (at least partly), but I don't like the
> idea of having all packet processing (... and routing) done in a piece
> of code that should work as a firewall.
> 
> > It would maybe be nicer to have some policy routing in the routing
> > table---sometimes it's more intuitive, it has to go there if you want
> > to use rtsock, and it's probably easier to do that than fix the
> > firewalls.  But the keywords are already _in_ the firewalls so
> > some day they should probably be fixed or removed.
> 
> My plan is to add policy routing to the base system, kernel routing
> table and co. but i may try to fix this issues to if i have time to
> the end of the summer. I've already had some knowledge of the PF code,
> but i don't promise anything :)
> 
> > In addition to policy routing people often ask for multipath routing.
> > A fully-general multipath routing that used byte counters to keep the
> > use of each path even would be nice, and I don't think other Unixes
> > have that yet. :)
> 
> This subject crossed my mind too. But it's a little bit harder to
> implement. I'm aware of an old patch (for FreeBSD 4.8) that does
> implement multipath, so I may try to use it too.

> And this leads us to
> the next question - how should the multipath be organized - on a
> packet or connection basis ???

Ivo,

I doubt whether either basis will suffice for all applications.
RFC 2991[1] describes some problems with "round-robin"[2] multipath
forwarding. The RFC recommends that packets for the same "flow"[3]
should follow the same path.

BTW, RFC 2991 informs the implementation of multipath forwarding in the
RADIX_MPATH patches from KAME.net---the multipath patches you refer to
above are probably the RADIX_MPATH patches.

Dave

[1] http://www.ietf.org/rfc/rfc2991.txt
[2] I imagine "round-robin" is roughly what you meant by "packet basis."
[3] Likewise, "connection basis" stood roughly for "flow."

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933