One way hashed (that can't be rainbow tabled) are not however PII afaik however, so it's quite easy to turn an IP address into a "net location ID" or something similar that can't be tracked back to a physical IP for analytics.
No need for rainbow tables, the search space is small enough to brute force.
Given a GPU farm however I'm sure it might be feasible. However at that point surely you just add a salt?
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.
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?