Will ISP Use of 10.0.0.0 Addresses Cause Problems?
"The setup is a small network, 6 PC's and one server. The server has Microsoft Small Business Server 4.5 (Proxy Server) loaded. Intermittently the PC's would lose connection to the server and start broadcasting for a master browser reelection. These requests were logged in the server event log. We also found that sometimes the subnet masks of the PC's would change from 255.255.255.0 to 255.0.0.0. The server acts as the DHCP server and the PC's were using DHCP. Rebooting the server would fix the problem for a time, maybe 10 minutes, maybe a day. Sometime the problem would go away without rebooting the server. The network was 10.0.0.0 with subnet 255.255.255.0.
I found that the problem was caused by the dial-up networking connection to the ISP. One of the ISP's servers is configured to use the Class A 10.0.0.0 addresses and network address translation the others use real IP addresses. The problem was intermittent because it would just depend on which of the ISP servers we happen to connect through. I resolved the problem by changing the internal network to 192.168.0.0."
10.0.0.0/8 -- You got that one right.
172.16.0.0/12 -- That right, too
You messed up on the other one, though. It's 192.168.0.0/16. That's right, the full 192.168.0.0 - 192.168.255.255 range is open.
Ref: RCF1918
--
--
"I personal[ly] think Unix is "superior" because on LSD it tastes like Blue." -- jbarnett
These can be summarized as follows:
If packets from the IP address will never reach the public internet without it being re-written (NAT'd) to a public address, then it is ok.
Some ISP's think that it's ok to use RFC1918 addresses on their internal point-to-point links. It is not. The reason why is that many ISP's filter anything coming from or going to a RFC1918 address because they generally are bogus packets anyways. However, if the RFC1918 addresses are used on internet visible interfaces, this causes things to break.
A good example of this is MTU path discovery. Basically this works by sending a packet from point a to point b with the don't fragment bit set. If the packet reaches a router which can't handle a packet of that size, the router sends back an ICMP packet which basically tells the "Discovering" machine that it couldn't forward the packet because it was too big for it's MTU setting. If the IP address of the offending router's interface happens to be an RFC1918 address, then you might never see the ICMP back and as such you will have weird problems going on.
Note: This is also why you shouldn't just filter ICMP packets.
In the case above, it sounds like the ISP is using the 10.0.0.0 address internally. As they also had the customer using the 10.0.0.0 address range, this could get weird really fast.
This was the words out of the mouth of a MSCE when I had set up an office environment with network 10. Because the office was rather large, I had thought to use 10.0.0.x/24 for the main office network and 10.0.1.x/24 for the lab. When DSL testing was to go in, the DSL and LAN lab would use 10.0.[234].x/24 for primary DSL, primary LAN, and secondary LAN.
I took the advice, and selected 10.1.[1234].0/24, and things worked swell.
This proved to be excellent advice when we started testing with Cisco router-access servers, because those things do NOT like a zero in any quad. With 10.1.1.0/24, though, everything worked great.
I now continue that practice, using 10.1.1.0/24 for any small private network I set up. Because the gateway to the Internet uses NAT, I'm not concerned about what the numbering is on the other side. In any case, every firewall is configured to not forward the private network addresses.
This works with NT, 2K, 98, 95, 3.1, and Linux. Not to mention BDS, Ascend, Cisco, USRobotics Total Control, Portmaster, and other RAS brands.