How do you attach a PPPoE username to a NAT record?

A NAT record ends at a private address, and a private address is not a person. Sometimes the router hands you the name in the same line. Where it does not, the address has to be matched against a record of who was holding it at that exact moment, and the moment is where the work is.

Why is a NAT record on its own not enough to name a subscriber?

Because the router deals in addresses and the question is about people. The line tells you an internal address was translated. Whose address it was at that second is knowledge the router had no reason to write down.

On a network handing out addresses from a pool, the same internal address belongs to different subscribers over a week. It is issued when somebody connects, released when they drop, and given to the next connection. There is nothing permanent about it.

So an answer that stops at the private address is only half an answer. It narrows a public address shared by hundreds down to one internal address, which is real progress, and then it stops short of the thing you were asked for.

When does the username appear in the line by itself?

When the subscriber session terminates on the same router that does the translating. In that arrangement each subscriber connection is its own interface on the router, and the router prints the interface by name.

The name sits in the field that would otherwise hold a physical port. Nothing extra was configured to put it there. It appears because of where the session ends, and it costs nothing.

Change the shape of the network and it disappears. Where sessions terminate on one device and translation happens on another, the translating router only sees traffic arriving on a link, so the same field holds a link that a few hundred households arrive over.

Both lines describe the same traffic. The first can be answered without leaving the line and the second cannot, and what separates them is a design decision taken years earlier, for reasons nobody connected to record keeping at the time.

What do you match against when the name is not there?

Against any record that says which subscriber held which address between which two moments. Three fields. Where those three fields come from matters less than whether they are being kept at all.

Where the address to subscriber mapping can come from

Source	What it gives you	What to watch
The router's own session list	Who is connected right now, on which address, for how long	It describes this instant only. Read it and lose it, and last week is gone
RADIUS accounting	A start and a stop per session, with the address and the username on both	Stop records go missing when a session ends badly, leaving sessions that never closed
Fixed address per subscriber	A mapping that never changes and needs no history at all	Costs address space and upkeep, so it suits business lines rather than everybody

Most operators already produce one of these without thinking of it as evidence. The accounting is running because billing needed it, or the session list is there because support looks at it. Neither was set up with a letter from a lawyer in mind, which is why neither is usually kept.

Why is the moment harder to match than the address?

Because addresses are exact and moments are a range. The NAT record carries one instant. The session record carries a span, and the match is whether that instant falls inside that span.

Get that wrong in the obvious way and you match against whoever holds the address now. That is the single most damaging error available here, because it produces a confident answer, an actual name, a real customer, and no indication whatsoever that it is the wrong one.

Two smaller problems sit underneath. Sessions that never closed properly leave a span with no end, which will happily swallow every later record on that address unless something decides how long an unclosed session is allowed to run. And clocks have to agree. If the router stamping the NAT record and the source of the session record disagree by a minute, every match near a session boundary lands on the wrong side of it.

What does it look like when the address is reused within the hour?

This is where a careless match stops being theoretical. Take one address and one afternoon.

A NAT record timestamped 13:52 belongs to the first subscriber. A record timestamped 14:30 belongs to the second. A record timestamped 14:08 belongs to neither, because nobody held that address in those six minutes, and an answer naming somebody for that moment is wrong in a way that is difficult to walk back.

Run that same afternoon through something that matches on whoever holds the address today, and all three records come back naming the second subscriber. The output looks orderly. It is orderly. It is also, in two cases out of three, about the wrong household.

None of this is exotic. Addresses are reused within minutes on any network where connections drop, which is every network, and short reconnections are common enough that the boundary case turns up regularly rather than rarely.

Is the username the same thing as the customer?

Often, and not always, and the exceptions are the ones that end up in front of a lawyer.

A username identifies a connection, not a person. Where one household has one line and one account holder, the two are the same thing and nobody has to think about it. Plenty of connections are not shaped like that. A single account can feed a hostel, a shop with a counter and a back room, an office of forty people, or a reseller who splits it again downstream and writes none of that down.

None of that changes the technical answer. The traffic did leave through that account, and that is a fact you can stand behind. What it changes is how the answer should be worded, because a name reported as a subscriber and a name reported as the holder of the account the traffic passed through are two different statements, and only one of them is defensible.

The practical response is to keep the account type where you already hold it, in billing, and to know which of your accounts are single households before somebody asks. It is a short list on most networks and an unpleasant surprise on the rest.

What does the answer look like when it is right?

One name, with the reasoning still attached to it.

A defensible answer is not just a username. It is what the request gave you, the private address that translated into it, the second on the clock, and the session that was open on that address at that second, carrying its own start and end. Anybody reading it can follow the same steps and land in the same place.

The reason to keep all of that rather than the name alone is that the answer may be questioned, possibly a long time later, by somebody whose job is to question it. A name on its own asks to be trusted. A name with the chain still attached asks nothing.