Skip Menu |

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

Report information
The Basics
Id: 80429
Status: resolved
Worked: 2.2 hours (131 min)
Priority: 0/
Queue: NetAddr-IP

People
Owner: Nobody in particular
Requestors: quanah.gibsonmount [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 4.062
Fixed in: (no value)



Subject: NetAddr::IP can't handle IPv6 addresses
Found when using sa-learn with NetAddr::IP v4.062: zimbra@zre-ldap002:~$ /opt/zimbra/libexec/sa-learn -p /opt/zimbra/conf/sa/salocal.cf --dbpath /opt/zimbra/data/amavisd/.spamassassin -L --no-sync --siteconfigpath /opt/zimbra/conf/spamassassin --spam /tmp/q.spam netset: cannot include 127.0.0.0/8 as it has already been included netset: illegal network address given: '[::1]/128' netset: illegal network address given: '[fc00:10:137:242::]/64' netset: illegal network address given: '[fe80::%eth0]/64' Learned tokens from 0 message(s) (0 message(s) examined) netset uses NetAddr::IP to validate the addresses provided. This is similar to the report in https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6681
There is not enough information in the bug report or the related spamassassin bug page to identify a problem. Current version 4.065 (and previous versions) handle the addresses mentioned in the bug report just fine as far as I can tell. Specific code or test program information is needed to identify possible issues with NetAddr::IP. How about providing the test code from SA that is failing?? Absent some additional information, this bug report is stalled. Simple test below runs fine. use diagnostics; use strict; use NetAddr::IP; # version = NetAddr-IP-4.065 my @addrs = (qw( 127.0.0.0/8 ::1/128 fc00:10:137:242::/64 fe80::/64 )); foreach (@addrs) { my $ip = new NetAddr::IP($_); print $ip,"\n"; } Result: 127.0.0.0/8 0:0:0:0:0:0:0:1/128 FC00:10:137:242:0:0:0:0/64 FE80:0:0:0:0:0:0:0/64
On Fri Oct 26 21:53:21 2012, MIKER wrote: Show quoted text
> There is not enough information in the bug report or the related > spamassassin bug page to identify a problem.
It turns out it is a bug in SpamAssassin failing to strip the []'s in some cases. Although I'm curious why NetAddr::IP doesn't do this itself, given it is a fairly common method of expressing IPv6 address space.
On Sun Oct 28 15:56:30 2012, MISHIKAL wrote: Show quoted text
> On Fri Oct 26 21:53:21 2012, MIKER wrote:
> > There is not enough information in the bug report or the related > > spamassassin bug page to identify a problem.
> > It turns out it is a bug in SpamAssassin failing to strip the []'s in > some cases. Although I'm curious why NetAddr::IP doesn't do this > itself, given it is a fairly common method of expressing IPv6 address
space. Show quoted text
>
NetAddr::IP implements IPv6 addressing as specified in RFC's 2373, 2732, 3513, etc... these are the "standards" set forth. Custom text representations of IPv6 addressing for individual applications are not covered.
On Mon Oct 29 14:20:03 2012, MIKER wrote: Show quoted text
> NetAddr::IP implements IPv6 addressing as specified in > RFC's 2373, 2732, 3513, etc... these are the "standards" set forth. > Custom text representations of IPv6 addressing for individual > applications are not covered.
https://tools.ietf.org/html/rfc3986 is an RFC standard for as well. It specifically notes: 3.2.2. Host The host subcomponent of authority is identified by an IP literal encapsulated within square brackets, [...snip...] A host identified by an Internet Protocol literal address, version 6 [RFC3513] or later, is distinguished by enclosing the IP literal within square brackets ("[" and "]"). So I would say that []'s are indeed part of the standards governing IPv6 addresses. There is also http://tools.ietf.org/html/rfc4038, which is informational, but still quite detailed in the use of brackets with IPv6 addresses. --Quanah
On Mon Oct 29 15:06:37 2012, MISHIKAL wrote: Show quoted text
> On Mon Oct 29 14:20:03 2012, MIKER wrote: >
> > NetAddr::IP implements IPv6 addressing as specified in > > RFC's 2373, 2732, 3513, etc... these are the "standards" set forth. > > Custom text representations of IPv6 addressing for individual > > applications are not covered.
> > https://tools.ietf.org/html/rfc3986 is an RFC standard for as well. It > specifically notes: > > 3.2.2. Host > > > The host subcomponent of authority is identified by an IP literal > encapsulated within square brackets, > > [...snip...] > > A host identified by an Internet Protocol literal address, version 6 > [RFC3513] or later, is distinguished by enclosing the IP literal > within square brackets ("[" and "]"). > > > So I would say that []'s are indeed part of the standards governing IPv6 > addresses. > > There is also http://tools.ietf.org/html/rfc4038, which is > informational, but still quite detailed in the use of brackets with IPv6 > addresses. > > > > --Quanah
Ahhh.... interesting. Haven't seen 3986. Thanks for bringing it to my attention. I've implemented the recognition of [ipV6_string] host URI as described in the RFC in version 4.066 which I just uploaded to CPAN. Best regards, Michael
On Mon Oct 29 16:50:18 2012, MIKER wrote: Show quoted text
> Ahhh.... interesting. Haven't seen 3986. Thanks for bringing it to my > attention. I've implemented the recognition of [ipV6_string] host URI as > described in the RFC in version 4.066 which I just uploaded to CPAN.
Awesome thanks!
On Mon Oct 29 16:54:41 2012, MISHIKAL wrote: Show quoted text
> On Mon Oct 29 16:50:18 2012, MIKER wrote: >
> > Ahhh.... interesting. Haven't seen 3986. Thanks for bringing it to my > > attention. I've implemented the recognition of [ipV6_string] host URI as > > described in the RFC in version 4.066 which I just uploaded to CPAN.
> > Awesome thanks!
changed from open to resolved