Comment by bvanheu
11 hours ago
that's the scenario they want to prevent. they can't force the client to use ipv4, if they connect via ipv6, they will be served an accss denied.
11 hours ago
that's the scenario they want to prevent. they can't force the client to use ipv4, if they connect via ipv6, they will be served an accss denied.
Yes, exactly as they would now, when the access over IPv6 is entirely unavailable.
With that, the customers who don't use filtering by IPv4 would be able to use IPv6. Those who do use access control by IPv4 ranges would have time to sort out their IPv6 setup, without having anything broken at the moment when IPv6 is enabled.
No, if you have a dual-homed stack right now, and they only expose IPv4, you connect over IPv4, you don't attempt to connect over IPv6 and get connection denied.
That's rather the problem - there's no trivial way to mimic that policy transparently while enabling IPv6, because most stacks will default to using IPv6 if they're dual-homed and expose both, and won't fall back if IPv6 connects but gives an error. (Offhand, I think the best you could do would be to tell everyone that you're migrating to a new URI scheme to allow cloning, with IPv6 enabled, and that as part of that, you'll have to update your allow/deny rules, then, after a truly astonishingly long time and lots of nagging of anyone who never does it, make the old path an alias of the new one and let the last remaining people break.)
I suppose that customers who set up access controls based on IPv4 address ranges must be running an UPv4-first stack, most likely IPv4-only.