[ppml] Suggestion for ARIN to deligate smaller IP blocks
John Paul Morrison
jmorrison at bogomips.com
Thu Jun 7 17:08:18 EDT 2007
Funny, there never used to be any reason to keep tech savvy small
businesses from designing and operating their networks properly (ie.
using BGP instead of NAT hacks or proprietary hardware), and not having
to renumber.
These are just the same sky is falling arguments that whether
intentionally or not, have created second class, second tier internet
users. You're not big enough to justify a /22? Then the attitude is "so
what" or "get lost" - you have to stay with that bad contract, or use a
proprietary or ugly NAT hack to stay in business, or you have to renumber.
This isn't 1995 any more. We're not running out of IP addresses - every
IPv4 /24 allocated is really just one more step to IPv6. Routers are
NOT crashing or having to be upgraded because the Internet routing
tables are doubling every month. The Internet saw unprecedented growth
in the beginning of the Web age because it was new, and we're never
going to see the same rate of growth. What we have here is the same old
arguments: address depletion and routing table size to create a two tier
internet used as a big stick to keep the little guy in his place. We
have IPv6 for address space growth, and the IETF saying there's no need
for panic on the routing table problem (on top of it we have Moore's law
on our side and the fact that the Internet isn't growing at the same rate).
BTW, I can *already* get provider aggregatable /24 addresses today if I
can justify them, and advertise these with BGP with another carrier. So
the next logical step is to have provider independent addresses so I can
cut the cord with the upstream ISP if their terms are onerous
John Paul Morrison
CCIE #8191
Mark Beland wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070607/359a7a7a/attachment.htm>
More information about the ARIN-PPML
mailing list