[158215] in North American Network Operators' Group
Re: Adding GPS location to IPv6 header
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Nov 26 14:56:26 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <50B38334.4060402@gmail.com>
Date: Mon, 26 Nov 2012 11:52:17 -0800
To: "Carlos M. Martinez" <carlosm3011@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Nov 26, 2012, at 06:56 , "Carlos M. Martinez" <carlosm3011@gmail.com> =
wrote:
> 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=E9simo". I couldn't find a similar one in English without =
using
> foul words :-)
>=20
The rough translation of p=E9simo is "terrible". And it certainly =
applies here.
FYI.
Owen
> 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.
>=20
> 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.
>=20
> cheers!
>=20
> ~Carlos
>=20
> On 11/26/12 9:20 AM, Mohacsi Janos wrote:
>>=20
>>=20
>>=20
>> On Sun, 25 Nov 2012, Ammar Salih wrote:
>>=20
>>> 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.
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> This is not data that should be sent on every packet. It becomes
>>> redundant.
>>>=20
>>>=20
>>>=20
>>> 1- It does not have to be in every IPv6 header, only when there is
>>> location
>>> update.
>>=20
>> It should not be in any IPv6 packet. It has to be in an upper layer
>> protocol.
>>=20
>>=20
>>>=20
>>> 2- the host should have the option of not sending location updates.
>>=20
>> In worst case. Host should have an option to sending location update =
-
>> probably not in IP headers, but upper layer protocol.
>>=20
>>>=20
>>> 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.
>>=20
>>=20
>> 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.
>>=20
>>=20
>>>=20
>>>=20
>>>=20
>>> ----------------------------------------------------
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> A good alternative would be to create application layer protocols =
that
>>> could request and send GPS positions.
>>>=20
>>> 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.
>>>=20
>>>=20
>>> 2- Layer 7 will not be detected by layer 3 devices (routers) .. so
>>> location-based service on layer-3 will not be possible.
>>>=20
>>>=20
>>> 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 ..
>>>=20
>>> that's why I am suggesting a unified lower layer *optional* =
mechanism
>>> which
>>> is capable of supporting all other applications.
>>>=20
>>=20
>> I prefer application and at most the transport layer protocol =
extension.
>>=20
>>=20
>>=20
>>>=20
>>>=20
>>> [1] https://datatracker.ietf.org/wg/geopriv/charter/
>>>=20
>>> [2] http://tools.ietf.org/html/rfc6442
>>>=20
>>> [3] http://dev.w3.org/geo/api/spec-source.html
>>>=20
>>>=20
>>>=20
>>> =
--------------------------------------------------------------------------=
--
>>>=20
>>> ------
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> 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?
>>>=20
>>>=20
>>>=20
>>> 1- The host should have the option of not sending location updates.
>>>=20
>>> 2- It's extension header, means it's up to the service =
provider
>>> to use
>>> the feature or not.
>>>=20
>>> 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).
>>>=20
>>>=20
>>>=20
>>> 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.
>>>=20
>>>=20
>>>=20
>>> 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.
>>>=20
>>>=20
>>>=20
>>> 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.
>>>=20
>>>=20
>>>=20
>>> -------------------------------------------
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> Thank you everyone for your time and professional feedback, I highly
>>> appreciate it!
>>>=20
>>>=20
>>>=20
>>> 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.
>>>=20
>>>=20
>>>=20
>>> Thanks,
>>>=20
>>> Ammar
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> 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
>>>=20
>>>=20
>>>=20
>>> Dears, I've proposed a new IPv6 "extension header", it's now posted =
on
>>> IETF
>>> website, your ideas and comments are most welcome!
>>>=20
>>>=20
>>>=20
>>> =
http://datatracker.ietf.org/doc/draft-add-location-to-ipv6-header/?include=
_t
>>>=20
>>> ext=3D1
>>>=20
>>>=20
>>>=20
>>> Thanks!
>>>=20
>>> Ammar Salih
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
