So I came across this post the other day and wanted to see what folks think about it. https://plus.google.com/u/0/109418153881180057361/posts/AvjZbbK6T7X Here is the relevant portion: *Got anything more specific than that to go on?* Actually, yes. Although I still want community feedback on how the idea can be improved. Most mesh systems have pretty arbitrary ways of handing out IP addresses, so I say, put a little logic into 'em, in a consistent way that works well for routing between networks and across the existing internet. An IPv6 address is composed of 8 chunks, each of which is 4 hex digits long. The first chunk should be something arbitrary but unclaimed - anybody know if 00fd is taken? - which is used consistently to indicate that this is a mesh-global address. The next two chunks are the longitude and latitude, respectively, in whatever precision a chunk affords across its respective scope. These first three chunks make up the network prefix that defines one network as distinct from another. How much geographical accuracy does this imply? Just enough to indicate where the "heart" of a network is, or was traditionally. A chunk can represent any number from 0-65534, because it can represent up to 65535 unique numbers and we start at 0. So, longitude can be expressed as a number of degrees "moved east" of the prime meridian from 0-360. This means the difference between each integer in a longitude chunk is 360°/65535, or .005493°. At the equator, where a degree represents the longest distance, that works out to about .4 miles [1]. For any other latitude, however, precision is better than that. Latitude, which goes from -90 to +90, can be represented as a 0-180 number where the equator is at 90, which works out to .002747° precision. So, competing networks in the same area can have slightly different network prefixes, while still each being more or less accurate (because networks are big and amorphous) while the precision isn't enough to pinpoint any individual node of the network, which I'd say is a happy medium. Longitude comes first for easier routing, since inter-network "send it east or send it west" questions seem more likely to me to come up for most switches based on the geography of the continents and the nature of the existing backbone ring of the internet. The remaining chunks can be chosen according to whatever algorithm the network administrators feel like. "Idiot devices" that aren't consciously part of the mesh will generally just put up and shut up with whatever DHCP gives them anyways, so that's not too concerning. If you decide to use client MAC address as part of it, that only leaves chunk 4 left to be set, and you can use the first four digits of the md5 hash of the MAC for that if you need something arbitrary yet deterministic. Every network can have its gateways to the corporate internet, and be accessible from the outside through them. That way, you can have inter-mesh communication over existing internet in a lightweight way: your packet routes to a gateway in your network, then across the tubes, through a gateway at the destination network, and to the ultimate destination. No packet encapsulation, no complex routing bullshit, just point A to point B. That's a simplistic overview, of course. It doesn't include shortcuts like nodes that act as part of multiple, neighboring networks, thus acting as gateways between the two. It doesn't consider IPv4 requests and service, which will probably require an AYIYA-based tunnel negotiation between the client and a gateway. But as a basic pattern, it provides consistency and efficiency between independent networks, which as far as I can see, is a vast deal more important than making one mesh to rule them all. I'm not sure what to make of it. Seems like someone trying to re establish classful addressing and not understanding routing, subnets, managed networks etc.