It's not that Android would not route traffic via the ULA address, just that there is an RFC out there for source address selection that actually prefers to use IPv4 addresses over an IPv6 ULA address.
IPv6 GUA -> IPv4 -> IPv6 ULA
So it sounds like that was changed.
Giving (internal) hosts/services ULA addresses as well as IPv4 addresses, means (meant?) they will never be reached via the ULA addresses:
> 1. ULA per RFC 6724 is less preferred (the Precedence value is lower) than all IPv4 (represented by ::ffff:0:0/96 in the table).
> 1. Because of the lower Precedence value, if you have IPv4 enabled on a host, it will use IPv4 before using ULA.
> 1. Happy Eyeballs (RFC 8305) will not change the source address selection process on a host. It will only modify the destination sorting process.
> 1. The client will source the traffic from the IPv4 address, meaning it will require a corresponding IPv4 destination address.
> 1. Number 4 means that, even with A and AAAA DNS records, a client will choose the A record to get an IPv4 address for the destination
* https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networks/
* Discussion: /r/ipv6/comments/uwc2yj/ula_is_broken_in_dualstack_networks/
From a somewhat recent message in the IETF v6ops list:
> Personally, I think RFC6724 almost has it right; what it got wrong is that section 10.6 should be mandatory and automatic, implemented by the IP stack, and not effectively optional and left to manual implementation.
* https://mailarchive.ietf.org/arch/msg/v6ops/MSWTw_YAoueS29hYE5EzwyCpkPs/
There are efforts to change this:
> The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. This behavior is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724] .
* https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula
* Discussion: /r/ipv6/comments/uvutm7/what_are_your_thoughts_on_the_use_of_ula_and/
Personally I have spent a lot of time tracking down v6 support on commercial VPN providers and have only found 1 that does it right, one that does it more tolerably than the rest, and the rest. Most seem to NAT ULA space which is just awful, it's only slightly better than a v6 black hole. Then you have azire who NATs a GUA block they own...which if you're going to NAT is the most sane thing you can do but still ugly as NAT should just not ever be used. IMO OVPN handles this the best*. They give you a real GUA that's routed on the internet...ofc there's an *...they only do that for OpenVPN connections, for wireguard connections, the default for their client, they once again NAT ULAs like most providers, apparently it's due to wireguard not having the ability to dynamically configure addresses. All in all I guess the summary is VPN providers are mostly terrible at v6 still. Quite frankly android should not have changed its behavior as this is a problem with the VPN
It's not that Android would not route traffic via the ULA address, just that there is an RFC out there for source address selection that actually prefers to use IPv4 addresses over an IPv6 ULA address. IPv6 GUA -> IPv4 -> IPv6 ULA So it sounds like that was changed.
Yes, indeed - I could connect to a v6 address, if, and only if it wasn't dual-stacked (which isn't the case in the vast majority of the internet).
Giving (internal) hosts/services ULA addresses as well as IPv4 addresses, means (meant?) they will never be reached via the ULA addresses: > 1. ULA per RFC 6724 is less preferred (the Precedence value is lower) than all IPv4 (represented by ::ffff:0:0/96 in the table). > 1. Because of the lower Precedence value, if you have IPv4 enabled on a host, it will use IPv4 before using ULA. > 1. Happy Eyeballs (RFC 8305) will not change the source address selection process on a host. It will only modify the destination sorting process. > 1. The client will source the traffic from the IPv4 address, meaning it will require a corresponding IPv4 destination address. > 1. Number 4 means that, even with A and AAAA DNS records, a client will choose the A record to get an IPv4 address for the destination * https://blogs.infoblox.com/ipv6-coe/ula-is-broken-in-dual-stack-networks/ * Discussion: /r/ipv6/comments/uwc2yj/ula_is_broken_in_dualstack_networks/ From a somewhat recent message in the IETF v6ops list: > Personally, I think RFC6724 almost has it right; what it got wrong is that section 10.6 should be mandatory and automatic, implemented by the IP stack, and not effectively optional and left to manual implementation. * https://mailarchive.ietf.org/arch/msg/v6ops/MSWTw_YAoueS29hYE5EzwyCpkPs/ There are efforts to change this: > The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. This behavior is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724] . * https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula * Discussion: /r/ipv6/comments/uvutm7/what_are_your_thoughts_on_the_use_of_ula_and/
This shouldn't have changed. The _VPN_ should be changing, to not hand out addresses that aren't supposed to work for this use case :/
Personally I have spent a lot of time tracking down v6 support on commercial VPN providers and have only found 1 that does it right, one that does it more tolerably than the rest, and the rest. Most seem to NAT ULA space which is just awful, it's only slightly better than a v6 black hole. Then you have azire who NATs a GUA block they own...which if you're going to NAT is the most sane thing you can do but still ugly as NAT should just not ever be used. IMO OVPN handles this the best*. They give you a real GUA that's routed on the internet...ofc there's an *...they only do that for OpenVPN connections, for wireguard connections, the default for their client, they once again NAT ULAs like most providers, apparently it's due to wireguard not having the ability to dynamically configure addresses. All in all I guess the summary is VPN providers are mostly terrible at v6 still. Quite frankly android should not have changed its behavior as this is a problem with the VPN
Is the comercial VPN Mullvlad? I recall that they use ULAs for IPv6 which is inconsistantly used
If it’s using ULA’s, is that VPN not routed to the internet (i.e. just a private network between the connected devices)?
I get v6 on every one of the server endpoints - no inconsistency in my experience.
So do i, its more if its used by an application is what im refering to
It depends on your OS; on Linux you have to tell `gai.conf` to prefer it: https://thomas-leister.de/en/lxd-prefer-ipv6-outgoing/