]>
Commit | Line | Data |
---|---|---|
1 | $Id: CIDR.txt 6 2005-09-10 01:02:21Z nenolod $ | |
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> |