On Mon, 3 Mar 2003 21:55:55 -0800 Todd Lyons <[EMAIL PROTECTED]>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Pierre Fortin wrote on Mon, Mar 03, 2003 at 08:54:40PM -0500 :
> > > >
> > > > So I would use /16 for a Class C network?
> > > Not quite:
> > > /8 is Class A
> > > /16 is Class B
> > > /24 is Class C
> > Not quite:)
> > 0....... ........ ........ ........ is Class A
> > 10...... ........ ........ ........ is Class B
> > 110..... ........ ........ ........ is Class C
> > 1110.... ........ ........ ........ is Class D (multicast)
> > 1111.... ........ ........ ........ is Class E (reserved)
>
> He's asking about what /16 is, and you're talking about classful
> delegations. I don't think you're answering the question he asked.
> However, enlighten me if I'm wrong.
>
> > But, nowadays, Classes are mainly historical...
>
> In reference to the IP block, yes. But if he wants to block everything
> from 69.2.33.*, he will use a class C mask, regardless of the fact that
> the 69.0.0.0 network is historically a Class A.
Todd,
I know you are pretty much up on this subject, hence the small smiley in
my post... but it always helps to give people something to think on....
in that vein, expounding some more for those who are still unsure about
this stuff...
Scott actually asked about 209.8.161.0/24 which was a Class C in the old
days... the "problem" is that people still insist on [mis]using the Class
[ABC] designators... it makes more sense to use /0-/32, which is NOT
restricted to /8, /16, /24 and /32 and forget the Class X.
So, Scott and others should really think in terms of how many 2^N
addresses to block, determine the appropriate mask to do that... there is
a down-side though... it also means that people really need to learn how
to determine the proper MATCH address that will result from using a mask
that is not one of the traditional Class masks. For instance (including
*cast addresses):
209.8.161.0/24 blocks 209.8.161.0--209.8.161.255
209.8.160.0/24 blocks 209.8.160.0--209.8.160.255
209.8.160.0/23 blocks 209.8.160.0--209.8.161.255 (=above 2 ranges)
209.8.160.0/25 blocks 209.8.160.0--209.8.160.128
Note that 209.8.160.0/19 would block more addresses above & below the /23
example above while using the *same* (209.8.160.0) match address... this
is because 160 is coincidentally a nice binary number (0xA0) with plenty
of trailing 0s. However, specifying 209.8.161.0/16 as Scott asked *may*
not work (depends on software which reads/uses it) because after the /16
mask is applied, the address to compare against 209.8.160.0 would be
209.8.0.0 -- not a match! Though iptables does the Right Thing (using my
drop script):
# drop 1.2.3.4/16 all
^^^^^^^^^^ wrong! yet...
# iptables -L -v -n
Chain INPUT (policy ACCEPT 764K packets, 520M bytes)
pkts bytes target prot opt in out source
destination
0 0 DROP all -- * * 1.2.0.0/16
0.0.0.0/0
^^^^^^^^^^
It's a Good Thing to understand what goes on...
When building match_address/mask pairs, one must be very careful that they
are a *matched* pair; after all, specifying address/mask in a config file
is not guaranteed to be corrected, as in iptables... there are "subnet
calculators" available online to help with this... YIKES! A quick search
on google for "subnet calculator" gives 32,800 links -- BUT... there are
many for sale, some for free download, and others online...
unfortunately, I had to get to the 19th link (http://jodies.de/ipcalc)**
before I found one online (it's downloadable too) that is remotely helpful
for the novice in explaining the above address/mask pairing issue...
** enter say 209.8.161.1 and 23 and note the binary representations
returned...
Oh well... hope I made the point that giving a /N answer is less than
helpful for many folk who most likely don't yet understand that the
*resulting* match address, after masking, is what belongs in this
address/mask pair.
HTH,
Pierre
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
