Cox IPv6 working for a time

[Gooberslot]

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

[stan-qaz]

I see the same thing, go to http://test-ipv6.com/ 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

[P-Chan]

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.

[Gooberslot]

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.

[Gooberslot]

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

[stan-qaz]

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-1.5.0.1-GA-01-NOSH

See here for more info on this: https://www.dslreports.com/forum/r30562682-Arris-SB6183-IPv6-TCP6-bug-Looking-for-firmware-update

[ohwell]

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.

[stan-qaz]

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.

https://www.dslreports.com/forum/coxhsi

[MikeV7896]

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.

[mmiller7]

Was this ever resolved?  If so, how?

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

[ohwell]

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.

[Derelict]

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.


[the_MiCrO]

Try this:
Open 'Wan interface' click 'save' and click 'apply', wait 1 minute
Is IPv6 restored?
Yes: https://redmine.pfsense.org/issues/7330

[Derelict]

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.

[maverick_slo]

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...
Thanks.

[Derelict]

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

[maverick_slo]

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