Re: netpfil with if_output and ip(6)_output

Hi all, > On 14 Nov 2016, at 1:55 PM, Andrey V. Elsukov wrote: > > I have some thought related to your proposal. > What you think if we will introduce new KPI to work with fwd_tags? > With such KPI we can make fwd_tags opaque for PFIL consumers and handle > tags identically

Re: netpfil with if_output and ip(6)_output

> On 14 Nov 2016, at 2:36 PM, Andrey V. Elsukov wrote: > > On 14.11.2016 16:13, Franco Fichtner wrote: >>> void ip6_flush_fwdtag(struct mbuf *m); >> >> This looks reasonable, thank you. How would we proceed with the >> implementation / porting of ipfw to the new

Re: netpfil with if_output and ip(6)_output

On 14.11.2016 16:13, Franco Fichtner wrote: > Hi Andrey, > >> On 14 Nov 2016, at 1:55 PM, Andrey V. Elsukov wrote: >> >> I have some thought related to your proposal. >> What you think if we will introduce new KPI to work with fwd_tags? >> With such KPI we can make fwd_tags

Re: netpfil with if_output and ip(6)_output

Hi Andrey, > On 14 Nov 2016, at 1:55 PM, Andrey V. Elsukov wrote: > > I have some thought related to your proposal. > What you think if we will introduce new KPI to work with fwd_tags? > With such KPI we can make fwd_tags opaque for PFIL consumers and handle > tags

Re: netpfil with if_output and ip(6)_output

On 14.11.2016 15:24, Franco Fichtner wrote: > I've opened a review to start removal of if_output from the > pf code with a conservative first batch, which would eventually > enable ipfw and pf redirect packets using the same PACKET_TAG_IPFORWARD > mechanism. It was met with multiple opinions, but

netpfil with if_output and ip(6)_output

Hi current, There is a growing concern over usability of netpfil with several premature exits out of the framework that would seem to try to provide consistent policy enforcement on traffic, namely: if_output: called by pf route-to type tags, in 12-CURRENT also from ipfw nat64 -- if_output in