Two months ago, IPv6 stopped working on my Xfinity connection. It had previously worked brilliantly. I was stumped. My first thought was a cable modem configuration problem. I wasn't looking forward to working my way though Xfinity's support.

Long story short, Xfinity changed how they do DHCPv6 in my area. This is likely to be rolled out elsewhere, so perhaps save some frustration among others.

They changed the location of the DHCPv6 server from local scope (fec0::/10) to a public IPv6.

I suppose this was to allow a single server to serve multiple network segments within their control and allow the network to scale better. Of course, none of the support team I spoke with were aware of this.

In the end, just three changes needed to be made to my configuration:

(1) IPv6 Firewall: Modified the default rule in the input chain that allows DHCPv6 (UDP, 547, 546) to allow ALL addresses rather than just local. (Presumably Xfinity has taken precautions on their end).

(2) DHCPv6 Client: Modified settings to NOT add default route. (This route is based on the location of the server it seems, which was also the gateway. Used to work.) Since the server is now at a public IP, it is not reachable as a gateway.

(3) IPv6 Routes: Add a static route for ::/0 via ether1 to reach the rest of the world. (add disabled=no dst-address=::/0 gateway=ether1)

Anyone have any thoughts on Xfinity's changing this? The default firewall filters expect local addresses. That suggests Mikrotik wouldn't be too enthusiastic.

Also, any comments on my configuration changes?


Perhaps this thread will save someone time in the future.

Since the server is now at a public IP, it is not reachable as a gateway.

DHCPv6 uses link-local multicast, so the server still has to be "local" to you in that sense. It can't be off in their Philadelphia headquarters, for instance.

Add a static route for ::/0 via ether1

Surely you get the effect of that via SLAAC?

The only purpose for having a static default route on a router would be to make it work before the "real" routes are known. Whether that's via SLAAC, OSPF, or BGP, someone has to tell your router what "upstream" means at any given instant, because as you've just discovered, it can change.

It's dumb clients that rely on default routes.

Anyone have any thoughts on Xfinity's changing this?

It sounds like they've moved from something idiosyncratic to standard.

I suspect only your firewall rule needed changing.

Thanks Tangent,

It seems the DHCPv6 server address is indeed in another segment, not local, judging from the address compared to the address assigned to the router (different /64). I suspect the multicast function is handled by a DHCPv6 relay. Once found, the resulting connection becomes unicast. DHCPv6 relay is a bit spooky to me, but it would make sense if it worked that way. Feel free to correct. Not sure if its actually in Philly, but just not in the same /64.

As for adding the default route ::0 ether1, my understanding is that is just telling my router where the outside world is connected, and how it finds the next hop is indeed SLAAC. In the previous configuration, the default route added by Mikrotik's DHCPv6 client was the link-local of the same machine that did PD (the DHCPv6 server). When i disable the route, things stop. Perhaps I've something configured incorrectly? I do have IPv6 ND enabled.

What's interesting to me, though, is that you suggested Xfinity was idiosyncratic before, and is now more standard. Is the Mikrotik default not standard? I wonder if more consumer oriented routers ran into this problem as well.

I do appreciate your response. IPv6 is a bit of an odyssey for me. Revelation comes in bits.

Not sure if its actually in Philly, but just not in the same /64.

It's entirely possible to route multicast, if the network is configured for it. PIM-SM, etc.

As for how your local piece of the Xfinity network is constructed, the best way I know to learn that is to play around with traceroute results. The host names are often enlightening and give a sense of the structure.

As for the network prefixes, I've seen IPv4 cases where Comcast has a /19 on one side of the road and an entirely unrelated /16 a few blocks away on the other side. City-scale networks that accrete over decades are complicated. Square that for regional networks, and cube it for national networks.

One may hope that IPv6 networks are structured more sanely, but I wouldn't read a whole lot into the subnet mask even so.

When i disable the route, things stop.

Okay. I'm glad you tried this change in isolation. I worry when I see "these three things all needed to be changed to fix things." It often speaks of a long debugging process where the entire list of changes is given as "what fixed it" when in fact its some subset, often just one change that was the actual fix.

Is the Mikrotik default not standard?

My reading of your first post is that you aren't using the MikroTik stock RouterOS configuration. You've changed it.

I think you're getting clever with all your fancy rules based on the way things previously worked. ISPs expect their clients to do autodiscovery, requiring at most a restart of the modem to pick the latest changes up. This gives their network engineers the freedom to change things without touching every piece of CPE. When you hard-code things, the world sometimes changes around you, and you're left in a broken state.

Thanks again.

I don't think I have many fancy rules, apologies if I was unclear. As you said, the big bit is the change in the firewall rule. Here is the default Mikrotik IPv6 firewall rule (ros7.1.2) that I had to change to make it work:


Simply remove the source address (fe80::/10) constraint, allowing any address.

So the open question seems to be, is this still the correct default or should Mikrotik change it?

Didn't work for me.

Default setup for Router Advertisements and Forwarding interact and affect default gateway acquisition.
viewtopic.php?t=194172#p1019428 is worth reading.

Same issue here with a swedish ISP that used to work fine with IPv6 until recently.

Changing the IPv6 firewall rule worked for me. On RouterOS v7.11 it's the default firewall rule #4. I just removed the reference to the Src. Address.

Edit: I should say, I'm now getting a bound address under DHCPv6 Client. IPv6 still didn't "work" when going to test-ipv6.com until I checked the box "Use Interface DUID".

Code: Select all

filter add chain=input action=accept protocol=udp dst-port=546 src-address=fe80::/10 comment="defconf: accept DHCPv6-Client prefix delegation."

Simply remove the source address (fe80::/10) constraint, allowing any address.

To make it safe you should probably NOT remove it, essentially allowing any GUA to server as your DHCP However, while XFinity configuration is strange, it's not prohibited by RFC. To make it secure do not remove the , instead change it to . This essentially ensures that only a relay with LLA can provide a DHCPv6. Since LLAs aren't routable, thus anyone outside of your local link cannot spoof and deliver you a packet with dst carrying LLA and mess with your link. If this is confusing, check more on IPv6 address types: https://www.networkacademy.io/ccna/ipv6 ... ress-types
Thus, the full rule will be:

In addition, enabling RA on untrusted WAN links you don't control, as suggested in viewtopic.php?t=201029#p1033001, is less than ideal. While it does work, it relies on a weak security assumption that Comcast configured their network properly with respect to RA filters. I wouldn't count on that Instead you can simply manually add a blind static default route via WAN interface:

That's it - no adding ND, no enabling RA, no opening the firewall to any DHCPv6 server out there