Re: [RFC PATCH nf-next] netfilter: conntrack: add support for storing DiffServ code-point as CT mark.

[Florian Westphal <fw@strlen.de>]

Jeremy Sowden <jeremy@azazel.net> wrote:
> "ct dscpmark" is a method of storing the DSCP of an ip packet into the
> conntrack mark.  In combination with a suitable tc filter action
> (act_ctinfo) DSCP values are able to be stored in the mark on egress and
> restored on ingress across links that otherwise alter or bleach DSCP.
> 
> This is useful for qdiscs such as CAKE which are able to shape according
> to policies based on DSCP.
> 
> Ingress classification is traditionally a challenging task since
> iptables rules haven't yet run and tc filter/eBPF programs are pre-NAT
> lookups, hence are unable to see internal IPv4 addresses as used on the
> typical home masquerading gateway.
> 
> The "ct dscpmark" conntrack statement solves the problem of storing the
> DSCP to the conntrack mark in a way suitable for the new act_ctinfo tc
> action to restore.

Yes, but if someone else wants to store ip saddr or udp port or ifindex
or whatever we need to extend this again.

nft should be able to support:

nft add rule inet filter forward ct mark set ip dscp

(nft will reject this because types are different).

Same for

nft add rule inet filter forward ct mark set ip dscp << 16

(nft will claim the shift is unsupported for a 8 bit type).

We need a cast operator for this.  Something like

nft add rule inet filter forward ct mark set typeof(ct mark) ip dscp

or anything else that tells the parser that we really want the diffserv
value to be assigned to a mark type.

As far as I can see, no kernel changes would be reqired for this.

A cheap starting point would be to try to get rid of the sanity test
and make nft just accept the right-hand-side of 'ct mark set',
then see how to best add an 'do this anyway' override in the grammar.

I have older patches that adds a 'typeof' keyword for set definitions,
maybe it could be used for this casting too.