Re: [ncc-services-wg] IP geolocation services
Hi. I think this should be addressed to the companies using Geolocation technics. Not the the RIR's nor the LIR's. We have had these issues with Google and has seeked answers from them on numerous occasions on how they do their Geolocation stuff. No respons what so ever. We tried to accomodate the customer wishes by changing the country of the Inetnum (violating our internal policies on how an Inetnum should be set up) but it didn't work of course. As long as they are not interested in discussing this I don't think the RIR's should do anything in their db's or change how they work the db. The users suffering should turn to Google, Yahoo or whatever the company using geolocation and complain. Not to the LIR nor to the RIR. Rgds Patrick Arkley European Hostmaster Verizon ** sent from mobile device ** ----- Original Message ----- From: ncc-services-wg-admin@ripe.net <ncc-services-wg-admin@ripe.net> To: Vegard Svanberg <vegard@monsternett.no> Cc: ncc-services-wg@ripe.net <ncc-services-wg@ripe.net> Sent: Tue Oct 27 17:18:41 2009 Subject: Re: [ncc-services-wg] IP geolocation services With my DB-WG Chair hat on: Trying to - with reasonable accuracy - deduct geo-location-info for a particular end-system using a particualr address, at a particular point in time, from a block registered in a particular RIR's DB as an assignment is very bad idea to begin with. At least for the RIPE-DB, there are no agreed or definend semantics for the interpretation of the country: attribute. The data is a hint, at best. Actually, the country codes entered could point to the home country of a particular LIR's administrative location, to the location of the responsible NOC (operating from abroad) or something altogether, completely, arbitrary. Also, there are the codes "ZZ" and "EU", neither of which is clearly defined regarding its meaning. Just to fill in some background: a while ago we had the discussion in the DB-WG proposing to completely remove the country attribute for the reasons given. However, we received input that requested the country data to be kept, but *purely* for statistical reasons! It was understood that the accuracy and quality of that sort of data is just good enough exclusively for *that* pupose - but not really for something else and least for basing operational decisions on! Now, taking off my DB-WG hat.... My personal feeling is that the RIRs' databases are definitely the wrong place to maintain such (volatile) data (in many cases for subranges of registry entries!) and the RIRs are the wrong organisatins to get involved with such a "service". And, to top it off, with mobile users and tunnels, the whole concept of managing access to data or services based on an IP address is going to brake more often than it does already ;-) Wilfried Vegard Svanberg wrote:
We've recently experienced a storm of customer complaints after starting to use IP addresses from a new allocation/assignment. The IP block was earlier in use by a German company. The result is that services like Google and Yahoo assume users are from Germany and presents content accordingly. Some users have also reported that they are excluded from certain services.
A quick web search reveals that this is a pretty common problem.
While not blaming RIPE or the other RIRs, we believe this problem should be addressed, and that the initiative has to come from the RIRs.
I would like to propose that RIPE NCC works together with other RIRs to see if it's possible to implement procedures/routines to notify providers and users of IP geolocation services of new, relocated and deleted allocations.
Also, one should probably consider if it's a need for a (distributed?) database with more fine-grained location data than the whois database currently provides (also, I've been told that licensing issues prohibits geolocation providers from using the RIR DBs directly, but I've not been able to verify this).
Apologies in advance if this has been discussed before -- I searched the archive, but got no hits.
Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009– huvudkontorets adress: Armégatan 38, Box 4127, 171 04 Solna, Sverige
* Arkley, Patrick <patrick.arkley@se.verizonbusiness.com> [2009-10-27 21:57]:
I think this should be addressed to the companies using Geolocation technics. Not the the RIR's nor the LIR's.
Well, of course. And note that noone are blaming the RIRs. But as you've experienced yourself, it's not easy being an ISP or LIR and discussing this directly. Most of the time, at least from my experience, you won't even get a decent answer. The RIRs should consider establishing communication channels with at least the major GeoIP service providers, but preferably also to major service providers relying on geo-location, like Google, Yahoo etc. It should be in their own interest that this info is as accurate as possible, so I believe they will listen if the party bringing this up is big enough and have suggestions on how this can be done efficiently. I'm having difficulties seeing who else than the RIRs would be best suited to coordinate this work. If this becomes wild west (well, it is already), ISP A's business in, say, Britain could be seriously impacted because the RIR allocated an IP block perviously used in Italy to the LIR. ISP A lose customers to ISP B and gets a lot of negative headlines because the customers can access <insert popular web service> from ISP B, but not from ISP A. The customers and journalists don't care who's to blame, and ISP A has no tool to control the situation, and in worst case it won't be fixed it in a long time. In my opinion, this is a very serious matter and must be treated accordingly. -- -o) Vegard Svanberg, CTO - Monsternett (www.monsternett.no) /\\ Violgata 3A, N-1776 HALDEN, NORWAY _\_v Phone: (+47) 69701802 | Fax: (+47) 69701801
The importance of geolocation wrt many end-user-services is well understood, but you're missing the point. Geolocation is not an attribute in the RIRs DBs, nor can the RIRs be held responsible for 3rd parties use of the data for unintended purposes. The country-attribute may say something about the location of the LIRs administrative HQ, but nothing prevents a particular prefix from being used somewhere else, or even across many different countries world-wide. What you're asking for would require new policies that place specific requirements on LIRs to register and maintain inetnum-objects for subnets consistent with national borders. //per
* Per Heldal <heldal@eml.cc> [2009-10-28 10:46]:
The importance of geolocation wrt many end-user-services is well understood, but you're missing the point. Geolocation is not an attribute in the RIRs DBs, nor can the RIRs be held responsible for 3rd parties use of the data for unintended purposes.
I've not said that. Please don't put words in my mouth.
What you're asking for would require new policies that place specific requirements on LIRs to register and maintain inetnum-objects for subnets consistent with national borders.
I've not said or asked for that, either. -- -o) Vegard Svanberg, CTO - Monsternett (www.monsternett.no) /\\ Violgata 3A, N-1776 HALDEN, NORWAY _\_v Phone: (+47) 69701802 | Fax: (+47) 69701801
I could not agree more. With kind regards, Andries Hettema IP-Office KPN Internet +31 (0)70 45 13398 ip-office@kpn.com Hi. I think this should be addressed to the companies using Geolocation technics. Not the the RIR's nor the LIR's. We have had these issues with Google and has seeked answers from them on numerous occasions on how they do their Geolocation stuff. No respons what so ever. We tried to accomodate the customer wishes by changing the country of the Inetnum (violating our internal policies on how an Inetnum should be set up) but it didn't work of course. As long as they are not interested in discussing this I don't think the RIR's should do anything in their db's or change how they work the db. The users suffering should turn to Google, Yahoo or whatever the company using geolocation and complain. Not to the LIR nor to the RIR. Rgds Patrick Arkley European Hostmaster Verizon ** sent from mobile device ** ----- Original Message ----- From: ncc-services-wg-admin@ripe.net <ncc-services-wg-admin@ripe.net> To: Vegard Svanberg <vegard@monsternett.no> Cc: ncc-services-wg@ripe.net <ncc-services-wg@ripe.net> Sent: Tue Oct 27 17:18:41 2009 Subject: Re: [ncc-services-wg] IP geolocation services With my DB-WG Chair hat on: Trying to - with reasonable accuracy - deduct geo-location-info for a particular end-system using a particualr address, at a particular point in time, from a block registered in a particular RIR's DB as an assignment is very bad idea to begin with. At least for the RIPE-DB, there are no agreed or definend semantics for the interpretation of the country: attribute. The data is a hint, at best. Actually, the country codes entered could point to the home country of a particular LIR's administrative location, to the location of the responsible NOC (operating from abroad) or something altogether, completely, arbitrary. Also, there are the codes "ZZ" and "EU", neither of which is clearly defined regarding its meaning. Just to fill in some background: a while ago we had the discussion in the DB-WG proposing to completely remove the country attribute for the reasons given. However, we received input that requested the country data to be kept, but *purely* for statistical reasons! It was understood that the accuracy and quality of that sort of data is just good enough exclusively for *that* pupose - but not really for something else and least for basing operational decisions on! Now, taking off my DB-WG hat.... My personal feeling is that the RIRs' databases are definitely the wrong place to maintain such (volatile) data (in many cases for subranges of registry entries!) and the RIRs are the wrong organisatins to get involved with such a "service". And, to top it off, with mobile users and tunnels, the whole concept of managing access to data or services based on an IP address is going to brake more often than it does already ;-) Wilfried Vegard Svanberg wrote:
We've recently experienced a storm of customer complaints after starting to use IP addresses from a new allocation/assignment. The IP block was earlier in use by a German company. The result is that services like Google and Yahoo assume users are from Germany and presents content accordingly. Some users have also reported that they are excluded from certain services.
A quick web search reveals that this is a pretty common problem.
While not blaming RIPE or the other RIRs, we believe this problem should be addressed, and that the initiative has to come from the RIRs.
I would like to propose that RIPE NCC works together with other RIRs to see if it's possible to implement procedures/routines to notify providers and users of IP geolocation services of new, relocated and deleted allocations.
Also, one should probably consider if it's a need for a (distributed?) database with more fine-grained location data than the whois database currently provides (also, I've been told that licensing issues prohibits geolocation providers from using the RIR DBs directly, but I've not been able to verify this).
Apologies in advance if this has been discussed before -- I searched the archive, but got no hits.
Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009- huvudkontorets adress: Armégatan 38, Box 4127, 171 04 Solna, Sverige
Hi, Because of the reasons stated below LIR's databases seems not to be perfect place to store geolocalization information. First of all IP block may be distibuted among different countries. Secondly information in database isn't updated along with network topology changes - in real cooperation with growing CDN solutions it should be updated along with every network topology change (even along with links failures). It seems that BGP is the only answer for the problem. Within my network I use geographic communities to feed CDN network with information about current network topology. Why not to use this idea in global scale: We could propose new RFC and agree that there is reserved community ASN:xxyy ASN advertising ASN number xx is global comunity number for geolocalization yy is countrycode The only problem is to have global acceptance for xx as reserved community number and time needed for deployment in majority of networks. Konrad Plich On Tue, 27 Oct 2009, Arkley, Patrick wrote:
Hi.
I think this should be addressed to the companies using Geolocation technics. Not the the RIR's nor the LIR's. We have had these issues with Google and has seeked answers from them on numerous occasions on how they do their Geolocation stuff. No respons what so ever. We tried to accomodate the customer wishes by changing the country of the Inetnum (violating our internal policies on how an Inetnum should be set up) but it didn't work of course.
As long as they are not interested in discussing this I don't think the RIR's should do anything in their db's or change how they work the db.
The users suffering should turn to Google, Yahoo or whatever the company using geolocation and complain. Not to the LIR nor to the RIR.
Rgds
Patrick Arkley European Hostmaster Verizon ** sent from mobile device **
----- Original Message ----- From: ncc-services-wg-admin@ripe.net <ncc-services-wg-admin@ripe.net> To: Vegard Svanberg <vegard@monsternett.no> Cc: ncc-services-wg@ripe.net <ncc-services-wg@ripe.net> Sent: Tue Oct 27 17:18:41 2009 Subject: Re: [ncc-services-wg] IP geolocation services
With my DB-WG Chair hat on:
Trying to - with reasonable accuracy - deduct geo-location-info for a particular end-system using a particualr address, at a particular point in time, from a block registered in a particular RIR's DB as an assignment is very bad idea to begin with.
At least for the RIPE-DB, there are no agreed or definend semantics for the interpretation of the country: attribute. The data is a hint, at best.
Actually, the country codes entered could point to the home country of a particular LIR's administrative location, to the location of the responsible NOC (operating from abroad) or something altogether, completely, arbitrary. Also, there are the codes "ZZ" and "EU", neither of which is clearly defined regarding its meaning.
Just to fill in some background: a while ago we had the discussion in the DB-WG proposing to completely remove the country attribute for the reasons given. However, we received input that requested the country data to be kept, but *purely* for statistical reasons! It was understood that the accuracy and quality of that sort of data is just good enough exclusively for *that* pupose - but not really for something else and least for basing operational decisions on!
Now, taking off my DB-WG hat....
My personal feeling is that the RIRs' databases are definitely the wrong place to maintain such (volatile) data (in many cases for subranges of registry entries!) and the RIRs are the wrong organisatins to get involved with such a "service".
And, to top it off, with mobile users and tunnels, the whole concept of managing access to data or services based on an IP address is going to brake more often than it does already ;-)
Wilfried
Vegard Svanberg wrote:
We've recently experienced a storm of customer complaints after starting to use IP addresses from a new allocation/assignment. The IP block was earlier in use by a German company. The result is that services like Google and Yahoo assume users are from Germany and presents content accordingly. Some users have also reported that they are excluded from certain services.
A quick web search reveals that this is a pretty common problem.
While not blaming RIPE or the other RIRs, we believe this problem should be addressed, and that the initiative has to come from the RIRs.
I would like to propose that RIPE NCC works together with other RIRs to see if it's possible to implement procedures/routines to notify providers and users of IP geolocation services of new, relocated and deleted allocations.
Also, one should probably consider if it's a need for a (distributed?) database with more fine-grained location data than the whois database currently provides (also, I've been told that licensing issues prohibits geolocation providers from using the RIR DBs directly, but I've not been able to verify this).
Apologies in advance if this has been discussed before -- I searched the archive, but got no hits.
Verizon Sweden AB - registrerat i Sverige med organisationsnummer 556489-1009ÿÿ huvudkontorets adress: Armégatan 38, Box 4127, 171 04 Solna, Sverige
On 28 Oct 2009, at 08:57, konradpl@zt.piotrkow.tpsa.pl wrote:
It seems that BGP is the only answer for the problem.
Nope. Every IP address (or /24) could have a LOC record associated with it. That could work the same way as a reverse DNS lookup. That said, I think this WG could develop a "Geolocation info from RIR databases (or DNS) considered harmful" RIPE document. IMO there's no need for an RFC or cleverness with ASNs.
That said, I think this WG could develop a "Geolocation info from RIR databases (or DNS) considered harmful" RIPE document. IMO there's no need for an RFC or cleverness with ASNs.
I think you just wrote it :) Really there isn't much more to say unless you actually want to work on solving the problem, we might consider adding it to the database disclaimer or manual. Grtx, Marco
On 28 Oct 2009, at 09:24, Marco Hogewoning wrote:
I think you just wrote it :)
Cool!
Really there isn't much more to say unless you actually want to work on solving the problem
Well, I suppose this mythical "Geolocation info from RIR databases considered harmful" document could explain the main reasons why that's the case.
I do agree that we can put as many records to the database as we want. Problem is in usabilility (BGP feed is easier to deal with on CDN platforms) and first of all speed - with BGP you can follow automaticly every change in network topology while separate database needs manual intervention. Konrad Plich On Wed, 28 Oct 2009, Jim Reid wrote:
On 28 Oct 2009, at 08:57, konradpl@zt.piotrkow.tpsa.pl wrote:
It seems that BGP is the only answer for the problem.
Nope.
Every IP address (or /24) could have a LOC record associated with it. That could work the same way as a reverse DNS lookup.
That said, I think this WG could develop a "Geolocation info from RIR databases (or DNS) considered harmful" RIPE document. IMO there's no need for an RFC or cleverness with ASNs.
On 10/28/2009 09:57 AM, konradpl@zt.piotrkow.tpsa.pl wrote:
Why not to use this idea in global scale: We could propose new RFC and agree that there is reserved community ASN:xxyy ASN advertising ASN number xx is global comunity number for geolocalization yy is countrycode
The only problem is to have global acceptance for xx as reserved community number and time needed for deployment in majority of networks.
aggregation? //per
On Wed, 28 Oct 2009, Per Heldal wrote:
On 10/28/2009 09:57 AM, konradpl@zt.piotrkow.tpsa.pl wrote:
Why not to use this idea in global scale: We could propose new RFC and agree that there is reserved community ASN:xxyy ASN advertising ASN number xx is global comunity number for geolocalization yy is countrycode
The only problem is to have global acceptance for xx as reserved community number and time needed for deployment in majority of networks.
aggregation?
No change - if you today advertise prefix you will still advertise it with the same mask. The only change is that geocommunity will be added. If you today advertise more specific prefix from different country you will add different geocommunity to show to the world that origin country for the whole less specific from LIR database is not applicable to it. Konrad Plich
On 10/28/2009 11:22 AM, konradpl@zt.piotrkow.tpsa.pl wrote:
aggregation?
No change - if you today advertise prefix you will still advertise it with the same mask. The only change is that geocommunity will be added.
If you today advertise more specific prefix from different country you will add different geocommunity to show to the world that origin country for the whole less specific from LIR database is not applicable to it.
Konrad Plich
And how will those networks who only see my aggregate be able to know the exact location of all my specifics? What you're suggesting is just one more incomplete source of information from which geoloc services can try to collect some coherent information (along with dns and inetnum-db). I read this thread as a request to help provide guaranteed accurate geoloc info, and BGP isn't the place for that. //per
On Wed, 28 Oct 2009, Per Heldal wrote:
On 10/28/2009 11:22 AM, konradpl@zt.piotrkow.tpsa.pl wrote:
aggregation?
No change - if you today advertise prefix you will still advertise it with the same mask. The only change is that geocommunity will be added.
If you today advertise more specific prefix from different country you will add different geocommunity to show to the world that origin country for the whole less specific from LIR database is not applicable to it.
Konrad Plich
And how will those networks who only see my aggregate be able to know the exact location of all my specifics?
If you do not avertise somewhere your more specyfic mens that prfix do not need different treatment than your global less specyfic. I can't imagine situation when you want part of your network to be routed in the same way like the rest of the network and at the same time to have different CDN that will be feeding it because of geolocation.
What you're suggesting is just one more incomplete source of information from which geoloc services can try to collect some coherent information (along with dns and inetnum-db). I read this thread as a request to help provide guaranteed accurate geoloc info, and BGP isn't the place for that.
BGP is the most coherent protocol with real reason of dividing traffic: different location=different traffic flow. BGP shows traffic flow and links state change. That is the information CDNs deserve. Additionaly it can be altered, is fast and automatic. Konrad Plich
participants (7)
-
Arkley, Patrick -
IP-Office KPN -
Jim Reid -
konradpl＠zt.piotrkow.tpsa.pl -
Marco Hogewoning -
Per Heldal -
Vegard Svanberg