From nobody Thu Nov 11 14:12:53 2021 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9FF6817ED02D; Thu, 11 Nov 2021 14:13:02 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) (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 4HqkFp1Hw5z4pxB; Thu, 11 Nov 2021 14:13:02 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: (Authenticated sender: gnn@neville-neil.com) by relay12.mail.gandi.net (Postfix) with ESMTPSA id ABC71200004; Thu, 11 Nov 2021 14:12:56 +0000 (UTC) From: George Neville-Neil To: Mike Karels Cc: Gleb Smirnoff , src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 20d59403961d - main - kernel: deprecate Internet Class A/B/C Date: Thu, 11 Nov 2021 09:12:53 -0500 X-Mailer: MailMate (1.14r5831) Message-ID: In-Reply-To: <90C05BCC-D4B6-43F9-95B1-D072EBA3703A@karels.net> References: <202111101536.1AAFa311018767@mail.karels.net> <90C05BCC-D4B6-43F9-95B1-D072EBA3703A@karels.net> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HqkFp1Hw5z4pxB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N I actually think that this is a reasonable solution. Best, George On 10 Nov 2021, at 17:26, Mike Karels wrote: > I’m going to top-post my reply to highlight this question: > It is proposed to revert the change to the default mask when setting > an Internet interface address without a mask, returning to the use of > the Class A/B/C mask as the default. We would still warn if there > was no mask supplied, except on loopback and point-to-point interfaces. > > Does anyone object, or otherwise have comments? > > Mike > > On 10 Nov 2021, at 10:38, Gleb Smirnoff wrote: > >> On Wed, Nov 10, 2021 at 09:36:03AM -0600, Mike Karels wrote: >> M> > The new /24 default is no better than classes. The only difference >> M> > that classes maintained POLA and new default doesn't. For example, >> M> > in my home network I have default router 10.0.0.1 and since it is >> M> > class A network on my VMs and test boxes I can type >> M> >> M> > # ifconfig vtnet0 10.6.6.6 >> M> >> M> > and that is going to work. With this change no longer. >> M> >> M> I suspect that /8 is by far the minority these days, even with a >> M> "Class A" net. I also use net 10 at home, and at the last several jobs, >> M> but it is subnetted in each case. I would peridically add an address, >> M> forgetting a mask, only to find that a route for 10/8 isolated the machine. >> >> The 10/8 can be used at home as a huge personal address space, just like >> a /64 IPv6 prefix. All addresses added without masks and everything works. >> >> M> That said, my main objective was to deprecate usage without a mask, and >> M> to warn in that case. Both the kernel and ifconfig now warn when a default >> M> mask is used. In the discussion on freebsd-net and in the review, the >> M> main thought was that masks should be required. But it isn't practical to >> M> fail and return an error with no mask, at least not without a significant >> M> period with warnings, or some systems would stop coming up on the network. >> M> >> M> One reviewer was going to comment on the /24 default, but thought it was >> M> better than the previous. I'm open to hearing more opinions. >> >> Although I don't internally agree that we really need to police people to >> always specify masks, I would make step forward and agree with that. So, >> let's do print loud warning on every attempt to set IP address without a >> mask. But I can not agree that change from class based guess to /24 is a >> right thing to do. A proper deprecation process goes like this: >> >> Step 1: Print warning, don't change legacy behavior. >> <... people adopt ...> >> Step 2: Return error. Remove deprecated behavior. >> >> What we did is that we changed behavior together with warning. The new >> behavior is neither the legacy one nor the desired one, where mask is >> a must. Look from a user perspective: for class C nothing changed, but >> changed for A and B. >> >> -- >> Gleb Smirnoff