bugzilla-daemon at netfilter.org
2013-Aug-13 01:21 UTC
[Bug 844] New: Can set apparently invalid netmask for hash:ip
https://bugzilla.netfilter.org/show_bug.cgi?id=844 Summary: Can set apparently invalid netmask for hash:ip Product: ipset Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: default AssignedTo: netfilter-buglog at lists.netfilter.org ReportedBy: quentin at armitage.org.uk Estimated Hours: 0.0 The following fails as expected: # ipset create foo hash:ip family ipv6 netmask 1 ipset v6.19: Syntax error: '1' is out of range 4-124 However, the following does not fail: # ipset create foo hash:ip netmask 1 family ipv6 # ipset add foo ffff:: # ipset list foo Name: foo Type: hash:ip Revision: 0 Header: family inet6 hashsize 1024 maxelem 65536 netmask 1 Size in memory: 16504 References: 0 Members: 8000:: Is there a reason why a netmask of 32 cannot be specified for ipv4 hash:ip sets, and also netmasks of 1,2,3,125,126,127 and 128 can't be specified for ipv6 sets? It would be very helpful for me if an ipv4 netmask of 32 and an ipv6 netmask of 128 could be specified, since I have to have code specifically not adding the netmask option if those netmasks are required. -- Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
bugzilla-daemon at netfilter.org
2013-Aug-14 14:50 UTC
[Bug 844] Can set apparently invalid netmask for hash:ip
https://bugzilla.netfilter.org/show_bug.cgi?id=844 Jozsef Kadlecsik <kadlec at netfilter.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kadlec at netfilter.org --- Comment #1 from Jozsef Kadlecsik <kadlec at netfilter.org> 2013-08-14 16:50:45 CEST --- The argument-order dependent netmask checking is fixed in bugzilla #841. As to why speficic netmask values are excluded: IPv4 32 and IPv6 128: those are identical with not spefifying the netmask at all. Technically these cases could be allowed. For IPv6 the netmasks less than 4 are not allowed because those are not user friendly in the IPv6 notation: a::/4 is OK, but do you know the boundary IPv6 addresses for a::/3? 124 is a compromise between a user friendly network and RFC3627. I believe most people would argue that 64 should be the largest value instead of 124. -- Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
bugzilla-daemon at netfilter.org
2013-Aug-14 16:00 UTC
[Bug 844] Can set apparently invalid netmask for hash:ip
https://bugzilla.netfilter.org/show_bug.cgi?id=844 --- Comment #2 from Quentin Armitage <quentin at armitage.org.uk> 2013-08-14 18:00:56 CEST --- (In reply to comment #1)> The argument-order dependent netmask checking is fixed in bugzilla #841. > > As to why speficic netmask values are excluded: > > IPv4 32 and IPv6 128: those are identical with not spefifying the netmask > at all. Technically these cases could be allowed. > >From my perspective, allowing 32 and 128 respectively would make life easier,and there doesn't seem a great reason for not allowing them. Allowing 32 I think would be easy, but allowing 128 if 125-127 are excluded is clearly not so easy the way the code is structured (but see my comment below).> For IPv6 the netmasks less than 4 are not allowed because those are not > user friendly in the IPv6 notation: a::/4 is OK, but do you > know the boundary IPv6 addresses for a::/3? >I think you've demonstrated your point very well! a::/4 and a::/3 amount to almost the same thing, i.e. ::/4 and ::/3. As for a000::/4 and a000:/3, I don't have any confusion around boundaries, and I don't see it as any different (in terms of knowing where the boundaries are) from 2001:a000::/20 and 2001:a000::/19, either of which would be allowed. As a more concrete example, I use bogon filters downloaded from www.team-cymru.org, and want to use ipsets to block them. They include ::/3, 4000::/2 and 8000::/1. Whilst I don't need to create ipset with those netmasks at the moment, it does suggest that it's not unreasonable to specify networks like that.> 124 is a compromise between a user friendly network and RFC3627. I believe > most people would argue that 64 should be the largest value instead of 124.Isn't there a difference between what one might want to filter, and what is considered valid as a network. I might, for some bizarre reason, assign all my hosts two consecutive addresses, and assuming the lower address is even, I could then identify a pair of host addresses with a /127 netmask. I might then want to build an ipset matching of number of these hosts, and so a netmask of /127 on the ipset would be useful. Since the ipset kernel code works for any length netmask, as I understand it, would it not be reasonable to let the user choose what length netmasks he wants to have, rather that taking the decision away from him? -- Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
bugzilla-daemon at netfilter.org
2013-Aug-17 19:15 UTC
[Bug 844] Can set apparently invalid netmask for hash:ip
https://bugzilla.netfilter.org/show_bug.cgi?id=844 Jozsef Kadlecsik <kadlec at netfilter.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Jozsef Kadlecsik <kadlec at netfilter.org> 2013-08-17 21:15:41 CEST --- You convinced me, I removed the restriction. The patch is pushed to the git tree. -- Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.
Reasonably Related Threads
- [Bug 841] New: Specifying netmask option when creating ipv6 hash:ip is inconsistent
- [Bug 838] New: ipset add foo syslog fails for bitmap:port
- [Bug 1139] New: The include guards on the include/libipset/linux_ip_set*.h are wrong
- [Bug 842] New: Addition of iptables rule referencing an ipset of the wrong address family does not fail
- [Bug 859] New: bitmap:port appears to be using 8 bytes of kernel memory per port, rather than 1 bit.