<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.<br>
<br>
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. <br>
<br>
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).<br>
<br>
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<br>
<br>
John Paul Morrison<br>
CCIE #8191<br>
<br>
<br>
Mark Beland wrote:
<blockquote cite="mid:466863B5.3090305@mcsnet.ca" type="cite">
<pre wrap="">
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:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, 6 Jun 2007, Jo Rhett wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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?
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Who is "us"?
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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?
</pre>
<blockquote type="cite">
<pre wrap="">On May 31, 2007, at 4:39 PM, John Santos wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">--
Jo Rhett
senior geek
Silicon Valley Colocation
Support Phone: 408-400-0550
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
_______________________________________________
This message sent to you through the ARIN Public Policy Mailing List
(<a class="moz-txt-link-abbreviated" href="mailto:PPML@arin.net">PPML@arin.net</a>).
Manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</a>
</pre>
</blockquote>
<br>
</body>
</html>