> 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.
This is a regression in FreeBSD. Case in point:
x230a.dnsmgr.net:root {1003}# route -n get 127.1.1.1
route to: 127.1.1.1
destination: 0.0.0.0
mask: 0.0.0.0
gateway: 192.168.32.8
fib: 0
interface: em0
flags:
recvpipe sendpipe ssthresh rtt,msecmtuweightexpire
So if I try to send packets to 127.1.1.1 they are going to attempt
to go out em0, simply WRONG as the netmask on lo0 CLEARLY states
they should be via that interface:
x230a.dnsmgr.net:root {1004}# ifconfig lo0
lo0: flags=8049 metric 0 mtu 16384
options=680003
inet 127.0.0.1 netmask 0xff00
ping 127.1.1.1
PING 127.1.1.1 (127.1.1.1): 56 data bytes
ping: sendto: Can't assign requested address
this should actually be silent with no response
I would say that FreeBSD is broken here with respect to the
loss of the 127.0.0.0/8 via lo0 route.
>
> > 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.
This is P2P implementation dependent, iirc both ppp and tun and slip
all use to need a /30 and packets sent to the 0 host was discarded,
and packets sent to the broadcast address was sent to the far end.
Your only looking at current FreeBSD behavior, and I would suggest
that a larger sweep be made in the name of interoperability. Also
your forcing a POLICY and not simply providing a METHOD. If I want
to run a /24 on a p2p link I should be allowed to.
>
> > > 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.
Can you point specifically at this code so I can get a better
understanding of what it is doing? I dont use BOOTP,
I use iPXE so I am unfamiliar with this code.
>
> > > 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
> > >
