That sounds plausible but we have "router solicitation" and that article is about "neighbor discovery"
Will look deeper into that.

I contacted the engineer at my ISP for clarification about the "UUID". It was a typo. He said their gateways use LL, but they tested EN and LLT. I think having an option to preserve LLT and enable it to be entered as a configuration parameter would be useful for situations where preservation of prefix is based on consistent DUID.

How do I set this up on the pfsense side?
Thank you.

Little bit awkward to answer my own question.

Here's a short howto for FreeIPA and pfsense:

For the specific zone in Freeipa Settings make sure "Dynamic update" is set to: true generate key, me using srvxxx.my.domain dnssec-keygen -a HMAC-MD5 -b 512 -n HOST srvxxx.my.domain

Open generate *.private file and copy the Key in the line that starts with Key:
3) On all FreeIPA hosts in replication edit /etc/named.conf by adding

include "/etc/named.srvxxx.key"; On all FreeIPA write file /etc/named.srvxxx.key key "srvxxx.my.domain" {       algorithm hmac-md5;       secret "your_key_from_2)"; }; restart ipa via```
ipactl restart You can add this for DHCP server if you like also for DHCPv6 server. Unfortunately the updates are being refused. I think the grant statement is not just right. I'll update this post if I get it resolved.

I'm guessing that the global address is used because a downstream IPv6 router could pick the RDNSS entry up and re-use it for its own LAN, this won't work if the address is a link-local address because the address wouldn't be reachable outside the original LAN.

In my case, I don't have any routers downstream.

Thanks,
Chris.

@JKnott:

In the case of my ISP (Telus), their edge router does not allocate such an address. Their gateway allocates its global WAN address in prefix+ff/64, using RFC 2464.

Are you using both pfSense and their modem in gateway mode?  If so, put the modem in bridge mode and use pfSense for your firewall.  pfSense is expecting to be assigned a prefix.  But the modem, in gateway mode, is taking that prefix.  I'm on Rogers and have a Hitron cable modem.  It's configured in bridge mode and I have a computer running pfSense as my firewall/router.

No, that's not what's happening. The modem is in bridged mode. (Actually one port is bridged, not the entire modem.) pfSense is getting its own prefix. It's working perfectly, albeit using the "dhcp before RA" patches. (FYI, I'm running two pfSense VMs on the server, each getting its own prefix.)

That's interesting.
No it isn't. In Dual Stack IPv6 connectivity never may rely on any IPv4 configuration parameter, ever.
Fritzboxes have been acting strange with IPv6 for some time now. There is a quite recent (german) article linking to some issues by heise in c't 10/2016. Your issue isn't in there.
This need to be examined in more detail. Try Wireshark or something and make more sense of the Neighbor Discovery packages (ICMP6).

https://redmine.pfsense.org/issues/6667

Instead of manually copying the file to /conf, you could install the cron package and back up the duid file every hour.  Because the file shouldn't change once created, and performing all kinds of extra writes to a CF or SSD is A Bad Thing, I use "-n" (no clobber) to make the backup.

I have the following cron job:

*  */1  *  *  *  root  /bin/cp -n /var/db/dhcp6c_duid /conf/dhcp6c_duid

…and the shellcmd setting (copying from /conf/ instead of from /conf/dhcp/) above.

(This should be improved to use "cp -f" if the timestamp of the copy in /var is newer than the backup.  In most linux distros, the "-u" parameter to cp would take care of that, but I don't see an equivalent in freebsd cp.)

The whole idea is that a user could still manually delete the duid file if they needed to "fix" a broken duid (or get a new lease or something.)  If that happens, you'd want a new backup taken.  If DUID changes, update the backup.  Else, don't write to it.

Of course, it'd be better still if backing up the duid file was incorporated into the scripts that backup (and restore) the dhcp leases automatically.

Thanks for the reply!

When I had that problem, briefly disconnecting the Ethernet cable was enough to cause a change.  It is standardized in DHCPv6-PD.  I supposed it may have a lease time, as DHCP addresses do.  After all, with barely 4000 /48s for each person on earth, we'd soon run out, if unused prefixes weren't reclaimed.  ;)

I run same 2.3.1-p5 amd64 and HE tunnel is stable as you could ever want.  Only times there are issues with it is when there are issues with my actual ISP connection.

What tunnel endpoint are you using?  I use the one in Chicago, they have many many other locations.  They have a status page you can look to find the status of any of the tunnels locations.

https://tunnelbroker.net/status.php

Lets see your tunnel quality vs your isp quality..

tunnel.jpg
tunnel.jpg_thumb
wan.jpg
wan.jpg_thumb

It would be nice if pfSense would support filtering based on MAC address, as some other firewalls do.

Turned out I had some typos in my dhcpv6 config after all the testing I'd done. Now starting dhcp6c manually works and ipv6 is up.

Except that that IPv6 address isn't really an IPv6 address… it's intended to be a way to access or reference an IPv4 host using an IPv6 address (also acceptable would be ::ffff:c0a8:201, if you want the real IPv6 look). A little more depth from a post in the Hurricane Electric forums...

[It] is an "IPv4-Mapped IPv6 Address".  It's another transition thing that is used to represent v4 addresses in a v6.  It's mainly used as an OS API thing to allow applications to do IPv4 via the IPv6 networking APIs (sockets, etc).  That way, when you write an application and want to do both IPv6 and IPv4, you can use the same calls and structures, etc, for both IPv6 and IPv4.  Without such a mechanism, an application such as a web server would have to reserve a socket and do a separate listen on both an IPv4 and IPv6 socket, manage them separately, etc.  With this mechanism, the application need only do a listen using the IPv6 API, and it can accept both IPv4 and IPv6 connections through the same API.  Doing a TCP connect also works similarly.  If the destination address in the sockaddr structure is a mapped address, it'll go through the IPv4 stack, otherwise it'll use the IPv6 stack.

Reference: https://forums.he.net/index.php?topic=635.msg2820#msg2820

So I would expect that using that IPv6 address would create a conflict, if not cause other issues.

Additional reference:
RFC 4291, Section 2.5.5.2 - IPv6 Addressing Architecture, IPv4-Mapped IPv6 Address

Thanks Chris.
I saw you also coded other values to bumb up so that is that and it works fantastic now.
I wish you good luck in your future career mate!

On networks with end user devices, yes, it would be a bad practice to use anything other than a /64.

@sheptard:

I just updated to 2.3.2-DEVELOPMENT which included a update to dhcp6 and seems things are working better. my internal clients have valid ipv6 addresses and ipv6 dns works just fine.

However I can't get any ipv6 traffic to leave my lan, but ipv6 connectivity works just fine on the router.

I just installed the DEV version and for me there was no difference. I configured the prefix and other settings as before. I had to manually start dhcp6c as above. After that, everything was the same as it was with the other version. The dhcp6 gateway status is "pending", but ipv6 is working.

Jimp,

Many thanks for your reply. The static IP address client (::210) is in the NDP Table but I am not sure if the client is talking to pfSense. Please see the attached NDP Table.

Thanks again for your reply!

Untitled.jpg
Untitled.jpg_thumb

Ok … almost that way ..

I got a /64 and a /48 from HuricaneElektric
The /64 is no between the first PFSense and the CARP-Cluster
The /48 is routed to the vIP of the CARP-Clusters WAN-vIP

the first /64 out of the /48 is for the LAN now.
RA is set to unmanaged for LAN-IPv6

Some stuff with default-GW and firewall arround ... Now it works really fine!