39

I was just wondering about this question above and I would greatly appreciate it if someone can explain why 255.255.249.0 isn't a valid subnet mask.

6
  • 3
    Related: perhaps this wasn't always the case: retrocomputing.stackexchange.com/questions/18072/… Mar 31, 2021 at 11:12
  • what's a subnet mask, for you?
    – njzk2
    Mar 31, 2021 at 20:53
  • 3
    @ThomasWeller: Would be nice if someone also had sources on why eventually got forbidden. I assume part of it was being able to store prefix-based routing tables in an efficient-to-search way (tries), but I have found posts like this and this and this indicating that it might have been a major usability disaster as well. Apr 1, 2021 at 8:05
  • 2
    The binary representation of 249 has a hole in it. In particular, it would create a network out of all nearby addresses that have the same parity in the third number. That is, 10.0.0.0, 10.0.2.0, 10.0.4.0 and 10.0.6.0 would be in the same network, while 10.0.1.0 and 10.0.3.0 (etc) would be in another. This is a useless feature that would tricky to implement, so it is forbidden.
    – Bass
    Apr 1, 2021 at 21:01
  • 1
    Important note on @user1686's comment, I believe that TRIES is intended to be the plural of TRIE with no relation to TRY.
    – Ben Voigt
    Apr 1, 2021 at 22:00

3 Answers 3

101

It's not a valid subnet mask because it doesn't define a prefix. If you convert it to binary, you'll see that its '1'-bits (and/or its '0'-bits) are not all contiguous. This is explicitly forbidden by RFC 4632 (part of the CIDR specification).

The only outstanding constraint is that the mask must be left contiguous


For example, convert a valid netmask 255.255.248.0 to binary:

|    255    |    255    |    248    |     0     |
  1111 1111   1111 1111   1111 1000   0000 0000

All the "1"-bits are at the beginning, which means the mask always matches a prefix – the first 21 bits define the network. (This means the whole 255.255.248.0 netmask can be written as "/21" for short.)

Among other things, allows networks to be easily ordered by their netmask – a /24 route is always more specific than a /21 route.

Now convert your 255.255.249.0 to binary:

|    255    |    255    |    249    |     0     |
  1111 1111   1111 1111   1111 1001   0000 0000
                                  ↑

This one has some 1-bits, some 0-bits, and then some 1-bits again. It has 22 "network" bits, but so does 255.255.250.0, and so does 255.255.252.0 – if an address matches routes with all those netmasks, it's unclear which one of them has higher priority.

As people in the comments mention, this used to be allowed, but not for very long.

From: David Edelman on NANOG

You could be sure of two things when there were ambiguities in the routing tables:
1 - Every manufacturer knew how to handle them.
2 - Every manufacturer did it a different way.


Note: There is another thing often called filter or ACL masks, where this restriction doesn't apply because filter masks don't have the "subnet" semantics associated with them (e.g. longest-prefix match) – they only either match or don't. For example, iptables would accept a filter mask 255.255.249.0 just fine.

6
  • Hmm, that's actually interesting about iptables. The man page says "The mask can be either an ipv4 network mask or a plain number [mask width]", which seems to imply it would only take proper contiguous masks. But you're right, it at least the rules load even with a non-contiguous one.
    – ilkkachu
    Mar 31, 2021 at 8:29
  • 3
    @Joshua Subnet masks predate CIDR, so that makes sense. From the CIDR wiki article (emphasis mine): "A subnet mask encodes the same information as a prefix length but predates the advent of CIDR. In CIDR notation, the prefix bits are always contiguous. Subnet masks were allowed by RFC 950 to specify non-contiguous bits until RFC 4632:Section 5.1 stated that the mask must be left contiguous." RFC 950 has an example with non-contiguous 255.255.255.88 mask.
    – JoL
    Mar 31, 2021 at 15:22
  • 2
    The consequence of the prefix requirement is that CIDR subnet masks expressed in dotted-decimal are always 0 or more times 255, 0 or 1 of either 128, 192, 224, 240, 248, 252 or 254, and 0 or more times 0 (for a total of 4 numbers, of course), in that order.
    – jcaron
    Mar 31, 2021 at 16:00
  • 1
    I once used a non-prefix IPv6 mask to define an evil bit for a client's network addressing schema (if bit 63 was set, it was a customer-access subnet). Mar 31, 2021 at 23:17
  • 1
    @JoL: There is also RFC 1519 from 1993 which already has the sentence "The only outstanding constraint is that the mask must be left contiguous.", so the "until RFC 4632" part is not exactly right. Apr 1, 2021 at 10:11
17

The mask needs to contiguously have high order bits on to mask the network address under which the subnet addresses are. 249 does not have this property, as it is 11111001 in binary, there are zeroes between the ones.

5

Formally speaking, it actually is a valid subnet mask. As the name implies, a subnet mask is simply a bitmask pattern (any pattern) that tells you which portions of the address define the network as a whole.

The reason that you never see more than eight distinct octet values is that starting very early on, the convention was to simply use the leftmost bits for the network and the remainder for host or sub-network addressing. This allowed a simple rule that everyone could remember and which told you which bits you could use if you needed to subdivide a network.

As far as standards go, we started with "classful" (not named at the time) networks, with classes A, B, and C being defined by their first one, two, or three octets, respectively, and allocated based on the size of who requested it. As far as I know, a fair amount of network kit early on was optimized in ways that only really worked on octet boundaries (classes D and E weren't used much and could still be handled that way).

This was eventually replaced by CIDR (Classless Inter-Domain Routing), which does mandate that the netmask be "contiguous 1s to the left". Among other reasons, it guaranteed that you could "roll up" someone's routing announcements into a smaller routing table entry if you knew that all of your routes for their networks went to the same port, even if they only announced separate route entries for each one.

This was especially important for mid-sized / regional ISPs who had multiple interconnects with the "tier 1" providers but often ended up with all of the routes for someone across the country effectively pointing to a single outbound route — while their RIB (routing information base, the complete set of routing info) would still know about all of the separate routes, their FIB (forwarding information base, the thing which drives the actual hardware at wire speed) could be kept smaller and thus faster. If you had mid-grade hardware, which was common, that could really make quite a lot of difference in how efficient your hardware was and how fast you could switch things.

TL;DR: A netmask really is a mask, and can have an arbitrary pattern, but in practice you'll basically never see one that isn't "all ones to the left".

3
  • 3
    Most systems now conform to CIDR, even those which still show subnet mask notation to the user, so in practice you really shouldn't see one that isn't... Apr 2, 2021 at 6:17
  • By the "Inter-Domain" portion of the acronym, does that mean that you can still define non-contiguous subnet masks within your own private network? I wasn't even aware of this change... I learned subnetting way back in 1999, when you could use any bitmask you liked, though I never had a reason to use anything non-contiguous, I knew that you could if you wanted. Apr 2, 2021 at 21:58
  • 1
    @DanHenderson formally speaking, within one domain of control you can do whatever you darn well please — that's one of the often-overlooked foundational principles of the Internet that really made all the difference. It is only when (and where) you want to actually talk to someone else that any of the standards matter, or even have anything to say whatsoever beyond advising about best practices. That said… there is definitely kit (software and hardware) that won't cope at all well with it anymore, simply because it is so unlikely to ever be legitimately encountered. Apr 3, 2021 at 6:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .