Home page logo
/

nanog logo nanog mailing list archives

Re: De-bogon not possible via arin policy.
From: Jimmy Hess <mysidia () gmail com>
Date: Thu, 15 Dec 2011 01:14:15 -0600

On Wed, Dec 14, 2011 at 10:47 PM, David Conrad <drc () virtualized org> wrote:
[snip]
I'm confused. When justifying 'need' in an address allocation request, what difference does it make >whether an 
address in use was allocated by an RIR or was squatted upon?  Last I heard, renumbering >out of (say) RFC 1918 space 
into public space was still a justification for address space.  Has this >changed?

It is a potential network change that could require additional address
space, if an operator plans a complete and immediate renumbering,  but
the choice to renumber is not an automatic justification for the same
number of  non-RFC1918 IPs   as the count of IPs available in their
RFC1918 space networks.
I'm sure the RIRs are not allowing that.

A RFC1918 network is not a "normal" network; and this is not a
renumbering in the same manner as a renumbering from public IP space
to new public IP space.




The operator might have to show why they shouldn't renumber their 1918
network partially, over time,  in a manner compatible with the RIR
policy for initial service provider allocations, instead of all at
once.

In other words:   What is the technical justification that all those
rfc1918  addressed hosts suddenly need to be moved  immediately,   and
 not over a normal allocation time frame for new public networks?


When building the rfc1918 network originally, the architect did not
need to follow RFC 2050,  RFC3194, etc,  so it is quite possible that
the 1918 network does not efficiently utilize IP addresses.

That means the RIR has to establish that the criterion is good enough.
"I have a rfc1918 /16 that I use,  so give me a public /16, please"
is not good enough.


That would essentially provide a backdoor around normal RIR justified
need policy, if it were allowed......

--
-JH


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]