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. > 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 Routes do not use the netmask on interface addresses, but only on the route. The only address that is reachable via lo0 is what is configured. Long ago, 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
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. 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 > > >
Re: cleaning up INET: deprecating network class A/B/C
> On 19. Oct 2021, at 23:16, Mike Karels wrote: > > 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. > I’ve got a use case that depends on being able to set and read the netmask on loopback interfaces consistently to allow orchestration and nomad fingerprinters to pick it up. But that’s really only about those operations. Best Michael
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
Re: cleaning up INET: deprecating network class A/B/C
> 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. 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. > > 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 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. I do believe Linux still defines the CLASS macros. > Mike -- Rod Grimes rgri...@freebsd.org