From owner-freebsd-current@freebsd.org Mon Nov 14 13:32:20 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 E74A6C3F3AE for ; Mon, 14 Nov 2016 13:32:20 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1j.cmail.yandex.net (forward1j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8719BBED for ; Mon, 14 Nov 2016 13:32:20 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp2o.mail.yandex.net (smtp2o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::26]) by forward1j.cmail.yandex.net (Yandex) with ESMTP id A498D20235; Mon, 14 Nov 2016 16:32:07 +0300 (MSK) Received: from smtp2o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp2o.mail.yandex.net (Yandex) with ESMTP id CF4BD50806D3; Mon, 14 Nov 2016 16:32:06 +0300 (MSK) Received: by smtp2o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id EYaG89MOkZ-W5BeHfaj; Mon, 14 Nov 2016 16:32:05 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1479130325; bh=nGgBwMNRG9Dmx4nOTuF665tc5oAcSRLbUaPPKv/EW3c=; h=Subject:To:References:Cc:From:Message-ID:Date:In-Reply-To; b=XgVt9JQau5IpDbFmKiFb77+ibYjfga1TkN2Tu21wpudvkcp8sHQKDZ/TmUCps2WPv 5VmR2zvgT3iRXW6lQHwkpRWrc+KqP0tOqMOU1rAxENmMcH7gnnQ1IBYPfY9+PGOCqv yKXdjoxVB6C0VVEr9QwVQcLjO1wIKjQD04WCxBlI= Authentication-Results: smtp2o.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: netpfil with if_output and ip(6)_output To: Franco Fichtner References: <2456B7E6-2425-4D86-A02B-33CE1EFEB608@lastsummer.de> Cc: freebsd-current From: "Andrey V. Elsukov" Message-ID: <2d59086f-5e46-03eb-1463-72db8aa422cf@yandex.ru> Date: Mon, 14 Nov 2016 16:29:23 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="66LnLchqpP8JPlW2C8DTlrjJ7oMbO07jM" 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:32:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --66LnLchqpP8JPlW2C8DTlrjJ7oMbO07jM Content-Type: multipart/mixed; boundary="lfjKNLXeR5D3ue4DQthrUfhJJLF4t1GdO"; protected-headers="v1" From: "Andrey V. Elsukov" To: Franco Fichtner Cc: freebsd-current Message-ID: <2d59086f-5e46-03eb-1463-72db8aa422cf@yandex.ru> Subject: Re: netpfil with if_output and ip(6)_output References: <2456B7E6-2425-4D86-A02B-33CE1EFEB608@lastsummer.de> In-Reply-To: --lfjKNLXeR5D3ue4DQthrUfhJJLF4t1GdO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14.11.2016 16:13, Franco Fichtner wrote: > Hi Andrey, >=20 >> On 14 Nov 2016, at 1:55 PM, Andrey V. Elsukov wrot= e: >> >> 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 handl= e >> 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); >=20 > This looks reasonable, thank you. How would we proceed with the > implementation / porting of ipfw to the new framework? >=20 >> Since I'm not quite aware how PF handles PACKET_TAG_IPFORWARD tags, yo= u >> can modify this to fully cover its needs. >=20 > Right now, it doesn't, which is the original problem: PACKET_TAG_IPFORW= ARD > 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 family. > 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. --=20 WBR, Andrey V. Elsukov --lfjKNLXeR5D3ue4DQthrUfhJJLF4t1GdO-- --66LnLchqpP8JPlW2C8DTlrjJ7oMbO07jM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEvBAEBCAAZBQJYKbwzEhxidTdjaGVyQHlhbmRleC5ydQAKCRABxeoEEMihesC8 CACUbfTK1Ie3GTy920J7VSdcGMcRjXzDBqK1XauEOT+k+0bsnOwNndhTze27Ycmw Cr3rOgMe10wzGEtaqi5SRAmYOQt9dEOCrMh3Pw7bINkjicD9pgV/h1nPYtAkmSH6 SzYKIB7/zOEOfAExcPNre5gOq8WTdNc5yni3MTlZzzSd9JZOlnTrex7CLl1DQr19 WKS7F/5wUgiQEJ+60QMqZ5kNYxN/+zt5ikxoy+sDcjGclgulpoJ123IJTG8RvPdK EX5w7CNyoxdOg4r2vct+km17TnIbVJWSMraJ3ohtcfTxwcPCJZ9ZbVmU4XahHhPI O3w1HKKzuLaigfTIZnh9M3k3 =7C3E -----END PGP SIGNATURE----- --66LnLchqpP8JPlW2C8DTlrjJ7oMbO07jM--