[admin@router] > /ipv6/export
# RouterOS 7.10.2
/ipv6 dhcp-server option sets
add name=ip6-dns options=dns-server-1
/ipv6 address
add address=::4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1
add address=::4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3996
add address=::4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3994
add address=::4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3993
add address=::4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3992
/ipv6 dhcp-server
add address-pool=delegation dhcp-option=ip6-dns interface=bridge1 lease-time=1h name=server1 rapid-commit=no
add address-pool=delegation dhcp-option=ip6-dns interface=bridge1.3996 lease-time=1h name=server2 rapid-commit=no
/ipv6 nd
set [ find default=yes ] dns=****:****:****:4004::53 hop-limit=32 interface=bridge1 managed-address-configuration=yes mtu=1500 ra-interval=20s-1m ra-lifetime=50m \
ra-preference=high reachable-time=33m20s retransmit-interval=4m
add dns=****:****:****:4004::53 hop-limit=32 interface=bridge1.3996 managed-address-configuration=yes mtu=1500 ra-interval=20s-1m ra-lifetime=50m ra-preference=high \
reachable-time=33m20s retransmit-interval=4m
add dns=****:****:****:4004::53 hop-limit=32 interface=bridge1.3994 managed-address-configuration=yes mtu=1500 ra-interval=20s-1m ra-lifetime=50m ra-preference=high \
reachable-time=33m20s retransmit-interval=4m
add dns=****:****:****:4004::53 hop-limit=32 interface=bridge1.3993 managed-address-configuration=yes mtu=1500 ra-interval=20s-1m ra-lifetime=50m ra-preference=high \
reachable-time=33m20s retransmit-interval=4m
add dns=****:****:****:4004::53 hop-limit=32 interface=bridge1.3992 managed-address-configuration=yes mtu=1500 ra-interval=20s-1m ra-lifetime=50m ra-preference=high \
reachable-time=33m20s retransmit-interval=4m
/ipv6 nd prefix default
set preferred-lifetime=30m valid-lifetime=1d
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.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
I suggest you try following the steps above to see for yourself that RouterOS will re-shuffle to fill the gap (due to removed 2nd subnet).You're doing it wrong if it does.
> :put [/ipv6/pool/print detail where name=global]
Flags: D - dynamic
0 D id=98 name="global" prefix=2001:db8:0:6540::/60 prefix-length=64 expires-after=1h32m
> /ipv6/address
> add from-pool=global interface=vlan-iot eui-64=yes
> add from-pool=global interface=vlan-work eui-64=yes
> add from-pool=global interface=vlan-tv eui-64=yes
> print detail where from-pool=global
12 G address=2001:db8:0:6542:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-iot actual-interface=vlan-iot eui-64=yes advertise=yes no-dad=no
13 G address=2001:db8:0:6543:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-work actual-interface=vlan-work eui-64=yes advertise=yes no-dad=no
14 G address=2001:db8:0:6544:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-tv actual-interface=vlan-tv eui-64=yes advertise=yes no-dad=no
> remove 13
> print detail from-pool=global
12 G address=2001:db8:0:6542:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-iot actual-interface=vlan-iot eui-64=yes advertise=yes no-dad=no
13 G address=2001:db8:0:6544:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-tv actual-interface=vlan-tv eui-64=yes advertise=yes no-dad=no
> /ipv6/dhcp-client/set numbers=0 script=":put hello"
> print detail from-pool=global
12 G address=2001:db8:0:6542:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-iot actual-interface=vlan-iot eui-64=yes advertise=yes no-dad=no
13 G address=2001:db8:0:6543:aaaa:bbbb:cccc:dddd/64 from-pool=global interface=vlan-tv actual-interface=vlan-tv eui-64=yes advertise=yes no-dad=no
/ipv6 address
add address=::1:4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1
add address=::3996:4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3996
add address=::3994:4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3994
add address=::3993:4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3993
add address=::3992:4e5e:cff:febc:**** eui-64=yes from-pool=delegation interface=bridge1.3992
> /ipv6/address
> add address=0:0:0:000e::1 interface=vlan-iot advertise=no from-pool=global
> print detail where from-pool=global
12 IG ;;; address pool error: bad preferred prefix! (1)
address=::e:0:0:0:1/64 from-pool=global interface=vlan-iot actual-interface=vlan-iot eui-64=no advertise=no no-dad=no
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.Address has to start with:: as ROS will only replace leading zeroes with bits from prefix.
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.address: ::xxxx:yyyy:wwww:zzzz:tttt/64
And that's the problem because the user has no influence over the RRRR subnet ID. Moreover, RouterOS can change it.and address: ::1/64 gives final address aaaa:bbbb:cccc:RRRR:0:0:0:1/64 where RRRR is pseudo randomly set by ROS.
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.add from-pool=global address=::1/64 interface=vlan-iot eui-64=no advertise=yes
add from-pool=global address=::2/64 interface=vlan-work eui-64=no advertise=yes
add from-pool=global address=::3/64 interface=vlan-tv eui-64=no advertise=yes
Ah that's typo lol, I edited the comment.If RouterOS did at all what you claim, that would produce a bad configuration
What are you asking lol, if the PD is dynamic, then it will always change. How's this a RouterOS problem? Ask Comcast to read this: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.
Ah that's typo lol, I edited the comment.
That's worse.add from-pool=global address=::1/64 interface=vlan-iot eui-64=no advertise=yes
add from-pool=global address=:0:1::1/64 interface=vlan-work eui-64=no advertise=yes
add from-pool=global address=:0:2::1/64 interface=vlan-tv eui-64=no advertise=yes
The delegated prefix usually doesn't change, so the addresses could stay the same if RouterOS allowed one to set the subnet id. You claim it does, but it clearly does not, as anyone can try for themselves. The fundamental problem with this deficiency is that the firewall is ill-equipped to deal with the potentially changing subnet id.What are you asking lol, if the PD is dynamic, then it will always change. How's this a RouterOS problem?
My example appears to satisfy this condition.Address has to start with:: as ROS will only replace leading zeroes with bits from prefix.
/ipv6/address
> add address=0:0:0:000e::1 interface=vlan-iot advertise=no from-pool=global
Perhaps it was like this previously, but at least since 7.9.2 it doesn't seem to be this way:While address written in such assignment does look like IPv6 address (and one might expect parser to treat it as such), the parser does some magic combining it with prefix (from pool) and it doesn't seem to be very inteligent at it.
> :put (0:0:0:000e::1 = ::e:0:0:0:1)
true
> :put [:typeof 0:0:0:000e::1]
ip6
> add address=::e:0:0:0:1 interface=vlan-iot advertise=no from-pool=global
> print detail
12 IG ;;; address pool error: bad preferred prefix! (1)
address=::e:0:0:0:1/64 from-pool=global interface=vlan-iot actual-interface=vlan-iot eui-64=no advertise=no no-dad=no
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.address: ::xxxx:yyyy:wwww:zzzz:tttt/64
They do not always change. My prefix allocations are pretty constant.What are you asking lol, if the PD is dynamic, then it will always change. How's this a RouterOS problem? Ask Comcast to read this: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.
https://www.ripe.net/publications/docs/ ... persistent
Doesn't seem to work anymore:The outcome was: if pool had prefix with length of /48 and was set to use /64 prefixes, then I could set 5x16 bits on address and it would result with valid IPv6 address on interface
> /ipv6/pool/add name=test prefix=2001:db8::/48 prefix-length=64
> /ipv6/address/add address=::e:0:0:0:1 interface=vlan-iot advertise=no from-pool=test
> print detail where from-pool=test
;;; address pool error: bad preferred prefix! (1)
Flags: X - disabled, I - invalid, D - dynamic; G - global, L - link-local
12 IG ;;; address pool error: bad preferred prefix! (1)
address=::e:0:0:0:1/64 from-pool=test interface=vlan-iot actual-interface=vlan-iot eui-64=no advertise=no no-dad=no
> /ipv6/address
> add address=0:0:0:0:1:: from-pool=test interface=vlan-iot
> add address=::2:0:0:0 from-pool=test interface=vlan-iot
> /print detail
12 G address=2001:db8:0:0:1::/64 from-pool=test interface=vlan-iot actual-interface=vlan-iot eui-64=no advertise=yes no-dad=no
13 G address=2001:db8:0:1:2::/64 from-pool=test interface=vlan-iot actual-interface=vlan-iot eui-64=no advertise=yes no-dad=no
It does not appear to me as a parser issue though. In fact current behavior of RouterOS seems logical: pool's address-prefix and prefix-length of allocations specified under /ipv6/pool covers Global ID and Subnet ID parts of the IPv6 address, while /ipv6/address covers the Interface ID part. It seems to be designed this way because the same pool can be used by both /ipv6/address and /ipv6/dhcp-server and they wanted to keep the implementation simple.Your experinents show that parser now works differently than it worked in v6. Is it better or not is yet to be seen.
Exactly. TheWhat I'd want is to remove prefix-length from /ipv6/pool and instead allow both /ipv6/address and /ipv6/dhcp-server to control it alongside Subnet ID. Although that'd require sophisticated conflict tracking.
i+1