Re: Adding GPS location to IPv6 header

Shane Amante <shane@castlepoint.net> Sun, 11 November 2012 17:08 UTC

Return-Path: <shane@castlepoint.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA1121F8578 for <ipv6@ietfa.amsl.com>; Sun, 11 Nov 2012 09:08:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOGLdCN8h76W for <ipv6@ietfa.amsl.com>; Sun, 11 Nov 2012 09:08:56 -0800 (PST)
Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4FE21F8564 for <ipv6@ietf.org>; Sun, 11 Nov 2012 09:08:56 -0800 (PST)
Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 8FCB120D6 for <ipv6@ietf.org>; Sun, 11 Nov 2012 17:08:55 +0000 (UTC)
Received: from mbp.castlepoint.net (174-29-211-99.hlrn.qwest.net [174.29.211.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 0019720C5; Sun, 11 Nov 2012 10:08:53 -0700 (MST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E54385E1-BE28-44C1-9CBC-3E927D8A899D"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Subject: Re: Adding GPS location to IPv6 header
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com>
Date: Sun, 11 Nov 2012 10:08:52 -0700
Message-Id: <0859AA2F-2972-4168-90DD-8A42B8C349C9@castlepoint.net>
References: <509e6d34.02d80e0a.51df.ffff9e7a@mx.google.com>
To: Ammar Salih <ammar.salih@auis.edu.iq>
X-Mailer: Apple Mail (2.1499)
X-DSPAM-Result: Innocent
X-DSPAM-Processed: Sun Nov 11 10:08:55 2012
X-DSPAM-Confidence: 1.0000
X-DSPAM-Improbability: 1 in 98689409 chance of being spam
X-DSPAM-Probability: 0.0023
X-DSPAM-Signature: 509fdba7199631273217742
X-DSPAM-Factors: 27, Information+#+#+#+Baghdad, 0.40000, Information+#+#+#+Baghdad, 0.40000, the+DNS, 0.40000, the+DNS, 0.40000, targeted+#+for, 0.40000, targeted+#+for, 0.40000, proof+#+the, 0.40000, proof+#+the, 0.40000, awareness+#+#+#+time, 0.40000, awareness+#+#+#+time, 0.40000, To*Ammar+Salih, 0.40000, salih+#+#+#+wrote, 0.40000, salih+#+#+#+wrote, 0.40000, suggests+#+#+#+as, 0.40000, suggests+#+#+#+as, 0.40000, configuration+#+#+#+geo, 0.40000, configuration+#+#+#+geo, 0.40000, depends+#+#+the, 0.40000, depends+#+#+the, 0.40000, targeted+#+the, 0.40000, targeted+#+the, 0.40000, city+#+#+do, 0.40000, city+#+#+do, 0.40000, not+#+#+#+layer, 0.40000, not+#+#+#+layer, 0.40000, able+#+#+the, 0.40000, able+#+#+the, 0.40000
Cc: geopriv@ietf.org, "ipv6@ietf.org List" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Nov 2012 17:08:58 -0000

Ammar,

Instead of adding GeoLoc information in an IPv6 Extension Header, you may wish to take a look at past & current attempts to *potentially* encode such information in the DNS.  The most recent proposal to do so is the following:
http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-03
Take a look at Appendix A for specific encoding examples that are possible within the DNS, with currently shipping BIND 9.  I base this on production deployment experience of encoding IP prefixes in the reverse DNS tree, as per draft-gersch, although *not* for geolocation information, but rather for SRO (Secure Route Origin) RR's.  If you're interested in draft-gersch-dnsop-revdns-cidr, it is targeted at the DNSOP WG of the IETF, so you may wish to subscribe to that mailing list and discuss it over there.

Lastly, I would note that the above complements RFC 1876 & RFC 2317 by providing a nomenclature for "better" encoding of VLSM (Variable Length Subnet Mask) IP prefixes in the reverse DNS tree.

-shane



On Nov 10, 2012, at 8:05 AM, Ammar Salih <ammar.salih@auis.edu.iq> wrote:
> Hello IETF, based on my discussions with both ipv6 and geopriv teams, I’ve written the below document to summarize few ideas.
> 
> Is it possible to publish this on IETF website? even if it will not be implemented now, at least for documentation and requesting feedback from the community.
> 
>  
> 
> Many thanks.
> 
> Ammar
> 
>  
> 
>  
> 
> Ammar J. Salih
> Baghdad, Iraq          
> October 30, 2012
> Title: IP-LOC
>  
>  
>                      
> Adding GPS location to IPv6 header
>  
> Abstract:
> =========
>  
>    This document describes IP-LOC, an extension to IPv6 header which suggests adding GPS coordinates, as the current method of determining the location of IP traffic is through IP address registration database, which is not very accurate as it depends on how the ISP registers its IP subnets, that is normally done in a country/city format.
>  
> It also assumes that in the future, GPS capability will be added to the router itself (just like smart phones) and packet marking and classification based on geo-location will be required.
>  
> QoS, firewall and routing based on geo-location will be highly required when mobile routers move from one geo-location to another which has different policy.
>  
>  
>  
>  
>  
> Benefits of adding GPS location to IPv6 header (IP-LOC)
> =======================================================
>  
>  
> Web Services: getting more accurate locations will enhance many services provided by the web, like targeted commercials (for example, I can get Ads regarding restaurants available in my neighborhoods instead of all restaurants in the city), another good example would be webpage’s language, my language will be detected more accurately based on my area rather than my country, as there are many countries with more than one popular language, not mentioning that many ip registrations does not even reflect the traffic originating country.
> 
> -------------------------------
>  
> Information accuracy and control: Nowadays, locations are assigned to IP addresses without user awareness or control, every time a user performs ip-lookup query the response would be different based on how the ISP has registered this IP subnet, IP-LOC suggests making locations more accurate and controllable through OS and network devices, exactly like IP addresses (user can change his/her IP address, but router can also modify the header information - in case it's required).
> 
> -------------------------------
>  
> 
> Routing: Policy based routing, based on geo-location, like routing predefined traffic through certain server or path, for different purposes (security, manageability, serviceability like choosing language, or routing traffic to specific cashing or proxy server based on country .. etc)
> 
> -------------------------------
>  
> 
> Copyright law: It happens when certain media/web content is not allowed in certain countries due to copyright law, the current method of determining locations is not accurate at all, on other hand, If layer-7 application to be used then the user might be able to manipulate the location field, in this case (if it’s required in future) the ISP can tag traffic with country/city more accurately as traffic passes through ISP’s boarder routers.
> 
> -------------------------------
>  
> Maps, navigation, emergency calls and many other services will be also enhanced with accurate locations.
>  
>  
>  
>  
> 
> CURRENT ARGUMENTS AGAINST THIS IDEA:
> ========================================
> 
> “Adding GPS position to every IPv6 header would add a lot of overhead”
>  
> Response: It does not have to be in every IPv6 header, only when there is location update, also the host should have the option of not to send location updates.
>  
> -------------------------------
>  
> “What about privacy?”
>  
> Response: User should have the option of not sending location updates. User should also have the ability to set location to all zeros, in this case no router will modify the location field and user loses the location-based services.
>  
> If it’s router-to-router link, then no need to be worried about privacy as such information usually configured on a separate network.
>  
> --------------------------------
>  
> “a good alternative would be to create application layer protocols that could request and send GPS positions”
>  
> Response: the layer-7 location request will not be detected by layer-3 devices (Routers), I am assuming that in the future, GPS capability will be added to the router itself (just like smart phones), features like packet marking and classification based on geo-location will be required to enforce the new geo-location policies.
>  
> --------------------------------
>  
> “For location-based routing protocols: Why would you want this?  Geographical location isn't actually that important a metric for routing; what you care about there is *topological* location, how far I am away from you in terms of hops or latency”
>  
> Response: For shortest path maybe yes, hops or latency is important, not for policy-based routing, in our case you might want to do location-based routing, like, routing traffic coming from French speaking users (in multi-language country like Canada) to google.fr
>  
> ---------------------------------
>  
> “For geolocation-based ACLs: you have the problem that if the geolocation is attached by the endpoint, then it can't be trusted, since the endpoint would lie to get past the ACL.  If it's attached by a router, the ACL needs to have proof that the router attached it (and not the endpoint), which means that you would need a signed geolocation header”
>  
> Response: You could have the router modify the location field anyways, just like L3 QoS fields, if you don't trust the host, so no need for encryption or security, additionally,  ACL is not only for security, it could be used for routing, QoS ..etc, so the host will not always has the motivation to manipulate the location field.
>  
> ---------------------------------
>  
> “Why can’t you simply implement rules related to geo-locations statically on the network device (router, firewall .. etc)?”
>  
> Response: To enforce new geo-location policies automatically, let’s assume that a mobile router (like a mobile BTS in a GSM network) moved from city-x to city-y, and according to city-x regulations VoIP calls over GSM network is allowed, but city-y regulations do not allow that. Now the topology may reflect same network metrics in both cities but there is no rule that triggers configuration change based on geo-location.
>  
> 
> ---------------------------------
>  
> 
>  
> What do you think?
>  
>  
> Author/Contact Information:
>  
>    Ammar J. Salih
>    Baghdad, Iraq
>  
>    Phone: +964 770 533 0306
>    Email: ammar.alsalih@gmail.com
>  
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------