Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast
John Gilmore
gnu at toad.com
Fri Nov 19 20:14:00 UTC 2021
Nick Hilliard wrote:
>> consider three hosts on a broadcast domain: A, B and
>> C. A uses the lowest address, B accepts a lowest address, but C does
>> not. Then A can talk to B, B can talk to C, but C cannot talk to A.
>> This does not seem to be addressed in the draft.
Section 3.4. Compatibility and Interoperability.
Many deployed systems follow older Internet standards in not allowing
the lowest address in a network to be assigned or used as a source or
destination address. Assigning this address to a host may thus make
it inaccessible by some devices on its local network segment. [there's
more...]
If you think that section needs improving, please send suggested text.
We're happy to explain the implications better.
Joe Maimon <jmaimon at jmaimon.com> wrote:
> its a local support issue only.
That's also true. The only issues arise between your devices, on your
LAN. Everybody else on the Internet is unaffected and can reach all
your devices, including the lowest if your LAN uses it. Nothing forces
you to use your lowest address, and we recommend that DHCP servers be
configured by default to not to hand them out (no change from how they
historically have been configured).
We submitted a 6-line patch to the Busybox DHCP implementation in
February to avoid hardcoded prevention of issuing a .0 or .255 address
(which was wrong anyway, even without our proposal). The default in the
config file continues to use a range excluding .0. The patch was merged
upstream without trouble. See:
https://github.com/schoen/unicast-extensions/blob/master/merged-patches/busybox/0001-Don-t-hardcode-refusing-to-issue-.0-or-.255-addresse.patch
John
More information about the NANOG
mailing list