You’re probably tired of this story by now: public IPv4 addresses are running out, lots of content is available only over IPv4, and so the service providers use NAT to give new clients (with no public IPv4 address) access to old content. It doesn’t matter which NAT variant the service provider is using, be it Carrier Grade Nat (CGN), NAT64, DS-Lite or A+P, the crucial problem is always the same: multiple users are hidden behind a single source IP address.

If you’re running a public web-based service (anything from non-hosted private blog to e-commerce solutions), you’re probably logging the HTTP requests made by the clients. Best case, you use the logs to monitor your web traffic, worst case, you can use them to help law enforcement track down the intruders ... but not if the intruders were hiding behind NAT.

What happens next depends on the legislation: Italy has outlawed NAT (a truly creative solution if I ever saw one); other legislations place the NAT translation logging burden onto the service providers, but nobody can help you if you’re not logging the source TCP port. Without that information, the service provider with perfect logging can give the law enforcement a list of hundreds of users using the IP address from your log at that particular moment in time; do you really think they’ll track them all down?

RFC 6302 nicely documents the logging requirements (just in case someone asks you who said the source TCP port should be logged).

It’s very easy to log source TCP port in Apache – just add %{remote}p to the logging format. Microsoft’s IIS is (yet again) a problem – I haven’t found any means of including the source TCP port in its log file. Any ideas (apart from moving to Apache)? Lots of people will be grateful if you document them in the comments.

On a somewhat tangential topic, you might want to listen to the Packet Pushers Show#72 – How We Are Killing the Internet with Jan Žorž explaining how A+P alleviates the need for NAT translation logging.