Skip Menu |
 

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

Report information
The Basics
Id: 62084
Status: resolved
Priority: 0/
Queue: Net-IP

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

Bug Information
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-------- # -*- 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::");
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>
Download (untitled) / with headers
text/plain 3.3k
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.
Download (untitled) / with headers
text/plain 735b
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 is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

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