Just for redundancy's sake: No, L3 is **not** the place for this kind of information. L3 is supposed to be simple, easy to implement, fast to switch. In Spanish we have a very strong adjective for this kind of ideas: "pésimo". I couldn't find a similar one in English without using foul words :-) In any case, and as it already has been pointed out, I can imagine an upper layer protocol, similar to NTP that reports GPS coordinates. Come to think of it, if NTP could be extended this would fit in nicely as there are already lots of NTP nodes which already have GPS sensors. Additionally, unless the proponents of this idea are expecting every router manufacturer to build GPS chips into their gear and us datacentre operators to drill holes on our roofs for the antennas, I don't see any real useful role for this extension header. cheers! ~Carlos On 11/26/12 9:20 AM, Mohacsi Janos wrote:
On Sun, 25 Nov 2012, Ammar Salih wrote:
Thank you everyone, I appreciate your feedback and will try to summarize few points in one email to avoid duplication .. apologies if I missed any.
This is not data that should be sent on every packet. It becomes redundant.
1- It does not have to be in every IPv6 header, only when there is location update.
It should not be in any IPv6 packet. It has to be in an upper layer protocol.
2- the host should have the option of not sending location updates.
In worst case. Host should have an option to sending location update - probably not in IP headers, but upper layer protocol.
3- I am suggesting an *extension header*, which means that operators will have the option of not using it in case they don't want to.
I suggest an upper layer protocol. Something like HTTP, TCP or UDP option. The server can initiate a carry, and a client can decide to answer with location information.
----------------------------------------------------
A good alternative would be to create application layer protocols that could request and send GPS positions.
1- there are already several application-layer mechanisms which have been created for this purpose, none of them has been considered by major service providers, google for example is still using RIR info for determining location-based settings like language.
2- Layer 7 will not be detected by layer 3 devices (routers) .. so location-based service on layer-3 will not be possible.
3- Currently, many applications do not share same mechanisms to obtain location or location-related data, GEOPRIV WG [1] works on http location mechanism, but *for the sake of example* VoIP soft-switches may not support http protocol, so a new mechanism needs to be developed- which has been done [2] .. W3c has also specified another API that provides scripted access to geographical location information [3] which has not been considered by others ..
that's why I am suggesting a unified lower layer *optional* mechanism which is capable of supporting all other applications.
I prefer application and at most the transport layer protocol extension.
[1] https://datatracker.ietf.org/wg/geopriv/charter/
[2] http://tools.ietf.org/html/rfc6442
[3] http://dev.w3.org/geo/api/spec-source.html
----------------------------------------------------------------------------
------
I see major privacy issues with this. Why introduce more intelligence which WILL eventually be used for more intrusion into the private lives of all of us?
1- The host should have the option of not sending location updates.
2- It's extension header, means it's up to the service provider to use the feature or not.
3- Users are being routed through ISPs, if we don't trust the ISP then I can assure you that ISP can get much more information than physical location, any un-encrypted traffic -which is the majority- can be analyzed at the ISP level (up to layer-7).
Anythink you write on facebook for example *if you don't use https* can be detected, including location tags, relationships, activities, wall posts, friends ... and much more, all your http traffic, including documents you read, messages, usernames, passwords, bank accounts ...etc.
Other than ISP, sniffers can be connected to the same layer-2/layer-3 device as mine, in this case I would worry about usernames/passwords/accounts/files/keys/pictures/messages .. etc, but not location as the sniffer in this case is mostly sitting at the same physical location as mine.
4- our locations currently are being sent anyways through RIR info, without our awareness or control, I am suggesting to have the end user control the feature, still his/her option though not to send location updates.
-------------------------------------------
Thank you everyone for your time and professional feedback, I highly appreciate it!
Please be informed that this is only a draft, and I am requesting comments, I also apologize for those who felt uncomfortable about the draft *they should not* as the whole feature is optional - in case its implemented.
Thanks,
Ammar
From: Ammar Salih [mailto:ammar.salih@auis.edu.iq] Sent: Thursday, November 22, 2012 3:00 PM To: 'nanog@nanog.org' Subject: Adding GPS location to IPv6 header
Dears, I've proposed a new IPv6 "extension header", it's now posted on IETF website, your ideas and comments are most welcome!
http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include_t
ext=1
Thanks!
Ammar Salih