Re: wireless geolocation

Ted Lemon <mellon@fugue.com> Tue, 06 June 2017 16:56 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9C7129AF3 for <ietf@ietfa.amsl.com>; Tue, 6 Jun 2017 09:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuosyHz8L5FI for <ietf@ietfa.amsl.com>; Tue, 6 Jun 2017 09:55:58 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA48129B0D for <ietf@ietf.org>; Tue, 6 Jun 2017 09:55:57 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id c10so82365465qtd.1 for <ietf@ietf.org>; Tue, 06 Jun 2017 09:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kVvYMIBQc/4BFBLLNHIWM6kR0vLqwqqkf+fcmgss/dg=; b=LZEc21C0kvLIP3IWOqiBo6umih8ek6Ld2cdrcAkcEEoKnsjMrcxKacq2Xkdk6u/TUm 5WjBrx1WevTEkzSuutLzB5rPRS77lGxRUoQBARb2EOTST1p9tORyBWatsNSkplnV6IOC 8n0prFa5hO+rJ246+ALdr6iec1rYu1lLCDUXKVgiKeMD62+T5bI812LbBq2A4+8rYnqX k64qx5sbTvGsjq0H+L3lcRrlyfJjOE+TXoNSz94DO23MnasLIAhbSSU76mQ865572KFD TTNzHScZUn5dukTwrGPJ93NNTRNmAp6a7HqRlckA/6xH9nBat+Zsq0AmMFgHkqZehsNc Nbmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kVvYMIBQc/4BFBLLNHIWM6kR0vLqwqqkf+fcmgss/dg=; b=p7+4XwB4LYwrxhjdfxbuKksu57aUCy8/BU4SqYOuDY1DxOMalnYqEUOWGSl+emFnmh GFP/yyBrmbXDl0pPgWba0wjc+D98NEnRmYv8AgQT9ceLKH63kc6FzwL4VP6oy4Lwr8ns 1q0tV/BYJ/ZR5//Hg3hdAhgDiJSaGxynRbMZuV/YkSEhvVNiiupSugChssZ/KeC9lPaN R3bBRENXnqprvlC7+OENVT9mTgztXFLKxarmKC6iYhaY7la8Uhem6S5Z/VeMHhIE8lHY CRe294p7/6c4RIhu3N5pmnoREaS5zpnvGX9XUFNqaxj1f3cp9rpK5afwUrcV7yRKNX81 DU5A==
X-Gm-Message-State: AODbwcCc6veHii7yerZ4J3DkbmBQmnzHIkjJYI7PRg84unv4whqHbPwt 5D6dtQKuB9apAALMjdC6nQ==
X-Received: by 10.200.45.83 with SMTP id o19mr25250803qta.43.1496768156616; Tue, 06 Jun 2017 09:55:56 -0700 (PDT)
Received: from [10.0.30.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id t13sm8807771qtc.22.2017.06.06.09.55.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 09:55:55 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <6E9EEE15-1A71-485C-9321-4068AB39AE0F@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1B4F366-C542-4E1B-ACBB-8404A1592F35"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: wireless geolocation
Date: Tue, 06 Jun 2017 12:55:54 -0400
In-Reply-To: <CAHw9_iKpKJA4ruNSR=Zq3ocu7ORwHVrNCnF3H0LJqDL5FrPMuA@mail.gmail.com>
Cc: Randy Bush <randy@psg.com>, IETF Rinse Repeat <ietf@ietf.org>
To: Warren Kumari <warren@kumari.net>
References: <m27f0pqgbc.wl-randy@psg.com> <50E30AF8-6D05-4698-AC71-70A0179F703E@fugue.com> <CAHw9_iKpKJA4ruNSR=Zq3ocu7ORwHVrNCnF3H0LJqDL5FrPMuA@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/nX9deLT_93fGTOE9LnTcxDedWUM>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jun 2017 16:56:00 -0000

On Jun 6, 2017, at 12:48 PM, Warren Kumari <warren@kumari.net> wrote:
> Because we use a *large* amount of address space - we (currently) give
> everyone a public IP address, we have multiple SSIDs / networks, etc.
> ISPs would be quite unlikely to be willing to give us a big enough
> block, we (often) also have multiple providers, etc. We would also
> need to renumber all of our infrastructure, redo DNS, etc.

Please understand when I say this that I am not proposing an unfunded mandate on the backs of volunteers here, but (a) it doesn't seem to me that we need to continue providing everyone with a routable IPv4 address, and (b) if renumbering is that hard, maybe that's worth thinking about, because renumbering is not generally all that hard, and we have developed a lot of technology in the IETF to _make_ it not hard.

E.g., if everything is numbered using IPv6, and the reason it needs numbered is so that it can be managed, wouldn't a ULA prefix for numbering managed devices solve that problem?   Or are we still managing them using stone knives and IPv4?

> We currently publish geo-location info in
> https://tools.ietf.org/html/draft-google-self-published-geofeeds-02 <https://tools.ietf.org/html/draft-google-self-published-geofeeds-02>
> format -- noc.ietf.org/geo/google.csv <http://noc.ietf.org/geo/google.csv>. This gets updated (assuming I /
> we don't forget :-)) before each meeting, and should be imported by
> google in advance of the meeting...

Apparently that's not solving the problem, though.   Google maps always seems to redirect me to the previous country, every IETF.   I think this is more of an operational problem than not having a routable IPv4 address would be—I don't assume when I'm traveling that I will have a routable IPv4 address.

> But, much of the issue is location being tied to the MAC address of
> the APs, not just the source IP. There are lots of geo providers, and
> they all need to be updated, etc.

Can't APs have their user-facing MAC addresses changed/randomized?   Again, I realize that that potentially another unfunded mandate, but I'm just asking whether this is something that can be done, not saying you should do it.