$Id: /rb/doc/CIDR.txt 2 2008-12-17T03:10:09.215481Z androsyn  $
 
 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>

© 2023 acidvegas, inc • generated with stagit