26

I understand the basic premise behind subnet masks, such as 255.255.255.0. But all the subnet examples I’ve seen have been (from left-to-right) contiguous 1s (HI bits). For instance, 255.255.0.0 (/16) translates to the following octets:

11111111 . 11111111 . 00000000 . 00000000

I believe that these bits must be contiguous, because the whole point of subnetting is to derive host ID and ranges of available device IDs. But it does have me wondering, might you ever have a subnet mask of, say, 255.17.255.0, or:

11111111 . 00010001 . 11111111 . 00000000
  • Would this ever happen? Or is it impossible for subnets to exist without contiguous 1s? If so, why?
  • Otherwise, if it is possible to do this, why would you (some concrete examples)?
  • @MSalters Just so you know, the automatic comment has now been changed to say "Possible duplicate of ..." so you don't need to manually enter the comment any more. ;-) – Chris Jester-Young Sep 30 '15 at 18:17
  • Short answer: yes, you are right. – Octopus Sep 30 '15 at 22:36
18

The section 3.1 in the RFC shows the allowed masks in the classless inter-domain routing. The bits have to be contiguous for the routing to work properly.

Also when thinking logically it would not really make sense to have strange random network masks.

| improve this answer | |
28

Yes, the easy way to think about it is that subnet masks are always 1s at the start. If a subnet-size-indicator doesn't have 1s at the start of the binary representation, then I would say that the subnet-size-indicator is not a proper “subnet mask,” using modern standards.

RFC 1219 states that the earlier RFC 950 permits non-contiguous bits. In fact, RFC 950 page 15 (section 3) clearly has an example which “illustrating non-contiguous subnet bits". However, there is no way to convert such subnets into CIDR notation. CIDR-style notation is what IPv6 has used (at least since RFC 1884 page 7, first sentence of section 2.4), so non-contiguous bits were never widely supported for IPv6 networks. RFC 1219’s method specifies that “subnet bits (mask = 1) are assigned from the most significant bit working towards the least". (The RFC 4632 section 3.1, mentioned by Sami’s answer, points to an official standard discussing CIDR notation.)

RFC 1878 page 2 shows the standard “subnet mask” notation for all the IPv4 subnets except for /0.

However, I'm going to elaborate a bit on Sami’s answer, looking into the “why” (with a concrete example, as the question did ask for)...

Some professional-grade Cisco equipment supports something called a “wildcard mask,” which inverts the bits. So a normal subnet could be represented by something called 00000000.00000000.00000000.11111111.

With Cisco’s wildcard masks, there was not a rule that all the zeros had to go first. So you could use 00000000.00000000.00000000.11111110.

That would end up creating a group that contained all even-numbered IP addresses.

This was actually important to know, because Cisco’s training covered it, and so the examination process for Cisco’s professional certifications might ask about such a thing.

However, I think it was mostly useless. Instead of dividing a network into half by using even-numbered addresses or odd-numbered addresses, you could just divide a network in half using low-numbered addresses and high-numbered addresses, by making normal subnets that are half as big.

Wildcard masks with non-contiguous bits were not terribly useful, and could be more challenging to work with. The point of the subnet mask bit set to 1 is to say that bit helps to identify which subnet a device is in. There’s no compelling reason to have those bits spread throughout the address, instead of just nicely grouping them at the start of the address. The result was that supporting these types of masks were an added complexity without much substantial benefit.

I guess Cisco eventually agreed that there’s no point to such non-traditional subnet masks, because they eventually dropped support for “wildcard masks". The older Pix firewalls support “wildcard masks,” but the newer ASA units use standard “subnet masks” instead.

I would not even try to make a network with non-contiguous “subnet bits” in the mask, because a lot of software would follow the newer trends/standards, and reject such a network design. Even if I was using older software, I would probably want my network to be able to be easily modified to be able to use newer software without needing to re-design the network. So, contiguous “subnet bits” are the only way to go.

If you're asked the question on a test, I would feel confident in saying that all the 1s need to be at the start of the address. That is what any sane tester would want the majority of students to be learning in this day and age.

| improve this answer | |
  • +1 - The only time I've seen wildcard masks used without all the 1's at the end are masks that were entered incorrectly. – Mark Henderson Sep 30 '15 at 21:19
2

RFC 950 says in chapter 2.2:

 To support subnets, it is necessary to store one more 32-bit
  quantity, called my_ip_mask.  This is a bit-mask with bits set in
  the fields corresponding to the IP network number, and additional
  bits set corresponding to the subnet number field.

 The code then becomes:

   IF bitwise_and(dg.ip_dest, my_ip_mask)
                               = bitwise_and(my_ip_addr, my_ip_mask)
         THEN
             send_dg_locally(dg, dg.ip_dest)
         ELSE
             send_dg_locally(dg,
                    gateway_to(bitwise_and(dg.ip_dest, my_ip_mask)))

so the proposal was about a simple bit operation which does not care about contiguous bits.

In 1985, CPU and memory were much more limited, so any more complex operations would simply not fit into the time.

It becomes even more explicit in chapter 3:

and that on network an 3-bit subnet field is in use (01011000), that is, the address mask is 255.255.255.88.

However, those RFCs seem to be outdated. On Windows 7 SP1 for example, it is not possible to set such a subnet mask:

Contiguous subnet mask required on Windows 7

Even on Windows XP SP2, this was not possible any more:

Subnet mask Windows XP SP2

The Windows 98 clone ReactOS however, allows setting the "strange" netmask:

ReactOS subnet mask

| improve this answer | |
1

I agree with the answer of @Sami Kuhmonen:

The section 3.1 in the RFC shows the allowed masks in the classless inter-domain routing. The bits have to be contiguous for the routing to work properly. Also when thinking logically it would not really make sense to have strange random network masks.

However, even if it is not desired or allowed, it is still possible to define a subnet mask of non-consecutive 1's. The reason behind this:
The network ID and host ID are calculated from IP address and subnet mask using the binary operations AND and XOR. Everything else is irrelevant.

I have tested that years ago on Win 2000, it works. Both computers had a 255.160.0.0 mask. They were in a LAN without router, so I cannot tell about router's behaviour (normally you can set the router's mask only in it's web interface, which will reject it).
You also cannot enter such an 'invalid' subnet mask into the corresponding field of the network settings; the GUI refuses to take it. But you can cheat by changing it in the registry directly. Afterwards reboot or disable+enable the NIC for the changes to become active.
The purpose of that all: uhm, probably none.

| improve this answer | |
  • Thanks for sharing, but this doesn't qualify as a standalone answer. It should be a comment on Sami Kuhmonen's answer. – agtoever Sep 30 '15 at 7:57
  • 2
    Way too long for a comment... Also I don't expect it to be marked as the answer. – Tobias Knauss Sep 30 '15 at 8:01
  • @agtoever: After editing and adding more details, I think it does qualify as an standalone answer now, because it has much info that is not part of other answers. – Tobias Knauss Sep 30 '15 at 8:12
  • "Works on one implementation" isn't a good answer, though. And it's not just "works on one OS", no, you apparently tested one particular PC with (importantly) one network. That means you have not verified whether the subnet routing code in Windows 2000 actually works, and that's precisely where network ID's are needed. Could you route between two non-adjacent 255.160.0.0 networks? – MSalters Sep 30 '15 at 14:40
  • @MSalters Works on one implementation still means it works. I didn't claim to speak for all possible OS of configurations. Also, what do you think how the packets get from one PC to another? The computer has to know the route. Therefore it must calculate whether the target computer is in the same subnet (send the packet directly) or far away (query the configured gateway for a route). // No, I don't think that I could do such a routing, because these subnet masks were not meant to be used. I demonstrated a case were it worked, but without different subnet. Maybe that works, too, who knows... – Tobias Knauss Sep 30 '15 at 23:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.