I found a strange error in the log, related to DHCPv6. As i remember saw it also in older firmwares:
assigned prefix len: 64 is bigger than configured: 64 using:72
Now mathematically this is an incorrect statement since they are equal. And the assigned /64 pool has in fact prefix length /64 - as given by the providers DHCP server.
A similar logic error is also there if i try to add a pool of /64 with prefix length 64:
Couldn't add New IPv6 Pool - prefix length must be bigger than prefix.
Here an equality should also be acceptable.
Use case for first issue:
I get a /64 address delegation from my provider via DHCPv6 and want to add it to a dynamic pool (here first error occurs - this actually should be a warning since the usage of /72 solves this from functional point of view - but it’s still wrong)
I want to assign those addresses to my network via RA and just forward it to my upstream provider. But i have only a /72 subnet and RA needs a /64 (this is solved by declaring a interface address from the pool with mask /64 but still just a workaround)
Use case for second issue:
Got a /48 assignement from my provider and want to set up multiple /64 address pools for subnets and use /64 address pools to use for RA. This means prefix /64 and prefix length /64 - which is not possible because of the second issue.
You get this error because delegated prefix should be larger than /64 if you want to give out /64 prefixes from that received prefix. You can’t get /64 prefixes from /64 pool.
First of all i don’t want to give out /64 prefixes from it. I just need to RA it on an internal interface.
I would say that situation is legit and functional for a 1 WAN/1LAN setup, and no bigger prefix is needed as long as that prefix is delegated to one single interface.
And to receive a prefix bigger than /64 is “best practice”. It SHOULD be but it MUST not be. It is not the case of my provider which gives out 1 single /64 prefix (and is sadly probably not the only one).
So if i assign that prefix to a pool and RA it on an internal interface and just forward IPv6 traffic from internal to external (gateway being the interface name) everything is in order and working. I don’t need a assigned IP on the external interface. Just pass-trough so that IPv6 traffic will emerge from the external MAC, nothing else.
So
is not a correct statement. You can get 1 /64 prefix from 1 /64 pool and use it. Nothing speaks against it.
IMHO prefix /64 == prefix length /64 seems correct and should be acceptable. Generally, prefix == prefix length should be acceptable.
Note that taking in account that it works even if the pool gets restricted to /72 and than used to assign an IP of /64 out of the pool to the internal interface and RA a /64 prefix from that pool - with stripped 8 bits of course - really works. Just to make about 1.8*10^19 addresses unusable because of “best practices”.
Restricting the usage of the pool concept without real technical reasons does not bring anything useful to no one except error messages in a log.
As far as I understand it they only intend you to use the DHCPv6 server to serve prefix delegations, so they expect you to have a pool of them to hand out.
RA is implemented since ages. Prefix delegation works since 5.11 as i remember.
And everyone tries to find excuses for putting “<” instead of “<=” in the code (even the error message is correct, but not the check).
A prefix is valid with a length equal to the prefix. This is what you get from your DHCPv6 server. And this is what every ISP hands out. A prefix which you can fully use, to the last IP in that prefix. And that means prefix equal length, not less.
And it is about DHCPv6 CLIENTS with PD, not about DHCPv6 servers.
You get a prefix from the server via DHCP. Its length equals the prefix (e.g. /64) and you have to create a dynamic pool to use that prefix (e.g. delegate is further). In this case you get an error in the log stating that the length is bigger than the prefix (which is not true, it is not bigger, it is EQUAL and not an error. The prefix length can not be bigger than the prefix, but it can be EQUAL or LESS).
I can not test prefixes other than /64 from my ISP, but this probably happens on any prefix length since prefix will be equal to prefix length when acquired by the DHCP client. (What would be the use e.g. to delegate a prefix of /48 and a length of /64 so you get only one /64 piece of it? Just to say you have /48?)
Everyone assumes I want to delegate prefixes or run a DHCP server from a pool.
No. I just want to assign the prefix to one internal interface and one single internal network so that individual computers can do autoconf via RA. Which i think is the ultimate goal of prefix delegation - to get an IP from the DHCP assigned to each computer in the network (and the simplest way is RA). And since DHCP allows a prefix to change, static assignment is not an option. So i need a dynamic pool populated by the DHCP client from which to advertise the prefix and here i get the error in the error log, error which is not a legitimate one.
IT WORKS nicely except those errors in the log during dynamic pool creation.
If this would hurt in any form other functionalities, keep the restriction on creating static pools (pref > len) and allow it only for dynamic pools (which would be sufficient for simple DHCPv6 clients & PD).
At the moment i can not imagine a situation in which prefix==length would do something wrong, but your developers know better.
If address is set to something like ::1/64, if the pool is populated, it will get the proper IP automatically, using prefix from pool | (or) address as defined. In my case, prefix is 2a02:2f02:1022:b08b::/64 from DHCP assigned to pool, so resulting address is 2a02:2f02:1022:b08b::1 and the associated /64 prefix is advertized on the LAN.
Assignment to local machines in the LAN is done via RA, and addresses are generated automatically using prefix + suffix derived from mac address.
