Geolocation data management practices?
Aloha NANOG, What is the best practice (or peoples preferred methods) to update/correct/maintain geolocation data? Do most people start with description field info in route/route6 objects? Also, thoughts and considerations on using IPv4 space from one RIR in countries belonging to another RIR? With IPv4 exhaustion and inter-RIR IPv4 transfers, and geolocation data, it seems less applicable than it had been (a decade ago). The IP's will be used for CDN, not by end-users/subscribers. Context: trying to work through an administrative "challenge" with LACNIC regarding an IPv4 transfer, considering transferring to ARIN and then using in LACNIC (then once resolved, transfer from ARIN to LACNIC). Or just using existing ARIN space in Brazil. LACNIC is making things more difficult than they need to be. I know this is NANOG... but seeking advice, working on a global network, US HQ, currently no active "registration" in LACNIC (except Brazil), but we operate in 5 countries in the region (data center/colo). We would use Brazil, but very hesitant to use their NIC (nic.br); LACNIC is saying we cannot maintain our relationship with them using our Brazil organization (our only formal subsidiary in the region). LACNIC does not really define the "entity" operating in their region well. We use our US entity with RIPE and APNIC, simply showing documentation (contracts) that we operate in their region. Maybe I am not using the magic word?
Hi Shawn, On Wed, Apr 20, 2022 at 01:14:29PM -1000, Shawn wrote:
What is the best practice (or peoples preferred methods) to update/correct/maintain geolocation data? Do most people start with description field info in route/route6 objects?
[snip]
Maybe I am not using the magic word?
The magic word is "geofeed"! :-) The format is specified in RFC 8805. Finding and using Geofeed data is described in RFC 9092. Example in the wild: $ whois -h whois.ripe.net 146.75.0.0 | fgrep geofeed: geofeed: https://ip-geolocation.fastly.com/ Another example below, in this instance the geofeed information is stored in a 'remarks:' attribute. Unfortunately this particular RIR does not (yet?) properly support the native RPSL geofeed attribute for IPv6 /48 PI blocks. $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep geofeed remarks: Geofeed https://sobornost.net/geofeed.csv Both approaches work. Kind regards, Job
Besides geofeed, there are also geoidx records in IRRs but whether geolocation services actually use geofeed or geoidx remains to be seen. You can see some geoidx: at this IRR entry in TC: https://bgp.net.br/whois/?q=-s%20TC%20-i%20mnt-by%20MAINT-AS271761 Regarding LACNIC, what LACNIC, NIC.mx and NIC.br do is to select which RIR or NIR services requests depending on the organisation's country. Rubens On Thu, Apr 21, 2022 at 9:53 AM Shawn <mailman.nanog.org@kleinart.net> wrote:
Aloha NANOG,
What is the best practice (or peoples preferred methods) to update/correct/maintain geolocation data? Do most people start with description field info in route/route6 objects?
Also, thoughts and considerations on using IPv4 space from one RIR in countries belonging to another RIR?
With IPv4 exhaustion and inter-RIR IPv4 transfers, and geolocation data, it seems less applicable than it had been (a decade ago). The IP's will be used for CDN, not by end-users/subscribers. Context: trying to work through an administrative "challenge" with LACNIC regarding an IPv4 transfer, considering transferring to ARIN and then using in LACNIC (then once resolved, transfer from ARIN to LACNIC). Or just using existing ARIN space in Brazil. LACNIC is making things more difficult than they need to be. I know this is NANOG... but seeking advice, working on a global network, US HQ, currently no active "registration" in LACNIC (except Brazil), but we operate in 5 countries in the region (data center/colo). We would use Brazil, but very hesitant to use their NIC (nic.br); LACNIC is saying we cannot maintain our relationship with them using our Brazil organization (our only formal subsidiary in the region). LACNIC does not really define the "entity" operating in their region well. We use our US entity with RIPE and APNIC, simply showing documentation (contracts) that we operate in their region. Maybe I am not using the magic word?
Go through this list: https://thebrotherswisp.com/index.php/geo-and-vpn/ The RFC only works if they're pulling your feed and they'd only know that if you contact them in the first place. On Thu, Apr 21, 2022 at 9:14 AM Rubens Kuhl <rubensk@gmail.com> wrote:
Besides geofeed, there are also geoidx records in IRRs but whether geolocation services actually use geofeed or geoidx remains to be seen. You can see some geoidx: at this IRR entry in TC: https://bgp.net.br/whois/?q=-s%20TC%20-i%20mnt-by%20MAINT-AS271761
Regarding LACNIC, what LACNIC, NIC.mx and NIC.br do is to select which RIR or NIR services requests depending on the organisation's country.
Rubens
On Thu, Apr 21, 2022 at 9:53 AM Shawn <mailman.nanog.org@kleinart.net> wrote:
Aloha NANOG,
What is the best practice (or peoples preferred methods) to update/correct/maintain geolocation data? Do most people start with description field info in route/route6 objects?
Also, thoughts and considerations on using IPv4 space from one RIR in countries belonging to another RIR?
With IPv4 exhaustion and inter-RIR IPv4 transfers, and geolocation data,
seems less applicable than it had been (a decade ago). The IP's will be used for CDN, not by end-users/subscribers. Context: trying to work through an administrative "challenge" with LACNIC regarding an IPv4 transfer, considering transferring to ARIN and then using in LACNIC (then once resolved, transfer from ARIN to LACNIC). Or just using existing ARIN space in Brazil. LACNIC is making things more difficult than they need to be. I know
it this is
NANOG... but seeking advice, working on a global network, US HQ, currently no active "registration" in LACNIC (except Brazil), but we operate in 5 countries in the region (data center/colo). We would use Brazil, but very hesitant to use their NIC (nic.br); LACNIC is saying we cannot maintain our relationship with them using our Brazil organization (our only formal subsidiary in the region). LACNIC does not really define the "entity" operating in their region well. We use our US entity with RIPE and APNIC, simply showing documentation (contracts) that we operate in their region. Maybe I am not using the magic word?
On 4/21/22 06:14, Rubens Kuhl wrote:
Besides geofeed, there are also geoidx records in IRRs but whether geolocation services actually use geofeed or geoidx remains to be seen. You can see some geoidx: at this IRR entry in TC: https://bgp.net.br/whois/?q=-s%20TC%20-i%20mnt-by%20MAINT-AS271761
Regarding LACNIC, what LACNIC, NIC.mx and NIC.br do is to select which RIR or NIR services requests depending on the organisation's country.
Also: RFC 3693: Geopriv Requirements <https://datatracker.ietf.org/doc/html/rfc3693> RFC 5870: A Uniform Resource Identifier for Geographic Locations ('geo' URI) <https://datatracker.ietf.org/doc/html/rfc5870> RFC 6288: URN Namespace for the Defence Geospatial Information Working Group (DGIWG) <https://datatracker.ietf.org/doc/html/rfc6288> RFC 6397: Multi-Threaded Routing Toolkit (MRT) BGP Routing Information Export Format with Geo-Location Extensions <https://datatracker.ietf.org/doc/html/rfc6397> RFC 6772: Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information <https://datatracker.ietf.org/doc/html/rfc6772> RFC 7942: The GeoJSON Format <https://datatracker.ietf.org/doc/html/rfc7942> RFC 8142: GeoJSON Text Sequences <https://datatracker.ietf.org/doc/html/rfc8142> RFC 8805: A Format for Self-Published IP Geolocation Feeds <https://datatracker.ietf.org/doc/html/rfc8805> RFC 9092: Finding and Using Geofeed Data <https://datatracker.ietf.org/doc/html/rfc9092> -- Charles Polisher (/Pedantic, I?/)
participants (5)
-
Charles Polisher -
Job Snijders -
Josh Luthman -
Rubens Kuhl -
Shawn