It simply does not make sense to set ULA automatically. ULA fc00::/7 is subdivided in fc00::/8 and fd00::/8. The former would use some global registry while the second one uses a random 40-bit subnet prefix (to avoid conflicts). You would need to share this 40-bit random value with every node in order to have a common /48 prefix. Besides that, It would not make sense to have a full /48 for a single VPN network. It should be subdivided into common /64 appending another 16-bit subnet id. So, in the end, you would need a way to pass the ULA prefix (40-bit + 16-bit). ULA should be configured just like any other global address.
If ULA is not the topic, we might need to change the thread name. The issue here is really about having Link Local Address automatically set. I know that Wireguard wants to be as clean as possible not including any automatic setup logic. However, most protocols that would do that job, at least, expect LL to be present (DHCPv6). LL is set by the kernel for ethernet devices but not for TUN interfaces, probably because there is simply no "link" on a L3 interface. There is, for example, a request to have it set for OpenVPN (https://community.openvpn.net/openvpn/ticket/415). I would expect IPv6 LL address to be present in any default scenario. I just don't know what would be the one to set it up. For ethernet devices, it is the kernel itself. For wireguard, there is a shared responsibility between userland (wg and wg-quick) and kernel. However, as a required feature, I would not depend on any software that is not required. If wg-quick is optional, it would not be the place to set the LL address. Maybe wg would be the one to set it as soon as a IPv6 stack is up for a wireguard interface, even when there is no intention to use IPv6. However, if wg is also "optional", it would be nice if the kernel API could require the userland code to inform the interface-id (or set a link local address) before IPv6 is up. For wireguard, LL address setup also means to set allowed IPs automatically. Regarding what interface id should be used, even random value is acceptable but not ideal for management as it could be used as part of device ID. Wireguard could use a simple algorithm to map pubkey 256-bit into a 64-bit value, just like ethernet 48-bit is mapped to a 64-bit value. It can be as simple as getting the last 64-bit from pubkey or any already in use form of hash. Keep it as simple as possible. It is not expected to be secret. The privacy extension, if used, is for automatically generated global addresses, not link-local one. Keep in mind that LL is not expected to be a replacement for any global address (ULA or Internet one). They should still be set. At least for Linux, no "normal" process would really use LL addresses without specifying the outgoing interface ("fe80::...%interface"), which might limit what you can do with it. In summary, my suggestions: 1) LL address should be set automatically by wg, better if required by kernel interface or even set up by kernel module. 2) interface identification can be derived from pubkey with a simple algorithm. It does not need to be a secure hash. Regards, --- Luiz Angelo Daros de Luca [email protected]
