How many IPv6 eyeballs are you missing?
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.
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.
Comments
Post a Comment