4 ms·

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, respec

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.

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.