On 22 November 2016 at 13:35, Alexander Bluhm <alexander.bl...@gmx.net> wrote: > On Mon, Nov 21, 2016 at 10:47:34PM +0100, Mike Belopuhov wrote: >> On 21 November 2016 at 22:38, Alexandr Nedvedicky >> > The bluhm's change should not alter behavior of older code. >> Yes, it just adds something new. > > I did not try to add something new, I have preserved what was there > in pf_route(). I have moved the "if (!r->rt)" from pf_route() to > the "case PF_AFRT" in pf_test(). Now it is more obvious what is > happening and we ask ourselves "does it work?". I have not tested > it. > > The parser does not accpet the obvious thing: > pass in on net1 inet af-to inet6 from 2001:db8::1 to 2001:db8::/96 route-to > 2001:db8::1@net0 > > This might actually work: > pass in inet all flags S/SA af-to inet6 from 0.0.0.0 dup-to em0 > Although pfctl prints the from 0.0.0.0 in the wrong af. > > The parser accepts this, but I doubt that pf will create a valid > IPv6 packet with the 1.2.3.4 address. > pass in inet all flags S/SA af-to inet6 from 0.0.0.0 dup-to 1.2.3.4@em0 > > So we have a kernel implementation that might work for a feature > that makes sense. Especially the reply-to could be useful. But > the parser is too dumb. I think we should fix the parser and then > test the kernel. > > bluhm
OK, all I wanted to know was if this is know to work and if it has been tested. I'd argue that we don't put the code that doesn't work or not tested or we don't know what it does :) When af-to was devised, it wasn't meant to be compatible with route-to because they do the same thing: policy routing. I didn't think about dup-to back then, but this one makes sense to me. However dup-to is now operating on the translated packet and pfctl parser might not expect that if destination address is provided. Should it be fixed or simultaneous specification of dup-to/route-to/reply-to and af-to should be prohibited?
