Total netowrking/MikroTik beginner: am I doing IPv6 right?

So yesterday I enabled IPv6 for the first time on my MikroTik router by reading some forum topics (and...advising with AI, sigh).

Today, my router has suddenly lost its IPv6 public IP, my guess is because it got a new prefix from the ISP but didn't update somehow. Going to whatismyipaddress website showed no IPv6. I just finished trying a myriad of configuration changes and it's finally working again, but I'm pretty sure I have some unnecessary/bad configuration. My ISP works with dynamic IPs and require PPPoE.

Can someone please look at these and let me know if all is well?

[u@MikroTik] /ipv6 dhcp-client print
Columns: INTERFACE, STATUS, REQUEST, PREFIX
# INTERFACE   STATUS  REQUEST  PREFIX                            
0 pppoe-out1  bound   prefix   xxxx:xxxx:xxxx:8700::/56, 19h43m8s
/ipv6 address print
Flags: D - DYNAMIC; G, L - LINK-LOCAL
Columns: ADDRESS, FROM-POOL, INTERFACE, ADVERTISE
#    ADDRESS                       FROM-POOL  INTERFACE     ADVERTISE
0 DL fe80::7a9a:18ff:fed0:82b8/64             B_LOCAL       no       
1 DL fe80::7a9a:18ff:fed0:82c0/64             sfp-sfpplus1  no       
2 DL fe80::a/64                               pppoe-out1    no       
3  G xxxx:xxxx:xxxx:8700::1/64     ipv6-pd    B_LOCAL       yes      
4  G xxxx:xxxx:xxxx:8701::/64      ipv6-pd    pppoe-out1    no 👈 notice this one says 8701 not 8700
/ipv6 nd print
Flags: X - disabled, I - invalid; * - default 
 0  * interface=all ra-interval=3m20s-10m ra-delay=3s mtu=unspecified reachable-time=unspecified 
      retransmit-interval=unspecified ra-lifetime=30m ra-preference=medium hop-limit=unspecified 
      advertise-mac-address=yes advertise-dns=yes managed-address-configuration=no 
      other-configuration=no dns="" pref64=""

Firewall:

/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" \
    connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=33434-33534 protocol=udp
add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 \
    protocol=udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept all that matches ipsec policy" ipsec-policy=\
    in,ipsec
add action=drop chain=input comment="defconf: drop everything else not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept established,related,untracked" \
    connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=\
    bad_ipv6
add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=\
    bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=ipsec-esp
add action=accept chain=forward comment="defconf: accept all that matches ipsec policy" ipsec-policy=\
    in,ipsec
add action=drop chain=forward comment="defconf: drop everything else not coming from LAN" \
    in-interface-list=!LAN

You shouldn't be doing both DHCPv6 client and RA on the WAN interface. The general pattern is prefix delegation via DHCP on the WAN, then RA to distribute it on the LAN.

Here's my take, documenting a working configuration. I've seen others report similar configurations as working elsewhere as well.

1 Like

Thanks. I just changed this actually, is this better?

[shibeladmin@MikroTik] > /ipv6 nd print
Flags: X - disabled, I - invalid; * - default 
 0 X* interface=all ra-interval=3m20s-10m ra-delay=3s mtu=unspecified reachable-time=unspecified 
      retransmit-interval=unspecified ra-lifetime=30m ra-preference=medium hop-limit=unspecified 
      advertise-mac-address=yes advertise-dns=yes managed-address-configuration=no 
      other-configuration=no dns="" pref64="" 

 1    interface=B_LOCAL ra-interval=3m20s-10m ra-delay=3s mtu=unspecified reachable-time=unspecified 
      retransmit-interval=unspecified ra-lifetime=30m ra-preference=medium hop-limit=unspecified 
      advertise-mac-address=yes advertise-dns=yes managed-address-configuration=no 
      other-configuration=no dns="" pref64="" 

OK, you have got yourself a subnet on ppoe-out1 <:::>8701::/64 is a subnet of <:::>8700::/64. You have been delegated a /56, which gives you 256 subnets from <:::>8700/64 to <:::>87ff/64.

I imagine you have put it on ppoe-out1 manually and maybe you have created a matching pool. Look at some client machines to see which subnet they have their addresses on. Beyond that, I don’t have much experience of ipv6.

Judging "better" requires me to know what B_LOCAL is. Rather than more back-and-forth guessing, how about you try it as I've documented and see how you get on? Then if there's a problem, we have a fully-documented baseline to work from.

1 Like

Judging "better" requires me to know what B_LOCAL is.

It's just a bridge interface for my LAN ethernet ports (sorry if I'm using the wrong jargon).

Rather than more back-and-forth guessing, how about you try it as I've documented and see how you get on? Then if there's a problem, we have a fully-documented baseline to work from.

I've read that once and got maybe 20% of what was written there (it's me, not you). It took me quite a while to get the hang of "regular" (IPv4) networking, RA, ND, and this concept of getting a prefix, slicing it and assigning my LOCAL network a subnet from that is very, alien to me.

I think what got messed up today is that I've somehow been assigned a different prefix, and all hell broke loose. This is what I attempted/I'm attempting to solve, without leaving invalid configurations alive.

It's just a bridge interface for my LAN

That's the hazard of departing from the stock naming. If you had kept it as "bridge" or "bridge1" (depending on device and RouterOS version you started with) it would have matched my example sufficiently. When you go and rename everything, you need to provide all those renamings to people used to the defaults, for use as a translation dictionary.

I've somehow been assigned a different prefix

Yes, which is why I went and did all that ULA stuff in the article. Keep re-reading until you get it. This is a simple home config, no more complex than necessary to be reliable. It's all there for a good reason.

1 Like

Yep, I'm focusing on this part. What confuses me is that it's under the subtitle "Inbound DNS". Isn't this more like DHCP? (which I know your article does not recommend using for home setups, or at least it uses a different technique)

That's 'inbound" from the router's perspective: LAN clients asking to use the caching DNS server.

Contrast "outbound" as the router contacting an upstream DoH server, for instance.

This ULA scheme is only DNS-specific in the sense that a LAN-side caching DNS server is the only service commonly running on a home router which all LAN clients are likely to need. If you have other services on that router which may benefit from having a LAN-side IPv6 address, the idea has broader applicability to you.

One more question regarding this point, and what is shown in the article:

add address=fddf:dffd:fdfd::1 advertise=no interface=bridge

And this quote:

That said, it is also valid to advertise the ULA. There are good reasons for doing so, but it's a site-specific decision.

Does that mean that after doing this step, I should NOT expect LAN clients to get an address in the range fddf:dffd:fdfd..? if so, how does this mitigate the scenario of an ISP initiated prefix change?

Thank you very much for the article and the help @tangent. I think the only place where my setup differs now is /ipv6/route/print. Whereas yours shows 3 items, mine has more entries:

#      DST-ADDRESS               GATEWAY                              DISTANCE
  DAd+ ::/0                      fe80::6aab:9ff:fe50:7401%pppoe-out1         1
0  As+ ::/0                      fe80::6aab:9ff:fe50:7401%pppoe-out1         1
  DAv+ ::/0                      pppoe-out1                                  1
  DAd  xxxx:xxxx:xxxx:a200::/56                                              1
  DAc  xxxx:xxxx:xxxx:a200::/64  B_LOCAL                                     0
  DAc  xxxx:xxxx:xxxx:a201::/64  pppoe-out1                                  0
  DAc  fdb7:5b00:ba4b::/64 👈 ULA      B_LOCAL                                     0 
  DAc  fe80::%sfp-sfpplus1/64    sfp-sfpplus1                                0
  DAc  fe80::%pppoe-out1/64      pppoe-out1                                  0
  DAc  fe80::%B_LOCAL/64         B_LOCAL                                     0

I should NOT expect LAN clients to get an address in the range fddf:dffd:fdfd..?

That's controlled by the advertise=yes/no setting, which the article is saying can be set either way, depending on what you're after. For the simple DNS-only case, the article explains why advertise=no works even though that means the clients don't get IPs in that scheme.

1 Like

If your ISP prefix changes often, you should consider reducing the preferred-lifetime and valid-lifetime settings under /ipv6 nd prefix default. The current default values are set extremely high and only suitable if you have static IPv6 prefix from the ISP.

Currently when the PPPoE client redials and the attached DHCPv6 client gets a new prefix, the router advertises the new prefix on your B_LOCAL interface but doesn't advertise the old prefix as deprecated. If you look on your LAN devices, for example with ipconfig /all under Windows, you'll see that the devices have both prefixes (usually with 4 addresses) listed as preferred. The devices might still use the old prefix (because still preferred) and of course have no connectivity.

If you have dynamic prefixes that changes often, reduce those two settings. The old addresses will stay preferred for at most the preferred-lifetime setting (then have their state changed to deprecated), and will disappear from the devices when valid-lifetime is up.

If you don't have hundreds of clients you can even set both values to 10m (what I am doing), and the clients will have the bad state for at most 10 minutes after the ISP has issued a new prefix.

2 Likes

Fantastic advice as I woke up this morning and discovered that within 10 hours I've been assigned more than 6-7 difference prefixes. Thank you!

It does seem like my ISP provider is handing my router out different prefixes at a staggering rate. Could this be some sort of setting on the router itself? I'm with a UPS so it can't be temporary power loss or anything like that.

Depends how you are connecting to the ISP. If it is a DHCP connection, you might be able to adjust the lease time on your side. If it is PPPoE, it might just be the line resyncing and possibly outside of your control.

The basic problem is your ISP and a bad implementation of IPv6. Static addresses should be the norm for IPv6. The address space is large enough not to require dynamic IP addresses [or NAT or CGNAT], but some ISPs seem to mindlessly apply the solutions to IPv4 problems to non problems on IPv6.

There is an argument that dynamic addresses on IPv6 provide ‘security’, but that is largely spurious and overall, I think that the ISPs should charge extra for dynamic addressing on IPv6. Over all, the solution is to ask the ISP for a static /56 or /48 delegation. And if they can’t manage this, then move to a more capable ISP.

Can you look at the "Link Downs" counter on the Status tab of the pppoe-out interface to see whether it might be caused by the PPPoE link being up & down often?

Another thing to observe, is the Prefix Expires After field of the DHCPv6 client instance. How long is the DHCPv6 client binding time set by the ISP? Does the DHCPv6 client tries to renew when Prefix Expires After reaches half of the lease time? and if yes, does the client get the same prefix or does the ISP gives out different prefixes at each lease renewal?

1 Like

Bingo. Link Downs: 204.
Last link down time: 2025-11-09 at 13:05 (5 hours ago)

So I think we have our reason. Question is: can something on the router cause this (attaching my dial out settings)? otherwise I'm going to have to make some support calls that I'm not looking forward to...(ISPs in my country tend to blame "your router" if you don't rent their overpriced, underpowered, s****y routers)

It's either one or the other, right? I'm positive I at least need PPoE.

Tell me about. Unfortunately ISP supply is even more scarce in my home country than it is elsewhere, and I'm not sure the other ISPs will behave any differently.

Does the fact that we see spf down then ppoe down indicate a hardware problem? I just noticed new IPs, went to the logs:

 19:02:33 interface,info sfp-sfpplus1 link down
 19:02:33 pppoe,ppp,info pppoe-out1: terminating... - disconnected
 19:02:33 pppoe,ppp,info pppoe-out1: disconnected
 19:02:33 pppoe,ppp,info pppoe-out1: initializing...
 19:02:33 pppoe,ppp,info pppoe-out1: connecting...
 19:02:33 interface,info sfp-sfpplus1 link up (speed 1G, full duplex)
 19:02:33 pppoe,ppp,info pppoe-out1: terminating...
 19:02:33 pppoe,ppp,info pppoe-out1: disconnected
 19:02:33 pppoe,ppp,info pppoe-out1: initializing...
 19:02:33 pppoe,ppp,info pppoe-out1: connecting...
 19:02:34 pppoe,ppp,info pppoe-out1: authenticated
 19:02:34 pppoe,ppp,info pppoe-out1: connected

Edit: just checked the temperature on my SFP module and MikroTik says it 78 C. That's a bit much isn't? could it be shutting down due to heat? (manufacturer says operating temperature is up to 85 C)

Edit2: I'm not sure where the bug is, the Winbox UI or the log output, but in the attached image the items appear in a different order.

Edit3: A related thread about SFP problems with the RB5009 (the model I have).

You need to sort by the first column, not by the date/time column. In your screenshot, the column with the index is out of order.

Your PPPoE client settings look normal to me. The problem is apparently due to your sfp-sfpplus1 port flapping. Do you have a SFP GPON ONU module? those normally run very hot, and your temperature probably causes the shutdowns.

On my RB5009 with an old Alcatel-Lucent G-010S-P module I have to put two mini heatsinks on it plus active cooling from two mini USB fans (they also cool the RB5009) to bring the temperature down to 37°C:

With this temperature my router and the GPON module have been running without issue for the past few years.

1 Like