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* 192.88.99.0/24, 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.

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.

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.