# ipv6 classful addressing with mesh?

So I came across this post the other day and wanted to see what folks

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.

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.

I'll bite. Is 60 Hudson 0.4 miles wide?

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.

No, it's somebody trying to re-invent geographical routing and not understanding yadda

The traceroute from my apartment to my office, a 20 minute bike ride iin the real world:

traceroute -A 192.70.187.198
traceroute to 192.70.187.198 (192.70.187.198), 30 hops max, 60 byte packets
1 192.168.2.1 (192.168.2.1) [AS8151/AS28513] 1.491 ms 1.452 ms 3.909 ms
2 71.62.120.1 (71.62.120.1) [AS21508] 18.133 ms 18.203 ms 37.221 ms
3 te-8-2-ur01.blacksburg.va.richmond.comcast.net (68.85.71.97) [AS20214] 18.002 ms 17.986 ms 17.959 ms
4 te-8-3-ar01.staunton.va.richmond.comcast.net (69.139.165.161) [AS33287] 21.101 ms 21.075 ms 21.047 ms
5 te-8-1-ar01.chesterfield.va.richmond.comcast.net (68.86.173.165) [AS21508] 29.087 ms 29.089 ms 29.029 ms
6 te-0-1-0-0-cr01.charlotte.nc.ibone.comcast.net (68.86.91.113) [AS7922] 38.882 ms 46.911 ms 46.916 ms
7 pos-3-14-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.85.213) [AS7922] 43.328 ms 45.617 ms 45.602 ms
8 nyc-e5.nyc.us.net.dtag.de (68.86.88.186) [AS7922] 45.585 ms 45.563 ms 45.540 ms
9 te4-2.ccr01.atl02.atlas.cogentco.com (154.54.10.233) [AS174] 42.049 ms 42.978 ms 42.959 ms
10 te0-0-0-1.ccr21.atl01.atlas.cogentco.com (154.54.0.165) [AS174] 41.061 ms 41.088 ms 41.097 ms
11 te0-5-0-7.ccr21.dca01.atlas.cogentco.com (154.54.42.193) [AS174] 40.750 ms te0-0-0-7.ccr21.dca01.atlas.cogentco.com (154.54.28.213) [AS174] 40.914 ms te0-0-0-3.ccr21.dca01.atlas.cogentco.com (154.54.28.201) [AS174] 40.878 ms
13 38.127.193.146 (38.127.193.146) [AS174] 43.281 ms 43.171 ms 43.208 ms
14 isb-7606-1.vl155.cns.vt.edu (192.70.187.148) [AS1312] 48.902 ms * *

Quite the little trip - north to Staunton, south to Atlanta, north to DC,
south to B'burg again, and I dunno WHAT happened at hop 8.

Every single person who suggests geographically-based routing or addressing
fails to understand that there's no cable connecting AS21508 to AS1312. And
there's likely to never be one (we invited all the local providers to peer,
several did accept because it lowered their upstream transit costs, Comcast
apparently didn't see the added complexity as being worth the infinitesmal
savings it would get them at their Cogent interconnect). So sending packets to
21508 because it's geographically "close" and hoping it will get to 1312 (or
vice versa) is a fool's errand. And if you're not basing routing decisions based
on the geographic address, who *cares* if the address reflects location? At
that point, you're much better off basing my IP address off the fact that I'm
a Comcast customer and Comcast probably knows how to get packets to
me.

I'll overlook the little detail that trying to use latitude and longitude as the
basis for IPv6 addresses ends up wasting literally an entire Pacific's worth