Re: cleaning up INET: deprecating network class A/B/C

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