Re: Policy Statement on Address Space Allocations
At 11:47 1/25/96, Daniel Karrenberg wrote:
1) The initial allocation for a newly established local registry (ISP) *always* is a /19. There will be no discussion about this. This is fixed, cast in stone, immutable, ... you get the idea. In particular it will not be influenced by marketing predictions, amount of capital available or the shoe size of the lawyers visiting our offices. (NB: The value of /19 might change at some point, but the fact that every newly established registry gets *the same size* initial allocation will not.)
When you allocate this /19, do you do so at such a boundary that it can be converted to a shorter (/18-/17-/16-etc) prefix at a later date thus avoiding the need to assign another block or forced renumbering (ie: "We will give you a new /18 block and you have x months to return your old /19 [ie: They are given a 2nd /19 worth of numbers and they most move their old /19 into the other half of the new /18]). If done correctly, you can reclaim the over allocation of "reserved for expansion" blocks after reaching the top of the original CIDR block and then doing the 2nd pass of NEW assignments by halving the space between "phase 1" allocations (in those segments where there has been no expansion of the /19 allocation into a /18-etc).
From this it looks like the internic is allocating a large number of
Here's an interesting thought on the whole thing... I've sort of noticed that the opinion of several people is that the way that the internic allocates IP numbers is "space efficient". CIDR routing on the other hand is considered "routing table efficient". I felt like digging through 205.* and 206.*, at least at the start. I did a whois on 205.0.0.0 and then looked at the last used # in the allocated block, and then did a whois on that #. For CIDR blocks, I was jumping over the entire block, as listed in the whois. prefixes longer than /18. Am I wrong in stating that (assuming that Sprint's policy is unchangable) any IP numbers allocated with a prefix longer than /19 in 205 and /18 in 206 is essentially wasted space, which is unusable, at least if you want connectivity with sprint? If this is the case, then I'd imagine that the allocation policies of certain registries (most notably the internic) of netblocks smaller than /18 is very address space inefficient. -forrestc@imach.com
While I'm still trying to puzzle out why a message sent to this particular list of exploders is different in any way from "spam," I'll jump in here:
[...] Sprint's policy is unchangable) any IP numbers allocated with a prefix longer than /19 in 205 and /18 in 206 is essentially wasted space, which is unusable, at least if you want connectivity with sprint?
I've always assumed that Sprint's policy in this regard means that they do not want to have complete connectivity. Why, in this day and age, anyone in the transit business would not want to be able to resell 100% connectivity to their customers, I do not know. But it's Sprint's error and Sprint's problem. One assumes that after enough "unrouteable" (by Sprint and only Sprint) prefixes are allocated, Sprint will receive enough negative feedback from their customers that they (Sprint) will have to revise this foolish policy. Meanwhile let's not put the tail before the donkey -- this is Sprint's problem and the wound, good doctors, was self inflicted. How many times will you let the fact that Sprint is jumping in front of your car lead you to swerve to avoid hitting them? Heck, if that's what they want, do it and get it over with. Don't anybody change their routing or allocation policies just because Sprint has odd routing policies. Sprint != Internet. Fortunately.
"Robert A. Rosenberg" <hal9001@panix.com> writes:
When you allocate this /19, do you do so at such a boundary that it can be converted to a shorter (/18-/17-/16-etc) prefix at a later date ....
Of course we do that. That's why I wrote: It should be noted that additional allocations are very often aggregatable with previous ones. So the number of /19 prefixes announced will decrease over time. However it is our policy not to make any guarantees about this happening. Daniel
participants (4)
-
Daniel Karrenberg -
Forrest W. Christian -
Paul A Vixie -
Robert A. Rosenberg