Description

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'

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

1. pascalhofmann commented on Oct 31, 2019

   

   pascalhofmannmannequin

   on Oct 31, 2019

   MannequinAuthor

   More actions

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

   added

   3.7 (EOL)end of lifeend of life

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Oct 31, 2019
3. ammaraskar commented on Nov 5, 2019

   

   ammaraskar

   on Nov 5, 2019

   Member

   More actions

   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.
4. ammaraskar commented on Nov 5, 2019

   

   ammaraskar

   on Nov 5, 2019

   Member

   More actions

   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'),
   	]
5. pascalhofmann commented on Nov 5, 2019

   

   pascalhofmannmannequin

   on Nov 5, 2019

   MannequinAuthor

   More actions

   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.
6. JamoBox commented on Nov 5, 2019

   

   JamoBoxmannequin

   on Nov 5, 2019

   Mannequin

   More actions

   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.
7. maw1395 commented on Dec 14, 2020

   

   maw1395mannequin

   on Dec 14, 2020

   Mannequin

   More actions

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

   transferred this issue fromon Apr 10, 2022
9. JamoBox commented on Oct 2, 2022

   

   JamoBox

   on Oct 2, 2022

   Contributor

   More actions

   @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?
10. Rosuav commented on Nov 29, 2022

    

    Rosuav

    on Nov 29, 2022

    Contributor

    More actions

    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.
11. gpshead

    added a commit that references this issue on Nov 29, 2022

    gh-82836: fix private network check (#97733)

    ed39109
12. miss-islington

    added 2 commits that reference this issue on Nov 29, 2022

    pythongh-82836: fix private network check (pythonGH-97733)

    a6f937c

    gh-82836: fix private network check (GH-97733)

    8dafefc
13. carljm

    added a commit that references this issue on Dec 1, 2022

    Merge branch 'main' into fixinspect

    12f7659
14. hauntsaninja commented on Jan 29, 2023

    

    hauntsaninja

    on Jan 29, 2023

    Contributor

    More actions

    Thanks for fixing!
15. hauntsaninja

    closed this as completedon Jan 29, 2023

Issue actions