What information should come with an IP address?¶
title: "What information should come with an IP address?" card_id: "IP-021" status: "complete" source_document: "https://docs.google.com/document/d/1m6izMmsfeus-Xe_6K1vCJ6VcD5FVHVXQvPXsbzDdyqk/edit?usp=drivesdk"
What information should come with an IP address?¶
What information should come with an IP address?¶
An IP address on its own is often of very limited use.
If somebody sends you an address copied into an email and says, “This is the offender’s IP address,” several obvious questions remain unanswered.
Where did it come from?
What did the system record?
When did it happen?
And what does the address actually represent?
The first thing that should come with an IP address is its source.
That means identifying the platform, device, server, firewall or other system that recorded it.
You also need the original record or the closest available export from that system.
A screenshot or copied address may be useful initially, but it can remove field names, surrounding events and other details needed to interpret the address correctly.
The record should show what event occurred.
Was it a successful login?
A failed login?
An upload?
A connection attempt?
A firewall alert?
Or simply a packet arriving at a network interface?
Those events don’t all prove the same thing.
The exact date and time are also essential.
That should include the year and, where available, seconds or even greater precision.
It must also include the time zone.
A timestamp of 14:35 is ambiguous unless you know whether it means UTC, GMT, British Summer Time or another local time.
Where systems display and store time differently, you also need to understand whether the value is the original recorded time or a converted display time.
The record should preserve the field label attached to the address.
An address labelled source IP may mean something very different from one labelled destination IP, client IP, forwarded IP or server IP.
If the record contains several addresses, keep them all together with their labels. Don’t extract one address and discard the context that explains the others.
Any available connection details should also be retained.
That may include:
the source and destination ports;
the protocol used;
whether the connection succeeded, failed or was blocked;
an account or device identifier;
and any event, request or session identifier that links the record to related activity.
Not every system will record all of these fields.
Their absence doesn’t automatically make the evidence useless. But you shouldn’t discard fields simply because their importance isn’t immediately obvious.
A source port, for example, may later be essential where a public IP address was shared between several customers or connections.
The information doesn’t need to arrive as a neatly prepared report.
What matters is that the original meaning and context haven’t been lost.
The minimum useful package is normally the address, the recording system, the original record, the event, the exact time and time zone, and any available connection or session details.
That still won’t identify the person responsible.
It gives you something more basic but essential: an IP address that can be interpreted properly and used as a reliable line of enquiry.