From nobody Sat Oct 23 14:57:54 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AB363181CE38 for ; Sat, 23 Oct 2021 14:57:57 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4Hc48N0bjhz3Cxr for ; Sat, 23 Oct 2021 14:57:55 +0000 (UTC) (envelope-from mike@mail.karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTPS id 19NEvtoL023437 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 23 Oct 2021 09:57:55 -0500 (CDT) (envelope-from mike@mail.karels.net) Received: (from mike@localhost) by mail.karels.net (8.16.1/8.16.1/Submit) id 19NEvsmc023436; Sat, 23 Oct 2021 09:57:54 -0500 (CDT) (envelope-from mike) Message-Id: <202110231457.19NEvsmc023436@mail.karels.net> To: "Rodney W. Grimes" cc: freebsd-net@FreeBSD.org From: Mike Karels Reply-to: karels@freebsd.org Subject: Re: cleaning up INET: deprecating network class A/B/C In-reply-to: Your message of Fri, 22 Oct 2021 08:49:16 -0700. <202110221549.19MFnG85075680@gndrsh.dnsmgr.net> List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23434.1635001074.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Oct 2021 09:57:54 -0500 X-Rspamd-Queue-Id: 4Hc48N0bjhz3Cxr X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of mike@mail.karels.net has no SPF policy when checking 216.160.39.52) smtp.mailfrom=mike@mail.karels.net X-Spamd-Result: default: False [0.30 / 15.00]; HAS_REPLYTO(0.00)[karels@freebsd.org]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[karels@freebsd.org,mike@mail.karels.net]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[karels@freebsd.org,mike@mail.karels.net]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N > > 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: > 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 metric 0 mtu 16384 > options=3D680003 > 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