Re: Support for 240/4 and 0/8 addresses in NetBSD

[Greg Troxel <gdt%lexort.com@localhost>]

Rhialto <rhialto%falu.nl@localhost> writes:

> On Thu 15 Jun 2023 at 09:12:02 -0500, David Young wrote:
>> Instead of adding a kernel config option or sysctl, wouldn't it be
>> simplest to add REJECT routes for the relevant ranges at boot, or not,
>> based on a setting in rc.conf? 
>
> I was thinking along the lines of: if a sysctl check (of some address
> validity) would get in the way of the fast path, then that particular
> check could be left the same. In the slow path (the failure case), it
> could then check the sysctl and possibly consider the address valid
> anyway.  With a scheme like this, the run time costs are only incurred
> if somebody actually uses the "new" addresses.

Stepping back from optimizing code, I think there are unanswered
questions:

  A) Are any of the addresses that are currently not allowed by standards
     actually in use?  [seems like obviously not]    If not, what is a
     rational timeframe for them being issued and used?

  B) Are the code changes on the table fundamentally:
     1) aligning to emerging standards?
     2) part of a process that argues that the standards should be
        changed?

  C) We hear that the documents are not yet standards-track work items,
     and people offlist have told me (paraphrasing vastly) that this is
     because "IETF complicated" and "IETF more political than technical
     these days".  If that's true, then it seems that for this to become
     reality so that A is true, documents will need to progress through
     standardization, to the point where registries are willing to
     issues addresses.  Assuming that's true, why is it useful for
     NetBSD to do anythning now, aside from stepping into IETF politics
     via B)2) ?


All that said, dyoung@'s idea of replacing the kernel checks with REJECT
routes has merit.