@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.

"I'm an ipv6 novice"

Doesn't sounds like you should be running a email server on ipv6 then ;)

"but experimenting with IPv6 to be prepared for the eventual change."

And I commend that fully.. I dabble with ipv6 myself to keep my hands in it for when might actually use it at work..  Which is truly lagging, I will most likely be retired before ipv6 is fully mainstream to be honest..  I would suggest go take certs tests from HE, you can get a free tshirt when you pass sage level.

I by no means am a dhcpv6 expert, but what dok mentions is going to be where you get started.. The DUID is going to be per machine, and this is normally how a dhcpv6 would give you your IP.. Its not going to give you multiple because you have multiple interfaces in the same network.. Now this could be tied with the IAID I assume to allow you to have each interface get an IP in the same prefix.

You would have to read the rfc's to be sure.. And then again would depend on if pfsense supports that, and if your isp support that..

I don't really see when this would be useful though.  Such a setup shouldn't really exist.. Why would you put 2 interfaces from the same machine into the same network?  Especially on a ROUTER!! You might do it on some host I guess serving up websites or something on different IPs.. But on a router - no.

Simple solutions to your problem.. Use different isps ;)  So each interface would get its own IP in its own prefix..  Use HE for ipv6, you could for sure setup tunnels on each interface.

Even if pfsense supports having each interface get an ipv6 in the prefix, doesn't mean your ISP does.. You could contact them - good luck with that ;)

I guess the WAN 'tracks' something for a list of LAN's - this list will be setup explicitly when the WAN is set - this list will be populated when all the LAN's exists AND when WAN is saved.
Something like that ^^

I can understand why ISPs might not want to statically assign non-business customer prefixes, as the customers may come and go.  However, through the use of the DUID, the assigned address should not change, at least not for the lifetime of the DUID.