How is a token value generated in mainline dht's get_peers query

I am reading bep 5 and trying to understand how a token value is generated. As I understand the token value is a randomly generated value that is used in a get_peers query for safety. This same token value would then be used in an announced_peers query to see if the same IP previously requested the same Infohash.

My question is how is this value generated exactly? It says something about an unspecified implementation - does this mean I can implement it myself (for example by using the SHA-1 value)?

I tried looking at other beps but couldn't find anything about specific rules for generating a token value, found nothing.

The token represents a write permission so that the other node may follow up with an announce request carrying that write permission.

Since the write permission is specific to an individual node providing the token it is not necessary to specify how it keeps track of valid write permissions, as there needs to be no agreement between nodes how the implementation works. For everyone else the token is just an opaque sequence of bytes, essentially a key.

Possible implementations are

• (stateful) keep a hashmap mapping from supplied tokens to their expiration time and which remote IP it is valid for.
• (stateless) hash a secret the remote ip, remote id and a validity-time-window-counter. then truncate the hash. bump the counter on a timer. when verifying check with the current and the previous counter.

Since a token is only valid for a few minutes and a node should also have a spam throttle it doesn't need to be high strength, just enough bits to make it impossible to brute-force. 6-8 bytes is generally enough for that purpose.

The underlying goal is to hand out a space-efficient, time-limited write permission to individual nodes in a way that other nodes can't forge.