From owner-svn-src-head@FreeBSD.ORG Mon Apr 6 10:39:44 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B01E10656D4; Mon, 6 Apr 2009 10:39:44 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 64F048FC1C; Mon, 6 Apr 2009 10:39:42 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 239444378; Mon, 06 Apr 2009 13:39:42 +0300 Message-ID: <49D9DBED.6050805@FreeBSD.org> Date: Mon, 06 Apr 2009 13:39:41 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Randall Stewart References: <200904061009.n36A9K6l063517@svn.freebsd.org> In-Reply-To: <200904061009.n36A9K6l063517@svn.freebsd.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r190758 - head/sbin/route X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 10:39:44 -0000 Randall Stewart wrote: > Author: rrs > Date: Mon Apr 6 10:09:20 2009 > New Revision: 190758 > URL: http://svn.freebsd.org/changeset/base/190758 > > Log: > Class based addressing went out in the early 90's. Basically > if a entry is not route add -net xxx/bits then we should use > the addr (xxx) to establish the number of bits by looking at > the first non-zero bit. So if we enter > route add -net 10.1.1.0 10.1.3.5 > this is the same as doing > route add -net 10.1.1.0/24 > Since the 8th bit (zero counting) is set to 1 we set bits > to 32-8. > > Users can of course still use the /x to change this behavior > or in cases where the network is in the trailing part > of the address, a "netmask" argument can be supplied to > override what is established from the interpretation of the > address itself. e.g: > > route add -net 10.1.1.8 -netmask 0xff00ffff > > should overide and place the proper CIDR mask in place. > > PR: 131365 > MFC after: 1 week Are you sure that this is a good idea? Is this behavior described/recommended somewhere? IMHO specifying network without explicitly defined netmask is at least dangerous, if not wrong, in present classless addressing time. Changing existing behavior breaks POLA for some set of users, while benefits are not so obvious to me. With previous code networks 10.0.0.0 and 11.0.0.0 were treated as /8, but with this change it became /7 and /8 respectively. Author of the PR referred here expects network 192.168 to be treated as /16, but with your algorithm it will probably become /13. -- Alexander Motin