Re: [Geopriv] Adding GPS location to IPv6 header

Gotcha - thanks!

Carl


-----Original Message----- =

From: Richard L. Barnes
Sent: Tuesday, November 20, 2012 1:12 PM
To: Carl Reed
Cc: Ammar Salih ; [email protected] ; [email protected] ; 'Fred Baker (fred)'
Subject: 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 use=
d =

> 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 =

> level 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 =

> useful, but it does not seem to me that this option would be harmful to =

> the network, only possibly the privacy of users.  In specifying the =

> privacy mechanisms in your detailed description, I would suggest that you =

> make this mechanism "opt-in" by end hosts.  For example, you could have a=
n =

> all-zero geolocation option indicate that a host wishes to disclose its =

> location, but doesn'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 option 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.ietf.org/id-info/
>>
>> Filing an Internet Draft does not imply consensus around the =

>> specification, and you will need to build that consensus. You will want =

>> to make your case, 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://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?inclu=
de_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 =

>> ever a case in which your GPS location is needed by the application but =

>> may need to be guarded for privacy reasons, you will want to put it in =

>> the application layer (above the transport, guarded by IPsec or TLS), no=
t =

>> the network 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 =

>> could find them included in the internet draft above.
>>
>>
>> I would expect that 6man might tell you that the IPv6 header 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 achieve that=
, =

>> it's probably 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 tha=
t =

>> 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.ietf.org/id-info/
>>
>> Filing an Internet Draft does not imply consensus around the =

>> specification, and you will need to build that consensus. You will want =

>> to make your case, 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 =

>> ever a case in which your GPS location is needed by the application but =

>> may need to be guarded for privacy reasons, you will want to put it in =

>> the application layer (above the transport, guarded by IPsec or TLS), no=
t =

>> the network layer. In fact, I would expect that 6man might tell you that =

>> the IPv6 header 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 achieve 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 =

>> 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:
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>>   This document describes IP-LOC, an extension to IPv6 header which =

>> suggests adding GPS coordinates, as the current method of determining th=
e =

>> location of IP traffic is through IP address registration database, whic=
h =

>> 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)
>> =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 =

>> restaurants in the city), another good example would be webpage=92s =

>> 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 eve=
n =

>> 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 accurat=
e =

>> and controllable through OS and network devices, exactly like IP =

>> addresses (user can change his/her IP address, but router can also modif=
y =

>> 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 purpose=
s =

>> (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=92s required in future) the ISP can =
tag =

>> traffic with country/city more accurately as traffic passes through ISP=
=92s =

>> boarder routers.
>>
>> -------------------------------
>>
>> Maps, navigation, emergency calls and many other services will be also =

>> enhanced 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 =

>> location updates.
>>
>> -------------------------------
>>
>> =93What about privacy?=94
>>
>> 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=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 =

>> 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.
>>
>> --------------------------------
>>
>> =93For 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=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-base=
d =

>> 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 endpoin=
t =

>> 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=94
>>
>> 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 th=
e =

>> 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 =

>> 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: [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
--------------------------------------------------------------------