Change default network from 172.17.0.0/16 to 169.254.0.0/16

[jbhoorasingh]

Any network defined in RCF1918 should not be used. This may cause routing issue if you are trying to access resources with an IP which falls in that range.

169.254.0.0/16 is a network which will never be routed within any network (i hope not)

[ghost]

I'm may be wrong here, but isn't 172.16-172.31 reserved for private networks, which is what docker is effectively creating in its containers' networks? If you can point me to where this is a problem it would be great, but since docker also uses 10.* and 127.168.* nets I think this is intentional. The container internal network is forwarded to the host network.

3. Private Address Space

   The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets:

   10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

[fcrisciani]

This PR will allow to specify the IP pools: https://github.com/docker/libnetwork/pull/2058

[erdnussflips]

@GordonHarley You asked where this could be a problem. In a companies network, could this be a problem, if they using 172.16/12.

[Gunni]

Do not use the first or last subnet, this RFC defines permitted use:

https://tools.ietf.org/html/rfc3927#section-2.1

[knkski]

I ran into this issue at my local library. The wifi network required getting redirected to a page where you accept their terms of use, and the internal DNS pointed me at 172.17.76.190 for that page, which conflicted with the default docker networking. Putting a non-conflicting IP range into /etc/docker/daemon.json and restarting docker fixed the issue for me:

{
  "bip": "172.26.0.1/16"
}

[mestag-a]

@knkski In my experience, this setting only sets the IP of the default Docker bridge interface. It doesn't prevent Docker from using 172.17.0.0/16 for another bridge ...

Are there any news on this proposal ? I'd also be interested in having Docker use another subnet than 172.17.0.0/16. Using 169.254.0.0/16 seems like a good idea, even though I agree with @GordonHarley 's comment. I'm not enough of a network guru to know the right thing to do.

[grealish]

I think the choice of private network CIDR for docker0 by docker should by dynamic and detect overlap with the LAN and WLAN interfaces, I see too many legacy and frankly dated WLAN network that reuses 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) Many cases if we do docker training and we find the WLAN DHCP range overlaps with local docker network, then it's a big no no as we can't have new people learning docker having to edit the /etc/docker/daemon.jsonfile just to avoid the issue.

I would like to see this some what solved as it becomes a blocker for less away when starting with docker

[hawicz]

Dynamically detecting overlap isn't really possible - just because you pick some subnet for docker to use that doesn't conflict with the host's local interface doesn't mean that it isn't routably connected to a conflicting subnet further out on the network. I've run into this exact problem, which can lead to somewhat hard to diagnose problems, and solved it by using the "link local" addresses as this issue suggests, so changing the default in this way seems to me like it would be a good thing.

It looks like the current default is at https://github.com/moby/libnetwork/blob/b3507428be5b458cb0e2b4086b13531fb0706e46/ipamutils/utils.go#L18, although I see a number of other references to "172.17" (e.g. in tests, etc...) so I expect changing this would be a bit more than a one line change. (I'm not familiar with this code at all, so I don't know what downstream effects such a change might have)