Gotcha - thanks!
Carl
-----Original Message-----
From: Richard L. Barnes
Sent: Tuesday, November 20, 2012 1:12 PM
To: Carl Reed
Cc: Ammar Salih ; geop...@ietf.org ; ipv6@ietf.org ; 'Fred Baker (fred)'
Subject: Re: [Geopriv] Adding GPS location to IPv6 header
References for DHCP location:
<http://tools.ietf.org/html/rfc4776>
<http://tools.ietf.org/html/rfc6225>
If I understand the proposal correctly, this is an orthogonal problem to 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" <cr...@opengeospatial.org> wrote:
Hi -
I asked this question before and did not get a response (maybe because my
question was off base).
There is a location extension for DHCP. This extension is consistent with
other location object definitions used in the IETF as well as what is used
and specified in various ISO, OGC, OASIS and other standards.
Why not use the DHCP location extension? Why define yet another location
element for IPv6?
Thanks
Carl Reed, PhD
CTO
OGC
-----Original Message----- From: Richard L. Barnes
Sent: Tuesday, November 20, 2012 11:49 AM
To: Ammar Salih
Cc: geop...@ietf.org ; ipv6@ietf.org ; '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 <ammar.sa...@auis.edu.iq> wrote:
Hello Fred,
You may certainly file an internet draft with your ideas. You will want
to read about what an Internet Draft is and how to file one.
http://www.ietf.org/id-info/
Filing an Internet Draft does not imply consensus around the
specification, and you will need to build that consensus. You will want
to make your case, and I would suggest starting on the geopriv mailing
list, although the case will eventually have to be made to 6man.
http://datatracker.ietf.org/wg/geopriv/charter/.
Appreciate it, the first draft has been submitted already
http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?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: Fred Baker (fred) [mailto:f...@cisco.com]
Sent: Friday, November 16, 2012 6:05 AM
To: Ammar Salih
Cc: <ipv6@ietf.org>; <geop...@ietf.org>
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.
On Nov 10, 2012, at 7: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.
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: ammar.alsa...@gmail.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
----------------------------------------------------
The ignorance of how to use new knowledge stockpiles exponentially.
- Marshall McLuhan
_______________________________________________
Geopriv mailing list
geop...@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
geop...@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------