[ppml] Suggestion for ARIN to deligate smaller IP blocks

[Heather Schiller]

Policies to reduce the minimum assignment from ARIN down to a /24 have 
been proposed in the past, including the last policy development cycle.

You can read archived ppml comments on the subject and meeting transcripts 
to get a feel for and against the idea.

Most recently:
http://www.arin.net/policy/proposals/2007_6.html

However your example of 75 IP's is significantly smaller than a /24 - 
which is the generally accepted minimum prefix size passed between 
providers.  If you would also like providers to consider lowering the 
prefix size they will accept, Nanog might be a better forum, as that is 
more operational than IP addressing policy.  (However don't expect it to 
be a popular idea, as it would add to routing table growth)  ARIN doesn't 
guarantee the routability of address space, so even if the policy were 
changed to make the minimum assignment a /25, you'd have to find a 
provider willing to leak it, and others willing to listen.

  --Heather

###############################################
  # Heather Schiller                          #
  # Customer Security & IP Address Management #
  # 800.900.0241                              #
  # security at mci.com                          #
###############################################

On Thu, 31 May 2007, Leroy Ladyzhensky wrote:

> In this suggestion I am not talking about ISP's but this is directed to policy IPv4 assignment for "end-users".
>
>
>
> The current policy is as follows...
>
>
>
> Single connection:    minimum assignment = /20 (16 class C's)  utilization: 25% immediate / 50% in one year.
>
> Multi-homed:        minimum assignment = /22 (4 class C's) utilization: 25% immediate / 50% in one year.
>
>
>
> Here is where this policy is lacking, and in my opinion is a complete oversight in ARIN policy.
>
>
>
> Requesting IP's from ARIN is not always a request for quantity... but ISP independence. Many internet businesses are not ISP's, but businesses that supply a service or a managed solution for other companies via the internet. In this situation ISP independence is critical for the company's survivability and flexability.
>
>
>
> Imagine this situation:
>
>
>
> An internet based company provides a specialized service. In order for the companies clients to utilize this service they need to open ports in their firewall. As we know this option in a firewall is based on the IP's of the internet based company. Let's say they have 2000 clients. so that 2000 firewalls that have entries for their IP's. These IP's are from their ISP since this company cannot fulfill the IP requirement as dictated by ARIN's policy (they may only use 75 IP's, not the 508 required by ARIN). then the inevitable happens: the ISP want the company to change to a new block of IP's, they increase their rates, are no longer providing acceptable service, got purchased/went bankrupt or other reasons... needless to say this company is forced to change IP's and 2000 customers now have to make firewall changes or face service disruptions. Depending on the reason this could impact the company's business and possibly loose clients in the process and cost money.
>
>
>
> This situation is not far fetched and maybe some of us reading this have experienced this ourselves.
>
>
>
> A company that provides internet based services needs to own its IP's .. that's just good business strategy.
>
>
>
> But, what happens when a company cannot reach the "quantity commitment"? I guess there is only 2 choices: Stay at risk / or take more than you need.
>
>
>
> Undoubtedly company's will choose to not be at risk.. so that will just take more then they need. And I guess deep down that just really goes against the very essence of ARIN.
>
>
>
> Implementing a policy/policy change for end users (internet based businesses, MSP's) to obtain a smaller block of IP's (/24 or /23) would allow companies like this to qualify for a block of IP's and prevent unneeded waste.
>
>
>
> I would like your comments / experiences on this issue.
>
>
>
> Thank You,
>
> Leroy Ladyzhensky - CCNA, CCDA, CSE
>