IP Address Lookup

Every packet you send carries a return address. Without it, nothing could reply: no web page, no message, no video frame. So the address your connection uses is not a secret you leak by accident. It is the part of every exchange that makes the exchange possible, and every server you talk to sees it.

What that address tells a stranger is a different question, and a much narrower one than many people fear. It names a numbered slot in a block. The block was handed to an organisation, and a public registry records which one. That is the whole of it. The rest of this essay is about reading those three things well: the number itself, the ranges set aside for special jobs, and the registry record behind a block.

Two ways to write a number

The older form, IPv4, is defined in RFC 791 as a 32-bit field. That gives 2^32 possible values, a little under 4.3 billion, written as four decimal numbers from 0 to 255 joined by dots. Short as it is, the form has traps. Some software accepts octal, hexadecimal and short forms with fewer than four parts, so 010 can mean eight rather than ten. RFC 6943 calls this the loose syntax. A careful reader refuses a leading zero rather than guessing what the writer meant.

IPv6 addresses are 128 bits long. RFC 4291 writes them as eight groups of up to four hexadecimal digits separated by colons. Because long runs of zeros are common, one run of zero groups may be replaced by a double colon, once per address, so the loopback address is simply ::1. A third form keeps the last 32 bits in dotted decimal, which is handy when an IPv4 address rides inside an IPv6 one.

That freedom created a practical mess. The same address could be written dozens of ways, and two programs comparing text could disagree about whether two strings were the same host. RFC 5952 settled on one recommended form. Leading zeros inside a group are dropped. The double colon must shorten as much as possible, must never stand in for a single zero group, and goes on the longest run of zeros, the first one when two runs tie. Letters are lower case. So 2001:db8:0:1:1:1:1:1 stays as it is, while 2001:db8:0:0:1:0:0:1 becomes 2001:db8::1:0:0:1.

These rules sound fussy until you need to search a log. A firewall rule written one way and a log line written another will not match as text. That is why a lookup tool should show you the canonical form first, and say what it changed to get there.

Blocks, not addresses

Nobody is handed a single address on its own. Since classless routing replaced the old fixed classes, addresses are given out in blocks written as a prefix and a length, such as 198.51.100.0/25. RFC 4632 describes the scheme: the length says how many leading bits are fixed, and the bits after that are free. A /25 in IPv4 fixes 25 bits and leaves 7, so it holds 2^7, or 128 addresses.

Here is a worked example you can reproduce. Type 198.51.100.23/25 into the lookup. The network starts at 198.51.100.0 and the last address is 198.51.100.127, with a mask of 255.255.255.128. In binary, the first 25 bits are the network and the last seven are the host part. The reverse-DNS name for the single address is 23.100.51.198.in-addr.arpa: the four numbers backwards under a special domain, the convention for mapping an address back to a name. IPv6 does the same with each hexadecimal digit reversed under ip6.arpa, as RFC 3596 sets out.

Blocks nest. A registry receives a large block, passes a smaller block inside it to a network operator, and the operator may record smaller pieces still. Looking up an address therefore means finding the most specific block that contains it, and seeing the larger ones it sits inside.

Addresses that mean something else

Not every number is a public address. RFC 6890 created two registries, one for IPv4 and one for IPv6, that list every block set aside for a special purpose, and IANA keeps them current. Each row names the block, the RFC that defines it, and whether addresses in it are valid as a source or destination, whether routers forward them, and whether they are reachable across the whole internet.

The best known rows are the private ranges of RFC 1918: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Any network may use them inside, so the same private address exists in millions of homes and offices at once. Close behind is 100.64.0.0/10, the shared space of RFC 6598, which carriers use between their large address-sharing equipment and their customers. Then come loopback, link-local addresses that never cross a router, and the documentation blocks of RFC 5737, such as 198.51.100.0/24, kept for examples so that no book or manual ever points at a real machine.

Two lessons follow. First, a special-use address has no holder to look up. A private address belongs to whoever is using it at this moment, inside one network, and a registry cannot say who. Second, there is no reason to send such an address anywhere. Asking an outside server about 192.168.1.20 would only tell that server something about your own network, and the answer would be empty. A careful lookup checks the special-purpose tables on your own machine and stops there.

IPv6 has its own list. The loopback, link-local fe80::/10 and unique local fc00::/7 blocks mirror their IPv4 cousins. The prefix 2001:db8::/32, now joined by 3fff::/20, is set aside for documentation. There is also a row for IPv4-mapped addresses, which carry an ordinary IPv4 address inside an IPv6 one and are written in the mixed form ::ffff:192.0.2.1.

Who holds a block, and how RDAP shows it

Public address space is handed out through five regional internet registries. AFRINIC serves Africa. ARIN serves Canada, the United States and parts of the Caribbean. APNIC covers Asia and the Pacific, LACNIC Latin America and the Caribbean, and the RIPE NCC Europe, the Middle East and Central Asia. Each keeps a public record of the blocks it has given out and who received them.

Those records were long read through WHOIS, a plain text service with no standard structure for its questions or its answers. The Registration Data Access Protocol replaces it with ordinary web requests and structured answers. RFC 9082 fixes the question: a server base address, then ip, then the address, as in a request ending ip/198.51.100.23. The server answers with the most specific registered network that contains the address.

But which server? RFC 9224 answers that with bootstrap files that IANA publishes, one for IPv4 and one for IPv6. Each lists prefixes and the registry server for each. A client finds the longest prefix that matches the address, the same rule routers use, and asks that server. The IPv4 file lists 221 prefixes, most of them whole /8 blocks, so the first step of any lookup is a short walk through a small table. Address space does move between registries, though, so a server may answer with a pointer to another registry instead of a record.

RFC 9083 describes what comes back for an IP network: the start and end addresses, a handle, a name, a type in the registry’s own words, a two-letter country code, the handle of the parent block, a status, dated events such as registration and last change, and a list of related entities. Each entity carries roles. The registrant is the holder of the block. The abuse role, when one is published, is where reports of misbehaviour should go. Several registries add a small extension that states the block in prefix form as well, so you do not have to work it out from two end addresses.

Why an address is not a location

The country in that record deserves care. It is the country the holder gave when it registered the block. A company with an office in one country can route traffic anywhere it likes, a mobile carrier can serve a whole region from one block, and a virtual private network deliberately sends your traffic out somewhere else. The registry says who holds the numbers. It never says where a device using them is sitting.

Commercial location databases try to go further, mixing registry data with measurements and guesses. RFC 8805 calls this best-effort geolocation and notes that there is no central way for operators to tell everyone where their prefixes are really used. It defines a voluntary feed operators can publish, and even that is described as something consumers should check. Location from an address is an estimate built on top of an estimate.

None of this is a flaw in the registries. They record holders because a holder is someone you can contact. They never set out to record places.

So an honest lookup does less than many people expect, and says so. It shows your public address as the server saw it, which behind a carrier’s shared equipment or a VPN is their address rather than your device’s. It shows the canonical form, the block and its size, and the special-purpose rows that apply.

For a public address it fetches the holder’s record from the registry itself, on your request and not before. What it will not do is put a pin on a map. The data to do that well does not exist in any public record, and pretending otherwise would turn a fact about a block into a guess about a person.

That restraint is the useful part. An address is a numbered slot in a block, the block has a holder, and the holder has an abuse desk. When something on the network misbehaves, those are the three facts that let you report it to someone who can act.