Update private_network.txt

[macfreek]

Remove spurious "/10"; remove incorrectly named "Class B" and "Class C".

[mintsoft]

@macfreek Looks like you've missed a test: https://travis-ci.org/duckduckgo/zeroclickinfo-goodies/jobs/18369569#L790

Btw: completely agree on the incorrect /10, however I don't understand why you've removed the classes?

[macfreek]

@mintsoft The terms "Class A", "Class B" and "Class C" have a special (albeit historic) meaning when it comes to IPv4 ranges: Class A is a /8, Class B is a /16, and Class C is a /24. (See RFC 791; this was obsoleted with CIDR in RFC 1518 in 1993).

The ranges mentioned in the text were /8, /12 and /16 respectively. Not /8, /16 and /24. Removing the "Class" nominator removes potential confusion.

The naming of RFC 1918 is ""24-bit block", "20-bit block", and "16-bit block" respectively. I don't think including these names are useful, so I just left them out.

I've updated the test, as well as the HTML snippet. It should work now (Travis succeeds for Perl 5.16. The error Perl 5.14 seems due to changes unrelated to this commit).

[mintsoft]

@macfreek Thanks for the updates.

WRT the tests you're completely correct; the 5.14 tests are failing due to some dependency issues that are currently being resolved elsewhere.

I agree with what you're saying regarding CIDR vs classful networking however RFC 1918 doesn't actually remove classifications from networks, only supplementing their use with CIDR for routing purposes. Unfortunately due to the reality of IPv4 this all gets very messy:

In this context the Class is referring not to the size of the blocks, but the actual network class, for example, 5.1.1.0/24 is Class A but only covers 254 usable addresses.

The ranges in the text were referring to the range of the available private IP's not the range of the class. This is consistent with other networking information (i.e. https://duckduckgo.com/?q=16.0.0.0%2F22 https://www.wolframalpha.com/input/?i=16.0.0.0%2F22 )

Personally, I lean towards leaving the classes in as they are technically correct, however I can understand where you were coming from in removing them :)

@jagtalon What are your thoughts on this? I'm unsure which way is best for consistency.

Could we arrange the data differently to help remove confusion?

[macfreek]

Cool, I've learned something today. Thanks! I never thought of e.g. subnets within 0.0.0.0/1 as "Class A" subnets. But then again, I've only been active in networking for 15 years, after people stopped using these designations.

I still recommend removing them. There is no functional distinction between subnets in class A, B and C, while class D is best referred to as "multicast" and class E as "reserved".

As for the goodie you just mentioned:

• I would remove the class there as well. Instead, list actual relevant information, in particular if the specified subnet is part of a special-purpose registry as defined by IANA (IPv4 special-purpose addresses, IPv6 special-purpose addresses), along with it's properties (Forwardable, Global, Reserved).
• Even if the class information is kept there for archaic reasons, there is still a small bug in there: 128.0.0.0/1 is not a class B, it overlaps class B, C, D and E. :)

If you'll list the goodie, I can create a bug report and see if I can fix it.

[mintsoft]

About keeping/leaving-them-in, I'm interested to see what other people think and see if we can reach a consensus.

I'll raise an issue for the Subnet Calculator to be improved by adding more detailed information on the missing address blocks. That said, there isn't a bug in the calculator as I understand it. Any address in the range 128.0.0.0 -> 191.255.255.255 is a Class B address. A Class B address is any IP address for which the 2 most significant bits are 10. (http://resources.intenseschool.com/ccna-prep-analyzing-classful-ipv4-networks/)

[macfreek]

128.0.0.0/1 is 128.0.0.0 - 255.255.255.255. So it includes all IP addresses starting with digit 1: both 10 (class B), but also 110 (class C), 1110 (class D), and 1111 (class E).

But please don't waste time on this. I just happen to like finding extreme cases.

This pull request is about improving the text. Any other suggestions should probably go to #319.

[mintsoft]

Oh sorry! Yes I'm with you now, I totally missed the /1

[jagtalon]

@mintsoft I think we should just merge this in. @crazedpsyc if it's okay with you then this should be good to go. :)

[mintsoft]

@jagtalon no objections from me!

[jagtalon]

Nice, @macfreek