A workaround is to use SLAAC as IPv6 Configuration Type on the LAN. Works well.

Even tho i seem to be talking to myself, i give it a go (again). Had a 7 day "streak" without any incidents, but the previous night i had a WAN disconnect according to the logs. This in turn lead to me loosing ipv6 a few hours later. Now, i wonder, could it be that whenever i loose WAN connectivity something "hangs" in that RA wont broadcast/refresh my prefix until i either reboot or restart wan? (By saving wan settings and applying without actually changing anything). It could be just a coincidence that i had 7 days uptime on WAN now vs. before changing nic's, as it usually happen at night (2 pm ish), which COULD indicate some ISP maintenance or something like that. Anyway, the thing is that it does seem as when WAN link goes down, something weird will happen with my prefix. I just upgraded to 2.2.6 today, but havent really had the chance to study the patchnotes yet, so not sure if this is something that is specifically addressed there tho. C

HowTo (In Dutch) for the scenario (pfSense, XS4ALL and IPv6) can be found http://blog.firewallonline.nl/how-to-en-tutorials/xs4all-pfsense-opnsense-ipv6/. Using it myself and working ok. Beware that there is a nasty bug: https://redmine.pfsense.org/issues/2762 preventing normal IPv6 usage with pfSense (slow loading sites). That is why I use 2.3 alpha. The only difference with my scenario is I skipped out de FB and working with VLANs on WAN side. To reduce potential problems: use MTU=1492 and MSS=1472 on WAN Interface

For that issue in particular, apinger has been replaced with dpinger in 2.3, and that's something we're in the middle of working on right now. So not something we'll pursue with apinger since it's gone in development versions. We'll make sure that scenario works in 2.3.

why would you need to add that to pfsense routes?  If you want your vpn client to use the ipv6 tunnel to get to other ipv6 networks other than the ones you list then yeah you prob want to push that route to your vpn client In the advanced box push "route-ipv6 2000::/3"

@kobold: Does this mean that after setting up the WAN interface / (re)boot, I always have to disconnect and connect the PPPoE twice? Yes. And control the process with (kill -9 PID). First time you will get rid of the "privateextension"-address (good), but there seems no proper/reliable cleanup of old PID dhcp6c. (bad). Therefore second time will assure you one valid PID on the proper fe80::, so to keep the hourly & mandatory 2-hourly lease renewal with ISP on fe80:"MAC". FYI: something strange in Status-Interfaces(PPPoE) are the value's for Link-Local & Address. I would expect Address to be based on pfSenseBox-WAN-MAC and Link-Local on the pfSenseBox-LAN-MAC. Now it is both on pfSenseBox-LAN-MAC (!?). In 2.2.4 Address was based on pfSenseBox-WAN-MAC. Typical design question… Oh, and work with forced MTU 1492 (WAN & LAN's).

<sarc>About need or grief or learning… Track interface. Once your refrigerator is aware with its MAC, it will talk to kaymart about the eggscontainer because you allowed RA assisted or unmanaged, SLAAC ;). And don't you love it, the 2-way audiovisual SmartTV. Nah, IPv6 will ease national security applications.</sarc> ISP-native or cloudy GE-tunnel does it matter ? I use IPv6 pfSense for explicit outbound allowance, so create static LAN's and use DHCP6-server an RA managed or just create static server(hosts) for LAN's...

Not that i have the all-knowledge of stuff tho, but this HAS been covered a lot of times before :) Anyway. 1. You can ofc. have both ipv4 and ipv6 addresses on your gear. That way you will "always" be able to connect to the ipv4 address if that is a concern :) 2. If you do not want to use ipv6 at all, just disable ipv6 on the lan/wan interfaces + you can remove the check in the box under System -> Advanced -> networking : Allow ipv6 (That way, ipv6 is disabled throughout pfsense) 3. There are different ways of setting up ipv6 for your internal devices. Several posts here on the forum about timewarner and ipv6. The easiest "out-of-the-box" setup should be to set WAN interface to "dhcp6", and LAN interface to "track interface" on the ipv6 box. You may have to fiddle around with the prefix size (dont remember for timewarner). If that works, your internal lan clients will get their ipv6 addresses from your isp via pfsense prefix delegation (PD). This wont make for static ipv6 addresses, or you having a direct influence on who gets what address. If you want to have static ipv6 addresses on your LAN, and use different network prefixes++ this can be achieved with running a internal dhcpv6 server and assigning addresses in a sense like you have with ipv4 although this is a much more advanced setup :) If you want to setup the latter, im sure this has been covered in many posts on the forum aswell :) Hopefully you got a couple of answers even tho im by far any expert in the field. Please correct me if im totally off tho :) C

I just want to say thanks to everyone who tried to help me on IRC and Reddit. I ended up solving this issue. The fix was to call up TWC and they changed my cable modem to put pfsene into bridge mode. Before I called them I had psfense in a "Pass Through" mode on the Ubee cable modem. I thought that was all I needed to do. With that setup I actually had a network on the cable modem and on pfsense. I also had an addition wifi hotspot coming from the cable modem. Once TWC put the modem into bridge mode, I could no longer access the cable modem interface. Wifi stopped as well. However, my pfsense start getting IPv6 addresses for my clients on LAN! Just in case anyone is wondering, the pfsense configuration is pretty much the same as in http://theosquest.com/2014/08/28/ipv6-with-comcast-and-pfsense/. I did also add a Firewall Rule to blcok all IPv6 traffic coming into LAN from outside of LAN. I also changed the DHCPv6 Prefix Delegation size to 64. 63 didn't seem to work, but I might try again with 56 or some other number lower than 64 to get another IPv6 range for GWN

@empbilly, Forget what you've been doing with IPv4 subnets.  The general consensus in the IPv6 world is that the "subnet" is no larger and no smaller than /64. That leaves you with 64 bits of usable host addresses in a single subnet.  To put that into perspective 64 bits = The entire world's Internet MULTIPLIED BY The entire world's Internet, and there would still be loads of addresses left over squeezed into a single IPv6 subnet. Technically when using only SLAAC its less, but still >40 bits. The only place where you'd see a netmask larger than /64 would be in the case of RA prefix delegation on a router where it is expected that other routers on the same subnet would take  the prefixes, again a /64, to use on one of their other interfaces.

Android devices support SLAAC tho. Setting pfsense dhcp6 server to "Assisted" should make ipv6 come alive on the android clients. C

Yes, but the point is why do I ever need this rule in first place, in order to get the ipv6 connectivity to work :-/

Thank you so much, it's working now :-)

Thanks very much dok! You put me on the right track.  Problem was subtle, but makes sense now in hindsight. I had stacked the SPF records, just as Google does, but if you put a "a" or "mx" inside the TXT record it is applying it to the fqdn of the stacked record, not the base record from which it was included originally. So while I had _spf.example.org.  IN TXT  "v=spf1 a mx ip4:72.x.x.x ~all", the SPF parser was looking for an A and MX record in _spf.example.org, not in example.org which included _spf.example.org. I've cleaned it up, folded mail6 back into mail and I'll give it another spin.  Strange though that it never has issues with IPv4 delivery, yet that is where the source of the problem lies.

You got an IPv6 address on the WAN side, but that won't do any good unless you also get an IPv6 address from a different prefix on the LAN side. It looks as if the ISP isn't honoring the IPv6 prefix delegation request.

Well it is a tunnel so yeah going to be a hit to perfomance compared to no tunnel but i think the small hit is well worth the current advantages to is with most isp a mess the feature i would love to see isp do is assigned /48 or /56 or even a 60 with control of the ptr if u request