Here's my post for the Team ARIN blog:
Many organizations have expressed skepticism about deploying IPv6.
But they need to understand that the issue is not how much IPv4 address
space they have, but how much is available for global distribution. As
IPv4 exhausts around the world over time, a new generation of web users
possessing only IPv6 addresses will materialize and grow substantially.
But when will this new generation of Internet users appear in
numbers? Many service providers are masking an indeterminate number of
these users due to the necessity of providing them access to both IPv6
and IPv4 web content. This makes it difficult to gauge IPv6 client
requests on a global scale, but you can actually measure this, albeit
coarsely, on your own web presence. Let’s see how.
Presumably, service providers with IPv6-addressed subscribers will
attempt to connect using native IPv6 end-to-end if possible, but drop
back to using an IPv4-IPv6 co-existence technology such as tunneling or
translation should the subscriber’s intended destination be reachable
only via IPv4. The means to determine this reachability is initially
done via the domain name system (DNS).
An IPv6-addressed device will attempt to resolve a user-selected URL
to an IPv6 address by issuing a DNS query for the AAAA resource record
type for the URL The service provider’s caching DNS server, to which the
subscriber device directs this query, will attempt to locate the DNS
server on the Internet that is authoritative for the corresponding
domain, then query the server for the AAAA record. Should the query
resolve successfully, the result is returned to the subscriber device
and it will attempt a native IPv6 connection. If unsuccessful, the
caching server may issue a similar DNS query for the A resource record
type to determine if the destination is configured with an IPv4 address.
If the subscriber device has only an IPv6 address, configuring the
caching DNS server as a DNS64 server provides a standardized method to
translate the returned A record query result into an IPv6 address. When
this synthesized IPv6 address is returned to the subscriber device in
the form of a synthesized AAAA query response, the device will attempt
to establish connectivity via a service provider NAT64 gateway, which
interconnects the service provider IPv6 network with the IPv4 Internet.
If the subscriber device is dual stacked, with both an IPv6 and an
IPv4 address, it should issue both the AAAA and A queries itself, then
apply its address selection policy table to determine which source and
destination addresses to use. The default policy table implemented by
most common operating systems today does favor IPv6 in the event of
results returned from the AAAA query. If the AAAA query fails to return
results, the device will attempt to initiate the connection via IPv4.
The bottom line is that IPv6 end users may be attempting to connect
to your website using IPv6. The best way to determine this is by
analyzing your DNS query logs. Review your query logs for AAAA query
rates over time to identify increases in AAAA queries. As mentioned,
this metric is rather coarse, as caching DNS or DNS64 servers will
cache responses received from other DNS servers, but it can serve as a
useful indicator of IPv6 connection attempts to your website.