Subject: Adding GPS location to IPv6 header

From: "Ammar Salih" <[email-masked]>
Date: Sat, 10 Nov 2012 18:05:11 +0300

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: [email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Sun, 11 Nov 2012 11:49:54 -0500

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

The best procedure for presenting new ideas to the IETF is to write an Internet Draft.

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

  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

>    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.
>  
>  
>  
>  
>  
> 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.
>  
>  
>  
>  
> 
> “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.
>  
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Shane Amante <[email-masked]>
Date: Sun, 11 Nov 2012 10:08:52 -0700

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

---

From: Eitan Adler <[email-masked]>
Date: Sun, 11 Nov 2012 12:09:51 -0500

On 10 November 2012 10:05, Ammar Salih <[email-masked]> wrote:
> another good example would be webpage’s language,
> country,

This is a very bad idea. There are already mechanisms for determining
preferred languages.  In many cases people don't speak the language of
the area they are located.

>as there are many countries with more than one popular language,

Why does this need to be in the IP header? There already exist
application layer mechanisms for obtaining location information.
Leaving it at the application layer also allows for appropriate
privacy UI controls.

> traffic to specific cashing or proxy server based on country .. etc)

This is the only somewhat sane use case I could see for this
information. Even then, location of the originating request isn't
always the correct item to route on.

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

The user can manipulate or control the lower layer IP traffic too. If
they can't this is an absurd privacy violation.

> enhanced with accurate locations.

Once again - this should be done at the application layer.

> location update, also the host should have the option of not to send

Didn't you just mention above that information would be added by ISP routers

> multi-language country like Canada) to google.fr

I'm not sure what you mean here. It is easy to redirect users from
google.com -> google.fr based on their application layer language
preference.

-- 
Eitan Adler

---

From: Eitan Adler <[email-masked]>
Date: Sun, 11 Nov 2012 18:22:06 -0500

On 11 November 2012 17:15, Ammar Salih <[email-masked]> wrote:
>They use IP address instead, and it's not always about http applications, how about VoIP applications, now you need another mechanism?

Nothing stops application layer protocols from sharing one mechanism

> .. how about detecting your preferred language for layer-3 routing?

Why does language matter ever matter in the network layer?

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

Exactly. You can't infer language from location. Some locations have
multiple valid languages.  This isn't a valid use case.

> I've explained this in previous parts of the document, mainly because Layer-3 devices won't be able to recognize the feature, and also to unify the location implementations at different layers.

Why do layer 3 devices need this information?  So far you have
mentioned exactly one use case that *might* be useful.

> It doesn't have to be always .. at least now you partially agree :)

I didn't say that. I said that this is the first time I you have
mentioned anything that *could* (not necc. should) be acting at layer
3.

> Users currently have absolutely *NO* control over IP<->location mapping, it's totally how your IP owner has
> registered the IP subnet, what I am suggesting is that your local ISP *can* tag the city location "if it's required", unless you want to share your exact location or set the location to all zeros, in this case you are asking the ISP not to tag your location, but in this case you give up all location based services.

Unless the ISP decides to ignore your "request" and provide the
information anyways. Also, what if your actual location differs from
the IP address range your request is coming from. This can easily
occur from tunnels or mobile networks.

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

How does the IP layer know when the *application layer* needs this information?

>*BUT* if it's required by the government/or any other  >organization or third party in the future for the sake of >protecting the copyright laws then the feature will be >available to support that as well.

How would my ISP know my GPS coordinates?  Once again please think
about this in the context of tunnels and mobile networks.

> Google.fr example is confusing many people, which I will modify, policy based routing has much more than routing tcp:80 traffic.

Why should the policy differ based on GPS coordinates?

-- 
Eitan Adler

---

From: "Ammar Salih" <[email-masked]>
Date: Mon, 12 Nov 2012 01:15:07 +0300

> another good example would be webpage’s language, my language will be 
> detected more accurately based on my area rather than my country,

> preferred languages.  

If those mechanisms are successful then why websites like google do not use them? They use IP address instead, and it's not always about http applications, how about VoIP applications, now you need another mechanism? .. how about detecting your preferred language for layer-3 routing?

> In many cases people don't speak the language of the area they are located.

Not many cases, maybe only while you are travelling to certain places of a language that you don't speak, in that rare case you can manually change the language via whatever application you are using.

>Leaving it at the application layer also allows for appropriate privacy 
>UI controls.

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

>This is the only somewhat sane use case I could see for this information. 
>Even then, location of the originating request isn't always the correct 
>item to route on.

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

> they can't this is an absurd privacy violation.

Users currently have absolutely *NO* control over IP<->location mapping, it's totally how your IP owner has registered the IP subnet, what I am suggesting is that your local ISP *can* tag the city location "if it's required", unless you want to share your exact location or set the location to all zeros, in this case you are asking the ISP not to tag your location, but in this case you give up all location based services.

> Didn't you just mention above that information would be added by ISP 

I said under the copyright law section "(if it’s required in future) the ISP can tag traffic with country/city more accurately as traffic passes through ISP’s boarder routers" ... which means the user has the option to put his/her real location, or set the location field to all zeros, or leave it without location tagging .. *BUT* if it's required by the government/or any other organization or third party in the future for the sake of protecting the copyright laws then the feature will be available to support that as well.

> 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

--
Eitan Adler

---

From: Mark Smith <[email-masked]>
Date: Mon, 12 Nov 2012 00:14:48 -0800 (PST)

IP addresses identify a device and it's location on the Internet, not it's geographical location (although there is some correlation, assuming no tunnels), or the person who is using it.

There is a Geolocation API for web browsers, perhaps it could be generalised to suit other applications.

 http://dev.w3.org/geo/api/spec-source.html

To identify people, to then determine their attributes (e.g. their preferred language), you have to use "attributes" of them, not the machine they're currently using or where it is located on the Internet e.g. what they know, what they are or what they have.

----- Original Message -----
> From: Ammar Salih <[email-masked]>
> To: 'Eitan Adler' <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Sent: Monday, 12 November 2012 9:15 AM
> Subject: RE: Adding GPS location to IPv6 header
> 
> If those mechanisms are successful then why websites like google do not use 
> them? They use IP address instead, and it's not always about http 
> applications, how about VoIP applications, now you need another mechanism? .. 
> how about detecting your preferred language for layer-3 routing?
> 
> 
> Not many cases, maybe only while you are travelling to certain places of a 
> language that you don't speak, in that rare case you can manually change the 
> language via whatever application you are using.
> 
> 
> I've explained this in previous parts of the document, mainly because 
> Layer-3 devices won't be able to recognize the feature, and also to unify 
> the location implementations at different layers.
> 
> Users currently have absolutely *NO* control over IP<->location mapping, 
> it's totally how your IP owner has registered the IP subnet, what I am 
> suggesting is that your local ISP *can* tag the city location "if it's 
> required", unless you want to share your exact location or set the location 
> to all zeros, in this case you are asking the ISP not to tag your location, but 
> in this case you give up all location based services.
> 
> 
> I said under the copyright law section "(if it’s required in future) the 
> ISP can tag traffic with country/city more accurately as traffic passes through 
> ISP’s boarder routers" ... which means the user has the option to put 
> his/her real location, or set the location field to all zeros, or leave it 
> without location tagging .. *BUT* if it's required by the government/or any 
> other organization or third party in the future for the sake of protecting the 
> copyright laws then the feature will be available to support that as well.
> 
> Google.fr example is confusing many people, which I will modify, policy based 
> routing has much more than routing tcp:80 traffic. 
> 
> --
> Eitan Adler
>

---

From: Robin Wilton <[email-masked]>
Date: Mon, 12 Nov 2012 10:11:21 +0000

Coming to this quite late in the discussion, here's my 2¢, in case it helps provide a relatively disinterested (but not *un*-interested) summary so far:

- The benefits expected from the proposed enhancement seem very hard for the mailing list to pin down and express (some are disputed as benefits, while others are acknowledged, but minor...).

- Some use-cases have been described, but I think it would be fair to say that none of them describes an absolute "can't live without it" need for the enhancement. Most of the claimed benefits seem to be realisable by other means, potentially for less effort.

- The people who would have to do the work to implement and deploy the enhancement are not the ones who would get the direct benefit - which makes it hard to build a rationale for doing it.

From an identity, privacy an policy perspective, there's also this: any time you have something which builds identity (and for the sake of this discussion I'm going to treat 'long-term and relatively accurate data about location' as a form of identity) into the online infrastructure, there is often some claimed benefit from it, but there is also a corresponding drawback in terms of privacy and security. 

For instance, copyright law enforcement has been cited as one possible use of the location data - but actually, GPS precision is almost certainly excessive for this purpose, given that copyright regimes apply at the level of the nation state, not the GPS co-ordinate... And once the data is in the header, it will get used for whatever purpose people can find to exploit or monetize it. It is by no means certain that all those purposes will be in the interests of the end user,

For example, 'language preference expression' may seem like a neutral enough goal, but then we should also consider - what happens if the technical infrastructure starts to identify you specifically as a Bosnian Muslim, or as an Arab Israeli, or as a Kurd living in Turkey... 

As I say, these are just my thoughts as someone coming late to the discussion and with no particular 'investment' in it to pursue... hope this is useful, though.

Yrs.,

Robin

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 12 Nov 2012, at 08:42, "Ammar Salih" <[email-masked]> wrote:

>> IP addresses identify a device and it's location on the Internet, not it's 
>> geographical location (although there is some correlation, assuming no 
>> tunnels), or the person who is using it.
> 
> Sounds very reasonable and I totally agree .. but don't we use IP address to determine geographic locations? Isn't that what google, youtube and other big names use to determine locations? 
> 
> 
> This is exactly what I am talking about, too many applications for the same purpose, we need one lower layer mechanism to unify all of them and make integration more flexible and compatible.
> 
> 
>> To identify people, to then determine their attributes (e.g. their 
>> preferred language), you have to use "attributes" of them, not the machine 
>> they're currently using or where it is located on the Internet e.g. what 
>> they know, what they are or what they have.
> 
> This is how the majority of Internet work today, based on IP address, I gave google as an example, plus language is not the only benefit, how about other benefits, like Ads and commercials, I mentioned an example of getting Ads of restaurants in my city instead of getting Ads about all restaurants in country. 
> 
> 
> Ammar
> 
> 
>>> another good example would be webpage’s language, my language will 
>>> be  detected more accurately based on my area rather than my country,
>> 
>>> This is a very bad idea. There are already mechanisms for 
>>> determining  preferred languages.
>> 
>> If those mechanisms are successful then why websites like google do 
>> not use them? They use IP address instead, and it's not always about 
>> http applications, how about VoIP applications, now you need another mechanism? ..
>> Not many cases, maybe only while you are travelling to certain places 
>> of a language that you don't speak, in that rare case you can manually 
>> change the language via whatever application you are using.
>> 
>> 
>>> mentioning that many ip registrations does not even reflect the 
>>> traffic originating country.
>> 
>> Layer-3 devices won't be able to recognize the feature, and also to 
>> unify the location implementations at different layers.
>> 
>>> language, or routing traffic to specific cashing or proxy server 
>>> based  on country .. etc)
>> 
>>> Even then, location of the originating request isn't always the 
>>> correct item to route on.
>> 
>>> The user can manipulate or control the lower layer IP traffic too. 
>>> If  they can't this is an absurd privacy violation.
>> 
>> Users currently have absolutely *NO* control over IP<->location 
>> mapping, it's totally how your IP owner has registered the IP subnet, 
>> what I am suggesting is that your local ISP *can* tag the city 
>> location "if it's required", unless you want to share your exact 
>> location or set the location to all zeros, in this case you are asking 
>> the ISP not to tag your location, but in this case you give up all location based services.
>> 
>> 
>>> 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.
>> 
>> I said under the copyright law section "(if it’s required in future) 
>> the ISP can tag traffic with country/city more accurately as traffic 
>> passes through ISP’s boarder routers" ... which means the user has the 
>> option to put his/her real location, or set the location field to all 
>> zeros, or leave it without location tagging .. *BUT* if it's required 
>> by the government/or any other organization or third party in the 
>> future for the sake of protecting the copyright laws then the feature will be available to support that as well.
>> 
>> Google.fr example is confusing many people, which I will modify, 
>> policy based routing has much more than routing tcp:80 traffic.
>> 
>> --
>> Eitan Adler
>> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Kipp Jones <[email-masked]>
Date: Mon, 12 Nov 2012 09:21:20 -0600

Indeed, many operating systems now include a location API -- this has been driven by the mobile operating systems but is now included in other operation systems such as Apples OS X.  These location API's use various techniques such as Wi-Fi, Cell, GPS, and IP positioning to attempt to determine the location of the device.  In general these services are invoked by various applications, but can also be utilized by the operating system itself.  Note that use of this information, and access to these APIs is sometimes controlled in order to require user permission for applications to access the location of the device.

Any discussion of automatically including location information in device communication needs a very thorough vetting with respect to privacy. Including precise latitude and longitude with every packet seems overkill.

How applications use this information (e.g. preferred language) is dependent on the application and the user experience desired.  The same is true with how web sites use the location information provided via W3C's geolocation API.  Many web sites do not take advantage of the W3C geolocation API as it requires a pop-up notification to the user that many people find annoying at best.

Kipp

.............................................. 
Kipp Jones
Chief Architect/Privacy Czar
[email-masked]
m: 404.213.9293 | @skykipp

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 12 Nov 2012 16:50:25 +0100

For IPv6 vehicular communications, there is sometimes a "geonetworking
layer" which exchanges coordinates.  This layer is conceptually below IP
layer (and above MAC).

Alex

Le 12/11/2012 16:21, Kipp Jones a écrit :
> Indeed, many operating systems now include a location API -- this
> has been driven by the mobile operating systems but is now included
> in other operation systems such as Apples OS X.  These location
> API's use various techniques such as Wi-Fi, Cell, GPS, and IP
> positioning to attempt to determine the location of the device.  In
> general these services are invoked by various applications, but can
> also be utilized by the operating system itself.  Note that use of
> this information, and access to these APIs is sometimes controlled
> in order to require user permission for applications to access the
> location of the device.
>
> Any discussion of automatically including location information in
> device communication needs a very thorough vetting with respect to
> privacy. Including precise latitude and longitude with every packet
> seems overkill.
>
> How applications use this information (e.g. preferred language) is
> dependent on the application and the user experience desired.  The
> same is true with how web sites use the location information
> provided via W3C's geolocation API.  Many web sites do not take
> advantage of the W3C geolocation API as it requires a pop-up
> notification to the user that many people find annoying at best.
>
>
> Kipp
>
> .............................................. Kipp Jones Chief
> Architect/Privacy Czar [email-masked] m: 404.213.9293 |
> @skykipp
>
>> IP addresses identify a device and it's location on the Internet,
>> not it's geographical location (although there is some
>> correlation, assuming no tunnels), or the person who is using it.
>>
>> preferred language), you have to use "attributes" of them, not the
>> machine they're currently using or where it is located on the
>> Internet e.g. what they know, what they are or what they have.
>>
>>
>>
>>
>>> From: Ammar Salih <[email-masked]> To: 'Eitan Adler'
>>> <[email-masked]> Cc: [email-masked]; [email-masked] Sent:
>>> Monday, 12 November 2012 9:15 AM Subject: RE: Adding GPS
>>> location to IPv6 header
>>>
>>>> another good example would be webpage’s language, my language
>>>> will be detected more accurately based on my area rather than
>>>> my country,
>>>
>>> If those mechanisms are successful then why websites like google
>>> do not use them? They use IP address instead, and it's not
>>> always about http applications, how about VoIP applications, now
>>> you need another mechanism? .. how about detecting your
>>> preferred language for layer-3 routing?
>>>
>>>
>>>> In many cases people don't speak the language of the area they
>>>> are
>>> located.
>>>
>>> Not many cases, maybe only while you are travelling to certain
>>> places of a language that you don't speak, in that rare case you
>>> can manually change the language via whatever application you
>>> are using.
>>>
>>>
>>>> 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.
>>>
>>>>  application layer mechanisms for obtaining location
>>>> information. Leaving it at the application layer also allows
>>>> for appropriate privacy UI controls.
>>>
>>> I've explained this in previous parts of the document, mainly
>>> because Layer-3 devices won't be able to recognize the feature,
>>> and also to unify the location implementations at different
>>> layers.
>>>
>>>> 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)
>>>
>>>> information. Even then, location of the originating request
>>>> isn't always the correct item to route on.
>>>
>>>> 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.
>>>
>>>> The user can manipulate or control the lower layer IP traffic
>>>> too. If they can't this is an absurd privacy violation.
>>>
>>> mapping, it's totally how your IP owner has registered the IP
>>> subnet, what I am suggesting is that your local ISP *can* tag
>>> the city location "if it's required", unless you want to share
>>> your exact location or set the location to all zeros, in this
>>> case you are asking the ISP not to tag your location, but in this
>>> case you give up all location based services.
>>>
>>>
>>>> Maps, navigation, emergency calls and many other services will
>>>> be also enhanced with accurate locations.
>>>
>>>> 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.
>>>
>>> I said under the copyright law section "(if it’s required in
>>> future) the ISP can tag traffic with country/city more
>>> accurately as traffic passes through ISP’s boarder routers" ...
>>> which means the user has the option to put his/her real location,
>>> or set the location field to all zeros, or leave it without
>>> location tagging .. *BUT* if it's required by the government/or
>>> any other organization or third party in the future for the sake
>>> of protecting the copyright laws then the feature will be
>>> available to support that as well.
>>>
>>>> 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
>>>
>>>> I'm not sure what you mean here. It is easy to redirect users
>>>> from google.com -> google.fr based on their application layer
>>>> language preference.
>>>
>>> -- Eitan Adler
>>> [email-masked] Administrative Requests:
>>> https://www.ietf.org/mailman/listinfo/ipv6
>> Geopriv mailing list [email-masked]
>  IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: SM <[email-masked]>
Date: Thu, 15 Nov 2012 17:25:48 -0800

At 02:11 12-11-2012, Robin Wilton wrote:
>- The people who would have to do the work to implement and deploy 
>the enhancement are not the ones who would get the direct benefit - 
>which makes it hard to build a rationale for doing it.

http://www.cleanitproject.eu/

Regards,
-sm

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 16 Nov 2012 03:05:11 +0000

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), 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:

Many thanks.
Ammar

Ammar J. Salih
Baghdad, Iraq
October 30, 2012
Title: IP-LOC

Abstract:
=========

“What about privacy?”

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<http://google.fr/>

What do you think?

   Ammar J. Salih
   Baghdad, Iraq

   Phone: +964 770 533 0306
   Email: [email-masked]<mailto:[email-masked]>

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

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

---

From: "Ammar Salih" <[email-masked]>
Date: Sun, 18 Nov 2012 17:51:00 +0300

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/?include_t
ext=1  

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), 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's the only layer that
makes the field useable to routers. 

Thanks,

Ammar

From: Fred Baker (fred) [mailto:[email-masked]] 
Sent: Friday, November 16, 2012 6:05 AM
To: Ammar Salih
Cc: <[email-masked]>; <[email-masked]>
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), 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.

Many thanks.

Ammar

Ammar J. Salih

Baghdad, Iraq          

October 30, 2012

Title: IP-LOC

Abstract:

=========

 

 

 

"What about privacy?"

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 <http://google.fr/> 

 

What do you think?

   Ammar J. Salih

   Baghdad, Iraq

   Phone: +964 770 533 0306

   - Marshall McLuhan

---

From: John Day <[email-masked]>
Date: Sun, 18 Nov 2012 18:39:16 -0500

It has been interesting to watch this discussion, but Eitan and 
others have it correct.

The purpose of network addresses is to locate an entity in the graph 
of the network.  Network addresses are intended to facilitate 
forwarding.  For forwarding, only the structure of the graph is 
important.  (Notice I did not say "topology."  A topology refers to 
the invariant properties of a mapping among sets. A graph is not a 
topology. A set of graphs might be. Yes, I know the field abuses the 
term all the time. Another failure of education.)

Physical location has nothing to do with the operation of the network 
layer. It is all about forwarding packets within the graph formed by 
the layer.  When one says that network addresses are location 
dependent (and they are) it is with respect to the graph of the 
network.  This is also why addresses must be assigned *by* the 
network.  Only the network knows where in the graph the nodes are. 
(Yes, this means that so-called MAC addresses are not addresses. They 
are serial numbers.  Neither were IP addresses pre-CIDR.)

All identifiers in computing are addresses and locate something.  As 
Saltzer says, to resolve a name is to locate an object in a given 
context.  Things like a so-called flat address is really just an 
address  used outside its context.  For example, MAC addresses locate 
the manufacturer and however else the manufacturer used the space.

This is all pretty basic stuff.

At 18:22 -0500 2012/11/11, Eitan Adler wrote:
>  >They use IP address instead, and it's not always about http 
>applications, how about VoIP applications, now you need another 
>mechanism?

I believe you were referring to Google here.  The wonderful thing 
about software is that it is possible for not very good programmers 
to do dumb things that will work for awhile.  As we have seen in this 
field since its inception, it is dangerous to confuse economic 
success with good science.

"Well, it works!" is merely an excuse, not an argument for good science.

Take care,
John Day

>Why does language matter ever matter in the network layer?

It has nothing do with physical location either.  So, if you would 
put that in why not something else.

>>because Layer-3 devices won't be able to recognize the feature, and 
>>also to unify the location implementations at different layers.
>
>>mapping, it's totally how your IP owner has
>>  registered the IP subnet, what I am suggesting is that your local 
>>ISP *can* tag the city location "if it's required", unless you want 
>>to share your exact location or set the location to all zeros, in 
>>this case you are asking the ISP not to tag your location, but in 
>>this case you give up all location based services.
>
>>*BUT* if it's required by the government/or any other 
>>>organization or third party in the future for the sake 
>>of >protecting the copyright laws then the feature will 
>>be >available to support that as well.
>

---

From: "Ammar Salih" <[email-masked]>
Date: Tue, 20 Nov 2012 14:33:57 +0300

John,

> The purpose of network addresses is to locate an entity in the graph of 
> the network.  Network addresses are intended to facilitate forwarding.  
> For forwarding, only the structure of the graph is important.  (Notice I 
> did not say "topology."  A topology refers to the invariant properties of 
> a mapping among sets. A graph is not a topology. A set of graphs might be.

> Yes, I know the field abuses the term all the time. Another failure of 
> education.)

I do understand that the intial purpose of layer-3 is to route data through
topological map, but that was 30 years ago, the IP concept is even older, I
believe it's about time to look into what has been done so far, and to let
some changes take place, and to give more space to new applications and
services to be introduces by providing the proper infrastructure.

> layer. It is all about forwarding packets within the graph formed by the 
> layer.  When one says that network addresses are location dependent (and 
> they are) it is with respect to the graph of the network.  This is also 
> why addresses must be assigned *by* the network.  Only the network knows 
> where in the graph the nodes are.

Once you provide location-based services, physical and network locations
will be strongly binded together, otherwise network will not know where to
forward these packets and topological location alone will be useless.

> I believe you were referring to Google here.  The wonderful thing about 
> software is that it is possible for not very good programmers to do dumb 
> things that will work for awhile.  As we have seen in this field since its

> inception, it is dangerous to confuse economic success with good science.

> "Well, it works!" is merely an excuse, not an argument for good science.

Good science should be practical enough to be applied in real life, business
and services invest technology to make peoples life easier and more
prodective .. I may not agree with you in refferring to google and others as
"not very good programmers to do dumb things that will work for awhile".

Thanks,
Ammar

-----Original Message-----
From: John Day [mailto:[email-masked]] 
Sent: Monday, November 19, 2012 2:39 AM
To: Eitan Adler; Ammar Salih
Cc: [email-masked]; [email-masked]
Subject: Re: Adding GPS location to IPv6 header

It has been interesting to watch this discussion, but Eitan and others have
it correct.

The purpose of network addresses is to locate an entity in the graph of the
network.  Network addresses are intended to facilitate forwarding.  For
forwarding, only the structure of the graph is important.  (Notice I did not
say "topology."  A topology refers to the invariant properties of a mapping
among sets. A graph is not a topology. A set of graphs might be. Yes, I know
the field abuses the term all the time. Another failure of education.)

Physical location has nothing to do with the operation of the network layer.
It is all about forwarding packets within the graph formed by the layer.
When one says that network addresses are location dependent (and they are)
it is with respect to the graph of the network.  This is also why addresses
must be assigned *by* the network.  Only the network knows where in the
graph the nodes are. 
(Yes, this means that so-called MAC addresses are not addresses. They are
serial numbers.  Neither were IP addresses pre-CIDR.)

All identifiers in computing are addresses and locate something.  As Saltzer
says, to resolve a name is to locate an object in a given context.  Things
like a so-called flat address is really just an address  used outside its
context.  For example, MAC addresses locate the manufacturer and however
else the manufacturer used the space.

>applications, how about VoIP applications, now you need another 

I believe you were referring to Google here.  The wonderful thing about
software is that it is possible for not very good programmers to do dumb
things that will work for awhile.  As we have seen in this field since its
inception, it is dangerous to confuse economic success with good science.

Take care,
John Day

>Why does language matter ever matter in the network layer?

It has nothing do with physical location either.  So, if you would put that
in why not something else.

>>ISP *can* tag the city location "if it's required", unless you want to 
>>share your exact location or set the location to all zeros, in this 
>>case you are asking the ISP not to tag your location, but in this case 
>>you give up all location based services.
>
>the IP address range your request is coming from. This can easily occur 
>from tunnels or mobile networks.
>
>>of >protecting the copyright laws then the feature will be >available 
>>to support that as well.
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 20 Nov 2012 13:49:48 -0500

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 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 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 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-masked]> wrote:

> Appreciate it, the first draft has been submitted already  http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_text=1  
> 
>  
> 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), 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’s the only layer that makes the field useable to routers.
> 
>  
> 
> Thanks,
> 
> Ammar
> 
>  
>

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 20 Nov 2012 12:52:13 -0700

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-masked] ; [email-masked] ; '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 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 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 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-masked]> wrote:

> 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/doc/draft-add-location-to-ipv6-header/?include_text=1
>
>
> 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 
> 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.
>
> location field into network layer, then again, it’s the only layer that 
> 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. 
> 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 
> 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.
>
> Hello IETF, based on my discussions with both ipv6 and geopriv teams, I’ve 
> 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
>
>
>
> 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.
>
> 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.
>
>
>
>
>
> 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.
>
> (security, manageability, serviceability like choosing language, or 
> routing traffic to specific cashing or proxy server based on country .. 
> etc)
>
> 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 
> 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? 
> 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 
> “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.
>
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 20 Nov 2012 15:12:54 -0500

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 the 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-masked]> 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

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 20 Nov 2012 13:14:51 -0700

Gotcha - thanks!

Carl

-----Original Message----- 
From: Richard L. Barnes
Sent: Tuesday, November 20, 2012 1:12 PM
To: Carl Reed
Cc: Ammar Salih ; [email-masked] ; [email-masked] ; 'Fred Baker (fred)'
Subject: Re: [Geopriv] Adding GPS location to IPv6 header

If I understand the proposal correctly, this is an orthogonal problem to the 
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-masked]> wrote:

> 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:
> 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 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 option is already present (indicating consent).
>
>> 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. 
>> 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. 
>> 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), 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 
>> 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. 
>> 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. 
>> 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), 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.
>>
>> provided by the web, like targeted commercials (for example, I can get 
>> Ads regarding restaurants available in my neighborhoods instead of all 
>> 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).
>>
>> 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.
>>
>> If it’s router-to-router link, then no need to be worried about privacy 
>> as such information usually configured on a separate network.
>>
>> 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.
>>
>>

---

From: "John Pickens (jopicken)" <[email-masked]>
Date: Tue, 20 Nov 2012 20:48:17 +0000

I've been monitoring this thread.  In the IETF the objective is to respect privacy of correlation of IP address to location metadata.   Essentially as mentioned below the client device receives it in the extant protocols.  The consumer can provide authorization as to the granularity of location that is visible to other entities.   As to this schema mentioned below, embedding location info in packet headers is potentially exposing the location coordinate to "snoopers".  If encrypted, then....  

Thoughts of others?

J

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Reed
Sent: Tuesday, November 20, 2012 12:15 PM
To: Richard L. Barnes
Cc: [email-masked]; [email-masked]; Ammar Salih; Fred Baker (fred)
Subject: 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-masked] ; [email-masked] ; 'Fred Baker (fred)'
Subject: Re: [Geopriv] Adding GPS location to IPv6 header

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-masked]> wrote:

> 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.
>
> 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 level of technical detail to help people understand.  I would 
> want to see at least:
> 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/>
>
> 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 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 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:
>> 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.
>> 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.
>> 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), 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.
>>
>>
>> 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 
>> I agree, also from OSI perspective, I would think twice before 
>> including location field into network layer, then again, it's the 
>> only layer that makes the field useable to routers.
>>
>>
>>
>> Thanks,
>>
>> Ammar
>>
>>
>>
>> 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.
>> 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.
>> 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), 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.
>>
>> 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
>>
>>
>>
>> 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 
>> 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.
>>
>>
>>
>>
>>
>> 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).
>>
>> language, or routing traffic to specific cashing or proxy server based on country ..
>> etc)
>>
>> manipulate the location field, in this case (if it's required in 
>> traffic passes through ISP's boarder routers.
>>
>> there is location update, also the host should have the option of not 
>> to send 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.
>>
>> 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"
>>
>> "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.

---

From: "Ammar Salih" <[email-masked]>
Date: Wed, 21 Nov 2012 01:03:06 +0300

> As to this schema mentioned below, embedding location info in packet
headers is potentially exposing the location coordinate to "snoopers

Ok, I would like to shed some light regarding privacy issue:

First, user should have the option of not sending location updates.

Second, user will be routed through an ISP, if we don't trust the ISP then I
can assure you that ISP can get much more information than physical
location, any un-encrypted traffic -which is the majority- can be analyzed
at the ISP level (up to layer-7).

Other than ISP, the sniffer could be connected to the same layer-2/layer-3
device as mine, in this case I would worry about
usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not
location as the sniffer in this case is mostly sitting at the same physical
location as mine.
	
Thanks
Ammar

-----Original Message-----
From: John Pickens (jopicken) [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2012 11:48 PM
To: Carl Reed; Richard L. Barnes
Cc: [email-masked]; [email-masked]; Ammar Salih; Fred Baker (fred)
Subject: RE: [Geopriv] Adding GPS location to IPv6 header

I've been monitoring this thread.  In the IETF the objective is to respect
privacy of correlation of IP address to location metadata.   Essentially as
mentioned below the client device receives it in the extant protocols.  The
consumer can provide authorization as to the granularity of location that is
visible to other entities.   As to this schema mentioned below, embedding
location info in packet headers is potentially exposing the location
coordinate to "snoopers".  If encrypted, then....  

Thoughts of others?

J

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carl Reed
Sent: Tuesday, November 20, 2012 12:15 PM
To: Richard L. Barnes
Cc: [email-masked]; [email-masked]; Ammar Salih; Fred Baker (fred)
Subject: Re: [Geopriv] Adding GPS location to IPv6 header

Gotcha - thanks!

Carl

---

From: "Ammar Salih" <[email-masked]>
Date: Wed, 21 Nov 2012 01:18:24 +0300

Hello Richard,

> 2. Where it is to be added to / removed from a packet 3. Requirements for 
> routers / hosts 4. Privacy considerations 5. Security considerations

I've been thinking about this also, and I was trying to see the general
feeling about the idea and getting some feedback first, then proceed with
more technical details, thanks for your interest!

> tools for authoring Internet drafts.  See, for example:

I am quite new to the IETF, still reading documents and exploring tools,
thanks for the note, appreciate it!

Thanks,
Ammar

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]] 
Sent: Tuesday, November 20, 2012 9:50 PM
To: Ammar Salih
Cc: 'Fred Baker (fred)'; [email-masked]; [email-masked]
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 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

Hope this helps,
--Richard

> 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.
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.
> "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"
> "Why can't you simply implement rules related to geo-locations statically
on the network device (router, firewall .. etc)?"

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Nov 2012 18:05:29 +1100

> at the ISP level (up to layer-7).

There are LOTS of ISPs between the client and the destination.  Most
of these can get nothing about your location.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Ammar Salih" <[email-masked]>
Date: Wed, 21 Nov 2012 11:23:52 +0300

Mark,

> There are LOTS of ISPs between the client and the destination.  Most of 
> these can get nothing about your location.

They can get much more! trust me, the point is that if you don't trust the
ISP then you should be worried about all your un-encrypted traffic, not only
location. 

Anythink you write on facebook for example *if you don't use https* can be
easily detected, including location tags,relationships,activities,  wall
posts, friends ... and much more, all your http traffic, including documents
you read, messages, usernames, passwords, bank accounts ...etc.

One last point, is that your current IP address reflects your location, I
can simply do ip lookup and find out your location. Would that be also
considered as privacy breach?

Thanks,
Ammar

-----Original Message-----
From: Mark Andrews [mailto:[email-masked]] 
Sent: Wednesday, November 21, 2012 10:05 AM
To: Ammar Salih
Cc: 'John Pickens (jopicken)'; [email-masked]; [email-masked]; 'Fred Baker
(fred)'

In message <[email-masked]>, "Ammar Salih"
writes:
> Second, user will be routed through an ISP, if we don't trust the ISP 
> then I can assure you that ISP can get much more information than 
> physical location, any un-encrypted traffic -which is the majority- 
> can be analyzed at the ISP level (up to layer-7).

There are LOTS of ISPs between the client and the destination.  Most of
these can get nothing about your location.
 
> Other than ISP, the sniffer could be connected to the same 
> layer-2/layer-3 device as mine, in this case I would worry about 
> usernames/passwords/accounts/files/keys/pictures/messages .. etc, but 
> not location as the sniffer in this case is mostly sitting at the same 
> physical location as mine.
> 	
> Thanks
> Ammar
> 
> 
> 
> mentioned below the client device receives it in the extant protocols.  
> The consumer can provide authorization as to the granularity of location
that is
> IPv6 option would send location from a host to the destination of a 
> packet (e.g., a server) and intermediate routers.
> 
> 
> 
> > 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 level of technical detail to help people understand.  I 
> > would want to see at least:
> > 2. Where it is to be added to / removed from a packet 3. 
> > Requirements for routers / hosts 4. Privacy considerations 5. 
> > Security considerations
> >
> > 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 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 option is 
> > already present
> (indicating consent).
> >
> >> http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?
> >> in
> >> clude_text=1
> >>
> >>
> >> 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), 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 
> >> 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), not the network layer. In fact, I would 
> >> expect that 6man might tell you that the IPv6 header has one 
> >> Hello IETF, based on my discussions with both ipv6 and geopriv 
> >> teams, I've written the below document to summarize few ideas.
> >>
> >> 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.
> >> 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 
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).
> >>
> >> based on
> country ..
> >> method of determining locations is not accurate at all, on other 
> >> hand, If
> >> future) the ISP can tag traffic with country/city more accurately 
> >> as traffic passes through ISP's boarder routers.
> >>
> >> this case no router will modify the location field and user loses 
> >> the location-based services.
> >>
> >> routing; what you care about there is *topological* location, how 
> >> far I am away from you in terms of hops or latency"
> >>
> >> 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
> >>
> >> 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"
> >>
> >> 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.
> >>
> >> 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.
> >>
> >>
> >> -------------------------------------------------------------------
> >> - IETF IPv6 working group mailing list [email-masked] Administrative

---

From: Ivan Shmakov <[email-masked]>
Date: Wed, 21 Nov 2012 16:36:56 +0700

>>>>> Ammar Salih <[email-masked]> writes:

 > They can get much more!  trust me, the point is that if you don't
 > trust the ISP then you should be worried about all your un-encrypted
 > traffic, not only location.

 > Anythink you write on facebook for example *if you don't use https*
 > can be easily detected, including location tags, relationships,
 > activities, wall posts, friends ... and much more, all your http
 > traffic, including documents you read, messages, usernames,
 > passwords, bank accounts ...etc.

	That's precisely the reason to never, ever consider plain,
	un-encrypted HTTP for anything that requires authentication.  To
	note is that the majority of sites don't allow logins over plain
	HTTP, and I've never seen a bank providing access to one's
	account over plain HTTP.

	Once again, in the typical case, there're way too many networks
	between you and the service you use to trust them all.

	The same applies to the non-TLS (non-SSL) versions of the other
	protocols, such as IMAP or XMPP, just as well.

 > One last point, is that your current IP address reflects your
 > location, I can simply do ip lookup and find out your location.

	It's not actually as simple as it may seem, as long as the
	possibility of a tunnel (VPN) is considered.

	Such tunnels is also a reason why it isn't sensible for an ISP
	to validate or provide geolocation information within the
	traffic routed.

 > Would that be also considered as privacy breach?

	Yes.  This is why one may occasionally want to relay one's
	traffic via Tor [1].

[1] https://www.torproject.org/

-- 
FSF associate member #7257

---

From: [email-masked]
Date: Wed, 21 Nov 2012 12:11:47 +0100 (CET)

> considered as privacy breach?

You can probably get a *hint* about my location from an IP lookup. You
can definitely not be certain my location - since you don't know if the
RIR info is correct, you don't know about any tunnels I might use, etc.

For instance - if I put the address of my mail server into Geo IP Tool
(one of several such services),

     http://www.geoiptool.com/en/?IP=195.1.209.33

it tells me the correct *country* for the IP. However, both the region
and the city are wrong. 

How valuable is location with contry granularity?

Steinar Haug, Nethelp consulting, [email-masked]

---

From: [email-masked]
Date: Wed, 21 Nov 2012 16:27:53 +0100 (CET)

> > You can probably get a *hint* about my location from an IP lookup. You can
> > definitely not be certain my location
> 
> Well, with the new draft, you can do the same, location accuracy can be
> tweaked to reflect city only, or city and region..etc.

And what makes you think I'm interested in publishing this?

> > it tells me the correct *country* for the IP. However, both the region and
> > the city are wrong.
> 
> That is the whole point, why are we happy with providing incorrect
> information? It's even without our awareness or control.

I don't particularly *want* to publish this information. Therefore, if
the geolocation data is to a large degree wrong, that's just fine!

My whole point was simply meant as a counterargument to your "I can
simply do ip lookup and find out your location". And my claim is that
no, you can't really "simply" do that. And I like it that way.

---

From: "Ammar Salih" <[email-masked]>
Date: Wed, 21 Nov 2012 15:41:41 +0300

Thanks,
Ammar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 21, 2012 2:12 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Adding GPS location to IPv6 header

> location, I can simply do ip lookup and find out your location. Would 
> that be also considered as privacy breach?

You can probably get a *hint* about my location from an IP lookup. You can
definitely not be certain my location - since you don't know if the RIR info
is correct, you don't know about any tunnels I might use, etc.

For instance - if I put the address of my mail server into Geo IP Tool (one
of several such services),

---

From: "Ammar Salih" <[email-masked]>
Date: Thu, 22 Nov 2012 10:43:38 +0300

Dears,

I can see almost everyone agrees to that the RIR info is not accurate and in
many cases is incorrect, so why the hassle of assigning wrong locations? And
why developers are building their applications based on incorrect
information.

And frankly speaking, I don't agree to *sending wrong location information
to protect our privacy*, it's either you send correct ones and get the
benefits of location-based services or you don't.

Thanks,
Ammar 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, November 21, 2012 6:28 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Geopriv] Adding GPS location to IPv6 header

> > You can probably get a *hint* about my location from an IP lookup. 
> > You can definitely not be certain my location
> 
> Well, with the new draft, you can do the same, location accuracy can 
> be tweaked to reflect city only, or city and region..etc.

> > it tells me the correct *country* for the IP. However, both the 
> > region and the city are wrong.
> 

I don't particularly *want* to publish this information. Therefore, if the
geolocation data is to a large degree wrong, that's just fine!

My whole point was simply meant as a counterargument to your "I can simply
do ip lookup and find out your location". And my claim is that no, you can't
really "simply" do that. And I like it that way.

---

From: SM <[email-masked]>
Date: Thu, 22 Nov 2012 03:27:06 -0800

Hi Ammar,
>why developers are building their applications based on incorrect

Developers take the data wherever they can find it.  The information 
which is distilled from that is a best guess [1].  A RIR can be asked 
to "clarify that Puerto Rico is part of the United States" [2].

Regards,
-sm

1. 
http://meetings.apnic.net/__data/assets/pdf_file/0005/23486/Lepinski-APNIC-30-Geolocation-Registry.pdf
2. https://www.arin.net/participate/acsp/suggestions/2010-2.html

---

From: George Mitchell <[email-masked]>
Date: Thu, 22 Nov 2012 08:31:24 -0500

On 11/22/12 02:43, Ammar Salih wrote:
> [...]

It is naive to expect the network to give you any more information about
the origin of a packet than what you need to respond to its sender.  It
is akin to asking your doctor for legal advice, or asking a bus driver
to design a nuclear reactor.                          -- George Mitchell

---

From: joel jaeggli <[email-masked]>
Date: Thu, 22 Nov 2012 08:30:55 -0800

> why developers are building their applications based on incorrect
The RIR isn't in the business of tracking location, it's in the business 
of allocating resources. if you want to know the location of the party 
which recieved the allocation, ask an RIR. Where the block is used 
rather than to whom it is allocated, that is none of their business.

---

From: Ignatios Souvatzis <[email-masked]>
Date: Fri, 23 Nov 2012 13:45:52 +0100

On Mon, Nov 12, 2012 at 01:15:07AM +0300, Ammar Salih wrote:

> do not use them? They use IP address instead, and it's not always
> about http applications, how about VoIP applications, now you need
> another mechanism? .. how about detecting your preferred language
> for layer-3 routing?

No *this* is a very bad idea. We have lots of foreign students
here, and information I'd want to look up is often more precise in
English, than say, German.

It's bad enough that I have to apply a dozen mouse clicks to get
some websites to give me the language I want; I don't want another
mechanism with an even higher perceived accuracy for that.

	-is

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 24 Nov 2012 06:57:33 -0500

Hi Ammar,

> why developers are building their applications based on incorrect

If this information is for application-layer consumption, it should be provided at the application layer. If existing application-layer mechanisms aren't providing what developers need, they should be improved.

> benefits of location-based services or you don't.

There is an important set of use cases where sending precise but spoofed location information can be very important (stalking, domestic violence, labor disputes/whistleblowing, etc.) -- when someone else who is tracking your location needs to see a location reported other than where you were. Again since the use context is required for supporting these, application-layer mechanisms and controls are the best tools for delivering this sort of privacy protection.

Alissa