North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: OMB: IPv6 by June 2008

  • From: Joe Abley
  • Date: Thu Jul 07 13:43:18 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