You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dual stack applications such as modern browsers should never have to deal with IPv4-mapped IPv6 addresses (https://tools.ietf.org/html/rfc4291#section-2.5.5), as they can simply use IPv4 addresses instead. This is not the case today however, at least in Chromium, in which for example [::ffff:7f00:1] resolves to localhost.
This situation is unfortunate, as it results in us having to specify how to determine the address space of such addresses (use the address space of the embedded IPv4 address).
It would be nice to reach a more satisfactory end state, maybe by amending the Fetch specification to forbid accessing such IP addresses?
It seems that the next step here is to file an issue on the Fetch specification. Then we can come back here and close this out by removing the special casing for IPv4-mapped IPv6 addresses.
It seems that the next step here is to file an issue on the Fetch specification. Then we can come back here and close this out by removing the special casing for IPv4-mapped IPv6 addresses.
Have you filed such an issue on the Fetch spec already?
Activity
letitz commentedon Feb 23, 2021
It seems that the next step here is to file an issue on the Fetch specification. Then we can come back here and close this out by removing the special casing for IPv4-mapped IPv6 addresses.
fred-wang commentedon May 14, 2021
Have you filed such an issue on the Fetch spec already?
letitz commentedon May 17, 2021
I have not, this is fairly low priority so far.
letitz commentedon Sep 22, 2022
Finally filed whatwg/fetch#1492.
SoniEx2 commentedon Aug 4, 2024
it gets worse if you take into account that a service can deploy both ULA and GUA for the same hostname (and this is not particularly uncommon)