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.

classification
Title: ipaddress.IPv6Address.is_private makes redundant checks
Type: performance Stage: patch review
Components: Library (Lib) Versions: Python 3.11, Python 3.10, Python 3.9, Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: mjpieters
Priority: normal Keywords: patch

Created on 2021-05-18 09:07 by mjpieters, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 26209 open mjpieters, 2021-05-18 09:41
Messages (1)
msg393860 - (view) Author: Martijn Pieters (mjpieters) * Date: 2021-05-18 09:07
ipaddress.IPv6Address.is_private uses a hard-coded list of `IPv6Network` objects that cover private networks to test against.

This list contains two networks that are subnets of a 3rd network in the list. IP addresses that are not private are tested against all 3 networks where only a single test is needed.

The networks in question are:

        IPv6Network('2001::/23'),
        IPv6Network('2001:2::/48'),  # within 2001::/23
        ...
        IPv6Network('2001:10::/28'), # within 2001::/23

The first is a supernet of the other two, so any IP address that is tested against the first and is not part of that network, will also not be part of the other two networks:

>>> from ipaddress import IPv6Network
>>> sub_tla_id = IPv6Network('2001::/23')
>>> sub_tla_id.supernet_of(IPv6Network('2001:2::/48'))
True
>>> sub_tla_id.supernet_of(IPv6Network('2001:10::/28'))
True

We can safely drop these two network entries from the list.

On a separate note: the definition here is inconsistent with IPv4Address's list of private networks. 2001::/23 is the whole subnet reserved for special purpose addresses (RFC 2928), regardless of what ranges have actually been assigned. The IPv4 list on the other hand only contains _actual assignments within the reserved subnet_, not the whole reserved block (RFC 5736 / RFC 6890, reserving 192.0.0.0/24, IPv4Address only considers 192.0.0.0/29 and 192.0.0.170/31). I'll file a separate issue for that if not already reported.
History
Date User Action Args
2022-04-11 14:59:45adminsetgithub: 88333
2021-05-18 09:41:48mjpieterssetkeywords: + patch
stage: patch review
pull_requests: + pull_request24826
2021-05-18 09:07:36mjpieterscreate