We have a DPC3941B in pass through mode with static IPv4 and IPv6 addresses. I am having trouble getting IPv6 routing through the modem to our firewall.
There are three possible ways that this could work:
1. Put the modem in bridge mode and lose our statics. This will allow our Ubiquiti router to use DHCP6-PD straight from Comcast. We've had success with this in the past, but I'm hesitant to do this because we'd like to use our statics.
2. Keep the modem in pass-through mode, feed the modem its WAN and LAN address ranges using DHCP6-PD (this happens), and then our Ubiquiti device uses DHCP6-PD against the DHCP service on the Comcast modem to get its WAN and LAN addresses (this does not happen). We have the stateful DHCP6 option enabled in the modem, but that looks to be standard DHCP6 for clients using the modem as the router, not a DHCP6-PD server that would further delegate ranges to our firewall.
3. Use static routing. We assign our Ubiquiti WAN and LAN addresses within our delegated /56, and then configure a static route in the modem so that it knows where to send the traffic. This would be a great solution, but I can't see any place in the modem to configure IPv6 static routes.
What is the official method for getting usable IPv6 in pass through mode with statics? Do we really need to choose either static addresses or IPv6?
Solved! Go to Solution.
Hey holmosapien (love the handle LOL)! Thank you for reaching out about the IPv6 routing! Most businesses have their networks set up a bit differently based on their needs but this forum thread has some good information that may be useful here, although the modem model is not the same one: Can not get internal IPv6 traffic to route with the CGA4131COM . If none of that helps, please click on our handle (ComcastBiz_Support) and send a private message with your name, the business name, the complete service address (including city, state, ZIP, suite number, etc), and the phone or account number, and any pertinent details about the current network setup so that we can take a closer look into this and help out
That thread suggests that you can't have both statics AND IPv6, since the modem must be in bridge mode for DHCPv6-PD to work. I'll send you a DM, since maybe there are additional options only available to you guys.
I haven't heard anything back, and apparently there's a 1 private message limit.
Is there a way you guys can configure a static IPv6 route on our modem so that we can route some space within our delegated prefix to our firewall? I can handle the firewall configuration, I just need a route on the modem.
The key to getting the DPC3941B working in pass-through mode is to turn off the "rapid-commit" option in the DHCPv6-PD client on the Ubiquiti firewall.
Rapid commit condenses the DHCP exchange from four messages (solicit, advertise, request, reply) to two messages (solicit, reply). Turns out the DPC3941B will only do prefix delegation if your DHCP client performs the full four-message exchange. With rapid commit, the modem will only give you a WAN address and no delegation.
Now we're having a problem where our delegated prefix isn't being routed -- no traffic destined for addresses within our delegated prefix make it through our modem. Traffic from our LAN makes it to its destination, the destination replies, but the reply is lost before it gets back to the WAN side of our firewall. I suspect this issue will be painful to resolve, but we're making progress.
Hey there! I hope you are having a nice Friday evening! I just wanted to follow up with you today to see how everything is working. In reviewing the dispatched ticket on the account, I am seeing that our Advanced Repair team was able to resolve the service issue.
Nope, after 17 days our delegated prefix is still not being routed. Pretty ridiculous.
If I could get someone on the phone I would love to help troubleshoot the problem, but so far everyone has been completely unwilling to communicate with me about this issue.
I am sorry to learn that your delegated prefix is still not being routed after 17 days. I would feel the same way if I experienced a delayed resolution. Would you mind confirming if our Advance Repair team were able to contact you and provide you with any additional information?
No, they have not contacted me at all. I called today at noon to check on the status of the ticket, and they promised me a response within 4 hours. I did not receive any calls.
The issue has finally been resolved. On 12/13 I noted that it was a routing issue that would be "painful to resolve", and it was indeed painful. It took over a month, with over 50 DMs between me and the social media support team here, 2 unnecessary modem swaps, and over half a dozen tickets escalated to tier 2 and closed without them ever contacting me or even looking at the issue.
It was frustrating, but at the same time understandable. We have lived in a world where NAT has been the standard for about 25 years, so even for the tier 2 people IP routing isn't a thing: give the modem a WAN address, the customer handles the LAN side, done. Our issue was that we were being assigned a delegated prefix on the LAN side that was clearly not being routed, but the tier 2 guys would ping the WAN address, get a response, and close the ticket. Even if you could get them to understand that the WAN wasn't the problem, they're programmed to respond that if it's on the LAN side it's outside of their demarcation even when it's publically routable address space assigned by Comcast.
To get it resolved I finally had to escalate the issue to the executive support team, who managed to get it resolved in about 4 business days. Pretty reasonable response time for an issue this complicated, if we could have skipped the month of wasted time before that.
I wanted to provide actionable information for future customers who find this thread, but unfortunately I don't think I can. It will always be painful dealing with a bureaucratic utility when your problem can't be resolved by checking the noise on the line or rebooting the modem, but the silver lining is that this support case is being used to improve the documentation and playbooks used by the tier 2 teams to diagnose and escalate issues. In short, it sounds like there might be some "the LAN is actually meaningful when using IPv6" training coming soon that will make this experience smoother as IPv6 becomes more commonplace.
So, thank you to the support team that has been very patient with my begging and pleading to get the right people on this issue, and I'm happy to finally resolve this thread.
Wow, we are so glad to see that everything is now resolved. We really do appreciate your patience with us and if you do ever need anything, please let us know as we are your one-stop-shop 24/7!