New problem solver
Netgear CG3000DCR IPv6 bugs and quirks
First some background. If you use Comcast business service and have a static IPv4 allocation, then you are required to use one of three CM, SMC D3GCCR, Cisco DPC3939B, or CG3000DCR. The good news is you have a static /56 prefix allocation. See Comcast Business IP Gateway and Static IP overview - Use your static IPs to run a server - IPv6 on the Comcast business web site.
You know the first part of the drill - contact Comcast support, convince first level that IPv4 and IPv6 are not the same thing, get escallated to tier 2. Then get your CM swapped out to CG3000DCR as it seem to be the only one working for IPv6. There is an excellent summary at GT.net Mailing List Archive (Home->nsp->ipv6) but some of the bugs listed may be gone by now. Other good information on Dual-Stack on SMC D3GCCR and Cisco DPC3939B on this forum.
Logging into the CG3000DCR CM, in -> LAN -> IPv6 Setup you should see a gateway address of the form 2603:xxxx:xxxx:xx00:yyyy:yyyy:yyyy:yyyy/64 and a prefix delegation of 2603:xxxx:xxxx:xx00::/56. That indicates the CM asked the CMTS for a DHCPv6 internet address prefix delegation (IA_PD) and got back a /56.
Normally a network engineer would want to set up an IPv6 static route pointing 2603:xxxx:xxxx:xx00::/56 to the customer owned router, but there is no provision in the CG3000DCR for static IPv6 routes. This is the first bug and its rather huge.
To take advantage of a subset of the /56 allocated the customer owned router needs to send a DHCPv6 IA_PD request to the CM. The IA_PD request can contain hints for the CM to request allocation of a specific size prefix or to allocate more than one prefix. The CM ignores the contents of the request and always returns the same /60 of the form 2603:xxxx:xxxx:xxf0::/60. Netgear will claim that is not a bug as the RFCs defining DHCPv6 IA_PD does allow the server to ignore the hint but indicate that the mask should be used as a hint, particularly in a ::/N request. A /60 allows 256 subnets so this is fine for me and probably most small/medium businesses.
The next bug is that the CG3000DCR CM, after allocating a IA_PD (or IA_NA) will not respond to pings from that address. This is clearly a bug and any network engineer such as me or the comcast tier 2 and tier 3 people I dealt with took this as indication that the CM was not working. Take a leap of faith and install IPv6 routes to the CM anyway. If you have working IPv6 via a tunnel (to HE.net for example) then deleting that default route and adding a default route to the CM will bring down your working IPv6 but allow you to test IPv6 through the CM. If that is the case consider installing a more specific route, just to the IPv6 prefix you will be pinging.
Another bug is that traceroute through the CM is completely broken. The CM seems to capture traceroute packets and reply to them directly even though the traceroute is supposed to go through the CM.
Finally if you have working IPv6 through a tunnel, you may have lots of IPv6 hosts to renumber. The best way to do this is create aliases on all your local subnets so that either the tunnel provider prefix (a /48 if its HE.net) or the Comcast prefix (a lowly /60 but good enough) are usable. Renumber all of the hosts after that. The problem will be convincing either the tunnel provider or Comcast to let packets with source routes not allocated by them to pass through during the transition. Otherwise a flash renumber is needed (renumber everything at once and change the default route - can't possibly be non-disruptive). There is a workaround for this but it involves using a packet filter which picks a default route based on source address and destination address being "not here". Perhaps another post if there is interest.