Re: Assignment outside of CIDR blocks

[[e-mail]]

> 
> Noel,
> 
> >This is a rather interesting statement, since the original motivation for CIDR
> >was that class B's (/16's) were getting used up too fast. Are we now in a
> >situation in which we will go back (effectively; 16 ~= 18) to allocating class
> >B's? I mean, if you can't get a /20, or a /24, or whatever, that increases the
> >incentive to ask for a bigger (/18) chunk of the address space.
> > 
> >Needless to say, this will do nothing at all to solve the real problem which
> >is motivating the non-routing of longer prefixes, which is that routing tables
> >are getting too large. We won't be able to route 40K /18's any better than we
> >can route 40K /20's. 
> 
> Observe that by requiring registries to allocation blocks of /N (where
> N may be 16 or 18) or larger (means shorter prefixes), imposes an upper
> bound (at most 2^N) on how many routing entries could be created out
> of these allocations, which in turn bounds the growth of routing
> tables due to new allocations. And that is precisely what we need to
> accomplish.

	The better way to do this is to have the service providers
	-charge- for route entries, not forcing delegation registries
	to respond to something over which they have no control.. ie
	the size/number of routing entries.
> 
> 
> > What is especially ironic is that this just increases
> > *another* problem, which is running out of address space as a whole.
> 
> This observation is only partially correct.  You're certainly correct
> that this could speed up a situation where the Internet registries
> would run out of unallocated addresses, and thus would not be able to
> allocate new addresses. However, from this it does not follow that IPv4
> addresses would not be available at all -- they just would not be
> available from the Internet registries. However, the addresses would be
> available from some other sources (need not be registries).  For more
> on this see RFC1744 by Geoff Huston.

	Thus handing over the total IPv4 space to providers.  Which
	gives us -NO- room for any changes in the future.  The better
	choice is to let address delegation registries worry about
	conservation of address space and let providers worry about
	prefix announcement.  Again, the right way to do this is:

		- Charge for routing prefixes
		- Delegate only the space needed, on demand
		- Require the return of address blocks when new
		  delegations are done.
		- Note that no prefix, of any size, may be globally
		  routable.
--bill