Google folks: I see historical reference to needing to use the Google Peering Portal ( http://peering.google.com) if you need to provide Google with geofeed info for GeoIP info on network blocks, ref https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html. Is that still the case? Are there any avenues to provide Google with geofeed info if you're *not* currently peering with 15169? Or to get access to just the geofeed update portion of the Peering Portal? -- Hugo Slabbert
I was able to get access without peering with 15169 by getting access to the ISP portal (isp.google.com) which does have Geofeed processing for my AS, but I am unsure if you will get access without being an eyeball network. On Tue, Aug 30, 2022 at 3:37 PM Hugo Slabbert <hugo@slabnet.com> wrote:
Google folks:
I see historical reference to needing to use the Google Peering Portal ( http://peering.google.com) if you need to provide Google with geofeed info for GeoIP info on network blocks, ref https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.
Is that still the case? Are there any avenues to provide Google with geofeed info if you're *not* currently peering with 15169? Or to get access to just the geofeed update portion of the Peering Portal?
-- Hugo Slabbert
For what it's worth I attempted to get access by filling out the same portal and was told to go pound sand, so your results may very. On 2022-08-30 12:40, Benjamin Hatton wrote:
I was able to get access without peering with 15169 by getting access to the ISP portal (isp.google.com <http://isp.google.com>) which does have Geofeed processing for my AS, but I am unsure if you will get access without being an eyeball network.
On Tue, Aug 30, 2022 at 3:37 PM Hugo Slabbert <hugo@slabnet.com> wrote:
Google folks:
I see historical reference to needing to use the Google Peering Portal (http://peering.google.com) if you need to provide Google with geofeed info for GeoIP info on network blocks, ref https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.
Is that still the case? Are there any avenues to provide Google with geofeed info if you're *not* currently peering with 15169? Or to get access to just the geofeed update portion of the Peering Portal?
-- Hugo Slabbert
Dear Hugo, On Tue, Aug 30, 2022 at 12:34:41PM -0700, Hugo Slabbert wrote:
Google folks:
I see historical reference to needing to use the Google Peering Portal ( http://peering.google.com) if you need to provide Google with geofeed info for GeoIP info on network blocks, ref https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.
Is that still the case? Are there any avenues to provide Google with geofeed info if you're *not* currently peering with 15169? Or to get access to just the geofeed update portion of the Peering Portal?
(I don't work for Google), but ... There is a RFC detailing how to find Geofeed data (and make Geofeed data findable): https://datatracker.ietf.org/doc/html/rfc9092 The idea is that in inetnum/inet6num objects (which are maintained by the IP prefix holder), the holder can point to the location where Geofeed data can be found. There are a few methods: 1) Use the 'geofeed:' RPSL attribute (the RIPE Whois server supports this), example: $ whois -h whois.ripe.net 146.75.0.0/16 | grep geofeed geofeed: https://ip-geolocation.fastly.com/ 2) A slightly uglier hack: stick a reference to the Geofeed location in a RPSL remark (should work in databases which don't (yet) support the 'geofeed:' attribute), example: $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv Kind regards, Job
I was able to get access without peering with 15169 by getting access to
For what it's worth I attempted to get access by filling out the same
Gonna multi-reply on this one: @Benjamin: the ISP portal (isp.google.com) which does have Geofeed processing for my AS, but I am unsure if you will get access without being an eyeball network. Thanks; I'll give that bash. I think our org might have tried this previously before my time, but will see where we get to. @Christopher: portal and was told to go pound sand, so your results may very. Good to know. :fingers-crossed: @Job: Thanks! I was aware of the RIPE whois option, but the relevant resources for us are in ARIN. I wasn't aware of the RPSL *remark* option for providing that. We should be able to give that a bash. Can anyone confirm if Google respects the remark-based option? Given the authors and some of the wording, I would hope so? -- Hugo Slabbert On Tue, Aug 30, 2022 at 12:48 PM Job Snijders <job@fastly.com> wrote:
Dear Hugo,
On Tue, Aug 30, 2022 at 12:34:41PM -0700, Hugo Slabbert wrote:
Google folks:
I see historical reference to needing to use the Google Peering Portal ( http://peering.google.com) if you need to provide Google with geofeed info for GeoIP info on network blocks, ref https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.
Is that still the case? Are there any avenues to provide Google with geofeed info if you're *not* currently peering with 15169? Or to get access to just the geofeed update portion of the Peering Portal?
(I don't work for Google), but ...
There is a RFC detailing how to find Geofeed data (and make Geofeed data findable): https://datatracker.ietf.org/doc/html/rfc9092
The idea is that in inetnum/inet6num objects (which are maintained by the IP prefix holder), the holder can point to the location where Geofeed data can be found.
There are a few methods:
1) Use the 'geofeed:' RPSL attribute (the RIPE Whois server supports this), example:
$ whois -h whois.ripe.net 146.75.0.0/16 | grep geofeed geofeed: https://ip-geolocation.fastly.com/
2) A slightly uglier hack: stick a reference to the Geofeed location in a RPSL remark (should work in databases which don't (yet) support the 'geofeed:' attribute), example:
$ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv
Kind regards,
Job
On Tue, Aug 30, 2022 at 01:28:18PM -0700, Hugo Slabbert wrote:
@Job:
Thanks! I was aware of the RIPE whois option, but the relevant resources for us are in ARIN. I wasn't aware of the RPSL *remark* option for providing that. We should be able to give that a bash.
Hmmm, there might be an obstacle due to lack of inetnum support in ARIN: https://www.arin.net/participate/community/acsp/suggestions/2021/2021-27/ However there is good news: the last paragraph of RFC 9092 section 3 suggests a workaround specific to ARIN: "Currently, the registry data published by ARIN are not the same RPSL as that of the other registries (see [RFC7485] for a survey of the WHOIS Tower of Babel); therefore, when fetching from ARIN via FTP [RFC0959], WHOIS [RFC3912], the Registration Data Access Protocol (RDAP) [RFC9082], etc., the "NetRange" attribute/key MUST be treated as "inetnum", and the "Comment" attribute MUST be treated as "remarks". Perhaps you insert a "Comment: Geofeed https://xxx/geofeed.csv" in the place where NetRange blobs come from? Kind regards, Job
Good call, thanks. That appears to be via the assigned resources bit ("IP Addresses" heading in Arin Online). Will give that a shot, thanks! -- Hugo Slabbert On Tue, Aug 30, 2022 at 1:38 PM Job Snijders <job@fastly.com> wrote:
On Tue, Aug 30, 2022 at 01:28:18PM -0700, Hugo Slabbert wrote:
@Job:
Thanks! I was aware of the RIPE whois option, but the relevant resources for us are in ARIN. I wasn't aware of the RPSL *remark* option for providing that. We should be able to give that a bash.
Hmmm, there might be an obstacle due to lack of inetnum support in ARIN: https://www.arin.net/participate/community/acsp/suggestions/2021/2021-27/
However there is good news: the last paragraph of RFC 9092 section 3 suggests a workaround specific to ARIN:
"Currently, the registry data published by ARIN are not the same RPSL as that of the other registries (see [RFC7485] for a survey of the WHOIS Tower of Babel); therefore, when fetching from ARIN via FTP [RFC0959], WHOIS [RFC3912], the Registration Data Access Protocol (RDAP) [RFC9082], etc., the "NetRange" attribute/key MUST be treated as "inetnum", and the "Comment" attribute MUST be treated as "remarks".
Perhaps you insert a "Comment: Geofeed https://xxx/geofeed.csv" in the place where NetRange blobs come from?
Kind regards,
Job
Old topic: if one doesn't have access to https://isp.google.com how does one update their geo-location data so Google sees it? Thanks, Hank
On Tue, Aug 30, 2022 at 12:34:41PM -0700, Hugo Slabbert wrote:
Google folks:
I see historical reference to needing to use the Google Peering Portal ( http://peering.google.com) if you need to provide Google with geofeed info for GeoIP info on network blocks, ref https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.
Is that still the case? Are there any avenues to provide Google with geofeed info if you're *not* currently peering with 15169? Or to get access to just the geofeed update portion of the Peering Portal?
Try putting it in your whois. More info on how this works and how to do it here: https://geolocatemuch.com/ Regards, Robert -- USC Information Sciences Institute <http://www.isi.edu/> Networking and Cybersecurity Division On Mon 2023-09-18 13:17:49+0300 Hank wrote:
Old topic: if one doesn't have access to https://isp.google.com how does one update their geo-location data so Google sees it?
Thanks,
Hank
On Tue, Aug 30, 2022 at 12:34:41PM -0700, Hugo Slabbert wrote:
Google folks:
I see historical reference to needing to use the Google Peering Portal ( http://peering.google.com) if you need to provide Google with geofeed info for GeoIP info on network blocks, ref https://mailman.nanog.org/pipermail/nanog/2015-May/075229.html.
Is that still the case? Are there any avenues to provide Google with geofeed info if you're *not* currently peering with 15169? Or to get access to just the geofeed update portion of the Peering Portal?
participants (6)
-
Benjamin Hatton -
Christopher Munz-Michielin -
Hank Nussbacher -
Hugo Slabbert -
Job Snijders -
Robert Story