Repository navigation
ipaddress.ip_network('0.0.0.0/0').is_private == True #82836
Description
| BPO | 38655 |
|---|---|
| Nosy | @ammaraskar, @corona10, @JamoBox |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2019-10-31.14:04:51.585>
labels = ['3.7', 'type-bug', 'library']
title = "ipaddress.ip_network('0.0.0.0/0').is_private == True"
updated_at = <Date 2020-12-23.16:40:12.315>
user = 'https://bugs.python.org/pascalhofmann'bugs.python.org fields:
activity = <Date 2020-12-23.16:40:12.315>
actor = 'corona10'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2019-10-31.14:04:51.585>
creator = 'pascalhofmann'
dependencies = []
files = []
hgrepos = []
issue_num = 38655
keywords = []
message_count = 6.0
messages = ['355753', '355998', '355999', '356007', '356044', '382990']
nosy_count = 5.0
nosy_names = ['ammar2', 'corona10', 'pascalhofmann', 'Wicken', 'maw1395']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue38655'
versions = ['Python 3.7']
Activity
pascalhofmann commentedon Oct 31, 2019
ipaddress.ip_network('0.0.0.0/0').is_private returns True, even though 0.0.0.0/0 clearly is no private network.
ammaraskar commentedon Nov 5, 2019
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.
ammaraskar commentedon Nov 5, 2019
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:
cpython/Lib/ipaddress.py
Lines 1537 to 1553 in 25fa3ec
pascalhofmann commentedon Nov 5, 2019
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.
JamoBox commentedon Nov 5, 2019
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.
maw1395 commentedon Dec 14, 2020
As far as I can tell this is still broken. A hard check for '0.0.0.0/0' should fix this issue.
JamoBox commentedon Oct 2, 2022
@ammaraskar I've put in a pull request #97733 for this issue - it seems to fix the immediate problem reported by OP.
The change of approach means we are asking "is the network itself private" rather than "are the network address and broadcast address of this network both in private ranges".
Are you able to give this a quick check to see if it's suitable?
Rosuav commentedon Nov 29, 2022
I'm trying to follow your logic here, and I think what you're writing now is that, if this network's base and broadcast addresses are within the same private block, the entire network is private. If that's your logic, it may be clearer to write it as "if this network is a subnet of any of the private blocks, it is private", although I believe the resulting effect will be the same.
gh-82836: fix private network check (#97733)
pythongh-82836: fix private network check (pythonGH-97733)
gh-82836: fix private network check (GH-97733)
Merge branch 'main' into fixinspect
hauntsaninja commentedon Jan 29, 2023
Thanks for fixing!