If GitHub flipped a switch and enabled IPv6 it would instantly break many of their customers who have configured IP based access controls [1]. If the customer's network supports IPv6, the traffic would switch, and if they haven't added their IPv6 addresses to the policy ... boom everything breaks.
This is a tricky problem; providers don't have an easy way to correlate addresses or update policies pro-actively. And customers hate it when things suddenly break no matter how well you go about it.
For every customer which has access controls configured based on IPv4 (sounds crazy enough already), GitHub would configure a trivial DENY ALL policy for IPv6. Problem solved.
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.)
Some food for thought:
https://news.ycombinator.com/item?id=47790889I don't get it.
For every customer which has access controls configured based on IPv4 (sounds crazy enough already), GitHub would configure a trivial DENY ALL policy for IPv6. Problem solved.
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.)
Now they can use Claude Code.