This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: ipaddress "is_private" and "is_global" are insufficiently documented and is_global probably has a bug
Type: behavior Stage:
Components: Versions: Python 3.4, Python 3.5
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: loewis, ncoghlan, pmoody, r.david.murray
Priority: normal Keywords:

Created on 2014-03-06 16:20 by r.david.murray, last changed 2022-04-11 14:57 by admin.

Messages (3)
msg212812 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-06 16:20
The 'is_private' and 'is_global' properties refer to the iana registries, but the terms 'private network' and 'public network' do no appear in the registry documentation.  There is no way to know what these methods are going to return other than examining the source code.

In particular, without looking at the source code a best-guess interpretation of the documentation would lead one to expect that is_private would return true only for RFC1918 addresses, since that is the one place the term 'private' appears.  Similarly, the naive interpretation of is_global would be that it would return False for all addresses listed in the ipv4 registry *except*, which is the only one whose global routing flag is True in the table.

I would submit that the fact that the latter is not true is a bug.

It is really not at all clear what 'is_private' means (see also issue 17400, which introduced is_global), so I am completely unclear how to rewrite the documentation to fully specify it, other than to list out the address ranges that it considers private.
msg212813 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-03-06 16:25
Oh, and just to make things more complicated, there are footnotes that some protocols allow global routing for protocol-allocated addresses that are otherwise not globally routable.  It would be reasonable to for is_global to ignore this, but it should be documented that it does so.
msg212843 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-03-06 21:50
I'm always in favour of using official terminology (and adjust if that changes over time). So in this case, I agree with David's analysis, and suggest the following specification:

- is_global returns False for all addresses where "Global" is "False" in the IPv4 or IPv6 Special-Purpose Address Registry
- a new method is_private_use is introduced, giving True only for the RFC1918 addresses
- a new method is_unique_local is introduced, giving True only for the RFC 4193 addresses.
- is_private is deprecated. Alternatively, it could be preserved and documented to being the union of is_privte_use and is_unique_local.

I don't think it it necessary to discuss footnote 1 in the IPv6 registry ("not global unless a specific allocations says otherwise"). The specific allocations that might override this come right below, so if we implement the table, we would cover all those more specific case.

I'm puzzled why Teredo is listed as "not global"; my understanding is that the Teredo prefixes even get announced in BGP, and are fully global.
Date User Action Args
2022-04-11 14:57:59adminsetgithub: 65056
2014-03-06 21:50:40loewissetnosy: + loewis
messages: + msg212843
2014-03-06 16:25:37r.david.murraysetmessages: + msg212813
2014-03-06 16:20:35r.david.murraycreate