Adding GPS location to IPv6 header

Alex dreamwaverfx at yahoo.com
Mon Nov 26 06:54:38 UTC 2012


While most of the people are trying to save the internet from any form 
of "goverment" and let it be free, this would be like shooting yourself 
in the foot.
This would be great for troubleshooting things...I agree, but other than 
that it would create a whole new plethora of privacy concerns.

We use the internet to express ideas either through our real life names 
or through alter-egos that give us anonymity and let us say things we 
wouldn't dare otherwise.
GPS data would just destroy any sort of anonymity that is left on the NET.
I can see big companies paying large sums for this sort of 
info...imagine google, facebook,etc having access to this kind of data.

"the host should have the option of not sending location updates."
Lets face it...how many people really know what a IP is, what it can do 
and what you can turn off or on?
Other than the IT sector, most other people do not care and they just 
plug-and-play.
This would just create a window through which you could implement such a 
feature and throw out most security concerns, because the people that 
actually care understand the feature and can turn it off...the masses 
are not so lucky and they get the BIG BROTHER treatment.

GPS header would have the same effect on IPv6 implementation as CGN.
While CGN and GPS data have the potential to make alot of cash for the 
ISP who implements it...we don't really want that in our lives and it 
would deter the customers from switching to IPv6 even more.

IMHO the Internet should just be free and offer full anonymity, else it 
would just come crashing down on our heads.

On 11/25/2012 2:30 PM, 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.
>
> 2- the host should have the option of not sending location updates.
>
> 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.
>
>   
>
> ----------------------------------------------------
>
>   
>
>   
>
>> 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.
>   
>   
>
> [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 at auis.edu.iq]
> Sent: Thursday, November 22, 2012 3:00 PM
> To: 'nanog at 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
>
>   
>
>   
>





More information about the NANOG mailing list