[ppml] Policy Proposal: Decreasing Exponential Rationing of IPv4 IP Addresses

[James Hess]

I oppose the proposed policy as stated.

> ARIN will ration the remaining available IP Address Space according to a
> decreasing exponential function in the family of e^(-x), where the
> ultimate function and factors are chosen to ensure that the remaining IP
> address space lasts for at least 10 years.

The proposed policy provides no specific device by which rationing can be
accomplished, no means to reach the end desired in the proposed rationale
are precisely given...

The proposal doesn't provide for exactly what "rationing is" for purposes of
policy I suggest it's similar to just having as a policy "IPV4 assignments
will not be  allowed to consume all available IP addresses"

Another problem is any rationing scheme ARIN attempts to implement beyond
justified need seems essentially be indicative of a failure of ARIN to
accomplish
its mission -- it will mean organizations who have the proper
justification and
need IP  addresses cannot be allocated all the addresses that  they need,
when they need the hosts to come online.


Rationing poses serious problems, depending on how it is implemented, and
still doesn't even manage to prevent exhaustion.

Either the request will be denied, despite requestor's urgent need, or
it will be
delayed despite requestor's urgent need, or requestor will receive a
smaller than sufficient number of addresses, and be left immediately asking
for more.


Rationing by ARIN doesn't truly prevent IPV4 exhaustion, because ARIN
is not the only
RIR, and if  ARIN reduces rate of address allocation, the supply of
addresses ARIN
will need from the IANA pool will be smaller (meaning more of the
remaining addresses
may get allocated by other RIRs such as APNIC/LACNIC/RIPE/AfriNIC).


If there is anything ARIN can ration anything on its own, I believe
it's the pool
allocated  to ARIN, provided rationing starts only _after_ IANA pools
are exhausted.



Also, the IP address allocations are not discrete assignments of individual
addresses that can easily be bound by a function such as Exp[-x];
these addresses
have a structure, they are allocated in large blocks, powers of 2
in size, and if massive routing table growth is to be avoided, individual
assignments  should never be split over multiple repeat assignments over time.

I pose that it is not acceptable to hand an organization who needs a /22
a /24 instead, let them request another /24 3 months mater, etc, until
they finally get 4  totally discontinuous /24s...

Hundreds of thousands of orgs  routing 4 /24s instead of  1 /22 a
piece would be a
serious inefficiency, that rationing without some very well-thought-out
guidelines could result in.


By 2010, the resulting routing table fragmentation  may well be a worse disease
than IP exhaustion, if that sort of fragmentation occurs.....

--
-J