* We don't have a routing architecture that is
independent of the structure of IP addresses. I wish we
did. I think the fact that we don't is going to lead us
into [other] very serious problems in the long term.
But the fact remains that we don't have anything
resembling an IP-address-independent routing fabric
proposal on the table, certainly not one that is
complete enough to be plausible.
* We are seeing more and more requirement for
multihoming of one type or another, whether you count
community wireless schemes or other small-group or
small-ISP models into the mix or not.
One implication of the first problem is that one can't solve the
second one by giving everyone who wants to connect to more than
one provider independently-routable PI space. Now, if we don't
come up with a solution to both of those problems, it doesn't
make any difference what features are in IPv6, because IPv6 will
fail, and it will fail because the Internet --at least the
Internet as we know it-- will fail. I think we even know what
the alternative looks like, at least in general terms, with
islands of walled gardens, each with independent address spaces,
and connected by bilateral agreements being the most likely of
those alternatives. Those proposals have been around for years,
we know what they look like, and they don't provide the
edge-oriented, end-to-end, "dumb" network we all believe is the
core strength of the Internet.
I don't doubt this, but it's fairly clear to me that having multiple
addresses per host and expecting hosts to make decisions about which
prefix to use is also highly undesirable - in the sense that it will
drastically limit the set of applications that can work well. But yes,
we have more of a chance of things working if they're all using a
single shared address space, than we do with disjoint address spaces.
I also don't see how this problem is any different between IPv4 and
IPv6, except that we might eventually expect IPv6 to scale to more
prefixes than IPv4. Yes, v6 hosts have the code to handle multiple
prefixes and addresses, but that doesn't mean that the apps can deal
reasonably with them. And in my experience even the simplest apps fail
to deal reasonably with multiple prefixes. (trial-and-error, waiting
tens of seconds to timeout before proceeding to the next address, is
not reasonable)
But we need to distinguish between what we can do in the short term and
what we need to do in the long term. In the short term our choices are
either to allow some form of provider-independent addressing (with all
that this means for the scalability of routing) or to expect hosts and
apps to deal with multiple prefixes. Which choice is better is not
obvious - it depends on whether you want to optimize IPv6 for easy
deployment or eventual scalability. Your answer to this question
probably depends on what layer you live at.
In the longer term we need to develop a way of doing a mapping from
location names or endpoint names to paths through the network, one that
preserves the uniqueness and structure of IPv6 addresses.
At least so far, "give every host one address and let the
network (the routers?) sort out the routing" seems to me to
reproduce the current IPv4 situation. That doesn't seem to me
to be a solution because it:
* Assumes that everyone who has a LAN that they want to
connect to multiple providers will have routable PI
space. Or
* Assumes that everyone who has a LAN that they want to
connect to multiple providers will be able to do so by
punching holes in CIDR blocks.
To my routing-naive mind, two mechanisms seem worth investigating:
- One is a mapping at the BGP layer from what I'll call path-independent
prefixes to path-specific prefixes. e.g. BGP could propagate
information of the form "route prefix X as if it were prefix Y".
Routers wouldn't have to compute routes for prefix X, they could just
compute routes for Y and then use the same entry for X as for Y in the
fowarding table. This lets the number of prefixes grow to some degree
without directly increasing the complexity of routing computations, as
long as the set of distinct destination networks as viewed from the core
did not get larger. In effect it would allow non-adjacent prefixes to be
aggregated for the purpose of route table computations. Which is not to
say that this comes for free, but it would let us to some degree move
toward a routing structure for the core that was independent of the IP
addresses used by hosts - in effect hosts and routing would use
different portions of the IP space, though some amount of overlap could
be tolerated.
- A mobileIP-like scheme for border routers, that could issue redirects
for prefixes as well as individual IP addresses. So packets for a
particular destination prefix would initially go to "home network
agents" that could live anywhere on the network (including a database
distributed across multiple exchange points in diverse locations, all of
which advertise reachability via BGP) but which (in addition to
forwarding initial packets) would return redirects for entire prefixes
that caused subsequent packets to be sent to the "in care of prefixes".
These redirects would be intercepted and acted on by routers near the
source, not (or not only) by the sending host. Yes, it would still
require tunneling, or MPLS, or some other way of telling the network
"route this traffic to here rather than to the destination address in
the IP packet; that's for use after the packet exits our network". But
there are lots of ways to do this, and perhaps they'll become more
widely available over time.
And for those who think these ideas are naive, keep in mind that I did
say they're not near-term solutions, and that in the near term we're
stuck with less sophisticated mechanisms. But we need to insist on
global addressing now so that we have a way to move to better routing
systems once we do solve the problems.
I don't see why it's unrealistic to have a global address
space that encompasses all hosts that are connected any
network that is connected to the Internet, and to expect
applications to use that global address space. I agree that
we cannot expect complete or near-complete connectivity.
But, if we have a one-address-per-host global address space --
which I think is what you are asking for-- and don't have
near-complete connectivity, then we are either going to see
rising times to set up the typical TCP connection, and a lot of
UDP attempts fall off the edge, or we are going to need a lot
more PI space. I don't see realistic alternatives for the
reasons discussed above. Do you? And, if so, what are they?
I doubt we'll see a one-size-fits-all kind of solution any time soon.
Some sites will be able to make do with multiple advertised prefixes,
perhaps with clever DNS tricks to try to minimize the connection
failures (yeech). Other sites will be able to tolerate a single
provider. Others will demand PI space and perhaps get it. Maybe they'll
have to buy an ISP, or masquerade as one, to accomplish this. I've
always thought the distinction between an ISP and a multi-homed,
multi-sited customer was fairly arbitrary. I could imagine an
arrangement where limited-time leases for use of some amount of what was
effectively PI space (even if it came out of providers' allocations, it
could be routed to multiple providers) was auctioned off to the highest
bidders, like radio spectrum. Or maybe the problems will create a demand
for more stable/clueful/expensive IP routing service.
Or maybe the public Internet will just degrade to the point that it's
not useful for very much. I'm not discounting that possibility, but
neither do I want to dwell on it.
In my mind, the reason we need feedback from the network to
applications about when applications try to violate
administrative prohibitions on use of the network is not so
that applications can try to route the messages through other
paths (though it does enable that to some limited degree) but
so that applications can provide accurate indications to their
users as to why they're failing.
Keith, while I'm very much in favor of accurate feedback,
messages with the ultimately semantics of "you lose" have a long
and well-documented history of being unpopular with users.
Granted. But there is no way that the reliability of internet
applications can improve unless the network can provide such feedback
to *somebody*. Now maybe it shouldn't always be the user, but the
application, or the user's network administrator, or the application
author/vendor. to some degree it depends on the application. But
nobody can do anything about the problem without some indication that
the problem exists and some way to distinguish one kind of problem
from another.
I'd rather focus on getting the network to work better and more often,
while reporting accurately on failures if there is no alternative but
to fail.
No question there, but if the failure is due to an administrative
prohibition (which is where I thought this started), it's hard
to see what it means to have the network work better and more often -
unless it's to discourage use of packet filtering. :)
I don't see why TCP and/or UDP stacks can't provide such
interfaces to applications, even though of course this means
that there will need to be other interfaces (invisible to
applications) between TCP and IP and UDP and IP to pass that
information upstream.
They can't provide it because we don't have a model, or set of
abstractions, for providing it. If it is important, maybe we
had better get started.
Has anyone made a list of important core problems that need to be
worked on?
Keith