4 ms·

This is what happens when you make the fresh college hire, who has only ever seen a /24, write your network interfaces. They just assume .0 and .255 are always

This is what happens when you make the fresh college hire, who has only ever seen a /24, write your network interfaces. They just assume .0 and .255 are always special. 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.

candiddevmike 3y ago
I think people might be confused by your post. With an IPv4 /24 subnet, .0 and .255 are special (they are the network and broadcast addresses for a /24, respectively). When you use a different subnet mask, the network (first IP) and broadcast (last IP) addresses will shift.
- Faaak 3y ago
  And even though, you can still have a /24 with used .0, .255 (for example if injected via BGP on machines that have other IPs)
  - candiddevmike 3y ago
    Like other things in tech, you can do this, but you really shouldn't. There are a lot of assumptions baked into those addresses per the RFCs, which are kind of like our industry's electrical code. Using a broadcast address is "not up to code".
    - NoZebra120vClip 3y ago
      Long, long ago, SunOS, and possibly other Unixes, considered x.x.x.0 as a broadcast address as well. (Or I should say more properly, an all-zeroes host address.) 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.
    - Faaak 3y ago
      Please tell, then. But no, I don't see what is wrong with that. An outsider doesn't know the CIDR of the IP he's talking too, so it wouldn't change. It only matters for the last router in the loop, and if it's taken into account (because it's actually your infra), then it's okay
  - iso1631 3y ago
    Most of my small sites are a pair of /24s, they have .255 as a loopback, split up the rest of the network into /26 or /27. 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
- ogurechny 3y ago
  The problem is that in the common case case those IP addresses are useless and serve no purpose. Broadcasts get broadcast because they are sent to broadcast MAC address. They can have IP packet with all-ones destination inside (which is different from a unicast packet sent to that same address via its unique MAC), they can have IP packet with a specific destination inside (well, maybe your ARP cache is malfunctioning, and you've forgotten the proper MAC address, but not the fact the host exists?), they can have arbitrary data (because you've invented our own protocol). You also need to call a different function or set some flag to make broadcast happen. It is possible that early IP stacks relied on a dedicated high-level broadcast address to prevent the need to handle all kinds of underlying networks in programs, but I'm not sure. (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.
  - w7 3y ago
    You can get some of properties you describe with the behavior most people would want via a combination of anycast, some route exchange protocol (probably BGP), and ECMP.
  - PinguTS 3y ago
    It seems you assume, that IP runs on Ethernet. But what IP that runs on a different data link layer that uses different address and doesn't know what a MAC address is?
    - ogurechny 3y ago
      Then it uses a different broadcast method that also does not depend on higher level IP addresses. 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.
c0nsumer 3y ago
I get this all the time at work... We have somewhat large subnets for clients (I think /22 and /23, and something much larger for our VPN pools) so I'll not-infrequently get "client has wrong IP address" things because they have a .0 or .1 or .255.
phh 3y ago
In school, I handled the network for students, we had a /22. I was still afraid to use .0 and .255.
- rvnx 3y ago
  It's logical: 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.
mike_d 3y ago
.0 and .255 are special. 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.
- ilyt 3y ago
  Wait till you see how people react to /31 and /31 ending with .0 > 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.
  - mlyle 3y ago
    His point is that there's a pretty common journey: - 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...
    - schoen 3y ago
      The Busybox DHCP server had a special case where it wouldn't ever give out a .0 address, and I submitted a patch to remove that. I didn't even think about the possibility that someone might intentionally want that (to work around misbehavior of other devices). I don't think the person who added it was thinking that way, but I might be wrong. 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.)
fsckboy 3y ago
I don't think CIDR has anything to do with this. If you had a class B network, were you required to segment it into class C's? no, right? so, same problem, it's not clear what are your network and broadcast addresses without knowing your class, same as not knowing your cidr /n 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.
- akira2501 3y ago
  I think the original expectation was you wouldn't segment it, and that's why each address class has it's own defined range of ipv4 space. See rfc870, MITs /8 was listed as "temporary" (lol) and they had several separate specific class Bs. The ghost of /etc/networks rattles in the distance..
Akronymus 3y ago
> They just assume .0 and .255 are always special. 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.
caveman9000 3y ago
Just about every sysadmin I worked with thought in /24s. A lot of people are used to deploying the Linksys home routers and can't think about subnets or supernets. It used to blow peoples minds when they would get a .0 or .255 address because I had them on a /22 or /23. Even the last network engineer I replaced had multiple /24s all over the place across our WAN. I couldn't summarize routes because he didn't use sequential subnets, just random ones all over the place. Drove me nuts.

candiddevmike 3y ago

I think people might be confused by your post. With an IPv4 /24 subnet, .0 and .255 are special (they are the network and broadcast addresses for a /24, respectively). When you use a different subnet mask, the network (first IP) and broadcast (last IP) addresses will shift.

Faaak 3y ago
And even though, you can still have a /24 with used .0, .255 (for example if injected via BGP on machines that have other IPs)
- candiddevmike 3y ago
  Like other things in tech, you can do this, but you really shouldn't. There are a lot of assumptions baked into those addresses per the RFCs, which are kind of like our industry's electrical code. Using a broadcast address is "not up to code".
  - NoZebra120vClip 3y ago
    Long, long ago, SunOS, and possibly other Unixes, considered x.x.x.0 as a broadcast address as well. (Or I should say more properly, an all-zeroes host address.) 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.
  - Faaak 3y ago
    Please tell, then. But no, I don't see what is wrong with that. An outsider doesn't know the CIDR of the IP he's talking too, so it wouldn't change. It only matters for the last router in the loop, and if it's taken into account (because it's actually your infra), then it's okay
- iso1631 3y ago
  Most of my small sites are a pair of /24s, they have .255 as a loopback, split up the rest of the network into /26 or /27. 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
ogurechny 3y ago
The problem is that in the common case case those IP addresses are useless and serve no purpose. Broadcasts get broadcast because they are sent to broadcast MAC address. They can have IP packet with all-ones destination inside (which is different from a unicast packet sent to that same address via its unique MAC), they can have IP packet with a specific destination inside (well, maybe your ARP cache is malfunctioning, and you've forgotten the proper MAC address, but not the fact the host exists?), they can have arbitrary data (because you've invented our own protocol). You also need to call a different function or set some flag to make broadcast happen. It is possible that early IP stacks relied on a dedicated high-level broadcast address to prevent the need to handle all kinds of underlying networks in programs, but I'm not sure. (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.
- w7 3y ago
  You can get some of properties you describe with the behavior most people would want via a combination of anycast, some route exchange protocol (probably BGP), and ECMP.
- PinguTS 3y ago
  It seems you assume, that IP runs on Ethernet. But what IP that runs on a different data link layer that uses different address and doesn't know what a MAC address is?
  - ogurechny 3y ago
    Then it uses a different broadcast method that also does not depend on higher level IP addresses. 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.

c0nsumer 3y ago

I get this all the time at work... We have somewhat large subnets for clients (I think /22 and /23, and something much larger for our VPN pools) so I'll not-infrequently get "client has wrong IP address" things because they have a .0 or .1 or .255.

phh 3y ago

In school, I handled the network for students, we had a /22. I was still afraid to use .0 and .255.

rvnx 3y ago
It's logical: 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.

mike_d 3y ago

.0 and .255 are special. 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.

ilyt 3y ago
Wait till you see how people react to /31 and /31 ending with .0 > 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.
- mlyle 3y ago
  His point is that there's a pretty common journey: - 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...
  - schoen 3y ago
    The Busybox DHCP server had a special case where it wouldn't ever give out a .0 address, and I submitted a patch to remove that. I didn't even think about the possibility that someone might intentionally want that (to work around misbehavior of other devices). I don't think the person who added it was thinking that way, but I might be wrong. 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.)

fsckboy 3y ago

I don't think CIDR has anything to do with this. If you had a class B network, were you required to segment it into class C's? no, right? so, same problem, it's not clear what are your network and broadcast addresses without knowing your class, same as not knowing your cidr /n 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.

akira2501 3y ago
I think the original expectation was you wouldn't segment it, and that's why each address class has it's own defined range of ipv4 space. See rfc870, MITs /8 was listed as "temporary" (lol) and they had several separate specific class Bs. The ghost of /etc/networks rattles in the distance..

Akronymus 3y ago

> They just assume .0 and .255 are always special. 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.

caveman9000 3y ago

Just about every sysadmin I worked with thought in /24s. A lot of people are used to deploying the Linksys home routers and can't think about subnets or supernets. It used to blow peoples minds when they would get a .0 or .255 address because I had them on a /22 or /23. Even the last network engineer I replaced had multiple /24s all over the place across our WAN. I couldn't summarize routes because he didn't use sequential subnets, just random ones all over the place. Drove me nuts.