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

[Seth David Schoen <schoen%loyalty.org@localhost>]

Hi folks,

Thanks for all the replies.  A few replies made roughly the same points
or raised roughly the same concerns, so I hope I can cover everything
with this general reply.


(1) The drafts I linked to are indeed our own proposals and are not
Internet standards.  They're technically not individual submissions,
because that has a technical meaning in the IETF process, but we may end
up publishing versions of these drafts through the individual submissions
process in the future, in which case they would still not be official
Internet standards and would have a different disclaimer on top about
not being standards-track documents.

I didn't mean for anyone to think that our proposals were Internet
standards, although we have been pursuing them at the IETF.  I shared
these drafts because they include a lot of background information and
argument, including exactly what changes we think should be made, why
we think these changes would be useful, how the status quo developed,
and how different operating systems (and other network software tools)
do or don't follow the behaviors we suggest.  If anyone is interested
in any of these topics, you should be able to find some answers in our
Internet-Drafts.


(2) Several people said that they thought NetBSD should follow existing
Internet standards, and not get out in front of possible changes, so to
speak.  I understand and respect this position, and for example this is
roughly the path that FreeBSD followed when we proposed similar changes
there -- by putting the behaviors we suggested behind sysctl options,
which are off by default, so that the default behavior follows the
existing standards, but system administrators can easily opt into the
different behavior for their own sites.  If people are strongly convinced
of the importance of defaulting to the existing standards behavior,
then I would suggest the sysctl opt-in approach that FreeBSD used.

We've been encouraging OS developers to consider making these changes in
advance of IETF standardization, which we don't think has been an unusual
position in Internet history.  It seems not uncommon that developers
adopted behaviors that they were persuaded were useful or potentially
useful, even while standards discussions were just beginning or were
still unsettled; developers have also often implemented behaviors from
drafts for many different reasons.  The old IETF slogan "rough consensus
and running code" and the practice of submitting work for standardization
after one already has interoperable implementations seem to reflect that.
I also understand that there are cases where changing existing behavior
without a prior standards consensus is potentially dangerous because it
could break or destabilize something or reduce compatibility between one
implementation and another.  We've thought hard about this and we don't
think that adopting what we suggest, even as a default, will cause any
significant harm or breakage.

But again, if people disagree or aren't comfortable with that, sysctls
and opt-in are a time-honored approach.

The treatment of the lowest address (which we also have a proposal
about) seems to be an example in which NetBSD (and, separately, OpenBSD)
decided to change a TCP/IP behavior unilaterally just because it seemed
like a good idea and people were persuaded it was potentially useful.
In NetBSD's case, I believe this was initially a sysctl that defaulted to
the traditional RFC 1122 behavior and that the default was flipped several
years later -- presumably when people had more experience with the change.


(3) People also alluded to our other proposals.  We do still have a
proposal about 127/8 (which I haven't tried to implement on NetBSD yet),
and a proposal about the lowest address in a network segment where NetBSD
is already doing exactly what we suggest.  The 127/8 change is trickier
than the others because it proposes to repurpose addresses that _could_
already have a meaning and use in practice, and because some TCP/IP
implementations have a special-case path for loopback that doesn't go
through the normal interface and routing table logic.  So far I've only
ever proposed the 127/8 change as a sysctl which is disabled by default,
and I don't have a proposal worked out for how NetBSD would do this.

If anyone does want to read about these other proposals, the
Internet-Drafts are at

https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-127/
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/