I am retrieving the IP Address for tracking purposes, this is not something that the user neither inputs nor is it used for any other reason than to track how many times a user has been to a site.
The address is stored in a database and used to see if the client has been on the site before.
So the question is can an IP Address be used in a malicious way? Other than “spoofing”.
I can't think of a way to inject any naughty characters, but I suppose it is how you get their IP address.
It is always best to never trust your users, especially if a database is involved.
If you don't validate the data that you put into your database, you might end up with malicious data (XSS, SQL injection etc..).
Make sure that data is clean before you put it in a database, as you don't know what it will be used for tomorrow.
I would argue that you should validate the IP Address before it is stored in the database because:
The retrieval from HTTP Request and database storage won't always be close to each other in the code. So at some point in the future someone might call the database storage method using bad data. If you write the code to validate it now, you are less likely to deal with problems in the future.
Most reasons for validation do not apply; the IP will come from a Request property built from information in the underlying connection that will already have been validated to a large extent and hence while it could be spoofed, it couldn't be faked to be something that isn't actually an IP address.
However, two reasons remain. One is that the mistrust in security is not just of intent but also of success; we can trust the layer giving us the IP address to not deliberately give us something else, but we can't necessarily trust it to be successful in its own checks - maybe some day an exploit is found that tricks that layer into passing something else. The other is that depending on what you are going to do with this IP, maybe a spoofed IP could cause some damage (this requires validation beyond merely validating the IP is an IP).
A counter-argument is that if all you are doing is logging, then as long as you use normal approaches to ensuring the formatting of data, logging the malicious code won't do anything nasty in itself.
A counter-counter-argument is that if the only thing you are doing is logging today, this may not be the case later in the project's lifetime.
On balance therefore, validation is reasonable to do, though I wouldn't freak out if I saw someone not doing so.
Do take care to make sure your validation accepts IPv6 addresses; they are still rare enough that your testing might not use any, but common enough (and getting more common) that you will hit them in production code. You don't want to block legitimate users because you encounter an IPv6 address.
If you are just using the IP address as fetched from the request, then there's nothing to worry about. The time to start thinking about validation is if you get traffic via a proxy server and you want the user's IP address rather than that of the proxy server. This is handled by proxy servers using the X-Forwarded-For header, and this is easily spoofed so take any value here with a pinch of salt and a bit of validation.