RE: IPv4 address length technical design

["Siegel, David" <Dave.Siegel () level3 com>]

I'll identify myself as the person who asked you the question privately.

Unfortunately, Barry, I still don't see a problem statement in your response.  It sounds to me as though it really is 
nothing more than an interesting thought experiment, and there's nothing wrong with that at all as long as we all 
acknowledge the purpose of the discussion.  :-)

Dave


-----Original Message-----
From: Barry Shein [mailto:bzs () world std com] 
Sent: Friday, October 05, 2012 6:25 PM
To: nanog () nanog org
Cc: Barry Shein
Subject: RE: IPv4 address length technical design


> While this is an interesting thought experiment, what problem are  > you trying to solve with this proposal?

(asked privately but it seems worthwhile answering publicly, bcc'd, you can id yourself if you like.)

Look, as I said in the original message I was asked to speak to a group of young "hackers" at the HackerSpace in 
Singapore.

I wanted to be interesting and thought-provoking, make them think through how this stuff works for an hour or two, 
encourage them to poke holes in it, etc. It was one of the audience who pointed out the potential MTU problem.

What problem does it solve, potentially?

0. Despite fears expressed herein I am not single-handedly planning to convert the worldwide internet to this over the 
weekend. I'm going to need some help :-)

1. It eliminates the need for DNS in its generally used form.

Sure, we've overloaded DNS with other functions from SPF -- in fact it was Meng Weng Wong, inventor of SPF, who 
graciously invited me to speak -- to whatever. But that's begging the point, there's nothing interesting here about 
distributed, lightweight databases other than eliminating one. Keep the DNS protocol per se for those things if you 
like.

But given this you won't need to translate between host names and addresses which is really what DNS was invented to do.

2. It makes "addresses" more transparent to humans, particularly when you consider ipv6 addresses as typically 
displayed (hex.) Is this an important goal? Not sure, but it's certainly true.

3. It's a transfinite space.

That just means that like Dewey Decimal etc it can be arbitrarily expanded, you can add more levels or even stick 
levels in between plus or minus some rules regarding SLDs/TLDs, and other rules which might or might not be imposed 
(see #4).

But its total address space is as large as you allow a payload, there is nothing inherent in the scheme that limits the 
addressing other than the permutation of all acceptable Unicode glyphs I guess. But since one can also have numeric 
parts and the set of integers is infinite (that's tongue-in-cheek, somewhat.)

4. Also, because it's transfinite it's arbitrarily segmentable.

Again, that just means you can impose any meaning you like on any substring or set of substrings. So for example 
host.gTLD is generally taken to be something of some significance, or host.co.ccTLD, and that sort of idea can be 
applied as needed, or not at all.

5. Bits is bits.

I don't know how to say that more clearly.

An ipv6 address is a string of 128 bits with some segmentation implications (net part, host part.)

A host name is a string of bits of varying length. But it's still just ones and zeros, an integer, however you want to 
read it.

The discussion I was responding to on NANOG involved how we got here and where might we be going.

I brought up an idea I'd worked out somewhat and have even presented in a small but public forum as being a possible 
future to consider further.

Now you can go back to your regularly scheduled Jim Fleming guffawing.

-- 
        -Barry Shein

The World              | bzs () TheWorld com           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*