IPv6 multicasts flooding the pfSense logs.



  • Thank you Mer for your response.
    On the other side of the WAN interface is a Comcast infrastructure, and the IPv4 or IPv6 addresses  in fact advertised via DHCPv4 or DHCPv6.
    I want to point out tho again, my WAN interface configured to ignore IPv6 and DCHP request it send to Comcast is send using DHCPv4.

    There is no question that I can not control what comes in from from WAN, but I can control/filter what packets should pass through the firewall or/and rejected or/and are dropped.
    All packets, according to my current set of rules, do get dropped silently.

    As far as identifying what firewall rule "default block rule", I am not sure how to identify it by looking at the logs, or "hovering" over the record in the log using GUI.

    I do not wish to stop logging the default rules because it is important to me to be aware what are the traffic conditions coming to the WAN interface, and that's, in part, what are logs are for.

    Maybe a better question for me to ask, how can I disable logging for one single IPv6 address that flooding my WAN interface with ICMPv6 requests. They do get dropped, or at least I hope that they do.

    Running a port scanner from outside of my WAN interface shows that there is not a single port exists on the IP address assigned to me. So my firewall stays quiet.
    But I only been able to run port scan using IPv4. i do not have capability to run a similar scan using IPv6. I'm suspecting that when IPv6 traffic reaches my WAN interface, my firewall may not behave as it does using IPv4 and instead of staying quiet, does …. something else...

    Another question I have... i find it very strange the patter of IPv6 ICPMv6 traffic I'm receiving. Those requests do not come from a large rage of external IPv6 addresses. All this traffic (~98% of all traffic that comes to my WAN) is coming from one specific address, all of it is ICMPv6.

    This is strange enough to me, that I am thinking maybe because the modem (this is  DOCSIS3 cable modem) has embedded services in it that may be generating this ICMPv6 barrage of pings. There goes a single IPv6 address shown  in logs that sends all this requests.

    Could some one who might be experiencing a similar problem or well familiar with IPv6, comment on this?

    Thank you.



  • So there is a cable modem between your WAN and Comcast?    The stuff IPV6 you see logged in your firewall are mot likely link local stuff from Comcast side of things, IPV6 does some things different than IPV4 and can be a bit chattier on link local addresses. 
    Web GUI, Firewall Logs, if the "Act" column is a red box with an X, that means "blocked".  Take your mouse, put it over that red x, let it sit (don't click).  You should see something pop up saying "block/1000000103"  (the actual number may be different).  That says action/rule number.

    What brand of cable modem?  You should be able to point a web broswer at it and see what it's doing, how its ethernet address is configured.
    Firewall, Rules, WAN tab, add a rule to specifically block, proto any, IPV6, sourced from the address you are seeing, don't log.  If you add that near or at the top of the WAN rules, it should stop logging them.



  • Hello Mer… Things are still not good with logs.

    I have created a rule on WAN for all IPv6 packets to be BLOCKED (dropped silently). In the GUI editing for the rule, the check box for logging is unchecked  and still the logs keep recording the events cut but this rule. In the log, when hovering over the red cross it does show the rule number from the top (first rule).

    The rule is the 3ed one in the list and that's as high in the list I can get, because the top two rules are auto-generated by PFsense to block the Bogon networks.

    Log's still on junked up with the ICPMv6 messages.

    Doesn't fire wall logs for WAN everything? If I would not have any rules for WAN governing incoming traffic.. than what? All traffic that came to WAN and was not initiated from with in (the host behind the firewall), Firewall logs immediately starts piling up, showing all the unsolicited requests.

    That's why this ICMPv6 messages are in the logs, even tho now I have a explicit rule to match the patter of the incoming traffic, and the check box to log this traffic is UN-checked.

    So there is no way to tell the logs to ignore the IPv6 traffic coming to the WAN and stop piling up the logs. That's how I see it as of right now.

    Sooo... is this a feature or a bug or a featured-bug?

    If some one from PFsense dev team reading this forum... please chime in..... because in my case, as of right now logs are nearly useless.

    I can go in and create a custom filter to sort out the logs and exclude the IPv6 junk, but that just not user friendly, additional work to do, and doe snot affect the graphical pie-charts - they all look totally skewed.

    Please help....

    In addition to this dilemma, got this weirdness going on:

    One of the events in logs on WAN interface looks like this:

    Action Time Interface Source Destination Protocol
    X Jun 16 00:04:37 WLAN 0.0.0.0 224.0.0.1 IGMP

    Hovering over the the red (X) mark shows a message:

    The rule that triggered this action is:
    @9(1000000103) block drop in log inet all label "Default deny rule IPv4"

    I do not have a single rule in the rule sets for the firewall with that label : "Default deny rule IPv4"

    Where is this coming from? Where is this rule? Does GUI not list all the rules?

    Someone PLEASE comment.... please?!



  • Can you grab screenshots of your rules?  All of the tabs (WAN, LAN, Floating).    That makes it easier for folks to see exactly what is being evaluated, in what order.  We want to be able to double check your protocol, source and dest, make sure that's all correct.
    Grab a screen shot of the firewall logs;  that will also eliminate any potential transcription errors trying to convey the information.

    Your fourth paragraph "…doesn't firewall logs...".  Yes, that would be the default deny/block rule on the WAN interface.

    It should be possible to not log all IPv6 traffic coming into the WAN; we just haven't figured out the right rule yet.

    Your IPV4:  the default deny rule is automatically added by pfSense itself, as the last rule in the list.  Probably doesn't show up in any of the lists by default.  That destination is a multicast address, IGMP protocol is used for managing multicast traffic between/through routers and to hosts.

    To verify that all the logs we are chasing are due to the default rules logging everything, try disabling logging of the default rules for a short bit of time.  Yes, you lose all the logs that you may be interested in,  but it will at least confirm we are looking at the right stuff.
    Screenshots of your rules tabs and of the firewall log lets us make sure we understand the order and specification of the rules and the characteristics of the logs we want to eliminate.

    It is also possible that the preexisting rules are actually the ones blocking and logging.  You should be able to edit them to disable logging;  again just to give us a data point.



  • Hello Mer, wow… could you just thank you right a way. This is absolutely awesome that you are willing to spend your time to help me and others to diagnose this...

    I have the screen-shots you requested...
    1. I included the most recent firewall log (from GUI);
    2. Floating Rules for Firewall;
    3. Rules for WAN (Ethernet)
    4. Rules for LAN (Ethernet)
    5. Rules for WLAN (Ethernet)
    6. Rules for VPN (OpneVPN)

    Questions: When you suggest to "disabling logging of the default rules" - I'm not quite sure what do you mean by that. I have never explicitly enabled logging when I created the rules.
    The rules that are in the list by default, up-on editing default rules, the check-box for logging shows to be un-checked.
    Are you suggesting to edit general logging options?
    I looked for options @:    Status-> System -> Logs Settings  and could not find an appropriate setting to adjust to temporarily halt logging of the default rule-set.

    Please see the screen-shots, and if there is anything I can do on my part to help to diagnose, please let me know and I will do what-ever I have to to provide you with more data.

    Again, thank you for your help.

    If you are the one who is working on the PFsense dev team, I want to make this very clear, - thank you for the work you do. I have absolutely no complaints. I get to use this software under GPL license, and it work awesomely well, comparing to it's commercial counterparts.

    I would spend my time to do a QA, to improve the PFsense so the other users experience can be even better :)

    Thank you.














  • No problem.  I'm not a pfSense developer just someone that uses the stuff and likes it and wants to help.  Thanks for the screenshots, it'll take me a little bit to go through them.  Rest assured that if anything I say is wrong, people will be along to correct me :)

    Status, System Logs, Settings should be the correct spot to turn off the default rule logging (yes, the top is probably labelled General Logging Options).  Should be a section labelled something like "Log Firewall Default Blocks", probably 3 or 4 options in there.  Basically any that are checked, uncheck and hit save at the bottom.  You may want to then clear the firewall log.  Then let us know what happens.

    I need another cup or 2 of coffee while I look at the screenshots.

    Ok, for the life of me I can't see anything wrong with the rules.  The only thing that makes sense is that ICMPv6 is not matching IPv6 with protocol *, but that doesn't make sense to me either.

    Now we wait for someone else to chime in, then we'll both know the answer.  In the meantime, see if disable default block logging helps.



  • Hello Mer, now I can confirm that adjusting the logging parameters to halt default firewall rules logging results in absolute empty logs.
    Once that check-box is UN-checked, there is absolutely no new records is made to firewall logs.

    As soon as the check-box is checked again and settings are saved, the firewall logs become full of this ICMPv6 events records. After clearing the logs and re-enabling logging for default firewall rules, logs show from 0 records, up to 98% of one single even (the same ICMPv6 messages) amongst other events related to the actual traffic coming to WAN interface (about 4% of the total number of the events logged for the firewall).

    This confirms that the messages that are flooding the logs in fact are generated by the default firewall rules.

    Now the question is how to disable the logging of, if not for this one single IPv6 address that spamming the logs (ideal), at least how to disable logging for IPv6 events (including ICMPv6) from been written to firewall logs.



  • Thanks for verifying that.  From what I see, your IPv6 block rule on the WAN should be getting triggered before the default deny, but apparently it's not.

    If you go to Diagnostics, Command Prompt, enter the command "pfctl -sr" and hit execute.  You'll get the rules, as pf sees them.  That may give us a clue.  You may also want to ssh or console in and do the command in case the output is truncated.



  • Got it… done. Here's the output:

    DiagnosticsCommand Prompt

    Shell Output - pfctl -sr

    scrub on re2 all fragment reassemble
    scrub on re0 all fragment reassemble
    scrub on re1 all fragment reassemble
    anchor "relayd/" all
    anchor "openvpn/
    " all
    anchor "ipsec/" all
    pass in quick on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
    pass out quick on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
    block drop in log quick inet6 all label "Block all IPv6"
    block drop out log quick inet6 all label "Block all IPv6"
    block drop in log quick inet from 169.254.0.0/16 to any label "Block IPv4 link-local"
    block drop in log quick inet from any to 169.254.0.0/16 label "Block IPv4 link-local"
    block drop in log inet all label "Default deny rule IPv4"
    block drop out log inet all label "Default deny rule IPv4"
    block drop in log inet6 all label "Default deny rule IPv6"
    block drop out log inet6 all label "Default deny rule IPv6"
    pass quick inet6 proto ipv6-icmp all icmp6-type unreach keep state
    pass quick inet6 proto ipv6-icmp all icmp6-type toobig keep state
    pass quick inet6 proto ipv6-icmp all icmp6-type neighbrsol keep state
    pass quick inet6 proto ipv6-icmp all icmp6-type neighbradv keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echorep keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echorep keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state
    pass out quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type echoreq keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routersol keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type routeradv keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbrsol keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to fe80::/10 icmp6-type neighbradv keep state
    pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type echoreq keep state
    pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routersol keep state
    pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type routeradv keep state
    pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbrsol keep state
    pass in quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 icmp6-type neighbradv keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type echoreq keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routersol keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type routeradv keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbrsol keep state
    pass in quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type neighbradv keep state
    block drop log quick inet proto tcp from any port = 0 to any label "Block traffic from port 0"
    block drop log quick inet proto udp from any port = 0 to any label "Block traffic from port 0"
    block drop log quick inet proto tcp from any to any port = 0 label "Block traffic to port 0"
    block drop log quick inet proto udp from any to any port = 0 label "Block traffic to port 0"
    block drop log quick inet6 proto tcp from any port = 0 to any label "Block traffic from port 0"
    block drop log quick inet6 proto udp from any port = 0 to any label "Block traffic from port 0"
    block drop log quick inet6 proto tcp from any to any port = 0 label "Block traffic to port 0"
    block drop log quick inet6 proto udp from any to any port = 0 label "Block traffic to port 0"
    block drop log quick from <snort2c>to any label "Block snort2c hosts"
    block drop log quick from any to <snort2c>label "Block snort2c hosts"
    block drop in log quick proto tcp from <sshlockout>to (self) port = ssh label "sshlockout"
    block drop in log quick proto tcp from <webconfiguratorlockout>to (self) port = https label "webConfiguratorlockout"
    block drop in log quick from <virusprot>to any label "virusprot overload table"
    block drop in log quick on re2 from <bogons>to any label "block bogon IPv4 networks from WAN"
    block drop in log on ! re2 inet from XX.XX.194.0/23 to any
    block drop in log inet from XX.XX.XX.XX to any
    block drop in log on re2 inet6 from fe80::212:eff:fee6:b069 to any
    block drop in log quick on re2 inet from 10.0.0.0/8 to any label "Block private networks from WAN block 10/8"
    block drop in log quick on re2 inet from 127.0.0.0/8 to any label "Block private networks from WAN block 127/8"
    block drop in log quick on re2 inet from 172.16.0.0/12 to any label "Block private networks from WAN block 172.16/12"
    block drop in log quick on re2 inet from 192.168.0.0/16 to any label "Block private networks from WAN block 192.168/16"
    block drop in log quick on re2 inet6 from fc00::/7 to any label "Block ULA networks from WAN block fc00::/7"
    pass in on re2 proto udp from any port = bootps to any port = bootpc keep state label "allow dhcp client out WAN"
    pass out on re2 proto udp from any port = bootpc to any port = bootps keep state label "allow dhcp client out WAN"
    block drop in log on ! re0 inet from 192.168.2.0/24 to any
    block drop in log inet from 192.168.2.1 to any
    block drop in log on re0 inet6 from fe80::20d:b9ff:fe38:5648 to any
    pass in quick on re0 inet proto udp from any port = bootpc to 255.255.255.255 port = bootps keep state label "allow access to DHCP server"
    pass in quick on re0 inet proto udp from any port = bootpc to 192.168.2.1 port = bootps keep state label "allow access to DHCP server"
    pass out quick on re0 inet proto udp from 192.168.2.1 port = bootps to any port = bootpc keep state label "allow access to DHCP server"
    block drop in log on ! re1 inet from 192.168.3.0/24 to any
    block drop in log inet from 192.168.3.1 to any
    block drop in log on re1 inet6 from fe80::20d:b9ff:fe38:5649 to any
    pass in on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
    pass out on lo0 inet all flags S/SA keep state label "pass IPv4 loopback"
    pass in on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
    pass out on lo0 inet6 all flags S/SA keep state label "pass IPv6 loopback"
    pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
    pass out inet6 all flags S/SA keep state allow-opts label "let out anything IPv6 from firewall host itself"
    pass out route-to (re2 XX.XX.XX.1) inet from XX.XX.XX.XX to ! XX.XX.XX.0/23 flags S/SA keep state allow-opts label "let out anything from firewall host itself"
    anchor "userrules/
    " all
    pass in quick on openvpn all flags S/SA keep state label "USER_RULE: OpenVPN BaseStar-VPN wizard"
    block drop in quick on re2 inet6 all label "USER_RULE: Block IPv6"
    pass in quick on re2 reply-to (re2 XX.XX.XX.1) inet proto udp from any to XX.XX.XX.XX port = 3219 keep state label "USER_RULE: OpenVPN BaseStar-VPN wizard"
    block drop in log quick on re0 inet proto tcp from 192.168.2.4 to (self) port = ssh label "USER_RULE: Isolate ConnectME client from firewall management"
    block drop in log quick on re0 inet proto tcp from 192.168.2.4 to (self) port = https label "USER_RULE: Isolate ConnectME client from firewall management"
    block drop in log quick on re0 inet proto udp from 192.168.2.4 to (self) port = ssh label "USER_RULE: Isolate ConnectME client from firewall management"
    block drop in log quick on re0 inet proto udp from 192.168.2.4 to (self) port = https label "USER_RULE: Isolate ConnectME client from firewall management"
    block return in quick on re0 inet from <nas>to XX.XX.XX.0/23 label "USER_RULE: No WAN access"
    block return in quick on re0 inet from <no_wan_access>to XX.XX.XX..0/23 label "USER_RULE: No WAN access"
    pass in quick on re0 inet from 192.168.2.0/24 to any flags S/SA keep state label "USER_RULE: Default allow LAN to any rule"
    block return in quick on re1 inet proto tcp from 192.168.3.0/24 to (self) port = ssh label "USER_RULE: Block access to Firewall Management"
    block return in quick on re1 inet proto tcp from 192.168.3.0/24 to (self) port = https label "USER_RULE: Block access to Firewall Management"
    block return in quick on re1 inet proto udp from 192.168.3.0/24 to (self) port = ssh label "USER_RULE: Block access to Firewall Management"
    block return in quick on re1 inet proto udp from 192.168.3.0/24 to (self) port = https label "USER_RULE: Block access to Firewall Management"
    block return in quick on re1 inet from 192.168.3.0/24 to 192.168.2.0/24 label "USER_RULE: Block traffic to LAN"
    pass in quick on re1 inet from 192.168.3.0/24 to any flags S/SA keep state label "USER_RULE: Permit outgoing IPv4 traffic"
    anchor "tftp-proxy/*" all

    Execute Shell Command

    My real WAN IP is replaced in this output with XX.XX.XX.XX just so you know what that is and why is it there.

    Please let me know if this helps.</no_wan_access></nas></bogons></virusprot></webconfiguratorlockout></sshlockout></snort2c></snort2c>



  • Yep, that helps.
    Seel the line that says this, the first block rule?
    "block drop in log quick inet6 all label "Block all IPv6"

    The "log" keyword is there.  On your WAN rules, didn't you label it "block all ipv6"?  make sure you don't have the "log" checked for that rule. 
    I think that block rule is from your addition, but it may be added from disabling the IPv6 that you did elsewhere in the config.
    One way to prove that would be to go back and reenable the IPv6 and leave your block rule that you added (turning back on the logging of default rules) and see what shows up in the logs.



  • That's it! You did it…

    To re-cap, the rule labeled "Block all IPv6" is not that one I created manually, the once I created is called "Block IPv6" and logging is not enabled on that rule.

    However, as soon as I re-enabled IPv6 processing under @ System->Advanced->Networking: Allow IPv6, the logging of those endless ICMPv6 messages stopped!

    Now logs look appropriate, just the way I would expected them to be. Only records are now shown on WAN is the unsolicited traffic and majority of it is IPv4.

    Thanks to you, the logs for firewall on my Pfsense is useful again.

    I can't thank you enough for all your help.

    This was not easy for me to diagnose and I think is worthy of been mentioned in official man pages for the PFsense.

    Again, thank you for all your help and assistance.



  • Fantastic!  So now we know that disabling IPv6 added the two block rules at the top, with the log option, that logging was affected by the disable options over on the log settings.

    We've both learned something about this now.



  • (Hopefully this isn't a second post… looks like I was logged off and had to come back and repost...)
    Thanks guys, now I know I'm not crazy (mostly) :)  I had the exact same problem as above compounded by the fact I syslog out to a local NAS which, after I disabled IPv6 a bit ago, began churning away 24/7 with all these log messages.

    I more or less did the same as you did above.  Re-enable IPv6 on the Advanced tab and add a manual rule with log OFF to block all IPv6 traffic.  Few notes for anyone who comes after:

    Thanks in part to this:
    https://www.engren.se/2013/04/30/some-pfsense-commands-to-keep-handy/

    Trying to find the rule that is logging all the messages...

    ssh to pfsense
    viconfig
    The firewall rule we're looking for is not present in this config.  Must be generated by whatever reads this config and creates the rules.

    In the actual runtime rules here:
    /tmp/rules.debug

    These are the two rules created when System > Advanced > Networking > "Allow IPv6" is unchecked (verified):

    Block all IPv6

    block in log quick inet6 all tracker 1000000003 label "Block all IPv6"
    block out log quick inet6 all tracker 1000000004 label "Block all IPv6"

    I say verified because I know those two rules are created and deleted when that checkbox is toggled.  I do NOT know if there is anything else modified.

    If any PFSense folks happen to see these posts, sure would be nice to have an extra option in that Advanced tab to control logging.



  • Found what may be a better solution.  Based on this:
    https://doc.pfsense.org/index.php/How_can_I_edit_the_PF_ruleset

    ssh to pfsense
    vi /etc/inc/filter.inc
    Find the two lines following:
                    $ipfrules .= "block in {$log['block']} quick inet6 all tracker {$increment_tracker($tracker)} label "Block all IPv6"\n";
                    $ipfrules .= "block out {$log['block']} quick inet6 all tracker {$increment_tracker($tracker)} label "Block all IPv6"\n";
    In both of those lines remove the string (and one space):
    {$log['block']}
    Save and quit vi

    Go back to pfsense UI and

    1. remove the custom rule we added from previous posts
    2. uncheck the "Allow IPv6" again
    3. let pfsense rewrite it's rules

    Now those default rules are back in place BUT without the log parameter.

    My only question:  will this manual modification be overwritten by a PFSense update?



  • Hi,

    Just went looking for this sort of thing also and found this:
    https://doc.pfsense.org/index.php/Firewall_Logs#Disable_Default_Block_Logging

    Hopefully this helps?



  • @mrogghe:

    Found what may be a better solution.  Based on this:
    https://doc.pfsense.org/index.php/How_can_I_edit_the_PF_ruleset

    This was very helpful.  Thanks!



  • Thanks all for the help in resolving this issue.

    I would like to clear something out , to ask actually:

    I had the same issue by being clogged by this ICMPv6 logs. After I checked the box "Allow IPv6" in advance/networking I got rid of the annoyance finally. Now do I need to create a rule manually to block IPv6 traffic (with logging of) so it won enter my WAN ? or since set "IPv6 Configuration Type" to "NONE" on my WAN interface so ipv6 will be still blocked ?

    Thanks.



  • Why would you want to block IPv6???  That's what the world is moving to.  It's the future of the Internet.



  • It's not moving to good direction then. :)



  • While I can't speak about the specific issues here, both ICMP6 and multicasts are essential parts of IPv6.  For example, there is no such thing as broadcasts with IPv6.  Instead, there are several types of multicasts, to specific groups.  Even ARP has been replaced with solicited node multicasts.  One thing that's also used extensively is MTU discovery, which involved ICMP6.  MTU discovery is essential, as with IPv6 routers are not allowed to fragment packets.  With IPv4, you could set the MTU to whatever and if the packet tried to pass through a router that couldn't handle the MTU, the packet would be fragmented so that the fragments could pass.

    I have been running IPv6 for 7 years, including just over a year with pfSense and it works fine.