It appears this may still be a bug in 2.2.2  My PPPoE sessions being renewed seem to completely break DHCP6 prefix delegation with my ISP.  The WAN link comes up and can be used to communicate but routing for the delegated subnet is completely broken. I was able to confirm that killing the processes and re-saving the wan config as suggested on the documentation page here https://doc.pfsense.org/index.php/DHCPv6_Client_XID_Mismatch resolved the issue.

@doktornotor: Can people here retest this with latest 2.2.3 snapshots? Seems working for me. Ditto, seems fine for me as well, but more widespread testing would be appreciated.

Thank You Johnpoz & Gertjan. … :D learningg  ....  :-*

@doktornotor: … Also note that the IPv6 display for PPPoE has never worked properly -- neither in the GUI dashboard, nor in the console menu. +1, that is, the WAN IPv6 prefix + MACderivative parallel to the WAN IPv4 entry. Luckily I know my steady /48 on beforehand, so I can issue the different subnets for the SLAAC, Static or DHCPv6 LAN's ;)

For those still encountering issues with Comcast's odd DHCPv6 setup FYI, another trick to doing this if you don't want to have to change the MAC address and aren't willing to wait a week: Modify the WAN dhcp settings to request a /60 as previously detailed Download http://www.ipv6.mtu.edu/wide_mkduid.pl which is a simple perl script to create a dhcp6c_duid file. Run it on a Linux box (or something with Perl installed) like so $ ./wide_mkduid.pl -t now -m <pfsense wan="" mac="" address="">successfully created /home/timw/dhcp6c_duid DUID is 00:01:00:06:55:77:0a:34:XX:XX:XX:XX:XX:XX (MAC redacted) copy over the generated dhcp6c_duid to the pfsense box (I scp'd it into /tmp) Save a copy of /var/db/dhcp6c_duid (just in case anything goes wrong) cp /tmp/dhcp6c_duid /var/db/dhcp6c_duid Go into the WAN settings in the Web UI and just resave them. Immediately after doing this I was received my shiny new /60 prefix delegation.</pfsense>

The gif tunnel being /128 is fine. @furgussen: kernel: cannot forward src fe80:2::20c:29ff:fe2a:fba2, dst 2001:0:9d38:6abd:307a:377a:a785:7ba6, nxt 6, rcvif vmx1, outif gif0 Which is bizarre.  I don't know why pfSense is trying to foward link-local out to the internet. Because something is sourcing traffic from its link-local IP destined to its LAN MAC. This looks like what'd happen if you didn't configure your routed /64 on your LAN interface, or didn't configure RAs or DHCPv6 to assign IPv6 IPs to clients.

@jayjanssen: Thanks, but that seems unsatisfying… But that's how it works… Feel free to experiment with DHCPv6-Server to learn about address routing mask /64. One should reserve the last 64 bits for addressing LAN hosts. SLAAC fits right in, but you can make what you want with static or dhcpv6.

but I had use PF2.1.X version , ipv6 work in andriod.  only PF2.2.X IPV6 not work.

I don't need that binding on that interface for sure.. So just removed it..

@Rhongomiant: I am being told by an ISP that has multiple gateways for redundancy that my pfSense devices should be able to get the gateway IP from Router Advertisements after sending a Router Solicitation. I realize that this will work if I use SLAAC … No, you use RA in combination with SLAAC, DHCPv6-server or Static IPv6 assignment. And your pfSense devices are on the LAN. Configure your LAN IPv6 as static first with another unique subnet value than WAN,  mask /64, not some other value there.

Seems that DHCPv6 server has no problem. Problem is the default settings of Windows I've installed the following Microsoft fixes from https://support.microsoft.com/en-us/kb/929852 Microsoft Fix it 50440 Microsoft Fix it 50443

Update - General System Logs also states: Note- my logs are latest first. php-fpm[60244]: /interfaces.php: Creating rrd update script snmpd[78479]: disk_OS_get_disks: adding device 'ada0' to device list check_reload_status: Reloading filter check_reload_status: updating dyndns lan php-fpm[60244]: /interfaces.php: Shutting down Router Advertisment daemon cleanly check_reload_status: Restarting ipsec tunnels check_reload_status: Syncing firewall

Just an update. I got an Intel 350-T4 adapter (igb) and am using one of the ports for my wan (untagged) IPv6 is now working properly. Is this an issue with tagged interfaces on em cards?

@shadowlaw: … Do you happen to know if the /48 xs4all gives you is static? ... Basically yes, but I call it quasi-static, cause they reserve the rights to change just as they could do with IPv4 ;) Right, it works with prefix delegation request by dhcp6c.

They forced the default behavior to be this way in 2.2.1. You aren't the only one that did not like this change (there are a lot of reasons not to use Track Interface, IMO but there are other discussions here about that). This is what I had to do in order to be able to enable DHCPv6 as it was prior to 2.2.1: http://www.cmoullas.net/pfsense-2-2-1-breaks-teksavvy-ipv6-on-the-lan/ For a very complete video guide on how to configure IPv6 you can see this series of videos: https://www.youtube.com/watch?v=zdSI7Ez0Xhs

While I wouldn't claim to be any sort of expert on ipv6, the clearest part of ipv6 to me is the routing. The default route must be on the same subnet as the address.  Any other configuration leads to a network without a router, which means local traffic only. The way I see it, doing what you have been doing is essentially adding another network configuration on top of the same physical device, which means your existing ipv6 address will only be used for local traffic.

I don't know of anyone doing that, but it's possible to configure if both prefixes are static. The RA config can advertise multiple subnets, but can only do so today if they're both static. Then you should be able to policy route by source network out the correct ISP. Source address selection by end hosts is possibly a bigger impediment. Client machines generally would only use one or the other. It's probably less problematic with servers with static IPs, such as if you want multi-WAN redundancy to the same internal system on native IPs of both.

I understand. It's only a concern moving between networks that have IPv6 and those that do not. My motivation behind all of this is when I introduced a new backup WAN that is IPv4 only. Instead of disabling IPv6 altogether, I thought I could easily toggle it on and off so I could force all clients to IPv4 automatically when only my IPv4 WAN is available. I think the best approach is to forget about it until I can support it everywhere.

@gsiemon: If I use Track Interface then I can't edit the RA details anymore although I seem to be able to trick pfSense as per my earlier post. Yep… and there's a long-standing feature request asking for the ability to modify DHCP6 Server and RA settings when Track Interface is being used... https://redmine.pfsense.org/issues/3029

Solved: The issue was using a virtual MAC address when running PFSense on a single NIC (router on a stick). When I was running with the virtual MAC, the NDP table showed my physical MAC still on my external VLAN interface. So, the NDP table wouldn't populate with the MAC of my cable modem. When I changed to another virtual MAC, it wasn't fixed. When I changed to my physical MAC, it worked. The "right" answer is to have a dedicated external NIC, I know this. I'm betting it isn't just the virtual MAC, but the combination of running a VLAN for my external interface AND a virtual MAC. What is the best way to submit this bug?