Adding GPS location to IPv6 header

Mon Nov 26 22:51:57 UTC 2012

The utility of this is somewhat moderated by limited geographical
mobility while a phone's active in a single session.  One rarely
drives from San Francisco to LA typing all the way on their smartphone
data connection, for example.

To the extent that you may apply IP ranges to wider geographical
areas, and limit the search space to a few % of the total, beyond
which devices get a new address pushed as they travel, this is
entirely manageable without the new header.

Some services dislike the endpoint renumbering like that, and some
connections go kerfluey, but most web based activities handle the
endpoint getting a new IP just fine; this is what cookies are for.
Your SSH connections will remind you that you should be using screen,
or not type and drive.  But the CHP and road hazards will already do
that.

Eventually being allowed to use air-to-ground cell data on airliners
will be slightly worse, but again, most protocols shrug at this
problem.

-george

On Mon, Nov 26, 2012 at 2:36 PM, William Herrin <bill at herrin.us> wrote:
> On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl <eugen at leitl.org> wrote:
>> On Mon, Nov 26, 2012 at 12:56:52PM -0200, Carlos M. Martinez 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
>>
>> I agree. You need to put it into L2, and the core usage would
>> be for wireless meshes. Consider cases like Serval or cjdns,
>> which run on Android headsets and equivalent embeddeds.
>> Technically you wouldn't need GPS everywhere if you could
>> do ~m scale time domain reflectometry in free space.
>> It is possible to build a local contiguous map via
>> mutual time of flight triangulation (actually, just visibility
>> gives you a very good hint).
>
> Actually, I think you just articulated the first use for Ammar's idea
> that's not either wrong, absurd on its face or obviously better
> handled at a different location within the protocol stack.
>
> Suppose you have a large single-owner mesh network, such as a folks
> walking around with cell phones. If you want them to have a stable
> layer 3 address (and you do) then you're handling what amounts to /128
> routes for tens of millions of devices. If you can guarantee that any
> packet *to* that address also contains a rough geographic location
> then you can discard any routes internally once they're more than a
> short geographic distance from the origin and route on the geography
> until you're close enough to find a specific /128 route. Tens of
> millions of routes is no problem if no single router needs to know
> more than a few thousand of them.
>
> By putting geographic location at layer 3, you're also handling it end
> to end which means you don't need a stateful border device to track
> the current location of all of those /128 routes. The device itself
> doesn't need to add location if it doesn't have the data; it's good
> enough for the receiving tower to attach a rough location.
>
> There are some assumptions in this model which are problematic. Key ones are:
>
> 1. Only valid as an interior gateway protocol (IGP). Geographic
> routing has been proven false for an EGP because it induces traffic to
> cross links for which neither source nor destination has permitted
> access.
>
> 2. Requires the application at the landed end to copy the IP option
> information into the outbound packets as well. This behavior is not
> presently guaranteed.
>
> 3. Assumes that the device will originate communication, receiving
> only replies from the landed end, or will use some intermediary to
> communicate current geographic information if inbound origination is
> required.
>
>
> At any rate, I think that discussion of adding a geographic option
> header to IPv6 should be tied up in the discussion of a routing
> protocol which critically depends on its presence and can't reasonably
> be built another way. Otherwise when a needful use case finally comes
> along, you'll discover that the option's rules of operation don't
> adequately enable it.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>

-- 
-george william herbert
george.herbert at gmail.com