OMB: IPv6 by June 2008
Joe Abley
jabley at isc.org
Thu Jul 7 17:37:34 UTC 2005
On 2005-07-07, at 12:53, Alexei Roudnev wrote:
> We have relatively PI address space in IPv4, which works fine, even
> with
> current routers. No any problem to hold the whole world-wide
> routing with a
> future ones. Is it a pproblem keeping 500,000 routess in core
> routers? Of
> course, it is not (it was in 1996, but it is not in 2005 and it
> will not be
> in 2008 - even if you will have 1,000,000 routes). IPv6 schema was
> build to
> resolve problem which do not exists anymore (with fast CPU and
> cheap memory
> and ASIC's).
Whether or not you see DFZ state growth as a serious enough issue to
architect around depends on how much additional routing complexity
you see in the network's future. Maybe there's the potential for
50,000,000 routes in the DFZ if everybody who really wants to multi-
home is able to do so; maybe it's higher. Regardless, there's still a
point where the demand for routing slots will outstrip availability.
However, DFZ state bloat is not the only potential benefit to keeping
multi-homing state at the edge of the network.
Here's an example, based in a future in which shim6 is successfully
deployed in sufficient numbers of IP stacks that it can be considered
commonplace, and consumer IPv6 internet access is easy to come by.
This is a thought experiment; bear with me. I promise to shut up
about shim6 after this message.
I have some devices in my home which require Internet connectivity --
a handful of wireless base stations, some MP3 players, a couple of
TiVO-style-things, an xbox in the basement, a few VoIP phones, a few
laptops, etc. Maybe I even have the mythical Internet fridge, without
which no forward-looking IPv6 thought experiment would be complete.
Since I can get both DSL and cable modem service for not much money
(about $20/month each) and since I get grumpy when my Internet access
goes away, I decide to buy both DSL and cable modem service. The more
Internet-dependent devices I have in my house, the more attractive
this option is.
Both Internet access services are delivered to my house in the form
of small routers, which answer router solicitation messages each with
EUI-64 addresses out of different PA /64s (one per provider).
My various networked devices each get two addresses in this way. When
they talk to some remote device that has a shim6 element in its
protocol stack, I get all the benefits that I would expect to achieve
by multi-homing: if one provider goes down, I use the other one
without having to debug anything, or yank any cables, or answer any
difficult pop-up questions. Sessions that are established before one
provider dies continue to work afterwards. New sessions start up just
fine. When the provider comes back on-line, everything continues to
work. I probably don't even notice that the provider had a problem.
My providers don't have to care that I am multi-homing. They deploy
precisely the same infrastructure regardless of whether I am multi-
homed or not. They don't have to talk BGP to me. They don't need a
"multi-homing" product. I'm just a regular customer.
As a consumer, I don't even have to know what "multi-homing" is; I
just need to order two (or more) completely independent Internet
access services and have the installer plug them into the switch in
my basement that connects everything else together.
This picture seems like it could scale to many millions of multi-
homed end sites. It seems like it is eminently supportable. It seems
like the kind of thing people would like to buy, if they knew they
could.
If you compare this shim6/IPv6 picture to one in which every single
multi-homed end site needs PI addresses and to announce a unique
prefix into the DFZ in order to multi-home, then you either have a
system which doesn't scale or you don't have much multi-homing going on.
If you compare this shim6/IPv6 picture to one in which the locator
selection is done in NAT boxes instead of in the host protocol stack,
then you have the additional complexity of NAT boxes communicating
with each other to determine path reachability through their
respective uplinks; you have coordination issues between multiple NAT
boxes on an inside address ranges to us; you maybe even need some
ability in hosts to switch their default routes between NAT boxes
when paths through one stop working. And at the end of the day you
still have NAT, with the attendant protocol kludges built into every
P2P and telephony app to allow them squeeze around the middlebox
minefield.
Joe
More information about the NANOG
mailing list