IPv6 address assignment unstable on 7.21.1

RouterOS General
1

Since an upgrade to 7.21.1 (from 7.20.6), IPv6 address assignment has become unstable.

I have a /48 assignment (xxxx:yyyy:zzz::/48), and I have manually assigned /64 addresses to applicable interfaces.

Thus xxxx:yyyy:zzz:0::1/64 to my bridge, xxxx:yyyy:zzz:1::1/64 to VLAN 100 , plus two other VLANs with incremental IPs. Some EUI64 enabled, some don’t (I’m just using shortened values here for sanity, plus it would have worked either way).

This was all fully functional in 7.20.6 and below without any hassle. On upgrade to 7.21.1, the manually assigned IP on the bridge interface become unstable. It would suddenly change which /64 was assigned to the interface. So it suddenly changed from xxxx:yyyy:zzz::1/64 to xxxx:yyyy:zzz:4::1/64.

At the same time, it would break other IPv6 access for traffic on this interface. Client devices appeared to be picking up new IPs from the xxxx:yyyy:zzz:4::/64 subnet via SLAAC, but I was unable to access some IPv6 services. There was nothing I could locate that implied access control blocks, but I didn’t get to the bottom of it**.**

Attempts to update the IP back to xxxx:yyyy:zzz::/64 on the interface would resulting in the subnet being incremented, i.e. the first try would make it xxxx:yyyy:zzz:5::1/64, then next try xxxx:yyyy:zzz:6::/64 and so on. I had to disable RA, delete the address, then manually assign xxxx:yyyy:zzz::1/64 again, enable RA and it would work.

But it would only work for a temporary period - unknow how long.

A reboot seemed to trigger it, but I’m not sure it was every reboot. That I could not be certain on.

As it was causing connectivity issues and thus productivity, I downgraded back to 7.20.6 and all is well again, without any problems.

Not really after advice, but was wondering if others have seen stability issues?

2

Due to changes in how to "fix" particular /64 prefix (taken out of /48 prefixes) is set to a particular interface, it's now not possible to set "zero-th" prefix to a particular interface.

E.g. it's OK to set address=::1:0:0:1/64 from-pool= or address=::ff:aa:bb:cc/64 from-pool= ... but not address=::0:0:0:1 from-pool= ... because this is first squashed into "::1" and that's then interpreted as "any prefix". ... Which can change with any configuration change on router (because pool will return different prefixes every time it's pooled).

There's ongoing discussion about this problem (among others) in release topic for 7.21.

2 Likes
3

Many thanks,

That does put the sudden assignment stability aspect into perspective.

Now, I could just go an re-allocate the prefixes allocated to existing interfaces, and proceed to update again. However, I am nervous about the issues I had with accessing IPv6 services when the incorrect assignment was present, especially when I didn’t get to the bottom of it.

I only ask this next part as it seems some are already versed on this (whilst I go lookup said thread and no doubt get lost in it).

Is there an immediate reason why this automatic re-prefixing would prevent access?

Having downgraded, I don’t have access to any data now that would tell me the state of the system, such as routes in place, so I get it’s catch-22 on trying to properly answer this blind.

I’d just rather at least be prepared as possible for any update, by either knowing the problem is prevented, or what I am gathering in the event of a problem before I would need to roll back.