Is 32,000 a big number? (I ran out of fingers - Let me take my shoes off) /48 works really well - I think I have about 5 right now.  I will give them back if people start running out. I agree with derelict.

Hmmm just a guess, is it possible that no RA is being send because client already exists in NDP table?

Ever get anywhere with your issue?

@digitalsushi: we have a comcast router we are leasing because we have a static v4 /28 routed to us with a comcast rip client configuration we are not allowed to run on our own hardware.  This router's configuration is locked in place - if we used our own router, we could do the /60 PD req no problem. I should have mentioned this earlier but I didnt want to take my own thread off topic. This was a critical piece of info. Comcast doesn't support more than /64 on their own gateway devices. They don't yet support "sub-delegation", where you would be able to have a /60 or /56 on their gateway (which is required to be used for static IP addressing) and then sub-delegate prefixes to other routers (like pfSense). That's why you can't get more than a /64, because you're using Comcast's gateway. If the static IPv4 addresses weren't necessary, then you would be fine to use pfSense as your only router (have theirs put into Bridge mode, or buy a modem-only device) and request a /60 or /56 for IPv6.

And again why do you have them in floating in the first place? Are they set to quick, rules in floating are for SPECIAL rules.. For example " I'm just not concerned with IPv6 on those VLANs." But you had a rule that should allow ipv6 out, which would be applied to ALL interfaces..  I don't recommend putting anything in floating unless it really needs to go there.

I think I agree with a lot what people are saying here but it just seems like a engineering nightmare. To my point earlier who knows what hashing algorithm they are using to randomize the mac address. Is it even a hash?  I'm just glad that I am not the only one that thinks everything about IPv6 is NOT all good. NAT just seemed like an elegant solution to a problem and now we have IPv6 and it just doesn't seem right to me, but we will see. If IP addresses was all we were worried about they could have just added an extra octet and called it a day. Hell you could even make that octet Hex which would have given you 48bits in the address space with is a ridiculous amount of IPs, but i guess we couldn't call it an octet, maybe a hextet. Older devices would just read the lower 32 bits; newer device would read all 48 bits. I read this book about every open system becomes closed, let me check the name real fast. The book is called "Who controls the Internet" it is on audible if you don't have time to actually read a physical book I definitely recommend you checking it out. I do appreciate everyone opinion though, it is good to hear different perspectives.

I think IPV6 is ready for the world and am baffled as to why it hasn't replace IPV4 already. So, yeah - I agree.

I'm having the same issue.  I originally had IPv6 set up to track the 6rd connection on the WAN interface, but later switched to a static LAN IP with the DHCPv6/RA server, but even with that, I still only ever get IPv4 addresses in DNS (except for static mappings).  Google hasn't been much help, and I can't find anything helpful in the pfSense documentation, beyond settings for the IPv4 mappings.  Any suggestions?

I'm ignoring it…

found it: services.inc

Looking at the 0.0ms RTT and Monitor "none" on HENETv6_TUNNELv6 GW… Are you absolutely sure you did NOT tick the "Disable Gateway Monitoring" instead of "Default Gateway"?

There's really no point in dropping MTU to 1280 on LAN.

split to its own thread since it had no relation at all to where it was originally posted.

@jpp: However, I noticed that pfSense assigns the client mac address as the local part of the IP6 address. No, your clients are doing that themselves. They should be using privacy addressing, so the v6 IP with the MAC in it is assigned, but not actually used for Internet traffic. Check on privacy addressing with your client OS(es) of choice. It's on by default in every recent mainstream OS (Windows, Linux, OS X, iOS, BSDs, etc.).

Also there is a bug when prefix length is not 32 for 6rd. Check this section of the forum for a  fix.

To add: MTU values must be in alignment. Test if you need 1492 with the PPPoE (not the 1500). So in pfSense Interfaces WAN & LAN set MTU 1492. Assure with rebooting in line with the MoDem. Expectation: if MoDem in bridge > if MoDem/PPPoE(IPv4) on WAN-iface > if WAN-DHCP6 > then a fe80…. on WAN-iface and a 2001:44b8:etc/64 on LAN-iface.

The ISP is useless. Get a tunnel from HE and ditch the ISP's IPv6 clusterfuck.