upvote
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.
reply
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.

reply
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.)

reply
deleted
reply