Disable Userland proxy by default

[thaJeztah]

The userland proxy was made optional in #12165 (ported to libnetwork in moby/libnetwork#171),
but still enabled by default because (if I remember correctly) disabling it caused issues on RHEL6 (cf #10676).

Now that we will stop supporting RHEL6 with the coming 1.8 release, I think we can change the default to "disabled". We can still keep the --userland-proxy option around so that users are able to enable it by setting --userland-proxy=true. We can remove the proxy altogether in a future release.

Changing the default might help resolving #11185 (possibly others)

Some issues related to disabling the userland-proxy that we should look into;

• userland-proxy doesn't allow host ip communications #21860
• overlay networking with userland-proxy disabled prevents port exposure #22741
• With --userland-proxy=false, dockerd listens on exposed ports (instead of docker-proxy) #28589
• When using userland-proxy=false many iptables entries instead of multiport #36214
• Cannot disable userland-proxy and go with hairpin #37163
• Cannot communicate with host through gateway IP when userland-proxy: false #40518
• container not able receive UDP traffic when disabled userland-proxy libnetwork#2423
• Broken network connectivity between two containers of different networks over published port on external ip #38784
• userland-proxy: false does not clean-up NAT rule when switching to userland-proxy: true #44721

[thaJeztah]

ping @docker/maintainers @mrjana @mavenugo

[mrjana]

@thaJeztah SGTM. I will push a PR once we get a few more thumbs up from @docker/maintainers.

ping @icecrime as well

[tiborvass]

I personally think @thaJeztah's proposal makes sense. +1 on changing default to false but keeping the flag just in case we have reports of other weird issues.

[LK4D4]

I think we should check if netlink for Hairpin isn't supported with --false and die then.

[tianon]

👍

[icecrime]

I'm all for it, I'm just a bit worried as I don't think so many people are giving --userland-proxy=false a try today (I have it on my host since 1.7.0 without issues), but that's what the freeze period is for.

[thaJeztah]

@icecrime true, but holding off longer won't help there. We've got the flag to give users a way to restore the old behaviour, so even if it results in issues, we can offer users a solution without having to release an update.

[icecrime]

@thaJeztah I agree. Do you want to try this for 1.8.0? I'm assuming we'd need a libnetwork PR to give us HairpinModeSupported() bool.

[thaJeztah]

I think it would be good to have this in 1.8.

@mrjana is already in this discussion and offered to create a PR to accommodate the changes (#14856 (comment))

I'll add it to the milestone (unless @calavera has objections)

[calavera]

sounds great!

[chenchun]

I have a question, does libnetwork or docker checks if a random allocated port is currently used by other processes with --userland-proxy=false? I known previously if failing to start userland-proxy process, such as the port is being allocated by other processes on the host, docker will retry to allocate a new port.