Repository navigation
ipaddress.IPv6Address.is_loopback broken for IPv4-mapped addresses #117566
Description
Activity
- addedtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
on Apr 5, 2024 - addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on Apr 6, 2024 - added a commit that references this issue
on Apr 25, 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 :)
The answer is not obvious.
But given a similar PR is being backported, I say this one should be backported as well.- added a commit that references this issue
on Apr 29, 2024 @encukou thanks so much for the review, good feedback, merge & backport -- much appreciated! ❤️
Hey all, sorry for a late comment but I only now saw this issue randomly.
For the record, this will now match the behavior of other languages such as Rust, Go and .NET, cf. rust-lang/rust#69772.
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
Moreover, ::ffff:127.0.0.0/104 is for all intents and purposes a loopback address, and should be treated as such.
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-addressesNoted.
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.
Bug report
Bug description:
While properties like
is_privateaccount for IPv4-mapped IPv6 addresses, such as for example:...the same doesn't currently apply to the
is_loopbackproperty:At minimum, this inconsistency between different properties is counter-intuitive. Moreover,
::ffff:127.0.0.0/104is 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
Linked PRs