From owner-freebsd-net@FreeBSD.ORG Thu May 6 15:50:03 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72F9116A4CE; Thu, 6 May 2004 15:50:03 -0700 (PDT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9477843D31; Thu, 6 May 2004 15:50:02 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from mp3 (y86xlgh7@mp3files.int.ru [195.128.64.20]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id i46Mnwu513359038; Fri, 7 May 2004 02:49:58 +0400 (MSD) Date: Fri, 7 May 2004 02:49:58 +0400 (MSD) From: Maxim Konovalov To: "David W. Chapman Jr." In-Reply-To: <20040506223545.GA61873@minubian.inethouston.net> Message-ID: <20040507023844.B96754@mp3files.int.ru> References: <200405061846.i46Ik3Jc060969@repoman.freebsd.org> <409A8EF3.5825EF0C@freebsd.org> <20040507020422.D94207@mp3files.int.ru> <20040506223545.GA61873@minubian.inethouston.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 22:50:03 -0000 On Thu, 6 May 2004, 17:35-0500, David W. Chapman Jr. wrote: > > We are using RR option all the time to track down routing asymmetry > > and traceroute is not an option, ping -R is very useful in that cases. > > We all know that ipfw (and I am sure all other *pf*) is able to > > process ip opts quite well and personally see no point in this > > sysctls. I fail to see a documentation update (inet.4 ?) as well. > > > > It is not clear for me why you ever ask for opinions after commit not > > before. Strick "nay" if you care :-) > > He hasn't changed the default yet. But I think for the select few > who actually use such tcp options, they can enable it. Most of the You mean ip options not tcp, right? I do not understant why we invent a new mechanism if we already have one. Put an example in /etc/rc.firewall. > users however will not need this. I think the point that is trying > to be made is that they want the default installation to be more > secure and those who need these features can simply turn them on. You mean "more obscure", right? Where net.inet.ip.process_options documented? How does it operate with f.e. IPSTEALTH? -- Maxim Konovalov