@MikroTik, Does RouterOS v7 support specifying a static “IPv6 Prefix ID” on per-interface basis?
Just rebooting my MikroTik router is a frustration. Due to every IPv6 enabled Local Area Network Interface changing the assigned /64 Subnet.
To clarify, my provider assigns a reasonbly static /48 v6 prefix via DHCPv6. Which rarely changes.
On the Local Area Network side. It feels like /64’s are assigned randomly…?
Whenever I create a new L2 domain (subint). The next in line /64 is then assigned to the new L2 domain.
And whenever I upgrade to latest stable in the v7 release branch. (Or for other reasons reboot the router). I observe the L2 domains (“segments”) very often get a new /64 compared to the prior one before reboot.
From other router platforms (e.g. pfSense). I have observed they implement a “IPv6 Prefix ID” to ensure the sub-delegated /64 on the Local Area Network side from the SP-delegated /48 block uses the same “ID” (the 4th group in the v6 prefix, 2000:db8:0456:<4th>:). Even if the delegated /48 prefix from SP changes.
My question is: Does RouterOS v7 (as of 7.10.2) have any configuration knob to ensure the same “ID” is used to sub-delegate /64’s from SP-delegated /48? (I.e. the 4th group does not change)
Are you talking about DHCPv6 server handing out Prefix Delegation downstream or from-pool address assignments for SLAAC? The former has static bindings, also the clients can hint what they want. As for the latter, it does appear to be sequential in no particular order and there doesn’t seem to be a way to specify custom subnet identifier.
My main issue/trouble with how the Prefix ID assignment is done. Is that I reboot the router (software upgrade). I cannot count on the Prefix (i.e. the /64 sub-delegated [by the ROS router] out of SP delegated /48) being stable. Meaning I experience a changing /64 Prefix. Which is quite annying. When the Local Area Network side IPv6 DNS server needs to be hardcoded by it’s IPv6 address. → Resulting in me needing to go around a handful of lxc container, 4 MikroTik devices, to update the previous IPv6 DNS address. It is not the providers fault. As the delegated IPv6 /48 stays stable for many months at a time.
(The issue is mostly prevalent for interfaces having been created since last reboot. That is most expected to be Prefix renumbered with a new /64 after reboot)
Cutout of the IPv6 configuration. Estimated to contain the most vital parts.
Second MikroTik supports static /64, assuming your PD is static, I’m using static /64s from the PD pool as we speak, nothing changes on reboot. You’re clearly doing it wrong.
I do not know about prefix delegation by RouterOs’s DHCPv6 Server, but from-pool address assignments do get shuffled and optimized whenever DHCPv6 client renews.
Consider adding 3 addresses, then remove the 2nd one and finally renew. You will see RouterOS changing subnetID of the 3rd address to be immediately after the 1st
Nope, even when the router REBOOTS, which I don’t think you understand it means DHCPv6 client renews, whenever the PD is static from upstream, irrelevant if it’s Cisco, Juniper, Huawei or MikroTik, the subnet-ID aka a specific ::1/64 on VLAN1, ::2/64 on VLAN2, ::3/64 on VLAN3 NEVER changes. You’re doing it wrong if it does.
@DarkNate this can happen. Lets say you get a /60 from your isp from a dhcp client and put it in a pool of /64s. You assign 3 /64 prefixes from a pool to different vlan interfaces. Even if you reboot, the pool assignments are not stored on disk and not saved to disk. These are resident in memory, so a reboot could shuffle the assignments around.
If you know a way to resolve this (which Mikrotik support has not been able to address in the past) then please share.
In my previous communication with support I suggested the addition of a preferred prefix option that could be used/updated for use on reboots.
Note how subnet ID changed from 2 and 4 to 2 and 3.
With respect to the VLAN filtering, are you talking about the loopback interface? I don’t have that switch to verify, but there are posts on this forum that suggest that a port-less loopback interface does not interfere with the offloading. Ability to have a loopback interface is crucial e.g. when you use a link-local backbone network. If this indeed the case that this bridge interface breaks offloading, Mikrotik appears to suggest to have an EoIP tunnel instead.
When setting ipv6 address (from pool), one can set N16 least significant bits of address where 128-N16 has to be equal to or more than size of prefix in pool. In case of @nravnen: pool prefix size is 48, meaning that it’s possible to set up to 5x16 bits. If one sets less (@nravnen example shows 4x16 bits), the ROS chooses the missing bits in some pseudo-random fashion (number of bits chosen by ROS of course depends on prefix size used in address, which should most of time be 64). The problem for most users is that ISPs tend to hand out prefixes larger than 48 bits (e.g. 56 or 60), but ROS insists on Nx16 bits grouping (I was complaining about it years ago, arguing that this is a bug, but MT replied that fine-grain handling of prefix+suffix handling would be feature request).
So in case of @nravnen, it should be possible to set IPv6 address like this:
My example appears to satisfy this condition. That RouterOS properly interpreted can be seen in the output. However, it found presence of bits set within pool’s prefix-length problematic.
You appear to suggest that one may influence target prefix length via the address property, but that’s not true. It will be ignored and pool’s prefix length will be taken instead.
And that’s the problem because the user has no influence over the RRRR subnet ID. Moreover, RouterOS can change it.
Now the ::x/64 assigned to any VLAN, will NEVER change even if you reboot the router, as long as the DHCPv6-client receives the same PD from the ISP, forever. Why tf do you need scripting/hacks for such basic functionality that RouterOS v6/v7 already supports?
MikroTik will autopopulate the network prefix/site prefix segment of the address, whereas subnet ID X will remain static. Since IPv6 subnetting is hierarchical, the ::1, 2 etc will never change.
We identify the VLAN based on the subnet ID X.
I’m using this method from last 6 years and rebooted my MikroTik at least 9000 times, never changed.
My comment was for dynamic allocations from an ISP. @DarkNate I can see that your config will work for a static allocation, but not for a dynamic one. I am using Comcast, so not a small ISP by any means.
If RouterOS did at all what you claim, that would produce a bad configuration, because all addresses you set on different interfaces would end up in the same subnet. You set the interface identifier (the last 64 bits) to 1, 2 and 3 respectively. But the the bits in the place of the subnet id are 0 for all three, so combined with the /48 prefix id, you’d get the same subnet on all three interfaces, if RouterOS actually took the subnet id from that address specification. In reality, it won’t even let you set those bits in that address to anything but 0. The subnet id is chosen by RouterOS and not guaranteed to stay the same. Just disable an interface and reenable it: new subnet. The problem is exactly like the top comment describes it. What happens for you is that RouterOS chooses the subnet ids in the same way every time since the interfaces never change on your system. So it appears as if RouterOS remembers the subnet ids, but it actually doesn’t. It’s just “luck” that they always end up the same due to your rather static network setup.
