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