IP Addressing and Routing Fundamentals for Investigators

An IPv4 address is a 32-bit number written as four octets in decimal, separated by dots: for example, 203.0.113.45. The address has two logical parts: a network portion, which identifies the network, and a host portion, which identifies the device within that network. The boundary between those two parts is defined by the subnet mask.

In CIDR notation, the mask length follows a forward slash. The address 203.0.113.45/24 means the first 24 bits (the first three octets, 203.0.113) identify the network, and the remaining 8 bits identify the host. That network can hold 254 usable host addresses (256 minus the network address and the broadcast address). A /16 network holds 65,534 hosts. A /30 holds 2 usable hosts and is typical for point-to-point router links. Knowing these calculations lets an investigator read routing tables and determine whether two addresses belong to the same segment.

RFC 1918 reserves three address ranges for private use: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. These ranges are not routed on the public internet. If an IP address in an evidence log falls within one of these ranges, it identifies a position inside a local network, not a public internet endpoint. The investigator must then obtain the NAT or firewall logs from the device that connects that local network to the internet.

NAT was introduced to extend the life of the IPv4 address space. A home router or ISP gateway receives one public IP address and uses it for all outbound connections from the devices behind it. When a device sends a packet outbound, the router replaces the private source IP with the public IP and assigns a port number to track the session in its translation table. The remote server sees only the public IP and the assigned port, not the private address of the originating device.

For investigators, this creates a two-step attribution problem. Step one: identify the ISP or organisation responsible for the public IP from the server log, using an RIR WHOIS or RDAP query. Step two: serve legal process on that ISP or organisation to obtain the subscriber record for that IP at the exact time of the connection. Most ISPs can return the subscriber identity from their DHCP or session logs if the request includes the IP address, the timestamp in UTC, and the protocol and port. Incomplete timestamps, or requests in local time without timezone specification, lead to misattribution because DHCP leases cycle and the same public IP may be assigned to different subscribers over time.

Legal frameworks differ by jurisdiction. In India, Section 67C of the Information Technology Act 2000 requires intermediaries to preserve logs for a period specified by the government; the Bharatiya Nagarik Suraksha Sanhita 2023 provides the procedural basis for production orders. In the United States, 18 U.S.C. § 2703 governs compelled disclosure of subscriber records from electronic communication service providers. In the United Kingdom, the Investigatory Powers Act 2016 authorises production of communications data including subscriber identity linked to an IP address. EU member states operate under Directive 2016/680 for law enforcement access to personal data held by processors.

The five Regional Internet Registries distribute IP address blocks to ISPs and large organisations within their geographic regions. ARIN covers the Americas; RIPE NCC covers Europe, the Middle East, and Central Asia; APNIC covers Asia-Pacific; LACNIC covers Latin America and the Caribbean; AFRINIC covers Africa. Each RIR maintains a public database of its allocations, queryable via WHOIS (the legacy text protocol) or the modern RDAP (Registration Data Access Protocol) which returns structured JSON.

A WHOIS or RDAP query against an IP address returns the organisation that holds the address block, the range of the block (in CIDR notation), and administrative and technical contact information. This tells an investigator which ISP or hosting company to approach. It does not reveal the individual subscriber. For a cloud-hosted address (an AWS, Azure, or Google Cloud IP, for example), the WHOIS record names the cloud provider as the holder. The next step is the cloud provider's own abuse or law enforcement contact process, using a legal production order in the relevant jurisdiction.

ASNs provide a second lookup path. A BGP route lookup against an IP address returns the ASN advertising the route. Tools such as Team Cymru's IP-to-ASN mapping service or the RIPE NCC Routing Information Service (RIS) allow investigators to confirm which network is currently or historically advertising a given prefix. This matters when the WHOIS record shows a sub-allocation from a downstream provider: the BGP data shows the actual network carrying the traffic, which may differ from the resource holder named in the RIR database.

Routing is the process by which packets move from source to destination across a series of routers. Each router consults its routing table, selects the best matching route for the destination address, and forwards the packet to the next hop. BGP manages the advertisement of routes between autonomous systems; Interior Gateway Protocols (IGPs) such as OSPF and EIGRP manage routing within a single AS.

Traceroute (or tracert on Windows) is the primary diagnostic tool for mapping the path a packet takes. It sends probes with incrementing Time-To-Live (TTL) values, causing each router to return an ICMP Time Exceeded message as its TTL expires, which reveals the router's IP address and round-trip time. Investigators use traceroute to identify the network path between two points, confirm geographic routing, and spot anomalies such as traffic transiting a country or ISP not expected from the address geography.

Router logs and NetFlow records are the most forensically significant routing-layer artefacts. NetFlow (and its successor IPFIX) captures per-flow summaries: source IP, destination IP, protocol, ports, byte count, packet count, and start and end timestamps. These records are compact enough for ISPs to retain for months and provide a complete picture of what traffic crossed a given router at any point in time. Full packet capture (PCAP) contains the payload of every packet but is too large for long-term retention except on small monitored segments.

IPv6 addresses are 128 bits long, written as eight groups of four hexadecimal digits separated by colons: for example, 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Consecutive groups of zeros may be compressed to ::, so the above could be written 2001:db8:85a3::8a2e:370:7334. The network prefix is again expressed in CIDR notation after the address. ISPs typically assign subscribers a /48 or /56 prefix, leaving the subscriber to assign /64 prefixes to individual network segments.

IPv6 eliminates the need for NAT in most deployments, because the address space is large enough for every device to have a globally unique public address. This creates a direct mapping from address to interface, which simplifies some attribution steps. However, privacy extensions (RFC 8981) cause hosts to generate randomised interface identifiers for outbound connections. These temporary addresses rotate on a schedule of hours to days, so a server log may contain a sequence of different IPv6 source addresses from the same physical device over the course of a day.

When collecting network evidence, investigators must capture both IPv4 and IPv6 traffic. A dual-stack host (one configured with both IPv4 and IPv6) may use IPv6 for connections to sites that support it and IPv4 for others. Logs from a single session may therefore span both address families. Missing one family means missing evidence.

Attribution in network investigation is a chain of evidence, not a single lookup. Each step must be documented, each record preserved with its chain of custody, and each legal process served and returned in a form acceptable to the court in the relevant jurisdiction.

• Step 1: Extract the IP and timestamp. From the server log or victim system, record the source IP address and the exact UTC timestamp of the connection. Confirm the server clock was synchronised to NTP and document any known clock offset.
• Step 2: WHOIS or RDAP query. Query the appropriate RIR database to identify the organisation or ISP responsible for the IP block. Document the query, the time of query, and the response in full. For cloud-hosted IPs, identify the provider and their law enforcement contact path.
• Step 3: Serve legal process. Issue a production order or equivalent legal demand to the identified ISP or hosting provider. Include the IP address, the UTC timestamp, and (for CGNAT environments) the source port. Request subscriber identity, service address, and any associated device identifiers.
• Step 4: Cross-reference with device evidence. Match the subscriber record against physical access to the service address. If the connection came from a shared access point (public Wi-Fi, office network), consider whether internal NAT or DHCP logs from that location can narrow the attribution to a specific device or user.
• Step 5: Corroborate with device forensics. Network attribution alone places a connection at a location. Device forensics (browser history, cached credentials, application logs) places the suspect at the device. Both threads together form the attribution case. See Digital Forensics for the device-side techniques.

VPNs and proxy services add intermediate hops to this chain. The server log shows the VPN or proxy IP, not the subscriber's IP. The investigator must first identify the VPN provider and serve process there to obtain the subscriber's IP, then repeat the chain from that IP. Some VPN providers claim to retain no logs; whether this claim is accurate depends on the provider's jurisdiction, technical architecture, and prior history of responding to legal process. The DNS and Domain Investigation topic covers how DNS queries can sometimes expose a user's true IP even when a VPN is active.