Re: allow 240/4 in various network daemons
Martin Schröder wrote: > Am Sa., 28. Mai 2022 um 22:46 Uhr schrieb Seth David Schoen > : > > We're also interested in talking about whether there's an appropriate > > path for supporting non-broadcast use of addresses within 127/8, our > > most controversial change. In Linux and FreeBSD, we're experimenting > > IPv6 is now older than IPv4 was when v6 was introduced. > You are beating a very dead horse. Martin, that comment is unhelpful.
Re: allow 240/4 in various network daemons
On 5/28/22 5:22 PM, Crystal Kolipe wrote: There certainly are people using this behaviour of the loopback address(es) in creative ways on non-OpenBSD systems: https://timkay.com/solo/ Changing it on those systems will likely break various users' scripts in unexpected ways. The script linked above doesn't work in it's original form on OpenBSD precisely because of the different behaviour of the 127/8 subnet. Not that I really care, because a solution to the _real_ problem already exists. It's called IPv6. True. But I would have to buy access to a VPN because my service provider hasn't extended IPv6 service to my location. Hurricane Electric isn't useful because some sites care about geography and they can't determine where a HE user is located.
Re: allow 240/4 in various network daemons
Am Sa., 28. Mai 2022 um 22:46 Uhr schrieb Seth David Schoen : > We're also interested in talking about whether there's an appropriate > path for supporting non-broadcast use of addresses within 127/8, our > most controversial change. In Linux and FreeBSD, we're experimenting IPv6 is now older than IPv4 was when v6 was introduced. You are beating a very dead horse. Best Martin
Re: allow 240/4 in various network daemons
On Sat, May 28, 2022 at 01:46:18PM -0700, Seth David Schoen wrote: > We're also interested in talking about whether there's an appropriate > path for supporting non-broadcast use of addresses within 127/8, our > most controversial change. In Linux and FreeBSD, we're experimenting > with the ideas of having a sysctl that defines the prefix length for > loopback on the 127 network (with the default value being 8), or making > the loopback interface honor netmasks in exactly the same way as other > network interfaces do (so if you set 255.0.0.0 as the mask on lo, then > it will believe 127.2.3.4 is reachable via loopback, while if you set > 255.255.255.255 as the mask, it will only believe 127.0.0.1 is > reachable). We think other systems will be willing to let people opt > into this change, but will likely not want to make it the default due to > concerns about possible existing uses for loopback addresses other than > 127.0.0.1. There certainly are people using this behaviour of the loopback address(es) in creative ways on non-OpenBSD systems: https://timkay.com/solo/ Changing it on those systems will likely break various users' scripts in unexpected ways. The script linked above doesn't work in it's original form on OpenBSD precisely because of the different behaviour of the 127/8 subnet. Not that I really care, because a solution to the _real_ problem already exists. It's called IPv6.
Re: allow 240/4 in various network daemons
Theo de Raadt writes: > This discussion relates to only one step of a number of potential increments. > > I believe it is a bad idea to conflate all of these potential address > space recovery changes as the same singular discussion. Not all the > decisions being made on intranets are sane. Not all of these proposals > make sense. Not all of these proposals make sense right away. > > Instead, they should be done piecemeal, and each one should be discussed > seperately, or we will lose the way. Thank you for merging the patches that improve OpenBSD's support for 0/8 and 240/4, and thank you again for making the lowest address broadcast change years ago. We'd be happy to hear more of your ideas about the best way to promote and discuss these changes. As you may be aware, software support for them is pretty good (and getting better all the time), while the IETF community has not been very enthusiastic about our drafts so far. We're also interested in talking about whether there's an appropriate path for supporting non-broadcast use of addresses within 127/8, our most controversial change. In Linux and FreeBSD, we're experimenting with the ideas of having a sysctl that defines the prefix length for loopback on the 127 network (with the default value being 8), or making the loopback interface honor netmasks in exactly the same way as other network interfaces do (so if you set 255.0.0.0 as the mask on lo, then it will believe 127.2.3.4 is reachable via loopback, while if you set 255.255.255.255 as the mask, it will only believe 127.0.0.1 is reachable). We think other systems will be willing to let people opt into this change, but will likely not want to make it the default due to concerns about possible existing uses for loopback addresses other than 127.0.0.1. (There was also a CVE affecting some software under Linux due to a kernel option where one could opt in to giving 127/8 both loopback and non-loopback semantics at the same time, which turns out to be a bad idea because then hosts on a LAN can address sockets that think they're bound only to loopback addresses! This is definitely not a good idea.) There also seems to be a strange ambiguity about whether OSes currently treat all of 127/8 as usable loopback or only treat 127.0.0.1 as reachable but effectively reserve all of the rest for future use. My impression is that either behavior is somewhat defensible under current standards, but I might have missed some language in an RFC that officially rules out one or the other.
Re: allow 240/4 in various network daemons
I would agree with the diff.. @claudio (for what it is worth)
in principle 240.0.0.0/4 was reserved for future use in the past...
so changing that today makes sense to me ...
On Fri, 6 May 2022 at 13:20, Claudio Jeker wrote:
>
> On Thu, May 05, 2022 at 11:37:24AM +0200, Claudio Jeker wrote:
> > So most routing daemons and other network daemons like pppd do not allow
> > 240/4 as IPs because they check the IP against IN_BADCLASS().
> > I think it is time to remove this restriction.
> >
> > Now there is another magical network 0.0.0.0/8 which is not allowed in
> > some but not all of the routing daemons. Not sure if that should be
> > removed or blocked in all daemons.
>
> The discussion about this diff totally derailed so lets try again. Anyone
> wants to OK this?
>
> --
> :wq Claudio
>
> Index: usr.sbin/bgpd/kroute.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
> retrieving revision 1.244
> diff -u -p -r1.244 kroute.c
> --- usr.sbin/bgpd/kroute.c 8 Mar 2022 12:58:57 - 1.244
> +++ usr.sbin/bgpd/kroute.c 5 May 2022 08:48:27 -
> @@ -1448,12 +1448,11 @@ kr_redistribute(int type, struct ktable
> return;
>
> /*
> -* We consider the loopback net, multicast and experimental addresses
> +* We consider the loopback net and multicast addresses
> * as not redistributable.
> */
> a = ntohl(kr->prefix.s_addr);
> - if (IN_MULTICAST(a) || IN_BADCLASS(a) ||
> - (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
> + if (IN_MULTICAST(a) || (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
> return;
>
> /* Check if the nexthop is the loopback addr. */
> Index: usr.sbin/bgpd/rde.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
> retrieving revision 1.544
> diff -u -p -r1.544 rde.c
> --- usr.sbin/bgpd/rde.c 22 Mar 2022 10:53:08 - 1.544
> +++ usr.sbin/bgpd/rde.c 5 May 2022 08:48:49 -
> @@ -1790,10 +1790,10 @@ bad_flags:
> UPD_READ(_addr, p, plen, 4);
> /*
> * Check if the nexthop is a valid IP address. We consider
> -* multicast and experimental addresses as invalid.
> +* multicast addresses as invalid.
> */
> tmp32 = ntohl(nexthop.v4.s_addr);
> - if (IN_MULTICAST(tmp32) || IN_BADCLASS(tmp32)) {
> + if (IN_MULTICAST(tmp32)) {
> rde_update_err(peer, ERR_UPDATE, ERR_UPD_NEXTHOP,
> op, len);
> return (-1);
> Index: usr.sbin/eigrpd/util.c
> ===
> RCS file: /cvs/src/usr.sbin/eigrpd/util.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 util.c
> --- usr.sbin/eigrpd/util.c 7 Dec 2018 08:40:54 - 1.10
> +++ usr.sbin/eigrpd/util.c 5 May 2022 08:53:31 -
> @@ -224,7 +224,7 @@ bad_addr_v4(struct in_addr addr)
>
> if (((a >> IN_CLASSA_NSHIFT) == 0) ||
> ((a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) ||
> - IN_MULTICAST(a) || IN_BADCLASS(a))
> + IN_MULTICAST(a))
> return (1);
>
> return (0);
> Index: usr.sbin/ldpd/util.c
> ===
> RCS file: /cvs/src/usr.sbin/ldpd/util.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 util.c
> --- usr.sbin/ldpd/util.c7 Dec 2018 08:40:54 - 1.5
> +++ usr.sbin/ldpd/util.c5 May 2022 08:54:03 -
> @@ -223,7 +223,7 @@ bad_addr_v4(struct in_addr addr)
>
> if (((a >> IN_CLASSA_NSHIFT) == 0) ||
> ((a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) ||
> - IN_MULTICAST(a) || IN_BADCLASS(a))
> + IN_MULTICAST(a))
> return (1);
>
> return (0);
> Index: usr.sbin/mrouted/inet.c
> ===
> RCS file: /cvs/src/usr.sbin/mrouted/inet.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 inet.c
> --- usr.sbin/mrouted/inet.c 21 Apr 2013 06:42:43 - 1.6
> +++ usr.sbin/mrouted/inet.c 5 May 2022 08:57:09 -
> @@ -36,7 +36,6 @@ inet_valid_host(u_int32_t naddr)
> addr = ntohl(naddr);
>
> return (!(IN_MULTICAST(addr) ||
> - IN_BADCLASS (addr) ||
> (addr & 0xff00) == 0));
> }
>
> @@ -83,7 +82,7 @@ inet_valid_subnet(u_int32_t nsubnet, u_i
> (subnet & 0xff00) == 0x7f00 ||
> (subnet & 0xff00) == 0x) return (FALSE);
> }
> -else if (IN_CLASSD(subnet) || IN_BADCLASS(subnet)) {
> +else if (IN_CLASSD(subnet)) {
> /* Above Class C address space */
> return (FALSE);
> }
> Index: usr.sbin/ospfd/kroute.c
> ===
> RCS file:
Re: allow 240/4 in various network daemons
On Fri, May 06, 2022 at 02:11:46PM +0200, Claudio Jeker wrote: > On Thu, May 05, 2022 at 11:37:24AM +0200, Claudio Jeker wrote: > > So most routing daemons and other network daemons like pppd do not allow > > 240/4 as IPs because they check the IP against IN_BADCLASS(). > > I think it is time to remove this restriction. > > > > Now there is another magical network 0.0.0.0/8 which is not allowed in > > some but not all of the routing daemons. Not sure if that should be > > removed or blocked in all daemons. > > The discussion about this diff totally derailed so lets try again. Anyone > wants to OK this? ok tb
Re: allow 240/4 in various network daemons
On Thu, May 05, 2022 at 11:37:24AM +0200, Claudio Jeker wrote:
> So most routing daemons and other network daemons like pppd do not allow
> 240/4 as IPs because they check the IP against IN_BADCLASS().
> I think it is time to remove this restriction.
>
> Now there is another magical network 0.0.0.0/8 which is not allowed in
> some but not all of the routing daemons. Not sure if that should be
> removed or blocked in all daemons.
The discussion about this diff totally derailed so lets try again. Anyone
wants to OK this?
--
:wq Claudio
Index: usr.sbin/bgpd/kroute.c
===
RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
retrieving revision 1.244
diff -u -p -r1.244 kroute.c
--- usr.sbin/bgpd/kroute.c 8 Mar 2022 12:58:57 - 1.244
+++ usr.sbin/bgpd/kroute.c 5 May 2022 08:48:27 -
@@ -1448,12 +1448,11 @@ kr_redistribute(int type, struct ktable
return;
/*
-* We consider the loopback net, multicast and experimental addresses
+* We consider the loopback net and multicast addresses
* as not redistributable.
*/
a = ntohl(kr->prefix.s_addr);
- if (IN_MULTICAST(a) || IN_BADCLASS(a) ||
- (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
+ if (IN_MULTICAST(a) || (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
return;
/* Check if the nexthop is the loopback addr. */
Index: usr.sbin/bgpd/rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.544
diff -u -p -r1.544 rde.c
--- usr.sbin/bgpd/rde.c 22 Mar 2022 10:53:08 - 1.544
+++ usr.sbin/bgpd/rde.c 5 May 2022 08:48:49 -
@@ -1790,10 +1790,10 @@ bad_flags:
UPD_READ(_addr, p, plen, 4);
/*
* Check if the nexthop is a valid IP address. We consider
-* multicast and experimental addresses as invalid.
+* multicast addresses as invalid.
*/
tmp32 = ntohl(nexthop.v4.s_addr);
- if (IN_MULTICAST(tmp32) || IN_BADCLASS(tmp32)) {
+ if (IN_MULTICAST(tmp32)) {
rde_update_err(peer, ERR_UPDATE, ERR_UPD_NEXTHOP,
op, len);
return (-1);
Index: usr.sbin/eigrpd/util.c
===
RCS file: /cvs/src/usr.sbin/eigrpd/util.c,v
retrieving revision 1.10
diff -u -p -r1.10 util.c
--- usr.sbin/eigrpd/util.c 7 Dec 2018 08:40:54 - 1.10
+++ usr.sbin/eigrpd/util.c 5 May 2022 08:53:31 -
@@ -224,7 +224,7 @@ bad_addr_v4(struct in_addr addr)
if (((a >> IN_CLASSA_NSHIFT) == 0) ||
((a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) ||
- IN_MULTICAST(a) || IN_BADCLASS(a))
+ IN_MULTICAST(a))
return (1);
return (0);
Index: usr.sbin/ldpd/util.c
===
RCS file: /cvs/src/usr.sbin/ldpd/util.c,v
retrieving revision 1.5
diff -u -p -r1.5 util.c
--- usr.sbin/ldpd/util.c7 Dec 2018 08:40:54 - 1.5
+++ usr.sbin/ldpd/util.c5 May 2022 08:54:03 -
@@ -223,7 +223,7 @@ bad_addr_v4(struct in_addr addr)
if (((a >> IN_CLASSA_NSHIFT) == 0) ||
((a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) ||
- IN_MULTICAST(a) || IN_BADCLASS(a))
+ IN_MULTICAST(a))
return (1);
return (0);
Index: usr.sbin/mrouted/inet.c
===
RCS file: /cvs/src/usr.sbin/mrouted/inet.c,v
retrieving revision 1.6
diff -u -p -r1.6 inet.c
--- usr.sbin/mrouted/inet.c 21 Apr 2013 06:42:43 - 1.6
+++ usr.sbin/mrouted/inet.c 5 May 2022 08:57:09 -
@@ -36,7 +36,6 @@ inet_valid_host(u_int32_t naddr)
addr = ntohl(naddr);
return (!(IN_MULTICAST(addr) ||
- IN_BADCLASS (addr) ||
(addr & 0xff00) == 0));
}
@@ -83,7 +82,7 @@ inet_valid_subnet(u_int32_t nsubnet, u_i
(subnet & 0xff00) == 0x7f00 ||
(subnet & 0xff00) == 0x) return (FALSE);
}
-else if (IN_CLASSD(subnet) || IN_BADCLASS(subnet)) {
+else if (IN_CLASSD(subnet)) {
/* Above Class C address space */
return (FALSE);
}
Index: usr.sbin/ospfd/kroute.c
===
RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
retrieving revision 1.114
diff -u -p -r1.114 kroute.c
--- usr.sbin/ospfd/kroute.c 20 Aug 2020 03:09:28 - 1.114
+++ usr.sbin/ospfd/kroute.c 5 May 2022 08:54:30 -
@@ -565,12 +565,11 @@ kr_redist_eval(struct kroute *kr, struct
goto dont_redistribute;
/*
-* We consider the loopback net, multicast and experimental addresses
+* We consider the
Re: allow 240/4 in various network daemons
On 2022/05/05 15:28, Jeroen Massar wrote: > Though they did it with 1.0.0.0/8 (though that is just a huge network > telescope). No this still does not work reliably
Re: allow 240/4 in various network daemons
It is like you are trying to predict the next 20 years, but I'm sorry I find it too confusing. Jeroen Massar wrote: > > On 5 May 2022, at 15:36, Theo de Raadt wrote: > > > > Jeroen Massar wrote: > > > >> I thus mostly see these odd prefixes (0/8, 127/8, 240/4) as extra RFC1918 > >> space > >> for those who do want to deploy more IPv4 as they can't be arsed after > >> almost > >> 30 years to finally do this IPv6 thing... > > > > But that's the dangerous part. > > > > If the operating systems suddenly allow use of this space for anything, and > > While security sensitive admins will too, there are way too many hosts that > have uptimes of several years and that will never be upgraded. > Rolling out such a change so that it is going to matter will be even slower > than an IPv6 rollout... decades. > > There are still stats out there which show how much ancient Android, or even > bare normal Linux is out there, and not forget about all the Windows boxes. > > Globally using these magic prefixes will thus become magic; operations teams > will never accept that debugging challenge, they have other things to do (in > the large corps: delivering ads, and those have to be delivered for sure, > hence why we have HTTPS everywhere now). > These magic prefixes don't have the properties of delivering ads, thus very > unlikely those types will use them for that (global routing). > > > everyone considers these address blocks new free-for-all new rfc1918 space, > > THEN the result will be that these spaces can never be globally announced > > later. > > IMHO they should not be, folks should be moving to IPv6 for global addresses. > > If the powers that be decide that it is "globally unique routeable space", > then I wish folks a lot of lot with debugging that. > > > You are suggesting facts on the ground should be allowed to beat the > > establishment of a policy. > > In case a policy is needed first, then one would have to wait for patching > too ;) > > > As an avid IPv6 user, IPv4 is only as compatibility on the edge for me, these > changes thus do not directly affect me (till the moment somebody wants to use > it globally and start breaking things). > > Greets, > Jeroen > >
Re: allow 240/4 in various network daemons
Jeroen Massar wrote: > I thus mostly see these odd prefixes (0/8, 127/8, 240/4) as extra RFC1918 > space > for those who do want to deploy more IPv4 as they can't be arsed after almost > 30 years to finally do this IPv6 thing... But that's the dangerous part. If the operating systems suddenly allow use of this space for anything, and everyone considers these address blocks new free-for-all new rfc1918 space, THEN the result will be that these spaces can never be globally announced later. You are suggesting facts on the ground should be allowed to beat the establishment of a policy.
Re: allow 240/4 in various network daemons
This discussion relates to only one step of a number of potential increments. I believe it is a bad idea to conflate all of these potential address space recovery changes as the same singular discussion. Not all the decisions being made on intranets are sane. Not all of these proposals make sense. Not all of these proposals make sense right away. Instead, they should be done piecemeal, and each one should be discussed seperately, or we will lose the way. Some of these address space changes will NEVER be globabaly routable because it has already been stomped on by squatters and will create visibility issues, or maybe NEVER is a decade hence. Other parts of thes address space changes have the potential for becoming globally routed. It is important to be careful and not just turn it into a free-for-all where people will make further bad decisions. Jeroen Massar wrote: > Hi Claudio, > > Why not update the BADCLASS check? > Though likely for IPv4 it will reduce to 0 items at one point and then can be > eliminated indeed. > > > Note that there are checks for loopback (127.0.0.0/8), there are a bunch of > organisations that started using everything but 127.0.0.0/24 (thus 127.0.0.1 > specifically) in their internal networks, routed, just like a normal prefix; > as that gives one kinda easily a whole /8 minus one /24. > Same for 0.0.0.0/8, there are orgs that instead of finally upgrading to IPv6 > just started using that, next to 240/8 and whatever they could find. > > Greets, > Jeroen >
allow 240/4 in various network daemons
So most routing daemons and other network daemons like pppd do not allow
240/4 as IPs because they check the IP against IN_BADCLASS().
I think it is time to remove this restriction.
Now there is another magical network 0.0.0.0/8 which is not allowed in
some but not all of the routing daemons. Not sure if that should be
removed or blocked in all daemons.
--
:wq Claudio
Index: usr.sbin/bgpd/kroute.c
===
RCS file: /cvs/src/usr.sbin/bgpd/kroute.c,v
retrieving revision 1.244
diff -u -p -r1.244 kroute.c
--- usr.sbin/bgpd/kroute.c 8 Mar 2022 12:58:57 - 1.244
+++ usr.sbin/bgpd/kroute.c 5 May 2022 08:48:27 -
@@ -1448,12 +1448,11 @@ kr_redistribute(int type, struct ktable
return;
/*
-* We consider the loopback net, multicast and experimental addresses
+* We consider the loopback net and multicast addresses
* as not redistributable.
*/
a = ntohl(kr->prefix.s_addr);
- if (IN_MULTICAST(a) || IN_BADCLASS(a) ||
- (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
+ if (IN_MULTICAST(a) || (a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET)
return;
/* Check if the nexthop is the loopback addr. */
Index: usr.sbin/bgpd/rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.544
diff -u -p -r1.544 rde.c
--- usr.sbin/bgpd/rde.c 22 Mar 2022 10:53:08 - 1.544
+++ usr.sbin/bgpd/rde.c 5 May 2022 08:48:49 -
@@ -1790,10 +1790,10 @@ bad_flags:
UPD_READ(_addr, p, plen, 4);
/*
* Check if the nexthop is a valid IP address. We consider
-* multicast and experimental addresses as invalid.
+* multicast addresses as invalid.
*/
tmp32 = ntohl(nexthop.v4.s_addr);
- if (IN_MULTICAST(tmp32) || IN_BADCLASS(tmp32)) {
+ if (IN_MULTICAST(tmp32)) {
rde_update_err(peer, ERR_UPDATE, ERR_UPD_NEXTHOP,
op, len);
return (-1);
Index: usr.sbin/eigrpd/util.c
===
RCS file: /cvs/src/usr.sbin/eigrpd/util.c,v
retrieving revision 1.10
diff -u -p -r1.10 util.c
--- usr.sbin/eigrpd/util.c 7 Dec 2018 08:40:54 - 1.10
+++ usr.sbin/eigrpd/util.c 5 May 2022 08:53:31 -
@@ -224,7 +224,7 @@ bad_addr_v4(struct in_addr addr)
if (((a >> IN_CLASSA_NSHIFT) == 0) ||
((a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) ||
- IN_MULTICAST(a) || IN_BADCLASS(a))
+ IN_MULTICAST(a))
return (1);
return (0);
Index: usr.sbin/ldpd/util.c
===
RCS file: /cvs/src/usr.sbin/ldpd/util.c,v
retrieving revision 1.5
diff -u -p -r1.5 util.c
--- usr.sbin/ldpd/util.c7 Dec 2018 08:40:54 - 1.5
+++ usr.sbin/ldpd/util.c5 May 2022 08:54:03 -
@@ -223,7 +223,7 @@ bad_addr_v4(struct in_addr addr)
if (((a >> IN_CLASSA_NSHIFT) == 0) ||
((a >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET) ||
- IN_MULTICAST(a) || IN_BADCLASS(a))
+ IN_MULTICAST(a))
return (1);
return (0);
Index: usr.sbin/mrouted/inet.c
===
RCS file: /cvs/src/usr.sbin/mrouted/inet.c,v
retrieving revision 1.6
diff -u -p -r1.6 inet.c
--- usr.sbin/mrouted/inet.c 21 Apr 2013 06:42:43 - 1.6
+++ usr.sbin/mrouted/inet.c 5 May 2022 08:57:09 -
@@ -36,7 +36,6 @@ inet_valid_host(u_int32_t naddr)
addr = ntohl(naddr);
return (!(IN_MULTICAST(addr) ||
- IN_BADCLASS (addr) ||
(addr & 0xff00) == 0));
}
@@ -83,7 +82,7 @@ inet_valid_subnet(u_int32_t nsubnet, u_i
(subnet & 0xff00) == 0x7f00 ||
(subnet & 0xff00) == 0x) return (FALSE);
}
-else if (IN_CLASSD(subnet) || IN_BADCLASS(subnet)) {
+else if (IN_CLASSD(subnet)) {
/* Above Class C address space */
return (FALSE);
}
Index: usr.sbin/ospfd/kroute.c
===
RCS file: /cvs/src/usr.sbin/ospfd/kroute.c,v
retrieving revision 1.114
diff -u -p -r1.114 kroute.c
--- usr.sbin/ospfd/kroute.c 20 Aug 2020 03:09:28 - 1.114
+++ usr.sbin/ospfd/kroute.c 5 May 2022 08:54:30 -
@@ -565,12 +565,11 @@ kr_redist_eval(struct kroute *kr, struct
goto dont_redistribute;
/*
-* We consider the loopback net, multicast and experimental addresses
+* We consider the loopback net and multicast addresses
* as not redistributable.
*/
a = ntohl(kr->prefix.s_addr);
- if (IN_MULTICAST(a) || IN_BADCLASS(a) ||
-
