| 1 |
$Id$ |
| 2 |
|
| 3 |
CIDR Information |
| 4 |
---------------- |
| 5 |
Presently, we all use IPv4. The format of IPv4 is the following: |
| 6 |
|
| 7 |
A.B.C.D |
| 8 |
|
| 9 |
Where letters 'A' through 'D' are 8-bit values. In English, this |
| 10 |
means each digit can have a value of 0 to 255. Example: |
| 11 |
|
| 12 |
129.56.4.234 |
| 13 |
|
| 14 |
Digits are called octets. Oct meaning 8, hence 8-bit values. An |
| 15 |
octet cannot be greater than 255, and cannot be less than 0 (eg. a |
| 16 |
negative number). |
| 17 |
|
| 18 |
CIDR stands for "classless inter domain routing", details covered |
| 19 |
in RFC's 1518 and 1519. It was introduced mainly due to waste within |
| 20 |
A and B classes space. The goal was to make it possible to use |
| 21 |
smaller nets than it would seem from (above) IP classes, for instance |
| 22 |
by dividing one B class into 256 "C like" classes. The other goal was |
| 23 |
to allow aggregation of routing information, so that routers could use |
| 24 |
one aggregated route (like 194.145.96.0/20) instead of |
| 25 |
advertising 16 C classes. |
| 26 |
|
| 27 |
Class A are all these addresses which first bit is "0", |
| 28 |
bitmap: 0nnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh (n=net, h=host) |
| 29 |
IP range is 0.0.0.0 - 127.255.255.255 |
| 30 |
|
| 31 |
Class B are all these addresses which first two bits are "10", |
| 32 |
bitmap: 10nnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh (n=net, h=host) |
| 33 |
IP range is 128.0.0.0 - 191.255.255.255 |
| 34 |
|
| 35 |
Class C are all these addresses which first three bits are "110", |
| 36 |
bitmap: 110nnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh (n=net, h=host) |
| 37 |
IP range is 192.0.0.0 - 223.255.255.255 |
| 38 |
|
| 39 |
Class D are all these addresses which first four bits are "1110", |
| 40 |
this is multicast class and net/host bitmap doesn't apply here |
| 41 |
IP range is 224.0.0.0 - 239.255.255.255 |
| 42 |
I bet they will never IRC, unless someone creates multicast IRC :) |
| 43 |
|
| 44 |
Class E are all these addresses which first five bits are "11110", |
| 45 |
this class is reserved for future use |
| 46 |
IP range is 240.0.0.0 - 247.255.255.255 |
| 47 |
|
| 48 |
So, here is how CIDR notation comes into play. |
| 49 |
|
| 50 |
For those of you who have real basic exposure to how networks are |
| 51 |
set up, you should be aware of the term "netmask." Basically, this |
| 52 |
is a IPv4 value which specifies the "size" of a network. You can |
| 53 |
assume the word "size" means "range" if you want. |
| 54 |
|
| 55 |
A chart describing the different classes in CIDR format and their |
| 56 |
wildcard equivalents would probably help at this point: |
| 57 |
|
| 58 |
CIDR version dot notation (netmask) Wildcard equivalent |
| 59 |
----------------------------------------------------------------- |
| 60 |
A.0.0.0/8 A.0.0.0/255.0.0.0 A.*.*.* or A.* |
| 61 |
A.B.0.0/16 A.B.0.0/255.255.0.0 A.B.*.* or A.B.* |
| 62 |
A.B.C.0/24 A.B.C.0/255.255.255.0 A.B.C.* or A.B.C.* |
| 63 |
A.B.C.D/32 A.B.C.D/255.255.255.255 A.B.C.D |
| 64 |
|
| 65 |
|
| 66 |
The question on any newbies mind at this point is "So what do all |
| 67 |
of those values & numbers actually mean?" |
| 68 |
|
| 69 |
Everything relating to computers is based on binary values (1s and |
| 70 |
zeros). Binary plays a *tremendous* role in CIDR notation. Let's |
| 71 |
break it down to the following table: |
| 72 |
|
| 73 |
A B C D |
| 74 |
-------- -------- -------- -------- |
| 75 |
/8 == 11111111 . 00000000 . 00000000 . 00000000 == 255.0.0.0 |
| 76 |
/16 == 11111111 . 11111111 . 00000000 . 00000000 == 255.255.0.0 |
| 77 |
/24 == 11111111 . 11111111 . 11111111 . 00000000 == 255.255.255.0 |
| 78 |
/32 == 11111111 . 11111111 . 11111111 . 11111111 == 255.255.255.255 |
| 79 |
|
| 80 |
The above is basically a binary table for the most common netblock |
| 81 |
sizes. The "1"s you see above are the 8-bit values for each octet. |
| 82 |
If you split an 8-bit value into each of it's bits, you find the |
| 83 |
following: |
| 84 |
|
| 85 |
00000000 |
| 86 |
^^^^^^^^_ 1sts place (1) |
| 87 |
|||||||__ 2nds place (2) |
| 88 |
||||||___ 3rds place (4) |
| 89 |
|||||____ 4ths place (8) |
| 90 |
||||_____ 5ths place (16) |
| 91 |
|||______ 6ths place (32) |
| 92 |
||_______ 7ths place (64) |
| 93 |
|________ 8ths place (128) |
| 94 |
|
| 95 |
Now, since computers consider zero a number, you pretty much have |
| 96 |
to subtract one (so-to-speak; this is not really how its done, but |
| 97 |
just assume it's -1 :-) ) from all the values possible. Some |
| 98 |
examples of decimal values in binary: |
| 99 |
|
| 100 |
15 == 00001111 (from left to right: 8+4+2+1) |
| 101 |
16 == 00010000 (from left to right: 16) |
| 102 |
53 == 00110101 (from left to right: 32+16+4+1) |
| 103 |
79 == 01001111 (from left to right: 64+8+4+1) |
| 104 |
254 == 11111110 (from left to right: 128+64+32+16+8+4+2) |
| 105 |
|
| 106 |
So, with 8 bits, the range (as I said before) is zero to 255. |
| 107 |
|
| 108 |
If none of this is making sense to you at this point, you should |
| 109 |
back up and re-read all of the above. I realize it's a lot, but |
| 110 |
it'll do you some good to re-read it until you understand :-). |
| 111 |
|
| 112 |
So, let's modify the original table a bit by providing CIDR info |
| 113 |
for /1 through /8: |
| 114 |
|
| 115 |
A B C D |
| 116 |
-------- -------- -------- -------- |
| 117 |
/1 == 10000000 . 00000000 . 00000000 . 00000000 == 128.0.0.0 |
| 118 |
/2 == 11000000 . 00000000 . 00000000 . 00000000 == 192.0.0.0 |
| 119 |
/3 == 11100000 . 00000000 . 00000000 . 00000000 == 224.0.0.0 |
| 120 |
/4 == 11110000 . 00000000 . 00000000 . 00000000 == 240.0.0.0 |
| 121 |
/5 == 11111000 . 00000000 . 00000000 . 00000000 == 248.0.0.0 |
| 122 |
/6 == 11111100 . 00000000 . 00000000 . 00000000 == 252.0.0.0 |
| 123 |
/7 == 11111110 . 00000000 . 00000000 . 00000000 == 254.0.0.0 |
| 124 |
/8 == 11111111 . 00000000 . 00000000 . 00000000 == 255.0.0.0 |
| 125 |
|
| 126 |
At this point, all of this should making a lot of sense, and you |
| 127 |
should be able to see the precision that you can get by using CIDR |
| 128 |
at this point. If not, well, I guess the best way to put it would |
| 129 |
be that wildcards always assume /8, /16, or /24 (yes hello Piotr, |
| 130 |
we can argue this later: I am referring to IPs *ONLY*, not domains |
| 131 |
or FQDNs :-) ). |
| 132 |
|
| 133 |
This table will provide a reference to all of the IPv4 CIDR values |
| 134 |
|
| 135 |
cidr|netmask (dot notation) |
| 136 |
----+--------------------- |
| 137 |
/1 | 128.0.0.0 |
| 138 |
/2 | 192.0.0.0 |
| 139 |
/3 | 224.0.0.0 |
| 140 |
/4 | 240.0.0.0 |
| 141 |
/5 | 248.0.0.0 |
| 142 |
/6 | 252.0.0.0 |
| 143 |
/7 | 254.0.0.0 |
| 144 |
/8 | 255.0.0.0 |
| 145 |
/9 | 255.128.0.0 |
| 146 |
/10 | 255.192.0.0 |
| 147 |
/11 | 255.224.0.0 |
| 148 |
/12 | 255.240.0.0 |
| 149 |
/13 | 255.248.0.0 |
| 150 |
/14 | 255.252.0.0 |
| 151 |
/15 | 255.254.0.0 |
| 152 |
/16 | 255.255.0.0 |
| 153 |
/17 | 255.255.128.0 |
| 154 |
/18 | 255.255.192.0 |
| 155 |
/19 | 255.255.224.0 |
| 156 |
/20 | 255.255.240.0 |
| 157 |
/21 | 255.255.248.0 |
| 158 |
/22 | 255.255.252.0 |
| 159 |
/23 | 255.255.254.0 |
| 160 |
/24 | 255.255.255.0 |
| 161 |
/25 | 255.255.255.128 |
| 162 |
/26 | 255.255.255.192 |
| 163 |
/27 | 255.255.255.224 |
| 164 |
/28 | 255.255.255.240 |
| 165 |
/29 | 255.255.255.248 |
| 166 |
/30 | 255.255.255.252 |
| 167 |
/31 | 255.255.255.254 |
| 168 |
/32 | 255.255.255.255 |
| 169 |
|
| 170 |
So, let's take all of the information above, and apply it to a |
| 171 |
present-day situation on IRC. |
| 172 |
|
| 173 |
Let's say you have a set of flooding clients who all show up from |
| 174 |
the following hosts. For lack-of a better example, I'll use a |
| 175 |
subnet here at Best: |
| 176 |
|
| 177 |
nick1 (xyz@shell9.ba.best.com) [206.184.139.140] |
| 178 |
nick2 (abc@shell8.ba.best.com) [206.184.139.139] |
| 179 |
nick3 (foo@shell12.ba.best.com) [206.184.139.143] |
| 180 |
|
| 181 |
Most people will assume the they were all in the same class C |
| 182 |
(206.184.139.0/24 or 206.184.139.*). |
| 183 |
|
| 184 |
This, as a matter of fact, is not true. Now, the reason *I* know |
| 185 |
this is solely because I work on the network here; those IPs are |
| 186 |
not delegated to a class C, but two portions of a class C (128 IPs |
| 187 |
each). That means the class C is actually split into these two |
| 188 |
portions: |
| 189 |
|
| 190 |
Netblock IP range |
| 191 |
-------- -------- |
| 192 |
206.184.139.0/25 206.184.139.0 to 206.184.139.127 |
| 193 |
206.184.139.128/25 206.184.139.128 to 206.184.139.255 |
| 194 |
|
| 195 |
For the record, 206.184.139.0 and 206.184.139.128 are both known as |
| 196 |
"network addresses" (not to be confused with "netblocks" or "Ethernet |
| 197 |
hardware addresses" or "MAC addresses"). Network addresses are |
| 198 |
*ALWAYS EVEN*. |
| 199 |
|
| 200 |
206.184.139.127 and 206.184.139.255 are what are known as broadcast |
| 201 |
addresses. Broadcast addresses are *ALWAYS ODD*. |
| 202 |
|
| 203 |
Now, the aforementioned list of clients are in the 2nd subnet shown |
| 204 |
above, not the first. The reason for this should be obvious. |
| 205 |
|
| 206 |
The remaining question is, "Well that's nice, you know what the netblock |
| 207 |
is for Best. What about us? We don't know that!" |
| 208 |
|
| 209 |
Believe it or not, you can find out the network block size by using |
| 210 |
whois -h WHOIS.ARIN.NET on the IP in question. ARIN keeps a list of |
| 211 |
all network blocks and who owns them -- quite useful, trust me. I |
| 212 |
think I use ARIN 5 or 6 times a day, especially when dealing with |
| 213 |
D-lines. Example: |
| 214 |
|
| 215 |
$ whois -h whois.arin.net 206.184.139.140 |
| 216 |
Best Internet Communications, Inc. (NETBLK-NBN-206-184-BEST) |
| 217 |
345 East Middlefield Road |
| 218 |
Mountain View, CA 94043 |
| 219 |
|
| 220 |
Netname: NBN-206-184-BEST |
| 221 |
Netblock: 206.184.0.0 - 206.184.255.255 |
| 222 |
Maintainer: BEST |
| 223 |
|
| 224 |
Does this mean you should D-line 206.184.0.0/16? Probably not. |
| 225 |
That's an entire class B-sized block, while you're only trying |
| 226 |
to deny access to a subnetted class C. |
| 227 |
|
| 228 |
So then how do you get the *real* info? Well, truth is, you don't. |
| 229 |
You have to pretty much take a guess at what it is, if ARIN reports |
| 230 |
something that's overly vague. Best, for example, was assigned the |
| 231 |
above class B-sized block. We can subnet it however we want without |
| 232 |
reporting back to ARIN how we have it subnetted. We own the block, |
| 233 |
and that's all that matters (to ARIN). |
| 234 |
|
| 235 |
Not all subnets are like this, however. Smaller subnets you may |
| 236 |
find partitioned and listed on ARIN; I've seen /29 blocks for DSL |
| 237 |
customers show up in ARIN before. |
| 238 |
|
| 239 |
So, use ARIN any chance you get. The more precision the better! |
| 240 |
|
| 241 |
Now, there is a small issue I want to address regarding use of CIDR |
| 242 |
notation. Let's say you D-line the following in CIDR format (hi |
| 243 |
sion ;-) ): |
| 244 |
|
| 245 |
205.100.132.18/24 |
| 246 |
|
| 247 |
Entries like this really makes my blood boil, solely because it adds |
| 248 |
excessive confusion and is just basically pointless. If you |
| 249 |
examine the above, you'll see the /24 is specifying an entire |
| 250 |
class C -- so then what's the purpose of using .18 versus .0? |
| 251 |
|
| 252 |
There IS no purpose. The netmask itself will mask out the .18 and |
| 253 |
continue to successfully use 205.100.132.0/24. |
| 254 |
|
| 255 |
Doing things this way just adds confusion, especially on non-octet- |
| 256 |
aligned subnets (such as /8, /16, /24, or /32). Seeing that on a |
| 257 |
/27 or a /19 might make people go "wtf?" |
| 258 |
|
| 259 |
I know for a fact this doc lacks a lot of necessary information, |
| 260 |
like how the actual netmask/CIDR value play a role in "masking out" |
| 261 |
the correct size, and what to do is WHOIS.ARIN.NET returns no |
| 262 |
netblock information but instead a few different company names with |
| 263 |
NIC handles. I'm sure you can figure this stuff out on your own, |
| 264 |
or just ask an administrator friend of yours who DOES know. A lot |
| 265 |
of us admins are BOFH types, but if you ask us the right questions, |
| 266 |
you'll benefit from the answer quite thoroughly. |
| 267 |
|
| 268 |
Oh, I almost forgot. Most Linux systems use a different version of |
| 269 |
"whois" than FreeBSD does. The syntax for whois on Linux is |
| 270 |
"whois <INFO>@whois.arin.net", while under FreeBSD it is |
| 271 |
"whois -h whois.arin.net <INFO>" Debian uses yet another version |
| 272 |
of whois that is incompatible with the above syntax options. |
| 273 |
|
| 274 |
Note that the FreeBSD whois client has shortcuts for the most commonly |
| 275 |
used whois servers. "whois -a <INFO>" is the shortcut for ARIN. |
| 276 |
|
| 277 |
Also note that ARIN is not authoritative for all IP blocks on the |
| 278 |
Internet. Take for example 212.158.123.66. A whois query to ARIN |
| 279 |
will return the following information: |
| 280 |
|
| 281 |
$ whois -h whois.arin.net 212.158.123.66 |
| 282 |
European Regional Internet Registry/RIPE NCC (NET-RIPE-NCC-) |
| 283 |
These addresses have been further assigned to European users. |
| 284 |
Contact information can be found in the RIPE database, via the |
| 285 |
WHOIS and TELNET servers at whois.ripe.net, and at |
| 286 |
http://www.ripe.net/db/whois.html |
| 287 |
|
| 288 |
Netname: RIPE-NCC-212 |
| 289 |
Netblock: 212.0.0.0 - 212.255.255.255 |
| 290 |
Maintainer: RIPE |
| 291 |
|
| 292 |
This query tells us that it is a European IP block, and is further |
| 293 |
handled by RIPE's whois server. We must then query whois.ripe.net |
| 294 |
to get more information. |
| 295 |
|
| 296 |
$ whois -h whois.ripe.net 212.158.123.66 |
| 297 |
|
| 298 |
% Rights restricted by copyright. See |
| 299 |
http://www.ripe.net/ripencc/pub-services/db/copyright.html |
| 300 |
|
| 301 |
inetnum: 212.158.120.0 - 212.158.123.255 |
| 302 |
netname: INSNET-P2P |
| 303 |
descr: Point to Point Links for for London Nodes |
| 304 |
country: GB |
| 305 |
--snip-- |
| 306 |
|
| 307 |
This tells us the actual IP block that the query was a part of. |
| 308 |
|
| 309 |
Other whois servers that you may see blocks referred to are: |
| 310 |
whois.ripn.net for Russia, whois.apnic.net for Asia, Australia, and |
| 311 |
the Pacific, and whois.6bone.net for IPv6 blocks. |
| 312 |
|
| 313 |
Contributed by Jeremy Chadwick <jdc@best.net> |
| 314 |
Piotr Kucharski <chopin@sgh.waw.pl> |
| 315 |
W. Campbell <wcampbel@botbay.net> and |
| 316 |
Ariel Biener <ariel@fireball.tau.ac.il> |
