I say this because I was one of those people when I graduated. At our school every network was /24, so 0 and 255 were always reserved. It was a while before I learned about CIDR and how those addresses may not be reserved.
Even outside of the context of a /24 I still reserve these addresses because they don't receive equal treatment on the internet. There are still dumb firewalls that treat them as broadcast amplification attacks, OS bugs that treat them as invalid, and a handful of other issues.
This issue tends to be a bell curve of experience. People brand new to networking, and the people who have spent dozens of years seeing the worst of what the internet has to offer both treat them as sacred cows, with the majority just shrugging and mumbling about CIDR.
It is the bug that creates itself.
> and the people who have spent dozens of years seeing the worst of what the internet has to offer both treat them as sacred cows
...a lot of them just didn't update their knowledge over time.
- Newbies see .0 and .255 as special
- We learn about CIDR, and there's nothing special about a .0 in the middle of a large block.
- Then we get zapped by weird connectivity problems or tools that don't let us enter the address because it fails "validation," etc.
Then we think... does our DHCP range really need to cross the boundary when we have a /23? Maybe we should just have two DHCP ranges with a little hole in the middle. It's less than 1% of addresses...
The behavior of arbitrarily rejecting .0 has gotten a lot rarer in the wild lately. (I can confirm that because I've done a whole bunch of connectivity tests to .0 addresses, including using RIPE Atlas.)
More likely to be a slightly fancy switch, or terrible CPE for DSL/Cable.
Experienced engineers understood that .0 and .255 are actually handled differently in the real-world, so they make sure to avoid them.
"Reality sucks, deal with it"
Newbies who just read the specs and learnt from classrooms are tricked into believing that .0 and .255 are the same. Which is true on paper, but not true in reality.
I tend to run /30 as the smallest because of that (no sudden surprises if a piece of gear doesn't support the extension)
I think last time I used it there were a few bugs around redistribution. I tend to use private IPs, certainly for p2ps, so a /30 is fine
Also, well-known IPs, and 192.168.0.1 in particular, should just be avoided. You don't want IP conflict in your network just because someone plugged in unconfigure device!
(Trick question for the exam is whether broadcast traffic received by new host with assigned address of .255 would be a problem.)
HOWEVER, if you want to broadcast something at a remote network, you need to have dedicated network broadcast IP addresses. Unfortunately, even RFC 919 from 1984 thinks it is not a recommended mode of operation. But imagine that we could get "ip/subnet" from DNS, send broadcast to a distant server farm, and receive response from anything that responded. Instead of DNS-based service discovery, we would have a single A record, and finally put that IANA port number database to use in port-based service discovery.
My point is that high level abstractions, like dedicated broadcast IP address that magically alters the behavior of lower level components, complicate things. Say, there is SO_BROADCAST, but it does nothing for TCP (even though we can imagine how broadcast client-to-server connection initiation might work), and there seems to be disagreement whether it allows to use broadcast address, or instructs to use broadcasts with any address. But Berkley sockets are also from mid-'80s, and it is possible that previous alternatives required manual configuration of low level APIs on each individual supported network to use broadcasts, so that was a step forward.
Looking at the BGP table it's just two entries (one for each /24).
I've encountered kit which doesn't like IPs on .0 or .255 in the middle of a /23 or larger, but I've also encountered kit which doesn't like any subnet that isn't a /24. That kit goes back to the supplier as faulty.
I've never seen kit which wont sent to a random x.x.x.255 address that isn't on the local subnet
It took a long, long time to shake that assumption out of all code, long after the OS had stopped using .0 that way. So this is yet another domino.
If you choose to use .0, then you have a cosmetic / mental issue ("omg numbering starts at 1, not at 0).
If you choose NOT to use .0 then you potentially save yourself hours of troubleshooting one day, and avoid productivity issues.
Reliability + Productivity > Cosmetic.
if you are "inside" your network, you have the mask; if you are outside, you don't know.
yes, if you are inexperienced and have never seen anything but class C, you might not make allowances for class B etc. The real problem with trying to solve these problems is we not allowed to deploy LARTs any more, or clue-by-fours.
The ghost of /etc/networks rattles in the distance..
For me, .0 and .255 were always associated with the first and last address of a block rather than those specific numbers. And thus the network and broadcast address respectively.