Suricata

cf paper https://www.scitepress.org/Papers/2019/78401/78401.pdf
cf S-V test https://github.com/OISF/suricata-verify/pull/172

flood advertise6 is interesting.
It is a pure DOS : just send many spoofed messages so that Suricata allocates many ressources when the attacker
As they are spoofed, we cannot see they if share the same origin, the only similarity being that they are icmpv6.type == 136

What could we do about it ?
We already have flow.memcap, but as for denial6-6, we may want to give up on those attacking flows rather than on the real ones.
Maybe we can have the flows timeout/cleanup try to pick first the flows with only one packet (from only one side)
We could also try to alert about this flood attack, trying to get data to have a flamegraph to visualize all the flows (IPv6 vs IPv4, TCP vs UDP, vs ICP, etc...)

Same goes for other flood attacks.

Beyond flooding Suricata, we should also think about if these flooding attacks are a DOS against another equipment such as a router (maybe MLD messages do this)

flood_rs6 does not seem a concern (only one flow with the same packet over and over again)