# Binary Numbers and Subnet Masks

### Gary C. Kessler October 2000 (Updated: June 2016)

#### An edited version of this paper appeared as a sidebar to the article "Hanging Out With the Classless Crowd" by W. Heldman, with the title "Binary Numbers and Subnet Masks" in Windows 2000 Magazine, January 2001.

To truly understand how to derive IP masks and apply them to addresses, you must understand binary numbers and how to convert them to decimal.

Let's start with something that we're all pretty comfortable with, namely decimal (base 10) numbers. Back when we were kids, we were taught that each digit in a decimal number stood for a different power of 10. The number 7836, for example, is interpreted as follows:

 7ū103 + 8ū102 + 3ū101 + 6ū100 = 7ū1000 + 8ū100 + 3ū10 + 6ū1 = 7000 + 800 + 30 + 6 = 7836

Now this is pretty simplistic, I admit, but understanding this is the basis for understanding any numeric base. In particular, it will help us understand binary (base 2).

We interpret binary numbers in exactly the same way as decimal numbers, except that each column of a binary number represents a different power of 2 rather than 10. We can easily convert a binary number to a more understandable decimal value. Let's first review the powers of 2 (we're only going to go as far as we need to for an 8-bit byte because IP addresses have 8-bit bytes).

 20 1 21 2 22 4 23 8 24 16 25 32 26 64 27 128

Given this information, we can convert the binary number 11010011 to decimal as follows.

 110100112 = 1ū27 + 1ū26 + 0ū25 + 1ū24 + 0ū23 + 0ū22 + 1ū21 + 1ū20 = 1ū128 + 1ū64 + 0ū32 + 1ū16 + 0ū8 + 0ū4 + 1ū2 + 1ū1 = 128 + 64 + 16 + 2 + 1 = 21110

Variable length subnet masking (VLSM) is essential to support classless addressing. VLSM allows us to build masks that are of pretty much any length and are not restricted to the byte boundaries of classful addressing. In this ways, we can either aggregate many NET_IDs into a single entry in a routing table or we can segment one Class C address, for example, into several subaddresses.

11000000 10101000 00010010 00110111

11111111 11111111 11111111 00000000

It's easy for us to look at this by examination and see that the all-ones bytes refer to the network ID portion of the address and we can see that the NET_ID is 192.168.18 (which we sort of knew anyway because the first three bytes of a Class C are the NET_ID). In VLSM and Classless Inter-Domain Routing (CIDR) notation, the mask would be referred to as a /24 ("slash-24"), because there are 24 one bits in the mask.

But how does this really work? When the software needs to determine the NET_ID portion of this address (for routing purposes, for example), the 32-bit subnet mask is logically ANDed with the 32-bit address, the result being that any address bit corresponding with a 1-bit in the subnet mask maintains its value (either 0 or 1) and any address bit corresponding with a 0-bit in the subnet mask is forced to 0. So let's carry out that operation for the Class C address and mask above:

 Address: 11000000 10101000 00010010 00110111 Subnet Mask: 11111111 11111111 11111111 00000000 AND -------- -------- -------- -------- Network ID: 11000000 10101000 00010010 00000000

After performing this calculation, the software now knows that the NET_ID is 192.168.18.0.

Let's now try a broader example. Since masks are created by writing some number of ones followed by zeroes, an all-ones byte will have the value 255 and an all-zeroes byte will have a value of 0, as shown above. But a VLSM may not have a mask that falls on a byte boundary so one of the bytes may have a value other than 0 or 255. In fact, an 8-bit byte has only eight possible subnet values as we increase the number of one bits from the left:

 10000000 128 11000000 192 (128+64) 11100000 224 (128+64+32) 11110000 240 (128+64+32+16) 11111000 248 (128+64+32+16+8) 11111100 252 (128+64+32+16+8+4) 11111110 254 (128+64+32+16+8+4+2) 11111111 255 (128+64+32+16+8+4+2+1)

Variable-bit subnet masks give us a great deal of flexibility in carving out multiple subnets within the Class C space. Suppose that we want to create eight subnetworks in the 192.168.18.0 address space. We just add 3 bits to the length of the 24-bit subnet mask. Why 3 bits? Because 23 = 8.

So now we have a /27, or 255.255.255.224, subnet mask. Recall that the first 24 bits are all ones, so the first three bytes will be 255. The fourth byte will have 3 ones in it and, therefore, a value of 224 from the table above.

Because we used 3 bits of the final byte as a mask (sometimes called a subnet ID), the host IDs are limited to 5 bits. Thus, each subnet is limited to 25 = 32 hosts. (In fact, each subnet in this example is limited to 30 hosts; the all-zeroes HOST_ID is never assigned to a host since it is used as the 0 placeholder for the network number and the all-ones HOST_ID is reserved as the subnet's broadcast address.)

But we still have one more significant problem to solve, namely, to identify the subnet numbers. Using the /27 mask does indeed give us eight subnets, but we also need to know their numbers if we're going to build a network diagram or a routing table. The eight possible values of the 3-bit subnet mask are:

 000 0 001 1 010 2 011 3 100 4 101 5 110 6 111 7

Therefore, the eight possible values of the final address byte are (again, the spaces are only for readability):

 000 00000 0 001 00000 32 010 00000 64 011 00000 96 (64+32) 100 00000 128 101 00000 160 (128+32) 110 00000 192 (128+64) 111 00000 224 (128+64+32)

So we now have our 8 NET_IDs that can be used for routing purposes:

 192.168.18.0/27 192.168.18.32/27 192.168.18.64/27 192.168.18.96/27 192.168.18.128/27 192.168.18.160/27 192.168.18.192/27 192.168.18.224/27

For obvious reasons, you should always indicate the subnet mask along with the address itself, as I've done above, to avoid ambiguity; the address 192.168.18.128, for example, is a valid address that can be used with a /25, /26, /27, /28, /29, or /30 subnet mask.

Gary C. Kessler is a consultant and chair of the Security Studies & International Affairs Dept. at Embry-Riddle Aeronautical University in Daytona Beach, Florida. You can reach him at gck@garykessler.net.