donate.wikimedia.org currently does not have an IPv6 address.
I'm not sure if there's anything that prevents IPv6 from being enabled on donate; if so, could we have it detailed in this task?
Adding IPv6 to donate would make no positive functional difference to actual donations as a) the vast majority of clients is dual-stacked), b) payments/frack is still IPv4-only.
As for "why": all of production is currently IPv6-enabled for the past 3 years now and this is an exception to it. Global IPv6 traffic is currently almost at 7% and rising quickly. There are also potential performance problems from having donate as IPv4-only, as this breaks SPDY/HTTP2 coalescing with the main site; resources from donatewiki are sometimes included in the main projects (e.g. the recent mobile app banner) and this would be slower to load, potentially worsening the experience for IPv6-enabled users.
Just spoke with K4-713 about this: donate.wm.o geolocates clients who are following non-banner links (e.g. email campaign links). Early on the ipv6 geocoding data was spotty so we were concerned that we'd have too many ipv6 users being kicked into the payment process as though they're in the wrong country. We don't expect this to be a big issue now, and there's no objection. However, we should alert Caitlin C when the change goes into effect so she can be on the lookout for a significant increase in users complaining about payment geography.
I'm planning on sending a big email blast to Belgium and Luxembourg on Monday at 9am UTC, and I'm thinking those small countries may be ripe for geolocation issues in this case. We don't usually force country in our email links - do you think I should for this blast until we can say for sure this doesn't cause too many problems?
(btw, the relevant TTLs are 600s, so you may not see the full effect for at least 10 minutes. Maybe longer for some clients, if they have bugger resolver caches that hold outdated records longer than they should).