[ppml] Suggestion for ARIN to deligate smaller IP blocks

Leroy Ladyzhensky leroy at emailsorting.com
Thu Jun 7 17:34:17 EDT 2007


That's where a good policy comes in....

I am not talking about any SMB that has a tech savvy owner/it guy that runs 
exchange....

I am talking about "internet based application/solution providers" (ASP's or 
MSP's) that are multi-homed. Companies that their sole business is
providing services/application hosting/to companies via the 
internet...companies that need to be ISP independent. These are the 
companies that can serve millions+ of end-users but do this all with only a 
few IP's (maybe as little as 64)...  these companies will most likely never 
use many IP's. validation needs to be ip place to show that IP change is 
extremely painful... to the point where an ISP almost cannot be done without 
business impact.

And since when is being trapped into a ISP a good thing? That's thinking is 
just insane... and will not comment on that anymore!!

lets really face it... the routing table issue is a legitimate concern, but 
doesn't seem to be a concern of ARIN from when a proposal like this was shot 
downs before... everything else is just fear.

If any company can NOT meet the requirements of using 2 /24's to be able to 
get a /22 (note the 50% waste is acceptable) from ARIN... and that really 
wants their own IP's... they LIE (I am sure that is shocking news to most of 
you). now your precious routing tables are full of /22's with 75% to 90% of 
the address's being wasted... and that's just wonderful.

Leroy L.




----- Original Message ----- 
From: "Mark Beland" <mark at mcsnet.ca>
To: "John Santos" <JOHN at egh.com>
Cc: <ppml at arin.net>
Sent: Thursday, June 07, 2007 3:59 PM
Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks


> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> 




More information about the ARIN-PPML mailing list