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

From: Date: Thu, 12 Mar 2015 19:02:48 +0000
Subject: Bug #69232 [NEW]: inet_ntop() does not treat IPv4 mapped IPv6 addresses consistently
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-191354@lists.php.net to get a copy of this message
From: wolfen at gmail dot com Operating system: linux PHP version: 5.5.23RC1 Package: Network related Bug Type: Bug Bug description:inet_ntop() does not treat IPv4 mapped IPv6 addresses consistently 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 bug report at https://bugs.php.net/bug.php?id=69232&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=69232&r=trysnapshot54 Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=69232&r=trysnapshot55 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=69232&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=69232&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=69232&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=69232&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=69232&r=needscript Try newer version: https://bugs.php.net/fix.php?id=69232&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=69232&r=support Expected behavior: https://bugs.php.net/fix.php?id=69232&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=69232&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=69232&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=69232&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=69232&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=69232&r=dst IIS Stability: https://bugs.php.net/fix.php?id=69232&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=69232&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=69232&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=69232&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=69232&r=mysqlcfg

« previous php.bugs (#191354) next »