In an IP packet, what does the source address field actually prove about the sender?

## The field is an input, not a fact Every IP packet carries two addresses in its header: a destination and a source. It is tempting to read them as symmetric — as if both were established by the network — but they are not. The destination is used; the source is merely carried. When a host builds a packet, it fills in both fields itself. On an ordinary machine the operating system's networking stack fills the source in with the address of the interface the packet is leaving from, because that is what a program that wants an answer needs. That behaviour is a convenience of the stack, not a rule of the protocol. Software that constructs packets directly can put any 32-bit value there (or any 128-bit value, for IPv6), and the resulting packet is perfectly well-formed. Nothing in the header binds the source field to anything else in the packet, and nothing signs it. ## Why nobody on the path checks it A router's job is to move a packet closer to its destination. It looks up the destination address in its forwarding table, picks an outgoing interface, decrements the time-to-live and sends it on. The source address plays no part in that decision. A router that wanted to validate the source would have to answer a question it usually cannot: *is this address one that could legitimately have come from the direction this packet arrived from?* In the middle of the internet that question has no reliable answer, because traffic is routinely asymmetric — the path a packet takes towards you is often not the reverse of the path your answer takes back. There is exactly one place where the question is easy: the edge port where a customer connects to its provider. There, the provider knows which address ranges it assigned to that customer, so anything else leaving that port is forged. That is why source validation is understood as the originating network's job — and why, when the originating network declines to do it, no one downstream can make up the difference. ## The asymmetry that constrains the attacker The destination address is self-enforcing: put a wrong one in and the packet simply does not arrive where you wanted. The source address is the opposite: put a wrong one in and the packet still arrives, and the only consequence is that any answer is delivered somewhere else — to the real owner of the address you claimed, who did not ask for it and will usually discard it or reject it. So the honest statement of what the field proves is narrow: *some device somewhere emitted a packet containing this value.* It does not prove the packet came from that host, from that network, from that country, or from a machine anyone controls. It does not prove a person was involved. It is the single most commonly over-read field in networking. ## What the field is still good for This does not make the source address useless. It is what makes a two-way conversation possible at all, and once a connection-oriented exchange is underway — where each side has had to receive something the other sent — the address at the far end has been implicitly confirmed as reachable by the party you are talking to. That is a much weaker property than identity, but it is not nothing. It is also perfectly reasonable to use source addresses to *reduce exposure*, as long as nobody calls that authentication. ## Common misreadings The first is assuming that forging requires special access or skill. It requires only a network that will forward the packet; the technique itself is decades old and published. The second is assuming that obviously-wrong sources, such as private ranges arriving from the public internet, cannot reach you — many networks do drop those, but that is an applied policy, not a property of IP. The third, and the one that costs real money, is treating a matching source address as evidence that a request came from a trusted system.