Determining where you are using IPv6
Human nature makes us curious to know where we are located within the World Wide Web. We are also curious about where within the global Internet the person we are communicating is connected. We could use this information to make security decisions to allow or block connections. When it comes to geolocation, accuracy is paramount, and Internet-connected device location can vary between IPv4 and IPv6. In this article, we explore Internet geolocation using IPv6, available tools, and discuss the technical challenges.
How Geolocation Works
Geolocation is the process of accurately determining the physical location of an object on the surface of our planet. This can be accomplished by using radio frequency (RF) signals from a mobile operator’s base stations to triangulate a subscriber’s approximate physical location. Today, most mobile phones have built-in GPS receivers but actually perform Assisted GPS (AGPS), which uses other RF information, like Wi-Fi info, to improve location determination when the GPS process alone takes too long or is not available. It is always fun to see your GPS latitude and longitude coordinates using a mobile phone app like GPS Essentials.
Geolocation has its benefits: for example, knowing where you are and preventing you from getting lost as well as for navigation by plotting the fastest course to your destination. Geolocation also helps an application service determine the location of the client and provide customized information. For example, a web browser application could determine your country of origin and display a requested web page in the local language. However, it can be surprising to be presented a web page in an unfamiliar language.
Determining the location of a system on the Internet (without GPS or RF signals) is more complicated. For network-connected devices, their location in this ethereal world is based on their IP address. If the IP address is a private (RFC 1918) address, then there is no way of determining the true physical location of the associated device based on the address alone. If the IP address is a public address, then it might be possible to determine the Regional Internet Registry (RIR), continent, and maybe country if you had additional information from the Internet provider.
Geoblocking and Geofencing
If the physical location of a device and its user can be accurately determined, then based on this information, connections can be permitted or restricted. Geoblocking is the practice of preventing connections from public IP addresses located in specific geographies. This is becoming a more common practice given the nation-state attacks and geopolitical influences on the Internet in recent years. This is also a technique used to restrict gambling to only those countries/states that permit it within their borders. Geoblocking can also be augmented by using the origin device’s time zone to restrict connections. If the location of the device could be accurately ascertained, then geofencing (i.e., establishing a virtual perimeter for a physical geography) could be performed to further permit or restrict connections. An example of this is evident in how Netflix permits or blocks connections based on the subscriber’s country-of-origin based on their source IP address. Netflix also limits subscribers using VPNs to get around their geofencing policies.
Governments, utilities or enterprise organizations may want to block attacks from geographies that aim to do them harm. In recent years, there has been significant geopolitical emphasis on geoblocking practices, especially in the European Union (EU). There are groups who feel that geoblocking opposes the free and open ideals of the Internet and favor bans on the practices of geoblocking. The Internet Society (ISOC) has also opposed commercial and geopolicital practices of content blocking.
These geoblocking capabilities are often built into firewalls, IPSs, load balancers and other perimeter defenses. Global Server Load-Balancing (GSLB) systems, like Infoblox DNS Traffic Control, have the ability to act on GeoIP information. Furthermore, Infoblox’s Secure DNS offering has DNS Firewall capabilities that prevent end-users from communicating with fast-flux botnet command and control (C&C) or domains that have poor reputations from Threat Intelligence Data Exchange (TIDE). DNS Firewall can block DNS queries based on domain name or the source IP address and can perform geoblocking.
Geolocation Challenges
As you can imagine, there are significant problems for geolocation when solely using the source IP address to attempt to accurately determine a device or user’s location. One key problem with determining location for IPv4 systems is caused by NATs changing the source address. This same problem can occur when an enterprise uses a cloud-based web content filter proxy system to help protect their geographically-dispersed workforce. When services providers employ Carrier-Grade NAT (CGN) or Large-Scale NAT (LSN) systems, these make it appear as if the client connection is originating from the NAT pool, which may not be anywhere close to the source/user. Similarly, in the case of DNS-based GSLB, if the location is attempted to be determined using the source IP address of the DNS resolver, the actual client may not be near that particular DNS resolver.
These same problems plague organizations that are attempting to use the client’s IP address as a form of authentication. Because of the inherent weaknesses of using usernames and passwords for authentication, some organizations are desperately seeking other methods to perform multi-factor authentication. But using the client’s source IP address is considered a bad practice and cannot be relied upon as a valid factor of a user’s identity. You can read more about this topic in the March 2013 (Vol 16, #1) issue of The Internet Protocol Journal, “IPv4 and IPv6 Address Authentication” on page 15.
IPv6 Geolocation
The accuracy of using an IP address for geolocation is based on the accuracy of the information about the allocation of IP addresses collected and maintained by RIRs and ISPs. Since IPv4 has been used for so many years, IPv4 geolocation is very accurate but IPv6 geolocation is not yet as precise. IPv6 addresses are assigned by RIRs to ISPs or organizations directly, then ISPs allocate addresses to customers, but all this location information may not necessarily be well-documented. If the IPv6 address is newly allocated and not entered into the geolocation databases, then that could cause problems.
When IPv6 addresses are assigned by IANA and ICANN to one of the five RIRs, it is easy to determine the RIR’s region just based on the IPv6 address prefix. RIRs maintain databases containing information about the organizations that have been allocated addresses and this information is publicly available through their WHOIS interface. For example, you can go to the American Registry for Internet Numbers (ARIN) WHOIS interface to query an IP address or ASN. RIR databases do contain location and address information of the registered organization and they do provide some utilities to access this information. However, RIRs, like RIPE, want to avoid becoming geolocation providers themselves, even as they do provide useful tools for documenting IP address location information.
Internet Routing Registries (IRRs) can also contain address information of organizations who are advertising their IP addresses with EBGP. There are many different IRRs that can be queries with the WHOIS utility.
One of the great things about using IPv6 is that there is no NAT66 function equivalent to NAT44 and the global address you are using is the source address that will be used when making connections. Even though IPv6-to-IPv6 Network Prefix Translation (NPTv6) (RFC 6296) exists, it is not widely deployed by enterprises or small businesses. Therefore, there really isn’t any reason you would need to do a “WhatIsMyIP” when using a global unicast IPv6 address.
IPv6 Geolocation Challenges
Because IPv6 prefix allocations may be newer and the databases are not as well documented as IPv4 addresses, there are examples of how IPv4 geolocation can be more accurate than IPv6. We can do some simple testing to compare the accuracy of IPv4 and IPv6 geolocation.
When I open my browser, and go to whatismyip.com, it correctly shows my global IPv6 address and detects my carrier as Comcast, but the location is listed as Mount Laurel, New Jersey instead of Denver, Colorado. This is a curious inaccuracy because if I copy my IPv6 address and browse to the http://whois.arin.net site and paste the IPv6 address, it correctly shows that my IPv6 address 2601:280:5b7f::/48 is allocated by Comcast to their Denver location. Why does it think I’m located in Mount Laurel, NJ? This location comes from the WHOIS information for Comcast Cable Communications, LLC, and their 2601::/20 IPv6 prefix organization record lists their location as 1800 Bishops Gate Blvd, Mt Laurel, NJ, USA. Therefore, the assumption is that my location is there instead of Denver, CO. This is a problem, because the WHOIS query results for my specific DHCPv6-PD-allocated /64 falls within the IPv6 block (2601:280::/26) that Comcast assigns to their Denver networks. This is an example of a service provider publicly disclosing the general location of an IPv6 address, but the IPv6-capable geolocation system not using all the publicly-available information at its disposal.
When I use RIPEstat geolocation widget (which relies on the MaxMind GeoLite City database) with my global IPv6 address, it thinks I am in Kansas City. However, when I use my public IPv4 address it correctly shows my location as Denver, CO.
When I browse to https://www.iplocation.net/ it uses several geolocation services and when I enter my IPv4 address, it correctly shows my ISP, Country, Region, and City (and my latitude and longitude is only a few miles off!). However, when I enter my IPv6 address, it correctly shows my ISP and my country but IP2location shows my city/region as Mount Laurel New Jersey, ipinfo.io says the region and city are not available, and DB-IP show my Region is Colorado buy my city as Aurora (30 miles away). Therefore, as they say, “your mileage may vary” (YMMV).
IPv6 Geolocation Support
There are now many geolocation software packages and services that support IPv6 addresses.
IP2Location.com published that they were ready for the support of IPv6 back in 2012. IP2Location.com offers IPv6-capable software components (.NET, Java, ISAPI Filter, ActiveX/COM DLL, IP-Country with ISO3166). However, when I go to their site, it accurately shows my state and city (and my latitude and longitude are extremely accurate based on my IPv4 address). However, when I enter my IPv6 address it once again thinks I am in Mount Laurel, New Jersey.
Digital Element is an IP geolocation provider that has IPv6 capabilities across a wide variety of products and services. In fact, F5’s load balancers use the Digital Element IP geolocation technology.
TCPIPUtils.com is a popular geolocation system that supports IPv6. When I use this system with my IPv4 address, it shows my location as Denver, CO. However, when I used this utility with my IPv6 address it thought my address was located in Kansas with a latitude of 38 and longitude of -98, several hundred miles from my actual location.
MaxMind GeoIP2 and GeoLite IPv6 Country and City database are popular solutions for IPv6 location services. When I enter my IPv6 address into this demonstration site, it accurately determines my city and state and the latitude and longitude is extremely accurate (the most accurate of those I tested).
Google offers their Geolocation API and Geocoding API that can perform geolocation based on IPv4 or IPv6 addresses and Google Maps has a wide variety of application integrations. Just like all IPv6 location systems, they have had challenges and are constantly making improvements to the accuracy of their systems.
Depending on your programming language of choice, there may be geolocation functions built in or that can be added. Python has a “geolocation-python” module that you can download off pypi or github. If you are using Go, there is a Golang client for Google Maps geolocation as well as freegeoip which is written in Go. Perl CPAN also offers the “Perl Geo:IP” module.
Content Delivery Networks (CDNs) also use end-user location to deliver the “closest” cached content for faster download and improved end-user experience. We have talked about how CDNs can help organizations IPv6-enable their public web applications. Companies like Quora, Akamai, AWS CloudFront, CloudFlare, Fastly, and Limelight all have IPv6 CDN and location approximation services. CDNs like, AWS’s CloudFront, can perform georestrictions and whitelist or blacklist connections based on the client’s approximate location.
What’s Next?
It appears that there is a disparity between the accuracy of IPv4 geolocation and IPv6 geolocation. Clearly, more work needs to be done in this area to make IPv6 geolocation as accurate as IPv4 geolocation. However, not all the work on improving IPv6 geolocation solely rests with the RIRs, the ISPs, or the geolocation software/services companies.
Thankfully we don’t completely rely on IP addresses for geolocation. Many mobile apps use the GPS coordinates within the phone as well as Wi-Fi information and other information in combination with GPS data. You have probably seen those mobile app permission pop-ups asking you to allow this flashlight/calculator/QR-code-reader app to allow access to your location and you probably clicked “OK”. Personal privacy concerns aside, one of IPv6’s inherent benefits is its restoration of the end-to-end model and thus no further need for NAT. Even though we should not rely on IP addresses as a factor of user authentication, IPv6 global addresses reduce Internet anonymity, provide greater assurance of what (if not who) you are connecting to, and may eventually lead to greater location accuracy.
