Bug #69232 [NEW]: inet_ntop() does not treat IPv4 mapped IPv6 addresses consistently
| From: | wolfen at gmail dot com | 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