[ppml] Suggestion for ARIN to deligate smaller IP blocks

Mark Beland mark at mcsnet.ca
Thu Jun 7 15:59:49 EDT 2007


Folks,
I've been watching this thread unwinding and feel I need to pitch in my 
two bits.

I think we're missing the most important elements of the problem here.

Arguably, nearly any moderate sized company can justify a /24 ... Your 
policy change
could specify that only ISP's may obtain blocks of /24, but the private 
business / ISP
distinction is one that may well be trivial for most businesses to 
overcome.... The
problem I envision is that when you tell tech savvy small businesses and 
ISP's that they
can be provider agnostic by obtaining an allocation directly from ARIN, 
there will
be a mad rush on the part of these companies to do just that. 
Multi-homing has always
been an option for those who can justify the allocations, but when you 
reduce the minimum
size of the allocation required and you also remove the need for such 
companies to be
multi-homed, I think your opening a pandora's box.. You would see

As the most important side-effect:
- 1000's of smaller companies, who don't really need a /24, exaggerating 
their need in order
to get an allocation.. after all, its convenient not to have to 
renumber.... easier than
planning ahead.

And we would also see:
- Significant routing table growth - can't argue this one - rather than 
seeing a /18(or larger) from big isp, we're seeing /24's
- A change in the ISP marketplace where mid/small sized customers all 
become provider agnostic.
This may be good for you if your a small isp or asp, but its bad for the 
Internet Access
business as a whole because it makes it very easy for these companies to 
change ISP's.. This
means that if your a small or mid sized internet service provider 
providing services to a business
who has their own allocation, big telco can come along any day and say 
here's the same service
for half the price, and they can have the client up and running in a 
matter of moments..... (this
as opposed to the current situation where renumbering is often more time 
consuming an expensive)


We were in your shoes a number of years ago, as a small ISP trying to 
get an allocation, and I appreciate
the realities of your situation. But on the other hand, what you are 
proposing has serious implications
for the entire industry, and I for one, would like to keep things 
exactly the way they are.


Regards,
Mark Beland




John Santos wrote:
> On Wed, 6 Jun 2007, Jo Rhett wrote:
>
>   
>> John, I'm a little confused by your math.
>>
>> 2000 customers * cost of changing IP addresses equals... $200 per  
>> customer if they have to pay an outside consultant to do it for them,  
>> usually less than $20 for inside help... Not a big number.
>> $40,000 <=> $400,000
>>     
>
> Maybe $400,000 is noise to your company.  My company has to think
> long and hard before spending $40,000.  Your perspective is seriously
> warped.
>
>   
>> Cost of upgrading a single big iron box to have more routing table  
>> slots > $100,000
>> Multiply by the number of big iron boxes who can't use a default  
>> route, say at least 400?
>>     
>
> Are you talking about the cost of upgrading all the backbone routers
> in the world to handle /25's vs. /22's?  (I forget the size Leroy 
> was originally looking for, but it was about 1/8 the minimum 
> assignment under the current rules.)
>
> Aren't all these big boxes going to need to be upgraded anyway to
> support IPv6?
>
>   
>> The only difference is who is paying for it, and who is gaining value  
>> for it.  You want us to pay, so that your business can gain value.
>>     
>
> Who is "us"?
>
>   
>> You do the math, and tell me again why I should be paying out of my  
>> pocket for your customer.  You very well could have explicit  
>> instructions sent to the customers for IP address changes.  You could  
>> very well purchase multiple IP ranges from different providers, and  
>> thus make the importance of any IP address change negliable.  Or you  
>> could pay $49/month to get a second uplink and then qualify for PI  
>> space based on multi-homing.
>>     
>
> Don't you need to be able to justify a /22 to get the PI multihoming
> space?  That was the basis of this whole discussion.
>
>   
>> Every one of those options is trivially cheap and easy to implement.   
>> This is why I reject your desire to make our businesses pay hard cash  
>> so that your business can avoid building even the most trivial  
>> resiliance into your process.
>>     
>
> Why does it cost your business any more if Leroy has a /25 that he
> is using most of versus if he has a /22 that he doesn't really need?
>
> Are you on about routing table size again, or something else?
>
>   
>> On May 31, 2007, at 4:39 PM, John Santos wrote:
>>     
>>> It is the 2000 customers who would have to pay the cost.  It may be
>>> small for each, but its cumulative, and will certainly generating lots
>>> of support calls back to Leroy's company.
>>>
>>> My company is in a similar situation to Leroy's customers.  We have an
>>> external mail filtering service.  Our published MX records point to
>>> the service, and they then forward the (filtered for spam, viruses,
>>> RBL, etc.) mail to us, so we have had to open up our firewall to SMTP
>>> from their specific IP addresses.  We are certainly *not* going to let
>>> them manage our firewalls for us, nor are we going to willy-nilly  
>>> change
>>> our firewall rules on their request without minimally verifying the
>>> origin of the request (a support call to them.)  Multiply by several
>>> thousand customers.
>>>
>>> If they were to start changing IP addresses frequently, we would start
>>> looking for a new service provider.
>>>
>>> This is an *extremely* unlevel playing field, since ACME GIANT ASP,
>>> INC. (which is many times the size of Leroy's company), could easily
>>> justify an allocation, and thus could promise their customers that
>>> their IP addresses and firewall rule would never change.
>>>       
>> -- 
>> Jo Rhett
>> senior geek
>>
>> Silicon Valley Colocation
>> Support Phone: 408-400-0550
>>
>>
>>
>>
>>
>>
>>     
>
>   




More information about the ARIN-PPML mailing list