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