Stupid Question maybe?

Tue Dec 18 13:29:18 UTC 2018

If you want the full historical definition, blow the dust off RFC791, and
open your hymnals to section 2.3.

"Addresses are fixed length of four octets (32 bits).  An address
    begins with a network number, followed by local address (called the
    "rest" field).  There are three formats or classes of internet
    addresses:  in class a, the high order bit is zero, the next 7 bits
    are the network, and the last 24 bits are the local address; in
    class b, the high order two bits are one-zero, the next 14 bits are
    the network and the last 16 bits are the local address; in class c,
    the high order three bits are one-one-zero, the next 21 bits are the
    network and the last 8 bits are the local address."

This is depicted visually if that's your deal in RFC796.

Back in '81 this was totally fine, but times change, and CIDR / VLSM
eventually made way more sense.

It's good to have at least a passing understanding of the old terminology
simply because documentation for newer stuff likes to reference it, but
don't get too hung up on it.

On Tue, Dec 18, 2018 at 6:47 AM Justin M. Streiner <streinerj at gmail.com>
wrote:

> On Mon, 17 Dec 2018, Joe wrote:
>
> > Apologizes in advance for a simple question. I am finding conflicting
> > definitions of Class networks. I was always under the impression that a
> > class "A" network was a /8 a class "B" network was a /16 and a class "C"
> > network was a /24. Recently, I was made aware that a class "A" was
> indeed a
> > /8 and a class "B" was actually a /12 (172.16/172.31.255.255) while a
> class
> > "C" is actually a /16.
>
> As others have mentioned, IP address classes are no longer relevant,
> beyond understanding how things were done in the past.  Address classes
> haven't been used for assignment or routing purposes for over 20 years,
> but the term lives on because it keeps getting undeserved new life in
> networking classes and training materials.
>
> Classfull address assignment/routing was horribly inefficient for two main
> reasons, both of which were corrected by a combination of CIDR and VLSM:
>
> 1. Assigning IP networks on byte boundaries (/8, /16, /24) was not
> granular enough to allow networks to be assigned as close as possible to
> actual need in many cases.  If you only needed 25 addresses for a
> particular network, you had to request or assign a /24 (legacy class C),
> resulting in roughly 90% of those addresses being wasted.
>
> 2. Classfull routing was starting to bloat routing tables, both inside of
> and between networks.  If a network had a little over 8,000 IPv4 addresses
> under its control, in the pre-CIDR days, that meant that they or their
> upstream provider would need to announce routes for 32 individual and/or
> contiguous /24s.  In the post-CIDR world, under the the best
> circumstances (all of their address space is contiguous and falls on an
> appropriately maskable boundary like x.y.0.0 through x.y.31.0), that
> network could announce a single /19.  When scaled up to a full Internet
> routing table, the possible efficiencies become much more obvious.  The
> network operator community has has to continue to grapple with routing
> table bloat since then, but for different reasons.
>
> Had CIDR, VLSM, and NAT/PAT not been implemented, we (collectively) would
> have run out of IPv4 addresses many years before we actually did.
>
> Thank you
> jms
>
> > Is this different depending on the IP segment, i.e. if it is part of a
> > RC1918 group it is classed differently (maybe a course I missed?) Or
> aren't
> > all IP's classed the same.
> > I was always under the impression, /8 = A, /16 = B, /24=C, so rightly, or
> > wrongly I've always seen 10.x.x.x as "A", and 192.168.x.x as "B", with
> > 172.16/12 as one that just a VLSM between the two.
> >
> > Again, apologizes for the simple question, just can't seem to find a
> solid
> > answer.
> >
> > Happy holidays all the same!
> > -Joe
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181218/eae428b4/attachment.html>