IP address, in practice

What it means

An IP address helps networks deliver packets. IPv4 addresses commonly appear as four decimal numbers; IPv6 addresses use longer hexadecimal notation. Addresses identify network locations or interfaces in context, rather than reliably identifying a person. One device can have several addresses, and one public address can represent many devices sharing a connection.

Security investigations use addresses to connect observations across systems, but the time and network context matter. Address assignments can change, intermediaries can forward traffic, and private addresses can repeat in different organizations. Treat an address as one useful clue alongside account, device, connection, and application evidence.

See the idea / Networks

The next hop changes. The destination stays.

Follow one IPv4 packet through a router. Its destination is the receiving interface, not the router or a verified human.

Authored two-network example: sender 192.0.2.17, receiver 198.51.100.44, one router. Routes and local links work; no address translation, tunneling, or fragmentation is shown. Addresses are reserved for documentation.

01 / 04

Address

The sender prepares a packet with source 192.0.2.17 and destination 198.51.100.44. That destination is on the other network; the router is the next hop, not the final recipient.

More about this step

The diagram separates the packet’s IP source/destination from the local next hop. This ordinary unicast example has a working route through one router between the two documented networks. The numbers are explanatory addresses, not live Internet destinations. No packet is actually sent.

Keep in mindThis illustrates one successful ordinary IPv4 route. IP does not guarantee delivery or authenticate a person. IPv6, shared addresses, translation, spoofing, and route failures need their own context.

Read the visual, step by step

Address. The sender prepares a packet with source 192.0.2.17 and destination 198.51.100.44. That destination is on the other network; the router is the next hop, not the final recipient. The diagram separates the packet’s IP source/destination from the local next hop. This ordinary unicast example has a working route through one router between the two documented networks. The numbers are explanatory addresses, not live Internet destinations. No packet is actually sent.
First hop. The packet crosses the first local network to the router. The router’s receipt appears after arrival; the receiving interface on the other network has not received it yet. The source remains 192.0.2.17 and the IP destination remains 198.51.100.44. A local link carries the packet to the selected router. Local frame addressing is separate and is not drawn; it does not replace the final IP destination.
Forward. After receipt, the router forwards toward 198.51.100.44 on the second network. The receiver shows receipt only after that hop arrives. The IP source and destination stay unchanged in this example. Forwarding uses the destination and the assumed working route. Routers can change other header fields, including time to live; this picture does not claim the entire header or local frame is unchanged. With no translation or source-route option here, the illustrated source and destination remain the original pair.
Interpret. The receiving interface has the packet. Its source address is a reported network locator, not proof of a human identity or application permission. Receipt of this packet also does not establish that a business task succeeded. The header and route tell us where this packet was sent and where it reports coming from. They contain no verified human identity. Authentication, application behavior, shared-address attribution, and reliable delivery are separate matters. The success shown is limited to receipt under the authored route assumptions.

This illustrates one successful ordinary IPv4 route. IP does not guarantee delivery or authenticate a person. IPv6, shared addresses, translation, spoofing, and route failures need their own context.

Flow references: RFC 791 - IP addressing and forwarding · RFC 5737 - documentation-only IPv4 addresses

AN ILLUSTRATIVE SCENARIO

A university sign-in investigation

A university sees many student accounts signing in from the same public address. The address belongs to a residence network whose router translates connections from many private devices to one public address. The shared address alone does not prove one person controls the accounts. An investigator checks precise timestamps and authorized network records, then compares device and authentication information. The team also asks whether a proxy inserted the logged address before treating it as the original client's location.

Put it to work

Record the full address, timestamp, time zone, and the system that observed it; note whether the record describes a client, proxy, or server.
Identify the relevant address family and network context, including private ranges, translation, proxies, and changing address assignments.
Correlate with account, device, and connection evidence before drawing conclusions or blocking an address that many legitimate users may share.

How to check your work

Check whether another analyst can reproduce the address-to-device association for the relevant time. If shared networks or missing records prevent that, keep the attribution limitation explicit in the case notes.

Connect the ideas

DNS
The lookup system that maps a name people type to an address a computer can contact.
Identity
The record an organization uses for a person, device, or workload that can be authenticated.
Log
A record emitted by a system that something happened, which may later be used as evidence.
Uncertainty
What you still do not know, written explicitly so it is not filled with false precision.

IP address