Internet DRAFT - draft-add-location-to-ipv6-header
draft-add-location-to-ipv6-header
Internet-Draft Ammar J. Salih
Intended status: Proposed Standard May 2013
Filename: draft-add-location-to-ipv6-header-01.txt
Enhancing Location Based IP Services
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on Dec 17, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights and
restrictions with respect to this document.
====================================
Enhancing Location Based IP Services
====================================
Abstract
This document describes IP-LOC, a proposed extension to IPv6 header
which suggests adding optional geo-location field, in order to
enhance existing geo-location based IP service as well as adding new
ones.
The current method of determining geo-location of IP traffic is
through RIR (Regional Internet Registry) database, this information
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 could 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 might also be
required in the future when mobile routers move from one geo-location
to another, which has a different policy.
1. Benefits of adding Geo-location to IPv6 header (IP-LOC)
==========================================================
1.1 Web Services
Getting more accurate locations will enhance many services provided
by the web, like Targeted Advertising (for example, I would get Ads
regarding restaurants available in my neighborhood instead of all
restaurants in the city).
1.2 Information Accuracy and Control
Information accuracy and control: Nowadays, locations are assigned to
IP addresses without user awareness or control, every time a user
performs ip-lookup query from different locations 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 its required).
1.3 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 call agent
language for VoIP calls, or routing traffic to specific cashing or
proxy server based on country .. etc)
1.4 Copyright Law
It happens when certain media/web content is not available to certain
countries due to copyright law, the current method of determining
locations is not accurate, on the other hand, If layer-7 application
to be used then the user might be able to manipulate the location
field, in this case (if its required in future) the ISP can tag
traffic with country/city more accurately as traffic passes through
ISP boarder routers.
1.5 Flexibility and Compatibility
Currently, many applications do not share same mechanisms to obtain
location or location-related data, like detecting language, for
example, if a VoIP user called in to a customer call center, the VoIP
softswitch might not support http requests in order to detect
customer language and redirect the call to the proper agent, so
although http and VoIP signaling protocols both work at the same
application layer, they can not always share the same mechanism, a
lower layer mechanism is necessary to obtain the location data.
1.6 Choosing Compression Ratio Automatically in Voice and Video
in VoIP for example, long distance call uses g729, while local call
uses g711 CODEC, in Cisco Call Manager, they use a feature called
"Region" and you manually set which phone belongs to which region,
then you set the CODEC between each two regions, this feature can be
enhanced in the future if the location can be detected in layer-3
header so phone can be assigned automatically to its correct region.
Maps, navigation, emergency calls and many other services will be
also enhanced with accurate locations.
2. Proposed IP-LOC Extension Header Format
===========================================
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Location Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Type-specific Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header (8 bits)
Indicates the type of the next header.
Hdr Ext Len (8 bits)
The length of this header, in multiples of 8 octets, not including the
first 8 octets.
Location Type (8 bits)
0 no location has been mentioned.
1 no location has been mentioned, but I want to have the ISP set the
location for me.
2 the location is mentioned in a ZIPCODE format.
3 Accurate GPS coordinates.
4 Approximate GPS coordinates .. within (1 km) radius.. neighbourhood.
5 Approximate GPS coordinates .. within (10 km) radius.. city.
6 Approximate GPS coordinates .. within (100 km) radius.. country.
Type-specific Data (variable)
Data that belongs to this type of Location.
3. Current arguments against this idea
=======================================
3.1 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
sending location updates.
----------------------------------------
3.2 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 is router-to-router link, then no need to be worried about
privacy as such information usually configured on a separate network.
----------------------------------------
3.3 A good alternative would be to create aplication layer protocols that
could request and send GPS positions
Response: 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.
----------------------------------------
3.4 For location-based routing protocols: Why would you want this?
Geographical location is not 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 VoIP traffic coming from French
speaking users (in multi-language country like Canada) to a French
speaking call agent.
----------------------------------------
3.5 For geolocation-based ACLs: you have the problem that if the
geolocation is attached by the endpoint, then it can not be trusted,
since the endpoint would lie to get past the ACL. If it is 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 do not 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.
----------------------------------------
3.6 Why can not you simply implement rules related to geo-locations
statically on the network device (router, firewall .. etc)?
Response: To enforce new geo-location policies automatically, lets
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.
----------------------------------------
3.7 For copyright law enforcement, GPS precision is certainly excessive
for this purpose, given that copyright regimes apply at the level of
the nation state, not the GPS co-ordinate
Response: It can vary from one location to another, please have a
look at the boarder between Netherlands and Belgium
http://en.wikipedia.org/wiki/File:Baarle-
Nassau_fronti%C3%A8re_ca%C3%A9.jpg
On the other hand, user should have the option of not sending
location update by setting all zeros in the location field, telling
the ISP routers not to do so as well, in that case the user protects
his/her privacy but loses the benefits of location-based services,
and in case user chooses to let the ISP routers tag his/her packets
with location updates then accuracy can be tweaked, it could be based
on your physical connection like mobile tower your connected to, or
even less accurate like the city (or even country) your are
connecting from. In a way that allows the implementation of copyright
law without compromising user privacy.
What do you think?
Authors' Addresses/Contact Information:
Ammar J. Salih
Baghdad, Iraq
Phone: +964 770 533 0306
Email: ammar.alsalih@gmail.com
