Please consider allowing server-ipv6 without adding implicit route

[Zugschlus]

Hi,
OpenVPN in tun mode normally puts an IP address with the appropriate netmask on the Interface. This leads to long connection timeouts when trying to connect to a non-connected client. I would like my notebook to be reachable when it's at home (and doesn't have the VPN tunnel up) and when it's on the road (when the VPN tunnel is up). I therefore have two AAAA records in DNS that point to the VPN and to the home-LAN address of my notebook. To allow that to happen with out having to wait for timeouts, I'd like my OpenVPN server to quickly issue a host unreachable when the tunnel is down.
With IPv4 that seeems to be reasonably easy. "server 10.8.0.0 255.255.255.0" is documented to translate to a number of other directives including ifconfig. So I can just replace my server statement with

mode server
tls-server
push "topology subnet"
ifconfig-pool 10.8.0.2 10.8.0.253 255.255.255.0
push "route-gateway 10.8.0.1"

and establish a client-connect script that sets a host route to $ifconfig_pool_remote_ip and removes it on client-disconnect. Some other contortions are needed to have a gateway IP on that interface, but it looks like having 10.8.0.1 and 10.8.0.2 on lo makes things work.
That doesn't seem to be as easy with IPv6. First, service-ipv6 is not as clearly documented to translate to a number of other directives, and the server doesnt seem to come up with just

ifconfig-ipv6-pool 2001:db8:0:bc02::/64
push "tun-ipv6"

Some kind of ifconfig-ipv6 statement is very obviously needed, and to make things worse, OpenVPN seems to insist on at least a /124 network configured on the Interface. Since my IPv6 OpenVPN transfer network luckily only has the OpenVPN server in the lowest /124 of my /64 transfer network, I could add

ifconfig-ipv6 2001:db8:0:bc02::1/124 2001:db8:0:bc02::1

and it works. But that surely feels like a bad hack, and I fear that this might stop working some time in the future.

Please consider removing the requirement to formally have an ifconfig-ipv6 statement on a IPv6-enabled OpenVPN server just to make the config validator happy. There are valid usecases to not want that.

Thanks for your consideration.

Greetings
Marc

[cron2]

Short answer, due to time constraints.

The /124 minimum is my doing, as I find this a reasonable mininum subnet size (and IPv6 ifconfig never deals in point-to-point, only subnets).

I think it really should work to have ifconfig-ipv6 ... /124 and then an ifconfig-ipv6-pool from a non-overlapping part of the overall /64. I'd expect it to trigger a few warnings about out-of-ifconfig-subnet assignment (if at all), but this is one of the "do what I say!" things... but I'd need to test it.

For static client assignments, using ccd/ files with ifconfig-ipv6-push will definitely work with out-of-subnet IPs (you'll need to use a /124 - which can be a per-client /124 or one for multiple clients). This was a bit tricky to implement with DCO (because system routing needs to be added/removed for client connects/disconnects) but Arne did this in f938d99 (in 2.7.0) - for non-DCO setups it needs help from --client-connect or --learn-address scripts.

Acknowledging the documentation bug that does not specify what --server-ipv6 expands to.