I started to add a comment on Hendrik Brummermann's answer but quickly ran out of space, hence....
I do not understand why an absence of CSRF protection would affect logging of an IP address. And even if it did, in the absence of any session management, what relevance an IP address has to managing the integrity of a transaction?
Also, in order to avoid replays, the token would need to vary between transactions - so the server would need to generate new values for each operation and remember them between requests - implying a session - implying a cookie!
What's missing from the original question is details of the threat model - particularly in the absence of any session, what is it you are trying to protect?
Assuming that replay attacks are not a big issue, then you could just include both a random value (R) and the hash of that random value + salt (f(R+X)) as hidden fields. Embedding a timestamp in R reduces the window for any replay attack (when you add the machinery to check it).
A stateless solution could be implemented by using information supplied in each request, e.g. using the user agent and accept- headers and (say) the first 16 bits of the client IP address AND a secret salt.
Note that I've regularly pointed out the silliness of using IP address information for authentication - and a client IP address can change (e.g. when connecting via load-balanced proxies) however IME, the only time where the most significant bits of the IP address change is when the client is deliberately trying to obscure their identity via a service such as TOR - in which case you probably don't want their POSTs anyway.
There are other ways of making this user identifier more unique - e.g. negotiated SSL properties, the current cookie set (even if it is empty!),
Obviously whatever reference data you use for the check, if you want to implement this via Django, then you'll need to override both the token generator and the checker (CsrfViewMiddleware).