Date: Thu, 7 Jul 2022 08:37:52 +1000 From: George Michaelson <ggm@algebras.org> To: mike@karels.net Cc: freebsd-net@freebsd.org Subject: Re: experimental support for IPv4 unicast extensions Message-ID: <CAKr6gn39%2BRDO6R7KDAjWRwyAxOrRL2HkHH7V_2RnFcWU%2BTuW1g@mail.gmail.com> In-Reply-To: <202207062206.266M6UVV033854@mail.karels.net> References: <202207062206.266M6UVV033854@mail.karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In my opinion, these changes are definitely worth accepting. Removing barriers to deployment of 240/4 is a good thing. The changes are really simple, easy to understand and gated by sysctl which is sensible. I really hope we can move from 'default off' to 'default on' in a reasonably short period of time. Disclaimer: I work in a regional registry so I am probably biassed. While I might personally prefer people move to v6, I think this is a good body of code change to deploy. Coincidentally I was a co-author on an expired draft to un-reserve 240/4 many years ago, but it (foolishly perhaps) proposed private use, not global unicast. The kernel changes would however have been much the same. Thanks for doing this Mike. -George On Thu, Jul 7, 2022 at 8:07 AM Mike Karels <mike@karels.net> wrote: > > I have been corresponding with the authors of Internet-Drafts that relax > restrictions on parts of the IPv4 address space to allow normal unicast > use, and I have FreeBSD changes to allow experimentation with these > updates. This message summarizes my changes, and solicits input. > > The changes are all controlled by sysctl, and default to "off". > The parts of the address space in question and the relevant changes: > > 0/8 (network 0) [1]: Restrictions on network 0 are lifted if the sysctl > net.inet.ip.allow_zeronet is set to 1. This applies to packet forwarding > and ICMP echo. > > 224/4 (Experimental/"Class E") [2]: Restrictions on the Experimental > address class are lifted if the sysctl net.inet.ip.allow_experimental > is set to 1. This applies to packet forwarding and ICMP echo. > > 127/8 (loopback net) [3]: The size of the reservation for the loopback > network can be reduced from 127/8 to 127.0/16 using the sysctl > net.int.ip.loopback_mask. My current sysctl sets the mask, but that > is a little cumbersome; I should probably change the sysctl to allow > a mask length to be set. This change is limited to the kernel; the > IN_LOOPBACK macro uses the current mask in the kernel, but the default > mask at user level. Also, some user programs use IN_LOOPBACKNET along > with a Class A shift to crack this by hand. The kernel change affects > IP packet input and output as well as forwarding. > > The changes described above are all included in a single review for now, > although I would probably separate them before pushing them. (They > necessarily collide though.) The review is intended for comments only, > and is https://reviews.freebsd.org/D35741. I think it makes sense to > put these changes in -current in order to enable experimentation, but > I wanted to open the subject for discussion first. > > Changes are also being made in Linux, although I don't know their state. > > Note that there is a related proposal and change to allow use of the > lowest host on a network/subnet [4]. This change was essentially a bug > fix for FreeBSD, and is already in -current and 13.1-RELEASE. > > Mike > > [1] https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-0/01/ > > [2] https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ > > [3] https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-127/ > > [4] https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKr6gn39%2BRDO6R7KDAjWRwyAxOrRL2HkHH7V_2RnFcWU%2BTuW1g>