I see a lot of replies about the legality. As mentioned I have legitimate 
reasons for doing this. I plan on serving customers in country.

My questions really are:

* Is most geo data simply derived from self reporting?
* Do these vendors have verification mechanisms?
* Going to the Estonia\Germany example would a traceroute "terminating" in 
Germany before being handed off to my network 1ms away be a tell-tale sign the 
servers are in Germany.
* Is the concept of creating "pseudoPOPs" where it's not cost effective to 
start a POP in the region a 'common practice'?
* Do I run the risk of being blacklisted for this practice?

-Nanoguser100

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, April 21, 2021 9:00 AM, nanoguser100 via NANOG <nanog@nanog.org> 
wrote:

> I wanted to get the communities' opinion on this.
>
> I am an admin for a quasi-ISP providing cloud hosted desktop solutions for 
> end users. We have POPs all around the world, own our own ASN, and advertise 
> /24s or /23s at each of our POPs fro our large aggregate. As an ISP we submit 
> our blocks to popular geolocation vendors such as Google, Maxmind, IP2, etc 
> and put the proper geolocations in our RIR records (RADB, ARIN, etc).
>
> Increasingly I have run into 'niche needs' where a client has a few users in 
> a country we don't have a POP, say Estonia. This is 'mainly' for localization 
> but also in some cases for compliance (some sites REQUIRE an Estonian IP). 
> With that being said is it common practice to 'fake' Geolocations? In this 
> case the user legitimately lives in Estonia, they just happen to be using our 
> cloud service in Germany. I do want to operate in compliance with all the ToS 
> as I don't want to risk our ranges getting blacklisted or the geo vendors 
> stop accepting our data. I would think it's pretty easy to tell given a 
> traceroute would end in Germany even though you're claiming the IP is in 
> Estonia. How common of a practice is it to 'fake' the geos? Is it an 
> acceptable practice?
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.

Reply via email to