Edit report at http://bugs.php.net/bug.php?id=50117&edit=1
ID: 50117 Updated by: [email protected] 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] [email protected] 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
