diff options
Diffstat (limited to 'doc/CIDR.txt')
| -rw-r--r-- | doc/CIDR.txt | 316 |
1 files changed, 316 insertions, 0 deletions
diff --git a/doc/CIDR.txt b/doc/CIDR.txt new file mode 100644 index 0000000..e17098a --- /dev/null +++ b/doc/CIDR.txt @@ -0,0 +1,316 @@ +$Id$ + +CIDR Information +---------------- + Presently, we all use IPv4. The format of IPv4 is the following: + +A.B.C.D + + Where letters 'A' through 'D' are 8-bit values. In English, this + means each digit can have a value of 0 to 255. Example: + +129.56.4.234 + + Digits are called octets. Oct meaning 8, hence 8-bit values. An + octet cannot be greater than 255, and cannot be less than 0 (eg. a + negative number). + + CIDR stands for "classless inter domain routing", details covered + in RFC's 1518 and 1519. It was introduced mainly due to waste within + A and B classes space. The goal was to make it possible to use + smaller nets than it would seem from (above) IP classes, for instance + by dividing one B class into 256 "C like" classes. The other goal was + to allow aggregation of routing information, so that routers could use + one aggregated route (like 194.145.96.0/20) instead of + advertising 16 C classes. + + Class A are all these addresses which first bit is "0", + bitmap: 0nnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh (n=net, h=host) + IP range is 0.0.0.0 - 127.255.255.255 + + Class B are all these addresses which first two bits are "10", + bitmap: 10nnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh (n=net, h=host) + IP range is 128.0.0.0 - 191.255.255.255 + + Class C are all these addresses which first three bits are "110", + bitmap: 110nnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh (n=net, h=host) + IP range is 192.0.0.0 - 223.255.255.255 + + Class D are all these addresses which first four bits are "1110", + this is multicast class and net/host bitmap doesn't apply here + IP range is 224.0.0.0 - 239.255.255.255 + I bet they will never IRC, unless someone creates multicast IRC :) + + Class E are all these addresses which first five bits are "11110", + this class is reserved for future use + IP range is 240.0.0.0 - 247.255.255.255 + + So, here is how CIDR notation comes into play. + + For those of you who have real basic exposure to how networks are + set up, you should be aware of the term "netmask." Basically, this + is a IPv4 value which specifies the "size" of a network. You can + assume the word "size" means "range" if you want. + + A chart describing the different classes in CIDR format and their + wildcard equivalents would probably help at this point: + +CIDR version dot notation (netmask) Wildcard equivalent +----------------------------------------------------------------- +A.0.0.0/8 A.0.0.0/255.0.0.0 A.*.*.* or A.* +A.B.0.0/16 A.B.0.0/255.255.0.0 A.B.*.* or A.B.* +A.B.C.0/24 A.B.C.0/255.255.255.0 A.B.C.* or A.B.C.* +A.B.C.D/32 A.B.C.D/255.255.255.255 A.B.C.D + + + The question on any newbies mind at this point is "So what do all + of those values & numbers actually mean?" + + Everything relating to computers is based on binary values (1s and + zeros). Binary plays a *tremendous* role in CIDR notation. Let's + break it down to the following table: + + A B C D + -------- -------- -------- -------- +/8 == 11111111 . 00000000 . 00000000 . 00000000 == 255.0.0.0 +/16 == 11111111 . 11111111 . 00000000 . 00000000 == 255.255.0.0 +/24 == 11111111 . 11111111 . 11111111 . 00000000 == 255.255.255.0 +/32 == 11111111 . 11111111 . 11111111 . 11111111 == 255.255.255.255 + + The above is basically a binary table for the most common netblock + sizes. The "1"s you see above are the 8-bit values for each octet. + If you split an 8-bit value into each of it's bits, you find the + following: + +00000000 +^^^^^^^^_ 1sts place (1) +|||||||__ 2nds place (2) +||||||___ 3rds place (4) +|||||____ 4ths place (8) +||||_____ 5ths place (16) +|||______ 6ths place (32) +||_______ 7ths place (64) +|________ 8ths place (128) + + Now, since computers consider zero a number, you pretty much have + to subtract one (so-to-speak; this is not really how its done, but + just assume it's -1 :-) ) from all the values possible. Some + examples of decimal values in binary: + +15 == 00001111 (from left to right: 8+4+2+1) +16 == 00010000 (from left to right: 16) +53 == 00110101 (from left to right: 32+16+4+1) +79 == 01001111 (from left to right: 64+8+4+1) +254 == 11111110 (from left to right: 128+64+32+16+8+4+2) + + So, with 8 bits, the range (as I said before) is zero to 255. + + If none of this is making sense to you at this point, you should + back up and re-read all of the above. I realize it's a lot, but + it'll do you some good to re-read it until you understand :-). + + So, let's modify the original table a bit by providing CIDR info + for /1 through /8: + + A B C D + -------- -------- -------- -------- +/1 == 10000000 . 00000000 . 00000000 . 00000000 == 128.0.0.0 +/2 == 11000000 . 00000000 . 00000000 . 00000000 == 192.0.0.0 +/3 == 11100000 . 00000000 . 00000000 . 00000000 == 224.0.0.0 +/4 == 11110000 . 00000000 . 00000000 . 00000000 == 240.0.0.0 +/5 == 11111000 . 00000000 . 00000000 . 00000000 == 248.0.0.0 +/6 == 11111100 . 00000000 . 00000000 . 00000000 == 252.0.0.0 +/7 == 11111110 . 00000000 . 00000000 . 00000000 == 254.0.0.0 +/8 == 11111111 . 00000000 . 00000000 . 00000000 == 255.0.0.0 + + At this point, all of this should making a lot of sense, and you + should be able to see the precision that you can get by using CIDR + at this point. If not, well, I guess the best way to put it would + be that wildcards always assume /8, /16, or /24 (yes hello Piotr, + we can argue this later: I am referring to IPs *ONLY*, not domains + or FQDNs :-) ). + + This table will provide a reference to all of the IPv4 CIDR values + +cidr|netmask (dot notation) +----+--------------------- +/1 | 128.0.0.0 +/2 | 192.0.0.0 +/3 | 224.0.0.0 +/4 | 240.0.0.0 +/5 | 248.0.0.0 +/6 | 252.0.0.0 +/7 | 254.0.0.0 +/8 | 255.0.0.0 +/9 | 255.128.0.0 +/10 | 255.192.0.0 +/11 | 255.224.0.0 +/12 | 255.240.0.0 +/13 | 255.248.0.0 +/14 | 255.252.0.0 +/15 | 255.254.0.0 +/16 | 255.255.0.0 +/17 | 255.255.128.0 +/18 | 255.255.192.0 +/19 | 255.255.224.0 +/20 | 255.255.240.0 +/21 | 255.255.248.0 +/22 | 255.255.252.0 +/23 | 255.255.254.0 +/24 | 255.255.255.0 +/25 | 255.255.255.128 +/26 | 255.255.255.192 +/27 | 255.255.255.224 +/28 | 255.255.255.240 +/29 | 255.255.255.248 +/30 | 255.255.255.252 +/31 | 255.255.255.254 +/32 | 255.255.255.255 + + So, let's take all of the information above, and apply it to a + present-day situation on IRC. + + Let's say you have a set of flooding clients who all show up from + the following hosts. For lack-of a better example, I'll use a + subnet here at Best: + +nick1 (xyz@shell9.ba.best.com) [206.184.139.140] +nick2 (abc@shell8.ba.best.com) [206.184.139.139] +nick3 (foo@shell12.ba.best.com) [206.184.139.143] + + Most people will assume the they were all in the same class C + (206.184.139.0/24 or 206.184.139.*). + + This, as a matter of fact, is not true. Now, the reason *I* know + this is solely because I work on the network here; those IPs are + not delegated to a class C, but two portions of a class C (128 IPs + each). That means the class C is actually split into these two + portions: + +Netblock IP range +-------- -------- +206.184.139.0/25 206.184.139.0 to 206.184.139.127 +206.184.139.128/25 206.184.139.128 to 206.184.139.255 + + For the record, 206.184.139.0 and 206.184.139.128 are both known as + "network addresses" (not to be confused with "netblocks" or "Ethernet + hardware addresses" or "MAC addresses"). Network addresses are + *ALWAYS EVEN*. + + 206.184.139.127 and 206.184.139.255 are what are known as broadcast + addresses. Broadcast addresses are *ALWAYS ODD*. + + Now, the aforementioned list of clients are in the 2nd subnet shown + above, not the first. The reason for this should be obvious. + + The remaining question is, "Well that's nice, you know what the netblock + is for Best. What about us? We don't know that!" + + Believe it or not, you can find out the network block size by using + whois -h WHOIS.ARIN.NET on the IP in question. ARIN keeps a list of + all network blocks and who owns them -- quite useful, trust me. I + think I use ARIN 5 or 6 times a day, especially when dealing with + D-lines. Example: + +$ whois -h whois.arin.net 206.184.139.140 +Best Internet Communications, Inc. (NETBLK-NBN-206-184-BEST) +345 East Middlefield Road +Mountain View, CA 94043 + +Netname: NBN-206-184-BEST +Netblock: 206.184.0.0 - 206.184.255.255 +Maintainer: BEST + + Does this mean you should D-line 206.184.0.0/16? Probably not. + That's an entire class B-sized block, while you're only trying + to deny access to a subnetted class C. + + So then how do you get the *real* info? Well, truth is, you don't. + You have to pretty much take a guess at what it is, if ARIN reports + something that's overly vague. Best, for example, was assigned the + above class B-sized block. We can subnet it however we want without + reporting back to ARIN how we have it subnetted. We own the block, + and that's all that matters (to ARIN). + + Not all subnets are like this, however. Smaller subnets you may + find partitioned and listed on ARIN; I've seen /29 blocks for DSL + customers show up in ARIN before. + + So, use ARIN any chance you get. The more precision the better! + + Now, there is a small issue I want to address regarding use of CIDR + notation. Let's say you D-line the following in CIDR format (hi + sion ;-) ): + +205.100.132.18/24 + + Entries like this really makes my blood boil, solely because it adds + excessive confusion and is just basically pointless. If you + examine the above, you'll see the /24 is specifying an entire + class C -- so then what's the purpose of using .18 versus .0? + + There IS no purpose. The netmask itself will mask out the .18 and + continue to successfully use 205.100.132.0/24. + + Doing things this way just adds confusion, especially on non-octet- + aligned subnets (such as /8, /16, /24, or /32). Seeing that on a + /27 or a /19 might make people go "wtf?" + + I know for a fact this doc lacks a lot of necessary information, + like how the actual netmask/CIDR value play a role in "masking out" + the correct size, and what to do is WHOIS.ARIN.NET returns no + netblock information but instead a few different company names with + NIC handles. I'm sure you can figure this stuff out on your own, + or just ask an administrator friend of yours who DOES know. A lot + of us admins are BOFH types, but if you ask us the right questions, + you'll benefit from the answer quite thoroughly. + + Oh, I almost forgot. Most Linux systems use a different version of + "whois" than FreeBSD does. The syntax for whois on Linux is + "whois <INFO>@whois.arin.net", while under FreeBSD it is + "whois -h whois.arin.net <INFO>" Debian uses yet another version + of whois that is incompatible with the above syntax options. + + Note that the FreeBSD whois client has shortcuts for the most commonly + used whois servers. "whois -a <INFO>" is the shortcut for ARIN. + + Also note that ARIN is not authoritative for all IP blocks on the + Internet. Take for example 212.158.123.66. A whois query to ARIN + will return the following information: + +$ whois -h whois.arin.net 212.158.123.66 +European Regional Internet Registry/RIPE NCC (NET-RIPE-NCC-) + These addresses have been further assigned to European users. + Contact information can be found in the RIPE database, via the + WHOIS and TELNET servers at whois.ripe.net, and at + http://www.ripe.net/db/whois.html + + Netname: RIPE-NCC-212 + Netblock: 212.0.0.0 - 212.255.255.255 + Maintainer: RIPE + + This query tells us that it is a European IP block, and is further + handled by RIPE's whois server. We must then query whois.ripe.net + to get more information. + +$ whois -h whois.ripe.net 212.158.123.66 + +% Rights restricted by copyright. See + http://www.ripe.net/ripencc/pub-services/db/copyright.html + +inetnum: 212.158.120.0 - 212.158.123.255 +netname: INSNET-P2P +descr: Point to Point Links for for London Nodes +country: GB +--snip-- + + This tells us the actual IP block that the query was a part of. + + Other whois servers that you may see blocks referred to are: + whois.ripn.net for Russia, whois.apnic.net for Asia, Australia, and + the Pacific, and whois.6bone.net for IPv6 blocks. + +Contributed by Jeremy Chadwick <jdc@best.net> +Piotr Kucharski <chopin@sgh.waw.pl> +W. Campbell <wcampbel@botbay.net> and +Ariel Biener <ariel@fireball.tau.ac.il> |