Special Address Masks

TCP/IP Protocols Overview  |  IP  |  ARP  |  ICMP  |  

Address Masks That Don't End on an Eight-Bit Boundary

If we recall that a mask of actually represents a binary number then we can easily understand how the mask value need not end on an eight-bit boundary. For example, consider a Class B network In this network I want to have up to 1024 hosts per subnetwork. This means I will need 10 bits to represent the host portion of the address (since 2 raised to the 10th power = 1024). I need 10 "0" bits in the mask to represent the host portion, the remainder will be split between the network and subnetwork identifiers. Since Class B uses the first 16 bits to identify the network this leaves 6 bits to represent the subnetwork. I can have up to 64 different values in the subnet field and up to 1024 values in the host field. The address mask looks like this:

11111111 11111111 11111100 00000000

There are three fields that are defined in this mask. Because we are applying this to a Class B network the first 16 bits represent the network. The next 6 bits represent the subnetwork, and the last 10 bits represent the host.

When each octet is converted to decimal the mask value becomes:

11111111 11111111 11111100 00000000
255. 255. 252. 0

Any number of bits can be used to identify the subnetwork. Some other examples (in Class B) include:

  • - Nine bits for the subnet, seven bits for the host
  • - Ten bits for the subnet, six bits for the host

The exact same scheme applies to Class A but only the first eight bits are included in the network part. This allows many more combinations for subnetting. Some examples in Class A include:
  • - (Typical) Eight bits for the subnet, sixteen bits for the host.
  • - Six bits for the subnet, eighteen bits for the host.
  • - Fourteen bits for the subnet, ten bits for the host.

When considering the subnetting in a network it is necessary to convert the dotted-decimal octet strings for the addresses and the mask back into binary to compare the fields and evaluate the results.

WildPackets is now Savvius

For the latest information on our products and services please go to our new site at www.savvius.com.

We are in the process of migrating some of our legacy content to our new site, so Wildpackets.com is still available. If the content you are looking for has already been migrated we will automatically redirect you.