So IPs can in fact be considered to be PII (or personally identifiable information) in some cases, so you're right to want to consider whether you need to protect them. Generally this doesn't mean, however, going to any additional lengths beyond how you would protect other PII, say, email addresses for example.
In any case, traditional hashing is likely going to be an ineffective mechanism. There are only 4 billion IP v4 addresses potentially in existence, and the reality is that you're probably dealing with a far smaller address space that that. This means that it's relatively easy for an attacker with the hashes to compute the IP addresses that result in those hashes. Salting is generally not useful in this case, because you presumably want to know when two requests are associated with the same IP address, and you will not be able to easily compare an existing hashes to the hash of the IP address associated with a new request if all of the hashes are uniquely salted.
You could, potentially use a keyed hash without a salt, using a function like HMAC. This, presuming you can keep the key secure will lead to hashes that can be compared to each other, but also cannot be associated to the IP addresses that were used to create them by an attacker who has the hashes, but not the key. If the key is obtained by the attacker however, this is no more secure than traditional hashing.
Generally speaking, I'd suggest that the risk here doesn't demand the complexity of a mitigation of this level. I think the complexity you're adding (and need to maintain) probably outweighs the additional security you'd get. However, if for your application does in fact require you to consider IP addresses to be sensitive enough to warrant extraordinary protection, consider using a keyed hash function.