[Bug 844] Can set apparently invalid netmask for hash:ip

bugzilla-daemon at netfilter.org bugzilla-daemon at netfilter.org
Wed Aug 14 18:00:57 CEST 2013


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.



More information about the netfilter-buglog mailing list