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*
On 10/05/2012 05:25 PM, Barry Shein wrote:
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.
Wasn't David Cheriton proposing something like this? http://www-dsg.stanford.edu/triad/ Mike
On 10/5/2012 9:11 PM, Michael Thomas wrote:
On 10/05/2012 05:25 PM, Barry Shein wrote:
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.
Wasn't David Cheriton proposing something like this?
http://www-dsg.stanford.edu/triad/
Mike
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#SECTION0004100...
On 6 Oct 2012, at 02:11, Michael Thomas <mike@mtcc.com> wrote:
Wasn't David Cheriton proposing something like this?
CCNx basically routes on URLs http://conferences.sigcomm.org/co-next/2009/papers/Jacobson.pdf Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/
On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein <bzs@world.std.com> wrote:
5. Bits is bits. I don't know how to say that more clearly.
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
It's occured to you that FQDNs contain some structured information, no? -b On October 5, 2012 at 21:47 bill@herrin.us (William Herrin) wrote:
On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein <bzs@world.std.com> wrote:
5. Bits is bits. I don't know how to say that more clearly.
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
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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 Sent from my iPhone On Oct 6, 2012, at 10:47 AM, Barry Shein <bzs@world.std.com> wrote:
It's occured to you that FQDNs contain some structured information, no?
-b
On October 5, 2012 at 21:47 bill@herrin.us (William Herrin) wrote:
On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein <bzs@world.std.com> wrote:
5. Bits is bits. I don't know how to say that more clearly.
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
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
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 October 6, 2012 at 11:06 george.herbert@gmail.com (George Herbert) wrote:
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 Sent from my iPhone
On Oct 6, 2012, at 10:47 AM, Barry Shein <bzs@world.std.com> wrote:
It's occured to you that FQDNs contain some structured information, no?
-b
On October 5, 2012 at 21:47 bill@herrin.us (William Herrin) wrote:
On Fri, Oct 5, 2012 at 8:25 PM, Barry Shein <bzs@world.std.com> wrote:
5. Bits is bits. I don't know how to say that more clearly.
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
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-- -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*
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 http://www.isen.com/papers/Dawnstupid.html, originally published as the cover story of ACM Networker 2.1, February/March 1998, pp. 24-31.
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. -- -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*
On Oct 7, 2012, at 12:52 PM, Barry Shein <bzs@world.std.com> wrote:
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.
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 http://bill.herrin.us/network/bgpcost.html) DDT provides a scalable, distributed database similar to DNS for looking up prefixes in LISP mapping servers.
On Sun, Oct 7, 2012 at 3:52 PM, Barry Shein <bzs@world.std.com> wrote:
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.
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Oct 6, 2012, at 11:35 AM, Barry Shein <bzs@world.std.com> wrote:
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.
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 Sent from my iPhone
----- Original Message -----
From: "Barry Shein" <bzs@world.std.com>
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.
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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
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
On Sat, Oct 6, 2012 at 6:14 PM, John Levine <johnl@iecc.com> wrote:
Hey, I've got a great idea. Let's lose this silly phone number portability nonsense and use phone numbers as routes.
You do not want to go down the hell hole that is SS7. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
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. -- -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*
On Sat, Oct 6, 2012 at 1:47 PM, Barry Shein <bzs@world.std.com> wrote:
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. On Sat, Oct 6, 2012 at 2:35 PM, Barry Shein <bzs@world.std.com> wrote:
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 -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 7 Oct 2012, at 18:17, William Herrin <bill@herrin.us> wrote:
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?
http://www.xent.com/FoRK-archive/july98/0041.html Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/
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*
participants (13)
-
Barry Shein -
Cutler James R -
David Miller -
George Herbert -
Jay Ashworth -
Joe Hamelin -
John Levine -
Michael Thomas -
Paul Vinciguerra -
Siegel, David -
Steven Noble -
Tony Finch -
William Herrin