Hi,
I have a RB5009UG+s+ hooked up to Xfinity cable via a Motorola MB8611.
I had it configured for both IPv4 DHCP and IPv6 DHCPv6 with a /60 prefix delegation.
Until about a week or two ago, this was all working fine, then, suddenly, I lost IPv6 connectivity.
The symptoms were/are that my DHCPv6 request receives a response just fine: I can get a /64 or /60 prefix delegation, as before, but I had no connectivity (all requests just timed out).
I have debugged it to the point that I have some evidence that makes me think something is “hinky” on the Xfinity side (perhaps the modem configuration they are pushing?).
What I see in the IPv6 routes is that I was handed a default route “::/0” with gateway address “2001:558:4060:79::10” (twice in fact, another odd aspect), but the flags for the entry are “DUdHI” so it’s flagged as unreachable.
Pretty much all other config is default or set up following recommendations in other post regarding getting IPv6 set up with Xfinity e.g. assigning the PD range to the local LAN, enabling “Add Default Route” in the DHCPv6 configuration etc.
What I changed that immediately restored connectivity is to change the global IPv6 “accept RAs” setting to “yes” rather than the default of “yes if forwarding disabled”. When I make that change, I immediately see a 3rd IPv6 default route get added but the gateway address is a link-local address of the form “fe80:%ether1” (ether1 is my WAN port), with flags “DA” so active. This route apparently gives me full IPv6 internet access, but it’s not coming from DHCPv6, rather from an RA, which, combined with the fact that it’s a link-local address seems wrong to me, or, at least, completely different to how it worked previously.
So, as I mentioned earlier, could this perhaps be a case of Xfinity misconfiguring the modem such that’s not acting as a bridge?
Any thoughts or suggestions on further debugging etc. would be greatly appreciated.
DHCPv6 cannot provide a default route by protocol design. The “Add Default Route” setting in RouterOS is an unfortunately named hack and needs to be disabled unless you are told otherwise by the upstream administrator. Contact mikrotik support and tell them that this naming is extremely misleading.
In IPv6 gateway is discovered via Neighbor Discovery from Router Advertisement messages sent by the upstream router. Link-local address you see is perfectly fine for routing.
@kentzo, setting the ND parameters as you indicated has fixed my IPv6 Xfinity routing problems; however, now I am being flooded with the following warnings in my log:
invalid mtu 9192 on Comcast-gateway from fe80::21c:73ff:fe00:99
After fixing the ND entry, I noticed that a default route entry was added.
I copied the default route (and interface specifics) that was added to my Route List, and made a manual static entry with the Gateway specific information from the ND added entry. I then disabled the ND entry and made my new static route active. That seems to have stopped the log entries. I guess this will work until Comcast decides to change the default route assignment…
Not all heroes wear capes
Thanks so much for this.
I had sort of managed to make this work, but I still had the “add-default-route” which I didn’t realize just went “oh, got a DHCPv6 response from here, must be a router” (ick), so I have cleaned that up and fixed the log spam.
Responding for visibility as this solution is popular but a bit unsafe, esp. with people removing the firewall rule and allowing any GUA DHCPv6. You can simply allow GUA source with LLA destination + add a blind default route: http://forum.mikrotik.com/t/xfinity-comcast-dhcpv6-configuration-change/156031/10
This works properly on both “old” and “new” “10G” networks.
I rely on RouterOS to do the filtering of incoming RA broadcasts and DHCPv6 replies.
Assuming both RouterOS is flawed and Comcast fails DHCP filtering on their bridge, your rule won’t help against malicious server on the same link.
Additionally it is not required by the RFC 8415 for client to initiate DHCPv6 exchanges from LLA, such filtering it may even break things:
If the server receives the message directly from the client and
the source address in the IP datagram in which the message was
received is not a link-local address, then the client is on the
link identified by the source address in the IP datagram (note
that this situation can occur only if the server has enabled
the use of unicast message delivery by the client and the
client has sent a message for which unicast delivery is
allowed).
and
If the client has a source address of sufficient scope that can be
used by the server as a return address and the client has received a
Server Unicast option (see Section 21.12) from the server, the client
SHOULD unicast any Request, Renew, Release, and Decline messages to
the server.
If you have this filtering rule, at least make sure that packets for the connections initiated by the router from that port are accepted regardless of the source address.
Removing ND on WAN prevents (?) RouterOS from possibly learning anything else from the upstream.
You have to trust your upstream a little bit. E.g. to not route LLAs.
