This queue is for tickets about the Net-IP CPAN distribution.

Report information
The Basics
Id:
62084
Status:
resolved
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
Test [...] globis.net
Cc:
AdminCc:

BugTracker
Severity:
(no value)
Broken in:
(no value)
Fixed in:
(no value)



Subject: Mishandling of valid IPv6 address in ip_is_ipv6
Date: Tue, 12 Oct 2010 19:08:29 +0200
To: bug-Net-IP@rt.cpan.org
From: Test <Test@globis.net>
I have been building my own IPv6 libraries on top of Net::IP. Thanks very much for the basis.

I think I have found a bug in the Net::IP library during my testing.

The subroutine ip_is_ipv6 seems to be incorrectly handling prefixes where the last valid hexseq of 4 hex digits of 0000 is replaced by "::". That in turn is messing up address expansion as it cannot determine what sort of address it is (v4 or v6).

Quoting rfc3513
 The use of "::" indicates one or more groups of 16 bits of zeros.
      The "::" can only appear once in an address.  The "::" can also be
      used to compress leading or trailing zeros in an address.
Here's my test harness. The last test gives the unexpected result.

I would expect that the string "2001:2:3:4:5:6:7::" is a valid IPv6 address and represents the expanded address prefix "2001:0002:0003:0004:0005:0006:0007:0000" but the routine currently returns undef, as it seems to be getting confused about the last trailing colon. Haven't worked out exactly why yet, but I thought I'd report it to see what you thought about this.

Wouldn't it potentially be better to use the regexp IPv6_re from Regexp::IPv6 that includes the full grammar from rfc2373?

-------002_base.t--------

Show quoted text
# -*- perl -*-

Show quoted text
# t/002_base.t - test base routines
use strict;
use warnings;

use Test::More qw(no_plan);

BEGIN { use_ok( 'Net::IP' ); }

my $expected;
my $address

use Net::IP qw(ip_is_ipv6);
$address=ip_is_ipv6('2001:2:3:4:5:6:7:8');
$expected=1;
is ($address,$expected,"Check ipv6 unicast 2001:2:3:4:5:6:7:8");
$address=ip_is_ipv6('::1');
$expected=1;
is ($address,$expected,"Check ipv6 loopback ::1");
$address=ip_is_ipv6('2001:2:3:4:5:6:7:8:9');
$expected=0;
is ($address,$expected,"Check invalid ipv6 unicast 2001:2:3:4:5:6:7:8:9 = too long");
$expected=0;
is ($address,$expected,"Check invalid ipv6 unicast 2001:2::3:4::5:6 = 2 sets of colons");
$address=ip_is_ipv6('2001:2:3:4:5:6::');
$expected=1;
is ($address,$expected,"Check ipv6 unicast prefix 2001:2:3:4:5:6::");
$address=ip_is_ipv6('2001:2:3:4:5:6:7::');
$expected=1;
is ($address,$expected,"Check ipv6 unicast prefix 2001:2:3:4:5:6:7::");
Subject: Re: [rt.cpan.org #62084] AutoReply: Mishandling of valid IPv6 address in ip_is_ipv6
Date: Wed, 13 Oct 2010 09:09:27 +0200
To: bug-Net-IP@rt.cpan.org
From: Test <Test@globis.net>
Bugs in Net-IP via RT wrote:
Show quoted text
Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
	"Mishandling of valid IPv6 address in ip_is_ipv6", 
a summary of which appears below.

There is no need to reply to this message right now.  Your ticket has been
assigned an ID of [rt.cpan.org #62084].  Your ticket is accessible
on the web at:

    https://rt.cpan.org/Ticket/Display.html?id=62084

Please include the string:

         [rt.cpan.org #62084]

in the subject line of all future correspondence about this issue. To do so, 
you may reply to this message.

                        Thank you,
                        bug-Net-IP@rt.cpan.org

-------------------------------------------------------------------------
I have been building my own IPv6 libraries on top of Net::IP. Thanks 
very much for the basis.

I think I have found a bug in the Net::IP library during my testing.

The subroutine ip_is_ipv6 seems to be incorrectly handling prefixes 
where the last valid hexseq of 4 hex digits of 0000 is replaced by "::". 
That in turn is messing up address expansion as it cannot determine what 
sort of address it is (v4 or v6).

Quoting rfc3513

  The use of "::" indicates one or more groups of 16 bits of zeros.
       The "::" can only appear once in an address.  The "::" can also be
       used to compress leading or trailing zeros in an address.

Here's my test harness. The last test gives the unexpected result.

I would expect that the string "2001:2:3:4:5:6:7::" is a valid IPv6 
address and represents the expanded address prefix 
"2001:0002:0003:0004:0005:0006:0007:0000" but the routine currently 
returns undef, as it seems to be getting confused about the last 
trailing colon. Haven't worked out exactly why yet, but I thought I'd 
report it to see what you thought about this.

Wouldn't it potentially be better to use the regexp IPv6_re from 
Regexp::IPv6 that includes the full grammar from rfc2373?

-------002_base.t--------

# -*- perl -*-

# t/002_base.t - test base routines
use strict;
use warnings;

use Test::More qw(no_plan);

BEGIN { use_ok( 'Net::IP' ); }

my $expected;
my $address

use Net::IP qw(ip_is_ipv6);
$address=ip_is_ipv6('2001:2:3:4:5:6:7:8');
$expected=1;
is ($address,$expected,"Check ipv6 unicast 2001:2:3:4:5:6:7:8");
$address=ip_is_ipv6('::1');
$expected=1;
is ($address,$expected,"Check ipv6 loopback ::1");
$address=ip_is_ipv6('2001:2:3:4:5:6:7:8:9');
$expected=0;
is ($address,$expected,"Check invalid ipv6 unicast 2001:2:3:4:5:6:7:8:9 
= too long");
$expected=0;
is ($address,$expected,"Check invalid ipv6 unicast 2001:2::3:4::5:6 = 2 
sets of colons");
$address=ip_is_ipv6('2001:2:3:4:5:6::');
$expected=1;
is ($address,$expected,"Check ipv6 unicast prefix 2001:2:3:4:5:6::");
$address=ip_is_ipv6('2001:2:3:4:5:6:7::');
$expected=1;
is ($address,$expected,"Check ipv6 unicast prefix 2001:2:3:4:5:6:7::");

  

My mistake. Apparently the standards have been updated. According to http://tools.ietf.org/html/rfc5952#section-4

4.2.2. Handling One 16-Bit 0 Field

The symbol "::" MUST NOT be used to shorten just one 16-bit 0 field. For example, the representation 2001:db8:0:1:1:1:1:1 is correct, but 2001:db8::1:1:1:1:1 is not correct. My test is therefore incorrect and the library is fine.

On Wed Oct 13 03:09:45 2010, Test@globis.net wrote:
Show quoted text
> My mistake. Apparently the standards have been updated. According to > http://tools.ietf.org/html/rfc5952#section-4 > > > 4.2.2. Handling One 16-Bit 0 Field > > > The symbol "::" MUST NOT be used to shorten just one 16-bit 0 > field. > For example, the representation 2001:db8:0:1:1:1:1:1 is correct, > but > 2001:db8::1:1:1:1:1 is not correct.
I do read it that you shouldn't compact this way. Still, to be compliant with the previous RFC it should be recognized as valid input. With a bit of a brute force made the library to behave like that - accept trailing :: for one nibble, but compact only two or more nibbles. Thanks for the report and tests!


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.