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> |