I understand that both CIDR and netmasks specify the network prefix of an IP address.

For example 192.168.1.123/24 is equivalent to 192.168.1.123 with the netmask 255.255.255.0

So, is CIDR just syntactic sugar for netmasks? What can we do using CIDR that we can't do using netmasks?

When it comes to IPv4, CIDR notation is just a different way to represent a netmask. There is no difference in the netmask presented in any of the following ways (i.e. it is the same netmask):

``````Dotted decimal notation: 255.255.255.0
CIDR notation:           /24
Binary notation:         11111111.11111111.11111111.00000000
Hex notation:            ff.ff.ff.00
``````

In your own documentation and design work, you can use any kind of notation you like, however keep in mind that if you use anything besides the first three, it will likely not be understood by anyone else. The first two are common, the third you normally only see in training/education and I only saw the last once long ago when working with a developer that preferred to work in hex.

As for support in device configurations, you will generally only see support for one (or possibly both) of the first two.

With IPv6, nearly everything will use CIDR notation, although I have seen (one time, although it makes little sense) someone use hex notation for the mask as well.

What can we do using CIDR that we can't do using netmasks?

Again, to be entirely clear, CIDR notation is just a different way to represent a netmask. What can we do with CIDR notation that we can't do with dotted decimal notation?

Represent the netmask with as little as two characters. It is simply easier and shorter to either type or write.

CIDR (Classless Inter-Domain Routing) means that you no longer pay attention to the network classes, and it can be used with network masks or the mask length (CIDR notation, which is what I think you mean).

Using CIDR notation simply makes it easier to read a prefix, and it can help prevent typos that can happen when typing out a network mask.

The original IP addressing specification actually allowed you to use non-consecutive network masks, so you had to spell out the mask. CIDR will not work with non-consecutive network masks, so simply using the mask length makes things easier to read and write.

IPv6 only uses CIDR and CIDR notation because it was developed after CIDR. The tricks with wildcard masks in IPv4 no longer are available with IPv6. It can be argued that those were just tricks, and if you depended on them, then you were not doing things correctly in the first place. I have run into people that were using the trick of odd and even addressing meaning something, and they were using that with IPv4 wildcard masks and wanted to do that with IPv6, but they were out of luck with that.

Addressing is much simplified under CIDR.

So, is CIDR just syntactic sugar for netmasks? What can we do using CIDR that we can't do using netmasks?

It's not simply syntactic, in as much as there are networking situations which can be written with netmasks which cannot be written with CIDR notation, the "nonconsecutive networks" which are thankfully hardly ever used. A non-consecutive netmask is something like 255.255.127.0, which doesn't fit the pattern for good netmasks, which all have N ones followed by (32-N) zeros.

If you find yourself wanting to use these "wacky netmasks", talk yourself out of it. They violate all current presumptions about how things work, and violate any number of standards. The only real reason for knowing about them is so that you know that certain mistakes are possible with netmask notation which are impossible to write in CIDR.

CIDR is really a much better way of expressing the network size. It conveys the right information in a concise way.

• You cannot use "nonconsecutive networks" for a subnet mask. They are not legal values as defined in the RFCs (see for example RFC 1878 for a list of potential subnet masks). You can use them for wildcard masks, or inverse masks, but not subnet masks if the vendor allows but the context of the OP's question is in regards to subnet masks. Commented Feb 27, 2018 at 22:02
• Of course I agree with you. However, one of the motivations for CIDR notation was so that you can't write such horrible masks. As a matter of practice, people did actually use these, usually for growing a subnet without renumbering the next subnet. OP's question was about the difference between CIDR and netmask notations., hence my answer. Commented Feb 28, 2018 at 9:55
• The use of non-contiguous masks was disallowed in RFC 1219 and RFC 1338. Since these preceded RFC 1519 and there is not mention of that being a motivation of CIDR in the RFC, I find little merit in the opening statement of your comment unless you can back this up in some way. Yes, non-contiguous masks were used very early, but this was rare, not in favor by network professionals of the time, and certainly shouldn’t be discussed as if it were still possible today. Commented Feb 28, 2018 at 15:23
• The best thing about CIDR notation is that you can't write the horrible things even by mistake. Sadly, it certainly is still possible to write horrible netmasks by mistake, which I have seen in the field, with the expected awful results. I have edited my answer to strengthen the advice against. Commented Feb 28, 2018 at 20:25
• On which platform have you seen this done? In my experience, trying to use a non-contiguous subnet mask results in an error/rejected input on any platform where I have seen someone accidentally input a non-contiguous one. Commented Feb 28, 2018 at 21:08

CIDR is equivalent to net mask and can be used interchangeably.

Unless you start talking about policy based routing. In that regard, it is different.

Say you make a rule for all traffic destined for the 10.10.10.0 255.255.255.0 network. All traffic destined for the .1 - .255 will be affected and rules applied.

If you make it a CIDR based rule 10.10.10.0/16 the rule only applies for that specific network. If the subnet is further subnetted to a /24 for example, and traffic is destined for 10.10.10.0/24 this will not match the CIDR rule and not be affected. But the same traffic with a route to the 10.10.10.0/16 the route rules will apply.

Hope this helps