/[svn]/ircd-hybrid-7.2/doc/CIDR.txt
ViewVC logotype

Contents of /ircd-hybrid-7.2/doc/CIDR.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 34 - (show annotations)
Sun Oct 2 21:05:51 2005 UTC (14 years ago) by lusky
File MIME type: text/plain
File size: 12435 byte(s)
create 7.2 branch, we can move/rename it as needed.


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>

Properties

Name Value
svn:eol-style native
svn:keywords Id Revision

svnadmin@ircd-hybrid.org
ViewVC Help
Powered by ViewVC 1.1.26