Hello,
On Mon, May 22, 2023 at 08:26:47PM -0400, Dan Ritter wrote:
> Tom Reed wrote:
> > If I know the network addr: 192.168.1.0
> > And know the broadcast addr: 192.168.1.255
> > Then I should have the possibility to cal the netmask addr: 255.255.255.0
> >
> > Isn't it?
>
> No. What's the netmask if you have:
>
> IP: 192.168.255.132
> broadcast: 192.168.255.255 ?
It's 255.255.0.0.
Specifying a broadcast address does completely define the network
range. If you know that 192.168.255.255 is the broadcast then the
network can only be 192.168.0.0/16.
You do not need to know even the network address; it's implied.
Since the broadcast is the all-ones address, change them to all
zeroes and that's your network address. So if your KNOW your
broadcast address is 192.168.255.255 then you ALSO KNOW that your
network address is 192.168.0.0/16 because there are 16 bits of 1s
there.
The reverse is not true: if you KNOW the network address is
192.168.0.0 but NOT the prefix/networks (how many 1s there are) then
you do not know where the broadcast address is. It could easily be:
192.168.0.0/31 = 192.168.0.0 → 192.168.0.1 no broadcast
192.168.0.0/30 = 192.168.0.0 → 192.168.0.2 broadcast 192.168.0.3
192.168.0.0/29 = 192.168.0.0 → 192.168.0.4 broadcast 192.168.0.5
.
.
192.168.0.0/24 = 192.168.0.0 → 192.168.0.254 broadcast 192.168.0.155
.
.
192.168.0.0/21 = 192.168.0.0 → 192.168.7.254 broadcast 192.168.7.255
.
.
192.168.0.0/16 = 192.168.0.0 → 192.168.255.254 broadcast 192.168.255.255
…and so on. Without the netmask or prefix you don't know where it
ends, but given a broadcast address then you DO know the netmask and
can work it out.
If given just an address and not told whether it is a broadcast
address or not then you are correct - you can't tell. If the only
information you have is "192.168.0.255" then you don't know if that
is a host address in a network bigger than /24. e.g. 192.168.0.0/23
goes from 192.168.0.0 → 192.168.1.255 and there, 192.168.0.255 would
just be another usable host address. But if you are told that
192.168.0.255 is definitely the broadcast, then this has completely
defined the rest.
Generally in this day and age we would be better off sticking to
prefix lengths not netmasks, i.e. "/24" not "255.255.255.0". And
those who have said this is backwards do have a point - you would
not normally start by specifying the broadcast address since
normally what is important to you is how many addresses are needed.
The netmask and broadcast addresses follow from that. But it's just
maths and it works both ways.
Also as regards /32 addresses, they are normally used for point to
point interfaces such as PPP, VPNs or virtual Ethernets, where every
packet you send that is not destined for yourself will always just
hit the other end of the link. While you CAN use any prefix, if it
is a point-to-point link with no need to directly interact with the
other end device then it is a waste to use anything but a /32. Such
links do not have a broadcast domain; they do not have or need a
network or broadcast address and as they accept every packet that
isn't addressed to itself they only need 1 address.
Here is an example of a real PPP interface I have here (IPs changed
however):
# ip -4 addr show dev ppp0
20: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast
state UNKNOWN qlen 3
inet 192.168.218.242 peer 81.187.81.187/32 scope global ppp0
# ip -4 ro show default
default dev ppp0 scope link
As you can see, the interface does not have a prefix because it's
not got a broadcast domain. There is no such concept as a broadcast
or network address here in this situation. The other end is
81.187.81.187/32 regardless. Every packet not destined for
192.168.218.242 obeys the default route, which is to an interface
(ppp0) not to an IP.
This could have been done with a /31 but that would have wasted a
lot of IPs: There'd be one for the customer and its pair at the ISP
end, instead of the /32 situation where the ISP end is the same for
all customers at that location. It could have been done with a /30
but that would have been even worse: it would burn 4 IPs per
customer for no useful reason. It could be done with any other valid
network and would waste more and more IPs the bigger the network is,
but it would still work.
There is still some legacy equipment that doesn't support /31s on
networks with only two devices despite RFC 3021 being more than 20
years old now.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
