[arin-ppml] Renumber and Return inconsistencies in the NRPM
stephen at sprunk.org
Tue Jan 27 21:10:38 EST 2009
heather skanks wrote:
> Why are the renumber and return policies different for multihomed vs
> non-multihomed ISP's? It seems to be optional for non-multihomed and
> required for multihomed - when the level of effort/hassle would be the
> same. ..and then there is no mention of renumbering for End Users?
> Is there some history or reasoning to this I'm missing?
> Standard/Non Multihomed ISP's
> 184.108.40.206.4. Renumber and return
> ISPs receiving a new /20 may wish to renumber out of their previously
> allocated space. In this case, an ISP must use the new /20 to renumber
> out of that previously allocated block of address space and must
> return the space to its upstream provider.
> Multihomed ISP's
> 220.127.116.11.3. Renumber and return
> Agree that the newly requested IP address space will be used to
> renumber out of the current addresses which will be returned to their
> upstream provider(s).
> End User
> Nada - there is nothing about renumber and return in the End User section
The differences certainly are problematic. Reading those sections in
isolation, it seems that the rationale is that if you're using hosts in
PA space to justify their first PI block, then you should be required to
renumber those hosts rather than keeping them in the PA space. If that
is indeed the idea, it should be separated out from the above three
cases into one general one and made /much/ more clear.
As to how it ended up this way, well, they were different policies
written by different people at different times, and the trend (with a
few notable exceptions) has been to divide things and write new language
rather than reference other sections of the NRPM or reorganize/combine
sections that are redundant...
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
More information about the ARIN-PPML