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