I'll guess mindcrime is the original poster. Due to responses to multiple threads, I figure a single explanation should suffice, referenced to related portions.

I'll guess mindcrime is the original poster. Due to responses to multiple threads, I figure a single explanation should suffice, referenced to related portions. a904guy is using addresses that are not in the RFC 1918 block for his personal network. While this is discouraged, there isn't anything preventing it. It can cause problems if someone decides to later use 11.1.11.0/24 since he wouldn't be able to use those addresses locally AND talk to external sites on that same netblock without doing some creative NAT. Secondly, yes, the provider should use RFC 1918 and RFC 4193 blocks. While this can cause problems when provider A uses 10.0.0.0/24 and provider B uses 10.0.0.0/24 and Provider A later buys Provider B, the private address blocks are there and are not supposed to be routed or announced outside local networks. In this case, it appears that Time Warner (or whomever), used 28.0.0.0/8 internally. This probably dates back to the @home network when the providers shared responsibility and grabbed the 24.0.0.0/8 block, then, later split and renumbered. TWC may have just swapped 24 for 28 on their network to eliminate re-engineering. No way to know for sure without someone knowing some history. shareme: There is a difference between DNS registered (which this block is not), and assigned and registered by ARIN. ARIN delegates blocks to particular entities and maintains that directory. That doesn't mean I can't use those IP addresses locally (I wouldn't be able to announce them to the global internet - well, you could if you had upstream providers willing or negligent in their best practices). The government is not leasing IP addresses to Sprint. How do we know this? Because the IP addresses are not being announced by anyone: HE.inet.0: 42 destinations, 42 routes (41 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 28w4d 15:04:18 > to x.x.x.x via ge-0/3/0.0 Internap.inet.0: 42 destinations, 42 routes (41 active, 0 holddown, 1 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 28w4d 15:03:57 > to x.x.x.x via ge-0/1/0.0 or, if you don't trust an active routing table that has defaults set, you can look at route-views: route-views>show ip bgp 28.191.58.169 BGP routing table entry for 0.0.0.0/0, version 338718131 Paths: (1 available, best #1, table Default-IP-Routing-Table, RIB-failure(17)) Not advertised to any peer 2905 65524 16637 196.7.106.245 from 196.7.106.245 (196.7.106.245) Origin IGP, metric 0, localpref 100, valid, external, best Now, related to this conversation, but included in a separate blog post, are some traceroutes that show packets vanishing into thin air as they exit networks. As most networks don't run defaultless - they have a default path just in case they receive a packet for an IP address that isn't in their routing table. This happens when you have a client of a provider that may not have their filters set properly, or, are have odd confederations or community settings that you don't see their announcement. Rather than blackhole those organizations, one normally has a default route pointed to a provider. A backbone provider would more likely run defaultless, a host or Internet Service Provider would normally run with a default route. So, you run a traceroute on a network that has a default route, and it gets to the border to a provider that doesn't run defaults and the packet is dropped. The DoD isn't filtering these packets or making them disappear - the Internet doesn't know where they should go, and, since there is no default route, the packets are dropped at the first router that doesn't know how to route it.