IPv4 address length technical design

Mon Oct 8 18:58:51 UTC 2012

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 at world.std.com] 
Sent: Friday, October 05, 2012 6:25 PM
To: nanog at 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 at 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*