php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #53236 IPv6 address validation error
Submitted: 2010-11-03 15:59 UTC Modified: 2010-11-08 05:40 UTC
From: dominic at sayers dot cc Assigned: cataphract (profile)
Status: Closed Package: Filter related
PHP Version: 5.3.3 OS: All
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: dominic at sayers dot cc
New email:
PHP Version: OS:

 

 [2010-11-03 15:59 UTC] dominic at sayers dot cc
Description:
------------
IPv6 addresses with a single abbreviated field are being validated 
inconsistently.

For example the following IPv6 address is marked as valid:

    1::2:3:4:5:6:7

but the following two IPv6 addresses are marked as invalid:

    ::1:2:3:4:5:6:7
    1:2:3:4:5:6:7::

How should they be validated? The authority on the text representation of IPv6 
addresses is RFC 4291, which allows all three examples. However the recently-
published RFC 5952 deprecates a format where a single field is abbreviated in 
this way, although it clearly states that such addresses must be accepted if 
presented. RFC 5952 defines a recommended formatting for *outputting* IPv6 
addresses, not for validating incoming ones.

RFC 3986 also allows this syntax, but RFC 5321 does not (although like RFC 5952 
it acknowledges the ultimate authority of RFC 4291).

The point of this bug report, however, is to point out the inconsistent 
validation of these addresses.

I believe they should all be allowed (as per RFCs 4291 and 3986). Warning: this 
might result in filter_var allowing some email addresses that have IPv6 address 
literals that are OK according to RFC 4291 but not RFC 5321.

Test script:
---------------
<?php
function isIP($address) {
  $valid = filter_var($address, FILTER_VALIDATE_IP);
  echo "$address is", ($valid ? '' : ' not'), ' valid<br/>';
}

isIP('1:2:3::4:5:6:7');
isIP('::1:2:3:4:5:6:7');
isIP('1:2:3:4:5:6:7::');
?>

Expected result:
----------------
1:2:3::4:5:6:7 is valid
::1:2:3:4:5:6:7 is valid
1:2:3:4:5:6:7:: is valid

Actual result:
--------------
1:2:3::4:5:6:7 is valid
::1:2:3:4:5:6:7 is not valid
1:2:3:4:5:6:7:: is not valid

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-11-08 05:36 UTC] cataphract@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&amp;revision=305186
Log: - Fixed the filter extension accepting IPv4 octets with a leading 0 as that
  belongs to the unsupported &quot;dotted octal&quot; 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-08 05:40 UTC] cataphract@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: cataphract
 [2010-11-08 05:40 UTC] cataphract@php.net
This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Fixed for PHP 5.3 and trunk.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 17:01:29 2024 UTC