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
