Re: Stupid Question maybe?

[Christian Meutes]

Hi Aseem,

On Wed, Dec 26, 2018 at 6:42 PM Aseem Choudhary  wrote:

> Hi Christian,
>
> Discontinuous mask for IPv6 was supported in IOS-XR in release 5.2.2.
>
> You can refer below link for details:
>
> https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/ip-addresses/command/reference/b-ip-addresses-cr-asr9000/b-ipaddr-cr-asr9k_chapter_01.html#wp4831598620
>
> I'am running 5.2.2. and it does definitely not work, only continues bits
do work (typhoon-based LCs / 9001).

cheers

-- 
Christian

e-mail/xmpp: christ...@errxtx.net
PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318

Stupid Question maybe?

[Aseem Choudhary]

Hi Christian,

Discontinuous mask for IPv6 was supported in IOS-XR in release 5.2.2.

You can refer below link for details:

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/ip-addresses/command/reference/b-ip-addresses-cr-asr9000/b-ipaddr-cr-asr9k_chapter_01.html#wp4831598620

Regards,

Aseem

On Wed, Dec 19, 2018 at 8:32 AM Saku Ytti https://mailman.nanog.org/mailman/listinfo/nanog>> wrote:

>* On Wed, 19 Dec 2018 at 02:55, Philip Loenneker
*>* https://mailman.nanog.org/mailman/listinfo/nanog>> wrote:
*>>* > I had a heck of a time a few years back trying to troubleshoot an issue
*>* where an upstream provider had an ACL with an incorrect mask along the
*>* lines of 255.252.255.0. That was really interesting to talk about once we
*>* discovered it, though it caused some loss of hair beforehand...
*>>* Juniper originally didn't support them even in ACL use-case but were
*>* forced to add later due to customer demand, so people do have
*>* use-cases for them. If we'd still support them in forwarding, I'm sure
*>* someone would come up with solution which depends on it. I am not
*>* advocating we should, I'll rather take my extra PPS out of the HW.
*>>* However there is one quite interesting use-case for discontinuous mask
*>* in ACL. If you have, like you should have, specific block for customer
*>* linknetworks, you can in iACL drop all packets to your side of the
*>* links while still allowing packets to customer side of the links,
*>* making attack surface against your network minimal.
*

And unfortunately is still not supported by IOS-XR for IPv6, which could
mean not having a scaleable way on your edge to protect your internal
network.

-- 
Christian

e-mail/xmpp: christian at errxtx.net
<https://mailman.nanog.org/mailman/listinfo/nanog>
PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.nanog.org/pipermail/nanog/attachments/20181220/cfd683a3/attachment.html
<https://mailman.nanog.org/pipermail/nanog/attachments/20181220/cfd683a3/attachment.html>>

--


   - Previous message (by thread): Stupid Question maybe?
   <https://mailman.nanog.org/pipermail/nanog/2018-December/098410.html>
   - Next message (by thread): Stupid Question maybe?
   <https://mailman.nanog.org/pipermail/nanog/2018-December/098447.html>
   - *Messages sorted by:* [ date ]
   <https://mailman.nanog.org/pipermail/nanog/2018-December/date.html#98465>
[ thread ]
   <https://mailman.nanog.org/pipermail/nanog/2018-December/thread.html#98465>
[ subject ]
   <https://mailman.nanog.org/pipermail/nanog/2018-December/subject.html#98465>
[ author ]
   <https://mailman.nanog.org/pipermail/nanog/2018-December/author.html#98465>

--
More information about the NANOG mailing list
<https://mailman.nanog.org/mailman/listinfo/nanog>

Re: Stupid Question maybe?

[Chuck Church]

When I first started working with Cisco products (around 1999) I came upon
a router doing NAT for internet access that used a discontiguous mask to
determine which address to PAT the hosts against as they were doing some
creative load balancing.  It worked really well, no matter what part of the
'block' the DHCP server gave inside addresses out to.  I was stumped for
the longest time trying to figure out what this did.

Chuck

On Mon, Dec 24, 2018 at 3:11 PM Tony Finch  wrote:

>
> On 18 Dec 2018, at 22:30, Joel Halpern  wrote:
>
> History of non-contiguous network masks, as I observed it. [snip]
>
> When we were done, other folks looked at the work (I don't know if the
> Internet Drafts are still in repositories, but they shoudl be.)  And
> concluded that while this would work, no network operations staff would
> ever be able to do it correctly.  So as a community we decided not to go
> down that path.
>
>
> In the late 1990s I was doing web server things at Demon Internet. Our
> “Homepages” service provided an IP-based virtual host for each customer (it
> predated widespread support for HTTP Host: headers), and by the time I
> joined the service had two /18s and a /16 of web sites (if my memory is
> correct). We were allocating addresses to customers sequentially, so the
> /18s were full and the /16 was in progress.
>
> We had a small number of front-end Squid reverse proxy caches which owned
> all the IP addresses, using a BSD kernel hack (which I worked on to get
> published but it never got committed upstream
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=12071)
>
> The problem was that the entirely static load spreading relied on the
> routing config upstream from the reverse proxies, and IIRC it just divided
> the space into /18s and allocated them to proxies. So the load allocation
> was very uneven.
>
> I thought up a cunning hack, to divide the /16 by using a non-contiguous
> netmask of 0x0003 instead of 0xc000, so that successive customers
> would be allocated to front ends 0,1,2,3 cyclically. Fun :-)
>
> But I observed that one of my colleagues had a CIDR chart stuck on the
> side of his monitor, and that all the documentation in this area warned of
> dragons and bugs, and I realised that it would be unwise to do more than
> try it out experimentally :-)
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at
>

Re: Stupid Question maybe?

[Tony Finch]

> On 18 Dec 2018, at 22:30, Joel Halpern  wrote:
> 
> History of non-contiguous network masks, as I observed it. [snip]
> 
> When we were done, other folks looked at the work (I don't know if the 
> Internet Drafts are still in repositories, but they shoudl be.)  And 
> concluded that while this would work, no network operations staff would ever 
> be able to do it correctly.  So as a community we decided not to go down that 
> path.

In the late 1990s I was doing web server things at Demon Internet. Our 
“Homepages” service provided an IP-based virtual host for each customer (it 
predated widespread support for HTTP Host: headers), and by the time I joined 
the service had two /18s and a /16 of web sites (if my memory is correct). We 
were allocating addresses to customers sequentially, so the /18s were full and 
the /16 was in progress.

We had a small number of front-end Squid reverse proxy caches which owned all 
the IP addresses, using a BSD kernel hack (which I worked on to get published 
but it never got committed upstream 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=12071)

The problem was that the entirely static load spreading relied on the routing 
config upstream from the reverse proxies, and IIRC it just divided the space 
into /18s and allocated them to proxies. So the load allocation was very uneven.

I thought up a cunning hack, to divide the /16 by using a non-contiguous 
netmask of 0x0003 instead of 0xc000, so that successive customers would 
be allocated to front ends 0,1,2,3 cyclically. Fun :-)

But I observed that one of my colleagues had a CIDR chart stuck on the side of 
his monitor, and that all the documentation in this area warned of dragons and 
bugs, and I realised that it would be unwise to do more than try it out 
experimentally :-)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at

Re: Stupid Question maybe?

[Florian Weimer]

* Baldur Norddahl:

> Why do we still have network equipment, where half the configuration
> requires netmask notation, the other half requires CIDR and to throw you
> off, they also included inverse netmasks.

Some also drop the prefix length in diagnostic output if it matches
that of the address class.  So you still need to know about address
classes, unfortunately.

Re: Stupid Question maybe?

[Saku Ytti]

On Thu, 20 Dec 2018 at 21:06, Grant Taylor via NANOG  wrote:

> Do you have /24 cover prefixes advertised to the Internet?

Yes, just it drops at the peering edge as more specific is not found.

> $EMPLOYER requires globally routable access to the link net IP on our
> equipment for specific configurations.  Sorry, I can't go into details.
>
> I'm trying to ascertain if the configuration (as I understand it) that
> advocating for would work for us or not.

Would require details, but I believe the host/32 pointing to interface
(no next-hop IP) ought to  do the trick.

-- 
  ++ytti

Re: Stupid Question maybe?

[Grant Taylor via NANOG]

On 12/20/2018 10:55 AM, Saku Ytti wrote:

Correct.


Do you have /24 cover prefixes advertised to the Internet?

What is that use-case? Do notice that I propose opt-in static host/32 
route pointing to the link, giving far-end INET reachability, if they 
so want, without adding attack surface on the near-end.


$EMPLOYER requires globally routable access to the link net IP on our 
equipment for specific configurations.  Sorry, I can't go into details.


I'm trying to ascertain if the configuration (as I understand it) that 
advocating for would work for us or not.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Stupid Question maybe?

[Saku Ytti]

On Thu, 20 Dec 2018 at 20:07, William Allen Simpson
 wrote:

> Then there were the fine vendors that conflated the link and IP headers.
> That fell apart when IEEE started assigning OUIs that began with 0x4xxx.

There is no way to know in-transit what MPLS carries. Vendors have
implemented heuristics of different complexities to try to guess what
is being carried in effort to enable services like ECMP and netflow.
In hindsight MPLS ethertype probably should tell what it carries
MPLS-IP, MPLS-ETH, MPLS-OTHER.
This is on-going problem with no obvious solution, the ECMP issue can
be largely handled by disabling payload guessing and relying on having
sufficient flow entropy in labels. But the services such as netflow
still need transit guessing.

-- 
  ++ytti

Re: Stupid Question maybe?

[Saku Ytti]

On Thu, 20 Dec 2018 at 18:22, Grant Taylor via NANOG  wrote:

> Are you advocating not advertising customer linknetworks within your own
> organization?

Correct.

> I know of a use cases where linknetworks must be globally accessible.
> At least the customer's linknetwork IP address.  So, not advertising
> them (or at least an aggregate for them) would be problematic.

What is that use-case? Do notice that I propose opt-in static host/32
route pointing to the link, giving far-end INET reachability, if they
so want, without adding attack surface on the near-end.

-- 
  ++ytti

Re: Stupid Question maybe?

[William Allen Simpson]

On 12/19/18 2:47 PM, valdis.kletni...@vt.edu wrote:

So at one show, the Interop show network went to a 255.255.252.0 netmask, and
of course a lot of vendors had issues and complained.  The stock response was
"Quit whining, or next show it's going to be 255.255.250.0".


Ha, I remember!

Let us not forget Interop 91, where one vendor accidentally sent all its
packets with an IP version field of 0.  Nearly every router was shown to
never check the IP version number!

Moreover, it turned out later that major printer vendors weren't checking
either  No good way to update them in the field, ever.

That was a serious worry as we designed PIPE/SIP/SIPP/IPv6, and the main
reason that we had to get new link layer protocol numbers.

Then there were the fine vendors that conflated the link and IP headers.
That fell apart when IEEE started assigning OUIs that began with 0x4xxx.

Interop really used to be a blessing, before it became just another show.

Re: Stupid Question maybe?

[Christian Meutes]

On Wed, Dec 19, 2018 at 8:32 AM Saku Ytti  wrote:

> On Wed, 19 Dec 2018 at 02:55, Philip Loenneker
>  wrote:
>
> > I had a heck of a time a few years back trying to troubleshoot an issue
> where an upstream provider had an ACL with an incorrect mask along the
> lines of 255.252.255.0. That was really interesting to talk about once we
> discovered it, though it caused some loss of hair beforehand...
>
> Juniper originally didn't support them even in ACL use-case but were
> forced to add later due to customer demand, so people do have
> use-cases for them. If we'd still support them in forwarding, I'm sure
> someone would come up with solution which depends on it. I am not
> advocating we should, I'll rather take my extra PPS out of the HW.
>
> However there is one quite interesting use-case for discontinuous mask
> in ACL. If you have, like you should have, specific block for customer
> linknetworks, you can in iACL drop all packets to your side of the
> links while still allowing packets to customer side of the links,
> making attack surface against your network minimal.


And unfortunately is still not supported by IOS-XR for IPv6, which could
mean not having a scaleable way on your edge to protect your internal
network.

-- 
Christian

e-mail/xmpp: christ...@errxtx.net
PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318

Re: Stupid Question maybe?

[Adam Atkinson]

On 19/12/2018 16:24, Naslund, Steve wrote:


It has ALWAYS been the only correct way to configure equipment and is
a requirement under CIDR.  Here were your commonly used netmasks
before CIDR/VLSM :

255.0.0.0 255.255.0.0 255.255.255.0

Which one is not contiguous?


There is an example in RFC950 on page 15.

   3.  A Class C Network Case (illustrating non-contiguous subnet bits)

  For this case, assume that the requesting host is on class C
  network 192.1.127.0, has address 192.1.127.19, that there is a
  gateway at 192.1.127.50, and that on network an 3-bit subnet field
  is in use (01011000), that is, the address mask is 255.255.255.88.

Admittedly, page 6 contains:

  Since the bits that identify the subnet are specified by a
  bitmask, they need not be adjacent in the address.  However, we
  recommend that the subnet bits be contiguous and located as the
  most significant bits of the local address.

I have never seen noncontiguous network masks used in real life, but I 
may not be old enough.


--
Adam Atkinson

Re: Stupid Question maybe?

[Smoot Carl-Mitchell]

On Wed, 2018-12-19 at 14:54 +, Naslund, Steve wrote:
> I am wondering how a netmask could be not contiguous when the network
> portion of the address must be contiguous.  I suppose a bit mask
> could certainly be anything you want but a netmask specifically
> identifies the network portion of an address.

Before CIDR, subnets allowed further subdividing Classful addresses and
the mask bits after the network part could be non-contiguous. For a
class A network the first 8 bits covered the classful network, but the
remaining subnet bits did not have to be contiguous. Most network
admins made the subnet part contiguous, but allowing non-contiguous
subnet masks simplified the actual implementation. There was no need to
check if the bits were contiguous in the code.

Also subnet masks had to be the exactly the same on all devices.  You
could not have variable length masks.  A common practice if you could
get a Class B network (16 bit network part) was to use a 24 bit mask to
divide the network into 254 subnetworks which was adequate for most
purposes at the time.
-- 
Smoot Carl-Mitchell
System/Network Architect
voice: +1 480 922-7313
cell: +1 602 421-9005
sm...@tic.com

Re: Stupid Question maybe?

[Joel Halpern]

History of non-contiguous network masks, as I observed it.

The rules did not prohibit discontiguous network masks.  But no one was 
sure how to make them work.  In particular, how to allocate subnets from 
discontiguous networks in a sensible fashion.


In the early 90s, during the efforts to solve the swamp and classful 
exhaustion problems, Paul Francis (then Tsuchia) and I each worked out 
table structures that would allow for discontiguous masks with 
well-defined "prefixes" / "parents".  Both approaches were based on 
extensions of Knuth's Patricia trees.  (It took some interesting 
analysis and extensions.)


When we were done, other folks looked at the work (I don't know if the 
Internet Drafts are still in repositories, but they shoudl be.)  And 
concluded that while this would work, no network operations staff would 
ever be able to do it correctly.  So as a community we decided not to go 
down that path.


Yours,
Joel

On 12/18/18 5:12 PM, David Edelman wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I seem to remember that before the advent of VLSM and CIDR there was no 
requirement for the 1 bits in the netmask to be contiguous with no intervening 
0 bits and there was always someone who tested it out on a production network 
just to prove a point (usually only once)

Dave

- -Original Message-
From: NANOG  On Behalf Of Naslund, Steve
Sent: Tuesday, December 18, 2018 3:37 PM
To: nanog@nanog.org
Subject: RE: Stupid Question maybe?

It is a matter of machine readability vs human readability.  Remember the IP 
was around when routers did not have a lot of horsepower.  The dotted decimal 
notation was a compromise between pure binary (which the equipment used) and 
human readability.  VLSM seems obvious now but in the beginning organizing 
various length routes into very expensive memory and low horsepower processors 
meant that it was much easier to break routes down along byte boundaries.  This 
meant you only had four different lengths of route to deal with.  It was 
intended to eliminate multiple passes sorting the tables.  I am not quite sure 
what you mean about interspersing zeros, that would be meaningless.  Remember 
that it is a mask.  The address bits which are masked as 1s are significant to 
routing.  The bits that are masked with 0s are the host portion and don't 
matter to the network routing table.

Steven Naslund
Chicago IL



/24 is certainly cleaner than 255.255.255.0.

I seem to remember it was Phil Karn who in the early 80's suggested that 
expressing subnet masks as the number of bits from the top end of the address word 
was efficient, since subnet masks were always a series of ones followd >by 
zeros with no interspersing, which was incorporated (or independently invented) 
about a decade later as CIDR a.b.c.d/n notation in RFC1519.
- Brian

-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQP+UHquEepll566aqXCCyZOY1FIQUCXBlw1AAKCRCXCCyZOY1F
IYkTAJ98Gh+IGhDcyIB92H9JyWtbCVDhugCfZXq60pnHCqttKfw2fpUCBagTxYo=
=RimM
-END PGP SIGNATURE-

Re: Stupid Question maybe?

[Grant Taylor via NANOG]

On 12/20/2018 02:47 AM, Saku Ytti wrote:
Aye. I'd recommend not advertise your linknetworks at all, and let 
customers either opt-in or out-out from creating /128 and /32 static 
route towards interface. Achieving mostly same result, except for in 
local device where edge interfaces can reach customer and your side.


Are you advocating not advertising customer linknetworks within your own 
organization?


I know of a use cases where linknetworks must be globally accessible. 
At least the customer's linknetwork IP address.  So, not advertising 
them (or at least an aggregate for them) would be problematic.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Stupid Question maybe?

[Saku Ytti]

On Thu, 20 Dec 2018 at 10:32, Christian Meutes  wrote:

> And unfortunately is still not supported by IOS-XR for IPv6, which could mean 
> not having a scaleable way on your edge to protect your internal network.

Aye. I'd recommend not advertise your linknetworks at all, and let
customers either opt-in or out-out from creating /128 and /32 static
route towards interface. Achieving mostly same result, except for in
local device where edge interfaces can reach customer and your side.

-- 
  ++ytti

Re: Stupid Question maybe?

[Joe]

Just wanted to say thanks to all for responses about the information on
this! Extremely informative and helpful.

Have a great holiday and happy new year!

-Joe



>

Re: Stupid Question maybe?

[Baldur Norddahl]

>
>
>
I remember working on a SGI Unix workstation, where you simply could not
specify netmask. It was implicated by the class of address. This meant that
there were only three possible netmasks.

If that was how the first IP implementations started out, we had contiguous
netmasks at the beginning...

RE: Stupid Question maybe?

[David Edelman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

You could be sure of two things when there were ambiguities in the routing 
tables:
 1- Every manufacturer knew how to handle them.
2 - Every manufacturer did it a different way.

I suspect that in most cases where two conflicting route entries existed, the 
router selected the first one that it encountered unless they were advertised 
using different protocols, then the priority associated with the protocol was 
used as a tie breaker.

Dave

- -Original Message-
From: NANOG  On Behalf Of Owen DeLong
Sent: Wednesday, December 19, 2018 3:47 PM
To: Thomas Bellman 
Cc: nanog@nanog.org
Subject: Re: Stupid Question maybe?



> On Dec 19, 2018, at 12:11 , Thomas Bellman  wrote:
> 
> On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:
> 
>> There was indeed a fairly long stretch of time (until the CIDR RFC 
>> came out and specifically said it wasn't at all canon) where we 
>> didn't have an RFC that specifically said that netmask bits had to be 
>> contiguous.
> 
> How did routers select the best (most specific) route for an address?
> If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and 
> 10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have 
> the same number of matching bits.
> 
>   /Bellman
> 

The institution of the longest match rule came with the prohibition 
(deprecation) of discontiguous net masks.

Owen
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQP+UHquEepll566aqXCCyZOY1FIQUCXBq72AAKCRCXCCyZOY1F
IVcSAKDwHTb8NranEYcejX1CJQwz0h318QCfSBzQMCiJ2uZwOxt3gvPTe3f38KE=
=HMXc
-END PGP SIGNATURE-

Re: Stupid Question maybe?

[valdis . kletnieks]

On Wed, 19 Dec 2018 21:11:39 +0100, Thomas Bellman said:
> On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:
> > There was indeed a fairly long stretch of time (until the CIDR RFC came out 
> > and
> > specifically said it wasn't at all canon) where we didn't have an RFC that
> > specifically said that netmask bits had to be contiguous.
>
> How did routers select the best (most specific) route for an address?
> If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and
> 10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have
> the same number of matching bits.

That didn't stop sites getting creative with it on their internal networks, and 
I
wouldn't be surprised if at least one router (Bay, Proteon, whatever) happened
to have an implementation that Just Worked.

Remember - there were enough ambiguities and odd implementations that
RFC 1122/1123 had to be issued.  *Lots* of "How the  did that ever
work?" back in those days - and often the answer was "By accident".

Re: Stupid Question maybe?

[Owen DeLong]

> On Dec 19, 2018, at 12:11 , Thomas Bellman  wrote:
> 
> On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:
> 
>> There was indeed a fairly long stretch of time (until the CIDR RFC came out 
>> and
>> specifically said it wasn't at all canon) where we didn't have an RFC that
>> specifically said that netmask bits had to be contiguous.
> 
> How did routers select the best (most specific) route for an address?
> If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and
> 10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have
> the same number of matching bits.
> 
>   /Bellman
> 

The institution of the longest match rule came with the prohibition 
(deprecation) of
discontiguous net masks.

Owen

Re: Stupid Question maybe?

[Thomas Bellman]

On 2018-12-19 21:28 MET, William Herrin wrote:

> Easy: .97 matches neither one because 64 & 97 !=0 and 32 & 97 != 0.
> That's a 0 that has to match at the end of the 10.20.30.

D'oh!  Sorry, I got that wrong.  (Trying to battle 10+% packet loss at
home and a just upgraded Thunderbird at the same time is bad for my
ability to construct consistent email messages, it seems...)  10.20.30.1
is much better example.

> The problem is 10.20.30.1 matches both, so which one takes precedence?
> Can't have a most-specific match when two matching routes have the
> same specificity.
> 
> I'm guessing the answer was: the routing protocols didn't accept
> netmasks in the first place and you were a fool to intentionally
> create overlapping static routes.

Agree that it would be foolish, but I was curious what implementations
did when encountering such a fool. :-)

/Bellman



signature.asc
Description: OpenPGP digital signature

Re: Stupid Question maybe?

[William Herrin]

On Wed, Dec 19, 2018 at 12:12 PM Thomas Bellman  wrote:
> On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:
> > There was indeed a fairly long stretch of time (until the CIDR RFC came out 
> > and
> > specifically said it wasn't at all canon) where we didn't have an RFC that
> > specifically said that netmask bits had to be contiguous.
>
> How did routers select the best (most specific) route for an address?
> If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and
> 10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have
> the same number of matching bits.

Easy: .97 matches neither one because 64 & 97 !=0 and 32 & 97 != 0.
That's a 0 that has to match at the end of the 10.20.30.

The problem is 10.20.30.1 matches both, so which one takes precedence?
Can't have a most-specific match when two matching routes have the
same specificity.

I'm guessing the answer was: the routing protocols didn't accept
netmasks in the first place and you were a fool to intentionally
create overlapping static routes.

Regards,
Bill

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Stupid Question maybe?

[Thomas Bellman]

On 2018-12-19 20:47 MET, valdis.kletni...@vt.edu wrote:

> There was indeed a fairly long stretch of time (until the CIDR RFC came out 
> and
> specifically said it wasn't at all canon) where we didn't have an RFC that
> specifically said that netmask bits had to be contiguous.

How did routers select the best (most specific) route for an address?
If the routing table held both (e.g.) 10.20.30.0/255.255.255.64 and
10.20.30.0/255.255.255.32, then 10.20.30.97 would match both, and have
the same number of matching bits.

/Bellman



signature.asc
Description: OpenPGP digital signature

Re: Stupid Question maybe?

[valdis . kletnieks]

On Tue, 18 Dec 2018 17:12:45 -0500, "David Edelman" said:
> I seem to remember that before the advent of VLSM and CIDR there was no
> requirement for the 1 bits in the netmask to be contiguous with no intervening
> 0 bits and there was always someone who tested it out on a production network
> just to prove a point (usually only once)

So at one show, the Interop show network went to a 255.255.252.0 netmask, and
of course a lot of vendors had issues and complained.  The stock response was
"Quit whining, or next show it's going to be 255.255.250.0".

There was indeed a fairly long stretch of time (until the CIDR RFC came out and
specifically said it wasn't at all canon) where we didn't have an RFC that
specifically said that netmask bits had to be contiguous.

RE: Stupid Question maybe?

[Naslund, Steve]

>Why do you think the network portion needs to be contiguous?

Just because some equipment at one time let you configure a non-contiguous mask 
does not make it correct configuration.  Please come up with any valid use case 
for a non-contiguous network (note NETWORK, not any other purpose) mask.

>Well, it does now. But that was not always the case.

It has ALWAYS been the only correct way to configure equipment and is a 
requirement under CIDR.  Here were your commonly used netmasks before CIDR/VLSM 
:

255.0.0.0
255.255.0.0
255.255.255.0

Which one is not contiguous?

>https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid/answer/Patrick-W-Gilmore

In this example, the writer used it as a parlor trick to actually break a 
network.  That's why you don't do it and it was never a good configuration.  It 
just exploited a UI that did not validate the netmask.

>https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid

In the second cited link, they are talking about using a non-contiguous mask in 
an access control function.  That is perfectly valid to do, it just is not a 
NETmask anymore.  By definition a netmask identifies the network portion of an 
address.  In the cited example they are defining a group of subnets to an ACL.

Steven Naslund
Chicago IL

>
>--
>TTFN,
>patrick

Re: Stupid Question maybe?

[Patrick W. Gilmore]

Why do you think the network portion needs to be contiguous?

Well, it does now. But that was not always the case.

https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid/answer/Patrick-W-Gilmore
https://www.quora.com/Why-is-the-subnet-mask-255-255-255-64-invalid

-- 
TTFN,
patrick

> On Dec 19, 2018, at 09:54, Naslund, Steve  wrote:
> 
> I am wondering how a netmask could be not contiguous when the network portion 
> of the address must be contiguous.  I suppose a bit mask could certainly be 
> anything you want but a netmask specifically identifies the network portion 
> of an address.
> 
> Steve
> 
>> I seem to remember that before the advent of VLSM and CIDR there was 
>> no requirement for the 1 bits in the netmask to be contiguous with no 
>> intervening 0 bits and there was always someone who tested it out on a 
>> production network just to prove a point (usually only once)

Re: Stupid Question maybe?

[William Allen Simpson]

On 12/18/18 8:38 PM, Fred Baker wrote:

On Dec 19, 2018, at 3:50 AM, Brian Kantor  wrote:

/24 is certainly cleaner than 255.255.255.0.

I seem to remember it was Phil Karn who in the early 80's suggested
that expressing subnet masks as the number of bits from the top end
of the address word was efficient, since subnet masks were always
a series of ones followd by zeros with no interspersing, which
was incorporated (or independently invented) about a decade later
as CIDR a.b.c.d/n notation in RFC1519.
- Brian


Actually, not really. In the time frame, there was quite a bit of discussion about "discontiguous" 
subnet masks, which were masks that had at least one zero somewhere within the field of ones. There were some 
who thought they were pretty important. I don't recall whether it was Phil that suggested what we now call 
"prefixes" with a "prefix length", but it was not fait accompli.


Actually, Brian is correct.  Phil was w-a-y ahead of the times.  But I don't
remember him talking about it until the late '80s.  Brian probably knew him 
longer.

Anyway, Fred is also correct.  It took many years, and a lot of argument, before
prefixes were common.  Partly that was me, in PIPE/SIP/SIPP and CIDRD.  Required
longest prefix match in early Neighbor Discovery drafts.

However, I was more of an advocate for suffixes, also known as host mask, 
wanting
them to be common between IPv4 and IPv6.  I still think it would have simplified
setup for operators.  Most don't care how long the network part, they know how
many nodes are needed on the LAN.

Cisco had adopted /n for network prefixes, so I'd proposed //h for host 
suffixes.
Anyway, /n made it into RFCs.



Going with prefixes as we now describe them certainly simplified a lot of 
things.

Take a glance at https://www.google.com/search?q=discontiguous+subnet+masks for 
a history discussion.


Didn't see anything ancient.  Circa 2010 arguments  Apparently, CIDRD 
archives
aren't up anymore.

RE: Stupid Question maybe?

[Naslund, Steve]

I am wondering how a netmask could be not contiguous when the network portion 
of the address must be contiguous.  I suppose a bit mask could certainly be 
anything you want but a netmask specifically identifies the network portion of 
an address.

Steve

> I seem to remember that before the advent of VLSM and CIDR there was 
> no requirement for the 1 bits in the netmask to be contiguous with no 
> intervening 0 bits and there was always someone who tested it out on a 
> production network just to prove a point (usually only once)

Re: Stupid Question maybe?

[t...@pelican.org]

On Tuesday, 18 December, 2018 22:43, "Brandon Martin" 
 said:
 

> This is a favorite interview type question of mine, but I won't
> disqualify a candidate if they can't come up with the reason. It's more
> of a probe for historical domain knowledge (one of many I'll slip in).


It's an interesting flag at interview for me, if it comes up, but I wouldn't 
normally talk about it unless the candidate does first.
 
-If they don't know or mention classful networking at all, they're new 
(relatively, I'm old), and that's fine.
 
-If they can get it right, they're either a long-timer or have done some 
network history.
 
-If they try to use it, and get it wrong, or can't properly explain it, there's 
a warning that they've been cramming network skills from some old and/or 
low-quality sources.  I'd start probing for other warning signs like /24s on 
point-to-point serial links, RIPv1, and the like.
 
Regards,
Tim.
 

Re: Stupid Question maybe?

[Saku Ytti]

On Wed, 19 Dec 2018 at 02:55, Philip Loenneker
 wrote:

> I had a heck of a time a few years back trying to troubleshoot an issue where 
> an upstream provider had an ACL with an incorrect mask along the lines of 
> 255.252.255.0. That was really interesting to talk about once we discovered 
> it, though it caused some loss of hair beforehand...

Juniper originally didn't support them even in ACL use-case but were
forced to add later due to customer demand, so people do have
use-cases for them. If we'd still support them in forwarding, I'm sure
someone would come up with solution which depends on it. I am not
advocating we should, I'll rather take my extra PPS out of the HW.

However there is one quite interesting use-case for discontinuous mask
in ACL. If you have, like you should have, specific block for customer
linknetworks, you can in iACL drop all packets to your side of the
links while still allowing packets to customer side of the links,
making attack surface against your network minimal.


-- 
  ++ytti

Re: Stupid Question maybe?

[Fred Baker]

On Dec 19, 2018, at 3:50 AM, Brian Kantor  wrote:
> /24 is certainly cleaner than 255.255.255.0.
> 
> I seem to remember it was Phil Karn who in the early 80's suggested
> that expressing subnet masks as the number of bits from the top end
> of the address word was efficient, since subnet masks were always
> a series of ones followd by zeros with no interspersing, which
> was incorporated (or independently invented) about a decade later
> as CIDR a.b.c.d/n notation in RFC1519.
>   - Brian

Actually, not really. In the time frame, there was quite a bit of discussion 
about "discontiguous" subnet masks, which were masks that had at least one zero 
somewhere within the field of ones. There were some who thought they were 
pretty important. I don't recall whether it was Phil that suggested what we now 
call "prefixes" with a "prefix length", but it was not fait accompli.

Going with prefixes as we now describe them certainly simplified a lot of 
things.

Take a glance at https://www.google.com/search?q=discontiguous+subnet+masks for 
a history discussion.


signature.asc
Description: Message signed with OpenPGP

RE: Stupid Question maybe?

[Philip Loenneker]

I had a heck of a time a few years back trying to troubleshoot an issue where 
an upstream provider had an ACL with an incorrect mask along the lines of 
255.252.255.0. That was really interesting to talk about once we discovered it, 
though it caused some loss of hair beforehand...

-Original Message-
From: NANOG  On 
Behalf Of Grant Taylor via NANOG
Sent: Wednesday, 19 December 2018 10:27 AM
To: nanog@nanog.org
Subject: Re: Stupid Question maybe?

On 12/18/2018 03:12 PM, David Edelman wrote:
> I seem to remember that before the advent of VLSM and CIDR there was 
> no requirement for the 1 bits in the netmask to be contiguous with no 
> intervening 0 bits and there was always someone who tested it out on a 
> production network just to prove a point (usually only once)

I would love to hear some confirmation of this, or even first hand 
experience.

/Mainly/ for historical / trivial purposes.  (Don't ask, don't tell.)



-- 
Grant. . . .
unix || die

Re: Stupid Question maybe?

[Grant Taylor via NANOG]

On 12/18/2018 03:12 PM, David Edelman wrote:
I seem to remember that before the advent of VLSM and CIDR there was 
no requirement for the 1 bits in the netmask to be contiguous with no 
intervening 0 bits and there was always someone who tested it out on a 
production network just to prove a point (usually only once)


I would love to hear some confirmation of this, or even first hand 
experience.


/Mainly/ for historical / trivial purposes.  (Don't ask, don't tell.)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Stupid Question maybe?

[Brandon Martin]

On 12/18/18 5:52 PM, James R Cutler wrote:

I am certain that I read the RFC years ago, but I can’t remember it.  Which RFC?


RFC796 defines the address formats for classes A, B, and C.  A starts 
with a 0 bit, B starts with 10, and C starts with 110 according to said RFC.

--
Brandon Martin

Re: Stupid Question maybe?

[James R Cutler]

> On Dec 18, 2018, at 5:43 PM, Brandon Martin  wrote:
> 
> On 12/18/18 2:58 PM, Scott Weeks wrote:
>> You can safely say that 72.234.7.0/24 is a
>> Class C/sized/  network.
>> --
>> But most don't say that.  They just say it's
>> a Class C, which it most assuredly is not.
>> I heckle them until they can give the correct
>> answer: leading bits are 110 or it's not a
>> Class C subnet.
>> scott
> 

I am certain that I read the RFC years ago, but I can’t remember it.  Which RFC?

> This is a favorite interview type question of mine, but I won't disqualify a 
> candidate if they can't come up with the reason.  It's more of a probe for 
> historical domain knowledge (one of many I'll slip in).
> -- 
> Brandon Martin

Re: Stupid Question maybe?

[Brandon Martin]

On 12/18/18 2:58 PM, Scott Weeks wrote:

You can safely say that 72.234.7.0/24 is a
Class C/sized/  network.
--

But most don't say that.  They just say it's
a Class C, which it most assuredly is not.
I heckle them until they can give the correct
answer: leading bits are 110 or it's not a
Class C subnet.

scott


This is a favorite interview type question of mine, but I won't 
disqualify a candidate if they can't come up with the reason.  It's more 
of a probe for historical domain knowledge (one of many I'll slip in).

--
Brandon Martin

RE: Stupid Question maybe?

[David Edelman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I seem to remember that before the advent of VLSM and CIDR there was no 
requirement for the 1 bits in the netmask to be contiguous with no intervening 
0 bits and there was always someone who tested it out on a production network 
just to prove a point (usually only once) 

Dave

- -Original Message-
From: NANOG  On Behalf Of Naslund, Steve
Sent: Tuesday, December 18, 2018 3:37 PM
To: nanog@nanog.org
Subject: RE: Stupid Question maybe?

It is a matter of machine readability vs human readability.  Remember the IP 
was around when routers did not have a lot of horsepower.  The dotted decimal 
notation was a compromise between pure binary (which the equipment used) and 
human readability.  VLSM seems obvious now but in the beginning organizing 
various length routes into very expensive memory and low horsepower processors 
meant that it was much easier to break routes down along byte boundaries.  This 
meant you only had four different lengths of route to deal with.  It was 
intended to eliminate multiple passes sorting the tables.  I am not quite sure 
what you mean about interspersing zeros, that would be meaningless.  Remember 
that it is a mask.  The address bits which are masked as 1s are significant to 
routing.  The bits that are masked with 0s are the host portion and don't 
matter to the network routing table.  

Steven Naslund
Chicago IL


>/24 is certainly cleaner than 255.255.255.0.
>
>I seem to remember it was Phil Karn who in the early 80's suggested that 
>expressing subnet masks as the number of bits from the top end of the address 
>word was efficient, since subnet masks were always a series of ones followd 
>>by zeros with no interspersing, which was incorporated (or independently 
>invented) about a decade later as CIDR a.b.c.d/n notation in RFC1519.
>   - Brian
-BEGIN PGP SIGNATURE-

iF0EARECAB0WIQQP+UHquEepll566aqXCCyZOY1FIQUCXBlw1AAKCRCXCCyZOY1F
IYkTAJ98Gh+IGhDcyIB92H9JyWtbCVDhugCfZXq60pnHCqttKfw2fpUCBagTxYo=
=RimM
-END PGP SIGNATURE-

RE: Stupid Question maybe?

[Naslund, Steve]

I see it more used in terms of firewall operations on what are normally network 
routing devices.  I suppose someone with Cisco IOS architecture inside 
knowledge could tell us why they use that notation with ACLs primarily.  

 I have never seen a computer want or accept an inverse mask so it is 
irrelevant to ARP.  The question with ARP is "are we on the same network".

The naming of inverse net mask is really tragic.  It should be called net mask 
and host mask because that is what they really are.  In a net mask the 1s 
denote the network portion, in the host mask (nee inverse netmask) the 1s 
denote the host portion.  That's all there is too it.

The inverse mask could be used to figure out whether to ARP or not.  You just 
have to decide if the 1s or 0s mean that something is significant or not 
significant to your calculation.  Using the inverse mask I could decide to dump 
the portion = 1.  Using the network mask I can dump the portion = 0.  Nothing 
states how you have to use the information.

Steve

>Hi Steve,
>
>That's like saying the inverse mask is technically correct when the computer 
>wants to decide whether to arp for the next hop. No sale man.
>
>A AND NETMASK ?= B AND NETMASK
>
>is exactly the same operation as
>
>A OR inverse NETMASK ?= B OR inverse NETMASK
>
>While A AND inverse NETMASK ?= B AND inverse NETMASK *never* yields useful 
>knowledge.
>
>No sale.
>
>Regards,
>Bill Herrin

Re: Stupid Question maybe?

[William Herrin]

On Tue, Dec 18, 2018 at 1:30 PM Naslund, Steve  wrote:
> 2.  The inverse mask is indeed a pain in the neck but is technically 
> correct.

Hi Steve,

That's like saying the inverse mask is technically correct when the
computer wants to decide whether to arp for the next hop. No sale man.

A AND NETMASK ?= B AND NETMASK

is exactly the same operation as

A OR inverse NETMASK ?= B OR inverse NETMASK

While A AND inverse NETMASK ?= B AND inverse NETMASK *never* yields
useful knowledge.

No sale.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

RE: Stupid Question maybe?

[Naslund, Steve]

Two reasons :


1.  Legacy configuration portability, people learned a certain way and all 
versions of code understand a certain way.  The best way to correct that issue 
it to accept either of them.

2.  The inverse mask is indeed a pain in the neck but is technically 
correct.  The subnet mask is used where the equipment cares to work with the 
network portion of the address (ignoring the host).  The inverse mask is 
important where the equipment cares more about the host we are referring to 
(ignoring the network).  It’s a bit of a cheat to allow for code used in 
routing to be used for ACL and firewall without modification to the code.  For 
example, the same code piece that routes a network toward an Ethernet interface 
can be reused to route a host toward a null interface.

Steven Naslund
Chicago IL

>Why do we still have network equipment, where half the configuration requires 
>netmask notation, the other half requires CIDR and to throw you off, they also 
>included inverse netmasks.

Re: Stupid Question maybe?

[Baldur Norddahl]

Why do we still have network equipment, where half the configuration
requires netmask notation, the other half requires CIDR and to throw you
off, they also included inverse netmasks.


tir. 18. dec. 2018 20.51 skrev Brian Kantor :

>
> /24 is certainly cleaner than 255.255.255.0.
>
> I seem to remember it was Phil Karn who in the early 80's suggested
> that expressing subnet masks as the number of bits from the top end
> of the address word was efficient, since subnet masks were always
> a series of ones followd by zeros with no interspersing, which
> was incorporated (or independently invented) about a decade later
> as CIDR a.b.c.d/n notation in RFC1519.
> - Brian
>
>

RE: Stupid Question maybe?

[Naslund, Steve]

It is a matter of machine readability vs human readability.  Remember the IP 
was around when routers did not have a lot of horsepower.  The dotted decimal 
notation was a compromise between pure binary (which the equipment used) and 
human readability.  VLSM seems obvious now but in the beginning organizing 
various length routes into very expensive memory and low horsepower processors 
meant that it was much easier to break routes down along byte boundaries.  This 
meant you only had four different lengths of route to deal with.  It was 
intended to eliminate multiple passes sorting the tables.  I am not quite sure 
what you mean about interspersing zeros, that would be meaningless.  Remember 
that it is a mask.  The address bits which are masked as 1s are significant to 
routing.  The bits that are masked with 0s are the host portion and don't 
matter to the network routing table.  

Steven Naslund
Chicago IL


>/24 is certainly cleaner than 255.255.255.0.
>
>I seem to remember it was Phil Karn who in the early 80's suggested that 
>expressing subnet masks as the number of bits from the top end of the address 
>word was efficient, since subnet masks were always a series of ones followd 
>>by zeros with no interspersing, which was incorporated (or independently 
>invented) about a decade later as CIDR a.b.c.d/n notation in RFC1519.
>   - Brian

Re: Stupid Question maybe?

[Saku Ytti]

On Tue, 18 Dec 2018 at 21:52, Brian Kantor  wrote:

> of the address word was efficient, since subnet masks were always
> a series of ones followd by zeros with no interspersing, which
> was incorporated (or independently invented) about a decade later

>From protocol POV there is no reason to make this assumption. It just
seems to make more sense for humans and modern hardware make the
assumption for forwarding, like it does make assumptions for the
distribution of prefix sizes, anything to get more out of less. For
ACL that assumption is still not true. It's optimisation which loses
information which for the common case does not matter.

-- 
  ++ytti

Re: Stupid Question maybe?

[Scott Weeks]

--- nanog@nanog.org wrote:
From: Grant Taylor via NANOG 

You can safely say that 72.234.7.0/24 is a 
Class C /sized/ network. 
--

But most don't say that.  They just say it's 
a Class C, which it most assuredly is not.  
I heckle them until they can give the correct 
answer: leading bits are 110 or it's not a 
Class C subnet.

scott

Re: Stupid Question maybe?

[Brian Kantor]

/24 is certainly cleaner than 255.255.255.0.

I seem to remember it was Phil Karn who in the early 80's suggested
that expressing subnet masks as the number of bits from the top end
of the address word was efficient, since subnet masks were always
a series of ones followd by zeros with no interspersing, which
was incorporated (or independently invented) about a decade later
as CIDR a.b.c.d/n notation in RFC1519.
- Brian

Re: Stupid Question maybe?

[Grant Taylor via NANOG]

On 12/18/2018 11:44 AM, Scott Weeks wrote:
It's good to have at least a passing understanding of the old terminology 
simply because documentation for newer stuff likes to reference it...


Agreed.

I seldom see people actually talking about class {A,B,C,D,E} networks as 
such.  It's almost always a reference to the size ~> netmask ~> prefix 
of a network.


Plus it's fun (and informative about a netgeek's skill) when they call, 
say, 72.234.7.0/24 a Class C and you can say no it's not.  Then you see 
if they can say why.  If they can't, well...ummm... I really mess with 
them after that.  It helps pass the work day. >;-)


You can safely say that 72.234.7.0/24 is a Class C /sized/ network. 
While it happens to be in the (former) Class A IP /range/.  But it is 
most decidedly /not/ a Class A /network/.



ps.  Be sure to send Wikipedia a small Christmas gift.  It's invaluable.


Agreed!



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Stupid Question maybe?

[William Herrin]

On Mon, Dec 17, 2018 at 9:36 PM 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.

Hi Joe,

Take everything you've ever heard about classful networking, throw it
away, and outside of trivia games never think about it again. Network
address classes haven't been a valid part of TCP/IP for more than two
decades now.

For historical trivia purposes only, the CIDR /16 replaced class B.
Had RFC 1918 come out before CIDR (RFC 1519),
172.16.0.0-172.31.255.255 would have described 16 contiguous class
B's, not just one, while 192.168.0.0-192.168.255.255 would have
described 256 contiguous class C's. In fact, this terminology is used
in RFC 1918's predecessor, RFC 1597.

And if you really like trivia, find the math error in RFC 1597.

Class A started at 0.0.0.0, class B started at 128.0.0.0 and class C
started at 192.0.0.0. There was also a class D (now the multicast
address space) starting at 224.0.0.0 and a class E (still reserved)
starting at 240.0.0.0.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Stupid Question maybe?

[Scott Weeks]

--- beec...@beecher.cc wrote:
From: Tom Beecher 

It's good to have at least a passing understanding of 
the old terminology simply because documentation for 
newer stuff likes to reference it...
--


Plus it's fun (and informative about a netgeek's skill) 
when they call, say, 72.234.7.0/24 a Class C and you 
can say no it's not.  Then you see if they can say why.  
If they can't, well...ummm... I really mess with them 
after that.  It helps pass the work day. >;-)

https://en.wikipedia.org/wiki/Classful_network#Classful_addressing_definition

scott


ps.  Be sure to send Wikipedia a small Christmas gift.  
It's invaluable.

Re: Stupid Question maybe?

[George William Herbert]

Sent from my iPhone

> On Dec 17, 2018, at 9:36 PM, Joe  wrote:
> 
> 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. 

You had it right to start with.

A is (was)  /8, B is /16, C is /24 

All on human easily readable byte boundaries in IPv4 space.

The RFC-1918 internal space was allocated from a /8, a /12, and a /16 sized 
block.  Those aren't A, B, or C network sizes.  Whoever corrected you is 
confused.

Anyone who networked before and during the CIDR transition won't forget this...


-george 

Re: Stupid Question maybe?

[Tom Beecher]

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 
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
> >
>

Re: Stupid Question maybe?

[Justin M. Streiner]

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

Re: Stupid Question maybe?

[Owen DeLong]

Class A,B,C represent the position of the first 0 bit in the address and a 
corresponding natural netmask. A=1st bit (/8), B=2nd bit (10xx, /16), and 
C=3rd bit (110x, /24). 

The confusion you seem to be experiencing related to the number of A,B, and C 
networks defined in RFC-1918 (private address space). 

In this case, a ingle A (10.0.0.0/8), 16 Bs (172.16.0.0/12), and 256 Cs 
(192.168.0.0/16) were set aside for private networks. 

Later, an additional block was reserved for CGNAT intermediary space 
(100.64.0.0/10 IIRC). 

Owen



> On Dec 17, 2018, at 21:36, 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. 
> 
> 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

Re: Stupid Question maybe?

[Jeremy Austin]

You may find this helpful in your search for knowledge:

https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing

"Classful" networking is rarely useful other than for understanding How We
Got Here.

There's a handy table in the linked article which expresses each IPv4 mask
length in relation to how many A, B, or C networks it is.

jermudgeon

On Mon, Dec 17, 2018 at 8:37 PM 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.
>
> 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
>


-- 
Jeremy Austin
jhaus...@gmail.com

(907) 895-2311 office
(907) 803-5422 cell

Stupid Question maybe?

[Joe]

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.

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