14

Given a prefix Y, it's easy to calculate the corresponding netmask: Put Y times a set bit, and then fill up "to the right" with zeros until one has 32 bits (IPv4) in total.

Example:

Prefix 24, thus netmask 11111111 11111111 11111111 00000000 or 255.255.255.0.

Can there be a netmask with a different bit pattern, such as

  • 00000000 11111111 00000000 11111111 (0.255.0.255)
  • 00000000 11111111 11111111 11111111 (0.255.255.255)
  • 11111111 11111111 11111111 00000001 (255.255.255.1)

Specifying a "prefix" obviously wouldn't work for these cases.

(I'm pretty sure the answer is "NO", but I'm writing some network code, and this needs to work in all possible cases, so I want to be 101% sure.)

Daniel Jour
  • 253
  • 1
  • 6

4 Answers4

11

RFC950 states that

Since the bits that identify the subnet are specified by a bitmask, they need not be adjacent in the address. However, we recommend that the subnet bits be contiguous and located as the most significant bits of the local address.

Most devices follow this recommendation as far as to enforce it. I have only managed to use non-contiguous subnet masks on Linux-only networks back in 2012; the Windows, OSX, Cisco and HP devices I tested didn't handle/allow it.

Community
  • 1
Filip Haglund
  • 238
  • 2
  • 7
  • 3
    I believe this has been superseded by [RFC1519](https://tools.ietf.org/html/rfc1519), which explicitly requires a contiguous mask. – user1686 Sep 11 '17 at 06:10
  • 1
    @grawity Could be the case. Found "The only outstanding constraint is that the mask must be left contiguous." when talking about CIDR, but didn't read enough to get the context. – Filip Haglund Sep 11 '17 at 10:01
6

If you are using prefixes and networks, then the answer is no, the bits need to be contiguous. There are cases where a wildcard mask (inverse of mask) can be used, e.g. Cisco ACLs, and those can be any bit pattern. For instance, you could block traffic from all the odd numbered hosts on a network. This seems to still be taught, but I have not seen it used very often (although I have seen it) in the real world.

Ron Maupin
  • 98,218
  • 26
  • 115
  • 191
4

No. A netmask is a continuous series of ones.

(The others are "wildcard" patterns.)

Ricky
  • 31,438
  • 2
  • 43
  • 84
  • 1
    This is not true. 30 years ago there were lots. There still may be some in operation. – MAP Jul 06 '16 at 02:02
  • 2
    I highly doubt that. No modern routing hardware will allow it. And routers from the 80s will have numerous problems with the way IP works today. (Been there. Told ya' not use the all zero subnet -- even in the late '90s that was a problem) The only two devices I still have from that era *will not* accept a non-contiguous netmask. (WTI pdus, still around because they have 10bT ports. Nothing talks to them, most of all *the internet*.) – Ricky Jul 06 '16 at 05:37
3

When TCP/IP first came out and got widespread, there were actually a lot of subnets with non-contiguous masks. But as addresses became scarce, the overhead to the rest of the net to allow global routing of these prefixes rather than forcing everything to be only prefix based; was too much and the global network changed to only supporting prefixes. There may actually still be legacy networks that use non-contiguous masks internally (many IGPs support this, still). But, when such a network connects to The Internet, it has a single prefix that covers all of them, that it advertises into BGP. And, of course, EGP (the predecessor to BGP) only supported Classful addressing.

I know several players with original issue Class A networks that used non-contiguous netmasks internally for one reason or another. I just don't know if any of them are still doing it. A lot of them don't even exit any more. The ARPAnet had an internal netmask of 255.0.0.255 (IIRC).

MAP
  • 346
  • 1
  • 8
  • 2
    NONSENSE. This has *nothing* to do with CIDR, or classes, or aggregation. A netmask has *ALWAYS* been contiguous. – Ricky Jul 06 '16 at 01:52
  • 1
    @RickyBeam You are definitely uninformed. In my 30 years doing Network Engineering I have encountered a large number of non-contiguous netmasks. In my answer I even gave an example (possibly the only one that's not under NDA with a client). – MAP Jul 06 '16 at 02:00
  • 2
    @MAP Would you happen to have any supporting reference for this? Perhaps a legacy RFC? Even a relevant news article might provide some context for debate. – Ryan Foley Jul 06 '16 at 02:51
  • 1
    Sorry, my 30 year old documentation is packed away, and correcting your incorrect memory of that time (where were you in 1982?) is not worth the effort to go scrounging through it. – MAP Jul 06 '16 at 03:06
  • 7
    See [RFC 950](https://tools.ietf.org/html/rfc950), for example. Page 15 gives an example with a netmask of 255.255.255.88. – Ross Presser Jul 06 '16 at 03:14
  • Or just Google the terms "non contiguous netmask". – Ross Presser Jul 06 '16 at 03:15
  • 2
    Specifically, I found RFC1219 which is about the topic (although there wasn't really a specific place where it says that non-contig masks had existed, the whole text implies that Paul was aware there were). Also in RFC1519 (second paragraph from the bottom of page 12) Vince specifically mentions that CIDR is adding the constraint of contiguous masks, implying that he knew there were places that were not. And finally an email on the FreeBSD list: http://lists.freebsd.org/pipermail/freebsd-net/2004-April/003648.html mentions having a client in 2004 with it. – MAP Jul 06 '16 at 03:53
  • 4
    I think page 12 of RFC 1519 actually hurts your case since the only relevant sentence is, "*The only outstanding constraint is that the **mask must be left contiguous***." (Emphasis mine) Since the mask is implied/assumed by the class in classful routing, and only three contiguous masks were used, and the RFC on CIDR specifies contiguous masks, it seems like your answer is wrong. The FreeBSD list post is a mystery to me. – Todd Wilcox Jul 06 '16 at 04:24
  • 1
    OK, I guess I'm adding my personal knowledge of the author. I know he actually knew about non-contiguous masks in use, I think he even ran one of those nets once. And since the old masks always had at least one bit on the left, you couldn't possibly ever have a right contiguous mask, so I'm not sure why he worded it in such an ambiguous way (other than that everyone in the IETF probably realized what was intended). I agree that this paragraph might not survive the RFC process as it stands now, except it was kept in tact in the replacement RFC. – MAP Jul 06 '16 at 04:31
  • 3
    The replacement RFC is 4632: https://tools.ietf.org/html/rfc4632 Note that slash notation is discussed and used, and the term "prefix **length**" appears several times, neither of which would make any sense at all if non-contiguous masks were supported. It's clear from RFC 950 that there could have been systems in the early days that used non-contiguous masks, but bringing that up will not help the asker understand how TCP/IP currently works, and could be very confusing. – Todd Wilcox Jul 06 '16 at 04:44
  • 3
    *Since the bits that identify the subnet are specified by a bitmask, they need not be adjacent in the address. **However, we recommend that the subnet bits be contiguous and located as the most significant bits of the local address**.* While that does not carry the SHOULD/MUST wording used today, that is exactly how everyone has built modern subneting capabilities. Over 3 decades of networking, I have never encountered technology that allows discontiguous subnets. – Ricky Jul 06 '16 at 05:02
  • 1
    I will repeat that RFC 950 has an actual example giving a non-contiguous netmask. – Ross Presser Jul 06 '16 at 21:01