Apologies if I’m missing something obvious here, this is my first time with a Mikrotik device.
I’m using a hAP ax³ as my home router, and am plugging the WAN/ether1 port directly into my ISP box. I have no issues at all with receiving an IPv4 address over DHCP and then using it with NAT.
However, I’ve been unable to get an IPv6 prefix.
I know my ISP provides IPv6, as I have used it previously on their provided router. After contacting them, I have confirmed that they do provide IPv6 /48 prefixes over DHCPv6, and that it should “just work”.
I have used the IPv6 → DHCP Client menu to try and configure this. I am requesting a /48 prefix but it gets stuck on “searching…”. If I request just an address, I get assigned a single IPv6 address. If I request an address and a prefix, I get the searching problem.
This suggests to me that the connection is fine, but that I’ve made a mistake somewhere.
I have created an IPv6 pool (also /48), and I am explicitly asking for a /48 in DHCP client. I have tried fiddling with add default route, rapid commit and other settings in the DHCPv6 client, but have not had any luck getting further with the v6 prefix.
I have not adjusted any settings outside of the DHCP client and the pools menu.
If anyone has any suggestions, or needs some more information to get a good picture of my setup, please just ask.
don’t create IPv6 pool manually. DHCPv6 client will create it automatically after it receives prefix.
don’t use prefix-length=48 (either set it to 64 or omit it altogether), it doesn’t do what you probabky think it does. It’s about prefix length when they are handed out: either to DHCPv6 server if your router is set up to pass prefixes further) or when assigning ipv6 address using syntax address=::1 from-pool=.
If you want to indicate desired prefix size to upstream DHCPv6 server, you can set prefix-hint=::/48 property of DHCPv6 client (but it’s a hint and upstream DHCPv6 server is likely to ignore it).
It could be that your ISP is handing out smaller (longer) prefixes than /48 (mine is giving /56, some are giving /60 and some brain-dead ISPs are giving /64) and since your setting says you’ll be using /48 prefixes, any received prefix smaller than /48 might be ignored by DHCPv6 client.
Also: setting add-default-route=yes is conceptually wrong, but it might work with some ISPs. What this option does is that it takes DHCPv6 server’s (link-local) address and uses it as upstream gateway in default IPv6 route. This works fine if DHVPv6 server is a router as well (either actually intended one or just happpens to support routing), but thr correct way would be to tisable this property and set /ipv6/settings/set accept-router-advertisements: yes (default is effectively “no” while ideally that would be enabled per interface).
But the setting, discussed in previous paragraph, doesn’t prevent your DHCPv6 client from obtaining prefix.
I have gone ahead and deleted my manually created pool.
When trying to enable accept router advertisements, I get an error like so:
/ipv6/settings/set accept-router-advertisements: yes
expected end of command (line 1 column 20)
Additionally, the DHCPv6 client isn’t happy when I try to specify no pool, or a blank prefix. (When I set it to /64, it gets stuck in the “searching…” state again - my ISP has assured me they are assigning /48s in this case)
Is this an issue with WinBox, the router, or my understanding?
If it doesn’t allow you to unset prefix-length, then set it to 64.
You can omit requesting address … it’s not always needed and some DHCP servers might have problems providing both in response to single request.
Are you using winbox4? I’m not closely following its development, but it might still have some teething problems here and there. So you can try using webfig (web UI) or CLI to verify that DHCPv6 client settings are indeed as intended.
The amended command worked to enable accept-router-advertisments.
I’m not actually entirely sure what version of winbox I’m running, but I am now using webfig instead and have verified the settings match expectations.
I have removed the request for a single address, but am still not being allocated a prefix.
Yeah, my WAN is on ether1 and IPv4 is working fine over it.
I’ve tried briefly toggling my IPv6 firewall down and back up and was unable to receive a prefix when it was down, suggesting that it might not be a firewall problem.
First: Disable your ipv6 Firewall
Second: Delete ALL your ipv6 configuration because you will start from scratch
Third: Once you have completed the 2 steps above THEN in Winbox Terminal issue the following directives - each one independently
Thanks for the suggestion. I have given it a shot but unfortunately I still don’t get IPv6 connectivity.
I have had no errors, the configuration seems to apply fine but after a reboot it gets stuck in the “searching…” state again.
I also noticed that my DoH server may be causing a problem, but after disabling it I found no difference either.
If anyone suspects the issue is something that could be resolved faster with information from my ISP, I have a pretty quick line of communication with them and could request information. The only thing they haven’t been able to support with was the router, as it isn’t provided by them - which is fair enough.
My ISP device is a cryptic box on the wall that I have no direct access to. I can’t directly request or check what mode it is in.
I have just tried powering it off for a few minutes and then bringing it back up - but no luck still.
I have a separate router they provided, which is switched off and not involved in my current network architecture. It used to act as the gateway, so I assume the box is running in bridge mode. I could get in touch with my ISP to ask them to verify this, although I’m not sure if my IPv4 internet would be working if it was in gateway mode.
I suspect that there is a ipv6 mismatch happening between your cryptic box and your Tik Router … best that you have your ISP check their DHCPv6 server to view how YOUR Tik ipv6 solicitation is taking place …
