cf166ed3b4
The old fd00:168:0::/48 base was never actually generated via RFC 4193's randomization procedure -- just a memorable placeholder chosen to visibly pair with the IPv4 10.168.x.x scheme. Replaced with fdf0:f243:f06f::/48, a real randomly-generated ULA prefix. That /48 consumes all three "identity" hextets a ULA prefix has room for, leaving only the subnet-id (4th) hextet -- the same one the per-network auto-allocation index already lived in -- with nowhere left to also place a fixed "168" marker without colliding with either the random prefix or the index itself. Per the user's own choice (offered two options): the per-network index is now offset by a constant 168 instead of matching IPv4's index number-for-number, so the first auto-allocated network's IPv6 block is fdf0:f243:f06f:168::/64 (paired with 10.168.0.0/24), second is ...:169::/64 (paired with 10.168.1.0/24), and so on -- deterministic and still visibly project-stamped, just via a constant offset instead of an identical digit. network_subnet.cpp's new ipv6_ula_prefix48/ipv6_subnet_id_base constants hold the new prefix and offset. Verified as root via the doas rule: two freshly created extern networks got fdf0:f243:f06f:168::/64 and fdf0:f243:f06f:169::/64 exactly as expected, correctly paired with their IPv4 subnets. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Gv3s5jckJKzh6JkMoi2Akz