Bug #50117 [Opn->Csd]: IPv6 validation errors
| From: | cataphract@php.net | Date: | Mon, 08 Nov 2010 04:39:53 +0000 |
| Subject: | Bug #50117 [Opn->Csd]: IPv6 validation errors | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-155842@lists.php.net to get a copy of this message | ||
Edit report at http://bugs.php.net/bug.php?id=50117&edit=1
ID: 50117
Updated by: cataphract@php.net
Reported by: crisp at xs4all dot nl
Summary: IPv6 validation errors
-Status: Open
+Status: Closed
Type: Bug
Package: Filter related
Operating System: *
PHP Version: 5.*, 6
-Assigned To:
+Assigned To: cataphract
Block user comment: N
New Comment:
Fixed for PHP 5.3 and trunk.
Previous Comments:
------------------------------------------------------------------------
[2010-11-08 05:36:19] cataphract@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=305186
Log: - Fixed the filter extension accepting IPv4 octets with a leading 0
as that
belongs to the unsupported "dotted octal" representation.
- Fixed bug #53236 (problems in the validation of IPv6 addresses with
leading
and trailing :: in the filter extension).
- Fixed bug #50117 (problems in the validation of IPv6 addresses with
IPv4
addresses and ::).
------------------------------------------------------------------------
[2010-11-03 14:12:42] dominic at sayers dot cc
Oops. Example 5 is of course invalid. My mind invented a :: when there
wasn't one.
------------------------------------------------------------------------
[2010-11-03 14:08:55] dominic at sayers dot cc
The authority on text representation of IPv6 addresses is RFC 4291 (I
think).
This authority is accepted by the authors of RFC 5952 who quote RFC 3986
only in
the context of associating port numbers with IPv6 addresses.
The first three examples given are valid according to RFC 4291, but in a
form
deprecated by RFC 5952. The Robustness Principle suggests we should
accept them
from others but not generate IPv6 addresses in this form ourselves.
Therefore
validating these addresses depends on the context - are we checking to
see if we
can possibly use them or are we checking to see we are generating
absolutely
spotless addresses ourselves?
The 4th & 5th examples given are also valid according to RFC 4291. In
fact this
RFC contains an example in exactly the same format in
http://tools.ietf.org/html/rfc4291#section-2.2
As it stands all 5 examples are valid according to RFC 4291 but none of
them
complies with RFC 5952.
The RFC 5952 recommendation for them would be
a:b:c:d:e:0:1.2.3.4
::a:b:c:d:e:f
0:a:b:c:d:e:f:0
::1.2.3.4
::255.255.255.255
------------------------------------------------------------------------
[2009-11-09 23:38:34] crisp at xs4all dot nl
I checked the sourcecode for the IPv6 validation and being based on
tokenization instead of using regular expressions I think I can offer
some guidance. I don't know C very well, but this is how I'd do it in
PHP itself:
function validateIPv6($IP)
{
$len = strlen($IP);
$octets = 8;
$compressed = false;
$i = 0;
$c = $IP[0];
while ($i < $len)
{
if ($c == ':')
{
$i++;
if ($i < $len)
{
$c = $IP[$i];
if ($c == ':')
{
if (!$compressed)
{
$octets--;
$compressed = true;
$i++;
}
else
{
return false;
}
}
elseif ($i == 1)
{
return false;
}
}
else
{
return false;
}
}
if ($i < $len)
{
$n = 0;
do
{
$c = $IP[$i];
if ( ($c >= '0' && $c <= '9')
|| ($c >= 'a' && $c <= 'f')
|| ($c >= 'A' && $c <= 'F')
)
{
$n++;
$i++;
}
elseif ($c == ':')
{
if ($n < 1 || $n > 4)
return false;
break;
}
elseif ($c == '.' && validateIPv4(substr($IP, $i - $n)))
{
$octets--;
break;
}
else
{
return false;
}
}
while ($i < $len);
$octets--;
}
}
return ($octets == 0 || ($compressed && $octets > 0));
}
offcourse validateIPv4() should be fixed as well (not allow leading
zeros), and you might want to add early bail-outs like when the string
doesn't have any ':' characters, but I'll leave that all up to you
------------------------------------------------------------------------
[2009-11-09 20:53:02] crisp at xs4all dot nl
Using 5.3.2-dev almost the same results:
valid addresses marked as invalid:
a:b:c:d:e::1.2.3.4
::0:a:b:c:d:e:f
0:a:b:c:d:e:f::
invalid address marked as valid:
::01.02.03.04
So basically it resolves just one of the cases and is still far from
RFC-compliant
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=50117
--
Edit this bug report at http://bugs.php.net/bug.php?id=50117&edit=1