ipaddress.ip_network('0.0.0.0/0').is_private returns True, even though 0.0.0.0/0 clearly is no private network.

The documentation for is_private notes:

  Returns:
  A boolean, True if the address is reserved per RFC 4193.
  iana-ipv4-special-registry or iana-ipv6-special-registry.

If we take a look at the iana-ipv4-special-registry then 0.0.0.0/8 does show up there: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml

While the name might be a misnomer, is_reserved instead of is_private might have been better, it does seem to conform to what the documentation says it will do.

Aah actually I was looking at an older version of the docs, the documentation now says, "if the address is allocated for private networks" which is actually misleading. The addresses here aren't all private networks: https://github.com/python/cpython/blob/25fa3ecb98f2c038a422b19c53641fa8e3ef8e52/Lib/ipaddress.py#L1537-L1553

0.0.0.0/0 is a network with addresses from 0.0.0.0 to 255.255.255.255.
0.0.0.0/8 is a network with addresses from 0.0.0.0 to 0.255.255.255.

So 4278190080 out of 4294967296 addresses in 0.0.0.0/0 clearly are no private addresses.

Looks like this happens because the is_private method that gets called is from _BaseNetwork, which checks if the network address '0.0.0.0' and the broadcast address '255.255.255.255' are both private, which they are as 0.0.0.0 falls into 0.0.0.0/8.

I think for this to get it right, you would have to change the is_private check for networks to iterate over each possible subnet and check if that is in the private networks list. This takes an unfeasibly long time.

So, we would probably have to add special cases for these networks, unless people have better ideas.

As far as I can tell this is still broken. A hard check for '0.0.0.0/0' should fix this issue.