ipv6 classful addressing with mesh?

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Sun Apr 1 01:47:35 UTC 2012


On Sat, 31 Mar 2012 19:35:05 -0500, Charles N Wyble said:

> 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
yadda 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
12  te0-1-0-5.ccr21.iad02.atlas.cogentco.com (154.54.2.50) [AS174]  40.638 ms te0-1-0-1.ccr21.iad02.atlas.cogentco.com (154.54.26.130) [AS174]  40.195 ms te0-3-0-5.ccr21.iad02.atlas.cogentco.com (154.54.41.230) [AS174]  43.299 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
of address space. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120331/fc26d590/attachment.sig>


More information about the NANOG mailing list