nftables: How to match ICMPv6 subtype in a rule?

Hello,

I have been reading RFC 4890 and 4443, as well as nftables wiki and man page.

It is obvious how to match ICMPv6 types using 'icmpv6 type'. However, as RFC 4890 recommends, there are situations where only a specific SUBtype must be accepted, e.g. section 4.3.1:

o Time Exceeded (Type 3) - Code 0 only
o Parameter Problem (Type 4) - Codes 1 and 2 only

I have been searching for days and I can't find any info about matching ICMPv6 subtypes. ip6tables can do that (as shown in the example in the RFC) but no info about nftables. ip6tables-translate cannot translate subtype rules (it converts them to a comment).

So, what is the nftables syntax to accept only a specific subtype of an ICMPv6 type?

FWIW, I am on Debian 12:

# nft -V
nftables v1.0.6 (Lester Gooch #5)
  cli:          editline
  json:         yes
  minigmp:      no
  libxtables:   yes

As far as the ICMPv6 header is concerned, there are only types and codes.

Those are types and codes.

These are the relevant sections of the manual:

LESS=+/'ICMPV6 HEADER EXPRESSION' man nft
LESS=+'/ICMPV6 TYPE TYPE' man nft
LESS=+'/ICMPV6 CODE TYPE' man nft

However, there are some errors in the manual. One is that the ICMPV6 HEADER EXPRESSION section does not make it clear that the type/keyword for the ICMPv6 Code is "icmpv6_code", instead generically describing it as "integer (8 bit)". Another is that it erroneously documents the keyword for the ICMPv6 Type as being "icmpx_code" in the ICMPV6 CODE TYPE section.

Anyway, the syntax is:

icmpv6 type <icmpv6_type> # where <icmpv6_type> is any valid ICMPV6 TYPE value icmpv6 code <icmpv6_code> # where <icmpv6_code> is any valid ICMPV6 CODE value

Both of this header expressions may be combined within a single rule. All of the possible values are documented by the aforementioned sections of the manual. Alternatively, you may ask for nft(8) to print out the supported values for you.

# nft describe icmpv6_type
# nft describe icmpv6_code

Kerin Millar

Thanks for clarifying.

I actually found the magic word "code" after posting here but I still wanted to wait for a reply. Yours explained it perfectly. I suppose I have been confused by reading too much from different sources :)

Have those been reported anywhere?

Having such possibility is interesting, as the integer code has different meaning depending on the type, i.e. it has no meaning per se and it looks strange to filter based on it only. I thought they must go "hand in hand" but obviously not. I wonder what purpose such filtering may serve.

In that sense, the output of:

is somewhat confusing (e.g. compare type 1 and type 3 or 4 in RFC 4443).

I'll open a bug.

Yes, indeed. It seems that the symbolic names were selected under the presumption that they would be most convenient for the common case - probably with the reject keyword in mind. Come to think of it, that's probably why the manual does not reference the icmpv6_code type in the ICMPV6 HEADER EXPRESSION section. Fortunately, there is always the option to specify an arbitrary integer value.

Kerin Millar

Thanks Kerin!

On Sun, Mar 31, 2024 at 07:34:07PM +0100, Kerin Millar wrote:
[...]

If you agree with this, I will save you from filing up a ticket:

https://patchwork.ozlabs.org/project/netfilter-devel/patch/[email protected]/

otherwise, let me know, I can post a v2.

Thanks for reporting.

Is it possible to have proper symbolic naming ('describe') of codes depending on type too? (as per RFC 4443)

I also notice there are some types that don't even have a corresponding name (e.g. 139, 140).

ip6tables-translate does not translate codes either.

Has that been reported/considered?

Speaking of all that:

I have managed to "translate" the whole Appendix B of RFC 4890. However, I am not quite sure how complete the appendix itself is, because:

- it does not address the recommendations given regarding hop limits
- I have found one bug (so far) in that same appendix

I wonder if it would be appropriate to contact the email addresses given at the end of the RFC itself. What do you think?

Considering the importance of correct secure handling of ICMPv6, it would be great to have an example on wiki.nftables.org showing a proper implementation of RFC 4890.

This is not yet done. Add it to bugzilla as a feature request I'd suggest.

I believe the existing ICMP types are based on iptables, and it seems iptables does not include those.

There is icmp6_type_tbl in src/proto.c that can be extended, better to use definitions available in icmp.h if available.

What iptables version are you using?

$ ip6tables-translate -I INPUT -m icmpv6 --icmpv6-type destination-unreachable
nft 'insert rule ip6 filter INPUT icmpv6 type destination-unreachable counter'

What bug?

# iptables -V
iptables v1.8.9 (nf_tables)

What you show works for me too, but e.g. this does not:

# ip6tables-translate -I INPUT -m icmpv6 --icmpv6-type ttl-zero-during-transit
nft # -I INPUT -m icmpv6 --icmpv6-type ttl-zero-during-transit

If you replace 'ip6tables' with 'ip6tables-translate' in the RFC example and run the whole script you will see the rest which don't translate.

For example, in section "TIME EXCEEDED ERROR MESSAGES", right after the comment saying:

# Allow incoming time exceeded code 0 messages

# only for existing sessions

the actual rules handle 'packet-too-big' (type 2), not 'time-exceeded' (type 3) with code 0, as recommended in section 4.3.1 and as it claims. The 'else' condition right after it does not do what it should either. As a result, type 3 (which is in the "must" section 4.3.1) seems not handled anywhere.

There is also some meaningless code, e.g. the loop around the 'bad-header'. Etc.