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 :slight_smile:

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.

Wasn't David Cheriton proposing something like this?

http://www-dsg.stanford.edu/triad/

Mike

Hi Barry,

Bits is bits and atoms is atoms so lets swap all the iron for helium
and see how that works out for us.

You can say "bits as bits" as clearly as you like but however you say
it you'll be wrong. Bits are defined by the semantics of their use.
Any equality or inequality between one bit and another, and in fact
whether they can be meaningfully compared at all, is found in those
semantics.

Bits ain't just bits. Bits are information *in context.* Change the
context, change the bits.

Regards,
Bill Herrin

Not exactly. TRIAD is a proposal for distributing content names using a
new routing protocol (in addition to existing routing protocols instead
of as a replacement for existing routing protocols) such that one could
"Route a content request, based on its name, toward the closest server
for that name."(1)

The actual forwarding of packets/requests would continue to use IP.

TRIAD addresses issues with namespace size using Explicit Aggregation
into collections. (2)

-DMM

1. http://www-dsg.stanford.edu/slides/triad-content-netseminar/img15.htm
2.
http://gregorio.stanford.edu/papers/contentrouting/node9.html#SECTION00041000000000000000

It's occured to you that FQDNs contain some structured information,
no?

   -b

As I said earlier, names' structure does not map to network or physical location structure.

DNS is who; IP is where. Both are reasonably efficient now as separate entities. Combining them will wreck one. You're choosing to wreck routing (where), which to backbone people sounds frankly stark raving mad.

If you aren't willing to consider where / routing as a problem of equal importance ( not as end-user visible perhaps, but ultimately as important ), then you're just pissing around and not being serious about exploring future options.

George William Herbert

Well, George, you can take a new idea and run with it a bit, or just
resist it right from the start.

We can map from host names to ip addresses to routing actions, right?

So clearly they're not unrelated or independent variables. There's a
smooth function from hostname->ipaddr->routing.

Take an extreme but extremely common case, the home or small office
end user.

Those packets only have exactly one place to go, right? One default
route.

So why do they need to turn a host name into an IP address at all to
ship a packet? The first-hop route is always exactly the same for
every single packet.

Is this a good use of DNS computrons? Answering DNS inquiries for
every new connection for every single-routed host on the internet?

Van Jacobson had a similar observation vis a vis TCP and PPP header
compression, why keep sending the same bits back and forth over a PPP
link for example? Why not just an encapsulation which says "same as
previous"?

Now, how can that be generalized?

   -b

On Oct 6, 2012, at 2:35 PM, Barry Shein <bzs@world.std.com> wrote, in part:

We can map from host names to ip addresses to routing actions, right?

So clearly they're not unrelated or independent variables. There's a
smooth function from hostname->ipaddr->routing.

I would suggest that this is a bit optimistic and oversimplified.

The mapping between DNS names and IP addresses is not necessarily unique or commutative. One may change either arbitrarily, as long some "directory service" exists which contains the current mapping. In addition, multiple DNS names may map to one or more IP addresses and IP addresses do not necessarily map to unique routes or DNS names. These are not smooth functions.

If names and addresses are not independent, then any change in either would predicate a change in the another. That is apparently not the experience of most network providers. The only action required for a change in network name or address is to update the "directory service" used to map between name and address.

Is this a good use of DNS computrons? Answering DNS inquiries for
every new connection for every single-routed host on the internet?

Yes, it is. Most "new" connections are repeats of previous connections (I request mail from my IMAP servers several times each day) and the preponderance of caching resolvers make the effort and traffic trivial. Even in the absence of cached final DNS reply, putting the lookup burden on the end system rather than the "routing engines" should be a no-brainer.

In particular, adding caching of connection destinations within routing components would not only seriously burden (read, slow down) routing engines but is also a violation of the Stupid Network. David S Isenberg said, "In a Stupid Network, control passes from the center to the edge". See The Dawn of the Stupid Network, originally published as the cover story of ACM Networker 2.1, February/March 1998, pp. 24-31.

In article <20592.28334.622769.539587@world.std.com> you write:

It's occured to you that FQDNs contain some structured information,
no?

Hey, I've got a great idea. Let's lose this silly phone number
portability nonsense and use phone numbers as routes.

I mean, anyone who moves and takes his cell phone with him has
only himself to blame, right?

R's,
John

You do not want to go down the hell hole that is SS7.

No.

Not just no, but hell no at the asserted communativity there, Barry.

That's not even Wrong...

And that's the point.

DNS to IP is in no way a smooth function. Hell no, for many networks. It's only true for the boringest customers. Try actual enterprise endpoints, or service providers.

IP to Routing is not smooth at predictable scales. Yes, it's in blocks, but a top-down view is at best fractal discontinuity.

IP to routing is smoother in IPv6 but as routing has two components - physical location and net path - was made smoother in one only ( net path, and to the degree that's smooth in physical location by accident...).

George William Herbert

It's occured to you that FQDNs contain some structured information,
no?

It has occurred to me that the name on my shirt's tag contains some
structured information. That doesn't make it particularly well suited
for use as a computer network routing key. Or suited at all.

you can take a new idea and run with it a bit, or just
resist it right from the start.

Intentionally crashing the moon into the earth is a new idea. How far
should we run with it before concluding that it not only isn't a very
good one, considering it hasn't taught us anything we didn't already
know?

Van Jacobson had a similar observation vis a vis TCP and PPP header
compression, why keep sending the same bits back and forth over a PPP
link for example? Why not just an encapsulation which says "same as
previous"?

Now, how can that be generalized?

By observing that within a restricted subset of a problem domain there
may be usable techniques that aren't portable to the broader problem
domain. This is not news, and your comments have not bounded a subset
of the routing problem domain in a way that would make a discussion of
names as routing keys interesting.

Regards,
Bill Herrin

Ok, then let's take a step back, perhaps not permanently, and say DNS
resolution is only really useful for routers with more than just a
single default external route.

So DNS could be reduced to an inter-router only protocol, similar to
BGP in some sense.

I suppose one question is how do we discover non-existant hostnames
but we have strong analogues to that at the ICMP level already, host
unreachable etc, just another kind of error feedback. But I'll agree
that begs some thought.

As I said, the proposal was originally offered by me to a bunch of
young "hackers" in Singapore for the purpose of stimulating
discussion.

Back in the 80s when DNS was a fairly new idea and things like Google
were way in the future I remember suggesting on the TCP-IP list that
people grab a phone number they owned as a domain name and add
first_last as a mailbox so we could leverage the international phone
directory system to find each other.

For example something like barry_shein@0016176403067.com (maybe insert
a letter, all-digits wasn't allowed back then.)

I guess that sort of idea was eventually incorporated into telephone
number mapping but not clear how successful that is or if the intent
is really the same. I think there were other analogues?

  http://en.wikipedia.org/wiki/Telephone_number_mapping

But the idea has come up.

LISP DDT uses a lookup to determine EID location.

Ok, then let's take a step back, perhaps not permanently, and say DNS
resolution is only really useful for routers with more than just a
single default external route.

So DNS could be reduced to an inter-router only protocol, similar to
BGP in some sense.

LISP DDT uses a lookup to determine EID location.

We operate one of the DDT roots, and yes the difference is that LISP uses an on-demand pull mechanism, where the route is looked up and then cached until it ages out from inactivity. BGP pushes every route to peers and everyone running BGP pays a hardware tax for carrying each and every route. (See Bill Herrin's work at BGP Cost) DDT provides a scalable, distributed database similar to DNS for looking up prefixes in LISP mapping servers.

Ah. *This* is where you fell off the horse.

Nope; the first one isn't smooth; it's *completely arbitrary*.

The mapping is, in fact, DNS's raison d'etre.

The second one has a relatively smooth mapping *at any given point in time*,
but you can't fit a function to that; it is prone also to arbitrary changes
over time.

Cheers,
-- jra

There's no party in the neighborhood you're searching. Turn it upside
down, on the other hand, and you end up somewhere like TRRP.
http://bill.herrin.us/network/trrp.html

Regards,
Bill Herrin

http://www.xent.com/FoRK-archive/july98/0041.html

Tony.

CCNx basically routes on URLs

http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.pdf

Tony.