From owner-freebsd-current@freebsd.org Mon Nov 14 13:13:30 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0AA5C3DCE2 for ; Mon, 14 Nov 2016 13:13:30 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (unknown [IPv6:2a01:4f8:a0:51d6::108:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6BA091E17 for ; Mon, 14 Nov 2016 13:13:30 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from francos-mbp.homeoffice.local (ipservice-092-217-062-255.092.217.pools.vodafone-ip.de [92.217.62.255]) by host64.shmhost.net (Postfix) with ESMTPSA id 3A69883C26; Mon, 14 Nov 2016 14:13:21 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: netpfil with if_output and ip(6)_output From: Franco Fichtner In-Reply-To: Date: Mon, 14 Nov 2016 14:13:20 +0100 Cc: freebsd-current Content-Transfer-Encoding: 7bit Message-Id: References: <2456B7E6-2425-4D86-A02B-33CE1EFEB608@lastsummer.de> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.3251) X-Virus-Scanned: clamav-milter 0.99.2 at host64.shmhost.net X-Virus-Status: Clean X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2016 13:13:30 -0000 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 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). ipfw only requires the forwarding address, pf will want to select the outgoing interface in the same step so the KPI already covers that. 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? 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? Cheers, Franco