Mailing List Archive

revisit: ipset nethash set type limited to /31
Hi,

(Original post on netfilter@lists.netfilter.org:
https://lists.netfilter.org/pipermail/netfilter/2007-August/069497.html)

My employer has an interest in having enhancing the functionality of
netfilter/trunk/ipset/ipset_nethash.c with the 2.6.18+ kernels and is
exploring the possibility of sponsoring a netfilter developer to make
this happen.

As ipset_nethash.c stands it handles subnet masks from /1 to /31 fine,
but the cases /0 & /32 are required to be handled in a different chain.
unifying these would vastly simplify and reduce our rules. And reduce
the delay it takes to update some rule sets. Is there anyone interested
in doing this?

There has been some previous discussion on this in March last year:
http://lists.netfilter.org/pipermail/netfilter/2006-March/065088.html
http://lists.netfilter.org/pipermail/netfilter/2006-March/065090.html

In particular:
http://lists.netfilter.org/pipermail/netfilter/2006-March/065091.html
This explains that the IPAddr & Mask is stored in 32 bits, leaving no
room for /0 & /32.

http://lists.netfilter.org/pipermail/netfilter/2006-March/065130.html
Jozsef suggested a potentially alternative method of a "union" set type.
Did anyone manage to implement this new type?

We are still wondering about the /0 & /32 "subnets". /0 could be handled
as a special case, if the IPAddr & Mask was allowed to use more then 4
bytes, eg 5. Then at the cost of 25% more memory in the hash we could
in some cases half the number of netfilter entries.

If it helps, we also have resources available to test development versions
of the ipset_nethash.c

ThanX
Neville Dempsey
Developer @ NetBox Blue (http://netboxblue.com)
Re: revisit: ipset nethash set type limited to /31 [ In reply to ]
On Aug 17 2007 16:54, Neville C. Dempsey wrote:
>
>As ipset_nethash.c stands it handles subnet masks from /1 to /31 fine,
>but the cases /0 & /32 are required to be handled in a different chain.

/0 is not a network anymore, it is "everything".
/32 is a single host, I think iphash is better suited for this.
Or perhaps even use fullipmap
[https://lists.netfilter.org/pipermail/netfilter-devel/2007-August/029066.html]


Jan
--
Re: revisit: ipset nethash set type limited to /31 [ In reply to ]
On Fri, 17 Aug 2007, Jan Engelhardt wrote:

>
> On Aug 17 2007 16:54, Neville C. Dempsey wrote:
>>
>> As ipset_nethash.c stands it handles subnet masks from /1 to /31 fine,
>> but the cases /0 & /32 are required to be handled in a different chain.
>
> /0 is not a network anymore, it is "everything".
> /32 is a single host, I think iphash is better suited for this.
As long you don't need to handle both networks and host in the same set.
If you do then you end up with double number of sets (eg. 400 instead of
200) and more complicated iptables rules.

Best regards,

Krzysztof Oledzki
Re: revisit: ipset nethash set type limited to /31 [ In reply to ]
* Krzysztof Oledzki wrote, On 17/08/07 14:03:
>
>
> On Fri, 17 Aug 2007, Jan Engelhardt wrote:
>
>>
>> On Aug 17 2007 16:54, Neville C. Dempsey wrote:
>>>
>>> As ipset_nethash.c stands it handles subnet masks from /1 to /31 fine,
>>> but the cases /0 & /32 are required to be handled in a different chain.
>>
>> /0 is not a network anymore, it is "everything".
>> /32 is a single host, I think iphash is better suited for this.
> As long you don't need to handle both networks and host in the same set.
> If you do then you end up with double number of sets (eg. 400 instead of
> 200) and more complicated iptables rules.
>
> Best regards,


I think we could have an extra byte per 8 entries, and they can take 1
bit each, giving 33 bit hash entries.

Its the sanest way.

the /0 entry can just be a single flag per hash, as there is only one of
them.

Sam
Re: revisit: ipset nethash set type limited to /31 [ In reply to ]
* Krzysztof Oledzki wrote, On 17/08/07 14:03:
>
>
> On Fri, 17 Aug 2007, Jan Engelhardt wrote:
>
>>
>> On Aug 17 2007 16:54, Neville C. Dempsey wrote:
>>>
>>> As ipset_nethash.c stands it handles subnet masks from /1 to /31 fine,
>>> but the cases /0 & /32 are required to be handled in a different chain.
>>
>> /0 is not a network anymore, it is "everything".
>> /32 is a single host, I think iphash is better suited for this.
> As long you don't need to handle both networks and host in the same set.
> If you do then you end up with double number of sets (eg. 400 instead of
> 200) and more complicated iptables rules.
>
> Best regards,


I think we could have an extra byte per 8 entries, and they can take 1
bit each, giving 33 bit hash entries.

Its the sanest way.

the /0 entry can just be a single flag per hash, as there is only one of
them.

Sam