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 On Nov 10, 2012, at 8:05 AM, Ammar Salih <ammar.sa...@auis.edu.iq> 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 > --------------------------------------------------------------------
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------