Hi Liping and Pablo,
On lør, 2016-10-22 at 09:44 +0800, Liping Zhang wrote:
> Hi Pablo,
> 2016-10-22 0:58 GMT+08:00 Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>:
> >
> > We still need datatype information for the inet family, from the
> > netlink_delinearize step, when dumping back the policy to
> > userspace.
> > Given that we cannot infer the datatype from the data size, as this
> > would be 16 bytes for both cases, we would still need to annotate
> > this
> > context information somewhere. The existing approach is providing
> > this
> > datatype information.
>
> Yes, the NFTA_RT_FAMILY attr will simplify our work, without this we
> will have much more work in nft utility.
>
> Since Anders suggests the following usage in INET family:
> # nft add rule inet filter postrouting ether type ip6 rt ip6 nexthop...
> ^^^^^^^^^^^^^
I'm considering to change the syntax to just "rt nexthop" and then
determine the family implicitly from
ctx->pctx.protocol[PROTO_BASE_NETWORK_HDR].desc (which must be set via
"ether type", "meta nfproto" or similar, when used from the inet
family) in expr_evaluate_rt() in stead of verifying it. This also seems
to be what NF_CT_SRC etc. currently does.
How does this sound?
> So I think it's better to add implict dependency rules in inet
> family:
> for rt ip nexthop: we add "meta nfproto ipv4"
> for rt ip6 nexthop: we add "meta nfproto ipv6"
>
> Then like NFT_CT_SRC do, we can implement a similar
> *ct_expr_update_type*, and call it in netlink_delinearize step.
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 agree this will add much more work in nft utility, and actually,
> use the NFTA_RT_FAMILY attr, if we did not add "ether type ip6"
> or "meta nfproto ipv6", "rt ip6 nexthop" can still work well in
> INET family.
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?
Regards,
Anders��.n��������+%������w��{.n����z�����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
