This issue tracker will soon become read-only and move to GitHub.
For a smoother transition, remember to log in and link your GitHub username to your profile.
For more information, see this post about the migration.

classification
Title: ipaddress.ip_network('0.0.0.0/0').is_private == True
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Wicken, ammar2, corona10, maw1395, pascalhofmann
Priority: normal Keywords:

Created on 2019-10-31 14:04 by pascalhofmann, last changed 2020-12-23 16:40 by corona10.

Messages (6)
msg355753 - (view) Author: (pascalhofmann) Date: 2019-10-31 14:04
ipaddress.ip_network('0.0.0.0/0').is_private returns True, even though 0.0.0.0/0 clearly is no private network.
msg355998 - (view) Author: Ammar Askar (ammar2) * (Python committer) Date: 2019-11-05 05:06
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.
msg355999 - (view) Author: Ammar Askar (ammar2) * (Python committer) Date: 2019-11-05 05:09
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
msg356007 - (view) Author: (pascalhofmann) Date: 2019-11-05 07:11
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.
msg356044 - (view) Author: Pete Wicken (Wicken) * Date: 2019-11-05 16:01
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.
msg382990 - (view) Author: Michael Woodham (maw1395) Date: 2020-12-14 15:22
As far as I can tell this is still broken. A hard check for '0.0.0.0/0' should fix this issue.
History
Date User Action Args
2020-12-23 16:40:12corona10setnosy: + corona10
2020-12-14 15:22:33maw1395setnosy: + maw1395
messages: + msg382990
2019-11-05 16:01:54Wickensetnosy: + Wicken
messages: + msg356044
2019-11-05 07:11:42pascalhofmannsetmessages: + msg356007
2019-11-05 05:09:49ammar2setmessages: + msg355999
2019-11-05 05:06:19ammar2setnosy: + ammar2
messages: + msg355998
2019-10-31 14:04:51pascalhofmanncreate