Re: Geolocation data management practices?

[Justin Krejci]

For corrections/updates, what I have found to be generally successful is


1. make sure to advertise the IP blocks into the DFZ from your ASN as soon as 
possible

2. make sure ARIN data is accurate (we use ARIN, you may use one of the other 
registries)

3. update my geofeed, as referenced already in this thread

4. directly contact organizations that have geolocation services but don't 
subscribe to my geofeed


If anyone has any additional geolocation organizations I didn't list, I would 
be happy to hear about them.



Geofeed subscriptions are in place with these organizations


IP Info
https://ipinfo.io/
https://ipinfo.io/faq/article/49-how-can-i-submit-a-correction
https://ipinfo.io/corrections

dbip
https://db-ip.com/
https://db-ip.com/contact/
support  db-ip.com

IPGeolocation
https://ipgeolocation.io/
support  ipgeolocation.io

Maxmind
https://www.maxmind.com/en/geoip-demo
https://support.maxmind.com/geoip-data-correction-request/

Neustar
https://www.home.neustar/resources/tools/ip-geolocation-lookup-tool
https://www.home.neustar/resources/tools/submit-to-global-ip-database
ipintel  support.neustar

BigDataCloud
https://www.bigdatacloud.com/ip-geolocation/

Digital Element
https://www.digitalelement.com/geolocation/
https://www.digitalelement.com/contact-us/
ip-data  digitalelement.com

ip2location
https://www.ip2location.com/demo
support  ip2location.com
Only accepts feeds when all entries have a city defined

Google
https://isp.google.com
Set geofeed URL within their ISP portal




No geofeed subscriptions in place for these organizations and require 
individual contact for corrections/updates


ipstack
https://ipstack.com/
https://ipstack.com/contact

Geo IP View
https://www.geoipview.com/
andrew  geoipview.com
email address is not currently receiving mail, as such I assume not many are 
using this service

IPligence
http://www.ipligence.com/geolocation
https://www.ipligence.com/contact

ipdata
https://ipdata.co/?ref=iplocation
https://ipdata.co/corrections.html
corrections  ipdata.co
working on adding geofeed support

IPIP
https://en.ipip.net/ip.html
sarah  ipip.net

IPHub
https://iphub.info/

IPinsight
https://ipinsight.io/
william  ipinsight.io

Info Sniper
https://infosniper.net/
https://infosniper.net/geoip-data-correction.php

GeoGuard
https://www.geocomply.com/products/geoguard/
ipintelligence  geoguard.com
More of a "are they using a VPN/hiding service" and not so much of a "Where are 
they" service.



From: NANOG  on behalf of Josh 
Luthman 
Sent: Thursday, April 21, 2022 9:24 AM
To: Rubens Kuhl
Cc: Nanog
Subject: Re: Geolocation data management practices?

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

Re: Ready to compromise? was RE: V6 still not supported

[Abraham Y. Chen]

Dear Pascal:

0) Thanks for your clarification. It enabled me to study your draft a 
little closer and came up with the following observations to share.


1)   "Yes, this is plain IP in IP. For a router does not know about 
YADA, this looks like the most basic form of tunnel you can get.":


    Not really. I believe that any networking stack conforming to the 
Options mechanism in RC791 can achieve the same, thus more concise and 
less involved. Please see Figure 4 of EzIP Draft.


https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space

2) " 1. 
Introduction 
and Motivation 
 
The proposed benefit is a thousandfold increase of the IPv4-addressable 
domain by building parallel realms each potentially the size of the 
current Internet.


"2.2. 
New 
Terms 
 


            This document often uses the following new terms:

 # IPv4 realm:

 # A full IPv4 network like the current Internet. YADA does not affect
   the traditional IPv4 operations within a realm.":

These are the critical statements that led to one of my two initial 
questions. That is, are you proposing to have N (>250 as an example 
cited in your draft) realms that each has the full IPv4 address pool 
capacity (after deducted for certain special functions)? This will be 
fine if each realm was occupying one floor of a stand-alone  skyscraper. 
I can not visualize this architecture when it is expanded to cover the 
whole earth, since each of them can operate with all the IPv4 addresses. 
Not only physically impossible to build such a skyscraper, but also how 
can we form 250 independent overlays on top of the entire IPv4 based 
Internet? Is there any mechanism that can isolate the respective 
transmission media of the 250 realms from one another?


3)    " 1. 
Introduction 
and Motivation 
 
 Connectivity between an IPv4-only node and an IPv6-only node, or 
between an IPv4-only node and a YADA node in different realm, still 
requires a CG-NATs as of today,  ":


Since eliminating the CG-NAT practice is one of the general motivations 
for address expansion efforts, I am puzzled by why are you still keeping 
it, and for how long? In contrast, upon the initial RAN (Regional Area 
Network) deployment, the CG-NAT will be retired from EzIP environment.


4)   "Figure 2 
: 
YADA format in the source realm 
 
YADA also requires a change for the routers that serve the shaft.":


    Are you saying that an IoT in a realm wishing to communicate with 
another in a separate realm does not need to know about this format nor 
something equivalent to convey such inter-realm address information?


5)   "Figure 4 
: 
YADA format inside the shaft 
 
":


This particular format closely resembles that of EzIP (see EzIP Draft 
Figure 4 mentioned above), where "outer IPv4 header" part of five words 
carrying the two realms' address information are conveyed by words 4 & 5 
of a standard IPv4 header, while the IoT (inner) addresses are 
transported by three Options words. The EzIP format enables the EzIP 
implementation to stay within the RFC791 specifications, no need to go 
beyond.


6) Below is my quick digest and comparison of our two projects by 
partially paraphrasing YADA terminology:


A.    Since there is no way to build a 250 floor skyscraper covering the 
entire globe for physical isolation between floors (realms), it is 
difficult to visualize how could the same IP address be used by 250 
separate parties as proposed by YADA without the fundamental address 
conflict issue. How to provide a medium that has 250 fully isolated 
layers, each capable of transporting the full set of IPv4 addresses, 
seems to be the challenge.


B.    The function of YADA format probably can be achieved by making use 
of the Options mechanism under RFC791, so that IP header can stay basic.


C.    The EzIP scheme is less capable than YADA, but much more concise 
and well-defined:


a.    Instead of multiple realms, each capable of full IPv4 addresses, 
EzIP works within only one set of IPv4 address pool.


b.    EzIP starts from only realm 1 which occupies a

Fall 2022 NANOG Registration Price Increase

[Edward McNair]

NANOG Community,

Due to rising costs, it has become necessary to increase registration fees. 
Beginning Monday, July 11, 2022, the price increase will go into effect. This 
will impact NANOG 86 and beyond. The new fee structure will be as follows: 

Member Pricing
 - Early: $675
 - Standard: $775
 - Late: $875
 - Onsite: $1075

Non-Member Pricing
 - Early: $700
 - Standard: $800
 - Late: $900
 - Onsite: $1100

Student Pricing
 - Early: $100
 - Standard: $100
 - Late: $100
 - Onsite: $100

Virtual Pricing
 - Standard: $100
 - Complementary: $0

We are committed to delivering a quality program and meeting experience for our 
community. We appreciate your understanding in this matter, and we look forward 
to your continued support and participation.

Sincerely,

Edward McNair
NANOG Executive Director

Re: Geolocation data management practices?

[Charles Polisher]

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 



RFC 5870: A Uniform Resource Identifier for Geographic Locations ('geo' 
URI) 


RFC 6288: URN Namespace for the Defence Geospatial Information Working 
Group (DGIWG) 


RFC 6397: Multi-Threaded Routing Toolkit (MRT) BGP Routing Information 
Export Format with Geo-Location Extensions 



RFC 6772: Geolocation Policy: A Document Format for Expressing Privacy 
Preferences for Location Information 



RFC 7942: The GeoJSON Format 

RFC 8142: GeoJSON Text Sequences 



RFC 8805: A Format for Self-Published IP Geolocation Feeds 



RFC 9092: Finding and Using Geofeed Data 



--
Charles Polisher
(/Pedantic, I?/)

Re: Geolocation data management practices?

[Josh Luthman]

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

Re: Geolocation data management practices?

[Rubens Kuhl]

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

Re: Geolocation data management practices?

[Job Snijders via NANOG]

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

Re: NXDOMAIN Resolvers

[Thomas Mieslinger]

There are public and commercial offerings for "DNS based protection".

e.g. 9.9.9.9 automatically generates NXDomains for suspected malicious
DNS Names even in their free service.

They have a page where you can check if you have been blacklisted (see
https://www.quad9.net/de/result)


On 4/20/22 11:07, Antonia Affinito wrote:

Good morning,
I am currently analysing the DNS resolvers (local and public ones) in
terms of protection and performance (in particular their speed).
I noticed that, in case of a malicious domain name, some local resolvers
send an NXDOMAIN and others a courtesy page address. Do you know if the
resolvers (for example TIM, Wind or Fastweb) can return an NXDomain in
order to protect their clients?

Thanks a lot


Mail priva di virus. www.avast.com



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Geolocation data management practices?

[Shawn]

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?

Direct fibre between Digital Realty ATL2 and Equinox AT1

[Stefan Funke]

Good morning NANOG!

I am looking for direct fiber providers between ATL2 and AT1, or 100g 
wavelengths. Any recommendations? Off-List replies are fine!


TIA,
-Stefan