CiotBSD
Some communication problems here, but thank you for that response. More food for thought that has me digging even deeper into my position!
I mainly I would like to respond to two things for the wider audiences on BSD Security, which is my primary focus, being on OpenBSD and a Cybersecurity Professional.
1) The IETF was a Federal Entity and then was Transferred to ISOC, The "Internet Society" with offices in Reston, Virginia, U.S., and Geneva, Switzerland. Read between the lines on that one!
Also try not to cry about this factoid from Wikipedia RE: ISOC:
Support to United Nations Internet Governance Initiative
The ubiquity of the Internet in modern-day society has prompted António Guterres, the United Nations Secretary-General to convene a panel of professional experts to discuss the future of the Internet and the role of the Internet in globalized digital cooperation. Three models were proposed after several rounds of discussion, i.e. a Digital Commons Architecture (DCA), a Distributed Co-Governance Architecture (CoGov), and a reformed Internet Governance Forum (IGF+). As of October 2020, the ISOC is leading and facilitating the multi-round meetings for Stakeholders’ Dialogue to collect, compile, and submit the inputs of the worldwide professionals and experts for future governance of the Internet.[28]
The draft you mentioned was written in 2006 and ISOC's track record on "security" is like The Pink Panther, meaning well, but wrecking everything along the way. A simple Github Search for ICMP, Security Topic will bring up lots of exploits like this one using "safe" neighborhood discovery.
Then there is the IETF from Geneva Switzerland documentation which is mostly, a niche perspective and imo, is not a valid voice in Cybersecurity, but simply concerned with at best, robust operation of the internet, and at worst, Inspector Clouseau.
Let's look at the full IETF 2006 statement.
3.1. Denial of Service Attacks
ICMPv6 can be used to cause a Denial of Service(DoS) in a number of
ways, including simply sending excessive numbers of ICMPv6 packets to
destinations in the site and sending error messages which disrupt
established communications by causing sessions to be dropped. Also
if spurious communication establishment messages can be infiltrated
on to a link it might be possible to invalidate legitimate addresses
or disable interfaces.
3.2. Probing
A major security consideration is preventing attackers probing the
site to determine the topology and identify hosts that might be
vulnerable to attack. Carefully crafted but, often, malformed
messages can be used to provoke ICMPv6 responses from hosts thereby
informing attackers of potential targets for future attacks. However
the very large address space of IPv6 makes probing a less effective
weapon as compared with IPv4 provided that addresses are not
allocated in an easily guessable fashion. This subject is explored
in more depth in [I-D.ietf-v6ops-scanning-implications].
3.3. Redirection Attacks
A redirection attack could be used by a malicious sender to perform
man-in-the-middle attacks or divert packets either to a malicious
monitor or to cause DoS by blackholing the packets. These attacks
would normally have to be carried out locally on a link using the
Redirect message. Administrators need to decide if the improvement
in efficiency from using Redirect messages is worth the risk of
malicious use. Factors to consider include the physical security of
the link and the complexity of addressing on the link. For example,
on a wireless link, redirection would be a serious hazard due to the
lack of physical security. On the other hand, with a wired link in a
secure building with complex addressing and redundant routers, the
efficiency gains might well outweigh the small risk of a rogue node
being connected.
3.4. Renumbering Attacks
Spurious Renumbering messages can lead to the disruption of a site.
Although Renumbering messages are required to be authenticated with
IPsec, so that it is difficult to carry out such attacks in practice,
they should not be allowed through a firewall.
3.5. Problems Resulting from ICMPv6 Transparency
Because some ICMPv6 error packets need to be passed through a
firewall in both directions, malicious users can potentially use
these messages to communicate between inside and outside, bypassing
administrative inspection. For example it might be possible to carry
out a covert conversation through the payload of ICMPv6 error
messages or tunnel inappropriate encapsulated IP packets in ICMPv6
error messages. This problem can be alleviated by filtering ICMPv6
errors using a deep packet inspection mechanism to ensure that the
packet carried as a payload is associated with legitimate traffic to
or from the protected network
The solution after all that HUGE security threat surface was to say "Deep Packet Inspection" which is beyond pf, and more in the direction of Wireshark with fairly complex custom Lua rules as because as mentioned integrating/capture/filter is needed both source and destination validation and the rule.
2) The need for a working, production, Internet Server is nearly out of scope for IETF ICMPv6 handling when not in a LAN or WAN in my opinion. DNS directly finds my services on the Internet. The Server's IPv6 is configured inside a modern hosted Network Operations Center with it's own routing and inside a VM hypervisor that has it's own IPv6 settings. What would be the need for an administrator to advertise to all the other completely non-related routers, network devices, and other heterogeneous servers in that NOC? Not much.
I can give testimony here as my server has quite complicated setup including IPv6 services with dual DNS and my latencies are 20-60ms, couldn't be much faster and all services work 100%.
