Cox IPv6 working for a time

  • I have Cox setup with IPv6 (using DHCP6 on the WAN interface), I have only the option prefix delegation size set to 64 with an IPv6 delegation hint being sent, the rest are defaults.  Here's what I get back from Cox:

    IPv6 Link Local fe80::230:18ff:fec7:ac19 
    IPv6 address 2600:8800:ff01:900:e8f7:7d3a:76af:a30 
    Subnet mask IPv6 128
    Gateway IPv6 fe80::214:f1ff:fee8:d3d9

    On my LAN interface I have IPv6 Track Interface (set to WAN, with 0 for prefix ID) it looks like this:
    IPv6 Link Local fe80::1:1 
    IPv6 address 2600:8800:480:8d:230:18ff:fec7:ac1a 
    Subnet mask IPv6 64

    One of my clients (Windows 7 system) is getting the following IPv6 configuration:
      DHCP Enabled. . . . . . . . . . . : Yes
      Autoconfiguration Enabled . . . . : Yes
      IPv6 Address. . . . . . . . . . . : 2600:8800:480:8d:5522:29d4:1e53:48e3(Preferred)
      Temporary IPv6 Address. . . . . . : 2600:8800:480:8d:f5df:c884:401a:ebf9(Preferred)
      IPv6 Address. . . . . . . . . . . : 2600:8800:480:29a:5522:29d4:1e53:48e3(Deprecated)
      Temporary IPv6 Address. . . . . . : 2600:8800:480:29a:6d76:501e:720f:daa3(Deprecated)
      Link-local IPv6 Address . . . . . : fe80::5522:29d4:1e53:48e3%10(Preferred)
      Default Gateway . . . . . . . . . : fe80::1:1%10
      DHCPv6 IAID . . . . . . . . . . . : 248533145
      DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1D-FB-61-0E-D0-50-99-87-22-64

    DNS Servers . . . . . . . . . . . : 2600:8800:480:29a:230:18ff:fec7:ac1a  (this looked wrong, so I disabled and re-enabled IPv6 in Windows, and got: 2600:8800:480:8d:230:18ff:fec7:ac1a instead now - I'm guessing this is the crux of my problem?)
                                          <ipv4 address="" listed="" here="" as="" well="">(I removed IPv4 info from the list, but I do have IPv4 as well, of course.

    pfSense version info:
    2.2.6-RELEASE (amd64)
    built on Mon Dec 21 14:50:08 CST 2015
    FreeBSD 10.1-RELEASE-p25

    Now everything seems to work just fine, I have enabled All IPv6 ICMP messages coming into WAN, online tests complain about privacy extensions, but that's because I have a Squid Proxy I use that I haven't enabled tempaddrs on yet (probably won't, it's a VM so I'm not horribly concerned).

    The problem I'm having is that once in a while (once a day, maybe every 2?) my IPv6 configuration will no longer work.  I use twitter on my android cell phone and I notice when it fails as image loads end up being very slow (I then use HE Tools IPv6 ping and see I can't resolve/ping IPv6 anymore).  The issue is on the Windows PCs and my Linux servers as well.  I've tried changing minor things in the interface in pfSense and applying settings, sometimes getting a new IPv6 address from Cox, but still having issues.  I have to reboot pfSense completely for connectivity with IPv6 to be fully restored.  I'm not sure where to look to troubleshoot, I thought maybe something was off in my settings, so hopefully the above can help shed some light on this.

    Thanks in advance for any assistance, this issue has been driving me crazy…</ipv4>

  • I believe I'm having the same problem. Every 2 days or so IPv6 stops working. The interface status shows everything is ok but no ipv6 connections will go through. If I release and renew the dhcp lease on the wan connection everything seems to come back up but that's really annoying to have to do every day.

  • It could be something on Cox's end regarding their DHCP-PD server… the fact that renewing seems to restore IPv6 connectivity might confirm that as being the issue. Do you get the same WAN address and prefix when you renew?

  • It's pretty hard to remember an IPv6 address but it looks the same to me.

  • I see the same thing, go to and get a 0 out of 10 score. Release and renew the WAN address and all is good, 10 out of 10.

    Original IP: 2600:8800:ff06:c00:5d70:ae62:77ea:81c3

    Renewed: 2600:8800:ff06:c00:a552:2096:14dd:e90e

  • I've been monitoring it and determined this is essentially what's happening to me (as described above) - It looks like the issue is that all the (forgive my lack of nomenclature, I'm new to IPv6) IPv6 "stuff" on the LAN side is attached to the WAN IP (because of "Track Interface" and using SLAAC internally, I'm guessing?) and when it changes on the WAN side, the services/addresses aren't being updated properly on the LAN.  I'll make note of exactly what steps I end up taking to fix it, but basically the fix for me has been rebooting pfSense (at which time IPv6 comes up on WAN, but DHCPv4 stays down until I renew the IP, for some reason).  I then do a ifdown eth0 / ifup eth0 on my proxy box and re-add my default gw (IPv4)… maybe because everything's behind a switch, so the host never sees any network disconnect, but I'll try to write down in more detail when I have this issue again.

  • Try enabling "Use IPv4 connectivity as parent interface" on your wan interface. I did that right after I posted my message over 3 days ago and so far IPv6 is still working. So either that did the trick or Cox fixed something on their end. I still think this is pfSense problem though.

  • I lost IPv6 again this morning so I guess my solution didn't work.

  • Cox is pushing some new firmware that is supposed to fix some IPv6 bugs, here in Phoenix with a SB-6183, I seem to have been updated to the new firmware in the last couple days.

    New firmware: D30CM-OSPREY-

    See here for more info on this:

  • I'm having the same issue with Cox and have a SB6141.

    The infrastructure at Cox forgets about my IPv6 addresses (IA_NA and IA_PD) from time-to-time (before any leases expire). Link-local works after a neighbor discovery on the next packet from dpinger, so pfSense Monitoring doesn't notice or at least report the problem anywhere. The fact the the neighbor discovery happens is a sign that the problem happened at Cox since they should always have it in the ND table since dpinger is sending packets every 1/2 second (at least with 2.3-RC).

    When I renew my lease, I get get a different IA_NA and the same IA_PD. So, they aren't losing all of the information.

    I've had a ticket opened with them for a little over two weeks. They initially closed it without contacting me. I had it reopened and provided more information and all they've asked since is what router/firewall I'm using. I think this is the same problem they're blaming Apple on with the AirPort Extreme, but haven't been able to verify.

    I recommend that anyone having this problem add additional monitoring in pfSense to monitor the routable IPv6 of the Cox router (you can get it with traceroute6) and open a ticket with Cox. I can at least see the issue in the pfSense dashboard now.

  • What city are you in?

    If you are having issues with Cox try the DSL Reports Cox HSI forum, there are several Cox folks that monitor the forum and can take a direct hand in solving your problems, even when your local Cox folks are dropping the ball.

  • A helpful hint for the gateway monitoring/dpinger (2.3)… do a traceroute to a couple of hosts... hopefully your second (third, if you do it from a PC on your LAN) hop is the same for all (or at least most) of them. Configure the gateway to use that next hop host instead of the default gateway... that way you take out link-local/NDP from the "is it up?" test. I recommend doing this for both IPv4 and v6, though IPv4 doesn't have the link-local fallback like IPv6 does for a default gateway.

    Some might say that it's better to ping a host on the internet instead of within your ISP's local network... that way you can tell if your ISP is having internet connectivity issues. If you had multi-WAN, and needed to fail over to a backup WAN when internet connectivity is lost (meaning there's an issue on the ISP's end), this might be helpful... but with only one ISP and WAN connection, I prefer to see what kind of latency is present between me and my ISP, rather than latency on the internet.

  • Was this ever resolved?  If so, how?

    I've got Cox and I have the EXACT thing you're describing.

  • It appears to be mostly fixed. Fixed enough that I can leave IPv6 enabled and it works for weeks/months. But, Cox still manages to break it once in a while which can require either resetting the WAN interface or rebooting to fix. It helps to have shorter internal network SLAAC and DHCPv6 life times.

  • LAYER 8 Netgate

    Cox IPv6 here in Las Vegas has been solid as a rock. /56 PD. They are even honoring the DUID and my /56 has not changed despite a couple firewall swaps, cable modem changes, and about a half-dozen new IPv4 assignments.

    ![Browser Shot-2017-03-06-23-45-47.png_thumb](/public/imported_attachments/1/Browser Shot-2017-03-06-23-45-47.png_thumb)
    ![Browser Shot-2017-03-06-23-45-47.png](/public/imported_attachments/1/Browser Shot-2017-03-06-23-45-47.png)

  • Try this:
    Open 'Wan interface' click 'save' and click 'apply', wait 1 minute
    Is IPv6 restored?

  • LAYER 8 Netgate

    To my knowledge there is no PPPoE on Cox, so that issue would not apply here.

    Edit/Save WAN is required to make changes to what interfaces are tracking WAN though.

  • I don't think that dhcp/pppoe makes difference.
    Your config uses same dhcpv6 client…
    Can you test my scenario in my thread here on forums? In ipv6 section...

  • LAYER 8 Netgate

    I have never seen the PD, etc go away from them so I can't check it here.

  • Ahh ok I hope some of devs have access to pd setup somewhere… Otherwise I can make it available to collect necessary things...