From nobody Wed Nov 10 16:38:56 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 B535A184B845; Wed, 10 Nov 2021 16:39:00 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (glebi.us [162.251.186.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Hq9Xh34dsz3P5D; Wed, 10 Nov 2021 16:39:00 +0000 (UTC) (envelope-from glebius@freebsd.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.16.1/8.16.1) with ESMTPS id 1AAGcwQG089091 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 10 Nov 2021 08:38:58 -0800 (PST) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.glebi.us (8.16.1/8.16.1/Submit) id 1AAGcv1i089090; Wed, 10 Nov 2021 08:38:57 -0800 (PST) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@freebsd.org using -f Date: Wed, 10 Nov 2021 08:38:56 -0800 From: Gleb Smirnoff To: Mike Karels Cc: 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 Message-ID: References: <202111101536.1AAFa311018767@mail.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=us-ascii Content-Disposition: inline In-Reply-To: <202111101536.1AAFa311018767@mail.karels.net> X-Rspamd-Queue-Id: 4Hq9Xh34dsz3P5D X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N 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