An IP address alone proves nothing: the timestamp, time zone and source port that make it evidence
You write the address into the incident record, send the report, and the provider answers that it cannot tell which subscriber that was. Nothing was wrong with the address. What was missing were the fields that make an address resolvable at all: the source port, a timestamp precise enough to be matched, and an unambiguous time zone. This is log hygiene rather than investigation, and it is decided months before the incident, by whoever configured the logs.
Why the address stopped being enough
Where one public address is shared between several subscribers, the address no longer uniquely identifies a subscriber. That is RFC 6269, and it is not a marginal case: a measurement study presented in 2016, detecting carrier NAT from peer lists and network test sessions rather than from a survey, found it in 17 to 18 percent of the eyeball networks it examined and in more than 90 percent of cellular ones, with the authors calling their own detection conservative and a lower bound. Give those figures their date and treat them as an order of magnitude rather than today's share. The consequence for a report is arithmetic rather than opinion: if your server did not record the source port, and the carrier did not record destination addresses, then the provider receiving your complaint is left pointing at every subscriber who shared that external address during the period. RFC 6269 spells that out, and the case it describes is a legal request from authorities: it says that request should include the source address, the source port and the timestamp. It is Informational and uses no requirement keywords, so read that as a description rather than a rule, but the same three fields are what make an abuse report answerable. The port is doing the work the address used to do. One caution belongs here rather than at the end. An address that cannot be narrowed to one subscriber should not be acted on as though it were one: blocking it, submitting it to a blocklist or naming it in a public complaint reaches every session behind the same gateway, and RFC 6269's section on abuse logging and penalty boxes makes exactly that point, that one user failing repeated logins can lock out people who never tried at all. Report it, and keep any action you take proportionate to what you can actually attribute.
What the standards ask you to log
The relevant document is short and older than most of the systems it describes. RFC 6302, published in June 2011 as BCP 162, says it is recommended as best current practice that internet-facing servers logging incoming addresses also log the source port number, and a timestamp, itself recommended in UTC, accurate to the second and taken from a traceable source such as NTP. Two details usually get flattened. The modality is recommended throughout, not required, including for UTC, so a post that tells you the standard demands anything has not read it. And the transport protocol and destination port are asked for only in the conditional case where the application is defined to use more than one transport or more than one port, not as a blanket rule. RFC 6302 also draws its own boundaries: it declines to make recommendations about logging on carrier NAT, though it does say an ISP deploying address sharing should also deploy a corresponding logging architecture, and it puts retention policy out of scope, so it cannot be cited for how a carrier should log or for how long anything is kept. On precision, there is a good argument for going finer than the second. The M3AAWG network address translation best practices document of August 2012, still the current version as of August 2026, works the arithmetic: a value described as accurate to the second can sit up to two seconds from a reference when it was truncated, and two independently recorded second-accurate values can differ from each other by as much as four seconds, which is uncomfortable when ports are recycled quickly. The standards support the fix rather than the arithmetic: RFC 6302 asks for accuracy to the second or better, and the syslog standard says an originator should include fractional seconds where clock accuracy and performance permit.
The time zone problem
A timestamp without an unambiguous zone is a guess with a colon in it. RFC 6302's reason for preferring UTC is worth quoting to anyone who defends local time: the offset or zone information can be lost as a record passes along the reporting chain, so the safest thing to write is the thing that survives being copied into a ticket. Three practical notes. Internet timestamps under RFC 3339 are fully qualified, and since RFC 9557 in April 2024 the trailing Z carries a subtly narrower meaning, that the time in UTC is known while the offset to local time is unknown, with plus zero implying instead that UTC is the preferred reference point. That is a 2024 change and should not be read backwards into older records. Second, a syslog line conforming to the current standard is not necessarily in UTC: the format permits a numeric offset as well as Z, so conformance tells you the timestamp is well formed, not what zone it is in. Third, anything in the older BSD syslog shape carries local time with no year and no zone indicator at all, which is why a line lifted from an old stream cannot be used as evidence without knowing the emitting host's zone and year. If your platform is unsure of its own clock, the syslog standard has a structured element for saying so, carrying whether the zone is known, whether the clock is synchronised and how far it may drift. Saying so in the record is far better than being asked later.
What the other side may not have
Your record is half the correlation, and it is worth knowing how the other half can fail, so that a report asks for the right thing and an answer of "we cannot tell" is read correctly. Carrier NAT requirements pull against each other by design: the carrier-grade NAT requirements of RFC 6888, published in April 2013 as BCP 127, say a port allocation scheme should maximise port utilisation and, in the next requirement, that it should minimise log volume, and notes that a scheme satisfying one does so at the expense of the other. It also says, for privacy reasons, that a carrier NAT should not log destination addresses or ports unless required to do so for administrative reasons, and points at RFC 6302 as the reason it should not need to, which is precisely why your source port matters. Port reuse can be quick: the requirement is that a deallocated port should not be reused for at least two minutes, with listed exceptions permitting immediate reuse and the interval configurable, so treat it as a convention rather than a floor you can count on. And a per-session log may simply not exist. A 2014 Independent Submission describes deterministic address mapping, under which full deterministic allocation can eliminate the need for translation logging altogether while the operator still records the mapping variables, so the honest phrasing when a provider says it has no record is that there may be no per-session log to search rather than that tracing is impossible. Retention varies by operator and jurisdiction; that is a question to ask in the request, not a number to assume. Finally, if the address reached you through a proxy or load balancer, the header carrying the original client cannot be relied upon to be correct, and a compliant deployment may deliberately publish an obfuscated token in place of the address or the port.
Writing the record
Put the fields in the report in the order that makes it actionable: the source address, the source port, the timestamp with an explicit zone and sub-second precision if you have it, the transport, and what you observed. The machine-readable abuse report format follows the same logic: the format itself is RFC 5965 of August 2010, and the source port field arrived two years later in RFC 6692, which says it should be present whenever the source address is, unless the port number is unavailable. Then be careful about what you claim, and about what you expect back. The address identifies a network location at a moment, not a person, and the fields above only make it possible for somebody holding the other half of the mapping to resolve it. What a resolved session names is an account or a line: a household behind one router, an office, a guest network, a shared host or a VPN exit all put many devices and many people behind the single line a provider can identify. Providers also do not, as a rule, return a subscriber identity to a private reporter; they act on their own customer, and putting a name to the line is a matter for legal process in the relevant jurisdiction. That is a different question from who held the block on that date, which public records answer only in part and only as far back as each registry publishes, and from what a trace can reach at all, which stops at the provider. One last piece of hygiene: capture the network side at incident time. A lookup six months later describes the network as it is then, and if the space has moved or been re-let in the meantime, the report you file will be describing somebody who was not there.
Look the address up on the front page while the incident is fresh and keep the answer with your log lines: who holds the block and what the registry says today, which network announces it, the abuse contact it resolves to, and the tags plus which public blocklists have carried the addresses sampled inside it, which describes the neighbourhood the address sits in rather than the session in your log line. The report names its sources and the date each was fetched, which is what makes it quotable later, and the routing history is dated, so the network announcing the block on the date in your record is answerable even long afterwards, to the resolution of the observed visibility windows rather than of your timestamp.