This also naively assumes that wireless network topology correlates with geographic location. Any radio engineer (or cell phone user) can explain why that doesn't work.
On 26 November 2012 17:36, William Herrin <b...@herrin.us> wrote: > On Mon, Nov 26, 2012 at 10:20 AM, Eugen Leitl <eu...@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 ................ her...@dirtside.com b...@herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 > >
