Mailing List Archive

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

Gonna multi-reply on this one:

@Benjamin:

> 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.

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:

> 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.

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?