netfilter buglog - Aug 2013 - [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.

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.

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.

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.