Comcast business - /56 fails.. /60 works but delegates /63s?
-
Why I can get 5 free static /48s from Hurricane Electric but not 1 from my my ISP I pay for is beyond me….
That's because HE and SixXS (the other common tunnel provider) are run by people who know IPv6 inside out. I have experience only with SixXS and the guy running it knows exactly what he is doing and SixXS is generally regarded a top notch service.
-
@virgiliomi:
Do you have Comcast Business service or residential service? Only Comcast Business provides as small as /56 prefixes. Residential service only goes as low as /60.
Is your Cisco "modem" really a gateway (modem + router)? If so, then the best way to go would be to put it in Bridge mode… otherwise you might find that the Cisco device is doing its own prefix delegation, which might be why pfSense isn't getting what you're expecting it to.
If you can't put it in Bridge mode because you have Business service with static IPv4 address(es), then you'll need to dig into some advanced settings on that Cisco gateway and see if there's something for prefix delegation you can adjust. Just so you know, though... you won't be able to get a /56 from the Cisco gateway if that's what it is receiving from Comcast... it's going to use at least one /64 for its own LAN network (which you'd be connecting pfSense to).
Yup, comcast business.
Is the thought even when I'm using a /60, that because the gateway is taking on of the /64s, that's somehow causing pfsense to delegate /63s to each sub interface instead of /64s?
And you're right, I've got a single v4 static assigned on it, which has precluded me from dumping it into bridge mode.
There are some advanced settings on there, i'll poke around.
I was hoping Comcast was doing something else.. since the Cable modem has:
WAN IP Address (IPv6): 2001:558:6045:xx:xxxx:xxxx:xxxx:xxxx
and the delegated prefix is completely different:
Delegated prefix (IPv6): 2601:648:8103:xxxx::/56
but I guess it's the fact that it's using a /64 on its LAN side to try and offering ipv6 directly. I don't see an advanced option to stop doing that. I can disable DHCP6 on the LAN side of it, but not SLAAC. (plus im assuming I need dhcp6 running here to get the delegations. )
Annoying that I can't use a static ipv4 when the gateway is in bridge mode. ugh.
-
…the Cable modem has:
WAN IP Address (IPv6): 2001:558:6045:xx:xxxx:xxxx:xxxx:xxxx
and the delegated prefix is completely different:
Delegated prefix (IPv6): 2601:648:8103:xxxx::/56
but I guess it's the fact that it's using a /64 on its LAN side to try and offering ipv6 directly. I don't see an advanced option to stop doing that. I can disable DHCP6 on the LAN side of it, but not SLAAC. (plus im assuming I need dhcp6 running here to get the delegations. )
Ok… so... the WAN address and delegated prefix for your Cisco gateway are normal. Everything else you'll be dealing with will be out of the delegated prefix.
As you've found, you can have pfSense request a /60 from the Cisco gateway. That's not surprising... it's likely set up to sub-delegate a handful of those. Your pfSense box should have a WAN address out of the Cisco's LAN /64, but then have a /60 that you can use for whatever you choose on however many different networks you want to set up (up to 16).
Your pfSense WAN IPv6 settings should be set to DHCP6, and the DHCP6 client settings should look similar to those in the attached image.
Your pfSense LAN IPv6 settings should be "Track Interface". Under the Track Interface settings, the interface chosen should be "WAN". Then you can choose a prefix ID, which will be the last character of the /64 prefix. For example, if your Cisco delegates 2601:648:8103:xx10::/60 to pfSense, and you select prefix ID 3 for your LAN, your LAN IPv6 prefix will be 2601:648:8103:xx13::/64
Hopefully that all works for you... the only reason it wouldn't is if the Cisco gateway is wanting to sub-delegate something other than /60, which might result in pfSense not appearing to have any IPv6 connectivity, since it's not getting what it's asking for. You might need to find out from Comcast what prefix size(s) their gateway is configured to sub-delegate for other routers... because that would be what you need to set pfSense to ask for.
-
Yup, that's how its setup/working today. It's just strange, DHCP6 on WAN, track interface on my LAN interfaces..
I just can't figure out why each LAN interface is taking a /63, instead of a /64.. Seems randomly wasteful, and I can't find a single configuration option that would lead to that happening.
In the log at the top, all I can guess is that some how the /59 being referenced is involved.. even though I'm configured to ask for a /60.
I noticed if I change it to a /61 that I hint for, all of my LAN interfaces become /62s.
When I had the netgear gateway from Comcast instead of Cisco, it all sort of just worked, had /64s on my LAN interfaces.. it failed, they replaced with Cisco, and its just been strange since.
-
Same situation here, comcast business on cisco nsa box with static IP4s.
Seems it always gives out /59 except when you select /56 in which case it gives nothingsetting in wan, IA_PD from cisco, what pfsense assigns to lan:
56, none, none
60, 59, 63
61, 59, 62
62, 59, 61
63, 59, 60
64, 59, 59not sure whats really going on here, certainly the cisco/comcast could be more well behaved but that doesnt excuse pfsense
too bad theres no way to set it to 59 in the guinot sure how to make pfsense break up the /59 into /64s or if thats even possible, slaac wont work with anything but /64
I have managed to force the lan side working with 64 setting and dhcpd6 but thats no beuno for android devices -
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.
