IPv6 Vs IPv4 for geolocation

After configuration of Nginx to listen on IPv6, website loads properly but for the users with IPv6, the geolocation fails (we use Maxmind free database), they are then all Geolocated in USA.

Make sure you are using the correct database. Some geoip offerings have seperate databases for IPv4 and IPv6 (AIUI with maxmind the legacy products are split into seperate v4 and v6 while the geoip2 products cover both in one database).

What really happens when an IPv6 client queries my website? If he has an IPv4 too, then it defeats the purpose of having IPv6.

There are different types of client to consider.

1. IPv4 only clients, that can only use IPv4 and will fail to access your site if it is v6 only.
2. True IPv6 only clients. These will not be able to access your site if it is IPv4 only. Such clients are currently extremely rare.
3. Traditional dual-stack clients with both IPv4 and IPv6. The IPv4 is likely to be natted at the premisis boundry and increasingly likely to be natted by the ISP as well.
4. IPv6 only clients using an ISP based DS-Lite gateway to access the IPv4 Internet.
5. IPv6 only clients using an ISP based NAT64/DNS64 gateway to access the IPv4 Internet.

Cases 1 and 2 are pretty obvious.

With cases 3 and 4 the client will likely try both IPv4 and IPv6. In general if it finds both it will try IPv6 first.

With case 5 the client will use your IPv6 address if a record exists. If you do not offer an IPv6 address it will use an IPv6 address synthesized by the NAT64/DNS64 gateway. The NAT64 will then translate the IPv6 traffic from the client to IPv4 traffic to send to you.

(which was because we were running out of IPv4)?

The original idea was that we would move from v4 only to dual-stack. Then once everyone was on dual-stack we could start turning off IPv4. The hope was that this would happen before IPv4 addresses ran out.

That didn't happen for many reasons including ivory tower standards that ignored the reality of the Internet and the simple fact that it was hard to build a buisness case for IPv6 when noone else was doing it.

So now we are in the sad position that IPv4 addresses have essentially run out but large parts of the internet are still IPv4 only.

ISPs are therefore forced to do something to enable continued growth in a post-depletion world with many IPv4-only services. They basically have three options.

1. Traditional NAT at the ISP level (often reffered to as "carrier grade NAT"). This may or may not be accompanied by rolling out IPv6 dual-stack.
2. DS-Lite. In this system IPv4 packets are encapsulated (generally by the CPE) and tunneled to a special NAT at the ISP. This NAT has extended mapping tables which identify not just the internal IP and port but also which IPv6 address the tunneled traffic came from.
3. NAT64/DNS64. In this system the ISPs DNS64 server synthisizes AAAA records for hostnames that don't have any pointing those records at the NAT64 box. The NAT64 server than translates the clients IPv6 traffic to IPv4 traffic.

All of these options ultimately come down to implementing mechanisms to allow IPv4 addresses to be shared among multiple customers.

Is the geolocation based on that IPv4 reliable?

Geolocation is always dependent on the accuracy of the geolocation data. As IPv4 addresses get more scarce they are likely to be moved around more reducing the accuracy of geolocation.

Furthermore with IP sharing mechanisms users in different locations may be behind the same IP. There is nothing a geolocation database can do about that.

Is there any drawback of not being IPv6 ready?

Beyond geolocation questions there are three main considerations here.

1. Performance and reliability. All of the mechanisms available to ISPs to share IPv4 addresses among multiple users are likely to reduce performance and reliability. How much they reduce them depends on how competant the ISP is at deploying them.
2. Abuse control. If all you have is shared IPv4 addresses then it makes it much harder to keep track of abusers to either ban them or report them to their ISPs.
3. The long term future. Right now there is still sufficient v4-only content that ISPs are forced to offer mechanisms for their users to access v4-only content. There could come a point though where the amount of v4 only content drops low enough that ISPs no longer consider it worthwhile to keep those mechanisms going.

If country-level granularity is sufficient for you, then you can simply rely on whois. Don't query whois for every single client IP address you see. When you do see a new IP and query whois, then cache the range such that future requests for IP addresses in that range do not touch whois. If you get no response from whois, then don't try to use whois for the same /32 for the next 24 hours.

If you need more fine-grained granularity, or if caching of data from whois is more complicated than what you want to implement, then you need to find a provider who can give you access to such data for IPv6. You do not have to use the same provider for IPv4 and IPv6.

For clients with both IPv4 and IPv6, you can build your own data about correspondence between addresses. How this can be done has been answered before.

If both client and server has dual stack support, then it is the client which decides whether IPv4 or IPv6 is used. Since 2010 it has been considered best practice that clients attempt to use the fastest or most reliable of the two.

There are clients with more reliable IPv6 connectivity than IPv4 connectivity. If your site only supports IPv4 those clients will experience your site as being unreliable. The fraction of users for which this is the case will keep growing.