It works now. :) I didn't change anything however so my ISP must've done something.

Why do you think the WAN address should be within your /60?  With that /60, you can have up to 16 LANs with a /64 prefix within 2600:8801:1d00:DE50 - 2600:8801:1d00:DE5E.  Normally, with IPv6, the ISP will assign a WAN address that is outside of your prefix.  That is certainly the case here.  Also, you don't actually need a routeable address on the WAN port, as routing, in IPv6, is normally done over the link local addresses.  The routeable address on the WAN interface would only be used for management and diagnostics.

Then lobby to your ISP to get it fixed.

It we add workarounds for broken designs, then ISPs will have no incentive to fix their broken designs.

No, the problem disappeared by itself… Probably an issue with my ISP?

I can add that I use a Windows 2016 IPv6 DHCP server for address leasing
My pfSense is set up for Unmanaged Router Advertisment
And I attach my LAN interface config

Thank in advance for any help

///Peter!

IPv6_RA.PNG
IPv6_RA.PNG_thumb
LAN_Interface.PNG
LAN_Interface.PNG_thumb

I think something might have been locking me out with the firewall rules when making interface changes.

In my case, I basically have a DMZ router hop to an internal network.  In order to rule this out, I connected my laptop directly to the LAN port of the Netgate.

I'm now able to make changes to the interfaces and not get locked out.

I'm also on Comcast, I set a prefix delegation hint of /60 and they happily handed me back that prefix.  Something to keep in mind if you need more subnets :)

@JKnott:

The only LL packets that pfSense can see are those that pass through a pfSense interface.  I know about the multicast packets for things such as router advertisements etc..  However, MLD is used to discover which devices on a local LAN want to receive specific multicasts from elsewhere, not those originating on the local LAN.  For example, if your computer wants to listen to some multicast out on the net, the routers (and possibly switches) listens for the request and then arranges to get that multicast from the source and pass it on to the requesting device(es).

Agreed; all the packets logged are from potential LAN clients of a multicast stream that the pfsense router has access to. If you execute "netstat -s -s" you can see that under icmp6: has reference to "MLDv2 listener report" which am guessing means the number of listeners observed since boot.

@JKnott:

There is no need to do this on the local network.  Also, multicasts are not received by every node on the network.  They are filtered by multicast MAC address in the NIC, so that if a node is not interested in a particular multicast, it doesn't hear it.

Yes, I understand and agree that multicasts are not received by every node. My understanding that the higher level IP protocols configure the Ethernet interface according to their needs to take advantage of the NICs ability to ignore Ethernet multicast traffic in hardware. The packets coming from various LL addresses on my LAN are sending to an IPv6 multicast address (ff02::16) that must be enabled by the pfsense router based upon a reserved Ethernet multicast address for MLDv2. I know how the old mapping of IPv4 multicast addresses were handled, but have not come across the equivalent method that supports IPv6 multicast addresses. IPv6 has many multicast addresses defined for LL traffic (https://www.iana.org/assignments/ipv6-multicast-addresses/link-local.csv)

@JKnott:

This differs from IPv4 broadcasts that all devices receive.  The only thing that's comparable in IPv6 is the all nodes multicast, which is received by all nodes and used for things like router advertisements.  Also, that "2" in ff02 refers to the scope, in this case link local.  That means a router will ignore it, as it doesn't have anything to do.

Both IPv4 and IPv6 use Ethernet multicast. IPv4 also uses Ethernet broadcast, which is not supported in IPv6, but, as you pointed out, however, if every IPv6 node enables the same Ethernet multicast address on a specific interface, then there is an effective link broadcast address. Routers will NOT repeat that traffic onto other links.

@JKnott:

BTW, RFC 3810 has been superseded by RFC 4604.

RFC4604 is an update to RFCs 3376 and 3810 and clarifies how IGMPv3 is related to MLDPv2

And, I still am waiting to hear why there is selective filtering of logged traffic. I wonder what else is unformatted besides MLDv2 listener reports…

To the time it takes.. You understand you can copy a rule right, and then just need to change the interface and it moves over to that tab..

So creating your rule once and then copy to multiple vlans only takes a few seconds.  And if you used alias to list your ports for your dest and even your dest IPs.. You just need to modify those and all rules using those would auto get updated..

@johnpoz:

Where do you read that?  That does not say anything of the sort…

I can put rfc1918 and public on a box as well - doesn't mean you should...

You seem to think its ok to run multiple layer 3 on the same layer 2, which is exactly what that is..  Which is not the case, be it you can do it or not..

Who says those are the same interface?  It could be a back lan, or a storage network..

If he wants to run ULA on a vlan interface, and Global on another vlan - sure ok... Pretty pointless but yeah you can do it..

I could for sure see it as storage network say..  This should be a different L2..

Well, here's what RFC 6724 says:

1.  Introduction

The IPv6 addressing architecture [RFC4291] allows multiple unicast
  addresses to be assigned to interfaces.  These addresses might have
  different reachability scopes (link-local, site-local, or global).
  These addresses might also be "preferred" or "deprecated" [RFC4862].
  Privacy considerations have introduced the concepts of "public
  addresses" and "temporary addresses" [RFC4941].  The mobility
  architecture introduces "home addresses" and "care-of addresses"
  [RFC6275].  In addition, multi-homing situations will result in more
  addresses per node.  For example, a node might have multiple
  interfaces, some of them tunnels or virtual interfaces, or a site
  might have multiple ISP attachments with a global prefix per ISP.

Notice it says "multiple unicast addresses".  That implies more than two, so we can rule out just a unicast & a link local.  It also mentions multiple scopes (unique local replaced site local).  Clearly the IETF intended there be multiple routable addresses on a single interface.  It also mentions multiple ISPs & prefixes.  These are things I've mentioned were possible with IPv6.  You may think it's "borked", but you're at odds with the IETF.  They seem to think there are valid reasons for these things.  I have also read pretty much the same in the Cisco book "IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6" 2nd ed..

I have removed pfsense from the equation and there is still packet loss so seems to be a strange coincidence with an ISP issue.

I really appreciate your help John.

With regards to your comments about ipv6 dns and / or global gateway setup, I can't find any reference to these in the guide, so probably the reason why they aren't setup.

I've just hooked up my Asus AC86U to my modem, bypassed my pfsense device, and configured my HE tunnel on the AC86U and I've got ipv6 connectivity straight away. I know I've followed the pfsense guide for setting up an HE tunnel on my pfsense as accurately as I can, but for some reason it just won't work. I don't see why it's so easy to setup on my AC86U yet so difficult on pfsense., it's certainly beaten me.

As I said before it's not important for me to get up and running, just would have been nice to have it, so I'm going to leave it for now. Perhaps when I have more time I'll rebuild pfsense and try again then, perhaps my initial setup wasn't correct.

Thanks again for all your help, I do appreciate your efforts.

If you want a device to talk to a global address it needs a global address.

Not quite.  It can, provided it doesn't have to go over the public Internet.  PfSense can easily route between global and ULA addresses.  I have done that here.  This is no different than using RFC 1918 addresses on IPv4.

But your client will have to have one if you want to be able to talk to stuff via that linklocal transit your using upstream of pfsense.

Here we go again.  Global addresses are not normally used for routing.  As I pointed out recently in another thread, routing is done using link local addresses between routers.  Check your routing table to verify.  You can also capture router advertisements to see what address is provided for routing.  However, those global addresses are definitely useful for management and diagnostic purposes.

But sure it is possible to do such routing with linklocal, or use a ULA as your transit IP scheme, etc.

Once again, link local addresses are always used for routing, unless specifically configured otherwise.  Take a look at your routing table in pfSense and computer operating systems.  You will see link local addresses.  For example, here is the default IPv6 route on the Linux computer I'm currently sitting at:

default via fe80::1:1 dev eth0  proto ra  metric 1024  expires 46sec hoplimit 64 pref medium

As you can see, it's a link local address, as provided by pfSense.  Further, it's entirely possible for a router to have the same link local address on multiple interfaces.  It's only necessary to have unique link local addresses for devices on any given link.  This would not be possible with a routable address.

As I mentioned in other threads, many things in IPv6 are different from IPv4.  You need to update your understanding of this.  There is one other difference shown in that default route that goes to another disagreement we had a while back.  Do you see that "medium" at the end of the line?  That refers to router priority.  By changing that, you could have multiple default routes, possibly via alternate ISPs, simply by assigning different priorities, as pfSense can do.  Then should the primary default route fail, another can then be used.  This is part of IPv6 and can only be accomplished in IPv4 by using a first hop redundancy protocol.

Now I have to do some special port forwarding, aka "connect to IP x.x.x.x port YY" for this backup and "connect to IP x.x.x.x port ZZ" for the other backup.

Again, not a huge deal but would be nice to have IPv6.

That's an excellent reason for moving to IPv6 as much as possible.  NAT brings a lot of problems, such as yours where you need some other means to select among multiple computers running the same protocols.

Let's see if I get any traction with this post:
https://answers.microsoft.com/en-us/msoffice/forum/msoffice_sfb-mso_mac-mso_o365b/skype-for-businesslync-services-dont-appear-to/c204b511-8b0b-4338-924e-729603627413

Again I hear you… So? Read https://tools.ietf.org/html/rfc7404

I just did.  That article points out why you'd need a routeable address for management purposes, not routing.  Given that any interface that has a routeable address would also have a link local address (even my OpenVPN tunnel has a link local address), it's not an either/or situation.  Use a routeable address for management and link local for routing.  Regardless, a routeable address is not necessary for routing in IPv6.  Incidentally, some of the things in that article might make a case for using ULA and not global addresses.  ULA provides a routeable address that's not exposed externally.

@kpa:

On top of that if you have only your normal IPv4 WAN connection and an IPv6 tunnel from HE (why would you even consider using another IPv6 connection in addition to your HE tunnel?)

I'm not the person you were replying to, but speaking for myself, I see things like this on my HE tunnel all the time:

Feb 12 14:00:45 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Alarm latency 33734us stddev 19534us loss 21% Feb 12 14:00:58 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Clear latency 33166us stddev 19392us loss 20% Feb 13 10:51:11 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Alarm latency 28309us stddev 9549us loss 22% Feb 13 10:51:12 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Alarm latency 605795us stddev 2656495us loss 19% Feb 13 10:52:07 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Alarm latency 137034us stddev 756717us loss 12% Feb 13 10:52:11 dpinger OPT3V6_TUNNELV6 2001:470:7:117e::1: Clear latency 33363us stddev 17753us loss 7%

My homelab setup is much simpler than pbnet's, in that right now it's just one IPv4 through my ISP, and one IPv6 tunnel via HE.  But due to the regular latency spikes, I'm considering trying to figure out how to set up some kind of multi-WAN thing, using my ISP's own IPv6 as the other uplink.  The issue is that my ISP's IPv6 is hilariously terrible, so I need to keep HE's tunnel as an option.  I think multi-WAN connections like this should be able to either failover or load-balance when the latency gets high enough to set off alarms, it's just I haven't had the time and energy to make the attempt.

So anyhow, that's just one example of why somebody might need a connection in addition to the tunnel.

@al:

If accepted this fix is likely to enter pfSense v. 2.4.3.

Excellent!  I'm running 2.4.2 so moving to .3 is totally an okay solution for me.

I shall not rule out that something else could be wrong in your specific setup.
Are you able to see the DHCPv6 leases in the menu of Diagnostics under the menu item NDP Table?

I can see the dynamic lease that I was expecting to see, yes.  So it's probably due to the parser problem that your patch fixes.  Since it's a small network, I can get on each client and find out their DUID, and create the static mappings manually.

I don't see any other DHCPv6 leases at all, though; neither dynamic nor statically mapping.  The rest of the NDP table, other than the router itself, are just the link-local addresses.  (So they're… not even asking for an address?  I would expect the Android phones to just languish in IPv4 until I get around to turning on SLAAC, but the laptops ought to be sending v6 solicitation packets... unless Windows 10 gets that wrong too...  They all seem to be making use of IPv6 even without the DHCPv6 leases, so this approach to a more thorough control of the local network is clearly incomplete.)

Sorry, rambling aloud now.  Going to call the problem solved, and then turn off the dual stack until I can figure out a better way to do this.  Maybe use only ULAs combined with prefix translation, if that's even supposed to work with a tunnel provider on the outside...  I need more sleep.

Thank you for your help, al!