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