Losing IPv6

Need Help?

That's what we're here for! The goal of the Rogers Community is to help you find answers on everything Rogers. Can't find what you're looking for? Just ask!
cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Highlighted
I Plan to Stick Around
Posts: 302

Re: Losing IPv6

Forgot to mention.  The way I captured that info was I configured a small managed switch for port mirroring and placed it between the cable modem and the computer running pfSense, so that the traffic was copied to a port where I had a computer running Wireshark.  I then booted the pfSense computer, so that I could capture the DHCPv6 sequence.

 

Highlighted
Resident Expert
Resident Expert
Posts: 7,027

Re: Losing IPv6

@Jking do you not see an IPV6 address for your connected devices?  If thats the case, what modem do you have?  The only proof that you need to provide is the fact that your modem does not have an IPV6 address or Delegated prefix (IPV6).

 

I'm going to assume here that you have the modem running in Gateway mode.  If not, flip the modem to Gateway mode to check the following:

 

If its a black Hitron CGN3xxxx modem or white Hitron CODA-4582 modem and IPV6 is enabled in the modem, when you log into the modem, you should see two IP addresses in the upper right hand corner of the data on the STATUS page.  That page is displayed automatically when you log into the modem.  So, if IPV6 is enabled, you should see both IPV4 and IPV6 addresses in that WAN IP Address block.  

 

To enable IPV6, navigate to the BASIC ... GATEWAY FUNCTION tab and ensure that the Router Mode is set to Dual.  Change it if necessary to DUAL and save the changes.  The modem will take a couple of minutes to switch to Dual mode.  I usually run a modem reboot when I change to Dual.  That is located in ADMIN .... DEVICE RESET .... Reboot.

 

Also note, for Gateway Ops, navigate to SECURITY .... IPv6 INBOUND.  Ensure that the Firewall is Enabled, and that ICMPv6 inbound to Hosts is Allowed.  IPV6 requires ICMP  to run, so you will have to allow IPV6 ICMP to the hosts. 

 

If you have an XB6 modem for the Ignite TV service, have a look at the Connection tab .... Delegated Prefix.  Same as above, you should see the appropriate IPV6 prefix.   That prefix should also be seen in ROGERS NETWORK .... Delegated Prefix.  I don't know where the IPV6 enable/disable it located, if it exists in the modem.  In the GATEWAY .... FIREWALL .... IPV6 select Typical or Custom and ensure that ICMP is allowed, if there is a setting for that.  

 

Now, if you don't see an IPV6 address in the WAN IP address block in the Status page of the Hitron modem, or a delegated prefix for the XB6 modem, I'd probably run a modem reboot.  If after the reboot you don't see an IPV6 address or prefix, then the CMTS is not supplying one.  That requires a discussion with a Tier II tech.  The Tier I tech that you chat with when you call tech support can't help.  Neither can the Tier II tech.  This is a CMTS configuration problem.  The only thing that a Tier II tech can do is confirm the absence of the IPV6 address or prefix and send a ticket to the network engineering staff to resolve.  That would probably take a couple of days, at the least.  A field tech can't help in this particular case as this is a CMTS configuration issue. 

 

So, when you have time, and if this is the situation that you're in, call tech support and ask to speak with a second level tech to report an IPV6 problem with the CMTS.  The tech that you're speaking with might give you some static about this, but the simple question is "Can you fix a CMTS".  If yes, lets talk.  If not, then pass me on to a second level tech.  For this discussion, have the modem's MAC address on hand, which is found on the STATUS page for the Hitron modems.  Not sure where this is for the XB6.  Also take note of the CMTS address which is found in any of the entries in the DOCSIS EVENTS log of the Hitron modem.  Does the XB6 have a similar page to log cable connection events?  Don't know.  Have both of those available to make it easier for the techs to find the modem and CMTS. 

 

If the tech refuses to help, send a message to the moderators at @CommunityHelps.  Follow that link to their public page.  Further down the page is a link to "Send this user a private message".  Follow that page to the message composition page.  Fill in the subject and details regarding the missing IPV6 address.  Also include your modem MAC address and CMTS IP address.  All the moderators can do is forward the observation/complaint to the network engineering staff.  When you're logged into the forum, look for a number overlaying your avatar in the upper right hand corner.  That avatar serves as a link to your own profile and message in and out boxes.  So you can have a look a the response and answer as required.  

 

 



Highlighted
Resident Expert
Resident Expert
Posts: 1,535

Re: Losing IPv6

I don't know if it's the same root cause but I've lost IPv6 connectivity out of the blue as well from time to time.  When this happens, channel changes on Ignite TV take a few seconds.  When I look at the connection log on my OpenWrt router, I only see IPv4 connections.  Things go back to normal immediately after I restart my IPv6 WAN interface.  After the restart, I get an IPv6 address on the interface from (what appears to be) a new/different address block.

 

I've seen the same thing happen before back when I had my XB6 in gateway mode (so it's not my router) and with my own router (with both Arris and Technicolor XB6's) with bridge mode enabled.



Highlighted
I Plan to Stick Around
Posts: 302

Re: Losing IPv6

@Jking do you not see an IPV6 address for your connected devices?  If thats the case, what modem do you have?  The only proof that you need to provide is the fact that your modem does not have an IPV6 address or Delegated prefix (IPV6).

 

That is not correct.  The modem will get an address, but IPv6 is not usable.  The way to verify the problem I had was to put the modem into gateway mode, so that they won't blame your router.  Then go to http://testipv6.com to see if you have IPv6.  If you don't then it's definitely a Rogers problem.   Also, the router will have a valid IP address and you will be able to access IPv6 addresses from it.  However, IPv6 does not work on the LAN side, as demonstrated with testipv6.com.  Also, the WAN IPv6 address is not used for routing, as link local addresses are used.  This is one point the techs were unaware of.  You are then supposed to receive a valid prefix.  But, in my case I wasn't getting one, as shown by the error in the capture I provided.  Also, the WAN address has absolutely nothing to do with the prefix, which is another point the techs didn't know.  That WAN address is used solely to identify the router and can be used for testing, VPNs, etc., but it plays no role in routing or providing the prefix.

 

Highlighted
I Plan to Stick Around
Posts: 302

Re: Losing IPv6

I don't know if it's the same root cause but I've lost IPv6 connectivity out of the blue as well from time to time. When this happens, channel changes on Ignite TV take a few seconds.

 

What alerted me to the problem was delay in sending email, as the IPv6 address would be tried first and then fail, before trying  the IPv4 address.

 

Highlighted
Resident Expert
Resident Expert
Posts: 7,027

Re: Losing IPv6

There is a potential for more than one problem here:

 

1.  The CMTS should assign an IPV6 address and/or prefix to the modem or router.  If the CMTS doesn't do that, then its one type of CMTS problem.  

 

2.  The CMTS assigns an IPV6 address/prefix to the modem or router, but, when you run an IPV6 trace, the only response is from the CMTS, or possibly upstream to a point whereupon the trace times out for every hop after that.  You don't ever get to the target address and any IPV6 test would fail.  If the only IPV6 response is from the CMTS, with nothing beyond it, then the CMTS isn't configured properly to allow the IPV6 return data to transit thru the CMTS back to your modem/router and pc.  If the same thing occurs further upstream, then the last identified server has the same problem, its not configured properly to allow the IPV6 return data to transit back to the originator.  In either case, this is a different problem from the first case.  

 

So, you could have more than one problem on the go.  First step is to determine if the CMTS is assigning an IPV6 address or prefix to the modem or router and go from there.  If you kick the modem into Gateway mode and don't get an IPV6 address/prefix in the modem, then you're looking at a Rogers problem, CMTS to modem, Rogers company equipment to Rogers company equipment.  That is an issue for the Rogers Network Engineering staff to correct.  Anything on your LAN has no bearing on the problem.



Highlighted
Resident Expert
Resident Expert
Posts: 1,535

Re: Losing IPv6

I have never had a problem where I cannot get an IPv6 address or PD so, for me, this is nothing more than a minor annoyance that can be resolved in seconds... and that also does not happen very often.

 

Unfortunately, for other Ignite TV customers, they will just think that the service is broken.  They can reboot their set-top boxes for days or weeks and the problem of slow channel changes will never go away... until their gateway gets rebooted.



Highlighted
I Plan to Stick Around
Posts: 302

Re: Losing IPv6

1. The CMTS should assign an IPV6 address and/or prefix to the modem or router. If the CMTS doesn't do that, then its one type of CMTS problem.

 

The CMTS must provide both an address and a prefix.  A modem, in gateway mode, provides a single /64 prefix to the LAN.  A separate router can get up to a /56.  The single address is used only for accessing the router and plays no part in routing.  It also has nothing to do with the assigned prefix.

 

 

2. The CMTS assigns an IPV6 address/prefix to the modem or router, but, when you run an IPV6 trace, the only response is from the CMTS, or possibly upstream to a point whereupon the trace times out for every hop after that. You don't ever get to the target address and any IPV6 test would fail. If the only IPV6 response is from the CMTS, with nothing beyond it, then the CMTS isn't configured properly to allow the IPV6 return data to transit thru the CMTS back to your modem/router and pc. If the same thing occurs further upstream, then the last identified server has the same problem, its not configured properly to allow the IPV6 return data to transit back to the originator. In either case, this is a different problem from the first case.

 

In my testing, I could successfully ping or traceroute from the computer running my pfSense firewall.  Doing the same from a computer on my LAN would fail.  I could see the packets going out, but no response.  This indicates a routing problem and is how I showed tier 2 support that the problem was within Rogers and not my network.  I also tethered a computer to my cell phone and tried pinging and traceroute from it, to my router and also LAN.  To the router worked, but not the LAN.  Again, I could not see the packets coming in for the LAN.  This also indicated a routing problem.

 

Above I also posted the error message I received from the CMTS:

 

        Status code
            Option: Status code (13)
            Length: 56
            Value: 00064e6f2070726566697820617661696c61626c65206f6e...
            Status Code: NoPrefixAvail (6)
            Status Message: No prefix available on Link
'CMTS89.WLFDLE-BNDL1-GRP3'

Here you can see the error message about the prefix not being available and it also identifies the failing system.

I had this info a few weeks before the problem was resolved, yet the network people refused to even look at the problem, until the senior tech was able to prove, beyond any doubt, that the problem was in that CMTS.

 

An ordinary customer wouldn't have had a hope of getting this sort of problem resolved.  I'd also say neither would most of the techs the customers deal with, as neither tier 2 support, nor the senior tech, knew how DHCPv6-PD actually worked, until I explained it to them.

 

This is not the only time I've had to go far beyond what a customer should have to, to get a problem resolved.