[netifd] Failed to assign requested subprefix of size 64

{"kernel":"5.4.50","hostname":"OpenWrt","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13692-556eb9872d","target":"mvebu/cortexa9","description":"OpenWrt SNAPSHOT r13692-556eb9872d"}}


My assumption is that it correlates with option ip6assign '64' and applies only to GUA (and not ULA), is that correct?

ISP provides a /56 GUA prefix but I do not understand why the netifd routine https://git.openwrt.org/?p=project/netifd.git;a=blob;f=interface-ip.c;hb=51e9fb8151e8f2c16ac1400bf4d64147ee7e8f5a#l1131 is actually printing these warnings:

netifd: Failed to assign requested subprefix of size 64 for guest, trying other
netifd: Failed to assign requested subprefix of size 64 for lan, trying other
netifd: Failed to assign requested subprefix of size 64 for mgt, trying other

?

Because it cannot carve out a suitable /64 prefix out of your PD pool. Could be due to fragmentation, unsuitable ip6hint values etc.

Check ifstatus wan6 (or ifstatus wan_6), ifstatus lan etc. to see which prefixes get assigned where.

the cause seems to be (oddly)

option ip6hint '9a9b'

That works for the ULA (global /48 prefix) but does not for GUA, in this case iftstatus lan:

"ipv6-prefix-assignment": [
                {
                        "address": "xxx:4540:6b28:2101::",
                        "mask": 64,
                        "preferred": 85881,
                        "valid": 85881,
                        "local-address": {
                                "address": "xxx:4540:6b28:2101:2037:442c:f8fc:55f0",
                                "mask": 64
                        }
                },
                {
                        "address": "fd30:d64c:1eed:9a9b::",
                        "mask": 64,
                        "local-address": {
                                "address": "fd30:d64c:1eed:9a9b:6b26:935f:6451:5ef6",
                                "mask": 64
                        }
                }

Unless I miscalculated, a /56 prefix allows for 256 x /64 prefixes, so from ...:X::/64 till ...:(X+100)::/64 (hexadecimal).

It might be that ...:9a9b::/64 is well out of range of your /56 PD pool, depending on the pool base address.

1 Like

Well, there is the intricacy of sub-netting a /56 prefix which is doable but the issue is that the ISP rolls over the /56 PD pool either every 24 hrs since last dial-in or on every dial-in, whichever happens first. Basically there is no stable pool base to calculate from...

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.