DHCPv6 tends to fail with higher end customer firewalls, i.e. Cisco ASAs and Juniper SRXs. After troubleshooting and using Wireshark, I now know what the issue is and have an ask of Spectrum/TWC in order to solve the current issue.
First, the issue. It has to do with IPv6’s Hop Limit on DHCPv6 Advertise packets being sent by TWC DHCPv6 server. I was trying to configure a DHCPv6 client on a Juniper SRX550 interface connected to a Spectrum/TWC Internet connection. The DHCPv6 client was failing on the SRX550, but DHCPv6 would work just fine when I plugged my Mac into the same connection. The reason it was failing on the Juniper SRX550 and Cisco ASA was because the DHCPv6 Advertise packet from the TWC DHCPv6 server was being received with an IPv6 Hop Limit of 0. As such, the SRX550 was dropping the DHCPv6 Advertise packet and sending an ICMPv6 Time Exceeded. ICMPv6 Time Exceeded packets are sent when a router/Firewall drops a packet due to the IPv6 Hop Limit reaching 0. I was able to capture this and see it clearly in Whireshark.
Now, the new IPv6 RFC 8200 that was just released 7/2017 states that "A node that is the destination of a packet should not discard a packet with Hop Limit equal to zero; it should process the packet normally." This does appear to be what Linux, macOS and Windows are doing, as DHCPv6 worked when I connected a Mac to the broadband circuit directly. Wireshark showed the DHCPv6 Advertise message being received with a IPv6 Hop Limit of zero and the Mac accepted it and IPv6 was dynamically configured. So, technically Spectrum/TWC are correct. However, most higher end firewalls are still using the older IPv6 RFC 2460 implementation which states that "...The packet is discarded if Hop Limit is decremented to zero." RFC 8200 obsoleted RFC 2460.
Given that RFC 8200 was just released 7/2017 and a lot of hardware manufacturers have not yet implemented these changes, I would like to ask that Spectrum/TWC increase their IPv6 Hop Limit by 1 on their DHCPv6 server for DHCPv6 Advertise packets. This would allow the broader customer base to utilize IPv6. Thank you for your consideration.
twc never got v6 running properly, they only have one server whereas v4 has 4 or 5 a lot closer, they respond a lot faster and seldomly time out. respons time from the v6 dns servers are also 10x longer than v4 and emta phone and v6 quirky as well. Mostly with v4 and v6 on the same modem and router.
I've been waiting for a resolution on this for quite a while too.
Interesting that RFC 8200 changed the expected behavior; I wasn't aware of that. I suspect the CMTS code was changed to match the new RFC without caring about what clients would break.
And it isn't just Spectrum; some Comcast users have the same issue.
I just submitted a case to Cisco to ask them to change the ASA code to allow hop-limit 0 packets, or at least to add a toggle for it. I'm not hopeful, but we'll see what happens. (Apparently the Juniper EX switches have a "no-ipv6-reject-zero-hop-limit" config option that the SRX doesn't?) Really it should be changed on the CMTS side also, but at least they can now correctly argue that this relatively new behavior of sending hop-limit 0 responses is following the spec (sigh)... so this is probably going to end up being a Cisco and Juniper fix.