If you're going to add a unique salt every operation you just destroyed the value of that IP address for tracking purposes. Which was the whole point of the discussion to begin with. By your scheme you might as well store a random number. So, either you store the IP in such a way that you can later re-associate a new call with the previous IP or you might as well not have it.

> However at that point surely you just add a salt?

How would that work? You'd have to use the same salt for every IP (which completely negates any benefit of the salt), otherwise how do you know that bcrypt(salt_1, IP_1), which you stored in your database yesterday, refers to the same IP as bcrypt(salt_2, IP_1) that you stored a month ago?

It's enumeration through 32 bits of 0-4294967295. There are only so much IPv4 addresses.

If you add a salt, then that "net location ID" becomes of very limited use. You won't be able to grep through the logs for request from specific IP, you won't be able to tell how many distinct IPs are accessing your services, etc etc. The only use I can see is keeping it in the session to check if IP address had changed, as a security measure.