[ih] The history of "This" 0.0.0.0/8 network?

[Dave Taht]

Grant Taylor <internet-history at gtaylor.tnetconsulting.net> writes:

> On 02/12/2019 11:23 AM, Dave Taht wrote:
>> I loved that book. It needs a sequel. Multiple sequels.
>
> Agreed!!!
>
>> One tidbit from that book I'd love to track down - it said paul buran 
>> wrote 11?13? 14? - can't remember- *books* about packet processing, 
>> and yet these have vanished from the internet. Whenever I struggle on 
>> something - like the whol bufferbloat thing - I fantasize that scribbled 
>> in the margin of book 13 was the answer to my problem.
>
> Hum.
>
> I'll have to look for that in context when I next re-read the book and 
> then start researching things.  }:-)

Might have been donald davies, don't remember.
>
>> What we see nowadays is 0.0.0.0/32 is used for useful stuff. 0.0.0.0/8, 
>> by history and by extension (including the 4.2 BSD broadcast gaff), 
>> is unused.
>> 
>> However, 0.0.0.1 - 0.255.255.254 *does work* as a real address with a 
>> very simple patch to linux.
>
> ~chuckle~
>
> Why do I now want to use this as something akin to 169.254/16 link-local 
> IP addresses.  }:-)
>
>> Boom. arp works, address assignement via dhcp works, it works as an 
>> address on everything patched.
>
> :-)

Apply this to linux/include/linux/in.h

and recompile.

 @@ -67,7 +72,7 @@ static inline bool ipv4_is_all_snoopers(__be32 addr)

 static inline bool ipv4_is_zeronet(__be32 addr)
  {
  -     return (addr & htonl(0xff000000)) == htonl(0x00000000);
  +     return (addr == 0);
   }

and you too can have 16 million extra IPv4 addresses to play with.

>> So trying to find the cases where that address range wouldn't work is 
>> on my mind. Clearly 0.0.0.0/32 is special, but...
>
> 0.0.0.0/32 is special.  But that doesn't directly translate to the 
> zeroth address in a subnet.
>
> I don't recall at the moment where 0.0.0.0/32 is used as a /destination/ 
> address.  I'm sure there is something, but I don't recall it at the moment.
>
>> The zeroth address is another long standing problem. Since cidr, and 
>> 4.2BSD's retirement, zeroth should be a usable address.
>
> The best I've found is that the zeroth address / subnet can be 
> misconstrued when addressing the (sub)network.
>
> Does 192.168.0.0 sans netmask address the 192.168.0.0/16 network, or the 
> 192.168.0.0/24 sub-network, or one of the 14 other sub-networks?
>
> As I think about it, I guess the broadcast (all ones host) address could 
> suffer from the same problem.  But the broadcast address is already 
> special and unused by hosts.
>
>> Explicit checks in the OS.
>
> Sorry, I was asking about what the reasoning was for them to be special, 
> not the code used to enforce / protect their special nature.
>
> Asked another way, what is the reasoning behind the zeroth (all zeros 
> host) address special and in need of protection to prevent it's use by 
> normal hosts?

I'm not sure there's any reasoning left at all. Just enough vestiges of
code and rfcs to make the zeroth address semi-special to make it harder
to deploy. Perhaps a new definitive RFC (and patches) mandating zeroth
be treated like any other unicast address would help.

>> Good question. But the issue died with BSD 4.2
>
> Indeed.
>
> I had (what I think is) another one come to mind last night.
>
> What, if any, security / specialness do people still ascribe to ports 
> below 1024?
>
> If it's a throwback to thinking that it requires root on a host to be 
> able to source traffic from ports below 1024....  Well, I don't trust 
> the remote host across the Internet at all.  So, I don't personally 
> ascribe any security to the port number.  But I don't know if I'm 
> strange in that.
>
> I personally (in my current naive state of mind) would like to see 
> daemons daemons source traffic from any of the other 65,535 ports 
> excluding than the destination port as a possible source port.
>
> Aside:  Why is port 0 special?  }:-)