CIDR

CIDR Information

Presently, we all use IPv4. The format of IPv4 is the following:

A.B.C.D

Where letters 'A' through 'D' are 8-bit values. In English, this means each digit can have a value of 0 to 255. Example:

129.56.4.234

Digits are called octets. Oct meaning 8, hence 8-bit values. An octet cannot be greater than 255, and cannot be less than 0 (eg. a  negative number).

CIDR stands for "classless inter domain routing", details covered in RFC's 1518 and 1519. It was introduced mainly due to waste within A and B classes space. The goal was to make it possible to use smaller nets than it would seem from (above) IP classes, for instance by dividing one B class into 256 "C like" classes. The other goal was to allow aggregation of routing information, so that routers could use one aggregated route (like 194.145.96.0/20) instead of advertising 16 C classes.

Class A are all these addresses which first bit is "0", bitmap: 0nnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh (n=net, h=host) IP range is 0.0.0.0 - 127.255.255.255

Class B are all these addresses which first two bits are "10", bitmap: 10nnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh (n=net, h=host) IP range is 128.0.0.0 - 191.255.255.255

Class C are all these addresses which first three bits are "110", bitmap: 110nnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh (n=net, h=host) IP range is 192.0.0.0 - 223.255.255.255

Class D are all these addresses which first four bits are "1110", this is multicast class and net/host bitmap doesn't apply here IP range is 224.0.0.0 - 239.255.255.255 I bet they will never IRC, unless someone creates multicast IRC :)

Class E are all these addresses which first five bits are "11110", this class is reserved for future use IP range is 240.0.0.0 - 247.255.255.255

So, here is how CIDR notation comes into play.

For those of you who have real basic exposure to how networks are set up, you should be aware of the term "netmask." Basically, this is a IPv4 value which specifies the "size" of a network. You can assume the word "size" means "range" if you want.

A chart describing the different classes in CIDR format and their wildcard equivalents would probably help at this point:

CIDR version	dot notation (netmask)	Wildcard equivalent - A.0.0.0/8	A.0.0.0/255.0.0.0	A.*.*.* or  A.* A.B.0.0/16	A.B.0.0/255.255.0.0	A.B.*.* or  A.B.* A.B.C.0/24	A.B.C.0/255.255.255.0	A.B.C.* or  A.B.C.* A.B.C.D/32	A.B.C.D/255.255.255.255	A.B.C.D

The question on any newbies mind at this point is "So what do all of those values & numbers actually mean?"

Everything relating to computers is based on binary values (1s and zeros). Binary plays a *tremendous* role in CIDR notation. Let's break it down to the following table:

A           B            C            D /8  == 11111111. 00000000 .  00000000  .  00000000  == 255.0.0.0 /16 == 11111111  .  11111111  .  00000000  .  00000000  == 255.255.0.0 /24 == 11111111  .  11111111  .  11111111  .  00000000  == 255.255.255.0 /32 == 11111111  .  11111111  .  11111111  .  11111111  == 255.255.255.255

The above is basically a binary table for the most common netblock sizes. The "1"s you see above are the 8-bit values for each octet. If you split an 8-bit value into each of it's bits, you find the following:

00000000 ^^^^^^^^_ 1sts place (1)
 * __ 2nds place (2)
 * ___ 3rds place (4)
 * ____ 4ths place (8)
 * _____ 5ths place (16)
 * ______ 6ths place (32)
 * _______ 7ths place (64)
 * ________ 8ths place (128)

Now, since computers consider zero a number, you pretty much have to subtract one (so-to-speak; this is not really how its done, but just assume it's -1 :-) ) from all the values possible.  Some  examples of decimal values in binary:

15 == 00001111  (from left to right: 8+4+2+1) 16 == 00010000  (from left to right: 16) 53 == 00110101  (from left to right: 32+16+4+1) 79 == 01001111  (from left to right: 64+8+4+1) 254 == 11111110 (from left to right: 128+64+32+16+8+4+2)

So, with 8 bits, the range (as I said before) is zero to 255.

If none of this is making sense to you at this point, you should back up and re-read all of the above. I realize it's a lot, but it'll do you some good to re-read it until you understand :-).

So, let's modify the original table a bit by providing CIDR info for /1 through /8:

A           B            C            D /1  == 10000000. 00000000 .  00000000  .  00000000  == 128.0.0.0 /2  == 11000000  .  00000000  .  00000000  .  00000000  == 192.0.0.0 /3  == 11100000  .  00000000  .  00000000  .  00000000  == 224.0.0.0 /4  == 11110000  .  00000000  .  00000000  .  00000000  == 240.0.0.0 /5  == 11111000  .  00000000  .  00000000  .  00000000  == 248.0.0.0 /6  == 11111100  .  00000000  .  00000000  .  00000000  == 252.0.0.0 /7  == 11111110  .  00000000  .  00000000  .  00000000  == 254.0.0.0 /8  == 11111111  .  00000000  .  00000000  .  00000000  == 255.0.0.0

At this point, all of this should making a lot of sense, and you should be able to see the precision that you can get by using CIDR at this point. If not, well, I guess the best way to put it would be that wildcards always assume /8, /16, or /24 (yes hello Piotr, we can argue this later: I am referring to IPs *ONLY*, not domains  or FQDNs :-) ).

This table will provide a reference to all of the IPv4 CIDR values

cidr|netmask (dot notation) +- /1 | 128.0.0.0 /2  | 192.0.0.0 /3  | 224.0.0.0 /4  | 240.0.0.0 /5  | 248.0.0.0 /6  | 252.0.0.0 /7  | 254.0.0.0 /8  | 255.0.0.0 /9  | 255.128.0.0 /10 | 255.192.0.0 /11 | 255.224.0.0 /12 | 255.240.0.0 /13 | 255.248.0.0 /14 | 255.252.0.0 /15 | 255.254.0.0 /16 | 255.255.0.0 /17 | 255.255.128.0 /18 | 255.255.192.0 /19 | 255.255.224.0 /20 | 255.255.240.0 /21 | 255.255.248.0 /22 | 255.255.252.0 /23 | 255.255.254.0 /24 | 255.255.255.0 /25 | 255.255.255.128 /26 | 255.255.255.192 /27 | 255.255.255.224 /28 | 255.255.255.240 /29 | 255.255.255.248 /30 | 255.255.255.252 /31 | 255.255.255.254 /32 | 255.255.255.255

So, let's take all of the information above, and apply it to a present-day situation on IRC.

Let's say you have a set of flooding clients who all show up from the following hosts. For lack-of a better example, I'll use a subnet here at Best:

nick1 (xyz@shell9.ba.best.com)  [206.184.139.140] nick2 (abc@shell8.ba.best.com)  [206.184.139.139] nick3 (foo@shell12.ba.best.com) [206.184.139.143]

Most people will assume the they were all in the same class C  (206.184.139.0/24  or  206.184.139.*).

This, as a matter of fact, is not true. Now, the reason *I* know this is solely because I work on the network here; those IPs are not delegated to a class C, but two portions of a class C (128 IPs each). That means the class C is actually split into these two portions:

Netblock              IP range 206.184.139.0/25      206.184.139.0   to 206.184.139.127 206.184.139.128/25    206.184.139.128 to 206.184.139.255

For the record, 206.184.139.0 and 206.184.139.128 are both known as "network addresses" (not to be confused with "netblocks" or "Ethernet  hardware addresses" or "MAC addresses"). Network addresses are *ALWAYS EVEN*.

206.184.139.127 and 206.184.139.255 are what are known as broadcast addresses. Broadcast addresses are *ALWAYS ODD*.

Now, the aforementioned list of clients are in the 2nd subnet shown above, not the first. The reason for this should be obvious.

The remaining question is, "Well that's nice, you know what the netblock is for Best.  What about us?  We don't know that!"

Believe it or not, you can find out the network block size by using whois -h WHOIS.ARIN.NET on the IP in question. ARIN keeps a list of all network blocks and who owns them -- quite useful, trust me. I think I use ARIN 5 or 6 times a day, especially when dealing with D-lines. Example:

$ whois -h whois.arin.net 206.184.139.140 Best Internet Communications, Inc. (NETBLK-NBN-206-184-BEST) 345 East Middlefield Road Mountain View, CA 94043

Netname: NBN-206-184-BEST Netblock: 206.184.0.0 - 206.184.255.255 Maintainer: BEST

Does this mean you should D-line 206.184.0.0/16? Probably not. That's an entire class B-sized block, while you're only trying to deny access to a subnetted class C.

So then how do you get the *real* info? Well, truth is, you don't. You have to pretty much take a guess at what it is, if ARIN reports something that's overly vague. Best, for example, was assigned the above class B-sized block. We can subnet it however we want without reporting back to ARIN how we have it subnetted. We own the block, and that's all that matters (to ARIN).

Not all subnets are like this, however. Smaller subnets you may find partitioned and listed on ARIN; I've seen /29 blocks for DSL customers show up in ARIN before.

So, use ARIN any chance you get. The more precision the better!

Now, there is a small issue I want to address regarding use of CIDR notation. Let's say you D-line the following in CIDR format (hi sion ;-) ):

205.100.132.18/24

Entries like this really makes my blood boil, solely because it adds excessive confusion and is just basically pointless. If you examine the above, you'll see the /24 is specifying an entire class C -- so then what's the purpose of using .18 versus .0?

There IS no purpose. The netmask itself will mask out the .18 and continue to successfully use 205.100.132.0/24.

Doing things this way just adds confusion, especially on non-octet- aligned subnets (such as /8, /16, /24, or /32). Seeing that on a /27 or a /19 might make people go "wtf?"

I know for a fact this doc lacks a lot of necessary information, like how the actual netmask/CIDR value play a role in "masking out" the correct size, and what to do is WHOIS.ARIN.NET returns no netblock information but instead a few different company names with NIC handles. I'm sure you can figure this stuff out on your own, or just ask an administrator friend of yours who DOES know. A lot of us admins are BOFH types, but if you ask us the right questions, you'll benefit from the answer quite thoroughly.

Oh, I almost forgot. Most Linux systems use a different version of "whois" than FreeBSD does. The syntax for whois on Linux is "whois @whois.arin.net", while under FreeBSD it is  "whois -h whois.arin.net "  Debian uses yet another version of whois that is incompatible with the above syntax options.

Note that the FreeBSD whois client has shortcuts for the most commonly used whois servers. "whois -a " is the shortcut for ARIN.

Also note that ARIN is not authoritative for all IP blocks on the Internet. Take for example 212.158.123.66. A whois query to ARIN will return the following information:

$ whois -h whois.arin.net 212.158.123.66 European Regional Internet Registry/RIPE NCC (NET-RIPE-NCC-) These addresses have been further assigned to European users. Contact information can be found in the RIPE database, via the WHOIS and TELNET servers at whois.ripe.net, and at  http://www.ripe.net/db/whois.html

Netname: RIPE-NCC-212 Netblock: 212.0.0.0 - 212.255.255.255 Maintainer: RIPE

This query tells us that it is a European IP block, and is further handled by RIPE's whois server. We must then query whois.ripe.net to get more information.

$ whois -h whois.ripe.net 212.158.123.66

% Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html

inetnum:    212.158.120.0 - 212.158.123.255 netname:    INSNET-P2P descr:      Point to Point Links for for London Nodes country:    GB --snip--

This tells us the actual IP block that the query was a part of.

Other whois servers that you may see blocks referred to are: whois.ripn.net for Russia, whois.apnic.net for Asia, Australia, and the Pacific, and whois.6bone.net for IPv6 blocks.

Contributed by Jeremy Chadwick  Piotr Kucharski  W. Campbell  and Ariel Biener 

/0 patterns
If you've read the above properly then it should be obvious that a /0 pattern ('e' = 0) is very rarely something you want. Such a pattern specifies that no bits have to be checked, hence all addresses will match a /0 pattern: akin to '*' as a mask. Very unlikely to be the intended result.

/32 patterns and /128 patterns
Again, this should be obvious from the above. A /32 pattern (For IPv4, 'e' = 32) or a /128 pattern (For IPv6, 'e' = 128) means that the entire address (32/128 bits for IPv4/6) will be matched. Therefore one of these patterns will only match exactly.