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>
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!