Contributor
•
19 Messages
CGA4131COM - DHCPv6-PD is broken and not routing packets
Maybe the community can help my problem on IPv6 and the Technicolor CGA4131COM modem not actually doing a DHCPv6-PD properly.
There are several posts here that document the same problem but then go quite... maybe they got fixed? Maybe they gave up.
Please see:
https://forums.businesshelp.comcast.com/t5/IPV6/DHCPv6-PD-Worked-With-CG3000DCR-Now-Broken-With-CGA4131COM/m-p/39195#M1019
https://forums.businesshelp.comcast.com/t5/IPV6/Prefix-Delegation-w-CGA4131COM-working/m-p/37468#M965
User fwpowell has beat this drum as well.
The problem:
I upgraded to 600mbps service for my business.
For the past 3 years I have had 150mbps or 300 mbps service with the Netgear CG3000DCR and the Cisco DPC3939B, the internal configuration has been the same for those years. I have not had an IPv6 delegation problem in those 3 years and enjoyed great service. Ever since I upgraded to the 600mbps service, which required the CGA4131COM modem, my configuration has been broken.
The CGA4131COM manifests the problem as such:
The modem will happily delegate a /59 network via DHCPv6-PD proof:
Feb 10 00:58:50 firewall-primary dhcp6c[14910]: reset a timer on mvneta2, state=SOLICIT, timeo=0, retrans=1091 Feb 10 00:58:50 firewall-primary dhcp6c[14910]: get DHCP option IA_PD prefix, len 25 Feb 10 00:58:50 firewall-primary dhcp6c[14910]: IA_PD prefix: 2603:300b:xxxx:20::/59 pltime=345600 vltime=345600
The router now assigns these IP's to the internal interfaces:
Feb 10 00:58:50 firewall-primary dhcp6c[14910]: create a prefix 2603:300b:xxxx:20::/59 pltime=345600, vltime=345600 `Feb 10 00:58:50 firewall-primary dhcp6c[14910]: add an address 2603:300b:xxxx:3a:208:a2ff:fe0c:e8e2/64 on mvneta1.300 `Feb 10 00:58:50 firewall-primary dhcp6c[14910]: add an address 2603:300b:xxxx:24:208:a2ff:fe0c:e8e2/64 on mvneta1.4 `Feb 10 00:58:50 firewall-primary dhcp6c[14910]: add an address 2603:300b:xxxx:21:208:a2ff:fe0c:e8e1/64 on mvneta0 `Feb 10 00:58:50 firewall-primary dhcp6c[14910]: add an address 2603:300b:xxxx:22:208:a2ff:fe0c:e8e2/64 on mvneta1.100 `Feb 10 00:58:50 firewall-primary dhcp6c[14910]: add an address 2603:300b:xxxx:26:208:a2ff:fe0c:e8e2/64 on mvneta1.6
So far everything is good and behaving like a documented standard. Now the internal interfaces try to ping an external site:
root ~ % ping6 2001:558:1c2:449::1 PING6(56=40+8+8 bytes) 2603:300b:xxxx:3a:208:a2ff:fe0c:e8e2 --> 2001:558:1c2:449:xxxx::1 --- 2001:558:1c2:449:xxxx::1 ping6 statistics --- 10 packets transmitted, 0 packets received, 100.0% packet loss
Looking at a packet capture of the wire between the router and modem we see:
00:39:23.389365 IP6 2603:300b:xxxx:3a:208:a2ff:fe0c:e8e2 > 2001:558:1c2:449:xxxx::1: ICMP6, echo request, seq 21, length 16 00:39:23.400403 IP6 fe80::10:18ff:fe12:1a5d > ff02::1:ff0c:e8e2: ICMP6, neighbor solicitation, who has 2603:300b:xxxx:3a:208:a2ff:fe0c:e8e2, length 32
The modem does not recoginize the sending IP, so it does a Layer 2 'who has' to see if something responds. Since this is a Layer 2 broadcast on a seperate VLAN than the internal Layer 3 interface, nothing responds and the packet is dropped. Nothing will ever or should respond to this request. If the modem was working properly as a router for a range it delegated it would forward the packets without a 'who has' request.
What should be happening?
The modem should forward the IPv6 packet on since it delegated the prefix. I believe this is due to the firewall never actually being disabled in the modem. The logs show:
FW.IPv6 INPUT drop , 272 Attempts, 2020/2/09 18:09:05 Firewall Blocked FW.IPv6 FORWARD drop , 2409 Attempts, 2020/2/09 18:09:05 Firewall Blocked
If the firewall was disabled, why would there by drops recorded? Also this ould be why it is working in a 'true bridge' mode which is only possible if the account does NOT have static IPv6 addresses.
What can be done?
This is a very simple thing to test for Comcast. Provision yourself a modem, launch any number of free routing/firewall products (pfSense, Linux with dhcp6c, any Cisco router, etc.), get a DHCPv6-PD from the modem, assign an IP internally, try to ping anything... even the modem's internal interface.
So far I have done an escalation with my account executive, I have tried for 2 weeks to get a resolution with the support team on the forums, tried multiple calls to the support call center, had 3 tech visits, and other conversations with Comcast employees. The only answer I get from Comcast is that they do not support anything past the modem and they do not support anything beyond the first /64 of the /56 IPv6 assignment.
At this point if you require IPv6 address space from the assigned /56 I would avoid any speeds over 300mbps and ask from any other modem in Comcast's offering.
Comcast_Gabriel
Official Employee
•
294 Messages
4 years ago
Hi, there! Thank you for your patience and for reaching out and for providing this information. We are very grateful for your business and time. Most of what you are describing here is beyond our line of demarcation or outside the scope of our services. As internal networks vary so drastically from business to business, I can only provide my expertise for our equipment or wiring. With the static IPv6 prefix delegated to a device, /56 is assigned for your use. What I would like to do from here is look at the modem in depth. Please click on my handle (Comcast_Gabe) and send a private message with your name, address, and account number or phone number listed on the account.
0
0
STS-134
Visitor
•
1 Message
4 years ago
Comcast_Gabe: I just had exactly the same issue, and I had to go back to a BWG (Business Wireless Gateway) modem, the black tower. And IPv6 started working properly immediately after switching back.
You are incorrect that the problem is past your "line of demarcation". Yes, YOUR demarcation ends at the modem, but it's THE MODEM that is misbehaving. Routers, when giving blocks of addresses to other devices via DHCPv6-Prefix Delegation, should then add the static routes for these address ranges to their routing table so that packets are routed properly. The CGA4131COM modems are NOT doing this, and therefore, the packets do not route properly. By running a packet sniffer on the WAN interface of my downstream device, I was able to tell the following:
(1) When pinging from the WAN interface (IPv6 address not assigned by Prefix Delegation and comes directly from the same /64 as the modem's gateway address) I can see ping packets going outbound to Google and get replies back.
(2) When pinging from the LAN side of my downstream device, I can see ping packets going out, but nothing comes back
(3) When pinging an IPv6 address on my LAN side (a *public* address that was assigned to my downstream device via DHCPv6 Prefix Delegation) from an external source, off the Comcast network, I do not see any packets from the external source hitting the WAN port of my downstream device. However, I do see a Neighbor Solicitation frame where the Comcast modem is asking the downstream device "who has this address?". This behavior is incorrect. The Comcast modem is a *router*, not a switch or a IPv6 client, and it should already KNOW where to send the packet based on the entries in its routing table, which it should have added when it gave the downstream device the PD entries.
This is similar to a IPv4 NAT device that runs a DHCP server giving an address to a device via DHCP(v4), and then refusing to actually route packets to or from said device because, although it gave it an IP address, it refuses to add any entries to the routing table when the device tries to reach an external site...and then the manufacturer of said device having the gall to say that said issue is "beyond our line of demarcation". No, it's not. Your modem is broken and instead of telling your customers who are pointing this issue out not only in this thread but also in the other one that it's not your problem, you need to tell the manufacturer to fix it.
Stop using your customers as beta testers. That this issue was not caught in one of the first 10-20 tests done on this modem, BEFORE it was even pushed out the door, really says something about your and your manufacturer's testing process. And if you want me to be a beta tester for Comcast, I'd be happy to -- but I expect to be paid for it. As it is, I had to spend at least 4-6 hours of MY OWN TIME diagnosing this issue because you guys dropped the ball.
0
CC_Michelle
Official Employee
•
526 Messages
4 years ago
Thanks for taking the time to reach out to us and welcome to the business forums. I would love to assist with the IPV6 routing issues. Can you please reach out through private message with your first and last name, full service address and account number or phone number?
0
0
mahdi_c
Contributor
•
12 Messages
3 years ago
This issue has resurfaced this week in Seattle. Was there a change done to the modem/comcast business gateway firmware? (I know there are updates pushed multiple times per week).
2
0