BGP and RIR IP Allocations: Why Proxy IP Origin Matters

Most proxy buyers treat "where is this IP" as one question. It is four, each answered by a different system, and they routinely contradict each other.

An address can be allocated to a company registered in London, sub-assigned to a reseller in Cyprus, announced from a Frankfurt point of presence, and geolocated to Amsterdam by one vendor and Frankfurt by another. Nothing here is broken. These are four separate assertions made by four separate parties, and only one of them, the geolocation database, is the one your scraping target reads.

Get comfortable with that hierarchy and most proxy mysteries stop being mysteries.

Address space flows down a chain defined by RFC 7020, the Internet Numbers Registry System. IANA sits at the top and holds the IPv4 address space registry, which records which /8 went to which Regional Internet Registry. Each RIR then allocates to Local Internet Registries, usually ISPs and hosting companies, which assign smaller ranges to their own customers.

Two words get used loosely and mean different things in the databases:

• Allocation is space given to an LIR so it can distribute it further. RIPE marks these ALLOCATED PA.
• Assignment is space handed to an end user for their own network. RIPE marks these ASSIGNED PA or ASSIGNED PI, and ARIN uses reallocation and reassignment on its network objects.

The status field is one of the most useful things on the record. An ASSIGNED PA block whose holder is a hosting company tells you a server network, not a consumer broadband network, no matter what the sales page said.

The other thing to internalize is that free IPv4 ran out a long time ago. IANA's central pool was exhausted on 3 February 2011. ARIN hit zero on 24 September 2015. The RIPE NCC issued its last addresses from the final /8 on 25 November 2019 and has run a waiting list since. Since then almost no new IPv4 gets allocated. It gets transferred and leased, which is exactly why so much proxy space has a registry record that no longer matches who operates it. When you audit a proxy IP, you are usually looking at a block that has changed hands at least once.

Five registries divide the planet. Each publishes the same core data through two interfaces: legacy whois on port 43, and RDAP over HTTPS with structured JSON.

A network record carries roughly this set of fields, with naming differences per registry:

The country field is administrative, not geographic

This trips up nearly everyone. The RIPE NCC states plainly in its database documentation that the country: attribute on an inetnum is not a reliable indicator of where the network is used. It describes the resource holder's registered country. A UK company can hold a block it deploys entirely in Singapore, and the record will still read country: GB. Treat it as a legal fact about a company, never as a location for the addresses.

RDAP replaced whois as the standard interface. The query format is defined in RFC 9082 and the JSON response format in RFC 9083, both published June 2021. You do not need to know which registry holds a block first: IANA publishes a bootstrap file mapping ranges to RDAP servers at data.iana.org/rdap/ipv4.json, and the community redirector at rdap.org follows it for you.

# Bootstrap-aware lookup, works for any IP in any region
curl -s "https://rdap.org/ip/104.16.0.1" | jq '{handle, name, country, type, startAddress, endAddress}'

# Straight to a specific registry when you already know the region
curl -s "https://rdap.arin.net/registry/ip/23.20.0.1" | jq '.name, .type, .cidr0_cidrs'

Pull the accountable parties and the abuse contact out of the entities array:

curl -s "https://rdap.org/ip/45.77.0.1" | jq -r '.entities[]?.roles | join(",")'
curl -s "https://rdap.org/ip/45.77.0.1" | grep -Eio '[a-z0-9._-]+@[a-z0-9.-]+' | sort -u

Legacy whois still works and is sometimes faster to eyeball:

whois -h whois.ripe.net 185.199.108.153 | grep -Ei '^(inetnum|netname|org|country|status|descr|geofeed)'

Here is what a site owner learns about your proxy from that one query, in about 200 milliseconds: the legal holder, the block size, the allocation status, the abuse contact domain, when the record last changed, and any remark naming a reseller. If the abuse address ends in a hosting company's domain and the netname reads VPS-POOL-3, no amount of browser fingerprint patching changes what the record says. Registry data is the cheapest, most stable classification signal a defender has, which is why it feeds directly into how sites score IP reputation.

Individual IPv4 addresses are too numerous and too fluid to track one by one. Reputation systems therefore key on the units that persist: the announcing Autonomous System and the prefix it announces. Spamhaus publishes ASN-DROP at the AS level. Cloudflare firewall rules match ip.geoip.asnum directly. Commercial usage-type feeds label whole ASNs as hosting, ISP, or mobile.

The practical consequence is shared fate. If your proxy sits in a /24 and forty of the other 254 addresses ran a credential-stuffing campaign last month, your address inherits the smell. The RIR record is what tells you how big that blast radius is: a /22 held by an IP broker means 1,024 addresses of shared history, most of which you cannot see. That mechanism is the whole reason subnet diversity is worth paying for, and it is why the datacenter ASN behind a pool predicts block rates better than any single IP's history does.

Registry layer, routing layer, reputation layer. The ASN is where the middle two meet.

The Border Gateway Protocol, specified in RFC 4271, is how networks tell each other which prefixes they can reach. An AS originates a prefix by announcing it to its peers and upstreams, those neighbors propagate it, and every router on the internet ends up with a path back. Two properties of that system matter enormously for proxies.

A prefix lives wherever its announcing routers are. Nothing in BGP references the registry. An operator can take a block allocated through RIPE to a UK entity, plug it into a router in Frankfurt, and announce it there. Packets for that block now terminate in Germany. The RIPE record still says GB. Both statements are true, and only one of them describes where your traffic exits.

The same prefix can be announced from many places at once. Anycast and multi-site deployments announce identical space from Ashburn, Frankfurt and Singapore simultaneously, and the closest announcement wins per client. A more specific announcement also beats a less specific one, so a /24 carved out of a /20 pulls traffic away from the parent regardless of who holds the parent.

Check both facts against RIPEstat's public data API:

# Which AS originates the prefix covering this IP, and which prefix is it?
curl -s "https://stat.ripe.net/data/routing-status/data.json?resource=185.199.108.153" | jq '.data.resource, .data.origins, .data.visibility'

# Everything the routing table knows about an AS, including announced prefixes
curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS36459" | jq '.data.prefixes[0:10][].prefix'

For a browser view, bgp.tools and bgp.he.net both show the origin AS, the upstreams, and the peer geography, which is a decent proxy for where a prefix is physically announced. Compare the upstream transit providers to the country the seller claims. A block advertised as Brazilian residential whose only upstreams are two European transit networks is not exiting in Brazil.

This is the single most common support ticket in the proxy business, and it has five causes. They stack.

1. The prefix is announced from a different country than the registry names. Registry says GB because the holding company is British. The router is in Frankfurt. This is the root cause in most cases.
2. Latency triangulation puts it where the packets terminate. Commercial geolocation vendors run measurement probes and infer position from round-trip times. If your exit node answers in 2 ms from a Frankfurt datacenter and 18 ms from London, every probe agrees it is German. The registry never enters the calculation.
3. The registry record is stale after a transfer. Post-exhaustion transfers move blocks between organizations and sometimes between RIR regions. Databases that cached the old holder can lag by weeks, so one vendor reports the old country and another the new one.
4. No geofeed exists, so vendors guess. When the operator publishes nothing, databases fall back on inference, and inference disagrees.
5. Reverse DNS leaks a city and gets parsed. PTR records like fra-03.pool.example.net are mined for airport and city codes. A hostname containing fra, ams or lhr pulls a vendor's guess toward that city even when the routing says otherwise.

If country accuracy matters to your job, and it does for pricing, retail and geo-targeted collection, you cannot rely on a seller's country label. You have to observe what a real destination reports through the proxy itself.

Here is the layer almost nobody checks, and it is the fastest way to separate a serious network operator from a reseller.

RFC 8805, published August 2020, defines a self-published IP geolocation feed: a plain CSV served over HTTPS where the operator states, per prefix, the country, region and city where that space is actually deployed. RFC 9092, July 2021, defines how to find that file, by putting a geofeed: attribute (or a remarks: Geofeed https://... line) directly in the RIR inetnum object, and how to validate it with an RPKI-signed detached signature.

A geofeed line looks like this:

203.0.113.0/24,GB,GB-LND,London,
198.51.100.0/25,DE,DE-HE,Frankfurt am Main,

The country and region codes are ISO 3166-1 alpha-2 and ISO 3166-2. Major geolocation vendors ingest these feeds, which means the operator effectively declares the location that ends up in the databases your targets query.

Find one straight from the registry record:

# The geofeed URL, if the holder published it
whois -h whois.ripe.net 203.0.113.10 | grep -iE 'geofeed'

# Then read the feed and pull the line covering your prefix
curl -s "https://example-operator.net/geofeed.csv" | grep '^203.0.113.'

Use this as a buying test. Ask a provider for the geofeed URL covering the ranges they are selling you. An operator running its own allocations will send a link within minutes. A reseller who does not control the inetnum object cannot publish one at all, which tells you their country labels are inherited from someone else's registry field and are not maintained by anyone you can call.

Announcing a prefix in BGP does not prove you are entitled to it. Two systems exist to attach authorization to routing, one old and weak, one modern and cryptographic.

Internet Routing Registries hold route and route6 objects that pair a prefix with the AS permitted to originate it. RADB, ALTDB, NTTCOM and the RIR-operated IRRs are the common databases, and transit providers build prefix filters from them. The weakness is authentication: in several non-RIR IRRs, objects can be created with little proof of holdership, and stale objects from a decade ago are common.

RPKI fixes the authorization problem properly. The architecture is specified in RFC 6480, published February 2012. Each RIR issues resource certificates to its members, and a member signs a Route Origin Authorization stating that a given AS may originate a given prefix, up to a stated maximum length. Relying-party validators such as Routinator and rpki-client turn those ROAs into a validated cache that routers consume. RFC 6811 then defines the three outcomes for any announcement:

Check any pair in one call:

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS15169&prefix=8.8.8.0/24" | jq '.data.status, .data.validating_roas'

Why this belongs in a proxy audit: an Invalid state on a block you are about to rent means large transit networks that enforce origin validation may already be discarding the route, so those addresses are unreachable from parts of the internet you cannot test from your laptop. A NotFound state combined with an origin AS that has no visible relationship to the RDAP holder is the classic fingerprint of loosely brokered space. It works today, and it can vanish the moment a filter tightens or the real holder objects. Neither state is automatically disqualifying. Both are worth pricing in.

The registry and the geolocation vendor answer different questions, with different methods, on different clocks.

No vendor sees the whole picture, so disagreement is the normal state rather than a bug. The rule that follows is simple. Use the registry to learn who controls an address and how much shared history it carries. Use BGP to learn where it is announced from. Use the geofeed when one exists. Then use a live request through the proxy to learn what your specific target believes, because that is the only opinion that decides whether you get served or blacklisted.

Run this before you commit to a pool. Take three or four sample IPs from a trial, not one, because a pool's worst subnet is what determines your block rate.

Step 1. Identify the holder.

IP=185.199.108.153
curl -s "https://rdap.org/ip/$IP" | jq '{name, country, type, startAddress, endAddress, remarks}'

Look at name and type. A hosting-sounding netname plus an ASSIGNED PA status on a hosting org means datacenter space regardless of the product label.

Step 2. Find the announced prefix and origin AS.

curl -s "https://stat.ripe.net/data/routing-status/data.json?resource=$IP" | jq '.data.origins[].origin, .data.first_seen'

Note the prefix length. A /24 shares your fate with 254 neighbors, a /20 with roughly 4,094.

Step 3. Check RPKI origin validation. Feed the AS and prefix from step 2 into the rpki-validation call shown earlier. Flag anything Invalid.

Step 4. Hunt for a geofeed. Grep the whois output for geofeed. If one exists, read the line covering your prefix and compare the city to what the seller promised.

Step 5. Ask a real destination what it sees, through the proxy. This is the only step that reflects your actual working conditions. With the SparkProxy Scraping API, pin the exit country and fetch a lookup endpoint in one call:

curl -G "https://scrape.sparkproxy.io/api/v1" \
  -H "X-API-Key: sk-YOUR_API_KEY" \
  --data-urlencode "url=https://ipinfo.io/json" \
  --data-urlencode "render_js=false" \
  --data-urlencode "premium_proxy=true" \
  --data-urlencode "country_code=GB"

premium_proxy=true routes through the residential pool instead of datacenter ranges, and country_code takes an ISO 3166-1 alpha-2 code such as US, GB or DE. Loop it in Python to sample what the exit reports across several countries:

import requests

API = "https://scrape.sparkproxy.io/api/v1"
HEADERS = {"X-API-Key": "sk-YOUR_API_KEY"}

for cc in ("GB", "DE", "US", "JP"):
    r = requests.get(
        API,
        headers=HEADERS,
        params={
            "url": "https://ipinfo.io/json",
            "render_js": "false",     # plain HTTP fetch, 1 credit
            "premium_proxy": "true",  # residential exit
            "country_code": cc,       # ISO 3166-1 alpha-2
        },
        timeout=60,
    )
    seen = r.json()
    print(cc, "->", seen.get("country"), seen.get("city"), seen.get("org"))

If you ask for GB and the destination reports DE, you have just reproduced the mismatch from section seven, and steps 1 through 4 tell you which of the five causes produced it.

Step 6. Decide. A pool where the RDAP holder, the announcing AS, the geofeed and the live observation all agree is a pool whose country claims will survive contact with a real target. Anything less, and you should be paying less for it.

Sales pages describe pools in marketing terms. Registries and routing tables describe them in verifiable ones. Ask a prospective provider four things and check each yourself: which ASNs the exits announce from, what the RDAP status and holder are on a sample of the ranges, whether a geofeed covers the ranges sold as country-targeted, and what a neutral endpoint reports through the proxy for each country you need.

SparkProxy runs its own datacenter and ISP ranges alongside a residential pool, and the Scraping API's country_code parameter resolves to exits we can point at rather than a registry field we inherited. That is the distinction worth testing, whoever you buy from.