Receiving /59 PD results in tracking interfaces using /63
-
@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.
-
If Comcast is anything like my ISP (Rogers), it has nothing to do with the modem. This is handled at the head end office, by the CMTS, which talks to the modem at the customer site. The modem, in bridge mode, as needed by pfsense for DHCPv6-PD to work, should be transparent. The alternative is for it to be in gateway mode, where a single /64 is provided it. In this case, you cannot use another router beyond it, to distribute a prefix.
The hard part may be getting the right people to work on the problem. A couple of years ago, I had a problem and was even able to identify the failing CMTS by host name. Even though both tier two support and a senior tech could see the problem was back at the head end, the appropriate people refused to work on the problem because I was running my own router (pfsense), ignoring the fact it was also happening to my next door neighbour, who was using the modem in gateway mode. It was only after the senior tech took his modem to the head end and tried it with 4 different CMTS, with it failing only on the one I was connected to, did those guys get off their butt to fix their problem.
Bottom line, Comcast should not be providing a /59, when a /60 is requested and that leaves the issue of pfsense not properly handling a prefix that it was given, even if incorrectly.
Incidentally, I have done work inside my ISP's offices in a few cities, though not the one I'm connected to and on equipment connected to the CMTS.
-
@derelict said in Receiving /59 PD results in tracking interfaces using /63:
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.
Because it is not a fix "just for Comcast," even though they are the trouble in the instant scenario.
Expecting pfSense to behave logically is reasonable. Do you think it is reasonable that pfSense mishandles assigning /64s when it receives a larger delegation than expected? Do you believe this is the only potential or possible scenario where this could occur?
-
Comcast or not, this is not the first time I’ve seen pfSense’s inability to handle a prefix size different from what has been requested. It really should be fixed, if for no reason than to provide a better user experience.
Does it require forking dhcpd just for pfSense? I would be surprised if it needed that drastic of a measure. But I’m not a developer, so I don’t know.
The S in IOT stands for Security
-
@jknott said in Receiving /59 PD results in tracking interfaces using /63:
Bottom line, Comcast should not be providing a /59, when a /60 is requested and that leaves the issue of pfsense not properly handling a prefix that it was given, even if incorrectly.
I absolutely agree.
I also believe, however, it is reasonable to expect pfSense to properly handle what it does get as long as it can reasonable meet the need - in this case a /59 in place of a /60 obviously exceeds the need.
-
@virgiliomi
My take on this is if there actually is a problem within pfsense, then it's in the FreeBSD it's based on and any such problem and possible fix should be sent upstream.
-
@jknott said in Receiving /59 PD results in tracking interfaces using /63:
If Comcast is anything like my ISP (Rogers), it has nothing to do with the modem. This is handled at the head end office, by the CMTS, which talks to the modem at the customer site. The modem, in bridge mode, as needed by pfsense for DHCPv6-PD to work, should be transparent. The alternative is for it to be in gateway mode, where a single /64 is provided it. In this case, you cannot use another router beyond it, to distribute a prefix.
Comcast's business offering in regards to IPv6 is a mess as others here have astutely pointed out.
If you have static IPv4 service, you must use one of their modems. They use some flavor of RIP on the cable side to route your block to you and a "consumer" modem, like an SB8200, apparently won't do what they want. Again, if I was fully dynamic, both IPv4 and IPv6, as I am at my home this entire situation would not even have come up and would be handled upstream as you suggest.
The modem Comcast provides doesn't operate in bridge mode when static IPv4 is involved. It is the gateway on my /29 in IPv4. Comcast assigns the modem a /56, then modem assigns a /64 to its LAN interface, and the modem is responsible for handling the rest of it on its LAN interface side. In the instant scenario, I desire to ask it for a /60 but it will only give me a /59 - that's a limitation in the modem firmware as the PD request never goes beyond the modem as it has a /56 to give me address space out of. Now, I have configured pfSense to ask for the /59 and it properly handles assigning /64s internally but there's another problem in Comcast's modem where that traffic is being dropped by the modem - Comcast has told me this much - so I'm still waiting for them to suss that but expect everything to work happily once they do.
I suspect if I paid for a metro E delivered service I could have things done very differently but 200 Mbps DOCSIS is $99/mo whilst I suspect the ethernet service would start at $1000 and go up from there. Yes, I know, you get what you pay for. :)
-
@slykens Pull requests will be evaluated for appropriateness.
-
In the end, pfSense handling of IPv6 isn't ideal, for example not showing what the isp is providing. The router (with modem) I had to buy for my new dsl line shows this and even can delegate prefixes to pfSense. You got what you paid for, I guess.
-
Hmm... look... another ISP (in Germany this time) with the same issue. I guess Comcast isn't the only one broken. Can this be looked into now to see where the problem lies as far as pfSense's handling of prefix size received being different from prefix size requested?
https://forum.netgate.com/topic/159463/ipv6-not-working-wan-and-lan-interface-getting-an-ip-adress-not-any-client
