Hmm. I have an HE.NET tunnel and happily get DHCPv6 + /56 PD from Cox.

I have been watching it for a while. They are honoring the DUID and not changing my prefix despite new modems and WAN MACs. My IPv4 address with them as changed at least three times since I started getting delegated this prefix.

@doktornotor:

Have you tried the "Request only an IPv6 prefix" checkbox on WAN?

Yes. There is my config :

@hda:

You need more (say /60, /56 or /48) from your ISP, to be able to create more /64 LAN's.

The first ISP in Belgium (Proximus) provide only one /64 per client :-(

I think this problem would be solved already if pfSense would not be restricted to CIDR. If a full subnet mask would be used, the top 64 bit could just be left 0 and the lower 64 bits (or at least the EUI-48 part could be 1 so that the IP+subnet mask would ignore the IPv6 prefix and only match the host-specific part. That's how firewall rules for dynamic IPv6 subnets can be easily implemented in ip6tables on Linux.

I have idea however if the CIDR restriction is a pf issue and whether a full subnet mask can be easily implemented.

Stefan

@kpa:

You can use both the static address and the random address at the same time. If you need to open any inbound traffic you use the static address based on the MAC address and for all outgoing traffic that is going beyond the pfSense router the random address gets used automatically. Best of the both worlds.

It's the way I think I'm gonna go, the only thing is that I can't set per-host rules and, more importantly, if the Traffic Graph section ever gets updated to support IPv6, I'll have no clue who is hogging my bandwidth, which is something I often rely upon (only 20 down/2 up).

@hda:

If your /56 prefix does not change, then just don't do Track Interface.
Assign Static LAN's prefix + subnet, suiting your LAN-host IP number.
Use RA Managed (DHCP) or Router Only (Static)

Unfortunately, it's dynamic.  It still seems buggy that pfSense would abandon its static routes after a network bounce though…

FYI regarding the Windows 10 Anniversary DHCPv6 renewal issue… according to the very last post in  this MS Technet discussion, the fix will be in the March 2017 monthly update.

The are the values of my test system (CentOS 7):

[root@test01 ~]# sysctl -n net.core.wmem_max
212992
[root@test01 ~]# sysctl -n net.core.rmem_max
212992
[root@test01 ~]# sysctl -n net.ipv4.tcp_rmem
4096    87380  6291456
[root@test01 ~]# sysctl -n net.ipv4.tcp_wmem
4096    16384  4194304

I checked them on a few other of my CentOS systems and they all give the same results back. I did not make any kernel modifications via sysctl.
The bandwidth issue is also visible when I do a curl -vv http://www.google.com from the PfSense Box

Thanks for the reply!

I will do that in the future, but i was exactly curious on how to do this.
I'm running pfsense 3.2.1 so I'm ipv6 ready.

Yes @marjohn pointed out the error of my ways

Simply setting the IPv6 Prefix ID to 1 rather than 0 means I can split my /56 across another LAN

Hi,

indeed it turned out to be client I was testing it, which was using dhcpcd. It works on other machines here, including Windows 10, GNU/Linux (both with Connman, NetworkManager). Since I was getting DHCPv6 in assisted mode I never suspected the client. Sorry for bothering everyone, but this turns out not to be an issue with pfsense after all.

Kind regards,
Bartosz

@luckman212:

Yesterday I upgraded from 2.3.2 to 2.3.3 and from there up to 2.4.  My build is now 2.4.0.b.20170131.2311. Took a bit of time to get the cobwebs brushed away, remove some no-longer-needed Patches, etc but for the most part it was smooth and painless.

So far so good, can't say if the dhcp6c issue is resolved yet but I'll know soon enough.  I saw some additional fixes were pushed today that haven't made it into snaps yet so that should get even better.

Yes, the PR today has gone upstream, a strange one that, deleting the pid file before all processes are complete is not nice. :)

Use an HE.NET tunnel or get an ISP that does real IPv6.

Err, no i don't think you can start a dhcp server without a scope definition (valid poole range). It would defeat the purpose the server. Just enter a scope and define any static leases you desire outside of the defined pool. Then pick the assisted mode from the router advertisments page. Or maybe just forget about the dhcpv6 server and use static addresses on the clients.

I don't think so.

6rd is still their "solution" for any users that aren't on enterprise fiber.  I asked an enterprise sales guy (for one of my clients) to chase down the issue a little but I don't think he gets it.

@sense1138:

No configuration seems to work

That's what I found. With the Cisco DPC3939B the connection is fragile and won't work for very long. By constantly rebooting the router and pfSense I could get ipv6 to stay running for days, hours, or minutes. Reboot router first, reboot pfSense second. No pattern as to when ipv6 would quit.

I can't ditch my 5 static and I have a satellite location that has run a Netgear+pfSense for months with no ipv6 outages. I solved it by asking for a Netgear CG3000DCR. The Windows clients came up immediately and have been up for several days. The Linux clients needed a reboot to get ipv6 smart. The only lingering problem is that if the Netgear is rebooted, pfSense will not restore connectivity automatically. pfSense must be restarted. Even worse, when there is a big change, ipv6 won't work at all until I reset pfSense to defaults and start again. ipv6 is the only thing pfSense is doing and I have all the steps written down so it's done in a few minutes. Maybe I'm just deleting the DUID file in a roundabout way.

The Netgear, like the Cisco, also gives prefixes different than those requested. The difference is that the Netgear doesn't stop routing ipv6-PD in a few minutes. For the Cisco, I tried making a table of the requests to the results but when I saw that a single requested prefix could result in at least two different received prefixes, and no pattern to which you would get, I gave up.

Trouble is the switch chip on the Netgear runs way too hot. The new Netgear arrived with 2 ports already burned out. I'm going to rig up fans to keep the other two from burning out too fast.

One thing that became clear after many months of testing is that pfSense ipv6 routing is not compatible with vlans using a single port. You must have multiple ports.

I don't use SLAAC. DHCPv6 clients can be forced by the DHCP server to give up their addresses. Once you hand out a SLAAC address, it is difficult to force the clients to give them up. When I see ipv6 not working I can just shut it down until I get it working again.

My testing and reading shows this:
Netgear: ipv6-PD works. I have not seen reported the timeout bug so this may be solved.
SMC: ipv6-PD does not work.
Cisco: ipv6-PD works for a short time.

I keep hoping that pfSense or Comcast fix the bugs wherever they may lie and it keeps not happening. I've considered giving up and just running ipv6-nat just to maintain continuous connectivity. Pinging from the pfSense interface address always works so long as you stay away from vlans. It's the PD routing that breaks down all the time. That the dashboard has no information about PD doesn't help.

I did mean:
xxxx:xxxx:49xx:0200:0000:0000:0000:0000/56
:Þ

But I've just reinstalled the entire router and reconfigured it which solved all the problems. Even the update problem where it could not contact the update site.