Re: [PATCH v2 nf-next 5/5] netfilter: nft: rt nexthop for inet family

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Sun, Oct 23, 2016 at 01:01:51PM +0800, Liping Zhang wrote:
> Hi Anders,
> 
> 2016-10-23 0:08 GMT+08:00 Anders K. Pedersen | Cohaesio <akp@cohaesio.com>:
> [...]
> > But ct_expr_update_type is only used during the netlink_delinearize
> > postprocess step, and that causes problems, when it is used in
> > combination with flow statements as described in other mail.
> 
> I think this is a bug and should be fixed.
> 
> > Would you object to dropping (i.e. kernel will not require it and
> > userspace will not include it) the NFTA_RT_FAMILY attribute for ip and
> > ip6 families, but unconditionally including it for the inet family?
> 
> After I read your and Pablo's explanation, now I'm not sure which one
> is better. :)
> 
> Maybe from this rt nexthop expression, we can get a relatively
> consistent way to handle the INET family properly, either
> explicitly add a _FAMILY_ attribute, or just like ct original saddr,
> completely handle it properly in the nft utility.

Please, use the layer 3 network context as you said. For the inet family,
we would need to bail out in case no context is available.

We can probably get rid of the _FAMILY attribute by introducing
explicit rt keys, ie.

        NFTA_RT_NH_IPV4
        NFTA_RT_NH_IPV6

I agree the _FAMILY attribute is getting ugly, specifically we don't
need this attribute with classid, so better if we can avoid it.

Thanks!