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.

It's a bug in netgear IGMP Snooping https://community.netgear.com/t5/Smart-Plus-Click-Switches/GS724Tv4-Enabling-IGMP-Snooping-on-a-VLAN-Breaks-IPv6-on-that/td-p/995071

@johnpoz: Dude I have been PUSHING for many years..  The problem is I work for a tier 1 telecom subsidiary, the service branch..  And if the customers don't ask, then they don't do ;) Believe me if was working at my old enterprise sort of job, would of been on ipv6 years ago there.. Where I had some input to overall direction for the enterprise.  Current position is more a fire fighter to why something is not working that I rarely had any say on the design of..  Or on some projects just the banana bender - make this happen.  Shit I have been complaining for years as well if your not going to use IPv6 then you shouldn't leave it unconfigured on the images your deploying..  Which finally got some traction when I showed them the % of traffic that is noise when 400 machines on just 1 segment with the default windows setup produces related to ipv6 when you leave it default out of the box.  Not multiply that by all the other segments with 1000's of more machines and producing a bunch of noise your switches have to handle for no reason at all.. As of late I no longer in the DC side of things other than when problem to fix, and more wan, etc. So even less input to what they do in the data centers.. I can see their point though - until such time they have a customer that needs/wants ipv6 there is little need to fire it up in a data center that is all rfc1918 space other than the edge.. And when you have a /16 of public space to work with and using a very very small % of that ipv6 doesn't really scream required.. I have been playing with ipv6 for many many years.. Got my free sage tshirt back jan of 2011 from HE ;)  I have been pushing for it, have had ipv6 on my network for years!! We've had ipv6 since around 2012. It's amazing how much traffic will be carried over ipv6 if you have it available. I don't watch it closely now that I'm using pfsense, but when I was using sophos utm it emailed me a report every month. Some months it was 80-90%. And that was using a hurricane electric tunnel, which I will continue to use until pfsense 2.4 is released (hopefully with the RA fix). At that point, I'll switch to native dual stack. The latency and bandwidth of ipv4 and ipv6 are the same, if not better for ipv6.

@stan-qaz: Do you have pfSense set to ignore the modem's default internal address? I use this for my SB-6183 on Cox Cable. … To make the DHCP client reject leases from an undesirable DHCP server, place the IP address of the DHCP server here. This is useful for rejecting leases from cable modems that offer private IP addresses when they lose upstream sync. Just a note that if you do this, you won't be able to check your modem's status page if it loses sync with your ISP for whatever reason. So if your modem is rebooting and you want to check the signal levels, event log, or something else, you won't be able to since pfSense is ignoring the modem's DHCP server.

This is fixed for me now, it was a configuration error on my side. The reason for the reloading of settings was that in Telekom's new BNG network the DHCPv6 would not hand out an IPv6 address for the WAN interface, only DNS server addresses and the delegated /56 prefix comes in via DHCPv6. Because of the empty addresses part of the DHCPv6 reply, dhcp6c would retry the request after a timeout of 0 seconds. In the new BNG network the address for the WAN interface comes in via Router Advertisement. This is now fixed for me by checking "Request only an IPv6 prefix". IIRC in the "old" Telekom network, the WAN interface would also get an address via DHCPv6.

confused - why are you trying to use the /48 as your transit.. You are using downstream routing at your pfsense router.. So your carp would be your transit network, which looks with that 48 to overlap all your downstream networks.

@doktornotor: Huh? That thing does not even test IPv6. There's nothing wrong with 1480 in the first place. Yeah I hear ya, all I know is if I change my lan settings to 1480 pfsense starts working but I am unable to get to speedtest.net.  If I turn v6 off all of it works, so its something to do with the 6rd, most stuff works when the mtu is blank but I noticed a couple sites like pfsense forum and netgate not working.  Not sure how to figure what the real issue is and what needs to be corrected but something is still not 100%. The other issue I appear to have is if I change my MTU settings on my lan the lan card on pfsense goes sideways, I have to reboot my box to bring it back on line, not sure whats causing that either, ughh.