idea for ipv6 allocation scheme

Thomas Keats tkeats@rainbowcomputersystems.com
Fri, 3 Aug 2001 16:28:04 -0400 (EDT)


Heh, Really, the idea I think would have promise, would be a conspirist's
nightmare ;)

Thomas


-------------------------------------------------
-- From the Desk Of ------------- Thomas Keats --
--------------- RainbowComputers.ca -------------
----------- RainbowComputerSystems.com ----------
-------------------------------------------------
---- AMD -- Intel -- Pandex -- DFI -- ASUS ------
---- MSI -- Creative Labs -- Maxtor -- GVC ------
-- Red Hat -- Slackware -- Debian -- Microsoft --
-------------------------------------------------


On Fri, 3 Aug 2001, Robert J. Rockell wrote:

> As if the Privacy people weren't paranoid enough already :)  The MAN will
> surely know what they are up to then...
> 
> Thanks
> Rob Rockell
> Principal Engineer
> SprintLink Europe/Asia
> 703-689-6322
> Sprint E|Solutions: Thinking outside the 435 box
> -----------------------------------------------------------------------
> 
> On Fri, 3 Aug 2001, John O Comeau wrote:
> 
> ->Since I haven't made a complete fool of myself on the net for a few months
> ->now, it's time to throw caution to the winds and toss out an idea I got
> ->yesterday morning in that semiawake state when lots of ideas of dubious
> ->quality enter the impressionable mind. This one seemed like a winner.
> ->
> ->Use street addresses as internet addresses. It's inherently routeable, and
> ->extremely easy to implement, but frivolously wasteful of address
> ->space. Here's an example. Let's say a TLA is assigned for this in the
> ->spirit of 6to4; 2666. My address is 5555 Bogus St, Somecity, FL,
> ->US. Compressing out the spaces and punctuation to reduce the
> ->inefficiency, and assigning a planet code TA (Terra) to make this scheme
> ->last a few years, we get: 5555BOGUSSTSOMECITYFLUSTA. Now inverting the
> ->byte order, and prepending the TLA, we get &fATSULFYTICEMOSTSSUGOB5555
> ->which is 27 bytes long, still way too big. Even using RAD50 (remember
> ->that, anybody?) we could only get it down to 19 bytes. But, due to the
> ->hierarchical nature of this scheme, an entity such as FL (the state
> ->Florida) could help by providing two- or three-letter abbreviations for
> ->each city. And if necessary, each city could provide numbers for every
> ->named street. Numbers can then be packed into 16-bit unsigned small
> ->integers. Now my address is 5555 3333 St, SC, FL, US. Packed, that becomes
> ->&fATSULFCSTS33UU, 16 bytes. Now I have my unique internet address.
> ->
> ->Contrived? Of course. Possible to implement? I think so. Each level of the
> ->hierarchy could provide the scheme for compressing the next lower level's
> ->data. This could all be made available publicly in a way such that my Aunt
> ->in Bingham, Maine only needs to find out my street address and type it
> ->into a browser, and the browser can fetch the compression rules from each
> ->level of the hierarchy and generate the address, and she can then see my
> ->webpage.
> ->
> ->An address in China would begin &fATNC and the remaining 10 bytes could be
> ->Unicode (big5 would't go too far, would it?). I doubt if 5 characters
> ->would work either, but then again, that country, or city, or city block,
> ->could establish its own method of ensuring that every address can fit into
> ->the 16 bytes of an IPv6 address. Of course, the planet and country codes
> ->can be squished into a byte each, also.
> ->
> ->This is probably not precisely the best venue for this discussion, but
> ->there are a lot of intelligent people on this list with the necessary
> ->diversity of viewpoints to give this a thorough beating. And if it meets
> ->dead silence, I'll know it was a complete waste of time typing this in.
> ->
> ->Thanks in advance - jc
> ->
> ->jcomeau@world.std.com aka John Otis Lene Comeau
> ->Home page: http://world.std.com/~jcomeau/
> ->Disclaimer: Don't risk anything of value based on free advice.
> ->"Anybody can do the difficult stuff. Call me when it's impossible."
> ->
>