@markd @becomingwisest @jschauma #Akamai has made #IPv6 dualstack the default for around a decade for new customer configurations. I talk some about why customers don't dual-stack (and why they should!) in https://www.akamai.com/blog/trends/10-years-since-world-ipv6-launch
Many customer sites have been on long enough to pre-date the switch of the default, but we do still see some rate of opting out. Some top reasons include:
* Operationally conservative and lack of understanding of the value ("if it isn't broke don't fix it" or "seems safer"), or have trouble justifying the effort to make the change safely with testing.
* Lack of support in their log processing and/or header processing and/or advanced business logic for IP handling. For example, companies may be using a third-party anti-fraud product which doesn't support IPv6. With Akamai's large base of Enterprise customers this is frustratingly common and the "just hash the IPv6 to an IPv4" makes things worse rather than helping.
* Auth tokens bound to IP addresses. (eg, setting it via IPv4 and validating via IPv6 fails, or vice-versa -- see https://www.akamai.com/blog/developers/why-you-shouldn-t-tie-ip-addresses-to-tokens )
* Custom or uncommon clients which break in the presence of IPv6. This is rare but I've seen it, for example some local streaming provider may have a user base with old Smart TVs that interact poorly with some ISP's somewhat broken IPv6 setup. I hear this less now, but it used to be common even a few years ago.
Note that it's worth checking both the "www" and apex name version of some of these, as in some cases the apex example.com name is IPv4-only but redirects to a dualstack "www" name due to CNAME-at-the-apex limitations.
