IPv6 RA: unsolicited multicasts, address deprecation, and multiple interface routes

[dvv]

I've installed VPN Client Pro on my Android phone primarily for its tap support, and things work basically fine, except for a couple-three things, which I'm seeing on my bridged tap connection:

1. Client doesn't seem to listen to unsolicited RA multicasts from the router on the remote LAN and because of that, it misses network address changes on the remote LAN.
2. Client doesn't seem to deprecate and discard auto-configured addresses, missing the opportunity to update its interface address again.
3. Client seems to only install the interface route it receives with the autoconfig RA (plus the /1 routes), ignoring extra non-autoconfig routes that are announced in the RAs. Not a biggie — our remote LAN router can handle that — but it'd be nice to have the other prefixes routed directly via the interface.

Are my observations correct? If yes, is there a chance to have the issues fixed ASAP (especially №1 and №2)?

Thanks!

[admin]

Hello,
thank you for the suggestions.
Unfortunately Android does not allow you to change the configuration of the VPN interface without closing and reopening it.
This implies that once the VPN is established it is not possible to add and/or remove addresses and routes.

[dvv]

How bad is closing and re-opening the interface to change the address? The old address (its prefix, in fact) is no good anymore, anyway.

[admin]

Closing and reopening the VPN interface resets all open connections. Probably for most users this is not acceptable.
Normally the old addresses are kept and marked as deprecated to avoid resetting connections

[dvv]

The problem is my upstream provider disregards DHCP6 renew requests and changes the delegated prefixes sometimes as often as once an hour. Once there's a new prefix, the old one is useless for any and all external connections. The local radvd in my configuration is made aware of the change immediately and starts informing local clients (VPN included) about the new prefix with multicasts. Linux, Windows, Android connected directly to the LAN take immediate notice and start using the new prefix, Linux and Windows boxes on tap'd VPN do that, too. Having the same VPN behavior in Android would be great.

Connections with deprecated prefixes only continue to work properly inside the LAN, but all external connections are dead the moment the delegated (PD'd) prefix is changed.

[admin]

I'll try to find some solution, but I can't assure you anything

[dvv]

Understandable. Thank you!

[admin]

I sent you PM with a test version...

[admin]

The problem can be solved using the new option "Process IPv6 RA updates" present in the new release 1.01.35

[dvv]

Thank you again!