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.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?
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?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.
: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"
}
}
}
And I want only first 64 bits:[sob@CHR5] > :put [/ipv6 address get [find interface=test2 from-pool=dhcp-pool] address]
2001:db8:0:123:234:5678:9abc:def0/64
Oops. But I can do this and it works:[sob@CHR5] > :put ([/ipv6 address get [find interface=test2 from-pool=dhcp-pool] address] & ffff:ffff:ffff:ffff::)
Script Error: cannot compute bitwise "and" of string and ipv6 prefix
Fine, then I'll just do this:[sob@CHR5] > :put ([:toip6 "2001:db8::123:234:5678:9abc:def0"] & ffff:ffff:ffff:ffff::)
2001:db8:0:123::
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)[sob@CHR5] > :put ([:toip6 [/ipv6 address get [find interface=test2 from-pool=dhcp-pool] address]] & ffff:ffff:ffff:ffff::)
[sob@CHR5] >
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
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...
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.Is there a way to change the behavior of RouterOS? Pause the DHCPV6 Client when there is no pppoe connection?
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 happeningNo 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).
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...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.
Or we could just follow RFC9096... This is an updated RFC6204...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.
That's true! But im used to losing my connection every 24 Hours (it's just bad to get another Hour or so on top with that lifetime thing). That's just normal in Germany! The ISP's are selling changing IP addresses as a Privacy feature. If you give a German a fixed IP, he gets upset about his privacy! And even in a business subscription you can end up paying +5€ a month for a fixed IP. The sell "privacy" to Privat Customers and selling fixed addresses to costumers who depend on it. And now i write a Post in an Customer Forum about how bad that is.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.
/ipv6 address
add interface=<LAN1> address=::1/64 advertise=yes comment=addr1 disabled=yes
add interface=<LAN2> address=::1/64 advertise=yes comment=addr2 disabled=yes
/ipv6 nd prefix
add interface=<LAN1> prefix=::/64 preferred-lifetime=0s valid-lifetime=0s disabled=yes
add interface=<LAN2> prefix=::/64 preferred-lifetime=0s valid-lifetime=0s disabled=yes
:local Config {{name="addr1";addr="::1:0:0:0:1"};{name="addr2";addr="::2:0:0:0:1"}}
foreach C in=$Config do={
:local IdAddr [/ipv6 address find comment=($C->"name")]
:local Interface [/ipv6 address get $IdAddr interface]
:local Disabled [/ipv6 address get $IdAddr disabled]
:local IdPrefix [/ipv6 nd prefix find interface=$Interface valid-lifetime="0s"]
:local OldAddr [/ipv6 address get $IdAddr address]
:local OldPrefix (([:toip6 [:pick $OldAddr 0 [:find $OldAddr "/"]]] & ffff:ffff:ffff:ffff::)."/64")
:if ($"pd-valid" = 1) do={
:local NewAddr (([:toip6 [:pick $"pd-prefix" 0 [:find $"pd-prefix" "/"]]] | [:toip6 ($C->"addr")])."/64")
:local NewPrefix (([:toip6 [:pick $NewAddr 0 [:find $NewAddr "/"]]] & ffff:ffff:ffff:ffff::)."/64")
:if ($OldAddr != $NewAddr || $Disabled = true) do={
:if ($OldPrefix = $NewPrefix) do={
/ipv6 nd prefix set $IdPrefix disabled=yes
:delay 1s
}
:log info ($Interface.": new prefix: ".$NewPrefix)
/ipv6 address set $IdAddr address=$NewAddr disabled=no
:delay 1s
:if ($OldPrefix != $NewPrefix && $OldPrefix != ::/64) do={
/ipv6 nd prefix set $IdPrefix prefix=$OldPrefix disabled=no
:log info ($Interface.": expired prefix: ".$OldPrefix)
:delay 1s
}
}
} else={
/ipv6 address set $IdAddr disabled=yes
:delay 1s
/ipv6 nd prefix set $IdPrefix prefix=$OldPrefix disabled=no
:log info ($Interface.": expired prefix: ".$OldPrefix)
:delay 1s
}
}
Well I already wrote, it would be possible to live with it when it changes once a day, and during a time you are not likely to be using the computer (maybe 03:00 or so).That's true! But im used to losing my connection every 24 Hours (it's just bad to get another Hour or so on top with that lifetime thing). That's just normal in Germany! The ISP's are selling changing IP addresses as a Privacy feature. If you give a German a fixed IP, he gets upset about his privacy! And even in a business subscription you can end up paying +5€ a month for a fixed IP. The sell "privacy" to Privat Customers and selling fixed addresses to costumers who depend on it. And now i write a Post in an Customer Forum about how bad that is.
Fortunately here in the Netherlands we do not have this issue and all IP addresses are fixed by default. At my (and I think all other VDSL and Fiber) providers it only changes when the provider has to do some network changes (maybe once every 3-5 years or so) and at Cable providers it usually does not change unless you power off your router and leave it powered off for more than an hour or so (they apparently use DHCP with a lease lifetime of about an hour).I wouldn't fuss here if I had another option! Or do you thing the IETF is releasing rfc9096 just for fun? I also think this a a bad idea, but what options are there?
Reeboting the Router over night and just eat that even longer downtime? That's kind of an option But... Power Outage... Electrician cuts the line... Construction worker destroys the line... Stuff at the Provider... etc...
I never hear people complaining about privacy of their IP address.
In the Netherlands we are not that naive that we believe that our privacy on internet is related to our IP address...I never hear people complaining about privacy of their IP address.
I guess it's about educating people/customers (even if the subject of education is utter nonsense). In Germany it seems to be privacy on internet. In my country it's section speed measurement on motorways (which is deemed unconstitutional due to privacy concerns), In Netherlands it might be something else (I hope there isn't though).
I know #21 ? viewtopic.php?t=182894#p911451It's your ISP that's causing the problem, they should be giving persistent /56s
https://www.ripe.net/publications/docs/ ... ed-harmful
thx but i just tried this today:Until you get built-in suppport from MikroTik, which is the right solution, you can try the following. I couldn't resist and had to try once more. It's still not exactly beautiful, but this time it works. Initial config is (do not use from-pool for addresses):
Actual configuration of addresses is at the first line of script, "name" must match comment given to address, "addr" is partial address what will be combined with prefix.Code: Select all/ipv6 address add interface=<LAN1> address=::1/64 advertise=yes comment=addr1 disabled=yes add interface=<LAN2> address=::1/64 advertise=yes comment=addr2 disabled=yes /ipv6 nd prefix add interface=<LAN1> prefix=::/64 preferred-lifetime=0s valid-lifetime=0s disabled=yes add interface=<LAN2> prefix=::/64 preferred-lifetime=0s valid-lifetime=0s disabled=yes
Code: Select all:local Config {{name="addr1";addr="::1:0:0:0:1"};{name="addr2";addr="::2:0:0:0:1"}} foreach C in=$Config do={ :local IdAddr [/ipv6 address find comment=($C->"name")] :local Interface [/ipv6 address get $IdAddr interface] :local Disabled [/ipv6 address get $IdAddr disabled] :local IdPrefix [/ipv6 nd prefix find interface=$Interface valid-lifetime="0s"] :local OldAddr [/ipv6 address get $IdAddr address] :local OldPrefix (([:toip6 [:pick $OldAddr 0 [:find $OldAddr "/"]]] & ffff:ffff:ffff:ffff::)."/64") :if ($"pd-valid" = 1) do={ :local NewAddr (([:toip6 [:pick $"pd-prefix" 0 [:find $"pd-prefix" "/"]]] | [:toip6 ($C->"addr")])."/64") :local NewPrefix (([:toip6 [:pick $NewAddr 0 [:find $NewAddr "/"]]] & ffff:ffff:ffff:ffff::)."/64") :if ($OldAddr != $NewAddr || $Disabled = true) do={ :if ($OldPrefix = $NewPrefix) do={ /ipv6 nd prefix set $IdPrefix disabled=yes } /ipv6 address set $IdAddr address=$NewAddr disabled=no :if ($OldPrefix != $NewPrefix && $OldPrefix != ::/64) do={ :delay 1s /ipv6 nd prefix set $IdPrefix prefix=$OldPrefix disabled=no } } } else={ /ipv6 address set $IdAddr disabled=yes :delay 1s /ipv6 nd prefix set $IdPrefix prefix=$OldPrefix disabled=no } }
/ipv6 nd prefix
add interface=<LAN1> prefix=::/64 preferred-lifetime=0s valid-lifetime=0s disabled=no
Windows-IP-Konfiguration
Ethernet-Adapter Ethernet 6:
Verbindungsspezifisches DNS-Suffix: home
IPv6-Adresse. . . . . . . . . . . : 5813:200:280f:200:2c48:43a5:51ff:d554
Temporäre IPv6-Adresse. . . . . . : 5813:200:280f:200:b918:8b6c:f7d:9144
Verbindungslokale IPv6-Adresse . : fe80::2c47:43a5:52ff:d454%4
netsh interface ipv6 show interfaces 4 level=verbose
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Other Preferred infinite infinite fe80::d4b7:93e0:15dd:6520%2
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Temporary Preferred 6d23h59m55s 23h55m14s 2001:db8:aaaa:2:e03f:1316:8927:d9b0
Public Preferred 29d23h59m58s 6d23h59m58s 2001:db8:aaaa:2:d4b7:93e0:15dd:6520
Other Preferred infinite infinite fe80::d4b7:93e0:15dd:6520%2
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Temporary Deprecated 1h56m51s 0s 2001:db8:aaaa:2:e03f:1316:8927:d9b0
Public Deprecated 1h56m51s 0s 2001:db8:aaaa:2:d4b7:93e0:15dd:6520
Temporary Preferred 6d23h59m52s 23h55m11s 2001:db8:bbbb:2:e03f:1316:8927:d9b0
Public Preferred 29d23h59m52s 6d23h59m52s 2001:db8:bbbb:2:d4b7:93e0:15dd:6520
Other Preferred infinite infinite fe80::d4b7:93e0:15dd:6520%2
Addr Type DAD State Valid Life Pref. Life Address
--------- ----------- ---------- ---------- ------------------------
Temporary Deprecated 1h55m19s 0s 2001:db8:aaaa:2:e03f:1316:8927:d9b0
Public Deprecated 1h55m19s 0s 2001:db8:aaaa:2:d4b7:93e0:15dd:6520
Temporary Deprecated 1h59m54s 0s 2001:db8:bbbb:2:e03f:1316:8927:d9b0
Public Deprecated 1h59m54s 0s 2001:db8:bbbb:2:d4b7:93e0:15dd:6520
Temporary Preferred 6d23h59m47s 23h55m6s 2001:db8:cccc:2:e03f:1316:8927:d9b0
Public Preferred 29d23h59m54s 6d23h59m54s 2001:db8:cccc:2:d4b7:93e0:15dd:6520
Other Preferred infinite infinite fe80::d4b7:93e0:15dd:6520%2
/ipv6 nd set [ find default=yes ] other-configuration=yes ra-delay=5s ra-interval=5s-30s
/ipv6 nd prefix default set preferred-lifetime=5m valid-lifetime=10m
[admin@MikroTik] /ipv6 nd> print
Flags: X - disabled, I - invalid, * - default
0 * interface=bridge ra-interval=1m30s-4m30s ra-delay=3s mtu=unspecified reachable-time=unspecified retransmit-interval=unspecified ra-lifetime=10m hop-limit=unspecified
advertise-mac-address=yes advertise-dns=no managed-address-configuration=no other-configuration=no
[admin@MikroTik] /ipv6 nd prefix> print
Flags: X - disabled, I - invalid, D - dynamic
0 D prefix=2001:x:x:x::/64 6to4-interface=none interface=bridge on-link=yes autonomous=yes valid-lifetime=4w2d preferred-lifetime=1w
[admin@MikroTik] /ipv6 nd prefix> /ipv6 nd prefix set preferred-lifetime=10m valid-lifetime=1h
numbers: 0
failure: can not change dynamic prefix
inet6 2001:x:x:x:b:b:b:b/64 scope global dynamic mngtmpaddr
valid_lft 2591854sec preferred_lft 604654sec
inet6 2001:x:x:x:a:a:a:a/64 scope global dynamic mngtmpaddr
valid_lft 2587382sec preferred_lft 600182sec
Thank you! I didn't see that before. That did it.Look at /ipv6/nd/prefix/default.
[admin@MikroTik] /ipv6 nd prefix default> print
autonomous: yes
valid-lifetime: 1h
preferred-lifetime: 10m
No this will not work... I testet with a Win 10 Client. It's kinda impossible to work with.So, we all here agree, that the only and permanent solution is would be the Mikrotik router needs to support RFC 9096 https://datatracker.ietf.org/doc/html/rfc9096 which is basically newer version of previous RFC6204 ? And this script is kind of workaround?
I am thinking of other alternatives:
1) Implement new local static IPv6 range for LAN and then do NAT
2) Disable IPv6 completely for LAN
I am sad about both options.
I could slowly make friends with nat again1) Implement new local static IPv6 range for LAN and then do NAT
There are now a few VPS providers who have switched off IPV4 because it is too complicated. In the long term, I think you will have problems without the V6 just as you would without the V4 today.2) Disable IPv6 completely for LAN
you can see them with:I can't see the lifetime values in windows, but I can in linux. It's following the 4w2d "nd prefix" values that I can't change.
netsh interface ipv6 show addresses
As long as the router has the prefix, that shouldn't happen. from what I've seen so far, the client always gets the prefix renewed in less than 1 minute. But if the router distributes a new prefix, you just want to get rid of the old one as quickly as possible, since this leads to connection problems.but if we set to 10 minutes, will the client device definitely loose the IPv6 address after 10 minutes. What if HTTP file download is in place that is longer then 10 minutes, IP connection will break, right?
With all these expired prefixes everything works? I can't imagine, probably because these are documentation prefixes? I notice that it works better on modern clients these days, but not 100%. For example the Twitter App and the picture cdn, which sometimes take 5 seconds to establish a connection. In the Chrome browser under Android and Windows again no problems...After prefix changed:
Another change:Code: Select allAddr Type DAD State Valid Life Pref. Life Address --------- ----------- ---------- ---------- ------------------------ Temporary Deprecated 1h56m51s 0s 2001:db8:aaaa:2:e03f:1316:8927:d9b0 Public Deprecated 1h56m51s 0s 2001:db8:aaaa:2:d4b7:93e0:15dd:6520 Temporary Preferred 6d23h59m52s 23h55m11s 2001:db8:bbbb:2:e03f:1316:8927:d9b0 Public Preferred 29d23h59m52s 6d23h59m52s 2001:db8:bbbb:2:d4b7:93e0:15dd:6520 Other Preferred infinite infinite fe80::d4b7:93e0:15dd:6520%2
So it seems to work fine. Well, almost, one time it got stuck, there was valid IP address with advertise=yes, but RouterOS didn't send any advertisements. It only started after I disabled and enabled it again. Which is unfortunate, but could be probably fixed if script did that after adding address, maybe with some additional delays to give system time to process everything (ugly solution, but...).Code: Select allAddr Type DAD State Valid Life Pref. Life Address --------- ----------- ---------- ---------- ------------------------ Temporary Deprecated 1h55m19s 0s 2001:db8:aaaa:2:e03f:1316:8927:d9b0 Public Deprecated 1h55m19s 0s 2001:db8:aaaa:2:d4b7:93e0:15dd:6520 Temporary Deprecated 1h59m54s 0s 2001:db8:bbbb:2:e03f:1316:8927:d9b0 Public Deprecated 1h59m54s 0s 2001:db8:bbbb:2:d4b7:93e0:15dd:6520 Temporary Preferred 6d23h59m47s 23h55m6s 2001:db8:cccc:2:e03f:1316:8927:d9b0 Public Preferred 29d23h59m54s 6d23h59m54s 2001:db8:cccc:2:d4b7:93e0:15dd:6520 Other Preferred infinite infinite fe80::d4b7:93e0:15dd:6520%2
With all these expired prefixes everything works?
that's exactly how ipv6 is supposed to work. When the preferred lifetime has expired, the devices invent a new address. The only problem with the changing prefixes is that the devices continue to use the deprecated and these can no longer be routed. and there is probably no way to get rid of them.With all these expired prefixes everything works?
My observation is that devices tend to "invent" IPv6 addresses once in a while even if prefix doesn't change. They will start to use new address for new connections, but will keep using depreciated addresses for already established connections.
This of course only works if prefix doesn't change and the old address is still valid in context of subnet.
Well, it is kind of optional. It is called "privacy extensions". It is useful when you have a device that connects to multiple networks, e.g. a laptop or phone that you take with you and connect to all kinds of networks. Or it could be argued it has some value when your IP prefix changes all the time.that's exactly how ipv6 is supposed to work. When the preferred lifetime has expired, the devices invent a new address. The only problem with the changing prefixes is that the devices continue to use the deprecated and these can no longer be routed. and there is probably no way to get rid of them.
My observation is that devices tend to "invent" IPv6 addresses once in a while even if prefix doesn't change. They will start to use new address for new connections, but will keep using depreciated addresses for already established connections.
This of course only works if prefix doesn't change and the old address is still valid in context of subnet.
Depends on how you define everything. Not access to internet, obviously, but that's not needed for "lab" test (if I dared to call few CHRs a lab ). But otherwise it seems good. Windows accept new prefixes and zero preferred lifetime of old ones. Running ping switches to new address when it becomes available. I'm too lazy to reconfigure stuff for real addresses, but there's no reason why it would work differently with them.With all these expired prefixes everything works? I can't imagine, probably because these are documentation prefixes?
Yes, but then you don't see the problem either. it's "only" the problem that clients use an outdated v6 to get on the internet and that doesn't work thanks to the prefix change.Depends on how you define everything. Not access to internet, obviously, but that's not needed for "lab" test (if I dared to call few CHRs a lab ). But otherwise it seems good. Windows accept new prefixes and zero preferred lifetime of old ones. Running ping switches to new address when it becomes available. I'm too lazy to reconfigure stuff for real addresses, but there's no reason why it would work differently with them.
Well, when the PPPoE connection bounces, the DHCPv6 client should immediately re-do its request and when it receives a different prefix than before it should declare the old one stale and use the new one to populate the address pool, which should trigger an address reassignment on all interfaces that use that pool.Years ago I found rfc4192. Sometimes I also saw 2 active prefixes at the same time on "German routers". But there is no documentation about how this should work. The dhcpv6 client only gives me 1 prefix. Run 2 dhcpv6 clients? On the other hand, the pppoe connection is simply terminated...
13:46:46 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:47 dhcp,error address received from the server differs from 2001:db8:aa::/56
13:46:47 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:48 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:50 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:51 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:52 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:53 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:54 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:55 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:56 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:57 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:57 system,info IPv6 address changed
13:46:58 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:5c5f:3a8c:7402:429f->2001:db8::1, len 40
13:46:58 system,info radvd prefix changed
13:46:58 script,info test2: expired prefix: 2001:db8:aa:2::/64
13:46:59 script,info test2: new prefix: 2001:db8:bb:2::/64
13:46:59 system,info IPv6 address changed
13:47:00 system,info radvd prefix changed
13:47:00 script,info test2: expired prefix: 2001:db8:aa:2::/64
13:47:03 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:aa:2:4805:f1c1:a903:b393->2001:db8::1, len 40
13:47:08 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:bb:2:4805:f1c1:a903:b393->2001:db8::1, len 40
13:47:09 firewall,info prerouting: in:test2 out:(unknown 0), src-mac 00:0c:29:07:cc:58, proto ICMP (type 128, code 0), 2001:db8:bb:2:4805:f1c1:a903:b393->2001:db8::1, len 40
Schnittstelle 4: Ethernet 6
Adresstyp DAD-Status Gültigkeit Bevorzugt Adresse
--------- ----------- ---------- ---------- ------------------------
Öffentlich Verworfen 1h54m29s 0s 2003:d1:9704:2700:2c48:43a5:51ff:d554
Temporär Verworfen 1h54m29s 0s 2003:d1:9704:2700:3906:12c9:3b86:6b22
Öffentlich Bevorzugt 1h59m48s 29m46s 2003:d1:9733:7900:2c48:43a5:51ff:d554
Temporär Bevorzugt 1h59m48s 29m46s 2003:d1:9733:7900:3906:12c9:3b86:6b22
Öffentlich Verworfen 1h59m45s 0s 2003:d1:9738:7900:2c48:43a5:51ff:d554
Temporär Verworfen 1h59m45s 0s 2003:d1:9738:7900:3906:12c9:3b86:6b22
Öffentlich Verworfen 1h59m48s 0s fd00::2c48:33a5:51ff:d554
Temporär Verworfen 1h59m48s 0s fd00::3906:52c9:3b86:6b22
Andere Bevorzugt infinite infinite fe80::2c48:53a5:51ff:d554%4
... changing from DSL-from-the-CO to DSL-from-the-curb ...
Yes that can be done, but usually it is only done by smaller ISPs who use only a single central PPPoE server where all customers on all line types come together.
It could work relatively well if done properly. Mainly there shouldn't be hard cutoff. So router would get prefix A, with maximum lifetime reflecting planned rollover. Then it would get new prefix B few hours in advance, before expiration of prefix A. Prefix A's preferred lifetime would be lowered to zero, but both would still work. New connections would use address from prefix B, while old ones would have chance to finish with prefix A. If there were at least few hours of overlap, it would be enough for mosts.
:global dhcpv6rafix
:set dhcpv6rafix ($dhcpv6rafix + 1)
:local invalid6prefixes [/ipv6 nd prefix print as-value where prefix in $"pd-prefix"]
:global ra6gettemp do={
:return [/ipv6 nd prefix find where !dynamic and interface=($1->"interface") and prefix=($1->"prefix") and preferred-lifetime~"^0s\$" and valid-lifetime~"^0s\$"]
}
:global ra6removetemp do={
:global ra6gettemp
:foreach x in=$1 do={
/ipv6 nd prefix remove [$ra6gettemp $x]
}
}
:local ra6invalidate do={
:global ra6removetemp
:if ([:len $1] < 1) do={
:return 0
}
[$ra6removetemp $1]
:delay 1
:foreach x in=$1 do={
:do { /ipv6 nd prefix add interface=($x->"interface") prefix=($x->"prefix") preferred-lifetime=0 valid-lifetime=0 } on-error={ }
}
}
:local checkstucktempra do={
:global ra6gettemp
:global ra6removetemp
:local foundstuck 0
:foreach x in=$2 do={
:if ([:len [$ra6gettemp $x]] > 0) do={
:set foundstuck 1
}
}
:if ($foundstuck != 0) do={
:delay 10
:local pooladdrs [/ipv6 address find where address in $1 and from-pool~".+"]
[$ra6removetemp $2]
/ipv6 address disable $pooladdrs
/ipv6 address enable $pooladdrs
}
}
:if (![:tobool [:tonum ($"pd-valid")]]) do={
:delay 2
:for i from=0 to=2 do={
[$ra6invalidate $invalid6prefixes]
:delay 1
}
} else={
[$checkstucktempra $"pd-prefix" $invalid6prefixes]
}
:if ($dhcpv6rafix < 2) do={
:set ra6removetemp
:set ra6gettemp
:set dhcpv6rafix
} else={
:set dhcpv6rafix ($dhcpv6rafix - 1)
}
Thank you SO much for developing and testing this!Inspired by previous postings here, I have taken a swing at implementing RFC6204/RFC7084/RFC9096 via scripting. But this time, in such a way that you can still use v6 prefix pools.
`I don't have anything set under the DHCPv6 client section.
`Once it reconnects, while the clients get the new /64 prefix from the ISP connection, it still sticks to the previous ones, effectively rendering the IPv6 part unusable.
`Not really, at least not in my scenario. Also, instead of doing something about it, "they" are busy selling me a bug as a feature
`I think MikroTik fixed it on 7.8?
`The solution, but still doesn't solve dynamic crap:
https://datatracker.ietf.org/doc/html/rfc8978
LTE does not use DHCPv6 for communicating v6 address assignments. It essentially uses RAs and SLAAC. So it would do you no good to try to set up a DHCPv6 client.
The script I wrote that does a "poor man's" implementation of RFC 9096 for the DHCPv6 client depends on a feature within the ROS DHCPv6 client that fires off a script in the event something changes with regard to the status of the DHCP lease.
About the best advice I can give you is that you will probably have to take the same basic principles, but come up with a script that fires off at some interval of your choosing (using /system/scheduler) in order to check to see if any address change has happened since the last time it checked.
By "it" do you mean the hosts on the networks ("clients") or the router itself? I assume you mean the hosts?
While I find the current situation with MikroTik and many facets of their IPv6 implementation frustrating as well, let's at least be honest about words and semantics.
What you are experiencing is not a bug, nor a feature. It is rather a distinct LACK of a feature.
It's just that the part they left out in their description is that there is a standard way of communicating the deprecation of old addresses to hosts on the network: [...]
There is no "bug" for MikroTik to fix.
Yes "accept-router-advertisements" exists under /ipv6/settings, but it is so horribly broken and useless!]
`There is also tons of philosophy around
`That I interpret as "someone else provided the poison and Mikrotik so far hasn't come up with an antidote yet".What you are experiencing is not a bug, nor a feature. It is rather a distinct LACK of a feature.
`[...] given that many ISPs apparently couldn't care less and implement questionable network behaviours [...]
`And what prevents Mikrotik to just implement this feature?
`However, certainly not a bug as MikroTik does everything right here as well, no?Yes "accept-router-advertisements" exists under /ipv6/settings, but it is so horribly broken and useless!]
In any software team, there is always more work than can be done with the available staff.Well I don't work for them, so...don't know, ask them? My best guess is that they simply haven't gotten to it yet. But I would happily join you in urging them to consider making it more of a priority than it (clearly) has been to-date.And what prevents Mikrotik to just implement this feature?
Do you have some eye defects? I clearly linked to the change log from MikroTik regarding V7.8.And what in the release notes so far leads you to believe that?
RFC6204 doesn't say jack squat about crappy dynamic prefixes. But RFC8978 does, please try to keep up.Please try to keep up. RFC 6204 was published 12 years ago. Many consumer platforms' IPv6 stacks already implement it on the client side. MikroTik just needs to implement it in their router software.
`Do you have some eye defects?And what in the release notes so far leads you to believe that?
`I clearly linked to the change log from MikroTik regarding V7.8.
*) ipv6 - added "pref64" option configuration for RA;
*) ipv6 - limited "hop-limit" parameter value range to 255;
*) ipv6 - made distributed DNS lifetime RFC8106 compliant;
`RFC6204 doesn't say jack squat about crappy dynamic prefixes.
`But RFC8978 does
First of all thanks for @Sob for taking the first (published) swing here at the changing ipv6 prefix and for you @NathanA for creating a robust version of it which implements RFC6204/RFC7084/RFC9096 as it did not peaked anyone interest to provide a solution before, although @IPANetEngineer did provide the command for NAT66.I just edited my previous reply with my DHCPv6 client script in order to replace it with an updated version.
NPTv6 sample rules by @Sob
Code: Select all/ipv6 firewall mangle add chain=postrouting action=snpt src-address=fd00:1234:5678:9a00::/56 src-prefix=fd00:1234:5678:9a00::/56 dst-prefix=publ:icpr:efix:b700::/56 add chain=prerouting action=dnpt dst-address=publ:icpr:efix:b700::/56 src-prefix=publ:icpr:efix:b700::/56 dst-prefix=fd00:1234:5678:9a00::/56
NAT sample config by @IPANetEngineer
Code: Select all/ipv6 firewall nat add action=masquerade chain=srcnat dst-address=2000::/3 src-address=\ 200:c01d:c01a:beef::7ac0/128 to-address=2603:XXXX:XXXX:XXXX::2/128
You cannot subnet a /64. Ask your provider for more space (a /60 or a /56 or a /48).By the way does anyone know how to subnet in case the ISP only provides a /64 address (for the router) and a /64 prefix (for the network behind the router)?
This request is just as successful as asking the state to lower the standard VAT rate...You cannot subnet a /64. Ask your provider for more space (a /60 or a /56 or a /48).
I rarely use the world impossible, however in this case I do: no amount of tinkering with DHCPv6 client configuration (prefix-hint and pool-prefix-length parameters) results in different prefix in case the T&C specifies /64 (and more often than not ISPs are not that bad at implementing T&C in case it is advantageous for them).It could be you already GET more space but have not yet understood how to activate it (with proper DHCPv6 client configuration)...
It's fixed, via hack. But still it doesn't resolve the issue with DNS host names. You need complex DDNS setup for running applications at home.Apparently the original topic discussed here (changing prefix does not result in deleting old prefix at clients) has been fixed in version 7.9beta.
So it could be a good idea for those affected by that to test this version.
What hack are we talking about?It's fixed, via hack.Apparently the original topic discussed here (changing prefix does not result in deleting old prefix at clients) has been fixed in version 7.9beta.
So it could be a good idea for those affected by that to test this version.