North American Network Operators Group Date Prev  Date Next  Date Index  Thread Index  Author Index  Historical Re: 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 badlydistributed 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
