If you are within the range of this network, why not just connect to it? Ask the network owner to provide you with the credentials and network settings you need and you're good to go. Working your way around a network security will only cause you headache, not to mention that it's illegal.
First, understand that any idea of network classes lost its relevance sometime in the mid 1990's. Protocols where classes were significant have versions that accept subnet masks as additional parameters and do not care about what class an IP address is in.
There are three ranges of private IP addresses, and one for each class, but the class doesn't have any meaning anymore, unless you are using an ancient protocol that doesn't let you specify a subnet mask with IP addresses. What does have meaning is the subnet associated with each "class":
RFC1918 name IP address range subnet mask
24-bit block 10.0.0.0 - 10.255.255.255 /8 or 255.0.0.0
20-bit block 172.16.0.0 - 172.31.255.255 /12 or 255.240.0.0
16-bit block 192.168.0.0 - 192.168.255.255 /16 or 255.255.0.0
If your company is really distributing private addresses to customers (this is called Carrier Grade NAT), then you are stuck with what your ISP provides as far as the interface where your computer or network connects to the ISP.
Second, your router has two interfaces. One faces the IP and receives an IP from your ISP's DHCP server. The other is facing your network and completely up to you what you do with. Now, if you are going to reuse any addresses your ISP is using, then you will have to juggle some complex NAT rules. A consumer-level router may not support such complex NAT rules - a Linux PC with iptables can do it but it's difficult to set up.
So, it is possible, but usually a lot easier to just select a range your ISP is not using. It doesn't matter which one. 10.0.0.0/8 is typically what businesses choose by convention, but it is just a convention.
Now, with the right NAT setup, you could pick any IP range out of thin air and use it on your home network. However, if your configuration has an error, traffic destined for your home network may go to external hosts instead. The above "private" IP ranges are agreed to be "non-routable" - if they happen to make it to your ISP, your ISP is supposed to drop them. With carrier-grade NAT being an exception of course. So if you use a private IP range that your ISP is not using, it protects you from a consequence of accidental misconfiguration.
Best Answer
127/8 (shorthand for 127.0.0.0/8) is reserved by IANA.
Win95 supported 127.0.0.1 but not other 127/8 addresses. WinXP supported 127/8. Cisco IOS supports no loopback addresses by default, but does support the loopback concept, and addresses can be manually assigned. If a computer has no need for more than one loopback address, or zero of them, there's no reason it has to support all those addresses. But, since IANA has now reserved all of them for that purpose, there is no compelling reason for a TCP/IP stack to not support them.
For the most part, there's no compelling need for multiple addresses; I often use multiple loopback connections, but can do so simply by specifying different TCP ports. (I do it for SSH port forwarding. Other VPN software may also be a frequent user for such things, as Isaac Hanson referred to in his answer.) Whether you use different TCP ports on one address (there are 65,535 of them), or multiple IP addresses, makes little technical difference. (However, having unique addresses might be easier in some cases, like if you had multiple servers that could listen to the same "default" port number.)
Ah, such strong language. Allow me to rile you up further :)
Actually, the much bigger waste of IPv4 addresses is 224/3, which contains 224/4 (minimally used for multicast) and 240/4 (almost entirely wasted, with just one address as the exception). So, don't think that we're almost out of IPv4 addresses. IANA has just been handing out the addresses from the former Class A, Class B, and Class C. But don't think for a minute that every last address has been used in the most effective way possible. To see some others: IETF BCP 153 (currently points to RFC 6890). The older RFC 5735 had much of the same information in a different format, e.g. section 4 on page 6. Poke around those, or some other standards, and I'm pretty sure you can find some other large amounts of addresses that are not being super-efficiently used/allocated.
It was decided that supporting some standards may be more desirable than helping IPv4 to limp along even more. One key reason for this may be that some people really were wanting to help push people towards IPv6 adoption.