Use of "ipv4" and "ipv6" announce parameters is now discouraged

[undertheironbridge]

In the last (12 March 2020) update to BEP-0007, the following paragraph was added :

An earlier version of this BEP specified new HTTP parameters to announce an additional address of a different address family than the source IP address of the tracker connection (&ipv4= and &ipv6=). These are discouraged, as they allow an attacker to announce a victim's IP address to launch a DDoS attack.

This is a valid concern. Ocelot supports ip and ipv4 announce parameters, as well as the X-Forwarded-For HTTP header, as ways to change the default IP reported to other peers.

[itismadness]

What a poor change as it really complicates the record keeping. It reads to me that to follow BEP-007, we can now expect a user may send the same announce multiple times with different IP addresses, and we have to now correlate them all to avoid duplication of stats.

[Roardom]

transmission/transmission#4502

[ckerr]

Transmission dev here. Does removal of ipv4=, ipv6= break Ocelot?

[sheepish-ops]

@ckerr Thanks for asking! No, it doesn't break anything.

The ipv6 code is quite buggy and I hope nobody is actually running it.

[voaii]

@ckerr Thanks for asking! No, it doesn't break anything.

The ipv6 code is quite buggy and I hope nobody is actually running it.

I'm currently running the v2.0 tagged version.
Will running the current version and removing ipv4=, ipv6= allow for both?

[sheepish-ops]

One of the problems with the IPv6 implementation in current master is that it is using a shared swarm for IPv4 and IPv6. This can cause problems with clients that do not support IPv6, see for example #24

There are very likely more issues, thus my recommendation to not run that IPv6 code at all.