It seems like a good idea to allocate IPv6 address from a pool, given my ISP is handing me a (static) /48 via DHCP prefix delegation. Historically I couldn't do this, because the subnet-id would change, but the 7.22 feature of allowing you to specify the subnet-id gives the option of keeping the subnet-id and the 64 bits of the local address fixed, while the first 48 bits come from the delegated prefix.
So this:
[igb@brsklink.batten.eu.org] > /ipv6/address/print where from-pool=brsk-pool-1
Flags: G - GLOBAL
Columns: ADDRESS, FROM-POOL, INTERFACE, VRF, ADVERTISE, VALID, PREFERRED
# ADDRESS FROM-POOL INTERFACE VRF ADVERTISE VALID PREFERRED
11 G 2a10:d582:6a4c:a90b::4:50/64 brsk-pool-1 WiredGuest0011 main yes
12 G 2a10:d582:6a4c:a909::4:50/64 brsk-pool-1 WirelessGuest0009 main yes
13 G 2a10:d582:6a4c:7::4:50/64 brsk-pool-1 Redzone5 main yes
14 G 2a10:d582:6a4c:4::4:50/64 brsk-pool-1 OldDefaultNetwork main yes
15 G 2a10:d582:6a4c:3748::1/64 brsk-pool-1 wireguard1 main yes 5h47m49s 5h47m49s
[igb@brsklink.batten.eu.org] >
The part I don't understand is the VALID and PREFERRED columns, which counted down from 24 hours. I screen-shotted it earlier, and then all of them still had times against them:
But if you already know about that, and only wonder why you see those two values next to the /ipv6 address assignment in RouterOS then:
Before RouterOS 7.21, when you add /ipv6 address entries and enable the Advertise flag, the router will send out Router Advertisement (RA) messages with the assigned prefix. The Valid Lifetime and Preferred Lifetime sent with those advertisements are values coming from these global default settings:
The IPv6 address pools now can have their own pair of lifetime parameters, that will automatically count down.
If you create /ipv6 address entries from pools, and with Advertise turned on, and the pool has their own lifetime parameters, then the address entries will use those lifetime values (which are live and counting down) whenever the router sends out RA messages for those entries, instead of using the values from the global default.
If the pool has no lifetime parameters, then the RA messages sent will use the lifetime values from the global settings mentioned above.
The Valid Lifetime and Preferred Lifetime (introduced with 7.21) of a pool cannot be set if you manually create a pool with hardcoded prefix!
If instead that pool was populated by a DHCPv6 client instance requesting prefix from upstream, then the lifetime values come from the DHCPv6 response to the prefix request. You'll see that the valid lifetime is usually equal to the value seen in the Prefix Expires After column in the DHCPv6 Clients table. The preferred lifetime might be the same or shorter, depending on the DHCPv6 server.
The ability to create sub-pool from a parent pool is a new feature introduced by RouterOS 7.22:
Now about this issue:
This appears to be a bug right now. From my observations, when you first create the /ipv6 address entry, or after a router reboot, the values displayed in the VALID and PREFERRED columns by /ipv6 address print will match the values of the referenced pool. However, when the DHCPv6 client renew its lease (normally after half of the lease time has elapsed) then the displayed numbers by /ipv6 address print are no longer kept in sync and will disappear when elapsed.
BUT this is only a display issue. The Router Advertisement (RA) messages sent by the router still have the correct Valid Lifetime and Preferred Lifetime value coming from the pool, and those values are normally reset each time the DHCPv6 client obtains a new lease. On the client operating systems you can use the commands mentioned at the end of the article linked at the top of my post, and see that the lifetimes values usually match what's left in the relevant IPv6 pool.
EDIT: Here is a screenshot for the out-of-sync situation: The DHCPv6 server sends a Valid Lifetime of 2 hours. After half of that elapsed (after 1 hour) the DHCPv6 client request a renewal of the lease and the Lifetime resets back to 2 hours. The screenshots show (from top to bottom) the DHCPv6 lease, the associated IPv6 pool lifetime, and the /ipv6 address print output:
As you can see, the /ipv6 address print shows lifetimes that are 1 hour shorter, because the renewal happened 1 hour after the original lease assignment.
I knew about the valid and preferred times for addresses in general, I was puzzled why they were only being shown for those interfaces.
You're right: it's presumably a display issue. Some days after I made the changes, I now see that although the SLAAC-obtained address to my ISP shows a valid and preferred timer, the addresses which came from the DHCPv6-PD delegation don't:
igb@pi-one:~$ ip -6 addr show eth0
# ...
valid_lft 65594sec preferred_lft 65594sec
igb@pi-one:~$ echo '18*3600+13*60+21' | bc -l
65601
igb@pi-one:~$
So it all looks good, apart from the cosmetics. The addresses are being advertised with lifetimes which trace back to the DHCP-PD allocation that created the pool from which the addresses are drawn. It's just that you can't (at least via CLI or webfig) reliably see them on the interfaces themselves. The CLI displays them until they time out, webfig doesn't display them at all.
Thanks for your detailed reply. I was worried that either the router itself or the IPv6 devices behind it would see their IPv6 addresses timing out.
