In a typical configuration where you receive a prefix via a DHCPv6 client and then use it to create a subnet for SLAAC clients, you do something like this:
Assuming you got the 2001:DB8::/60 delegated prefix, the line above will add the 2001:DB8::1/64 address to the to-clients interface.
But this seems to be wrong!
Per RFC8415:
For each delegated prefix, the client assigns a subnet to each of the links to which the associated interfaces are attached.
When a client subnets a delegated prefix, it must assign additional bits to the prefix to generate unique, longer prefixes.
In other words the assigned address should be 2001:DB8::000X:0:0:0:1/64 where X is a value from 1 to F but not 0. It appears that RouterOS, contrary to the standard recognizes 2001:DB8::/64 as a valid subnet from 2001:DB8::/60.
That being said, I don’t understand why was it necessary to require that additional bits must be added for subnetting.
Additional bits … to the acquired prefix length. In the example above prefix length is 60, so subnetting can be done using prefix lengths larger than 60, 64 is a perfect choice.
Bits can have values 0 and 1, both are equally valid.
Hence prefix 2001:DB8::/60 is not the same as 2001:DB8::/64 …
I’m likely misreading it, but the rfc examples do alter prefix by adding bits before subnetting (extending the prefix):
2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and
2001:db8:0:2::/64 for assignment to the two links in the
subscriber network. If the client were delegated 2001:db8:0::/48
and 2001:db8:5::/48, it might assign 2001:db8:0:1::/64 and
2001:db8:5:1::/64 to one of the links, and 2001:db8:0:2::/64 and
2001:db8:5:2::/64 for assignment to the other link.
The way I understand that RFC is that 2001:DB8:0:0::/64 is a valid IPv6 prefix. I really don’t get your idea that added bits have to be non-zero (a bit of a stretch, but that way 2001:DB8:0:2::/64 would not be a proper prefix because the least significant bit would be 0 and how do we know it belongs to the prefix or not? So perhaps it’s a 2001:DB8:0:2::/63?).
Yeah, it does serve the purpose of example to show non-zero LSB not to confuse people with too many zeroes …
I don’t get it either, but I don’t keep all the possible IPv6 configurations in my mind. It very well may serve some purpose. In the example, after extending prefix length they also altered the extension. Perhaps it’s implied in a reference implementation that it may store a prefix-length-less address somewhere and this relationship between delegated prefix and it subnets can be established via this alterations?
2001:db8:0::/48, it might generate 2001:db8:0:1::/64 and 2001:db8:0:2::/64 for assignment to the two links in the subscriber network.
If the client were delegated 2001:db8:0::/48 and 2001:db8:5::/48, it might assign 2001:db8:0:1::/64 and 2001:db8:5:1::/64 to one of the links, and 2001:db8:0:2::/64 and 2001:db8:5:2::/64 for assignment to the other link.
In a related vein, for the host part of the address, unlike in IPv4 where all 0’s (this network), and all 1’s (broadcast address), in IPv6, all 0’s in the host part of the address is not overloaded with any special meaning and is a valid address. Likewise, all 1’s in the host part is not overloaded with the special meaning of the broadcast address, and is a valid address with no special meaning.
