[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/