Are subnets always contiguous 1s? [duplicate]

Question

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)?

Answer 1

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.

Answer 2

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.

Answer 3

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:

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

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

Answer 4

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.