Re: [Geopriv] Adding GPS location to IPv6 header

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

arguments in this thread.  It would be more helpful if you could add a leve=
l =

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

your detailed description, I would suggest that you make this mechanism =

"opt-in" by end hosts.  For example, you could have an 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 optio=
n =

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

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

> 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/?includ=
e_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 th=
e =

> application layer (above the transport, guarded by IPsec or TLS), not 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 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 t=
o =

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

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

> application layer (above the transport, guarded by IPsec or TLS), not 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 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)
> =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 Ad=
s =

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

> (user can change his/her IP address, but router can also modify the heade=
r =

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

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

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

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

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

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

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