New problem solver
•
26 Messages
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.
curtisv
New problem solver
•
26 Messages
8 years ago
Correction:
Error = number of subnets for /60 was stated as 256.
Correct info = a /56 yeilds 256 subnets. a /60 yields 16 subnets.
Followup:
The strategy suggested for renumbering works for FreeBSD and the pf packet filter. The following two lines can be added:
pass out route-to ( $ext_if $ipv6_cm ) inet6 from to ! to !
pass out route-to ( gif0 $ipv6_he ) inet6 from
Variables are defined as follows ext_if is the interface name facing the CM (in this cast ext_if = "vtnet1"). cm_ipv6 is the /56 prefix allocated. he_ipv6 is the Hurricane Electric tunnel allocation (a /48 which is the smallest allocation they give out other than /64). my_ipv6 contains both. The <> notation is a pf table (in this case a const table).
This pf setup routes packets with source address from the Comcast IPv6 allocation to the Comcast CM and routes packets with source address from the HE IPv6 allocation to the HE tunnel. This allows as much time as needed to renumber and change DNS and all that.
Other packet filters have similar capabilities though the config syntax will differ.
0
0
tmittelstaedt
Problem solver
•
326 Messages
8 years ago
Here is my traceroute through my CG from my FBSD system:
$ traceroute6 www.google.com
traceroute6 to www.google.com (2607:f8b0:400a:806::2004) from 2603:3004:618:8d00:21a:64ff:fe99:7d0c, 64 hops max, 12 byte packets
1 2603:3004:618:8d00:abd:43ff:fe9a:e0af 0.328 ms 1.425 ms 1.090 ms
2 2001:558:4060:d::1 9.250 ms 10.455 ms 9.910 ms
3 xe-3-2-2-sur04.troutdale.or.bverton.comcast.net 9.627 ms 9.724 ms 11.254 ms
4 ae-52-ar01.troutdale.or.bverton.comcast.net 11.298 ms 12.180 ms 11.193 ms
5 be-33490-cr01.seattle.wa.ibone.comcast.net 14.643 ms 15.548 ms 15.078 ms
6 hu-0-10-0-1-pe05.seattle.wa.ibone.comcast.net 13.712 ms 13.508 ms 13.833 ms
7 as40009-2-c.ashburn.va.ibone.comcast.net 20.417 ms 15.661 ms 14.553 ms
8 2001:4860:0:1041::1 17.032 ms 16.190 ms
2001:4860:0:1040::1 16.894 ms
9 2001:4860:0:1::1e69 15.245 ms 13.874 ms
2001:4860:0:1::1e6b 16.123 ms
10 sea15s01-in-x04.1e100.net 13.801 ms 10.928 ms 14.242 ms
Here is my traceroute from a win7 system on a /60 issued from the netgear via dhcp-pd and behind another router:
C:\Users\tedm>tracert -6 www.google.com
Tracing route to www.google.com [2607:f8b0:400a:809::2004]
over a maximum of 30 hops:
1 <1 ms 1 ms 1 ms 2603:3004:618:8df0:21b:cff:fe3c:3fa1
2 13 ms 9 ms 10 ms 2001:558:4060:d::1
3 13 ms 10 ms 10 ms xe-3-2-2-sur04.troutdale.or.bverton.comcast.net
[2001:558:f2:1c6::1]
4 11 ms 9 ms 11 ms ae-52-ar01.troutdale.or.bverton.comcast.net [200
1:558:f0:14a::1]
5 15 ms 14 ms 16 ms be-33490-cr01.seattle.wa.ibone.comcast.net [2001
:558:0:f736::1]
6 13 ms 15 ms 15 ms hu-0-13-0-1-pe05.seattle.wa.ibone.comcast.net [2
001:558:0:f655::2]
7 14 ms 15 ms 12 ms as40009-2-c.ashburn.va.ibone.comcast.net [2001:5
59:0:8::2]
8 20 ms 17 ms 13 ms 2001:4860:0:1040::1
9 12 ms 13 ms 13 ms 2001:4860:0:1::491
10 19 ms 15 ms 13 ms sea15s12-in-x04.1e100.net [2607:f8b0:400a:809::2
004]
Trace complete.
C:\Users\tedm>
I dunno, maybe you are just using an inferior operating system? 😉
0
0
curtisv
New problem solver
•
26 Messages
8 years ago
That was not a useful reply but I suppose you knew that. Or maybe not. I get the smiley though. I guess you couldn't resist and OS dig. 🙂
You are also not pinging from the IA_PD allocated /60 since 2603:3004:618:8d00:21a:64ff:fe99:7d0c is in 2603:3004:618:8d00::/64, your DMZ, not in the 2603:3004:618:8df0/60 that would have been allocated with a IA_PD request.
Anyway - I'm using FBSD and traceroute on the OS works fine. It also now works fine through the Netgear CM now that I corrected an asymetric route problem. That fix is described at http://forums.businesshelp.comcast.com/t5/IPV6/Netgear-CG3000DCR-IPv6-bugs-and-quirks/m-p/31298#M761 which predated your reply. Both HE.net and Comcast block packets where the source address is not in a destination that they are forwarding to in the other direction. This is something they should be doing to prevent forged source addresses in packets and block certain types of attacks such as backscatter DDOS. Prior to making that change I could traceroute with the "traceroute6 -s" option forcing a source address (or ping6 -S, where its uppercase for ping6). With the pf workaround described in the referenced message the route is selected at my router (HE or Comcast) based on the IPv6 source address.
I probably should have replied to myself with a followup to the original post indicating traceroute works now. Oh wait -- I did reply and that is what you replied to but I didn't indicate that this fixed traceroute. Oops. I should have mentioned that the asymetric route was the cause of the traceroute problem.
Just to be clear on the ping and traceroute issue here is a summary. Both ping6 and traceroute6 to the CM works for me from 2603:3005:5602:8a00::137 (on the CM local /64 subnet) but not from 2603:3005:5602:8af2::137 (an address within the IA_PD /60 allocation). Traceroute6 from either address through the CM (to an address past the CM, not to the CM itself) always works as long as routes are symetric.
For now I'm not going to mark this as fixed, unless I hear that the IA_PD limitations and the ping bugs have been fixed in the CG3000DCR CM. So to summarize, a partial workaround exists and is described here. Pinging the router from an address not in the /64 adjacent to the router doesn't work. Traceroute works. The workaround is partial in that only a /60 out of the allocated /56 is usable.
Curtis
0
0