incorrect. In the iptables machinery there is a table called the forwarding table. Every packet that the router determines needs routing hits the forwarding table and can be inspected before forwarding. This is where the firewall makes decisions about forwarded packets.
I think looking at your original question though you're asking about why are there input rules allowing ICMP to hit the router itself? And the answer is that the router may need to do things like download packages, do DNS lookups, solicit NTP information, or even just perform speed tests. So, it needs to get ICMP messages that tell it for example that it's sending packets too big, sending to unreachable destinations, it needs to hear router advertisements, it needs to hear neighbor advertisements, etc. How can it find out about its upstream router if it can't hear the RAs and can't find out how to send to the upstream router's link local interface if it can't do neighbor discovery etc. I don't think these are "connection tracked" when they come directly from the router, though they may be conntracked when they're forwarded by the router.
I am afraid we would disagree on that - it does not require packet inspection (firewall) for a router to function since routing is handled through the kernel's Forwarding Information Base (FIB - routing tables).
ipt tables are not part of the FIB but instead being userland to utilise the kernel's netfilter for packet inspection.
For me it boils down to the question how the firewall determines which packet is input and which is forward - does it consult the FIB for that purpose?
After ingress, if the packet isn't bridged, then it goes to prerouting raw firewall table, then through conntrack, prerouting mangle, prerouting nat, and there's a routing decision (consult the FIB) if it's going to be routed then you hit forwarding mangle, forwarding filter, postrouting mangle, postrouting nat, and then out towards egress... (this is for iptables, nftables is somewhat different, it has the same kinds of hooks but you can have many tables hooked in at each hook)
What I just figured is that with ct state 2,4 accept enabled in the forward chain
icmpv6 types 1 | 2 | 3 | 4 | 128
reached the downstream clients despite the explicit forwarding rule being disabled.
Whilst the protocol being stateless it seems that conntrack is adding an entry to its table on packet egress with state [UNREPLIED] and if receiving a response from the remote host within a given time frame changes the state to [ASSURED].
With the ct hook priority -200 in nf it is then processed prior the filter hook with its priority of 0
