I’ve read multiple sources including official documentation and watched YouTube videos, but no matter what I’ve tried, IPv6 isn’t working as it should.
My devices do get IPv6 addresses and they can reach some IPv6 sites but fails IPv6 tests (IPv6 large packet fail) and they cannot be pinged from the outside. Sometimes IPv6 stops working completely until I reconnect my client devices from scratch.
I use the router as DNS server in IP DHCP-Server and inside DNS settings I have multiple IPv4 and IPv6 addresses. And they are reachable via ping but not always, which again ties up with my IPv6 problem.
My country: India
My ISP: BSNL
They allocate dynamic public IPv4 and dynamic IPv6 with /64 prefix as detected by RouterOS’s IPv6 DHCP Client.
So this is my config, step wise as I entered them:
My suggestion for your issue (I have experienced the very same thing) is to do the following:
When the IPv6 tests fail go to Winbox ipv6 dhcp Client then highlight the connection and Release wait 5 seconds then Renew
Now go back to your test sites and test again … when i do that the test sites I use work and all tests work [pass] the way i expect.
using ipv6-test.com i get 19/20 … I do not get 20/20 because of an ISP issue with host names
If this site prompts you for something just cancel the prompt and the test will continue — I do not remember what it prompts for.
Man, so I got to release and renew often? Because this affects all of my devices on the daily. And writing a manual script for this makes no sense, this shouldn’t be a problem.
Is there anything wrong with my IPv6 configuration?
This probably means that your internet connection does not have MTU 1500 but a smaller value.
Check what the MTU value is and if you can raise that to 1500. E.g. when you use PPPoE there is a Max MTU and Max MRU field in the settings, put 1500 there and see if it works and this larger MTU is accepted (this requires that your ISP support RFC4638).
When it works, your problem is probably solved. When it is not working and you are still stuck with something like MTU 1480 or 1492, see what it is and copy this value to IPv6->ND (open the “all” line and enter the MTU there).
Now restart your clients and see if it now works.
I think mozerd did not understand the root cause of the problem.
The issue is that the MTU information obtained from the ISP (the interface MTU) is not communicated (via the route table and the IPv6 ND) to the clients.
So the clients do not know about this limitation and transmit packets that are too large in some cases.
I gave you a workaround to send the correct MTU to the clients via IPv6 ND. That could only improved by MikroTik by making it automatic.
Also you can work around the problem using a TCP MSS clamping rule in the mangle table:
However, best is to try to set the MTU/MRU of the PPPoE line to 1500 and see if it works, and if not call your ISP and urge them to support RFC4638.
That will solve many other small problems you have with a PPPoE line.
PPPoE is capped at 1492 MTU subtract 8 for protocol overhead. Which is why I dislike my ISP using PPPoE to begin with.
The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1492. Since Ethernet has a maximum payload size of 1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is 2 octets, the PPP MTU MUST NOT be greater than 1492.
IPv6 large packet fail means the receiver was unable to deliver ICMPv6 Type 2 (Packet too big) to the sender. The whole point of ICMPv6 Type 2 is to negotiate IPv6 packet size as IPv6 standard mandates, IPv6 cannot be fragmented.
I didn’t see your other reply, I just replied to it. Yeah, my ISP isn’t going to implement RFC4638 anytime soon. Check my other reply for more details.
That is why you need RFC4638 support at the ISP. That RFC overrules those limits. I have full 1500 byte MTU on my PPPoE.
IPv6 large packet fail means the receiver was unable to deliver ICMPv6 Type 2 (Packet too big) to the sender. The whole point of ICMPv6 Type 2 is to negotiate IPv6 packet size as IPv6 standard mandates, IPv6 cannot be fragmented.
I’ve used the standard minimum IPv6 MTU 1280 in IPv6>ND to avoid MTU related issues.
And fixed MTU for IPv4 in the PPPoE interface that’s determined by my ISP at 1460.
There must be a mistake somewhere. When everything is configured like I mentioned it just works. The reason you can reach some sites and not others when you have this error is that some sites block ICMP (clueless firewall admins) and the same thing happens with IPv4.
I’ve shared my IPv6 config. Does it look correct to you? I also added this to IPv6 firewall:
add action=accept chain=input comment="ICMPv6 Packet Too Big" icmp-options=2:0-255 protocol=icmpv6
add action=accept chain=forward comment="ICMPv6 Packet Too Big" icmp-options=2:0-255 protocol=icmpv6
Also is there a way to make MikroTik “refresh” IPv6 client addresses within a specific time frame? I’ve noticed that after a few hours, some client devices have over 20 IPv6 addresses that are clearly dead as my ISP periodically refreshes their assigned prefixes.
I’ve seen the issues even with famous sites like “ipv6.google.com”. Sometimes I can reach them, sometimes I can’t.
First try to reproduce the issue without any firewall other than “accept established/related”, “accept icmpv6 (no further qualifiers)” and “accept new outgoing”.
That is the default configuration.
Also is there a way to make MikroTik “refresh” IPv6 client addresses within a specific time frame? I’ve noticed that after a few hours, some client devices have over 20 IPv6 addresses that are clearly dead as my ISP periodically refreshes their assigned prefixes.
Fortunately the ISPs here don’t do that, my addresses are completely static (although obtained using DHCPv6 PD, they never change).
I have seen others that mention problems with their ISP changing the prefix once per day.
Changing more than once per day would be enough for me to abandon that ISP, or at least abandon IPv6. It will be useless in the current situation without NPT (NAT) for IPv6.
Also, make sure you disable “privacy extensions” on the clients. It has no point when using fixed devices, and it only makes such problems worse.
First try to reproduce the issue without any firewall other than “accept established/related”, “accept icmpv6 (no further qualifiers)” and “accept new outgoing”.
That is the default configuration.
Yes, I’ve done this and was able to reproduce the same issue. And yes, at the moment, IPv6 firewall is the default from the RouterOS script on first boot.
So I tried settings it up again and noticed something, only 3 client devices at any given point of time are getting IPv6. Any ideas what could be causing this?
Here are my results on a Windows 10 Machine (I had to create a new inbound rule in Windows firewall to allow ICMPv6 echo and packet too big to get these results):
Fortunately the ISPs here don’t do that, my addresses are completely static (although obtained using DHCPv6 PD, they never change).
I have seen others that mention problems with their ISP changing the prefix once per day.
Changing more than once per day would be enough for me to abandon that ISP, or at least abandon IPv6. It will be useless in the current situation without NPT (NAT) for IPv6.
Also, make sure you disable “privacy extensions” on the clients. It has no point when using fixed devices, and it only makes such problems worse.
Yeah, my ISP changes both IPv4 and IPv6 every 24 hours give or take.
Privacy extensions means the client will not use the MAC-derived fixed IPv6 address structured like prefix:xx:xx:xx:ff:fe:xx:xx:xx but will change IPv6 address regularly.
(different random addresses prefix:xx:xx:xx:xx:xx:xx:xx:xx so no ff:fe in the middle and not looking like the MAC address)
I get a 10/10 on test-ipv6.com with all tests indicating successfull. This is on a PPPoE line with RFC4638 support and a MikroTik router.
They are ON by default and I do not know how to turn it off for those systems, I never use them.
Any ideas about my 3 client devices getting IPv6 but not the rest?
Plus I had to add an inbound rule on Windows firewall for packet too big to pass.
You will have permanent pain when you cannot get 1500 byte MTU and no way to communicate smaller MTU to the client (like in a ND).
Make sure you do not set the clients to “managed address” (DHCPv6 client), it will not work. It has to be SLAAC (router sends RA).
Also it appears that in some of my setups the Router Sollicitation does not operate correctly and only the regularly sent Router Advertisement is processed.
This means that initially the clients get only IPv4 (via DHCP) and then 200-600 seconds later they hear a RA and get IPv6.
So just connecting a client and immediately checking the situation can lead to deceptive results.
I did lower the RA interval to 30-120 in IPv6->ND to improve this a bit.
@pe1chl, yes you are correct in that I did not understand the root cause of the problem expressed by @DarkNate
My apologies to DarkNate …
I do not use PPPoE – mine is DHCP … but I do have similar behavior that DarkNate exposes which behavior is only caused when I reboot - or - my ISP reboots my Cable Gateway [in Bridge mode] and my Tik does not respond appropriately to the rebooted bridged cable modem. The ipv6 global address that I receive from my ISP does not change but for some reason my Tik exhibits this strange behavior and the only solution that I have found to fix it is the one I have described.
It looks like you did not read my original post thoroughly. It’s clearly obvious that I’m using ND and SLAAC through and through.
Router Solicitation for whatever reason is glitching not only on MikroTik. I have seen the exact same problem with TP-Link, D-Link, Netgear and so on and so forth.
My client devices get IPv6 only on 3 of them, and even then, when my ISP changes the prefix, my client devices have like 20 dead and expired IPv6 in their system. Applies to both my iOS and Windows 10 machine.
This strange behaviour with IPv6 router solicitation/advertisement is not limited to MikroTik. Consumer-grade devices are plagued with the same issues. I have tested and observed the same issue regardless of ISP.
I thought at least MikroTik wouldn’t have consumer-grade issues, but they do. Maybe I should’ve opted for a cisco router even though it’s expensive.
Yes on the router. But make sure your clients are correctly setup as well. When they are somehow configured for DHCPv6 (unusual!) it will not work.
Router Solicitation for whatever reason is glitching not only on MikroTik. I have seen the exact same problem with TP-Link, D-Link, Netgear and so on and so forth.
I happen to notice it this week when I was testing an installation where I before had IPv6 issues in the next hop past the MikroTik router.
I connected an Android phone, went immediately to network info and saw only IPv4. Ran test-ipv6.com and no IPv6. Looked in the router and saw others with active IPv6 connections in IPv6->firewall->connections. I was puzzeled, and in a hurry.
Later checked again and IPv6 was fine. That is when I did a trace and saw it comes up only on the first RA received, not immediately on connection.
The phone is supposed to send a Router Sollicitation when it connects, but either it does not do that or it is not received/processed correctly.
That may actually be related to Multicast filtering in the switch.
My client devices get IPv6 only on 3 of them, and even then, when my ISP changes the prefix, my client devices have like 20 dead and expired IPv6 in their system. Applies to both my iOS and Windows 10 machine.
It not working for all devices has to be some issue with RA not being processed correctly, they are being sent.
Having 20 dead addressses after one day can only be explained by privacy extensions being enabled, google how to disable it.
Your local systems remembering old prefixes after the ISP has changed them can be considered a RouterOS bug or at least limitation.
(it should send an RA with the old address and zero lifetime when it withdraws the old address to set the new one, but it doesn’t)
