Re: Adding GPS location to IPv6 header

["Carlos M. Martinez" <carlosm3011 () gmail com>]

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