Subject: [100attendees] Incorrect GeoIP for IETF network addresses

From: Darshak Thakore <[email-masked]>
Date: Mon, 13 Nov 2017 02:34:45 +0000

Hi all,

Is there a way to update the geoIP that the IETF IP addresses resolve to? I’ve been seeing this behavior for the past few IETF’s where on google maps (or on bing maps for that matter) in a browser, when I allow geo-location (while connected to the IETF* networks) it always resolves to the previous IETF venue. So today when I click “Your location” button on google maps, it shows that I’m at Hilton Prague and when I was in Prague, it showed me Chicago (and so on)

Just wanted to know if there’s something I/we can do to make it resolve to the right venue

Darshak

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Mon, 13 Nov 2017 10:38:41 +0800

Oh, behold the joys of the opaque world of GeoIP.

I don’t think there is a “magic” way of updating all GeoIP 
databases.

On 13 Nov 2017, at 10:34, Darshak Thakore wrote:

> Hi all,
>
> Is there a way to update the geoIP that the IETF IP addresses resolve 
> to? I’ve been seeing this behavior for the past few IETF’s where 
> on google maps (or on bing maps for that matter) in a browser, when I 
> allow geo-location (while connected to the IETF* networks) it always 
> resolves to the previous IETF venue. So today when I click “Your 
> location” button on google maps, it shows that I’m at Hilton 
> Prague and when I was in Prague, it showed me Chicago (and so on)
>

> _______________________________________________
> 100attendees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/100attendees

---

From: Jim Martin <[email-masked]>
Date: Mon, 13 Nov 2017 10:41:38 +0800

Darshak,
	This is a sadly complicated issue. There is no geolocation standard, so it’s a matter of trying to update the various organizations that provide geolocation services. We work closely with Google, and  try to work with SkyHook (the geolocation that Apple uses for BSSID based location) and MaxMind (a common location provider). Unfortunately, these are a bit hit or miss, as they’re not really setup for a non-trivial network to move around the world. We continue to work on it, and are always open to help, if anyone has suggestions. 

	BTW: In terms of google maps, it “works for me” on my Mac using Safari right now. Swing by the NOC in Indiana if you get the chance so we can try to understand the differences in results. Thanks!

	-Jim

> On Nov 13, 2017, at 10:34 AM, Darshak Thakore <[email-masked]> wrote:
> 
> Hi all,
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/100attendees <https://www.ietf.org/mailman/listinfo/100attendees>

---

From: Chris Morrow <[email-masked]>
Date: Mon, 13 Nov 2017 02:43:57 +0000

On Mon, Nov 13, 2017 at 1:35 PM Darshak Thakore <[email-masked]>
wrote:

> Hi all,
>
>
>
> Is there a way to update the geoIP that the IETF IP addresses resolve to?
> I’ve been seeing this behavior for the past few IETF’s where on google maps
> (or on bing maps for that matter) in a browser, when I allow geo-location
> (while connected to the IETF* networks) it always resolves to the previous
> IETF venue. So today when I click “Your location” button on google maps, it
> shows that I’m at Hilton Prague and when I was in Prague, it showed me
> Chicago (and so on)
>
>
>
> When I open an incognito browser (with no profile, a fresh browser
instance) I see singapore in 'https://maps.google.com'.
When I open https://maps.bing.com in the same browser instance I see:
Atlanta, GA (an ietf was there... a very long time ago?)
When I open https://maps.yahoo.com I get some search results and a map in
there of Dallas, TX.

My android phone's 'maps' application shows me local/Singapore locations
while inside the hotel... It thinks I'm near the
carlton/mint-museum/raffles-hotel... so it's close enough?

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Nov 2017 10:44:06 +0800

On Mon, Nov 13, 2017 at 10:34 AM, Darshak Thakore
<[email-masked]> wrote:
> IETF venue.

So, this is a long, and ongoing problem -- there are many geo-location
databases, and getting all of them updated is hard.
Erik Kline wrote a document which helps with this --
https://tools.ietf.org/html/draft-google-self-published-geofeeds-02
and the IETF has published these...

Also, many of the geo solutions also include stuff like the BSSID /
MAC address of the radio you are connected to...

>  So today when I click “Your location” button on google maps, it

So, thi time we thought we got this right for Google / Google Maps at
least -- for me / other people who have tried this it seems to finally
believe that we are were, er, we are...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Bob Hinden <[email-masked]>
Date: Mon, 13 Nov 2017 10:45:14 +0800

Darshak,

> Is there a way to update the geoIP that the IETF IP addresses resolve to? I’ve been seeing this behavior for the past few IETF’s where on google maps (or on bing maps for that matter) in a browser,…

When I do the same, it shows my location in Singapore.  I am using Safari on MacOS 10.12 over IPv6.

Bob

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 Nov 2017 02:52:01 +0000

I’ve also pursued this with another providers which used the “sightings” of BSSIDs and cell signals and how they handle updates, when I moved a portable cell spot.  The issue turned out to be that it requires:

  *   GPS-enabled clients to report the new location in sufficient volume to cause the service to reconsider the location
  *   The service-side database to be updated
  *   Clients to age out their cache of the previous location of the BSSID/cell.

As a result, the expected time for clients to see the new location was 10-15 days, by which point we won’t be here any more.

From: 100attendees [mailto:[email-masked]] On Behalf Of Jim Martin
Sent: Monday, November 13, 2017 10:42 AM
To: Darshak Thakore <[email-masked]>
Cc: [email-masked]
Subject: Re: [100attendees] Incorrect GeoIP for IETF network addresses

Darshak,

              -Jim

On Nov 13, 2017, at 10:34 AM, Darshak Thakore <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Darshak
_______________________________________________
100attendees mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/100attendees

---

From: Darshak Thakore <[email-masked]>
Date: Mon, 13 Nov 2017 03:00:03 +0000

Thanks all for the feedback
So here are the results of my experiment

1. Google Chrome (logged into my google profile) - Just going to maps.google.com takes me to www.google.com.sg/maps (which is expected) and shows me Singapore location and the “My Location” button shows that it acquired my location from my phone history (I have a pixel connected to the same account). However clicking on the button takes me to Hilton Prague
2. Google Chrome Incognito – Takes me to google.com.sg but clicking on “My Location” takes me to Hilton Prague
3. Firefox (logged into my google account) – Same behavior as Chrome – clicking “My Location” takes me to Prague
4. Firefox Incognito – Takes me to Prague
5. Safari – going to maps.google.com takes me to google.com.sg/maps AND clicking on Location, it actually seems to work right

Jim, I’ll swing by the NOC in Indiana shortly to see if can collect some data points

Darshak

On 11/12/17, 7:44 PM, "Warren Kumari" <[email-masked]> wrote:

    CableLabs WARNING: The sender of this email could not be validated and may not match the person in the "From" field.

    

    
    W

---

From: Michal Krsek <[email-masked]>
Date: Mon, 13 Nov 2017 11:08:34 +0800

One of part solutions is to signal "ignore this BSSID" to GeoIP 
provider. Possible IETF agenda?

                 Michal

On 13/11/2017 10:52, Mike Bishop wrote:
>
> I’ve also pursued this with another providers which used the 
> “sightings” of BSSIDs and cell signals and how they handle updates, 
> when I moved a portable cell spot.  The issue turned out to be that it 
> requires:
>
>   * GPS-enabled clients to report the new location in sufficient
>     volume to cause the service to reconsider the location
> As a result, the expected time for clients to see the new location was 
> 10-15 days, by which point we won’t be here any more.
>
> *From:* 100attendees [mailto:[email-masked]] *On Behalf 
> Of *Jim Martin
> *Sent:* Monday, November 13, 2017 10:42 AM
> *To:* Darshak Thakore <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [100attendees] Incorrect GeoIP for IETF network addresses
>
> Darshak,
>
> This is a sadly complicated issue. There is no geolocation standard, 
> so it’s a matter of trying to update the various organizations that 
> provide geolocation services. We work closely with Google, and  try to 
> work with SkyHook (the geolocation that Apple uses for BSSID based 
> location) and MaxMind (a common location provider). Unfortunately, 
> these are a bit hit or miss, as they’re not really setup for a 
> non-trivial network to move around the world. We continue to work on 
> it, and are always open to help, if anyone has suggestions.
>
> BTW: In terms of google maps, it “works for me” on my Mac using Safari 
> right now. Swing by the NOC in Indiana if you get the chance so we can 
> try to understand the differences in results. Thanks!
>
> -Jim
>
>
>
>     On Nov 13, 2017, at 10:34 AM, Darshak Thakore
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     Is there a way to update the geoIP that the IETF IP addresses
>     resolve to? I’ve been seeing this behavior for the past few IETF’s
>     where on google maps (or on bing maps for that matter) in a
>     browser, when I allow geo-location (while connected to the IETF*
>     networks) it always resolves to the previous IETF venue. So today
>     when I click “Your location” button on google maps, it shows that
>     I’m at Hilton Prague and when I was in Prague, it showed me
>     Chicago (and so on)
>

---

From: Chris Morrow <[email-masked]>
Date: Mon, 13 Nov 2017 03:10:45 +0000

On Mon, Nov 13, 2017 at 2:09 PM Michal Krsek <[email-masked]> wrote:

> One of part solutions is to signal "ignore this BSSID" to GeoIP provider.
> Possible IETF agenda?
>
>
that's done (for several meetings now), at least for google's maps/etc. yes.

> I’ve also pursued this with another providers which used the “sightings”
> of BSSIDs and cell signals and how they handle updates, when I moved a
> portable cell spot.  The issue turned out to be that it requires:
>
>    - GPS-enabled clients to report the new location in sufficient volume
>    to cause the service to reconsider the location
>    - The service-side database to be updated
>    - Clients to age out their cache of the previous location of the
>    BSSID/cell.
>
>
>
> *From:* 100attendees [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Jim Martin
> *To:* Darshak Thakore <[email-masked]> <[email-masked]>
>               This is a sadly complicated issue. There is no geolocation
> standard, so it’s a matter of trying to update the various organizations
> that provide geolocation services. We work closely with Google, and  try to
> location) and MaxMind (a common location provider). Unfortunately, these
> are a bit hit or miss, as they’re not really setup for a non-trivial
> network to move around the world. We continue to work on it, and are always
> open to help, if anyone has suggestions.
>
>
>
>               BTW: In terms of google maps, it “works for me” on my Mac
> using Safari right now. Swing by the NOC in Indiana if you get the chance
> so we can try to understand the differences in results. Thanks!
>
>
>
>               -Jim
>
>
>
>
>
> 100attendees mailing [email-masked]://www.ietf.org/mailman/listinfo/100attendees
>
>

---

From: Chris Morrow <[email-masked]>
Date: Mon, 13 Nov 2017 03:11:06 +0000

On Mon, Nov 13, 2017 at 2:00 PM Darshak Thakore <[email-masked]>
wrote:

> 1. Google Chrome (logged into my google profile) - Just going to
> maps.google.com takes me to www.google.com.sg/maps (which is expected)
> and shows me Singapore location and the “My Location” button shows that it
> acquired my location from my phone history (I have a pixel connected to the
> same account). However clicking on the button takes me to Hilton Prague
> 3. Firefox (logged into my google account) – Same behavior as Chrome –
> clicking “My Location” takes me to Prague
> 5. Safari – going to maps.google.com takes me to google.com.sg/maps AND
> clicking on Location, it actually seems to work right
>
>
all of the above is odd, I'd be happy to see your tests (in the noc).

>     CableLabs WARNING: The sender of this email could not be validated and
> may not match the person in the "From" field.
>
> resolve to?
>     > Just wanted to know if there’s something I/we can do to make it
> resolve to
>     > the right venue
>     >
>     >
>     >
>     > Darshak
>     >
>     >

---

From: Alexandre PETRESCU <[email-masked]>
Date: Mon, 13 Nov 2017 04:12:39 +0100

Le 13/11/2017 à 03:43, Chris Morrow a écrit :
>
>
>
> On Mon, Nov 13, 2017 at 1:35 PM Darshak Thakore 
>     resolve to the right venue
>
>
> When I open https://maps.yahoo.com I get some search results and a map 
> in there of Dallas, TX.
>
> My android phone's 'maps' application shows me local/Singapore 
> locations while inside the hotel... It thinks I'm near the 

I wonder why this happens this way.

It seems like a database is updated too late, or that there is latency 
between update and visibility.

It is the as if the DNS were updated towards a fixed prefix that IETF 
meetings would carry wherever it moves.

But I am not sure IETF meetings use same IP addresses wherever the 
meeting moves?

Is the IPv6 DNS resolver address constant at IETF meetings?

Alex

---

From: Chris Morrow <[email-masked]>
Date: Mon, 13 Nov 2017 03:16:09 +0000

> I wonder why this happens this way.
{reasons}

> between update and visibility.
my example has the process working though?

> meetings would carry wherever it moves.
I'm not sure that DNS matters quite yet though?
The ip prefix the IETF network uses is the same (both v4 and v6) for each
meeting.

> But I am not sure IETF meetings use same IP addresses wherever the meeting
> moves?
>
>
we do.

> Is the IPv6 DNS resolver address constant at IETF meetings?
the resolvers are the same, yes.

---

From: Alexandre PETRESCU <[email-masked]>
Date: Mon, 13 Nov 2017 04:19:32 +0100

> provider. Possible IETF agenda?

IETF has a number of things on geography and IP.

'geonet' was a BoF 4 or 5 years ago.

GeoPriv and GeoJSON was and is WG respectively.

For BSSID: the MAC-to-coordinates mappings dont deserve much 
consideration IMHO, as it's not IP.

Wireshark setting 'GeoIP' fields is something non-standardised that 
should not be trusted.  IT may say "Alaska" but it should not be taken 
seriously.

Alex

>> when I moved a portable cell spot.  The issue turned out to be that 
>> it requires:
>>
>> As a result, the expected time for clients to see the new location 
>> was 10-15 days, by which point we won’t be here any more.
>>
>> *From:* 100attendees [mailto:[email-masked]] *On 
>> Behalf Of *Jim Martin
>> provide geolocation services. We work closely with Google, and  try 
>> to work with SkyHook (the geolocation that Apple uses for BSSID based 
>> BTW: In terms of google maps, it “works for me” on my Mac using 
>> Safari right now. Swing by the NOC in Indiana if you get the chance 
>>     resolve to? I’ve been seeing this behavior for the past few
>>     IETF’s where on google maps (or on bing maps for that matter) in
>>     a browser, when I allow geo-location (while connected to the
>>     IETF* networks) it always resolves to the previous IETF venue. So
>>     today when I click “Your location” button on google maps, it
>>     shows that I’m at Hilton Prague and when I was in Prague, it
>>     showed me Chicago (and so on)
>>

---

From: Darshak Thakore <[email-masked]>
Date: Mon, 13 Nov 2017 03:33:17 +0000

I can swing by NOC at 12, as soon as we have the lunch break.

Darshak

From: Chris Morrow <[email-masked]>
Date: Sunday, November 12, 2017 at 8:11 PM
To: Darshak Thakore <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [100attendees] Incorrect GeoIP for IETF network addresses

On Mon, Nov 13, 2017 at 2:00 PM Darshak Thakore <[email-masked]<mailto:[email-masked]>> wrote:
Thanks all for the feedback
So here are the results of my experiment

1. Google Chrome (logged into my google profile) - Just going to maps.google.com<http://maps.google.com> takes me to www.google.com.sg/maps<http://www.google.com.sg/maps> (which is expected) and shows me Singapore location and the “My Location” button shows that it acquired my location from my phone history (I have a pixel connected to the same account). However clicking on the button takes me to Hilton Prague
2. Google Chrome Incognito – Takes me to google.com.sg<http://google.com.sg> but clicking on “My Location” takes me to Hilton Prague
3. Firefox (logged into my google account) – Same behavior as Chrome – clicking “My Location” takes me to Prague
4. Firefox Incognito – Takes me to Prague
5. Safari – going to maps.google.com<http://maps.google.com> takes me to google.com.sg/maps<http://google.com.sg/maps> AND clicking on Location, it actually seems to work right

Darshak

On 11/12/17, 7:44 PM, "Warren Kumari" <[email-masked]<mailto:[email-masked]>> wrote:

    W

---

From: Michal Krsek <[email-masked]>
Date: Mon, 13 Nov 2017 11:34:27 +0800

Hi Alex,

> consideration IMHO, as it's not IP.

Sorry for my shortcut:

BSSID is not on IP level, on the other hand, APs are being (most likely) 
connected to the IP network. And the IP network operator may signal to 
the devices that this is a "mobile" network. Not proposing any 
particular protocol here for now.

> should not be trusted.  IT may say "Alaska" but it should not be taken 

There are other non-standard ways, how to handle it (like call to your 
friend that works for MaxMind).

Michal

>>> to work with SkyHook (the geolocation that Apple uses for BSSID 
>>> based location) and MaxMind (a common location provider). 
>>> Unfortunately, these are a bit hit or miss, as they’re not really 
>>> setup for a non-trivial network to move around the world. We 
>>> continue to work on it, and are always open to help, if anyone has 
>>> suggestions.
>>>
>>>     IETF* networks) it always resolves to the previous IETF venue.

---

From: Alexandre PETRESCU <[email-masked]>
Date: Mon, 13 Nov 2017 04:39:29 +0100

Le 13/11/2017 à 04:16, Chris Morrow a écrit :
>
>
>
> On Mon, Nov 13, 2017 at 2:12 PM Alexandre PETRESCU 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>>         IETF’s where on google maps (or on bing maps for that matter)
>>         in a browser, when I allow geo-location (while connected to
>>         the IETF* networks) it always resolves to the previous IETF
>>         venue. So today when I click “Your location” button on google
>>         maps, it shows that I’m at Hilton Prague and when I was in
>>         Prague, it showed me Chicago (and so on)
>>
>>     When I open an incognito browser (with no profile, a fresh
>>     browser instance) I see singapore in 'https://maps.google.com'.
>>     When I open https://maps.bing.com in the same browser instance I
>>     see: Atlanta, GA (an ietf was there... a very long time ago?)
>>     When I open https://maps.yahoo.com I get some search results and
>>     a map in there of Dallas, TX.
>>

It's good to know that it's known why it happens.

>     It seems like a database is updated too late, or that there is
>     latency between update and visibility.
>
>
>     It is the as if the DNS were updated towards a fixed prefix that
>     IETF meetings would carry wherever it moves.
>
>
> The ip prefix the IETF network uses is the same (both v4 and v6) for 
> each meeting.
>

Ah, that could be part of the reasons then.  I suppose then there is 
tunnelling between Singapore and the home of these constant IP addreses.

For that to work one would need the IP-to-coordinates converters to 
consider also tunnelling - these quantum leaps between worlds, these VPN 
gateways tresspassing country legislation on content delivery, etc.

Or one would need to update the IP routes in the Internet whenever IETF 
moves.  It is possible.

Or update the LOC entries in DNS (if LOC entries are used).  It is also 
possible.

Just some speculation...

Alex

---

From: Jim Martin <[email-masked]>
Date: Mon, 13 Nov 2017 11:48:38 +0800

> On Nov 13, 2017, at 11:39 AM, Alexandre PETRESCU <[email-masked]> wrote:
> 
> Ah, that could be part of the reasons then.  I suppose then there is tunnelling between Singapore and the home of these constant IP addreses.

	There’s no tunneling as part of the infrastructure of the IETF network. We have the several address blocks that we advertise from our own AS each time, this time via 4 upstream providers. The servers are at the same addresses for each meeting.

	-Jim

---

From: Alexandre PETRESCU <[email-masked]>
Date: Mon, 13 Nov 2017 05:02:13 +0100

Le 13/11/2017 à 04:34, Michal Krsek a écrit :
> BSSID is not on IP level, 

BSSID - Basic Service Set ID, is a 48bit value, very much similar to MAC 
addresses.  On an AP you have a 48bit BSSID, a 48bit MAC on the WiFi 
interface and a 48bit MAC on its Ethernet interface.  The 3 are 
distinct.  One would need to map the three to coordinates.  Some map 
just the BSSID, or just the Network Name, often known as ESSID which is 
yet another value.  Sometime the Network Name is hidden, you want it 
hidden, cant reveal.

All these things are not IP.

> on the other hand, APs are being (most likely) connected to the IP 
> network. And the IP network operator may signal to the devices that 
> this is a "mobile" network. Not proposing any particular protocol here 
> for now.
>
>> should not be trusted.  IT may say "Alaska" but it should not be 
>> taken seriously.
>

'Out-of-band' means :-)

Alex

---

From: Michal Krsek <[email-masked]>
Date: Mon, 13 Nov 2017 14:59:03 +0800

Hi,

> BSSID - Basic Service Set ID, is a 48bit value, very much similar to 
> MAC addresses.  On an AP you have a 48bit BSSID, a 48bit MAC on the 
> WiFi interface and a 48bit MAC on its Ethernet interface.  The 3 are 
> just the BSSID, or just the Network Name, often known as ESSID which 
> is yet another value.  Sometime the Network Name is hidden, you want 
> it hidden, cant reveal.
>

they are not, but you can tell (over IP) to the client that GeoIP 
resolution based on underlying information is not producing relevant 
information.

Those clients DO IP communication with some GeoIP vendors.

Or, do we still need to work on human interraction, e.g. bringing GeoIP 
people to the bar, order them a few drinks and give them (under the 
table) small piece of dirty paper that shows them BSSID of "mobile APs" 
? Imagine that every car has AP functionality. GeoIP people will become 
permanently drunk.

Micahl

---

From: joel jaeggli <[email-masked]>
Date: Mon, 13 Nov 2017 16:14:23 +0800

> between update and visibility.

Entities which employ the maxmind free dataset get access to quarterly
updates.