对于某些“看起来像”IPv4 地址的 IPv6 地址,inet_pton() 是否损坏


Is inet_pton() broken for some IPv6 addresses that "look like" IPv4 addresses?

我使用的是PHP版本5.2.17,我看到以下内容按预期工作:

$x = inet_pton('::F');
$y = inet_ntop($x);
print "::F -> $y'n";
Output: ::F -> ::f

但以下没有:

$a = inet_pton('::FEEF:1886');
$b = inet_ntop($a);
print "::FEEF:1886 -> $b'n";
Output: ::FEEF:1886 -> ::254.239.24.134

我本来希望第二个代码片段产生此输出:

::FEEF:1886 -> ::feef:1886
IPv6地址::

FEEF:1886是什么让PHP认为它真的是一个IPv4地址?inet_ntop/inet_pton 转换在"高"96 位中具有 0 的其他地址(例如 ::F)中正常工作。

编辑:我的第一个想法是这可能是我的PHP版本中的错误,但是使用这个在线PHP沙箱,我看到PHP版本到5.6.2的相同行为。因此,这要么是故意的(在这种情况下,我非常想知道这种行为的原因),要么是现代版本的PHP中仍然存在的错误。

附录:我在 2015 年 3 月 12 日打开了 PHP Bug 69232,因为 inet_ntop() 对 ::/96 中地址的行为明显不一致。

IPv6 地址的文本表示允许每个 IPv6 地址的多个不同有效表示。

这意味着 IPv6 的所有这些有效文本表示在通过 inet_pton 时都映射到相同的二进制 128 位字符串。

但是,当使用inet_ntop将二进制128位字符串转换为文本表示时,它显然只能输出代表该IP地址的众多有效字符串之一。它选择的那个称为规范表示。

使用 IPv4 表示法写入 IPv6 地址的最后 32 位始终有效。但是,只有少数IPv6地址类使用该格式作为其规范表示形式。

::/96已被弃用,但这只是意味着这些地址不应该再被使用,它不会影响inet_ptoninet_ntop对待它们的方式。

::ffff:0.0.0.0/96是另一个前缀,在其规范表示中使用 IPv4 表示法。该前缀用于套接字 API 中的 IPv4 兼容性,但这些前缀永远不会通过网络发送,因为它们适用于线路上的流量为 IPv4 的情况。

您看到的是(错误地)表示为IPv6地址的IPv4地址。这种做法在 2006 年被 RFC 4291 正式弃用:

"IPv4 兼容 IPv6 地址"现已弃用,因为当前的 IPv6 转换机制不再使用这些地址。不需要新的或更新的实现来支持这一点地址类型。

试试这个:

function _inet_ntop($ip) {
  if (strlen($ip) == 4) { // For IPv4
    list(, $ip) = unpack('N', $ip);
    $ip = long2ip($ip);
  }
  elseif(strlen($ip) == 16) { // For IPv6
    $ip = bin2hex($ip);
    $ip = substr(chunk_split($ip, 4, ':'), 0, -1);
    $ip = explode(':', $ip);
    $res = '';
    foreach($ip as $index => $seg) {
      while ($seg {0} == '0')
        $seg = substr($seg, 1);
      if ($seg != '') {
        $res .= $seg;
        if ($index < count($ip) - 1)
          $res .= $res == '' ? '' : ':';
      } else {
        if (strpos($res, '::') === false)
          $res .= ':';
      }
    }
    $ip = $res;
  }
  return $ip;
}

你可以调用这个函数而不是inet_ntop

$a = inet_pton('::FEEF:1886');
$b = _inet_ntop($a);
print "::FEEF:1886 -> $b'n";
// Output => ::FEEF:1886 -> ::feef:1886
$x = inet_pton('::F');
$y = _inet_ntop($x);
print "::F -> $y'n";
// Output => ::F -> ::f

总结一下到目前为止我在答案和评论中所看到的内容:

  • IPv6 地址具有规范格式,即 inet_ntop() 返回的格式。
  • ::
  • /96 地址范围已弃用,但 ::ffff/80 未弃用。
  • 尽管所有 ::/96 地址都由 inet_ntop() 渲染为 ::/IPv4 地址是有意义的,但似乎 inet_ntop() 将 ::/112 地址和 ::/96 中的"更高"呈现为 ::/IPv4
  • 点状四边形(例如 ::254.239.24.134),并将 ::/96 地址呈现为"低于"::/112 作为"正常"IPv6 地址。
  • 如果您希望 inet_ntop() 以相同的方式呈现所有 IPv6 地址(即 8 个十六进制单词具有通常的零压缩规则),那么您需要编写自己的方法来实现这一点。

我自己的解决方法是通过将任何 IPv4 点分四边形重写为十六进制字来扩展 inet_ntop()(我将逻辑分解为多种方法,以便我更容易跟踪我在做什么):

function _inet_ntop($addr) {
    return fix_ipv4_compatible_ipv6(inet_ntop($addr));
}
/**
 * If $str looks like ::/IPv4-dotted-quad then rewrite it as
 * a "pure" IPv6 address, otherwise return it unchanged.
 */
function fix_ipv4_compatible_ipv6($str) {
    if (
        ($str[0] == ':') &&
        ($str[1] == ':') &&
        preg_match('/^::('S+'.'S+)$/', $str, $match)
    ) {
        $chunks = explode('.', $match[1]);
        return self::ipv4_zones_to_ipv6(
            $chunks[0],
            $chunks[1],
            $chunks[2],
            $chunks[3]
        );
    } else {
        return $str;
    }
}
/**
 * Return a "pure" IPv6 address printable string representation
 * of the ::/96 address indicated by the 4 8-bit "zones" of an
 * IPv4 address (e.g. (254, 239, 24, 134) -> ::feef:1886).
 */
function ipv4_zones_to_ipv6($q1, $q2, $q3, $q4) {
    if ($q1 == 0) {
        if ($q2 == 0) {
            if ($q3 == 0) {
                if ($q4 == 0) {
                    return '::0';
                } else {
                    return '::' . self::inflate_hexbit_pair($q4);
                }
            } else {
                return '::' . self::inflate_hex_word($q3, $q4);
            }
        } else {
            return '::' . self::inflate_hexbit_pair($q2) . ':' . self::inflate_hex_word($q3, $q4);
        }
    } else {
        return '::' . self::inflate_hex_word($q1, $q2) . ':' . self::inflate_hex_word($q3, $q4);
    }
}
/**
 * Convert two 8-bit IPv4 "zones" into a single 16-bit hexword,
 * stripping leading 0s as needed, e.g.:
 * (254, 239) -> feef
 * (0,1) -> 1
 */
function inflate_hex_word($hb1, $hb2) {
    $w = self::inflate_hexbit_pair($hb1) . self::inflate_hexbit_pair($hb2);
    return ltrim($w, '0');
}
/**
 * Convert one 8-bit IPv4 "zone" into two hexadecimal digits,
 * (hexits) padding with a leading zero if necessary, e.g.:
 * 254 -> fe
 * 2 -> 02
 */
function inflate_hexbit_pair($hb) {
    return str_pad(dechex($hb), 2, '0', STR_PAD_LEFT);
}

虽然可以说远不如 JC Sama 提出的 _inet_ntop() 函数优雅,但它的运行速度比我的(基本上是随机的)测试用例快了大约 25%。

kasperd,diskwuff和JC Sama提供的答案提供了有用的信息和解决方法,可能对其他SO读者有用,所以我对它们都投了赞成票。但是他们没有直接解决我最初的问题,所以我添加了这个答案:

PHP 函数 inet_pton() 的行为是正确的。问题是 inet_ntop() 没有一致地处理 ::/96 中的 IPv6 地址。这是PHP中的一个错误。