The current setup is allowing data leaks in a dual stack network over IPv6. Disabling IPv6 in the docker network should solve this.

[MuttMutt-Outdoors]

Breaking change

I do not believe this will break anything but the network changes potentially could cause an issue.  I have tested and researched the changes but those mainly are in the docker network.  I did my best to use the same information from a working container so it should be seamless.  I also tested the docker compose setup as a fresh install on Ubuntu and verified that the IPv6 leaks are fixed.

Proposed change

The current setup is allowing DNS and potentially traffic to pass over the IPv6 address from the container in a dual stack network.  Simply disabling the IPv6 connectivity for the network that is being used by the Transmission-OpenVPN container should fix this issue.  It's mainly a change in how a container is setup in docker or podman and should be fairly  simple.  I was able to test the Docker Compose changes however I did not test the docker run so it should be tested but the documentation I read shows it should work. 

I also added a couple sections dealing with the testing of leaks coming from transmission for those people who decide they want to use a dual stack network.  The instructions should be fairly simple to follow and allow people to fix the potential issues or at least help them understand they need to test before they start using the setup in a dual stack environment.

Sorry if I goofed anywhere this is my first ever pull request to a public repo.  Let me know or feel free to fix. 

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New feature (which adds functionality to this container)
• Breaking change (fix/feature causing existing functionality to break)

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue: relates to #
• Link to documentation updated (if done separately): https://...

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated

[ilike2burnthing]

This would likely break Mullvad and OVPN setups:

docker-transmission-openvpn/docs/provider-specific.md

Lines 66 to 81 in dad76c5

	### MULLVAD & OVPN
	According to [(#1355)](https://github.com/haugene/docker-transmission-openvpn/issues/1355)
	ipv6 needs to be enabled for mullvad vpn
	this is an example for docker compose
	```yaml
	# ipv6 must be enabled for Mullvad to work
	sysctls:
	- "net.ipv6.conf.all.disable_ipv6=0"
	```
	or add following line to docker run
	```yaml
	--sysctl net.ipv6.conf.all.disable_ipv6=0
	```
	The same is true for provider OVPN.

[MuttMutt-Outdoors]

Simple enough to put in the documentation to comment out or remove that section for Mullvad or OVPN users.

Currently anyone who is using the default configuration in a dual stack environment is likely leaking DNS at the very least and possibly more. Unless there is another way to disable IPv6 in the container. I also have to assume that Mullvad and OVPN are able to work over an IPv4 connection since there are still ISP's who do have not implemented IPv6 on their network. This change only disables IPv6 from the container to the local network, inside the container IPv6 should still continue to function.

[ilike2burnthing]

         sysctls: 
             - "net.ipv6.conf.all.disable_ipv6=1" # 0 for Mullvad and OVPN users

Would this not be easier than creating a new network?

[MuttMutt-Outdoors]

A new container always creates a new network unless it is implicitly told to join an existing network so really the code change only prevents the network from passing data.

The issue with Mullvad and OVPN are probably stemming from earlier versions of docker that did not enable IPv6 by default for whatever reason. Now that it does we have to swing in the opposite direction and disable the connectivity.

On top of that if we disable IPv6 in the container then we lose the ability to use IPv6 between containers should that be desired. You could easily create a network that has IPv6 availability but no true network access and attach both to the container. Then use IPv6 to communicate between multiple containers yet restrict outside access to IPv6 from the transmission-openvpn container to the internet itself.

I am sure there are multiple ways to do this but it's difficult to choose which one makes the most sense based on the particular situation. IMHO using the network to do so prevents the container from even having an opportunity to receive an IPv6 address at all.