On Wed, Apr 30, 2003 at 01:31:50PM -0700, Tony Hain wrote: > The reason I say this is about reachability is that even with unique > addresses, applications will fail when they choose to pass 'an opaque > identifier' around, while they simultaneously assume that the content is > a valid topology locator at the receiver. The arguments claim the need > for opaqueness as an application simplifier on one hand, at the same > they insist that the topology match their perspective of a flat routing > space. The real network is not a single flat routing space. And this is where we disagree. For better or for worse, the market is demanding that IP addresses that can be treated as belong to a single flat routing space. How else do you explain the demand for provider independent addresses, and people punching holes in CIDR blocks so they can have have multihoming support for reliable network service? One solution for that would be to not do multihoming, and simply have servers live on multiple IP addresses belonging to multiple ISP's, and use multiple DNS 'A' records in order to provide reachability. I suspect that would be Tony's solution about what we should be doing today. This is perhaps workable for short-term http connections, but it's absolutely no good for long-term TCP connections, which won't survive a service outage since TCP commits the "sin" of using IP addresses to identify its endpoints, instead of using DNS addresses.... But whether this is the reason, or the whether there are other reasons why the "solution" of killing off provider independent addresses and letting the DNS sort it out has been perceived as unacceptable, it's pretty clear that the market is spoken. Even as people have been wagging their fingers and saying "horrible, horrible", customers are demanding it, and ISP's are providing it. This is the situation in IPv4, and I very much doubt the situation is going to change much in IPv6. It's certainly true that having a reliable end-point identifier is critical. But I don't think the DNS is it. The DNS has been abused in many different ways, and very often, thanks to split DNS games, and CNAMES, and all the rest, the name which the user supplies to the application is also not guaranteed to be a name which can be utilizable by C when B wants to tell C to connect to A: > ---- A ---- > | I > | n > | t > I e ---- C > 2 r > | n > | e > | t > ---- B ---- Tony is basically saying, "IP addresses don't work for this, so let's bash application writers by saying they are broken, and tell them to use DNS addresses instead". Well, I'm here to point out that DNS addresses don't work either. Applications get names such as "eddie.eecs", and even when they get a fully qualified domain name, thanks to a very large amount of variability in how system administrators have set up split-DNS, there is no gauarantee that a particular DNS name is globally available, or even globally points at the same end point. So if IP addresses are not a flat routing space, DNS names are not a flat naming space, either. I struggled for a while to come up with ways of coming up with a "canonical DNS name" which could be passed around to multiple hosts many years ago when I was trying to come up with a convenient way to construct canonicalized, globally usable Kerberos principal names from host specifiers that were supplied by the user on the command line. We ran up against the same problem. Fundamentally, the DNS wasn't and isn't designed to do this. Now, I suppose you could say that the people who "broke" DNS are fault, but there are also people who would say that the people who broken the flat routing space assumption (which while not universally true was true enough for engineering purposes) are a fault instead. Perhaps a more constructive thing to say is that the original Internet architecture --- and here I mean everything in the entire protocol stack, from link layer protocols to application level protocols --- were not well engineered to meet the requirements that we see being demanded of us today. This is why I believe that ultimately 8+8 is the most interesting approach. As the old saw goes, "there is no problem in computer science that cannot be solved by adding an additional level of indirection". What we need is something that sits between DNS names and provider-specific IP addresses. That is a hole in the architecture which today is being fixed by using provider-independent addresses, much to the discomfort of router engineers. Another solution, which has been articulated by Tony, is that we should sweep all of this dirt under the DNS carpet instead, and force the application writers to retool all their implementations and protocols to pass DNS names around instead. But the DNS really isn't suited to handle this. What we need is something in-between. - Ted
