Some days ago I again experienced some ipv6-troubles with my network. This time, the router rearranged the prefixes it hands out, so my servers again became unavailable over ipv6.
My ISP gave me a /56 prefix. My system has three networks, the prefixes were xx:1900::/64, my main network, xx:1901::/64 and xx::1902::/64, two less important vlans.
After changing the mtu of my ipv6-network the router decided to change the prefix of the main network to xx::1903::/64, after reverting the mtu, it changed the prefix to xx::1904::/64. So my servers became unavailable over ipv6. That was more than two weeks ago.
Now, for some reason, the router decided to rearrange the prefixes. Now the lesser important networks got xx:1900::/64 and xx::1901::/64. The main network got xx::1902::/64. Again my servers became unavailable over ipv6.
Anyone having similar experiences with ipv6 ?
Can I tell the router which prefixes it should hand out ? Of course based on the prefixes the ISP gives.
Here a7 is the subnet-id (8 available bits with a /56 prefix) that you can hardcode in the address entry. With a /60 pool then of course you can only choose 4 bits.
What is dynamic ? I’m with the same isp for years. Only when I changed from vdsl to fiber I got a new prefix. And that’s probable because I changed routers, from fritzbox to mikrotik.
I understand that my prefix could change, but it didn’t. Nevertheless, the router shuffled the “internal” prefixes.
Does it work also if prefix falls into "upper part" of the /56 ? E.g. not fd5e:6379:994a:0000::/56 but fd5e:6379:994a:5900::/56 ? It used to work for the former case already in ROS v6 ... but not for the later case. The problem was that ROS took the prefix from pool as a whole (including the 00 from part 5900 which is not part of /56 prefix) and the "subnet id" as well ... and couldn't combine them intelligently (i.e. to 59a7). With "bottom part" (all zeroes) it successfully formed e.g. 00a7 ...
When rrported, they claimed it wasn't bug report but rather feature request ... so I wonder if they finally came around to do/fix it.
You mentioned rOS v 7.21 should address the problem. Well, it seems not.
Now I’m on rOS 7.21.2 and I’m experiencing the problem again. I don’t know why but a few days ago the router changed the prefix of one VLAN. x:x:x:1900::/64 changed to x:x:x:1903::/64. Before I defined the address as ::1/64 for my three VLAN’s, in the order I wished the prefixes to be. Now I expicitly changed the problematic address to x:x:x:1900:0:0:0:1/64. Was OK for a few days but today it changed again to x:x:x:1903:0:0:0:1/64.
Now I tried to define the address the way you described. It seems not to work. Tried some times, this is the last try :
\[admin@router-vlans\] /ipv6/address> print where !dynamic
Flags: G - GLOBAL
Columns: ADDRESS, FROM-POOL, INTERFACE, VRF, ADVERTISE, VALID, PREFERRED
# ADDRESS FROM-POOL INTERFACE VRF ADVERTISE VALID PREFERRED
0 G x:x:x:1902::1/64 ipv6-pool1 VLAN80 main yes 3w1d22h48m57s
1 G x:x:x:1901::1/64 ipv6-pool1 VLAN89 main yes 4w1d22h49m13s 6d22h49m13s
2 G x:x:x:1905::1/64 ipv6-pool1 VLAN185 main yes 4w1d22h49m13s 6d22h49m13s
\[admin@router-vlans\] /ipv6/address> add address ::00:0:0:0:1 from-pool=ipv6-pool1 interface=VLAN185
<delete address x:x:x:1905::1/64 via winbox>
\[admin@router-vlans\] /ipv6/address> print where !dynamic
Flags: G - GLOBAL
Columns: ADDRESS, FROM-POOL, INTERFACE, VRF, ADVERTISE, VALID, PREFERRED
# ADDRESS FROM-POOL INTERFACE VRF ADVERTISE VALID PREFERRED
0 G x:x:x:1902::1/64 ipv6-pool1 VLAN80 main yes 3w1d22h48m57s
1 G x:x:x:1901::1/64 ipv6-pool1 VLAN89 main yes 4w1d22h49m13s 6d22h49m13s
2 G x:x:x:1906::1/64 ipv6-pool1 VLAN185 main yes 4w1d22h49m13s 6d22h49m13s
\[admin@router-vlans\] /ipv6/address>
So I reverted to defining the full address, in the hope it will stick.
If only I knew why the prefix changes. Is there something on my network the says "hey, change the prefix" ?
FWIW, I contacted Mikrotik support (before v7.21), the only thing they say : it's always been so.
You can specify the subnet id part since 7.21, no need to specify the full address. However there is one exception, that is the first subnet (the one with subnet id all zeros) cannot be specified that way, that one will be dynamic. You can read about this in the 7.21 threads.
Example: ISP gives you /56 prefix, that you put in isp-pool, under /ipv6 address, you can assign hardcoded prefixes like this, together with from-pool=isp-pool:
address=::1:xxxx:yyyy:zzzz:www
address=::2:xxxx:yyyy:zzzz:www
...
address=::10:xxxx:yyyy:zzzz:www
address=::11:xxxx:yyyy:zzzz:www
...
address=::fe:xxxx:yyyy:zzzz:www
address=::ff:xxxx:yyyy:zzzz:www
And they all apply correctly and the interfaces will have fix assigned address & prefix from the pool. Except for this:
address=::00:xxxx:yyyy:zzzz:www, which is identical to address=::xxxx:yyyy:zzzz:www
That entry with subnet-id 0 (00 in case of /56, 0 in case of /60, 0000 in case of /48) will always be dynamic, and the prefix will jump to the next available subnet-id every time the DHCPv6 binding renews, or every time you make change to the interface. If you want your interface to have predictable & fixed subnet-id you should make sure the interface does not have the subnet zero assigned!
If you have a preferred order for your interfaces, that will mean you'll have to shift all your assignments once. If the order is not important, then you only have to edit the interface that currently has the subnet-id once to give it a higher subnet-id.
