The I2P network is currently under a Denial-of-Service attack. This attack affects I2P and i2pd but in different ways and is having a serious effect on network health. Reachability of I2P sites is badly degraded.
Java I2P users are suggested to disable the sybil attack tool, delete the sybil-blocklist, and re-start their routers.
To disable the sybil attack detector tool
Open the sybil attack detector in your router console at http://127.0.0.1:7657/netdb?f=3&m=15
Change “Background Analysis Run Frequency” to “Never”
Click “Save” to save the settings.
To delete the sybil blocklist, run:
On Debian and Ubuntu:
rm “/var/lib/i2p/i2p-config/sybil-analysis/blocklist-sybil.txt”
On other Linuxes and on Mac OSX:
rm “$HOME/.i2p/sybil-analysis/blocklist-sybil.txt”
And on Windows:
del %LocalAppData%\i2p\sybil-analysis\blocklist-sybil.txt"
When you are finished, re-start your I2P router.
If you are hosting a service inside I2P and it is hosted on a Floodfill router, you should consider multihoming the service on a Floodfill-disabled router to improve reachability. Other mitigations are being discussed but a long-term, backward-compatible solution is still being worked on.
From one of the developers:
Excellent question. In the case of Java I2P and of I2P+, the attacker is actually gaming the sybil attack tool in order to trick routers into erroneously banning floodfills.
Basically the attacker has found a way to trick real routers into attempting to connect to fake routers. Normally, this is not harmful, fake routers are just offline routers. Offline forever.
But if you craft your fake router this one specific way then the router you are tricking thinks some real router, which is usually reachable, is offline. That’s how it affects I2P without the sybil tool. The sybil tool, in this case, amplifies the effect of the attack and the duration of the attack, because the real router which is ddos’ed gets banned by the sybil tool.
Edit: I am deliberately leaving out specific details here.