This hub covers the addressing and routing layer — the numbers and identifiers that move packets across the internet. For VPN detection, WebRTC and DNS leaks, and browser fingerprinting, see the Privacy & Detection hub. For SSL, HTTP headers, HSTS, CSP, and exposed-service scanning, see the Web Security hub. What follows is the IP, ASN, subnet, port, and hardware-identifier toolkit.
All IP & network tools
The tools in this hub cover addressing, routing, subnets, ports, hardware identifiers, latency, reverse DNS, IP reputation, and IOC enrichment.
Understanding IP addresses
An IP address is a numerical label that routes packets across the internet. The familiar IPv4 form (8.8.8.8) is 32 bits, allowing roughly 4.3 billion unique addresses — and the public pool ran out around 2011. IPv6 (2001:db8::1) is 128 bits and effectively unlimited; it's now the default on most modern networks, though IPv4 remains the lowest-common-denominator.
Three IPv4 ranges are reserved for private use by RFC 1918: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. These addresses exist on every local network in the world (your router, your office, every coffee shop) and never appear on the public internet. Your router translates between your private LAN address and the public IP your ISP assigned to your connection — a process called NAT. The address websites see is the router's, not your laptop's. That's why a household with a dozen devices appears to the outside world as a single IP.
Public IPs are either static (permanently assigned, common for servers and business connections) or dynamic (assigned from a pool, common for residential). Dynamic addresses can change at any time — sometimes on every router reboot, sometimes once a quarter, depending on the ISP. Mobile carriers rotate even faster because devices roam between cell towers.
The IPv4-to-IPv6 transition is the slow-motion backdrop to all of this. IPv4 exhaustion didn't break the internet because of two stopgaps: NAT (many devices sharing one public address) and a secondary market where IPv4 blocks now trade for ~$30-50 per address. IPv6 removes the scarcity entirely, but adoption is uneven — some networks are IPv6-first, many are dual-stack, and a stubborn long tail remains IPv4-only. Practically, that means any tool that touches addresses has to handle both families gracefully, and any investigation should check whether a host has an AAAA record hiding a separate, often less-monitored, IPv6 attack surface.
How geolocation actually works
Geolocation databases (MaxMind GeoLite2 is the de facto standard) map IP ranges to physical locations using a combination of registry data, BGP routing announcements, and probe networks that triangulate real-world latency to known endpoints. The result is good — country-level accuracy is essentially 99%, and city-level lands within 50 km about 65-75% of the time for residential IPs. Anything more precise (a street, a neighbourhood) is almost always wrong.
Datacenter IPs are a different story: they appear in the geo database at the hosting provider's registered location, which has no relationship to the physical user. An AWS server in São Paulo geolocates to Seattle if the IP block is registered to AWS US-East. That's a feature, not a bug — those IPs aren't tied to a human user.
A typical IP lookup returns country, region, city, coordinates (lat/lon), timezone, ISP, and ASN. For bulk investigation, the Bulk IP Lookup takes up to 100 addresses at once and exports to CSV/JSON. Both tools also surface reverse DNS (PTR records), which map an IP back to the hostname the operator assigned to it — useful for verifying that a sending mail server identifies itself consistently in DNS.
Geo databases also flag connection type: residential ISP, mobile carrier, business broadband, hosting/datacenter, or government/education. The flag is heuristic — derived from the ASN and the registry data — but reasonably accurate at the broad category level. For fraud and abuse work, "this is a residential cable IP" vs "this is an AWS server" is often the single most important field on the response.
Autonomous Systems and ASNs
The internet is a network of networks. Each independent network — Comcast, Cloudflare, your university, every cloud provider — is an Autonomous System identified by a numeric ASN. The AS owns a set of IP ranges and announces routes to neighbouring ASes via the Border Gateway Protocol (BGP). When a packet leaves your laptop bound for a remote server, every hop along the path is a routing decision between ASes.
ASNs were originally 16-bit (1-65535) but the space was exhausted, so 32-bit ASNs (up to ~4.3 billion) became standard around 2007. Most modern allocations use the 4-byte form; older networks still hold 2-byte numbers. The full registry is maintained by the regional internet registries (ARIN, RIPE, APNIC, LACNIC, AFRINIC).
An ASN lookup tells you the organisation, country of registration, total prefix count, and the actual IP ranges announced. It's the right level of abstraction when you're investigating whether an attack came from a single hosting provider, whether a customer's network announces consistent blocks, or how a CDN's footprint compares to its competitors'. Notable ones worth knowing: AS13335 Cloudflare, AS15169 Google, AS16509 Amazon, AS8075 Microsoft, AS32934 Meta. Look up any AS with the ASN Explorer.
BGP is the part that makes this fragile. There's no central authority that validates an AS's right to announce a particular prefix — the system runs on trust, with periodic well-known incidents where an AS accidentally (or intentionally) announces routes for blocks it doesn't own, briefly black-holing or intercepting traffic for entire services. RPKI (Resource Public Key Infrastructure) is the cryptographic fix, letting networks cryptographically attest which AS is allowed to originate which prefix; it's now deployed across most of the internet's backbone but still patchy at the edges. Most ASN-level investigation never needs to touch BGP directly, but knowing the routing layer is trust-based explains a lot of otherwise-baffling traffic patterns.
CIDR and subnetting
IP addresses are allocated and routed in blocks, and the notation for a block is CIDR — Classless Inter-Domain Routing. A CIDR like 192.168.0.0/24 means "the first 24 bits are the network, the remaining 8 identify hosts," which works out to 256 addresses (254 usable, after the network and broadcast addresses). The smaller the slash number, the larger the block: a /16 is 65,536 addresses, a /8 is over 16 million, and a /32 is a single host.
Subnetting is the daily maths of network engineering — carving a larger allocation into smaller segments for separate teams, environments, or security zones, each with its own firewall posture. VLSM (Variable Length Subnet Masking) lets you size each subnet to its actual need rather than splitting evenly, which conserves address space. IPv6 changes the feel of this (a single /64 holds more addresses than the entire IPv4 internet) but the notation and the network/host split work the same way.
The CIDR Calculator expands any prefix into its network address, broadcast address, first and last usable host, and total count, for both IPv4 and IPv6, plus VLSM support and a prefix-length cheat sheet. It's the fastest way to answer "how many hosts does a /26 hold?" or "what's the broadcast address of this block?" without doing binary in your head.
Ports and services
An IP address gets a packet to a host; a port number gets it to the right service on that host. Ports run 0–65535 and split into three ranges: system/well-known ports (0–1023, assigned to standard services and requiring elevated privileges to bind), registered ports (1024–49151, assigned to specific applications), and dynamic/ephemeral ports (49152–65535, used by the OS for the client side of outbound connections).
Knowing what runs on a port is half of reading any firewall rule, connection log, or packet capture. 80 and 443 are HTTP and HTTPS; 22 is SSH; 25, 465, and 587 are the mail-submission ports; 53 is DNS; 3306, 5432, and 27017 are MySQL, Postgres, and MongoDB. The Port Lookup covers the full IANA registry plus enriched detail on the common ones — assigned service, transport protocol, security notes, and related ports — so you can decode an unfamiliar port number or check what should (and shouldn't) be exposed.
MAC addresses and hardware vendors
Below IP, at the local-network layer, every network interface has a MAC address — a 48-bit hardware identifier burned in at manufacture (and often randomised by modern devices for privacy). The first 24 bits are the OUI (Organisationally Unique Identifier), assigned by the IEEE to the manufacturer of the interface. That means the OUI reveals who made the network card in any device whose MAC you can see — on your LAN, in a DHCP lease table, or in a packet capture.
The MAC Address Lookup resolves any MAC or OUI prefix to its manufacturer using the full IEEE registry — 39,000+ vendors, refreshed regularly. It's the tool you reach for when an unfamiliar device shows up on your network and you want to know whether it's a printer, a phone, a smart-home gadget, or something that shouldn't be there. Note the caveat: phones and laptops increasingly use randomised MACs per network to defeat tracking, so a randomised address won't resolve to a real vendor — which is itself a useful signal.
Measuring response time
The last piece of the network toolkit is latency. Cloudflare Workers can't send ICMP, so traditional ping is out — but HTTP-layer response time is actually a better signal for web services anyway, because it captures the full DNS + TCP + TLS + server-processing path that real page loads go through. The Response Time Checker sends sequential HTTP probes to any host and reports min / max / average / median latency, jitter, and packet loss, along with which Cloudflare colo handled the request so you know where the measurement originated.
It's the right tool for "is this host up and how fast does it respond from here?" and for comparing latency across runs to spot instability. A low average with high jitter points to a congested or overloaded path; consistent high latency points to physical distance or a missing CDN edge in your region.
Related hubs
This hub used to cover privacy and web-security tools too; they now live in dedicated clusters. Looking for VPN detection, WebRTC/DNS leak testing, or browser fingerprinting? See the Privacy & Detection hub. For SSL/TLS inspection, HTTP security headers, HSTS, CSP, or open-port and CVE scanning? See the Web Security hub. For DNS records, propagation, DNSSEC, and WHOIS, see DNS & Domains; for SPF/DKIM/DMARC and the rest of the mail stack, see Email Security.
Common troubleshooting scenarios
"What is my IP address?"
Open the IP Lookup and submit no input — it returns your apparent public IP plus the geo and ASN. If it shows a different address than your device's network settings, that's expected: your router is doing NAT, and the address you see in the OS is a private RFC 1918 range that never leaves the LAN.
"Who owns this IP, and what else do they run?"
Start with the IP Lookup for the ISP and ASN, then pivot through the ASN Explorer to see every prefix that operator announces. This is the standard move when triaging an abusive IP from your logs — one address is a data point, the AS footprint is the context that tells you whether it's a residential ISP, a cloud provider, or a bulletproof host.
"How many hosts fit in this subnet?"
Paste the CIDR into the CIDR Calculator. It returns usable host count, the network and broadcast addresses, and the full range — the answer to subnet-sizing questions without binary arithmetic. For variable-size segments within one allocation, the VLSM mode sizes each subnet to its need.
Learn more
The deep-dive posts below cover the addressing and routing concepts in detail.