Consider a list of IP addresses as provided by the X-Forwarded-For HTTP header:

10.0.0.142 , 192.168.0.10 , 212.43.234.12 , 54.23.66.43

I would like to know which is the first publicly-accessible address in that list. I can look over them easily enough, but how can I tell which are publicly-accessible? It seems to me (my untrained eye) that 10.0.0.142 is a workstation, 192.168.0.10 is an internal proxy, and 212.43.234.12 is a publicly-accessible address being forwarded through the proxy at 54.23.66.43. Is there any way to calculate this in code?

My first intuition is that addresses that start with 10. or 192. are not publicly accessible, but http://simplesniff.com reveals my home IP address to be 192.117.111.61. Is there a formula for determining which addresses are public and which are reserved private? Note that even trying to ping the server in question might not help as some servers won't respond to ping, and also there might be an address on my local network which also matched the internal address.

  • 3
    I would also point out that even if you find an address is routable, some companies abuse public address space internally. I have first-hand knowledge of a very large and well-known corporate name that is inexplicably using AFRINIC and AT&T IPv4 space on their internal corporate network instead of RFC1918 space... they proxy all HTTP traffic... and the X-Forwarded-For header from their corporate network will show public space they do not actually own. – Mike Pennington Jul 10 '13 at 13:25
  • @MikePennington first hand experience of this too, except they were using APNIC numbers. Could also cause an issue when an internal machine (especially those that find the destination to be in their subnet) tries to access one of the public servers... – emynd Jul 10 '13 at 16:56
  • @MikePennington - for a private network using puplic IPv4 addresses that are actually in use outside of the private network (ie: the internet), how would someone inside the private network reach a public site with an IP address in that same range? Wouldn't that request be routed to some computer (even perhaps their own computer) within the private network? – Kevin Fegan Jul 19 '14 at 22:12
  • Blindly trusting x-forwarded-for is a bad idea. It's trivial for any abuser to set a fake x-forwarded-for header claiming any address they want. – Peter Green Mar 28 '17 at 3:07
up vote 24 down vote accepted

RFC 1918 defines private IP address ranges. Have a look here.

From that document:

  1. Private Address Space

    The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

    10.0.0.0 - 10.255.255.255 (10/8 prefix)

    172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

    192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

  • Thank you. I find it interesting that 127.0.0.0/16 (and maybe more) are not on that list. – dotancohen Jul 10 '13 at 14:43
  • 5
    localhost is defined in tools.ietf.org/html/rfc6761 – Darryl Braaten Jul 10 '13 at 15:11
  • 4
    @dotancohen: The loopback block is a /8, not a /16 and is not on that list because it's not private address space. – Blrfl Jul 10 '13 at 19:35
  • @Blrfl: Thank you, I wasn't sure how wide the loopback block is. I'm actually not looking to identify private addresses but rather non-public addresses (a subset of which is private). Other than the RFC 1918 / 6890 addresses and the 127.0.0.0/8 space, are there other obviously non-public addresses that one might come across? – dotancohen Jul 11 '13 at 4:59
  • 1
    en.wikipedia.org/wiki/… 240.0.0.0 - 254.255.255.254 (240.0.0.0/4 and 255.0.0.0/8) – David Houde Jul 11 '13 at 7:49

Besides the original RFC 1918 space (which is now updated to RFC6890), there are several other blocks such as 192.0.2.0 that are not announced publicly. Furthermore, it's possible that someone has valid IPv4 space that just isn't announced in the public internet.

The simplest thing to do is telnet route-views.oregon-ix.net, login as rviews and look for yourself... for instance, this is some "192" space that's announced by AS7018 (AT&T)...

route-views>sh ip route 192.199.1.0
Routing entry for 192.199.1.0/24
  Known via "bgp 6447", distance 20, metric 0
  Tag 7018, type external
  Last update from 12.0.1.63 3w1d ago
  Routing Descriptor Blocks:
  * 12.0.1.63, from 12.0.1.63, 3w1d ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 7018

route-views>

On the other hand, you'll see that 192.0.2.0/24 (ref RFC6890) is nowhere to be found...

route-views>sh ip route 192.0.2.0 255.255.255.0
% Subnet not in table
route-views>

Nor is 169.254.0.0/16 (or longer)...

route-views>sh ip route 169.254.0.0 255.255.0.0 longer
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 128.223.51.1 to network 0.0.0.0

route-views>
  • 1
    RFC 1918 has not been updated by(or to) RFC 6890. RFC 6890 simply "reiterates the assignment of the IPv4 address block (192.0.0.0/24) to IANA. It also instructs IANA to restructure its IPv4 and IPv6 Special-Purpose Address Registries." It does not update the IPv4 Special-Purpose Address Registry Entries for Private-Use and the IPv4 address block 192.0.0.0/24 is categorized as "IETF Protocol Assignments." – one.time Sep 24 '13 at 1:21
  • 2
    @one.time, RFC 6890 contains a superset of the address space reserved in RFC 1918. I have no idea why you are talking about 192.0.0.0/24; perhaps you should re-read my answer more closely :-) – Mike Pennington Sep 24 '13 at 1:33
  • the IPv4 block 192.0.0.0/24 is of the main talking points of RFC 6890 so I made reference to it for good measure and comparison to RFC 1918. "Besides the original RFC 1918 space (which is now updated to RFC6890)" is what sparked my curiosity when reading your post. Aside from an update to special-purpose address registry entries for IPv4 and IPv6 for the inclusion of 192.0.0.0.24, RFC 6890 is not an update to RFC 1918. I just wanted to provide an observation regarding the accuracy of the statement. HTHs ;-) – one.time Sep 24 '13 at 1:54
  • 5
    @one.time, pedantically RFC 6890 is not an update to RFC 1918. Functionally, one should use RFC 6890 instead of RFC 1918 when considering IP space that is valid in a public BGP table... – Mike Pennington Sep 24 '13 at 1:56

Team Cymru provides a bogon reference for both IPv4 and IPv6 that you can use to filter out unassigned/reserved/private IP addresses - it's offered both as a simple list for well-known prefixes and also in a much larger list that includes space that is as-yet unassigned by RIRs.

They also run a BGP bogon server that you can request a free peering to - invaluable if you're unable to run a default-free zone to the internet.

  • 2
    Frankly 'unassigned' is something that is useless to filter, filtering it causes lot more problems than it solves. And actual bogons are easy, as they are very stable/static. – ytti Jul 10 '13 at 13:38
  • 2
    OK, then don't use that one, As I said, they offer a variety of flavours. – Olipro Jul 10 '13 at 13:54

There are a number of ranges that are reserved for various use cases. IANA has the authoritative and comprehensive list. It includes RFC1918, RFC6761 as well as more recent reservations like the 100.64/10 CGN block. If you find any addresses in there they are likely somehow used in a private network and should be discarded in favour of the others in search of the first public address.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.