Back to Articles

Mapping the Invisible: How IPv4Explorer Turns 4.3 Billion IP Addresses Into a Navigable Map

[ View on GitHub ]

Mapping the Invisible: How IPv4Explorer Turns 4.3 Billion IP Addresses Into a Navigable Map

Hook

Every device on the internet lives somewhere in a 4.3-billion-address grid, yet most developers have never seen what that space actually looks like. IPv4Explorer maps it like Google Maps charts the Earth.

Context

Understanding IPv4 allocation has traditionally required either memorizing CIDR notation or querying WHOIS databases—both abstract, text-based approaches that make pattern recognition nearly impossible. When you need to visualize who owns what in the IPv4 space, your options are limited: static infographics like xkcd's famous Hilbert curve map, or dense tables from Regional Internet Registries. Neither approach lets you explore dynamically.

The problem becomes acute when you're investigating network incidents, planning IP allocation strategies, or teaching network fundamentals. How do you explain that 17.0.0.0/8 belongs to Apple when students can't grasp the scale of a /8 block? How do you quickly identify which ISP controls a suspicious IP range during a security investigation? IPv4Explorer solves this by treating the 32-bit address space as a two-dimensional coordinate system, rendering it through familiar map-browsing paradigms.

Technical Insight

The core innovation in IPv4Explorer is its space-filling curve algorithm that transforms a one-dimensional IPv4 address (a 32-bit integer from 0 to 4,294,967,295) into x,y coordinates on a 2D plane. While the implementation predates the developer's discovery of Hilbert curves, it achieves a similar locality-preserving property: adjacent IP addresses tend to be visually near each other, making network blocks appear as cohesive regions rather than scattered pixels.

The mapping function operates by splitting the 32-bit address into two 16-bit segments. The high 16 bits determine the coarse position, while the low 16 bits determine fine-grained placement within that region. This creates a natural hierarchy—perfect for a tile-based rendering system. At zoom level 0, you see RIR allocations (ARIN, RIPE, APNIC). Zooming in reveals national registries, then ISPs, then individual subnet allocations.

Here's a simplified version of how the coordinate transformation works:

function ipToCoordinates(ipAddress: number): { x: number; y: number } {
  // Extract high and low 16-bit components
  const high = (ipAddress >>> 16) & 0xFFFF;
  const low = ipAddress & 0xFFFF;
  
  // Apply space-filling curve transformation
  // This simplified example uses a Z-order curve (Morton encoding)
  let x = 0, y = 0;
  
  for (let i = 0; i < 16; i++) {
    const bitMask = 1 << i;
    x |= ((high & bitMask) >> i) << (i * 2);
    y |= ((low & bitMask) >> i) << (i * 2);
  }
  
  return { x, y };
}

// Example: Where does 8.8.8.8 (Google DNS) appear?
const googleDNS = (8 << 24) | (8 << 16) | (8 << 8) | 8;
const coords = ipToCoordinates(googleDNS);
// Returns coordinates in the 8.0.0.0/8 region

The tile generation system leverages this coordinate mapping to create SVG tiles on demand. When you pan to a new region, the client calculates which tile coordinates are needed (using Leaflet's tile layer system), requests them from the server, and the server generates SVG content by querying its IP allocation database. Each tile typically covers a /16 or /20 block depending on zoom level, coloring regions based on ownership data from IANA and IP2Location.

The data pipeline is equally clever. Rather than embedding a massive static database, IPv4Explorer periodically fetches IANA's delegation statistics and merges them with IP2Location's commercial database. The combined dataset is indexed by IP range using an interval tree structure, enabling fast lookups when generating tiles:

interface IPRange {
  start: number;  // First IP as 32-bit integer
  end: number;    // Last IP as 32-bit integer
  owner: string;
  country?: string;
  asn?: number;
}

class IntervalTree {
  // Simplified interval tree for IP range queries
  query(ip: number): IPRange | null {
    // Binary search to find containing range
    // Returns ownership data for tile coloring
  }
}

The TypeScript implementation provides compile-time safety for the complex bit manipulations required. Converting between dotted-decimal notation, 32-bit integers, and 2D coordinates involves numerous opportunities for off-by-one errors and integer overflow. TypeScript's strict type checking catches many of these issues during development, especially when dealing with CIDR range calculations that must handle edge cases like 0.0.0.0/0 or 255.255.255.255/32.

Perhaps the most impressive architectural decision is the use of SVG for tile rendering rather than raster images. SVG allows crisp visualization at any zoom level, enables interactive hover states showing ownership details, and keeps tile file sizes minimal since most tiles contain only a few colored rectangles representing IP blocks. The server can cache frequently accessed tiles (like those showing major cloud providers' address space) while generating obscure regions on demand.

Gotcha

The custom space-filling curve algorithm, while functional, creates a barrier to reproducibility and academic citation. If you're conducting research that references IP address visualization, you'll likely need to cite Hilbert curve implementations instead, as IPv4Explorer's mapping lacks formal mathematical documentation. This isn't merely academic—if you're building tooling that needs to interoperate with other IP visualization systems, the non-standard coordinate system means you can't simply exchange coordinates between tools.

Data freshness presents another challenge. IP2Location updates are periodic, not real-time, so newly allocated blocks may appear as "unallocated" until the next refresh cycle. During my testing, several recently announced cloud provider expansions weren't reflected in the visualization. For incident response scenarios where you're investigating a brand-new malicious IP range, you'll still need to fall back to manual WHOIS queries. The tool also lacks programmatic API access—it's purely a visual interface, so you can't integrate it into automated monitoring workflows or scripts that need to process IP ownership data in bulk.

Verdict

Use if: You're teaching network fundamentals and need an intuitive way to demonstrate IP allocation concepts, conducting security research that benefits from visual pattern recognition across address ranges, or you're a network administrator who needs to quickly understand regional IP ownership during incident triage. The Google Maps-style interface makes it accessible to stakeholders who don't speak CIDR fluently. Skip if: You need programmatic API access for automation, require real-time allocation data for security monitoring, need Hilbert curve-specific visualizations for academic work, or you're working in environments where third-party data dependencies (IP2Location) create licensing or compliance issues. For production network management, combine this with RIPE Stat or Shodan for comprehensive coverage.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/developer-tools/davidbullado-ipv4explorer.svg)](https://starlog.is/api/badge-click/developer-tools/davidbullado-ipv4explorer)