idnits 2.17.1 draft-add-location-to-ipv6-header-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 283 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 25 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Ammar J. Salih 2 Filename: draft-add-location-to-ipv6-header-01.txt 4 Enhancing Location Based IP Services 6 Status of this Memo 8 This Internet-Draft is submitted in full conformance with the 9 provisions of BCP 78 and BCP 79. 11 Internet-Drafts are working documents of the Internet Engineering 12 Task Force (IETF). Note that other groups may also distribute 13 working documents as Internet-Drafts. The list of current Internet- 14 Drafts is at http://datatracker.ietf.org/drafts/current/. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 This Internet-Draft will expire on Dec 17, 2013. 23 Copyright Notice 25 Copyright (c) 2013 IETF Trust and the persons identified as the 26 document authors. All rights reserved. 28 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 29 Relating to IETF Documents (http://trustee.ietf.org/license-info) 30 in effect on the date of publication of this document. Please 31 review these documents carefully, as they describe your rights and 32 restrictions with respect to this document. 34 ==================================== 35 Enhancing Location Based IP Services 36 ==================================== 38 Abstract 40 This document describes IP-LOC, a proposed extension to IPv6 header 41 which suggests adding optional geo-location field, in order to 42 enhance existing geo-location based IP service as well as adding new 43 ones. 45 The current method of determining geo-location of IP traffic is 46 through RIR (Regional Internet Registry) database, this information 47 is not very accurate as it depends on how the ISP registers its IP 48 subnets, that is normally done in a country/city format. 50 It also assumes that in the future, GPS capability could be added to 51 the router itself (just like smart phones) and packet marking and 52 classification based on geo-location will be required. 54 QoS, firewall and routing based on geo-location might also be 55 required in the future when mobile routers move from one geo-location 56 to another, which has a different policy. 58 1. Benefits of adding Geo-location to IPv6 header (IP-LOC) 59 ========================================================== 61 1.1 Web Services 63 Getting more accurate locations will enhance many services provided 64 by the web, like Targeted Advertising (for example, I would get Ads 65 regarding restaurants available in my neighborhood instead of all 66 restaurants in the city). 68 1.2 Information Accuracy and Control 70 Information accuracy and control: Nowadays, locations are assigned to 71 IP addresses without user awareness or control, every time a user 72 performs ip-lookup query from different locations the response would 73 be different, based on how the ISP has registered this IP subnet, 74 IP-LOC suggests making locations more accurate and controllable through 75 OS and network devices, exactly like IP addresses (user can change 76 his/her IP address, but router can also modify the header information - 77 in case its required). 79 1.3 Routing 81 Policy based routing, based on geo-location, like routing predefined 82 traffic through certain server or path, for different purposes 83 (security, manageability, serviceability like choosing call agent 84 language for VoIP calls, or routing traffic to specific cashing or 85 proxy server based on country .. etc) 87 1.4 Copyright Law 89 It happens when certain media/web content is not available to certain 90 countries due to copyright law, the current method of determining 91 locations is not accurate, on the other hand, If layer-7 application 92 to be used then the user might be able to manipulate the location 93 field, in this case (if its required in future) the ISP can tag 94 traffic with country/city more accurately as traffic passes through 95 ISP boarder routers. 97 1.5 Flexibility and Compatibility 99 Currently, many applications do not share same mechanisms to obtain 100 location or location-related data, like detecting language, for 101 example, if a VoIP user called in to a customer call center, the VoIP 102 softswitch might not support http requests in order to detect 103 customer language and redirect the call to the proper agent, so 104 although http and VoIP signaling protocols both work at the same 105 application layer, they can not always share the same mechanism, a 106 lower layer mechanism is necessary to obtain the location data. 108 1.6 Choosing Compression Ratio Automatically in Voice and Video 110 in VoIP for example, long distance call uses g729, while local call 111 uses g711 CODEC, in Cisco Call Manager, they use a feature called 112 "Region" and you manually set which phone belongs to which region, 113 then you set the CODEC between each two regions, this feature can be 114 enhanced in the future if the location can be detected in layer-3 115 header so phone can be assigned automatically to its correct region. 117 Maps, navigation, emergency calls and many other services will be 118 also enhanced with accurate locations. 120 2. Proposed IP-LOC Extension Header Format 121 =========================================== 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Next Header | Hdr Ext Len | Location Type | | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 128 | | 129 . . 130 . Type-specific Data . 131 . . 132 | | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Next Header (8 bits) 136 Indicates the type of the next header. 138 Hdr Ext Len (8 bits) 139 The length of this header, in multiples of 8 octets, not including the 140 first 8 octets. 142 Location Type (8 bits) 143 0 no location has been mentioned. 144 1 no location has been mentioned, but I want to have the ISP set the 145 location for me. 146 2 the location is mentioned in a ZIPCODE format. 147 3 Accurate GPS coordinates. 148 4 Approximate GPS coordinates .. within (1 km) radius.. neighbourhood. 149 5 Approximate GPS coordinates .. within (10 km) radius.. city. 150 6 Approximate GPS coordinates .. within (100 km) radius.. country. 152 Type-specific Data (variable) 153 Data that belongs to this type of Location. 155 3. Current arguments against this idea 156 ======================================= 158 3.1 Adding GPS position to every IPv6 header would add a lot of overhead. 160 Response: It does not have to be in every IPv6 header, only when 161 there is location update, also the host should have the option of not 162 sending location updates. 164 ---------------------------------------- 166 3.2 What about privacy? 168 Response: User should have the option of not sending location 169 updates. User should also have the ability to set location to all 170 zeros, in this case no router will modify the location field and user 171 loses the location-based services. 173 If it is router-to-router link, then no need to be worried about 174 privacy as such information usually configured on a separate network. 176 ---------------------------------------- 178 3.3 A good alternative would be to create aplication layer protocols that 179 could request and send GPS positions 181 Response: layer-7 location request will not be detected by layer-3 182 devices (Routers), I am assuming that in the future, GPS capability 183 will be added to the router itself (just like smart phones), features 184 like packet marking and classification based on geo-location will be 185 required to enforce the new geo-location policies. 187 ---------------------------------------- 189 3.4 For location-based routing protocols: Why would you want this? 190 Geographical location is not actually that important a metric for 191 routing; what you care about there is *topological* location, how far 192 I am away from you in terms of hops or latency 194 Response: For shortest path maybe yes, hops or latency is important, 195 not for policy-based routing, in our case you might want to do 196 location-based routing, like, routing VoIP traffic coming from French 197 speaking users (in multi-language country like Canada) to a French 198 speaking call agent. 200 ---------------------------------------- 202 3.5 For geolocation-based ACLs: you have the problem that if the 203 geolocation is attached by the endpoint, then it can not be trusted, 204 since the endpoint would lie to get past the ACL. If it is attached 205 by a router, the ACL needs to have proof that the router attached it 206 (and not the endpoint), which means that you would need a signed 207 geolocation header 209 Response: You could have the router modify the location field 210 anyways, just like L3 QoS fields, if you do not trust the host, so no 211 need for encryption or security, additionally, ACL is not only for 212 security, it could be used for routing, QoS ..etc, so the host will 213 not always has the motivation to manipulate the location field. 215 ---------------------------------------- 217 3.6 Why can not you simply implement rules related to geo-locations 218 statically on the network device (router, firewall .. etc)? 220 Response: To enforce new geo-location policies automatically, lets 221 assume that a mobile router (like a mobile BTS in a GSM network) 222 moved from city-x to city-y, and according to city-x regulations, 223 VoIP calls over GSM network is allowed, but city-y regulations do not 224 allow that. Now the topology may reflect same network metrics in both 225 cities but there is no rule that triggers configuration change based 226 on geo-location. 228 ---------------------------------------- 230 3.7 For copyright law enforcement, GPS precision is certainly excessive 231 for this purpose, given that copyright regimes apply at the level of 232 the nation state, not the GPS co-ordinate 234 Response: It can vary from one location to another, please have a 235 look at the boarder between Netherlands and Belgium 236 http://en.wikipedia.org/wiki/File:Baarle- 237 Nassau_fronti%C3%A8re_ca%C3%A9.jpg 239 On the other hand, user should have the option of not sending 240 location update by setting all zeros in the location field, telling 241 the ISP routers not to do so as well, in that case the user protects 242 his/her privacy but loses the benefits of location-based services, 243 and in case user chooses to let the ISP routers tag his/her packets 244 with location updates then accuracy can be tweaked, it could be based 245 on your physical connection like mobile tower your connected to, or 246 even less accurate like the city (or even country) your are 247 connecting from. In a way that allows the implementation of copyright 248 law without compromising user privacy. 250 What do you think? 252 Authors' Addresses/Contact Information: 254 Ammar J. Salih 255 Baghdad, Iraq 257 Phone: +964 770 533 0306 258 Email: ammar.alsalih@gmail.com