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.