ipaddress.ip_network('0.0.0.0/0').is_private == True

@ammaraskar

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']

Linked PRs

[3.11] gh-82836: fix private network check (GH-97733) #99887

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:

cpython/Lib/ipaddress.py

Lines 1537 to 1553 in 25fa3ec

    
           _private_networks = [ 
        
               IPv4Network('0.0.0.0/8'), 
        
               IPv4Network('10.0.0.0/8'), 
        
               IPv4Network('127.0.0.0/8'), 
        
               IPv4Network('169.254.0.0/16'), 
        
               IPv4Network('172.16.0.0/12'), 
        
               IPv4Network('192.0.0.0/29'), 
        
               IPv4Network('192.0.0.170/31'), 
        
               IPv4Network('192.0.2.0/24'), 
        
               IPv4Network('192.168.0.0/16'), 
        
               IPv4Network('198.18.0.0/15'), 
        
               IPv4Network('198.51.100.0/24'), 
        
               IPv4Network('203.0.113.0/24'), 
        
               IPv4Network('240.0.0.0/4'), 
        
               IPv4Network('255.255.255.255/32'), 
        
               ]

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.

@ammaraskar

@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?

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

Thanks for fixing!

Navigation Menu

Repository navigation

ipaddress.ip_network('0.0.0.0/0').is_private == True #82836

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	_private_networks = [
	IPv4Network('0.0.0.0/8'),
	IPv4Network('10.0.0.0/8'),
	IPv4Network('127.0.0.0/8'),
	IPv4Network('169.254.0.0/16'),
	IPv4Network('172.16.0.0/12'),
	IPv4Network('192.0.0.0/29'),
	IPv4Network('192.0.0.170/31'),
	IPv4Network('192.0.2.0/24'),
	IPv4Network('192.168.0.0/16'),
	IPv4Network('198.18.0.0/15'),
	IPv4Network('198.51.100.0/24'),
	IPv4Network('203.0.113.0/24'),
	IPv4Network('240.0.0.0/4'),
	IPv4Network('255.255.255.255/32'),
	]

ipaddress.ip_network('0.0.0.0/0').is_private == True #82836

Description

Linked PRs

Activity

pascalhofmann commented on Oct 31, 2019

ammaraskar commented on Nov 5, 2019

ammaraskar commented on Nov 5, 2019

pascalhofmann commented on Nov 5, 2019

JamoBox commented on Nov 5, 2019

maw1395 commented on Dec 14, 2020

JamoBox commented on Oct 2, 2022

Rosuav commented on Nov 29, 2022

hauntsaninja commented on Jan 29, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions