Use symbolic ICMP types in MLD rule

[jonathanunderwood]

Symbolic ICMP types for MLD were added in commit e6e82a5. This commit updates the config file to use them.

[jonathanunderwood]

@jow- unsure if this needs tests updates, but I am struggling to parse the tests - any pointers much appreciated.

[brada4]

Build and install ucode and run sh script in top level.

[jonathanunderwood]

@jow- any chance we can get this merged for 24.10?

[brada4]

Readback via nft gives numbers (but your patch is correct)

[jonathanunderwood]

@jow- would be great if we could get this into 24.10 (now on rc4) - it's a minimal change and has been working fine for me locally.

[brada4]

Does it work with firewall3?

[CallMeR]

From rfc4890 - Recommendations for Filtering ICMPv6 Messages in Firewalls

4.3. Recommendations for ICMPv6 Transit Traffic

4.3.3. Traffic That Will Be Dropped Anyway -- No Special Attention Needed

Link-local multicast receiver notification messages (must have link-local source address):
o Listener Query (Type 130)
o Listener Report (Type 131)
o Listener Done (Type 132)
o Listener Report v2 (Type 143)

4.4. Recommendations for ICMPv6 Local Configuration Traffic

4.4.1. Traffic That Must Not Be Dropped

Link-Local Multicast Receiver Notification messages:
o Listener Query (Type 130)
o Listener Report (Type 131)
o Listener Done (Type 132)
o Listener Report v2 (Type 143)

According to the content of this document, it seems that these types of ICMP packets coming from the WAN can be safely dropped. On the other hand, for packets coming from the LAN, they need to remain in the Accept state. However, since the current firewall policy allows all traffic from the LAN, there is no issue.