[arin-ppml] Renumber and Return inconsistencies in the NRPM

Stephen Sprunk 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
>
> 4.2.2.1.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
>
> 4.2.2.2.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...

S

-- 
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...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090127/d2be8c4f/attachment-0001.bin>


More information about the ARIN-PPML mailing list