New Contributor
•
10 Messages
Any updates on dual stack router, SMC D3G CCR?
Lots of discussions about getting the Comcast gateways working with routers but they are some months or years old. Might be worth asking this for current status.
I have an SMC D3G CCR, 1 static IP, in gateway mode (i.e. no DHCP). IPv4 has been working flawlessly for years. Now looking at how/if IPv6 can be supported. Have a Linux router/firewall/NAT box behind the gateway. I have the router working nicely under IPv6: I can ping6 everywhere, and even get a 10/10 score at test-ipv6.comcast.net. It is using the Wide-DHCPv6-Client package to get the config info from the gateway and have tried having it request both /56 and /60 prefixes using the IA_PD request (although copied from apparently reliable sources, the config has not been explicitly tested for that), but I get no delegations.
I have tried lots of the tricks to try to trigger getting one, but no luck (power cycling gateway, changing router's WAN ethernet address). I also see numerous reports that the D3G is just not going to work. I did call tech support last weekend, got a ticket sent to Tier 2, but nothing back (and even though my knowledge on this topic is rudimentary, it was a lot more than the tech's -- sad).
Is this a hopeless cause? Will the D3G CCR just not work? Or do I need to persist and find the right person who knows how to provision the gateway to hand out a /56 or /60 prefix?
VBSSP-RICH
Advocate
•
1.4K Messages
9 years ago
Hello mk9pa and welcome,
I am having small difficulty with exactly what your are having issues with on your IPV6. So, I am going to provide you the most comprehensive answer. So, first your IPV4 static IP being ported over to IPV6 has not been established by Comcast at this time. Secondly, It is my understanding that Comcast currently only supports /64 prefixes for their IPV6 dynamic addresses. If you look in the Forum IPV6 Category you will find some posts relevant to your topic. So, if you have a specific networking requirement for /56 or /60 Prefixes, your pursuit with Comcast Tier 2 Engineer is your best option. The Comcast Tier 2 Engineers have high influence on Comcast IPV6 stategic implementation.
0
0
mk9pa
New Contributor
•
10 Messages
9 years ago
Thanks, Rich, for the response. Based on your info, I settled on trying to get a /64 PD only, and for the first time in a long series of learning and experimentation was successful. The SMC gateway's LAN interface gets a 2601:xxxx:xxxx:8100::1/64 address, my router's LAN-facing interface gets a 2601:xxxx:xxxx:81ff::/64 prefix, and successfully advertises it to all LAN devices which then pull appropriate addresses from that prefix and set their default routes back to the router's LL address.
Still, no internet IPv6 connectivity from internal LAN devices. By tracing packets and using traceroute6 both from internal and external sources (e.g. http://www.traceroute6.net) I find:
The last two points are shown by traceroute6's display from http://www.traceroute6.net which shows the packets going all the way to the gateway's WAN address, then stars from there on.
This may be the SMC D3G's fatal flaw, is that correct? IOW, although initial IPv6 rollouts included (supposedly) /56 and /60 PDs, they now do include a /64 only, but this gateway cannot do the routing. Indications, similar to what others have noted, is that the gateway's External Router Delegated Prefix list is empty, and the Gateway Summary's Network pane shows "LAN IPv6 Prefixs Delegations" [sic] to be the same 2601:xxxx:xxxx:8100::/64 that is the gateway's LAN subnet prefix, not the delegated one.
0
0
VBSSP-RICH
Advocate
•
1.4K Messages
9 years ago
You Gateway could have a hardware or firmware issue and you might want to get that device replaced or make sure that the firmware is up to the atest revision level. You would have to contact Comcast high speed internet using the technical option and check with a technical agent to determine whether the SMC is still deficient in IPV6 routing and worst case would be you could upgrade to like a NetGear 3000, if the SMC has this IPV6 routing deficiency.
0
0
Xn0r
Occasional Visitor
•
6 Messages
9 years ago
So it sounds to me like you've tried to get the SMC to do prefix delegation but it's still behaving like it used, to, assigning it's local LAN IPv6 prefix as the delegated prefix? This is what happened last time I played with the modem and tried getting IPv6/PD working.
I had the same experience working with this with my linux dual stack router/firewall. Just can't get it to do PD. But this we beffore the Delegated Prefix pane at the bottom of the Ipv6 setup tab appeared after some firmware update. So was excited that maybe they got it to work.
One thing I've seen through googleing, which I haven't confirmed, is that if your SMC is in bridged mode, as mine is (which is apparently indicated by operating mode "RG" on the gateway summary -> gateway status tab), that IPv6 routing and DHCPv6 won't work correcly. My modem is definitely in bridged mode for my static IPv4s.
Another thing I noticed is that if what it says is correct, the firewall on the SMC automatically blocks all IPv6 traffic through the router by default. On the Firewall -> Port Configuration page, there's a link you can press on that says "Allow public access to LAN side IPv6 Hosts". This pops open a few hidden lines on the page which reveals a check mark "Disable all IPv6 access rules". If what the page says is to believed, you would need to do this for it to pass traffic also.
Let me know if you have any luck.
Xn0r
0
0
mk9pa
New Contributor
•
10 Messages
9 years ago
Hi Xn0r, to summarize what the SMC is doing, with wide-dhcp-client set up on the LInux router behind the SMC:
1) The last 16 bits of the SMC's IPv6 64-bit WAN prefix are 8100 (i.e. 2601:xxxx:xxxx:8100::/64), which would be assigned by Comcast's upstream DHCP server. Both the LAN interface of the SMC and the WAN interface of the router are assigned addresses from this prefix. No problem so far.
2) The SMC appears to delegate a 64-bit prefix whose last 16 bits are 81ff to the router's wide-dhcp-client. I say "appears to" because this prefix is not shown as a delegated prefix in the SMC's network summary, but the wide-dhcp-client on the router picks this up and assigns an address from that 81ff prefix to its LAN interface. So something is not fully working here.
3) Running router advertisements (with radvd) on the router's LAN interface, LAN clients all assign themselves appropriate IPv6 addresses from the 81ff prefix as expected, with gateway being the router's LAN interface. So it appears the entire LAN is correctly configured.
4) Packets from internal clients are routed through the router and out the router's WAN interface, based on results from packet sniffing (tcpdump).
5) Packets sent from an external source (http://www.traceroute6.net) to the router's WAN interface (in the 8100 prefix) are routed all the way through and appear on the router's WAN interface. Running a web browser on the router, I get 100% IPv6 support reported on http://test-ipv6-ct.comcast.net
6) Packets sent from an external source (also http://www.traceroute6.net) to the router's LAN interface (in the 81ff prefix) are also routed all the way through the Internet to the SMC... but no further. They do not ever show up on the router's WAN interface.
My conclusion is that the SMC is swallowing the packets, either rejecting them or not routing them. The SMC is in RG mode as you mention, and I've also tried disabling IPv6 access rules, I've tried enabling specific rules that should allow packets to get to specific internal hosts (on the 81ff prefix), but nothing works.
I've seen that the Netgear CG3000DCR gateway is supposed to work (better?) but its VOiP support may be broken. We use Ooma VOiP for our phone service, so breaking that is not worth getting the optional, low priority IPv6 at this time.
So, I've pretty much given up at this point and completely disabled all IPv6 on my router, am not running router advertisement, and all IPv6 addresses in my network now are link local only. I have investigated options to run dynamic IP addresses and pick up one of the newer self-owned gateways (thereby saving $30/month also), but it's not looking usable because I run an IMAP server which doesn't look easily portable to a dynamic IP.
0
0
tmittelstaedt
Problem solver
•
326 Messages
9 years ago
The SMC is broken with IPv and always has been. Comcast submitted the DHCP-PD bug to SMC years ago and nothing has been done on it. In setting up new Comcast clients out here in Oregon, Comcast isn't even offering the SMC as a new modem for business customers. I ran one of these modems for years and I agree under IPv4 it is rock solid reliable. But, the Netgear under IPv4 is also rock solid reliable and it's IPv6 implementation is not broken.
Comcast is never going to put out an APB saying the SMC is broken under Ipv6 because they have hundreds of thousands of them out there, working. They don't want a rush from people who don't understand anything and just have a knee-jerk reaction to replace something because there's a bug reported on it in a feature they aren't even using. And it's not like the SMC is completely broken under IPv6. As long as you don't have a router or firewall behind it, IPv6 works fine.
The only bugfix that APPEARS to have been deployed on the SMC over the last couple years is that at least 2 years ago when you enabled IPv6 on the SMC, the modem would last about 16 hours then completely lock up. Now, you can enable IPv6 and after 16 hours the modem just stops routing IPv6 but it appears to continue to route IPv4.
0
mk9pa
New Contributor
•
10 Messages
9 years ago
Thanks tmittelstaedt. Do you have any experience with the Netgear CG3000DCR and VoIP? We're using Ooma which is excellent with the SMC, but reports on the Netgear say it's broken, which would eliminate my use of that gateway.
0
0
tmittelstaedt
Problem solver
•
326 Messages
8 years ago
SIp ALG is broken - it isn't just on this cable modem, read this:
https://community.netgear.com/t5/WiFi-Range-Extenders-Repeaters/SIP-Alg-on-netgear-routers/td-p/243294
The bug affects their other devices.i
0
0