From nobody Tue Oct 19 21:15:54 2021 X-Original-To: freebsd-net@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 0FA361817506 for ; Tue, 19 Oct 2021 21:15:57 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4HYmkM61Mjz3JTy for ; Tue, 19 Oct 2021 21:15:55 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 19JLFsPB006626 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 19 Oct 2021 16:15:54 -0500 (CDT) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 19JLFsaR006625; Tue, 19 Oct 2021 16:15:54 -0500 (CDT) (envelope-from mike) Message-Id: <202110192115.19JLFsaR006625@mail.karels.net> To: "Rodney W. Grimes" cc: freebsd-net@FreeBSD.org From: Mike Karels Reply-to: karels@freebsd.org Subject: Re: cleaning up INET: deprecating network class A/B/C In-reply-to: Your message of Tue, 19 Oct 2021 08:57:00 -0700. <202110191557.19JFv0cW063587@gndrsh.dnsmgr.net> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6623.1634678154.1@mail.karels.net> Date: Tue, 19 Oct 2021 16:15:54 -0500 X-Rspamd-Queue-Id: 4HYmkM61Mjz3JTy X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [-1.37 / 15.00]; HAS_REPLYTO(0.00)[karels@freebsd.org]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.70)[-0.704]; NEURAL_HAM_LONG(-1.00)[-0.999]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.968]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[karels@freebsd.org,mike@mail.karels.net]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[karels@freebsd.org,mike@mail.karels.net]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Rod wrote: > > I plan to do some cleanup of the residual code defining and using the > > old Internet network classes (A/B/C), which have been obsolete since > > CIDR took hold. This is an outline of what I plan, as it will happen > > in a number of steps and reviews, and I would like feedback on some > > of it. > > > > I want to reduce the use of the obsolete definitions and interfaces, > > and make it less likely for them to be used going forward. I plan > > to hide the Class A/B/C bit definitions unless a feature test macro > > is defined; that will be the default for user code for the moment. > > A few files in the kernel will need to define the feature test macro > > for now (but see the next two paragraphs). > Sounds good. > > > > Several of the uses of the historical network class macros have to > > do with generating a default network mask when none is provided. > > The worst of these is in the code for SIOCAIFADDR (add interface > > address). I want to have ifconfig and/or the kernel warn about this; > > the default is most likely wrong. After some time with a warning, > > it should become an error to set an Internet interface address > > without a mask (except for loopback and point-to-point interfaces, > > where the mask is meaningless). > Sounds good except that last bit, mask on loopback is > meaningful, especially for people like me that alrady > have modified systems that change loopback from 127/8 > to 127/16. I'm not aware of anything that uses the mask on a loopback interface; are you? There is no network route installed when the loopback address is set. I think it's similar for point-to-point interfaces, where only the host route for the destination is added. > Also care should be taken on point to point, > I think there is probably a fair bit of code/systems > out there that MAY still assume /30 or require /30 to > be set on these, it MAY be an interropt issue to force > the FreeBSD end to /32. Where is the mask ever used on a point-to-point interface? There is no broadcast address. However, my changes wouldn't break anything that isn't already broken. > > I am tempted to define a new default mask, e.g. 24 bits, for those > > places that must be able to generate one. An example is NFS BOOTP > > code. I am interested in feedback on this idea. It would help to > > reduce use of the old masks, and 8- or 16-bit prefixes are highly > > unlikely to be correct. Comments on adding a default mask? This > > would eliminate the use of the old class macros in the kernel. > I am not keen on the idea of a default mask at all. I believe > every place that an IP address -is- used also has the ability > to specify a netmask. The cases that I'm talking about, like the NFS BOOTP code, have two choices: use a default, or fail (to boot, in this case). I'm not talking about adding a default anywhere, just changing it to ignore the "class" of the address. This would also be true when setting a local address with ifconfig, but that would only be temporary until it starts to return an error. > > The C library routines inet_netof() and inet_lnaof() should be > > deprecated, as they use the historical masks. inet_makeaddr() is > > almost as bad; it works almost by accident as long as a mask is a > > multiple of 8 bits. I'd like to remove their use from the base > > system. Unfortunately, I have no idea how much other software uses > > them. We can at least document them as deprecated and unsafe. > Wrap them in a depricating macro, the do a EXP-RUN with that macro > defined, should get a good idea of that fallout from that. EXP-RUN? > I do believe Linux still defines the CLASS macros. It does. There are a surprising number of references even in base. Mike