Date: Tue, 19 Oct 2021 16:15:54 -0500 From: Mike Karels <karels@freebsd.org> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: freebsd-net@FreeBSD.org Subject: Re: cleaning up INET: deprecating network class A/B/C Message-ID: <202110192115.19JLFsaR006625@mail.karels.net> In-Reply-To: Your message of Tue, 19 Oct 2021 08:57:00 -0700. <202110191557.19JFv0cW063587@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202110192115.19JLFsaR006625>