Theodore Ts'o wrote:
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.
The market demand is for stable addresses that can be routed globally.
That does not mean that the network manager wants to globally route
every prefix.
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?
The market demand is for address space that is STABLE. This stability
must isolate the network manager from the whims of any ISP, as well as
prevent the network manager from being locked into a provider to avoid
the cost of renumbering. That does not equate to a demand that every
prefix be globally routed, or that every node be globally accessible.
The network manager demands the control to decide that.
The IETF app community is demanding that to keep their view of the world
pristine and simple, they get to define the world as a flat routing
space, and claim they are passing around opaque data structures, at the
same time they fully intend for the receiver to use the opaque object as
a topology locator.
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.
That scenario is inconsistent. You start with 'not do multihoming', but
then describe multihomed servers.
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....
I did not say that using an IP address was a sin, just that doing so
without understanding the topology that you are describing is a broken
model.
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.
I agree that PI is in market demand, and have a couple of personal
drafts on the topic. I saw this as a failing in the current PA or
Private, allocation model and figured we needed to get it dealt with.
It's certainly true that having a reliable end-point
identifier is critical. But I don't think the DNS is it.
One of my points awhile back was that the current DNS is not up to the
task, and neither are the other name resolution services. Those need to
be addressed at the same time as the applications that insist in doing
the work for themselves.
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".
I am saying that the app either needs to learn the topology, or pass the
task off to a service that has the means to learn it. Passing around
addresses that are useless is not an approach to solving the problem.
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.
Which simply points out we have work to do, that won't get done by
avoiding the issue.
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.
So the IESG needs to task the DNS community with fixing it. The reality
of the deployed network is that the topology is inconsistent from
different perspectives. If all the 'identifier to topology' resolving
processes expect the world to be flat, they are simply broken.
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.
Or even 20 years ago. The issue was ignored in the past because the
demand was low enough to allow that.
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".
8+8 and similar schemes suffer one of the same problems you are
complaining about. To make them work, the network needs a very fast
converging, global, identifier to locator mapping service. Mangling the
address field in the packet only allows the app to use part of the
address for the identifier. There is no reason that the identifier has
to be part of the address.
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.
The problem will not be solved by PI addressing. I don't care if apps
pass around addresses, as long as they are doing the work to make sure
the address is consistent with the topology the app is intentionally
describing. If the app is not going to learn about topology (and I agree
the app shouldn't) it needs to rely on a service that has the means to
do the job. We agree, the current DNS is not up to the task.
Tony