worse than IPv6 Pain Experiment

Owen DeLong owen at delong.com
Wed Oct 9 22:28:09 UTC 2019



> On Oct 9, 2019, at 14:43 , bzs at theworld.com wrote:
> 
> 
> OK OK OK.
> 
> Can I summarize the current round of objections to my admittedly
> off-beat proposal (use basically URLs rather than IP addresses in IP
> packet src/dest) as:
> 
>  We can't do that! It would require changing something!

No… You can summarize it as “Doing things that way would break lots of
useful things without yielding much in the way of practical benefit.”

> I've no doubt many here are comfortable with the current architecture.

Well, sure, but I bet most of us would jump at the chance for something
better if we actually saw such a thing. I’m all for trying out the wild and
crazy ideas that might yield benefit. I just don’t think that what you have
proposed so far actually qualifies on that last part.

> Bits is bits.

Yes and no. At the lowest possible layer, a bit is a bit is a bit. However,
when you add abstraction and assign meaning, such as ASCII characters,
double-precision floating point, URLs, IPv6 (or if you must, IPv4) addresses,
OSPF Areas, Autonomous System Numbers, etc., then groups of bits start
to take on additional significance.

It matters how we represent, process, interpret, store, and manage those bits.

Different methodologies of each of those tasks are more or less appropriate
for each given application. For example, a straight twos-compliment binary
numeric interpretation of a 64-bit wide field with the MSb for sign and the
remaining bits as significant digits is fantastic for integer arithmetic, but nearly
useless for arbitrary precision manipulation of fractions. On the other hand,
IEEE 754 floating point format of 32 bits where the MSb is for sign, the next
8 bits represent the exponent, and the remaining 23 bits represent the
significant digits (“fraction” in IEEE terms) is very useful for arbitrary
precision manipulation of fractions, but not at all good at integer math,
especially for integer numbers that require low order precision, but have
values greater than 2^23.

Similarly, the current structure of IPv6 (and if you must, IPv4) addresses
provides tremendous utility for moving packets about the internet. It’s not
great at providing human-readable destination addresses. It’s also not
great at providing geographic location information. Both of those are tasks
for which those particular representations were never intended.

There’s a reason that we have compact cars and B-trains (double
trailer tractor-trailer rigs). A compact car is lousy at moving massive
quantities of products. OTOH, a B-Train doesn’t fit in the average
parking space very well and is hard to maneuver down most residential
streets. (It also gets really lousy gas mileage for single-person transportation).

We purpose build things in different ways to optimize them for different tasks
throughout human history. Addresses are no different.

> URLs are, to a machine, just bit strings though they do incorporate a
> hierarchical structure which isn't that dissimilar from current
> network/host parts of IP addresses.

Well, yes and no. For example, it’s not uncommon for a domain, say
toyota.com, to be widely distributed across multiple networks of wildly
different topologies.

With the exceptions of anycast and multicast, it’s very unusual (I’d even
venture to say unheard of) for a globally scoped address to be usefully
deployed on multiple connected disparate networks without some
sort of translator in the middle).

Neither end of a URL provides anything resembling network topological
hierarchy.

> URLs are an obvious candidate to consider because they're in use, seem
> to basically work to identify routing endpoints, and are far from a
> random, out of thin air, choice.

In reality, you’re not really talking about URLs here, even. You’re talking
about DNS host names. (The part before the // isn’t really part of what
you want to consider in your network routing scenario, neither is anything
that comes after the first /).

It’s not that we couldn’t use some form of hierarchically structured human-
readable name for this purpose… It’s that using DNS host names _REALLY_
wouldn’t work well.

> Given the vast improvements in hardware since we last seriously
> thought about this (ca. 1990, IPv6) perhaps this worship of
> bit-twiddling and bit-packing may be a bit (haha) like those who once
> objected to anything but machine language programming because HLLs
> were so inefficient!

Or, perhaps, it’s not actually a love of bit-twiddling so much as a recognition
that there are serious flaws with the idea of trying to use DNS host names
for routing decisions.

Come back with a more useful naming scheme that takes topology into
consideration and lines up where routing decisions need to, and let’s
discuss it more seriously. Continue pounding on DNS host names and
you’re not going to make much headway because, well, it’s not quite
the dumbest thing I’ve ever heard, but it isn’t that far off.

> P.S. It was from a talk I gave in Singapore to the local HackerSpace
> and intended to provoke thought and discussion but not just "no, we
> can't do that because that's not the way we do things.”

I think dismissing the comments here as “no… that’s not how we do things”
really fails to take proper heed of some of the comments.

Owen




More information about the NANOG mailing list