Adding GPS location to IPv6 header

George Herbert george.herbert at gmail.com
Tue Nov 27 01:13:56 UTC 2012


On Mon, Nov 26, 2012 at 4:53 PM, Owen DeLong <owen at delong.com> wrote:
>
> On Nov 26, 2012, at 14:51 , George Herbert <george.herbert at gmail.com> wrote:
>
>> 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.
>>
>
> That's true to a limited extent today.
>
> It's not likely to remain true.
>
> (No, it won't be the driver typing on their smartphone data connection, but
> it will be the busload or high-speed trainload of people typing, gaming, etc.
> all the way from SF to LA and/or other non-interactive data usages that are
> becoming more and more prevalent.
>
> Further, the speed of handoffs will have to get faster and the address stability
> area larger as that starts to include things like airplanes.
>
> Owen


Right, but GPS location in these scenarios is not helpful.  Because
the network provider has plenty of evidence you're on the move - your
cell location starts hopping at significant speeds, it's kind of
obvious.

You can either handle this with L3/4 stuff - painfully, but one can
establish a regional forwarder net which is a downwards-looking
default in each region, to handle L3 traffic for nodes that went off
the reservation.  Or you can handle this at L5 or above, in which case
this is not our problem per se; it's the device and consumer services'
website or central services site, or P2P type protocols designers
problem to handle IP address flips etc.  Which, frankly, already is
being handled (most mobile users, anyone who uses WiFi in multiple
locations + a phone data connection, etc).  It's not totally seamless,
but it works, and it's good enough.

In either case, knowing the GPS location of the phone or device is not
relevant to handling the problem or detecting it, beyond what the cell
site data gives you naturally.

As you already have to support devices hopping IPs, adding network foo
(with evident significant downsides) which does not make that hopping
IPs problem go away seems like it's a no-answer.


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




More information about the NANOG mailing list