Bug #69232 [Com]: inet_ntop() does not treat IPv4 mapped IPv6 addresses consistently

Edit report at https://bugs.php.net/bug.php?id=69232&edit=1 ID: 69232 Comment by: wolfen at gmail dot com Reported by: wolfen at gmail dot com Summary: inet_ntop() does not treat IPv4 mapped IPv6 addresses consistently Status: Open Type: Bug Package: Network related Operating System: linux PHP Version: 5.5.23RC1 Block user comment: N Private report: N New Comment: In response to the comment yesterday (3/15/2015): Why do you say that ::F is not a valid IPv4 address? It is reserved as a broadcast address, which means I cannot assign it to a host. But it *is* a perfectly valid address as far as I know. Previous Comments: ------------------------------------------------------------------------ [2015-03-15 16:15:37] keithm at aoeex dot com It looks to me like the function is following RFC 5952. RFC5952 Seciton 5 "Text Representation of Special Addresses" "Addresses such as IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and IPv4-translatable addresses [ADDR-FORMAT] have IPv4 addresses embedded in the low-order 32 bits of the address.[...]For these addresses, mixed notation is RECOMMENDED if the following condition is met: the address can be distinguished as having IPv4 addresses embedded in the lower 32 bits solely from the address field through the use of a well-known prefix." ::FEEF:1886 meets that condition by having an all-zero prefix which is why it is formatted as an IPv4 mapped address. ::F meets the all-zero prefix but the lower 32-bits do not form a valid IPv4 address so it sticks with the IPv6 representation. ------------------------------------------------------------------------ [2015-03-12 19:02:48] wolfen at gmail dot com Description: ------------ I'm using PHP version 5.2.17, but using the online PHP sandbox at http://sandbox.onlinephpfunctions.com/ I see the same behavior for PHP versions up through 5.6.2: The following works as expected: $x = inet_pton('::F'); $y = inet_ntop($x); print "::F -> $y\n"; Output: ::F -> ::f But the following surprised me: $a = inet_pton('::FEEF:1886'); $b = inet_ntop($a); print "::FEEF:1886 -> $b\n"; Output: ::FEEF:1886 -> ::254.239.24.134 I would have expected the second code snippet to produce this output: ::FEEF:1886 -> ::feef:1886 My initial surprise was due to my being unaware that addresses in ::/96 (i.e. with the "high" 96 bits all set to 0) are considered "IPv4 compatible IPv6 addresses", which according to RFC 4291 are now deprecated. But what continues to mystify me is how PHP chooses between "pure IPv6 mode" (e.g. ::ff) and "IPv4 compatible IPv6 mode" (e.g. ::254.239.24.134) when generating a printable representation for an IPv6 address in ::/96. I can find no rule explaining which addresses are supposed to be rendered in which way, which seems wrong. IMO the "canonical representation" (as specified in RFC 5952) should be generated, or at least all the addresses in ::/96 should be rendered in the same format. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=69232&edit=1