Receiving /59 PD results in tracking interfaces using /63
-
Hello All -
I am fighting with Comcast Business to sort out some issues with IPv6. They really don't understand how it works but I can live with that if I wasn't having what looks like a problem with pfSense, also.
In my case, the modem they foisted on me will only hand out a /59. If pfSense asks for a /60, it will accept the /59 but then assign /63s to the tracking interfaces. This causes slaac not to work.
Why would pfSense assign /63s to those interfaces configured to track the WAN?
-
Do you understand how DHCPv6-PD works? The /59 or /60 is the prefix assigned to pfsense, which is then split into /64s for each interface. A /60 gives you 16 /64s and /59, 32. You many or may not have a /128 WAN address.
-
@jknott Yes, I understand how IPv6 works. Did you read my post?
To be absolutely clear -
The WAN interface is configured for PD with a hint of /60. The modem responds with a /59 which pfSense then accepts. Ostensibly, this should not be a problem - why should getting more than we asked for be a problem?
The LAN and OPT interfaces are configured to track the WAN interface with appropriate Prefix IDs. When pfSense sees the above, the TRACKING interfaces (LAN, OPT, etc) are assigned /63s from the /59 assigned to pfSense by the modem. Since these interfaces are /63, slaac does not work and the devices on those networks do not auto configure as they would if the interface had a /64 assigned.
The problem is that when pfSense receives the /59 on the WAN interface, the inside interfaces (LAN, OPT, etc) that are configured to track WAN are then configured with /63 instead of the appropriate /64.
-
@slykens said in Receiving /59 PD results in tracking interfaces using /63:
are assigned /63s from the /59
That makes zero sense.. And if that was the case I would think the forums would be on fire with people complaining..
Please post up this - your saying the status of your interface after is picked prefix out of what was delegated to you is /63? Please post up screen shot of that.
Your running what version of pfsense 2.4.5p1?
-
Attached is a screen shot showing what I see. I apologize for the bit of potato redaction but I think the information needed is clear.
In this scenario pfSense asks for /60, the Comcast modem offers /59, so pfSense takes it.
edited to add - I have set pfSense to request a /59 and it will properly assign /64s to the tracking interfaces.
-
@slykens said in Receiving /59 PD results in tracking interfaces using /63:
I have set pfSense to request a /59 and it will properly assign /64s to the tracking interfaces.
Really - yeah this needs to be reported. My ISP doesn't provide IPv6, so I have no way to even try to test this other than setting up a downstream pfsense..
Lets call in @jimp and @Derelict and see if they have some info or what info you could post up about this.. I will have a quick look see in redmine to see if already reported.
But from what you posted and what you say you can fix it by just requesting /59 does seem like something really weird going on..
-
@johnpoz I concur, doctor, something isn't right, thus my posting about it. :)
I'm happy to provide what other information I can so, anyone, please ask.
To provide a little more insight - this is on Comcast's business service with their CGA4131COM modem and static IPv4. The modem will only give me a /59 as best as I can tell and initially it wanted to give me a /59 that started with the /64 it had assigned to its LAN interface - something that is obviously braindead and won't work. It is now at least offering me the ba40:: network as a /59 (instead of ba00::) but there is apparently something in the modem that is dropping traffic destined for the delegated network that is preventing it from working for me. I have a tier 2 tech helping figure this out and right now they seem to agree it is a problem on their end and likely in the modem itself.
My home residential service with an SB8200 but purely dynamic works perfectly with pfSense requesting a /60 and distributing /64s to my inside interfaces as I desire.
-
While I don't disagree about the problem, I also have to ask... if you know that pfSense is getting a /59, why don't you adjust the setting in WAN to show that you're getting a /59? Then most likely all will begin working as expected.
The S in IOT stands for Security
-
Yeah he did that..
- I have set pfSense to request a /59 and it will properly assign /64s to the tracking interfaces.
But there is still something wrong if a slightly different PD gets sent that the lan side mask is not a /64
-
It would be really nice if Comcast fixed their IPv6 deployment. You should be getting what you ask for. Seems all of their IPv6 modem/router code is hopelessly broken. /59 is just plain silly. Calling them to try to get them to fix it is like calling this guy:
As I understand the problem, there is no good way to get the issued PD out of dhcp6c. It doesn't matter what they actually delegate. All the math done in pfSense assumes you receive what you asked for.
This same issue holds a lot of IPv6 things that would be nice like an automatic "Alias" for the delegated prefix and things that would be much more sane if there was an interface to get the delegated prefix from dhcp6.
-
It would be interesting to see what a packet capture of the DHCPv6-PD sequence shows.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
@jknott dhcpv6-60-59.pcap Attached please find a capture of the dhcp conversation.
In this cap, pfsense asks for 60, the modem responds with a 59, pfsense then requests the 59 and the modem assigns it.
-
@derelict said in Receiving /59 PD results in tracking interfaces using /63:
It would be really nice if Comcast fixed their IPv6 deployment. You should be getting what you ask for. Seems all of their IPv6 modem/router code is hopelessly broken. /59 is just plain silly. Calling them to try to get them to fix it is like calling this guy:
Comcast's residential IPv6 works great. Business is a total mess. Now they are chasing a pre-routing firewall in their modem that appears to be dropping packets destined for the delegated network on my side. At least the tier 2 guy I am working with acknowledges there is a problem and is trying to get it corrected. As mentioned, I can happily live with the /59 and pfSense will work properly with it when the configuration matches, but I can't yet pass traffic due to the modem's wonkiness.
As I understand the problem, there is no good way to get the issued PD out of dhcp6c. It doesn't matter what they actually delegate. All the math done in pfSense assumes you receive what you asked for.
Perhaps not a perfect solution but the prefix acquired does show up in the dhcp.log so it should be parseable to get the info:
Dec 24 11:19:28 gateway dhcp6c[53540]: get DHCP option IA_PD prefix, len 25
Dec 24 11:19:28 gateway dhcp6c[53540]: IA_PD prefix: 2603:3007:x
::/59 pltime=344481 vltime=344481This same issue holds a lot of IPv6 things that would be nice like an automatic "Alias" for the delegated prefix and things that would be much more sane if there was an interface to get the delegated prefix from dhcp6.
The folks pushing Netplan on Ubuntu have finally fixed token support. Small steps are making it better all the time. I agree overall on the sentiment - it would be awful nice if everything "just worked" the way it has been advertised to. I don't know that adoption would finally become universal but it wouldn't hurt. So many of my IT peers are ambivalent to anti-IPv6 that it feels like I'm the odd one out.
-
@virgiliomi said in Receiving /59 PD results in tracking interfaces using /63:
if you know that pfSense is getting a /59, why don't you adjust the setting in WAN to show that you're getting a /59? Then most likely all will begin working as expected.
I said in the edit to my third post in this thread that that is what I have done. That does not mean that pfSense is behaving properly, however.
-
- I see the /60 solicit
- I see the /59 offer
- I see the /59 request
- I see the /59 provided
So, Comcast is giving a /59 when a /60 is requested, but pfsense then accepts it. I have no idea why pfsense is messing up a prefix that is accepted, but you should check with Comcast about why they're providing a /59, when a /60 is requested.
PfSense running on Qotom mini PC
i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
UniFi AC-Lite access pointI haven't lost my mind. It's around here...somewhere...
-
@jknott said in Receiving /59 PD results in tracking interfaces using /63:
I have no idea why pfsense is messing up a prefix that is accepted
Yeah that is what I think should be fixed.. I hear ya the ISP is messed up.. But if you get /X as your prefix no matter if its what you asked for or not as far as size... I would hope pfsense should create your /64s from this - as long as its large enough to create your prefixes off of, etc..
Its quite possible the coding of this is more involved than my noncoder brain thinks it is - but it doesn't seem like a optimal result setting /63s - which are not good..
It very well could be a very low priority thing as well.. Since you would hope 999999/1000000 times the ISP would hand you the prefix you request..
Maybe logging the mismatched prefix request vs assigning a bad prefix on the tracking interfaces would be better than assigning a /63 or /whatever that is not going to be good.
-
@johnpoz said in Receiving /59 PD results in tracking interfaces using /63:
It very well could be a very low priority thing as well.. Since you would hope 999999/1000000 times the ISP would hand you the prefix you request..
I agree it’s not a dealbreaker but in this situation fixing pfSense is more agile than expecting Comcast to resolve their rectal cranial inversion quickly and likely benefits others who may have simply given up since IPv6 isn’t a requirement in many deployments. I’m very lucky to be working with a tech at Comcast who has not yet told me to pound sand.
I also think it would be good if pfSense would respond to brain dead situations by doing the best it can - like you said, if there’s enough space to make /64s then do what it can. This isn’t a work around just for Comcast, per se, it would be a fix so pfSense would behave as expected.
-
@jknott said in Receiving /59 PD results in tracking interfaces using /63:
- I see the /60 solicit
- I see the /59 offer
- I see the /59 request
- I see the /59 provided
So, Comcast is giving a /59 when a /60 is requested, but pfsense then accepts it. I have no idea why pfsense is messing up a prefix that is accepted, but you should check with Comcast about why they're providing a /59, when a /60 is requested.
I don’t mean to be rude but I don’t think you read what I’ve posted. This is the second post in the thread from you where you either misunderstand what has been posted or you try to direct the conversation away from the issue posted about, in this case that pfSense mishandles assigning tracking interfaces /64s when it receives an “unexpected” delegation.
To go down that road, yes you are correct that Comcast should handle it correctly, especially as a /60 is smaller than a /59, but Comcast has insisted to its customers for years that their modems work fine and when they finally get cornered have been telling customers to get bent. In my case the tech I am working with has taken it seriously and I (and other Comcast customers) can live with a /59 instead of a /60. PfSense properly handling the unexpected delegation would make the whole thing work more smoothly. I suggest this is important to fix as Comcast is a technology leader and their methods are likely to be replicated by other ISPs in the US and it’s not like it is a workaround only for Comcast - it’s fixing it so it behaves properly.
-
@jknott They send a /59. It's really stupid. So are they.
-
@slykens Why should pfSense have to code around Comcast's long-term inability to provide the service you are paying for? Comcast Business IPv6 is a complete clown car.
I have already explained the technical limitations surrounding this issue from the pfSense perspective. If you are supposed to get a /56 or a /60 and explicitly request a /56 or /60, and get a /59 (!) instead it is Comcast's provisioning that is broken - not the firewall. Should pfSense assume the technical debt in forking and maintaining their own dhcp6c because Comcast is hopelessly broken, continues to be broken for years, and tells you your third-party firewall is beyond our demarc and we can't help you with it despite multiple customers all providing the same data that Comcast's gear is at fault?
Comcast doesn't care. Use an HE.net tunnel if Comcast is your only choice.
