Re: Adding GPS location to IPv6 header

Ammar,

On Nov 10, 2012, at 10:05 AM, Ammar Salih wrote:

> Hello IETF, based on my discussions with both ipv6 and geopriv teams, I=
=92ve written the below document to summarize few ideas.
> =

> Is it possible to publish this on IETF website? even if it will not be im=
plemented now, at least for documentation and requesting feedback from the =
community.

The best procedure for presenting new ideas to the IETF is to write an Inte=
rnet Draft.

Suggest you take a look at the IETF web site at http://www.ietf.org.  Espec=
ially:

  Getting started in the IETF:  http://www.ietf.org/newcomers.html  =

  The Tao of IETF:  http://www.ietf.org/tao.html
  Procedures to submit an Internet Draft:  http://www.ietf.org/id-info/

Regards,
Bob

  =

> =

>  =

> =

> Many thanks.
> =

> Ammar
> =

>  =

> =

>  =

> =

> Ammar J. Salih
> Baghdad, Iraq          =

> October 30, 2012
> Title: IP-LOC
>  =

>  =

>                      =

> Adding GPS location to IPv6 header
>  =

> Abstract:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>  =

>    This document describes IP-LOC, an extension to IPv6 header which sugg=
ests adding GPS coordinates, as the current method of determining the locat=
ion 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 r=
outer 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 w=
hen mobile routers move from one geo-location to another which has differen=
t policy.
>  =

>  =

>  =

>  =

>  =

> Benefits of adding GPS location to IPv6 header (IP-LOC)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
>  =

>  =

> 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 restaura=
nts in the city), another good example would be webpage=92s language, my la=
nguage will be detected more accurately based on my area rather than my cou=
ntry, as there are many countries with more than one popular language, not =
mentioning that many ip registrations does not even reflect the traffic ori=
ginating 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 regis=
tered this IP subnet, IP-LOC suggests making locations more accurate and co=
ntrollable through OS and network devices, exactly like IP addresses (user =
can change his/her IP address, but router can also modify the header inform=
ation - in case it's required).
> =

> -------------------------------
>  =

> =

> Routing: Policy based routing, based on geo-location, like routing predef=
ined traffic through certain server or path, for different purposes (securi=
ty, manageability, serviceability like choosing language, or routing traffi=
c to specific cashing or proxy server based on country .. etc)
> =

> -------------------------------
>  =

> =

> Copyright law: It happens when certain media/web content is not allowed i=
n 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 t=
his case (if it=92s required in future) the ISP can tag traffic with countr=
y/city more accurately as traffic passes through ISP=92s boarder routers.
> =

> -------------------------------
>  =

> Maps, navigation, emergency calls and many other services will be also en=
hanced with accurate locations.
>  =

>  =

>  =

>  =

> =

> CURRENT ARGUMENTS AGAINST THIS IDEA:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> =

> =93Adding GPS position to every IPv6 header would add a lot of overhead=
=94
>  =

> 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 locat=
ion updates.
>  =

> -------------------------------
>  =

> =93What about privacy?=94
>  =

> Response: User should have the option of not sending location updates. Us=
er 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=92s router-to-router link, then no need to be worried about privacy=
 as such information usually configured on a separate network.
>  =

> --------------------------------
>  =

> =93a good alternative would be to create application layer protocols that=
 could request and send GPS positions=94
>  =

> Response: the layer-7 location request will not be detected by layer-3 de=
vices (Routers), I am assuming that in the future, GPS capability will be a=
dded to the router itself (just like smart phones), features like packet ma=
rking and classification based on geo-location will be required to enforce =
the new geo-location policies.
>  =

> --------------------------------
>  =

> =93For location-based routing protocols: Why would you want this?  Geogra=
phical location isn't actually that important a metric for routing; what yo=
u care about there is *topological* location, how far I am away from you in=
 terms of hops or latency=94
>  =

> 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 r=
outing, like, routing traffic coming from French speaking users (in multi-l=
anguage country like Canada) to google.fr
>  =

> ---------------------------------
>  =

> =93For geolocation-based ACLs: you have the problem that if the geolocati=
on is attached by the endpoint, then it can't be trusted, since the endpoin=
t would lie to get past the ACL.  If it's attached by a router, the ACL nee=
ds to have proof that the router attached it (and not the endpoint), which =
means that you would need a signed geolocation header=94
>  =

> Response: You could have the router modify the location field anyways, ju=
st like L3 QoS fields, if you don't trust the host, so no need for encrypti=
on or security, additionally,  ACL is not only for security, it could be us=
ed for routing, QoS ..etc, so the host will not always has the motivation t=
o manipulate the location field.
>  =

> ---------------------------------
>  =

> =93Why can=92t you simply implement rules related to geo-locations static=
ally on the network device (router, firewall .. etc)?=94
>  =

> Response: To enforce new geo-location policies automatically, let=92s ass=
ume that a mobile router (like a mobile BTS in a GSM network) moved from ci=
ty-x to city-y, and according to city-x regulations VoIP calls over GSM net=
work 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: [email protected]
>  =

> =

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------