extensions: libip6t_mh: Add translation to nft

Add translation for mobility header to nftables.

Examples:

$ sudo ip6tables-translate -A INPUT -p mh -j ACCEPT
nft add rule ip6 filter INPUT ip6 nexthdr mobility-header counter accept

$ sudo ip6tables-translate -A INPUT -p mh --mh-type 1 -j ACCEPT
nft add rule ip6 filter INPUT ip6 nexthdr mobility-header mh type 1 counter accept

$ sudo ip6tables-translate -A INPUT -p mh --mh-type 1:3 -j ACCEPT
nft add rule ip6 filter INPUT ip6 nexthdr mobility-header mh type 1-3 counter accept

---
 extensions/libip6t_mh.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

index 686a293..55ce028 100644
@@ -202,6 +202,26 @@ static void mh_save(const void *ip, const struct xt_entry_match *match)
 		printf(" --mh-type %u", mhinfo->types[0]);
 }
 
+static int mh_xlate(const struct xt_entry_match *match,
+		    struct xt_buf *buf, int numeric)
+{
+	const struct ip6t_mh *mhinfo = (struct ip6t_mh *)match->data;
+
+	if (mhinfo->types[0] == 0 && mhinfo->types[1] == 0xFF)
+		return 0;
+
+	if (mhinfo->types[0] != mhinfo->types[1])
+		xt_buf_add(buf, "mh type%s %u-%u ",
+			   mhinfo->invflags & IP6T_MH_INV_TYPE ? " !=" : "",
+			   mhinfo->types[0], mhinfo->types[1]);
+	else
+		xt_buf_add(buf, "mh type%s %u ",
+			   mhinfo->invflags & IP6T_MH_INV_TYPE ? " !=" : "",
+			   mhinfo->types[0]);
+
+	return 1;
+}
+
 static const struct xt_option_entry mh_opts[] = {
 	{.name = "mh-type", .id = O_MH_TYPE, .type = XTTYPE_STRING,
 	 .flags = XTOPT_INVERT},

@@ -220,6 +240,7 @@ static struct xtables_match mh_mt6_reg = {
 	.print		= mh_print,
 	.save		= mh_save,
 	.x6_options	= mh_opts,
+	.xlate		= mh_xlate,
 };
 
 void _init(void)

1.9.1

I think this translation will not work as the mobility header may not be exactly the next header, in IPv6 you can get several extension headers one after another.

By now I'd suggest:

... meta l4proto mobility-header mh type 1 counter

Anyway, the extension header expression needs some care, it would be good to keep this documented in the wiki page.

While at this, it would be good if you can verify that our definition in nftables matches rfc6275 (see nftables/src/exthdr.c), I already detected wrong header definitions in the past.

It would be also good if you can go back to all your translations and validate what we already got into the tree from the packet path, ie. generate traffic that matches the rule in ip6tables and nftables. Note sure if you made this checks.

Some of them should be easy to test, some other may take a while, python scapy may help in some cases to forge and to inject a packet with a specific layout.

Thanks.