I’m very ignorant when it comes to firewalls, so please bear with me.
The reason I think that is because I assume a forward rule just forwards traffic to a given client as long as it’s adressed to that client. Is my thinking wrong?
Yes, it’s confusing to me. Do forward rules keep track of upper-layer levels too? Will they not forward a stray ICMPv6 packet, i.e. one where a prior session with the client hasn’t been established?
This isn't firewall-related. The RFC explained the IPv6 network stack.
(i.e. the actual IPv6 Protocol)
It seems so.
???
Let make sure you understand this is not firewall-related (specifically) first.
3.2.1. Internet Control and Management
Confirm, please.
I say that because it's programmed - it's nothing you can change. 
(You could probably try to play with ALLOW rules - now that you know that...but I hope you understand my point.)
i.e. iptables and nft and the stack/modules that interact with them are [should be] RFC-compliant.
I'm not sure that's the case...
Sounds pretty firewall-y to me.
I think it is a fairly reasonable question to ask whether the default firewall policies (as defined within OpenWRT) follow the recommendation set out in RFC 6092. As it currently stands it doesn't look like there's anything within the firewall which would block either an ICMPv6 "Destination Unreachable" and "Packet Too Big" packet if there isn't an existing conntrack state for the traffic. But I might be missing something...
Let's test by allowing everything 
...lol...get my point :wink-
(check the code)
Also it says:
Recommendations for filtering ICMPv6 messages in firewall devices are described separately in [RFC4890]
~ (Emphasis Added) RFC6092-3.2.1
I disagree - just on plain reading of the first sentence.
No, not really. How does questioning whether the current firewall implementation blocks certain ICMPv6 messages for traffic that doesn't have an existing conntrack state lead to a 'test by allowing everything'?
What code?
If you look at the whole sentence then it's clear the recommendation in RFC 6092 is intended to add to those made in RFC 4890. I'm not sure if you're trying to claim otherwise??
Yes, see heading of 3:
Also, see all the dialogue of another master heading,which 3.1.
It's title?
3.1. Stateless Filters
(Our firewalls are stateful, correct?)
Certain kinds of IPv6 packets MUST NOT be forwarded
~ (Emphasis Added) RFC6092-3.1
Who make sure it MUST NOT?
Confirm please.
Lastly, master heading of 3.2:
3.2. Connection-Free Filters
Some Internet applications use connection-free transport protocols with no release semantics, e.g., UDP. These protocols pose a special difficulty for stateful packet filters because most of the application state is not carried at the transport level. State records are created when communication is initiated and are abandoned when no further communication is detected after some period of time.
Maybe,more correctly, the Kernel (i.e. sysctrl).
I would respond more fully, but if I'm honest your responses make very little sense. I'm no closer to understanding what you're trying to get at then I was several responses ago.
The closest I can get is you're implying that netfilter is written to implicity drop any ICMPv6 "Destination Unreachable" and "Packet Too Big" messages that don't have a matching transport state record, regardless of any actual rules that might appear in the firewall. Which would raise the question of why RFC 4890 appears to provide specific examples of how you would construct iptables rules to only allow ICMPv6 messages when there is an existing session.
Correct, upper layer state is not taken into account.
I"ll try in points:
Exactly. RFC6092 says this (in master 3.2).
Thread linked shows common misconception between firewall and lower IP stack itself.
Because the specific recommendation in RFC 6092 expands on what is in RFC 4890 and is therefore about the firewall... If you're not grasping that then there's really nothing further to discuss.
It's not about the IP stack. It's recommendations for how you should configure residential CPE to provide for "simple security" capabilities.
Yes, within the context of filtering, i.e. firewalls... The whole point of that section is to identify they've already made recommendations about filtering ICMPv6 (in RFC 4890) so don't need to repeat it, but are adding an additional recommendation.
Anyway, @jow has already confirmed the recommendation isn't followed by OpenWRT so anything further is kinda moot.
I believe you misunderstand:
If you misunderstand, lest have a private class by PM.
iptables is a user-space utility program that allows a system administrator to configure the IP packet filter rules of the Linux kernel firewall, implemented as different Netfilter modules.
~ https://en.wikipedia.org/wiki/Iptables
nftables replaces the legacy iptables portions of Netfilter.
~ https://en.wikipedia.org/wiki/Nftables
So in simple question form - why are you trying to discussion the stateful firewall configs?
that don't match any filtering state should be dropped.
~ RFC6090-3.2.1
The state matching should be straightforward to implement (would come handy for other user rules as well) but the restriction to only allow actually delegated prefixes will be trickier, we would need to maintain some kind of set and frequently update it from netifd/odhcpd whenever something changes in the local prefix situation. Doable but a lot of work, so unlikely to happen soon. I could look into state matching though
I believe you you both grossly misunderstand. Nonetheless, I'm glad others program the lower networking stack.
@jow's discussion led you further away.
I'll try to setup devices with Wireshark in my spare time - or perhaps I'm just being unclear Anyways,all cool, all good. 
Or maybe he's claiming OpenWrt is a real firewall - by RFC definition?
Hence why the specification is not followed.
It's simply not a firewall. It's Linux/nftables.
Not sure what the OP is getting at here
You really need to go back and read what the RFC are about. And really try hard to understand this time. They are both recommendations for filtering, i.e. implementation of firewall. RFC 4890 provides recommendations for ICMPv6, RFC 6092 goes further and provides recommendations for other traffic. But they are both about firewalls.
That doesn't even make sense..
Look, we're clearly not going to come to an agreement about this. Probably best to leave this aspect of the discussion here. Let's just leave the rest of the thread to discuss what it was originally about (i.e. whether changes should be made to the firewall).
That would be useful, and even just having that state matching would probably get close to implementing the recommendation.
I edited.
I mean the developers make no such claim for it to be a firewall, do they???
I'll do that...I lat taught a class on it a few weeks ago...
It makes sense, a firewall meet specifications. Anything else, isn't.
A lot of this code is upstream,and has nothing to do with OpenWrt -nonetheless, I recall seeing no guarantee that the combination of software/packages/modules/etc. will result in all the specifications of a complaint firewall. And no single person/group could guarantee that, without (well... code).
That's all I meant.
e.g. firewalls allow no traffic by default
Great. But the RFCs are simply recommendations for what packet filters should be implemented within equipment. That's all about the rules you implement, not about the underlying code of the firewall (unless the firewall is so poorly written that any constructed rules don't do what they should). But we can rule that out as, afaik, netfilter works pretty well so it's back to just being a discussion around rules.
This whole discussion should've simply been the response @jow provided, i.e. the current implementation of rules in OpenWRT does not block the forwarding of ICMPv6 "Destination Unreachable" and "Packet Too Big" messages if there is no existing established or related state for the traffic, and therefore it doesn't follow that specific recommendation.
OK, I agree with all but this. Again, are you making reference to:
wow...
Yea again, OpenWrt.
HUMMMM....
REC-10 should only be implemented on a real firewall. Routers - are OK. I also disagree - this doesn't have to be "implemented by rule" on a firewall
I understand the confusion now.
(When I first learn OpenWrt, I was confused by others using the term "firewall" too - I've started improperly using it.)
We've come to think the same software/hardware on desktops/embedded devices are [100% identical] on these industrial devices.
Which is a default rule implemented by OpenWRT.
I'm not sure what you're getting at here. The recommendations in RFC 6092 are for Customer Premises Equipment which includes devices such as the sort of routers that people would use OpenWRT on. The RFC itself makes this clear:
The whole point of the RFC is to provide recommendations for how the firewall on such devices should be configured to function in order to provide 'simple security' capabilities.
??
I can't really believe that you don't understand, so I would say simply test a Ci$co appliance or something like that. You'll clearly see in seconds that OpenWrt isn't a firewall, nothing close.
I just beg (moreso the OP), please don't keep trying to inquire or postulate if you don't understand clearly. I (and I'm sure others) don't want their routers having issues because someone got the notion it's a firewall and removes those rules from default.
Otherwise, this seems like something for upstream and various Kernel changes. But as I noted, most exist in sysctrl/Kernel already (i.e. ICMPV6 responses are Related traffic - unrelated to the firewall entries the OP highlighted). The OpenWrt is routing/forwarding that unrelated traffic in the firewall rule.
I also noted these are stateless recommendations in the RFC - but somehow the debate continues on stateful firewall rules?
This is why I tried to highlight the sillyness of testing by making stateful firewall changes. Somehow, it was taken as some credence supporting your pont-of-view. The test would be to remove the rule, it should still work on Established traffic (hence, in code).
So then its noted (or rathar, my statements seem discounted by you) - because you see stateful rules?
I'm not sure how that's difficult or confusing (i.e. stateful vs. stateless), but I've tried my best to offer clarity. I do appreciate the level-headed collegiate discussion, but I think it's ran the course.
As I said, not sure how my statements were unclear; but nonetheless, carry on.
You missed my point (it almost seem on purpose and comical). I actually can't tell if you're j/k; but I don't beleive you'd persist if that were the case - so I wanted to respectfully formulate a coherent response to you.
Again, thanks for the scholarly discussion.
Perhaps I'm wrong, eh...it's possible too.
I'm postulating? I merely use the terminology that's used in the OpenWrt documentation where it's referred to as a firewall. I thought I made it very clear that I'm ignorant about how the firewall in OpenWrt works, and that's why I'm asking the questions I'm asking. I don't really see why there's any point in continuing this discussion as jow has pretty much settled the issue now.