Stupid Question maybe?
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
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 <jbfixurpc@gmail.com> 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 jhaustin@gmail.com (907) 895-2311 office (907) 803-5422 cell
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 (10xxxxxx, /16), and C=3rd bit (110xxxxx, /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 <jbfixurpc@gmail.com> 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
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
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@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
Sent from my iPhone
On Dec 17, 2018, at 9:36 PM, Joe <jbfixurpc@gmail.com> 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
On Mon, Dec 17, 2018 at 9:36 PM Joe <jbfixurpc@gmail.com> 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 ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
/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
On Tue, 18 Dec 2018 at 21:52, Brian Kantor <Brian@ampr.org> 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
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 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 <nanog-bounces@nanog.org> 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-----
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 <nanog-bounces@nanog.org> 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-----
On 18 Dec 2018, at 22:30, Joel Halpern <jmh@joelhalpern.com> 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 0xffff0003 instead of 0xffffc000, 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.finch <dot@dotat.at> http://dotat.at
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 <dot@dotat.at> wrote:
On 18 Dec 2018, at 22:30, Joel Halpern <jmh@joelhalpern.com> 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 0xffff0003 instead of 0xffffc000, 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.finch <dot@dotat.at> http://dotat.at
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
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 <nanog-bounces+philip.loenneker=tasmanet.com.au@nanog.org> 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
On Wed, 19 Dec 2018 at 02:55, Philip Loenneker <Philip.Loenneker@tasmanet.com.au> 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
On Wed, Dec 19, 2018 at 8:32 AM Saku Ytti <saku@ytti.fi> wrote:
On Wed, 19 Dec 2018 at 02:55, Philip Loenneker <Philip.Loenneker@tasmanet.com.au> 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@errxtx.net PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318
On Thu, 20 Dec 2018 at 10:32, Christian Meutes <christian@errxtx.net> 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
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
On Thu, 20 Dec 2018 at 18:22, Grant Taylor via NANOG <nanog@nanog.org> 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
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
On Thu, 20 Dec 2018 at 21:06, Grant Taylor via NANOG <nanog@nanog.org> 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
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)
On Wed, 2018-12-19 at 14:54 +0000, 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 smoot@tic.com
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/P... 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 <SNaslund@medline.com> 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)
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/P...
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
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
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.
On 2018-12-19 20:47 MET, valdis.kletnieks@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
On Wed, Dec 19, 2018 at 12:12 PM Thomas Bellman <bellman@nsc.liu.se> wrote:
On 2018-12-19 20:47 MET, valdis.kletnieks@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 ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
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
On Dec 19, 2018, at 12:11 , Thomas Bellman <bellman@nsc.liu.se> wrote:
On 2018-12-19 20:47 MET, valdis.kletnieks@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 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 <nanog-bounces@nanog.org> On Behalf Of Owen DeLong Sent: Wednesday, December 19, 2018 3:47 PM To: Thomas Bellman <bellman@nsc.liu.se> Cc: nanog@nanog.org Subject: Re: Stupid Question maybe?
On Dec 19, 2018, at 12:11 , Thomas Bellman <bellman@nsc.liu.se> wrote:
On 2018-12-19 20:47 MET, valdis.kletnieks@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-----
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...
On Wed, 19 Dec 2018 21:11:39 +0100, Thomas Bellman said:
On 2018-12-19 20:47 MET, valdis.kletnieks@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 <expletive> did that ever work?" back in those days - and often the answer was "By accident".
On 12/19/18 2:47 PM, valdis.kletnieks@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 0x4xxxxxxx. Interop really used to be a blessing, before it became just another show.
On Thu, 20 Dec 2018 at 20:07, William Allen Simpson <william.allen.simpson@gmail.com> 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 0x4xxxxxxx.
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
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 <Brian@ampr.org>:
/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
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.
On Tue, Dec 18, 2018 at 1:30 PM Naslund, Steve <SNaslund@medline.com> 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 ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
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
* 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.
On Dec 19, 2018, at 3:50 AM, Brian Kantor <Brian@ampr.org> 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.
On 12/18/18 8:38 PM, Fred Baker wrote:
On Dec 19, 2018, at 3:50 AM, Brian Kantor <Brian@ampr.org> 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.
participants (26)
-
Adam Atkinson -
Baldur Norddahl -
Brian Kantor -
Christian Meutes -
Chuck Church -
David Edelman -
Florian Weimer -
Fred Baker -
George William Herbert -
Grant Taylor -
Jeremy Austin -
Joe -
Joel Halpern -
Justin M. Streiner -
Naslund, Steve -
Owen DeLong -
Patrick W. Gilmore -
Philip Loenneker -
Saku Ytti -
Smoot Carl-Mitchell -
Thomas Bellman -
Tom Beecher -
Tony Finch -
valdis.kletnieks＠vt.edu -
William Allen Simpson -
William Herrin