Using RIR info to determine geographic location...

Fri Dec 21 02:13:17 UTC 2007

Personally, I have trouble accepting some of the claims the
geotargeting companies have made, such as Quova's 99.9% to the country
level, and 95% to the US state level.  ( More info at
http://www.quova.com/page.php?id=132 ) Perhaps I'm just part of the
outlying data; using the "three top search engines" I rarely see them
get the city correct (ie. where *I* am physically located, as opposed
to where the registration data says the block is located), and have
seen some glaring errors for the country in some cases.

Geotargeting has turned into quite a business, and I'm concerned that
people who rely on these services do not fully understand the risks.

--gregbo

On Thu, Dec 20, 2007 at 08:48:44AM +0200, Hank Nussbacher wrote:
> 
> At 08:44 PM 19-12-07 -0500, Drew Weaver wrote:
> 
> I too would be interested to know how others feel about the various 
> geo-location services available to speed things along.  Three that come to 
> mind are Akamai, Neustar/Ultradns and the "roll your own" Cisco GSS 
> 4492R.  How do they stack up?  How good are the various Maxmind files?
> 
> Thanks,
> Hank
> 
> 
> >         Is this becoming a more common or less common practice as we 
> > slide ourselves into the last week of 2007? The reason I am wondering is 
> > we have noticed some 'issues' recently where correct info in the RIR 
> > causes very inefficient and sometimes annoying interaction with some of 
> > the world's largest online applications (such as Google) lets say for 
> > example that a customer in India purchases dedicated server or 
> > Co-Location hosting at a HSP in the United States [very common]. So the 
> > RIR shows that the customer is in India, so when the customer interacts 
> > with any google applications google automatically directs this traffic to 
> > google.in (or the India version of whichever app)....
> >
> >         More unfortunate than this fact, is the fact that it appears that 
> > services and application providers such as google are caching RIR data 
> > for an "unknown" amount of time. Which means that if a service provider 
> > SWIPs an allocation to a customer (lets use the same example... again in 
> > India) (say a /24) to a user, and then that user subsequently returns 
> > that allocation and the service provider re-allocates in smaller blocks 
> > to different customers in say /29, /28.. et cetera... the problems 
> > related to this issue are compounded (30 customers being affected, 
> > instead of one...) by this caching...
> >
> >         Obviously providing RIR information is the responsibility of 
> > service providers (it is even ARIN's policy) has anyone else in the 
> > community ran into issues such as this and found solutions or workarounds?
> >
> >Happy holidays to all on NANOG :D
> >
> >Thanks,
> >-Drew