| 1 |
knight |
31 |
$Id$ |
| 2 |
adx |
30 |
|
| 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> |
