In the bep042 it is said,

> A DHT node which receives an ip result in a request SHOULD consider
> restarting its DHT node with a new node ID, taking this IP into
> account. Since a single node can not be trusted, there should be some
> mechanism to determine whether or not the node has a correct
> understanding of its external IP or not. This could be done by voting,
> or only restart the DHT once at least a certain number of nodes, from
> separate searches, tells you your node ID is incorrect.

Before bootstrap an id is generated and properly secured as described in the P "Node ID restriction".
Both id and ip values, might be incorrect, but are stored, are accessible for later manipulations, and are used anyway for the bootstrap.

The bootstrap lookup takes place, find_node messages are sent, their responses contains the ip field with a value, might be errors or responses.

> Nodes that enforce the node-ID will respond with an error message
> ("y": "e", "e": { ... }), whereas a node that supports this extension
> but without enforcing it will respond with a normal reply ("y": "r",
> "r": { ... }).

At that point the program should consider it has failed to discover its public ip, accounting for the reception of many ip fields values which are different from the one stored at beginning.

At that point,
- What measures can be taken to ensure that the new ip provided by the network is correct ?
- Or, is the network to be fully trusted by the consensus of the majority ? (If i get 40 responses, with 35 identical ip fields, its a majority)
- is it mandatory to keep checking the ip field after bootstrap ? which is the only moment where the ip field "vote" check takes place.
I could check all messages, but that makes the code more complex than what seems necessary.