nanog mailing list archives
Re: worse than IPv6 Pain Experiment
From: Owen DeLong <owen () delong com>
Date: Wed, 9 Oct 2019 15:28:09 -0700
On Oct 9, 2019, at 14:43 , bzs () 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
Current thread:
- Re: IPv6 Pain Experiment, (continued)
- Re: IPv6 Pain Experiment William Herrin (Oct 09)
- Re: IPv6 Pain Experiment Nicholas Warren (Oct 08)
- Re: IPv6 Pain Experiment Valdis Klētnieks (Oct 08)
- Re: IPv6 Pain Experiment bzs (Oct 08)
- Re: IPv6 Pain Experiment Masataka Ohta (Oct 08)
- Re: IPv6 Pain Experiment Owen DeLong (Oct 08)
- Re: IPv6 Pain Experiment bzs (Oct 09)
- Re: IPv6 Pain Experiment Owen DeLong (Oct 09)
- Re: worse than IPv6 Pain Experiment John Levine (Oct 09)
- Re: worse than IPv6 Pain Experiment bzs (Oct 09)
- Re: worse than IPv6 Pain Experiment Owen DeLong (Oct 09)
- Re: worse than IPv6 Pain Experiment Matt Harris (Oct 09)
- Re: worse than IPv6 Pain Experiment Owen DeLong (Oct 09)
- Re: worse than IPv6 Pain Experiment Masataka Ohta (Oct 09)
- Re: worse than IPv6 Pain Experiment Valdis Klētnieks (Oct 09)
- Re: worse than IPv6 Pain Experiment John R. Levine (Oct 09)
- Re: worse than IPv6 Pain Experiment William Herrin (Oct 09)
- Re: worse than IPv6 Pain Experiment bzs (Oct 10)
- Re: worse than IPv6 Pain Experiment Masataka Ohta (Oct 09)
- Re: worse than IPv6 Pain Experiment Tony Finch (Oct 10)
- RE: worse than IPv6 Pain Experiment Kevin Menzel (Oct 10)