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.

Author forst
Recipients bbayles, ekohl, forst, h.venev, jana, pmoody, python-dev, ronaldoussoren
Date 2021-10-17.17:38:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1634492336.79.0.0714818362439.issue30528@roundup.psfhosted.org>
In-reply-to
Content
I've stumbled upon this myself, and had a go at fixing it, before looking up this issue. My approach ended up being a bit different:

1. I rewrote the existing _reverse_pointer() methods, so that they'd handle both addresses and networks, instead of defining separate methods for the IPvXNetwork classes.
2. Trying to generate a reverse pointer for a prefix that doesn't align with the granularity of reverse pointers (8 bits for IPv4, 4 bits for IPv6) will raise an exception instead of returning a more general prefix.

I would like to bring up point 2 for discussion, since it differs from both of the other PRs submitted regarding this issue.

For example, let's take an example subnet 127.45.240.0/20. The other solutions here propose generating a reverse pointer like "45.127.in-addr.arpa", i.e. returning a reverse pointer to a bigger subnet that includes the original one. When you convert that reverse pointer back into a network, you get 127.45.0.0/16. It doesn't match the original network, thus you lose some information about it.

I'd like to propose to be more strict about it (or at least, make the strict behaviour an option) to avoid unintentional loss of precision when generating reverse pointers in these cases.
History
Date User Action Args
2021-10-17 17:38:56forstsetrecipients: + forst, ronaldoussoren, pmoody, python-dev, h.venev, bbayles, ekohl, jana
2021-10-17 17:38:56forstsetmessageid: <1634492336.79.0.0714818362439.issue30528@roundup.psfhosted.org>
2021-10-17 17:38:56forstlinkissue30528 messages
2021-10-17 17:38:56forstcreate