> 2) (assuming #1) I believe we would have to put a condition to check the set
> type versus the nlattr type, and allow a size difference on
> set(inet_addr)/set_elem(ipv4_addr) (I don't know if that has any
> ramifications).
The kernel doesn't know what an ipv4 or ipv6 address is.
It only knows the total key size. In case of nft_set_pipapo.c its also
told the sizes of the individual subkeys. (e.g. ipv4_addr .
inet_service -> 4 . 4, ipv6_addr . ip_protocol -> 16 . 4).
Maybe it would be possble to xlate ipv4 addresses to ipv6 mapped
addresses, but that would still require expansion in userland, because
ip saddr @foo
ip6 saddr @foo
cannot work. We'd need to rewrite it to something like
meta nfproto ipv4 {
reg32_1 = 0xffffffff
reg32_2 = 0xffffffff
reg32_3 = 0xffffffff
reg32_4 = ip saddr
lookup @foo sreg32_1
}
meta nfproto ipv6 ip6 saddr @foo
I don't think its worth the pain. Also because then ipv4 becomes
indistinguishable from on-wire mapped addresses.
> Another possible approach would be to create an API to transmit valid size
> types for a set type from userland. We would still need to ID the set type,
> and that has the above problems of set.ktype.
There are different sets, yes, but none of these sets support a
particular data type. They don't know what that is, the datatype is a
userspace thing and its only stored in the kernel so that 'nft list
ruleset' and friends know how to pretty-print the octet soups stored in
the set. Its not related to matching.
