Re: [Geopriv] Adding GPS location to IPv6 header

References for DHCP location:
<http://tools.ietf.org/html/rfc4776>
<http://tools.ietf.org/html/rfc6225>

If I understand the proposal correctly, this is an orthogonal problem to th=
e one DHCP location solves.

DHCP geolocation sends location from the DHCP server to the end host.  This=
 IPv6 option would send location from a host to the destination of a packet=
 (e.g., a server) and intermediate routers.



On Nov 20, 2012, at 2:52 PM, "Carl Reed" <[email protected]> wrote:

> Hi -
> =

> I asked this question before and did not get a response (maybe because my=
 question was off base).
> =

> There is a location extension for DHCP. This extension is consistent with=
 other location object definitions used in the IETF as well as what is used=
 and specified in various ISO, OGC, OASIS and other standards.
> =

> Why not use the DHCP location extension? Why define yet another location =
element for IPv6?
> =

> Thanks
> =

> Carl Reed, PhD
> CTO
> OGC
> =

> =

> -----Original Message----- From: Richard L. Barnes
> Sent: Tuesday, November 20, 2012 11:49 AM
> To: Ammar Salih
> Cc: [email protected] ; [email protected] ; 'Fred Baker (fred)'
> Subject: Re: [Geopriv] Adding GPS location to IPv6 header
> =

> Hi Ammar,
> =

> I have read your draft.  From what I can tell, it is just a summary of th=
e arguments in this thread.  It would be more helpful if you could add a le=
vel of technical detail to help people understand.  I would want to see at =
least:
> 1. The format of the IPv6 option
> 2. Where it is to be added to / removed from a packet
> 3. Requirements for routers / hosts
> 4. Privacy considerations
> 5. Security considerations
> =

> Also, it will be slightly easier to read if you use some of the standard =
tools for authoring Internet drafts.  See, for example:
> <http://tools.ietf.org/>
> =

> Technically speaking, I'm not yet convinced that this option is very usef=
ul, but it does not seem to me that this option would be harmful to the net=
work, only possibly the privacy of users.  In specifying the privacy mechan=
isms in your detailed description, I would suggest that you make this mecha=
nism "opt-in" by end hosts.  For example, you could have an all-zero geoloc=
ation option indicate that a host wishes to disclose its location, but does=
n't know its geolocation to put in the option; then you could require that =
a router SHOULD NOT populate this option unless an all-zero geolocation opt=
ion is already present (indicating consent).
> =

> It would also be helpful to clarify how this option would relate to other=
 similar options, such as the line identifier option:
> <http://tools.ietf.org/html/rfc6788>
> =

> Hope this helps,
> --Richard
> =

> =

> =

> =

> On Nov 18, 2012, at 9:51 AM, Ammar Salih <[email protected]> wrote:
> =

>> Hello Fred,
>> =

>> =

>> You may certainly file an internet draft with your ideas. You will want =
to read about what an Internet Draft is and how to file one. http://www.iet=
f.org/id-info/
>> =

>> Filing an Internet Draft does not imply consensus around the specificati=
on, and you will need to build that consensus. You will want to make your c=
ase, and I would suggest starting on the geopriv mailing list, although the=
 case will eventually have to be made to 6man. http://datatracker.ietf.org/=
wg/geopriv/charter/.
>> =

>> Appreciate it, the first draft has been submitted already http://datatra=
cker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_text=3D1
>> =

>> =

>> One consideration you should take in view is that the IPv6 header is not=
 encrypted, so information found in it is globally readable. If there is ev=
er a case in which your GPS location is needed by the application but may n=
eed to be guarded for privacy reasons, you will want to put it in the appli=
cation layer (above the transport, guarded by IPsec or TLS), not the networ=
k layer.
>> =

>> I have suggested few solutions to cover the privacy concern and also why=
 I am suggesting the network layer instead of the application layer, you co=
uld find them included in the internet draft above.
>> =

>> =

>> I would expect that 6man might tell you that the IPv6 header has one pri=
mary purpose, which is to conduct a datagram from the sender's system to th=
e intended receiver's system; if the data doesn't help achieve that, it's p=
robably in the wrong header.
>> =

>> I agree, also from OSI perspective, I would think twice before including=
 location field into network layer, then again, it=92s the only layer that =
makes the field useable to routers.
>> =

>> =

>> =

>> Thanks,
>> =

>> Ammar
>> =

>> =

>> =

>> From: Fred Baker (fred) [mailto:[email protected]]
>> Sent: Friday, November 16, 2012 6:05 AM
>> To: Ammar Salih
>> Cc: <[email protected]>; <[email protected]>
>> Subject: Re: Adding GPS location to IPv6 header
>> =

>> You may certainly file an internet draft with your ideas. You will want =
to read about what an Internet Draft is and how to file one. http://www.iet=
f.org/id-info/
>> =

>> Filing an Internet Draft does not imply consensus around the specificati=
on, and you will need to build that consensus. You will want to make your c=
ase, and I would suggest starting on the geopriv mailing list, although the=
 case will eventually have to be made to 6man. http://datatracker.ietf.org/=
wg/geopriv/charter/.
>> =

>> One consideration you should take in view is that the IPv6 header is not=
 encrypted, so information found in it is globally readable. If there is ev=
er a case in which your GPS location is needed by the application but may n=
eed to be guarded for privacy reasons, you will want to put it in the appli=
cation layer (above the transport, guarded by IPsec or TLS), not the networ=
k layer. In fact, I would expect that 6man might tell you that the IPv6 hea=
der has one primary purpose, which is to conduct a datagram from the sender=
's system to the intended receiver's system; if the data doesn't help achie=
ve that, it's probably in the wrong header.
>> =

>> On Nov 10, 2012, at 7: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 i=
mplemented 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:
>> =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 =
router itself (just like smart phones) and packet marking and classificatio=
n 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 differe=
nt 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 restaur=
ants in the city), another good example would be webpage=92s language, my l=
anguage will be detected more accurately based on my area rather than my co=
untry, as there are many countries with more than one popular language, not=
 mentioning that many ip registrations does not even reflect the traffic or=
iginating 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 regi=
stered this IP subnet, IP-LOC suggests making locations more accurate and c=
ontrollable through OS and network devices, exactly like IP addresses (user=
 can change his/her IP address, but router can also modify the header infor=
mation - in case it's required).
>> =

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

>> =

>> Routing: Policy based routing, based on geo-location, like routing prede=
fined traffic through certain server or path, for different purposes (secur=
ity, manageability, serviceability like choosing language, or routing traff=
ic 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 determinin=
g locations is not accurate at all, on other hand, If layer-7 application t=
o be used then the user might be able to manipulate the location field, in =
this case (if it=92s required in future) the ISP can tag traffic with count=
ry/city more accurately as traffic passes through ISP=92s boarder routers.
>> =

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

>> Maps, navigation, emergency calls and many other services will be also e=
nhanced 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 i=
s location update, also the host should have the option of not to send loca=
tion updates.
>> =

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

>> =93What about privacy?=94
>> =

>> Response: User should have the option of not sending location updates. U=
ser 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 privac=
y as such information usually configured on a separate network.
>> =

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

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

>> Response: the layer-7 location request will not be detected by layer-3 d=
evices (Routers), I am assuming that in the future, GPS capability will be =
added to the router itself (just like smart phones), features like packet m=
arking 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 =
routing, like, routing traffic coming from French speaking users (in multi-=
language country like Canada) to google.fr
>> =

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

>> =93For geolocation-based ACLs: you have the problem that if the geolocat=
ion is attached by the endpoint, then it can't be trusted, since the endpoi=
nt would lie to get past the ACL.  If it's attached by a router, the ACL ne=
eds 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, j=
ust like L3 QoS fields, if you don't trust the host, so no need for encrypt=
ion or security, additionally,  ACL is not only for security, it could be u=
sed for routing, QoS ..etc, so the host will not always has the motivation =
to manipulate the location field.
>> =

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

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

>> Response: To enforce new geo-location policies automatically, let=92s as=
sume that a mobile router (like a mobile BTS in a GSM network) moved from c=
ity-x to city-y, and according to city-x regulations VoIP calls over GSM ne=
twork is allowed, but city-y regulations do not allow that. Now the topolog=
y 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
>> --------------------------------------------------------------------
>> =

>> ----------------------------------------------------
>> The ignorance of how to use new knowledge stockpiles exponentially.
>>   - Marshall McLuhan
>> =

>> _______________________________________________
>> Geopriv mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/geopriv
> =

> _______________________________________________
> Geopriv mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/geopriv =


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