Community discussions

MikroTik App
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 5:05 pm

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:
/ipv6 dhcp-client
add add-default-route=yes interface=pppoe-out1 pool-name=IPv6_Pool rapid-commit=no request=prefix use-peer-dns=no

/ipv6 address
add from-pool=IPv6_Pool interface=bridge advertise=yes

ipv6 nd print
 0  * interface=bridge ra-interval=3m20s-10m ra-delay=3s mtu=unspecified reachable-time=unspecified retransmit-interval=unspecified ra-lifetime=30m hop-limit=unspecified 
      advertise-mac-address=yes advertise-dns=yes managed-address-configuration=no other-configuration=no
      
ipv6 settings print
forward: yes
accept-redirects: yes-if-forwarding-disabled
accept-router-advertisements: yes
max-neighbor-entries: 8192
 
User avatar
mozerd
Member
Member
Posts: 410
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 5:46 pm

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.

using test-ipv6.com I get 10/10

Not sure why RouterOS behaves this way ......
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 6:11 pm

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.

using test-ipv6.com I get 10/10

Not sure why RouterOS behaves this way ......
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?
 
User avatar
mozerd
Member
Member
Posts: 410
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 6:30 pm

Is there anything wrong with my IPv6 configuration?
Your ipv6 config is fine

I agree that this should not be happening and my suggestion is only a temporary fix.

Inquire with MikroTik Support
support@mikrotik.com
and see what they have to suggest.
 
pe1chl
Forum Guru
Forum Guru
Posts: 6675
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 7:05 pm

IPv6 large packet fail
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.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 7:08 pm

Is there anything wrong with my IPv6 configuration?
Your ipv6 config is fine

I agree that this should not be happening and my suggestion is only a temporary fix.

Inquire with MikroTik Support
support@mikrotik.com
and see what they have to suggest.
I emailed them. Let's hope they can resolve this. I linked them to thread in the email.
 
pe1chl
Forum Guru
Forum Guru
Posts: 6675
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 7:17 pm

I emailed them. Let's hope they can resolve this. I linked them to thread in the email.
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:
/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes \
    protocol=tcp tcp-flags=syn
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.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 7:29 pm

IPv6 large packet fail
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.

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.
Source: https://tools.ietf.org/html/rfc2516 (Check Section 7 LCP Considerations)

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.

Cloudflare has a blog about IPv6 "fragmentation": https://blog.cloudflare.com/ip-fragmentation-is-broken/

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.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 7:31 pm

I emailed them. Let's hope they can resolve this. I linked them to thread in the email.
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:
/ipv6 firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes \
    protocol=tcp tcp-flags=syn
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.
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.
 
pe1chl
Forum Guru
Forum Guru
Posts: 6675
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 8:06 pm

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.
Source: https://tools.ietf.org/html/rfc2516 (Check Section 7 LCP Considerations)
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.

Cloudflare has a blog about IPv6 "fragmentation": https://blog.cloudflare.com/ip-fragmentation-is-broken/

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.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 8:35 pm

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.
 
pe1chl
Forum Guru
Forum Guru
Posts: 6675
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 9:55 pm

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
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.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 10:27 pm

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): Image
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.

What are "privacy extensions"?
 
pe1chl
Forum Guru
Forum Guru
Posts: 6675
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 11:08 pm

What are "privacy extensions"?
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.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Fri Jun 26, 2020 11:15 pm

What are "privacy extensions"?
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.
How do I turn "privacy extensions" off on my iOS and Windows Machine? I think they are off by default?

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.
 
pe1chl
Forum Guru
Forum Guru
Posts: 6675
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 10:41 am

How do I turn "privacy extensions" off on my iOS and Windows Machine? I think they are off by default?
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.
 
User avatar
mozerd
Member
Member
Posts: 410
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 1:32 pm

I think mozerd did not understand the root cause of the problem.
@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.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 3:31 pm

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.
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.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 3:35 pm

I think mozerd did not understand the root cause of the problem.
@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.
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.
 
pe1chl
Forum Guru
Forum Guru
Posts: 6675
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 5:18 pm

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.
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.
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)
 
User avatar
mozerd
Member
Member
Posts: 410
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 5:33 pm

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)
IMO, its a bug but yes perhaps a current RouterOS limitation -- only MikroTik can confirm.

I have many clients not all windows clients, many Apple and Linux ..... all exhibit this strange behavior after a ISP CPE reboot and the only FIX is the one that I mentioned earlier.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 5:42 pm

Yes on the router. But make sure your clients are correctly setup as well.
So I have 3 OSes on my clients, iOS, Windows and Android. I cannot disable "privacy extensions" on iOS nor on Android, and on Windows, if it's disabled, router discovery would also be disabled. On RouterOS, I unchecked "Advertise MAC address" which I assumed will help with this "privacy extensions" issue.

When they are somehow configured for DHCPv6 (unusual!) it will not work.
And iOS, Android and Windows all support SLAAC out of the box, I don't see config problems on client devices on IPv6.

Also Android is... Android: https://www.nullzero.co.uk/android-does ... -fix-that/

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.
So clearly, I'm not the only user-facing IPv6 issues on MikroTik and also other brands. What's really the cause here? I mean, it's a major problem that is seemingly ignored by the vendors.

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)
Privacy extensions cannot be altered on Android/iOS, and even if we could, this seems more like a dirty hack than a proper IPv6 solution/implementation.

Another small hack I came up with is to reduce the preferred and preferred-lifetime & valid-lifetime to 2 hours in ND>Prefix, it seems to work and forces the client devices to refresh IPv6 addresses every two hours or at least drop whatever it used after 2 hours, but again this is dirty and not a clean solution and I'm not sure if it'll work well in the long-run.

However, I'm really frustrated that only 3 devices at any point of time is receiving IPv6 addresses to begin with. My RouterOS and client devices configuration all looks good to me. My email to MikroTik is still left without a reply for now.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 5:45 pm

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)
IMO, its a bug but yes perhaps a current RouterOS limitation -- only MikroTik can confirm.

I have many clients not all windows clients, many Apple and Linux ..... all exhibit this strange behavior after a ISP CPE reboot and the only FIX is the one that I mentioned earlier.
I am glad to know this issue isn't isolated only to me. I kept thinking it was my config or something. Somebody should file a bug report on this.

Check my previous reply, I have come up with a small hack that seems to work-around this issue

Also, I'd like to emphasise that this issue isn't limited to MikroTik, the same misbehaviour occurs on many generic and popular consumer routers.
 
User avatar
mozerd
Member
Member
Posts: 410
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 6:25 pm

Another small hack I came up with is to reduce the preferred and preferred-lifetime & valid-lifetime to 2 hours in ND>Prefix, it seems to work and forces the client devices to refresh IPv6 addresses every two hours or at least drop whatever it used after 2 hours, but again this is dirty and not a clean solution and I'm not sure if it'll work well in the long-run..
DarkNate ... that's a nice hack :)
I am not able to change this under Winbox ...... how did you do it using CLI?
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 6:30 pm

Another small hack I came up with is to reduce the preferred and preferred-lifetime & valid-lifetime to 2 hours in ND>Prefix, it seems to work and forces the client devices to refresh IPv6 addresses every two hours or at least drop whatever it used after 2 hours, but again this is dirty and not a clean solution and I'm not sure if it'll work well in the long-run..
DarkNate ... that's a nice hack :)
I am not able to change this under Winbox ...... how did you do it using CLI?
You need to disable DHCPv6 Client/IPv6Address first, set up ND>Prefix. Then it'll automatically allocate the values you set when DHCPv6 client is restarted. I used Winbox.
Last edited by DarkNate on Sat Jun 27, 2020 6:36 pm, edited 2 times in total.
 
User avatar
mozerd
Member
Member
Posts: 410
Joined: Thu Oct 05, 2017 3:39 pm
Location: Canada
Contact:

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 6:33 pm

Thank You
 
pe1chl
Forum Guru
Forum Guru
Posts: 6675
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 6:41 pm

However, I'm really frustrated that only 3 devices at any point of time is receiving IPv6 addresses to begin with. My RouterOS and client devices configuration all looks good to me. My email to MikroTik is still left without a reply for now.
I am operating a couple of WiFi networks at company locations where 200-500 clients are connected every day (Android, Apple, Windows, ChromeOS etc) and out of those I see maybe 3-10 that are not actively using IPv6. Maybe they have disabled it somehow.

But then, we do not have dynamic prefixes. One location has completely fixed addresses, two others have DHCPv6 PD setups like you have but the ISP always returns the same prefix, so the addresses never change.
At one of the locations we recently observed 2 issues:
- the upstream was PPPoE with 1492 byte MTU (not established from the MikroTik router but from an upstream ISP-owned router)
this was fixed by setting 1492 as the MTU in the ND setting, and also proactively by a MSS clamp rule as shown above.
- the ISP router somehow failed to route most IPv6 packets, sometimes it works but mostly not. It was replaced and now works OK. this however caused massive confusion in some apps that see that they have IPv6 but it does not actually work ("your internet connection is bad"). I temporarily worked around that by turning off IPv6 entirely until the router was replaced, and that solved the immediate problem.

From then on, IPv6 works fine on this location as well, but I observed the RA issue when debugging it. This however does not affect the usual users who are connected several hours and get their IPv6 setting after one or two minutes.
I still plan to trace the Router Sollicitation situation. I guess it maybe filtered somewhere outside the MikroTik router, or maybe it is not even sent at all by some devices.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Sat Jun 27, 2020 7:57 pm

I am operating a couple of WiFi networks at company locations where 200-500 clients are connected every day (Android, Apple, Windows, ChromeOS etc) and out of those I see maybe 3-10 that are not actively using IPv6. Maybe they have disabled it somehow.

But then, we do not have dynamic prefixes. One location has completely fixed addresses, two others have DHCPv6 PD setups like you have but the ISP always returns the same prefix, so the addresses never change.
At one of the locations we recently observed 2 issues:
- the upstream was PPPoE with 1492 byte MTU (not established from the MikroTik router but from an upstream ISP-owned router)
this was fixed by setting 1492 as the MTU in the ND setting, and also proactively by a MSS clamp rule as shown above.
- the ISP router somehow failed to route most IPv6 packets, sometimes it works but mostly not. It was replaced and now works OK. this however caused massive confusion in some apps that see that they have IPv6 but it does not actually work ("your internet connection is bad"). I temporarily worked around that by turning off IPv6 entirely until the router was replaced, and that solved the immediate problem.

From then on, IPv6 works fine on this location as well, but I observed the RA issue when debugging it. This however does not affect the usual users who are connected several hours and get their IPv6 setting after one or two minutes.
I still plan to trace the Router Sollicitation situation. I guess it maybe filtered somewhere outside the MikroTik router, or maybe it is not even sent at all by some devices.
I think we should try to contact MikroTik about these issues, as there's no way the users can work-around this. I've emailed them, it would be great if more than one user does the same thing.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Sun Jun 28, 2020 1:06 am

It also looks like the mangle rules for tcp-mss-clamping aren't required anymore: viewtopic.php?t=122019#p781363
 
pe1chl
Forum Guru
Forum Guru
Posts: 6675
Joined: Mon Jun 08, 2015 12:09 pm

Re: IPv6 configuration on PPPoE interface

Sun Jun 28, 2020 11:29 am

I think we should try to contact MikroTik about these issues, as there's no way the users can work-around this. I've emailed them, it would be great if more than one user does the same thing.
MikroTik is not interested in IPv6 issues. Their customers never ask for it, they say.
It also looks like the mangle rules for tcp-mss-clamping aren't required anymore
This very likely only is true for IPv4.
 
User avatar
floaty
Member Candidate
Member Candidate
Posts: 194
Joined: Sat Oct 20, 2018 1:24 am
Location: 52°08'32.34"N 14°39'05.0"E

Re: IPv6 configuration on PPPoE interface

Fri Jul 03, 2020 11:57 pm

... who's wondering ?
we have IPv6 running for over 10 years in the provider-production-environment ... but who's using ? in EMEA or AMER (without BETA-Feeling) ?
Noises heard: it's running big time in the "chinese-internet" (and they wanna be part of the standardization-process ... [they invented the loo-paper .. so ... why not ??] )
... BUT probably ("wise-guys"-thinking in mind) ... it's skiped ... and we proceed with v8 ... or vX : )
~~
We know what happens to people who stay in the middle of the road. They get run over.
 
DarkNate
newbie
Topic Author
Posts: 25
Joined: Fri Jun 26, 2020 4:37 pm

Re: IPv6 configuration on PPPoE interface

Sat Jul 04, 2020 10:29 pm

... who's wondering ?
we have IPv6 running for over 10 years in the provider-production-environment ... but who's using ? in EMEA or AMER (without BETA-Feeling) ?
Noises heard: it's running big time in the "chinese-internet" (and they wanna be part of the standardization-process ... [they invented the loo-paper .. so ... why not ??] )
... BUT probably ("wise-guys"-thinking in mind) ... it's skiped ... and we proceed with v8 ... or vX : )
What? Your English is R.I.P.

Who is online

Users browsing this forum: No registered users and 51 guests