CIDR FAQ

Owen,

  > > Conclusion:
  > > 
  > >    In the area of routing aggregation IPv6 will do for us *exactly the same* 
  > >    as what IPv4 does. 
  > > 
  > With one notable exception.... No allocation legacies.  That is there aren't
  > any old badly-distributed ipv6 addresses floating around.
doesn't the transition strategy foresee to embedded the old cluttered IPv4
space into the new supposedly clean IPv6 megaspace...
Thus I suspect the allocation legacy will be inherited.
While I agree with Yakov that we need to worry about the new allocations,
I think that the legacy is large enough that some garbage collection
would be well advised - and could be important for survival under current
and future growth.

  >                                                            This means that
  > ipv6 aggregation should be substantially more effective than ipv4 CIDR has
  > been.
I guess it can be made more effective, because distributing address space
over service providers can be done in ways that allow much more space
for growth without renumbering into a new bigger contiguous allocation.
With the current scarce IPv4 space forces registries to apply slow start
allocations for providers - resulting in multiple prefixes for one
provider (or the need to renumber more or less complete provider spaces).

Considering this (on the very pessimistic side) two questions come to mind:

- it seems to me that so far we only have considered to ask for the
  renumbering of customer networks (when they switch providers, or to kindly
  release large, inefficiently used spaces), and maybe small access
  providers.
  Will things get so tough that I will have to ask my customers
  to renumber because I need to switch from a clutter of small spaces
  (as built in slow start and and with allocations not larger then /16)
  into a larger single prefix space?  - even when I started out with
  provider aggregatable space, and tell customers that address space
  cannot be moved to another provider and I'm warning them that using their
  old numbers we cannot guarantee "full" connectivety.

- if large scale renumbering needs to happen, the problem seems to be analog
  to memory allocation systems (on the fly); I faintly remember that
  this could mean another factor of ineffeciency for the use of space.
  How much will this reduce the expected life time of the IPv4 space?
  (well, of course, under exponential growth it will be not very much)

BTW we would need to recognize the need for large scale renumbering a couple
of years ahead - else we will not have the tools to do it, not to think
about the need to educate network and systems administrators...

For a more positive perspective:
Can we assume that the current "end of the line" routers can be made
to deal safely with 45,000 routes?  (Seems 64 MB is ok for this; probably
somewhat faster processors would be nice to deal with the updates and
flapping;  how much more thrust would be needed to deal with the
computational complexity of the routing problem at this level?)

Considering that 45,000 is already 75% of all possible /16 prefixes,
could we define the goal of limiting the number of prefixes to 45,000
or some other (but firmly defined) close number?

Assuming
- we make wise use of space on the new allocations,
- we really drop long prefixes for old cluttered space when we get close
  to the limit,
- the typical topology does not change in ways that are require much
  more router ressources,
- we decide quickly,
- and we start communicating this to planners and administrators,
I think there could be good chance to survive until a high percentage of v4
space is consumed (and the expected life time of our big boxes might
be higher and more secure).
This should be sufficient for v6 to survive for some time as well;
but of course the question of the limit of number of routes needs
to be revisited with some different parameters - and hopefully some
additional helpful tools, and maybe some new algorithms.

  Ruediger