Date: Sat, 23 Oct 2021 09:57: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: <202110231457.19NEvsmc023436@mail.karels.net> In-Reply-To: Your message of Fri, 22 Oct 2021 08:49:16 -0700. <202110221549.19MFnG85075680@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 sin=
ce
> > > > CIDR took hold. This is an outline of what I plan, as it will hap=
pen
> > > > in a number of steps and reviews, and I would like feedback on som=
e
> > > > of it.
> > > > =
> > > > I want to reduce the use of the obsolete definitions and interface=
s,
> > > > 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 macr=
o
> > > > 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 mac=
ro
> > > > 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 th=
is;
> > > > 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 addres=
s
> > is set. I think it's similar for point-to-point interfaces, where onl=
y
> > 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: <UP,GATEWAY,DONE,STATIC>
> recvpipe sendpipe ssthresh rtt,msec mtu weight expire
> 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=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> options=3D680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
> inet 127.0.0.1 netmask 0xff000000
Routes do not use the netmask on interface addresses, but only on the rout=
e.
The only address that is reachable via lo0 is what is configured. Long ag=
o,
I remember driving a Sun workstation to its knees by doing "ping 127.0.0.2=
",
which it would "send" via the loopback, receive it, then try to forward
until hit the hop limit. That inspired the change in the route.
I haven't done the archaeology, but I believe the change from net route
to host route was in 4.3BSD (1986). Similarly for point to point: there
are only host routes to the remote and local addresses (the latter via
the loopback).
> 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....
Ideally, there would be a reject route to the loopback "net" that would
cause 127.1.1.1 to be unreachable. But you see why there are "Martian"
filters that refuse to forward packets to the "loopback".
> I would say that FreeBSD is broken here with respect to the
> loss of the 127.0.0.0/8 via lo0 route.
If it is broken, I think it has always been broken.
> > =
> > > 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.
I'm not so sure about this; I didn't think slip or ppp had any idea of
broadcast or a zero host. But it doesn't affect the current discussion
(see below).
> 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'm not proposing any change in policy. If some links require a specific
mask, they should be configured with it. With the change I'm proposing,
the default would change from 8/16/24 bits depending on class to 24 bits
in any default case.
> > =
> > > > 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 talk=
ing
> > 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 ret=
urn
> > 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.
It's src/sys/nfs/bootp_subr.c. I don't know the circumstances in which
it is used (e.g. whether it is used with DHCP for diskless boot).
> > =
> > > > 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 use=
s
> > > > 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?
> It is a build of all the ports with a some modification applied, like
> your patch, so that a change can be tested for impact on ports.
There are enough references in the base system that I think I'll just
mark the routines deprecated in the man page and in comments in the
header. Some of the base system is not worth changing (e.g. rarp).
Mike
> > =
> > > I do believe Linux still defines the CLASS macros.
> > =
> > It does. There are a surprising number of references even in base.
> And I believe there is a large mass in ports as well. Last time
> I thought about killing the class macros a quick servey lead me
> to believe it would break a huge amount of software.
> I do believe with the work John Gilmore is trying to get
> done on opening up some of the "reserved" IP space could
> lead to considerable effort by all OS and software vendors
> to clean this up, but it is not going to be quick or easy.
> > Mike
> -- =
> Rod Grimes rgrimes@freeb=
sd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202110231457.19NEvsmc023436>