Info on private IP addressing

[spidey07]

If you want to know more check out RFC 1918.

Many times these addresses are calld 'unroutable.' There is really nothing special about 192.168.0.0/16, 10.0.0.0/8 or 172.16.0.0/12. Just another IP address range. But with the introduction of RFC1918 the internet numbering association said "let's reserve these for private use"

Any router will route them just like any other route. You can even send them over the internet. Heck a whole LOT of service providers use them to form the core of their network.

BUT!

The key is that any Internet router, particuarlly border routers which are at the edge of a providers network are supposed to filter these addresses. A common practice is to simply route any packet with a source or destination IP address of the private IP range to NULL0. Null0 being a special interface on a router that says "bit bucket" or "drop this packet" The NULL0 interface is used because the routers hardware is generally optimized to route instead of process access lists which would just say "drop the packet"

So are these addresses non-routable on the Internet? Not really, but most all providers will drop the packets.

For more info on best practices for Internet Routers see RFC 2827. For special IP addresses see RFC 3330.

http://www.ietf.org/rfc/rfc1918.txt?number=1918
http://www.ietf.org/rfc/rfc2827.txt?number=2827
http://www.ietf.org/rfc/rfc3330.txt?number=3330

 

[kamper]

Hmmm, thanks for the lecture spidey

What do you mean when you say that "service providers use them to form the core of their network"? I picture a residential isp type of thing giving out 10.x.x.x ip addresses to households and hiding it's entire network behind a big nat. Or is it more like when they have chunks of their network that consists entirely of connections between their own private routers and they just use those numbers for interfaces between their own hardware?

 

[spidey07]

Not really a lecture, just felt like sharing.


You're real close though. Its not NAT, but the provider network could use private addressing.

The entire ISP network is considered an autonomous system - a single network under a common routing/administrative policy. All the routers in the "core" of the ISP network do nothing more than route packets to other autonomous systems.

It isn't really NAT, its just that the border routers on the ISP net are directly connected to the actual "internet" and as such use public IP address space, owned by them. We'd get deep into BGP stuff to go further but on a scale like this think of actual autonomous systems rather than individual routers.

On the core of the network the SP uses a routing protocol like OSPF or IS-IS to maintain the fast convergence and hiearchy of the core. At the edge of the network the run BGP to maintain actual path information.

jeez, I'm just gonna stop now. Its too hard to explain without a white board.

 

[kamper]

No, I'm following you. Actually, I'm studying the Network Layer chapter in my networking text book right now so I'm particulary interested.

So the devices using the unroutable addresses would be routers that don't ever need to send their own packets outside of the autonomous system right? But if there is a host connected to this system that is talking to other machines on the internet or a router at the edge of the AS then it gets a routable address? I suppose the internal routers that expose themselves to the hosts also need routable addresses on the same subnet as the hosts themselves.

 

[spidey07]

in a ISP network you have the "transport" network - all it does it route traffic.

then you have the internal network and maybe even the managenet network.

So there are no hosts on the transport network - its job is to route frames between ASes. The hosts are on the internal network and they have ways to exit the network as well. The management network is for administration/troubleshooting/monitoring/reporting/events/provisioning.

All these networks aren't necessarily separate devices. Its all in the IP design.

decent doc I found by googling "isp design bgp address space"
http://ipmon.sprintlabs.com/pu...re-And-Performance.pdf

 

[n0cmonkey]

I've encountered plenty of RFC1918 addresses on the insides of various ISPs (particularly Verizon and Adelphia). It's fairly common, since these machines probably don't have any reason to connect directly to systems outside of the internal network.

Interesting posts as always spidey07.

 

[geejo]

Originally posted by: spidey07


The key is that any Internet router, particuarlly border routers which are at the edge of a providers network are supposed to filter these addresses. A common practice is to simply route any packet with a source or destination IP address of the private IP range to NULL0. Null0 being a special interface on a router that says "bit bucket" or "drop this packet" The NULL0 interface is used because the routers hardware is generally optimized to route instead of process access lists which would just say "drop the packet"

Thanks for the info spidey07. Its very useful if Info threads like this one posted here more often

 

[Tazanator]

there are several others too to watch for ...
heres some of my router rules ...

# Refuse packets claiming to be to the loopback interface.
/sbin/iptables -A INPUT -i $WAN -d 127.0.0.1 -j DROP
# Refuse broadcast address packets.
/sbin/iptables -A INPUT -i $WAN -d 192.168.1.255 -j DROP
# Refuse Class D multicast addresses.
/sbin/iptables -A INPUT -i $WAN -s 224.0.0.0/4 -j DROP
## Refuse Class E reserved IP addresses.
/sbin/iptables -A INPUT -i $WAN -s 240.0.0.0/4 -j DROP

##########################################
#Block ICMP Scans #
##########################################
echo "MCBlaster blocking ON"
#drop all MSBlaster-type worms with ICMP scans of 92 bytes
iptables -A FORWARD -p icmp -m length --length 92 -j DROP
#Allow all "normal" ICMP traffic through router
iptables -A FORWARD -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type source-quench -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type parameter-problem -j ACCEPT
iptables -A FORWARD -p icmp --icmp-type echo-reply -j ACCEPT
##########################################
# DOS reduction
##########################################
#Limit inbound echo-request to 10 per second, with burst limit of 10 from WAN
iptables -A FORWARD -i $WAN -m limit --limit 10/s --limit-burst 10 -p icmp --icmp-type echo-request -j ACCEPT
#Limit outbound echo-request to 5 per second, with burst limit of 30 to WAN
iptables -A FORWARD -o $WAN -m limit --limit 5/s --limit-burst 30 -p icmp --icmp-type echo-request -j ACCEPT
#Drop any icmp traffic over the limits specified above
iptables -A FORWARD -p icmp -j DROP
##########################################
#Worm traffic blocking
##########################################
#Block common worm traffic coming in via External interfaces
iptables -A FORWARD -j DROP -i $WAN -p tcp --dport 135:139
iptables -A FORWARD -j DROP -i $WAN -p udp --dport 135:139
iptables -A FORWARD -j DROP -i $WAN -p tcp --dport 444
iptables -A FORWARD -j DROP -i $WAN -p udp --dport 444
iptables -A FORWARD -j DROP -i $WAN -p udp --dport 995:999
iptables -A FORWARD -j DROP -i $WAN -p udp --dport 8998
#Block access to backdoor on system infected by W32.Novarg.a@mm Worm
iptables -A FORWARD -p tcp --dport 3127:3149 -j DROP
#Block incoming DHCP requests
iptables -A FORWARD -j DROP -i $WAN -p tcp --dport 67