Changing ipv6 prefix

i have a dynamic changing ipv6 prefix. For some reason it’s very dynamic an changes multiple times a day and i end up with multiple ipv6 addresses on the client’s.

https://www.ripe.net/publications/docs/ripe-690#5-2--why-non-persistent-assignments-are-considered-harmful
There under 5.2 is this mentioned: “If the CPE knows that the delegated prefix has changed, it should send out RA packets with a prefix valid lifetime of 0 to tell all devices that the old addresses are no longer valid.”
Is RouterOS sending an RA with a lifetime of 0 when the prefix changes? Or is there some way to do it with a script?

No, it isn’t doing this. I’m not sure how to fix it with a script, it may be possible. This is something I hope they will fix soon in RouterOS v7.

I think it’s something that RouterOS should support natively (eventually). But it should be doable using lease script too. You need to add previous prefix in /ipv6/nd with zero lifetime. I don’t know if there’s separate event for releasing old prefix and getting new one. If there is, and it’s in some variable set by script, it should be very easy. If not, you’d need to save previous prefix in some global variable and use that.

Edit: Actually, probably not that easy, because prefix that lease script see can be e.g. /56, but you’d need to advertise /64s used on individual interfaces, so that can be quite a bit of scripting.

Im not familiar with Mikrotik Scripting but would it be simple to just send a RA lifetime 0 bevor a prefix is Advertised? I guess in a simple network without multiple ipv6 networks this would not be to bad?

Yes and no. You can add config for advertising old prefix, but you first need to find out what it is. Because if you add it using address with from-pool, what prefix is selected is internal mechanism, you don’t know for sure what exact prefix it will be. So you’ll probably have to take one that was selected, but it depends on whether it’s stil there when lease script runs after the change.

Hello,
I am using RouterOS 7.1.1 and i have dynamic IPv6 /56 range from ISP.
My lan-clients (android 12, windows 10/11) are keeping the old IPv6 address and getting the new ones after some time, however it is the issue that you described.
Seems like well known issue, where IETF also stated workarounds - section 5.1 - Improvements to SLAAC
https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum-01#section-5.1

So, any chance that we can expect this implemented natively via RouterOS update?

There’s always chance, but someone needs to convince MikroTik. Before that happens, you’re on your own. After a not really enjoyable masochistic session with RouterOS scripting, I’m pretty sure it’s doable in some way with that. Here is what I came up with (DHCPv6 client lease script):

:if ($"pd-valid" = 1) do={
  :log info ("### acquired prefix: ".$"pd-prefix")
} else={
  :log info ("### lost prefix: ".$"pd-prefix")
  :local Addresses [/ipv6 address find from-pool=dhcp-pool]
  :log info $Addresses
  :foreach Address in=$Addresses do={
    :local Tmp [/ipv6 address get $Address address]
    :local Prefix ([:pick $Tmp 0 ([:len $Tmp] - 4)]."/64")
    :log info ("Prefix: ".$Prefix)
    :local Interface [/ipv6 address get $Address interface]
    :log info ("Interface: ".$Interface)
    :do {
      /ipv6 nd prefix add interface=$Interface prefix=$Prefix preferred-lifetime=0 valid-lifetime=0
    } on-error={
      :log warn "failed: /ipv6 nd prefix add interface=$Interface prefix=$Prefix preferred-lifetime=0 valid-lifetime=0"
    }
  }
}

It’s basic proof of concept, which almost works. Aside from zero robustness, the problem is that when I’m trying to add prefix with zero lifetime, same dynamic prefix already exists, so it fails. But it has to exist, because otherwise I wouldn’t be able to find what I need to add. Also, when I look at it now, I could have started there, and not from IPv6 address. The solution would be either to somehow delay the command to add zero-lifetime prefix, after the old dynamic one is removed (I’m not sure how, except maybe with horrible hack using scheduler), or script the whole address assignment, instead of using from-pool (which may not be too difficult). If anyone wants to play further, I wish you good luck.

As for me, my frustration level is high enough to last me for a while. I don’t know if it’s just me, but RouterOS scripting is so unintuitive and unfriedly, as if it was one of design goals. For example, I wanted to get prefix properly from any address. So I have an address:

[sob@CHR5] > :put [/ipv6 address get [find interface=test2 from-pool=dhcp-pool] address]
2001:db8:0:123:234:5678:9abc:def0/64

And I want only first 64 bits:

[sob@CHR5] > :put ([/ipv6 address get [find interface=test2 from-pool=dhcp-pool] address] & ffff:ffff:ffff:ffff::slight_smile:
Script Error: cannot compute bitwise “and” of string and ipv6 prefix

Oops. But I can do this and it works:

[sob@CHR5] > :put ([:toip6 “2001:db8::123:234:5678:9abc:def0”] & ffff:ffff:ffff:ffff::slight_smile:
2001:db8:0:123::

Fine, then I’ll just do this:

[sob@CHR5] > :put ([:toip6 [/ipv6 address get [find interface=test2 from-pool=dhcp-pool] address]] & ffff:ffff:ffff:ffff::slight_smile:

[sob@CHR5] >

What?! (edit: I see it now, it doesn’t like address ending with /64, I’d have to strip that first; so ok, it’s my mistake, but it’s one such problem after another)

Ok i see a script is kinda bad. And there should no need for it anyway. A “Simple” thing like acquiring an ip prefix should just work. But i found something.

Since 2 Days i log DHCP on debug. Now i found something that happens bevor every new prefix:

21:54:52 dhcp,debug,packet send pppoe-out1 -> ff02::1:2%50 
21:54:52 dhcp,debug,packet type: solicit 
21:54:52 dhcp,debug,packet transaction-id: aeb768

Oh the Router just solicit a new prefix! Every Day! Great
How can i stop this?

Edit:
It’s kinda simple:

21:54:40 pppoe,ppp,info pppoe-out1: terminating... 
21:54:40 pppoe,ppp,info pppoe-out1: disconnected 
21:54:40 pppoe,ppp,info pppoe-out1: initializing... 
21:54:40 pppoe,ppp,info pppoe-out1: waiting for packets... 
21:54:41 interface,info pppoe-out1 detect UNKNOWN 
21:54:41 dhcp,debug rebinding with any server... 
21:54:41 pppoe,ppp,info pppoe-out1: connecting... 
21:54:42 pppoe,ppp,info pppoe-out1: authenticated 
21:54:42 pppoe,ppp,info pppoe-out1: connected 
21:54:42 interface,info pppoe-out1 detect UNKNOWN 
21:54:42 dhcp,debug rebinding with any server...

pppoe Connection from the Provider goes down. I guess they do this every 24H on a Privat VDSL Connection to reset the V4… But i should get 180 Days with my V6 Prefix. Provider is 1&1 with a VDSL Bitstream Access to “Deutsche Telekom”
After the pppoe disconnect RouterOS tries 4 rebinds on DHCPV6 Client. After 4 rebind there is a solicit.
In the configuration from Deutsch Telekom the DHCPV6 Client is in the pppoe Connection.
Is there a way to change the behavior of RouterOS? Pause the DHCPV6 Client when there is no pppoe connection?

Basic idea about handling broken connections is that one must not assume that re-established connections will be able to handle previously used addresses. That’s even more the case with PtP connections (such as PPPoE) where whatever client has is routed from ISP towards client.
So it’s the only right thing for DHCP (and DHCPv6) client to do the full handshake. It’s then up to DHCP server to give out addresses according to admin’s policy.
Many ISPs have policy of (deliberately) changing addresses and prefixes for varous reasons (most of them have to do with their clients). And the only proper technical way to deal with it is to acquire static IP address and/or IPv6 prefix from ISP (sometimes this comes with additional cost).

Right… Since 20 Years we try to implement ipv6 and now its just time to “fix” every ISP in the World… More and more servers have no ipv4 anymore (for various reasons)
So what we do now? NAT? :frowning:

Found a Internet Draft: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-slaac-renum-01
And it ends in rfc9096: https://datatracker.ietf.org/doc/html/rfc9096

@Mikrotik could you please implement rfc9096?

No amount of NATing will save your ongoing connections, they’ll just break. Your ISP doing the disconnects in the middle of evening is … (insert your favourite curse word).

PPP profile has on-up and on-down event, so you can use them to enable and disable DHCPv6 client. But it may not help, because DHCPv6 client will probably start from scratch anyway when enabled.

I have no problem with a Breaking connection. My problem is the somewhat the lifetime of the ipv6 prefix. When i get a new prefix the old ipv6 address on the clients Steys there and is deprecated. The Clients are not able to figure that out in ipv6. The standard lifetime on Mikrotik is 1h and preferred 30minutes. i changed it to 30min and 15min. i don’t know what happens when u just lower it further, but i guess at some point, some things are happening
The goal would be to find a Solution to the prefix lifetime. It seems the Provider changes the prefix about every ~24h. So with the Mikrotik standard config i have ~1 Hour downtime every day… rfc9096 describes how to deal with such a situation. https://datatracker.ietf.org/doc/rfc9096/

My Provider (1&1) is a Reseller from “Deutsche Telekom” the have a so called Bit-stream access https://en.wikipedia.org/wiki/Bit-stream_access even my IP Adresse is from Deutsche Telekom. I know the Prefix lifetime from Deutsche Telekom is 180 Days. So i guest with the same IP it’s the same DHCP so i have the same time? So something is wrong with the Mikrotik DHCP Client…

I just found a Forum Post from my Provider from 2017. The mention a Prefix lifetime from 24h! Without rfc9096 i don’t know what to do! Disable → Enable the pppoe interface every night and hope for the best? But even then i see another problem with the V6 Address Advertisement on RouterOS :slight_smile:

When a Prefix is enabled and advertised in IPv6 Address List and there is a IP with that Prefix on the network it reports: “Duplicate Address Detected” and the Prefix is disabled. But there might be only staled addresses with the same Prefix. After a while they are gone, but RouterOS does not notice this and leaves the prefix disabled. So disable → enable pppoe could lead to this problem…
Theres a reason for rfc9096 :slight_smile:

There’s no doubt that this should be internal function. If you assign address using from-pool and pool changes, system should handle it. If it automatically advertises current valid prefix, it might as well advertise the old one with zero lifetime, it shouldn’t be too difficult to add it. You can write to MikroTik support and report it as bug or as feature request, and you’ll see what they tell you.

This issue was already reported in 2013, but apparently still not fixed. There’s scripts in the other threads, also, to try to deal with the problem.

Deprecating old IPv6 prefix when removed or replaced RFC6204
http://forum.mikrotik.com/t/deprecating-old-ipv6-prefix-when-removed-or-replaced-rfc6204/66526/1

IPv6 connectivity problems…
http://forum.mikrotik.com/t/ipv6-connectivity-problems/70214/1

It’s standard with IPv6 stuff, “there’s not enough demand for it”, so it can wait few years… :\

Also, when your IPv6 prefix changes multiple times per day it is probably better to handle it as “ISP does not support IPv6” and unconfigure it.
Otherwise you likely would have more problems than benefits due to this situation.

And of course, ask ISP to stop that silly behavior.

Or we could just follow RFC9096… This is an updated RFC6204…
And i ask my ISP about that silly behavior. In 2017… But they Act like Mikrotik and just don’t care…
Oh and while you on that thing. Could you just ask all other ISP’s in the World to fix that??? Sorry but there is no solution other than RFC9096…

There is a difference between “IPv6 address could sometimes change” (and maybe it would change every night) and “IPv6 address changes multiple times per day”.
Even when it would be perfectly handled by the router, there would still be issues when the address changes in the middle of your download, for example.
It would be inconvenient even when it would be handled immediately.