Repository navigation
ipaddress.IPv6Address.is_loopback broken for IPv4-mapped addresses #117566
Description
Bug report
Bug description:
While properties like is_private account for IPv4-mapped IPv6 addresses, such as for example:
>>> ipaddress.ip_address("192.168.0.1").is_private
True
>>> ipaddress.ip_address("::ffff:192.168.0.1").is_private
True...the same doesn't currently apply to the is_loopback property:
>>> ipaddress.ip_address("127.0.0.1").is_loopback
True
>>> ipaddress.ip_address("::ffff:127.0.0.1").is_loopback
FalseAt minimum, this inconsistency between different properties is counter-intuitive. Moreover, ::ffff:127.0.0.0/104 is for all intents and purposes a loopback address, and should be treated as such.
For the record, this will now match the behavior of other languages such as Rust, Go and .NET, cf. rust-lang/rust#69772.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux
Activity
pythongh-117566: fix IPv6Address.is_loopback for IPv4-mapped loopbacks
pythongh-117566: fix IPv6Address.is_loopback for IPv4-mapped loopbacks
pythongh-117566: fix IPv6Address.is_loopback for IPv4-mapped loopbacks
gh-117566: fix IPv6Address.is_loopback for IPv4-mapped loopbacks (GH-…
paravoid commentedon Apr 26, 2024
This was fixed in main, as @encukou merged the PR. The only outstanding question I have is whether this warrants a backport to 3.12.x or not. Depending on the answer, this may be resolved :)
encukou commentedon Apr 29, 2024
The answer is not obvious.
But given a similar PR is being backported, I say this one should be backported as well.
pythongh-117566: fix IPv6Address.is_loopback for IPv4-mapped loopbacks (
[3.12] gh-117566: fix IPv6Address.is_loopback for IPv4-mapped loopbac…
paravoid commentedon May 1, 2024
@encukou thanks so much for the review, good feedback, merge & backport -- much appreciated! ❤️
jstasiak commentedon May 21, 2024
Hey all, sorry for a late comment but I only now saw this issue randomly.
Just to clarify, Rust's behavior is deliberately the opposite of this, as in it doesn't interpret IPv4-mapped IPv6 addresses like that[1][2].
I would argue that
is not necessarily the only or even the most natural approach. For example with this patch there's no built-in way to check strictly for the IPv6 loopback address and nothing else.
And yes, I'd argue that
is_privateandis_globalinterpreting IPv4-mapped IPv6 addresses is IMO a mistake too and the decision is best left to the developer (theipv4_mappedproperty can be used to convert if/when needed).[1] rust-lang/rust#86335
[2] https://doc.rust-lang.org/std/net/struct.Ipv6Addr.html#ipv4-mapped-ipv6-addresses
encukou commentedon May 30, 2024
Noted.
I'll also opine that this API is, in hindsight, too coarse-grained and opinionated to be a good match for stdlib. Everyone has different expectations of what the edge cases should be.
See this point in the linked Rust discussion: “A point in favour of not supporting IPv4-in-IPv6 addresses is that that is the behaviour Rust has always had, and that supporting it would require changing already stable functions”
IMO, the most important thing we should go for here is consistency within the module: either all the functions should unwrap IPv4-mapped addresses, or none of them should.