Prolixium dot com: News >> Blog >> IPv6 on Comcast Business

Comcast Business decided to give me some IPv6 lovin' a week or two ago on my DOCSIS connection. Unfortunately, it still seems to be a work in progress.

IPv6 Options

The above is the IPv6 configuration screen on my (well, Comcast Business') NETGEAR CG3000DCR. I've got a /56 that I suspect was obtained via DHCPv6-PD on the DOCSIS interface. The LAN interface has a /64 out of that /56 and supports DHCPv6-PD as well. It's also got RAs enabled with RDNSS:

21:08:16.491207 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::c604:15ff:febe:e634 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 120
	hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
	  source link-address option (1), length 8 (1): c4:04:15:be:e6:34
	    0x0000:  c404 15be e634
	  prefix info option (3), length 32 (4): 2601:8:a401:4c00::/64, Flags [onlink, auto], valid time 345600s, pref. time 345600s
	    0x0000:  40c0 0005 4600 0005 4600 0000 0000 2601
	    0x0010:  0008 a401 4c00 0000 0000 0000 0000
	  unknown option (24), length 24 (3): 
	    0x0000:  3800 0005 4600 2601 0008 a401 4c00 0000
	    0x0010:  0000 0000 0000
	  rdnss option (25), length 40 (5):  lifetime 60s, addr: 2001:558:feed::1 addr: 2001:558:feed::2
	    0x0000:  0000 0000 003c 2001 0558 feed 0000 0000
	    0x0010:  0000 0000 0001 2001 0558 feed 0000 0000
	    0x0020:  0000 0000 0002

The RDNSS allows IPv6 clients that have not yet embraced DHCPv6 to mostly work without IPv4, which is nice (although I still think it's a hack).

I was puzzled by the other options on the configuration screen, though. The "Enable Unicast" and "Enable Rapid Commit" initially meant nothing to me and I assumed the "Enable EUI-64 Addressing" toggled the "A" flag in the RA. I individually toggled all of the options and compared the results, which required a few reboots, unfortunately. From what I can tell the "Enable Rapid Commit" and "Enable EUI-64 Addressing" options do absolutely nothing to the RA messages. However, "Enable Unicast" removes all the flags and all but one option in the RA:

20:59:52.178671 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::c604:15ff:febe:e634 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24
     hop limit 64, Flags [none], pref medium, router lifetime 0s, reachable time 0s, retrans time 0s
       source link-address option (1), length 8 (1): c4:04:15:be:e6:34
         0x0000:  c404 15be e634

I'm not sure why that option isn't labeled appropriately or why enabling "unicast" would result in such a configuration. Silly consumer networking equipment.

Anyway, I threw a host on the link and, of course, started running some traceroutes. I expected to see the LAN interface of the CG3000DCR as the first hop, but I didn't:

HOST: rpi                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2001:558:4082:48::1                              0.0%     1   10.8  10.8  10.8  10.8   0.0
  2.|-- te-0-2-0-5-ur07.burien.wa.seattle.comcast.net    0.0%     1    9.0   9.0   9.0   9.0   0.0
  3.|-- ae-21-0-ar03.burien.wa.seattle.comcast.net       0.0%     1    8.7   8.7   8.7   8.7   0.0
  4.|-- be-1-sur03.ferndale.wa.seattle.comcast.net       0.0%     1   11.8  11.8  11.8  11.8   0.0
  5.|-- he-1-3-0-0-10-cr01.seattle.wa.ibone.comcast.net  0.0%     1   10.9  10.9  10.9  10.9   0.0
  6.|-- pos-2-14-0-0-cr01.seattle.wa.ibone.comcast.net   0.0%     1   26.2  26.2  26.2  26.2   0.0
  7.|-- be-10-pe02.111eighthave.ny.ibone.comcast.net     0.0%     1   27.0  27.0  27.0  27.0   0.0
  8.|-- 10gigabitethernet1-1-3.switch1.sjc2.he.net       0.0%     1   29.3  29.3  29.3  29.3   0.0
  9.|-- 10ge1-1.core1.fmt1.he.net                        0.0%     1   81.8  81.8  81.8  81.8   0.0
 10.|-- he.net                                           0.0%     1   37.3  37.3  37.3  37.3   0.0

Other than the bad PTR on hop #7, the first hop was unexpected. Is it, instead, the DOCSIS interface address that's being used in the ICMPv6 response?

(rpi:21:45)% mtr -rwc1 2001:558:4082:48::1
Start: Fri Dec  5 21:46:21 2014
HOST: rpi                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2001:558:4082:48::1  0.0%     1    9.1   9.1   9.1   9.1   0.0

Maybe. But when I traceroute to my host from the outside, why do I see 2001:558:a2:f3::2, instead?

HOST: netflix01.ring.nlnog.net                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a00:86c0:ff0a:2906::1                      0.0%     2    1.0   1.0   1.0   1.0   0.0
  2.|-- 2a00:86c0:26c::9                            0.0%     1    0.3   0.3   0.3   0.3   0.0
  3.|-- 2001:559::ca1                               0.0%     1    0.9   0.9   0.9   0.9   0.0
  4.|-- be-17-cr01.56marietta.ga.ibone.comcast.net  0.0%     1    1.6   1.6   1.6   1.6   0.0
  5.|-- 2001:558:0:f747::2                          0.0%     1   19.2  19.2  19.2  19.2   0.0
  6.|-- be-21-ur07.burien.wa.seattle.comcast.net    0.0%     1   20.4  20.4  20.4  20.4   0.0
  7.|-- 2001:558:a2:f3::2                           0.0%     1   18.8  18.8  18.8  18.8   0.0
  8.|-- 2601:8:a401:4c00:ba27:ebff:fe8f:7486        0.0%     1   28.4  28.4  28.4  28.4   0.0

This appears to be an anomaly when an ICMPv6-based traceroute is used. A UDP one works as expected:

(rpi:21:49)% mtr -u -rwc1 he.net.          
Start: Fri Dec  5 21:49:35 2014
HOST: rpi                                             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2601:8:a401:4c00:c604:15ff:feee:e634             0.0%     1    0.9   0.9   0.9   0.9   0.0
  2.|-- 2001:558:4082:48::1                              0.0%     1   16.2  16.2  16.2  16.2   0.0
  3.|-- te-0-2-0-5-ur07.burien.wa.seattle.comcast.net    0.0%     1    8.9   8.9   8.9   8.9   0.0
  4.|-- ae-21-0-ar03.burien.wa.seattle.comcast.net       0.0%     1   13.0  13.0  13.0  13.0   0.0
  5.|-- be-1-sur03.ferndale.wa.seattle.comcast.net       0.0%     1   12.5  12.5  12.5  12.5   0.0
  6.|-- he-1-3-0-0-10-cr01.seattle.wa.ibone.comcast.net  0.0%     1   11.1  11.1  11.1  11.1   0.0
  7.|-- pos-2-14-0-0-cr01.seattle.wa.ibone.comcast.net   0.0%     1   28.2  28.2  28.2  28.2   0.0
  8.|-- be-10-pe02.111eighthave.ny.ibone.comcast.net     0.0%     1   26.7  26.7  26.7  26.7   0.0
  9.|-- 10gigabitethernet1-1-3.switch1.sjc2.he.net       0.0%     1   31.8  31.8  31.8  31.8   0.0
 10.|-- 10ge1-1.core1.fmt1.he.net                        0.0%     1   38.2  38.2  38.2  38.2   0.0
 11.|-- ???                                             100.0     1    0.0   0.0   0.0   0.0   0.0

2001:558:4082:48::1 is obviously the CMTS.

Now that we've got the initial exploring out of the way, I figured I would try the "static route" feature on the CG3000DCR to see if it worked with IPv6 at all:

IPv6 Static Route Fail

This was a complete fail. I tried adding a /64 static route to a static host I have on the link with a subnet mask of "64" and then one of "ffff:ffff:ffff:ffff::" but both failed.

As far as the permanency of this rather useless /56 I'm given, a quick look around on the support forums made me conclude that the current prefixes are dynamic and static prefixes will be rolled out in the future. I suppose that answers the question about reverse DNS delegation, too. I can't imagine that being a possibility at all without static assignments. I also sure do hope that they provide an option for delegation instead of just adding individual records like they do for IPv4 (and, poorly, I may add, since it must be done via a phone call).

I guess I'm not ready to dump my tunnels, yet. I'd like a static assignment and reverse DNS. Otherwise, the sweetness of native IPv6 still feels like a downgrade.