Date: Wed, 14 Jun 2017 19:27:29 -0500 From: "Mike Karels" <mike@karels.net> To: "John Jasen" <jjasen@gmail.com> Cc: "FreeBSD Net" <freebsd-net@freebsd.org> Subject: Re: state of packet forwarding in FreeBSD? Message-ID: <C7ADE52F-C7E9-415C-AD9C-DCFBEB43EED7@karels.net> In-Reply-To: <CAACLuR17yRETErqsxbdhBPJrjQur0oMVOqvL5ZCkmjLCKkHLNA@mail.gmail.com> References: <CAACLuR17yRETErqsxbdhBPJrjQur0oMVOqvL5ZCkmjLCKkHLNA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Responding to the thread as a whole: another alternative is the FLOWTABLE kernel option. I added route and link-layer caching for endpoints (TCP a= nd UDP), which makes the FLOWTABLE option less useful (or undesirable) there= , but FLOWTABLE adds route caching for packet forwarding as well. I=E2=80=99= d suggest testing that also. Mike From owner-freebsd-net@freebsd.org Thu Jun 15 02:09:09 2017 Return-Path: <owner-freebsd-net@freebsd.org> Delivered-To: freebsd-net@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 C69CCBFB571 for <freebsd-net@mailman.ysv.freebsd.org>; Thu, 15 Jun 2017 02:09:09 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (wollman-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:ccb::2]) (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 89690823DF for <freebsd-net@freebsd.org>; Thu, 15 Jun 2017 02:09:09 +0000 (UTC) (envelope-from wollman@hergotha.csail.mit.edu) Received: from hergotha.csail.mit.edu (localhost [127.0.0.1]) by hergotha.csail.mit.edu (8.15.2/8.15.2) with ESMTP id v5F297JV048084; Wed, 14 Jun 2017 22:09:07 -0400 (EDT) (envelope-from wollman@hergotha.csail.mit.edu) Received: (from wollman@localhost) by hergotha.csail.mit.edu (8.15.2/8.14.4/Submit) id v5F297tx048083; Wed, 14 Jun 2017 22:09:07 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22849.60482.848811.80144@hergotha.csail.mit.edu> Date: Wed, 14 Jun 2017 22:09:06 -0400 From: Garrett Wollman <wollman@bimajority.org> To: Rui Paulo <rpaulo@me.com> Cc: freebsd-net@freebsd.org Subject: Re: Enable IPv6 Privacy Extensions by default In-Reply-To: <1497417261.2220.5.camel@me.com> References: <20170611215904.4612ee41@kalimero.tijl.coosemans.org> <D05BDD5A-F7ED-4DFE-8835-DE444A12C771@lists.zabbadoz.net> <20170612131912.42537b13@kalimero.tijl.coosemans.org> <1497408664.2220.3.camel@me.com> <201706140257.v5E2vRDE029173@hergotha.csail.mit.edu> <1497417261.2220.5.camel@me.com> X-Mailer: VM 8.2.0b under 25.1.1 (amd64-portbld-freebsd10.3) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (hergotha.csail.mit.edu [127.0.0.1]); Wed, 14 Jun 2017 22:09:07 -0400 (EDT) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, HEADER_FROM_DIFFERENT_DOMAINS autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hergotha.csail.mit.edu X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/>; List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 15 Jun 2017 02:09:09 -0000 <<On Tue, 13 Jun 2017 22:14:21 -0700, Rui Paulo <rpaulo@me.com> said: > Pretty sure these problems have been addressed by now, given the amount > of computers, smart phones, tablets, etc. running with privacy > extensions enabled. They've been "fixed" mostly by hiding big networks behind NATs and leaving them IPv4-only. And in some enterprises by implementing DHCPv6. (We haven't done the latter but expect to if I can ever get the time.) There have been no fixes to the NDP or MLD protocols that would make "privacy" addresses as specified safe to use in large networks, and it's highly unlikely that there ever will be, given that fixing the protocols would set back IPv6 adoption even further. When I first ran into this, people seriously said things to me like "duh, obviously every office in your building should have its own separate /64". I kid you not. That was the recommended "solution": broadcast domains with two or three machines on them. That's fine for your home network hanging off a cable modem, not OK for an office building with a thousand people and twice that many computers in it. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C7ADE52F-C7E9-415C-AD9C-DCFBEB43EED7>