[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Adding GPS location to IPv6 header
- Subject: Adding GPS location to IPv6 header
- From: mysidia at gmail.com (Jimmy Hess)
- Date: Sun, 25 Nov 2012 00:28:54 -0600
- In-reply-to: <CAO9uaO2pBq6F=Z25TGPe9CpAwaoG2ArGcb4R5pZgsoVo5ykfYw@mail.gmail.com>
- References: <[email protected]> <CAO9uaO2pBq6F=Z25TGPe9CpAwaoG2ArGcb4R5pZgsoVo5ykfYw@mail.gmail.com>
On 11/24/12, John Adams <jna at retina.net> wrote:
> Don't conflate layer 5-7 needs with basic communication requirements. IP is
> not the place for this sort of header.
IP is the logical place for this kind of header, as this information
is node dependent, not application dependent.
It would be useful for identifying the location of a server, when an
IP address does not.
For example, in the case of an anycasted service, the source IP
address does not uniquely identify where the source came from.
The requirement that the embedded location data, be GPS data,
however: would seem to be overly restrictive; a simple 8-bit
"Site number" identifier could be all the location data needed for
diagnostic purposes.
"Privacy issues" are policy considerations, that have no place in
the determination of protocol header formats; providers of a service
will generate location header extensions, if they are useful to them,
if they are not, then they would choose to not support the extension.
If a provider wants to attempt to implement rights management using
header fields, then more power to them.... I never heard of a
digital rights management provider implementing an open
standards-based approach, and it would be a positive development if
they did, but more likely than not, they will ignore header extension
options, and implement rights management identification inside
proprietary application layer payloads that contain the actual
protected content,
instead of IP packet headers, which are easily stripped off, and
replaced with new IP headers containing the same packet data payload.
--
-JH