On 14.11.2016 16:13, Franco Fichtner wrote:
> Hi Andrey,
>> On 14 Nov 2016, at 1:55 PM, Andrey V. Elsukov <bu7c...@yandex.ru> 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 in all *proto*_output() routines.
>> For first glance I can propose the following:
>> /* ip_var.h */
>> #define      IP_HAS_NEXTHOP(m)       ((m)->m_flags & M_IP_NEXTHOP)
>> int ip_set_fwdtag(struct mbuf *m, struct sockaddr_in *dst,
>>    u_short ifidx);
>> int ip_get_fwdtag(struct mbuf *m, struct sockaddr_in *dst,
>>    u_short *ifidx);
>> void ip_flush_fwdtag(struct mbuf *m);
>> /* ip6_var.h */
>> #define      IP6_HAS_NEXTHOP(m)      ((m)->m_flags & M_IP6_NEXTHOP)
>> int ip6_set_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst,
>>    u_short ifidx);
>> int ip6_get_fwdtag(struct mbuf *m, struct sockaddr_in6 *dst,
>>    u_short *ifidx);
>> 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 framework?
>> Since I'm not quite aware how PF handles PACKET_TAG_IPFORWARD tags, you
>> can modify this to fully cover its needs.
> Right now, it doesn't, which is the original problem: PACKET_TAG_IPFORWARD
> aligns well with netpfil, now we only need pf to do the same (and
> maybe the new ipfw net64 code at some point as well).

nat64 does direct if_output only when undocumented
IPFIREWALL_NAT64_DIRECT_OUTPUT option was used. In other cases (by
default) translated packet will be scheduled via netisr.

Also, do not forget that we have special handling for fwd_tags in
udp/tcp output path.

> ipfw only requires the forwarding address, pf will want to select
> the outgoing interface in the same step so the KPI already covers
> that.

Yes, we get both ifindex and destination address from one call.
In future ipfw(4) also can be extended to use ifindex.

> As a note, set_fwdtag will have to be able to (safely) rewrite the
> internal structure, in case one filter overwrites the decision of
> the other, or we call flush + set again?

In my meaning it should remove old tag and set new one. This can be
optimized for cases when we have tag with nexthop for the same address

> Another small oddity is the flipping of M_FASTFWD_OURS which is
> write only for forwarding, but overwriting with another all requires
> to unset it.  Should M_FASTFWD_OURS set/unset be part of the KBI as
> well?

It looks like M_FASTWFD_OURS also can be covered by this KPI.

WBR, Andrey V. Elsukov

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to