Comcast business - /56 fails.. /60 works but delegates /63s?
-
Yeah, I'm seeing a similar problem with 2.3.1p5
I also have Comcast Business but I have a plain SurfBoard modem (6141) that's L2 only. So pfsense should be talking directly to Comcast.
My WAN has DHCP6 set enabled and "Only request an IPv6 prefix, do not request an IPv6 address" is checked On.
My LAN is set to Track Interface referencing the WAN interface down below.
On the WAN page, I initially selected 64 for "DHCPv6 Prefix Delegation size".
However, no clients on the internal subnet get an address, but the LAN interface gets an address with a 56 prefix.
Based on suggestions above, I tried 60, which is correctly reflected on the LAN interface but still no clients receive an address.
I've now tried 63. However the LAN interface shows 57, and still no clients have received an address.
I'm pretty sure everything else internally is working correctly as I'm hoping to use pfsense to replace a Shibby Tomato box, which was working great for IPv6.
I've now tried these settngs:
Select on WAN -> Assigns to LAN:
64 -> 56
63 -> 57
62 -> 58
61 -> 59
60 -> 60
56 -> 64, which actually assigns an IPv6/64 address to internal clients.So it's now working but not as I would have expected.
-
Never found a resolution myself.. Seems buggy to me, but I'm not an ipv6 master.. but I can't see why if they give me a /59, I can't still use /64s.. why would anyone want a /63 on an end user subnet that won't delegate any further?
As you mentioned, no SLAAC because of the /63. I can't figure out why pfsense is assigning it, beyond guessing it never thought it'd be handed a /59. Any combination of hints results in random different subnet sizes.
-
Just curious… are you deleting the DUID file and release/renew the WAN after every prefix size change you make?
If you're not deleting the DUID, then that might account for unusual things happening. DHCPv6 is all based on the DUID, an identifier that should be unique per system/device using DHCPv6. If Comcast issues you a delegation of /64 first, then you want a /60, if your system is still sending the same DUID, Comcast's server sees that you already have a /64 delegation and won't create a new delegation of the size that you now want. Deleting the DUID file followed by a release/renew causes dhcp6c to create a new DUID file, which is then used to submit a DHCPv6 request to Comcast's server. New DUID = new delegation of the desired size.
BTW, residential service can request down to a /60, business service can request down to a /56. Honestly, though, if you don't need more than 16 /64 prefixes for your use, stick with a /60. No need to request 256 /64's when you only need 5.
-
i added the 59 option to /usr/local/www/interfaces.php line 2141 like so:
array("none" => "None", 16 => "48", 12 => "52", 8 => "56", 5 => "59", 4 => "60", 3 => "61", 2 => "62", 1 => "63", 0 => "64")
obviously change the setting on wan to the new 59 option
still getting: "Jul 25 12:21:50 radvd 53058 no auto-selected prefix on interface hn0, disabling advertisements"
but slaac now magically working on the lanmust be something to do with pfsense completely ignoring the prefix id setting on the lan interface page
whatever, slaac works now so im not gonna worry about it -
@virgiliomi:
Just curious… are you deleting the DUID file and release/renew the WAN after every prefix size change you make?
If you're not deleting the DUID, then that might account for unusual things happening. DHCPv6 is all based on the DUID, an identifier that should be unique per system/device using DHCPv6. If Comcast issues you a delegation of /64 first, then you want a /60, if your system is still sending the same DUID, Comcast's server sees that you already have a /64 delegation and won't create a new delegation of the size that you now want. Deleting the DUID file followed by a release/renew causes dhcp6c to create a new DUID file, which is then used to submit a DHCPv6 request to Comcast's server. New DUID = new delegation of the desired size.
BTW, residential service can request down to a /60, business service can request down to a /56. Honestly, though, if you don't need more than 16 /64 prefixes for your use, stick with a /60. No need to request 256 /64's when you only need 5.
that might fix it, depending on your modem/service level.
business service with the big cisco nsa modem in router mode is giving a 59.
there's no way to even request 59 in interfaces.php, so refreshing the dhcp6 lease is going to do nothing in this case.
the problem is pfsense loosing its cookies when it gets handed a prefix other than what it wants. -
I could never fix it.. and I wasn't deleting the DUID file, but I was changing my WAN mac on every attempt.. assumed that would update the duid.
Last night I finally just shoved the Cisco cable modem into bridge mode, gave up my static IPv4, and hinted for a /56, and now i have /64s on my interfaces and SLAAC is working again. DynDns for my future i guess! (Not a pfsense problem, that's a comcast problem).
Would still like to know why pfsense was putting /63s on interfaces though, it sure seems like a bug.
-
Just saw one that requested a /56 (which is supposed to be static to him, yet delegated via DHCP6) and getting a /59 - of all things - instead.
Comcast seems sort of confused when it comes to their IPv6.
-
I could never fix it.. and I wasn't deleting the DUID file, but I was changing my WAN mac on every attempt.. assumed that would update the duid.
Last night I finally just shoved the Cisco cable modem into bridge mode, gave up my static IPv4, and hinted for a /56, and now i have /64s on my interfaces and SLAAC is working again. DynDns for my future i guess! (Not a pfsense problem, that's a comcast problem).
Would still like to know why pfsense was putting /63s on interfaces though, it sure seems like a bug.
it is a pfsense problem if it breaks when it doesn't get the delegation size it wants
-
I only ever got this to work right by ditching my static IPv4 address and going into bridge mode, where I could get my full /56.
Needing my static v4 address again, I've gone back to requesting just a /60, and I still end up with this issue that pfsense is assigning /63s to all sub interfaces, so SLAAC won't work.
no idea really what to do. No configuration seems to work, it seriously seems like somewhere is an off by 1 error.
-
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.
