[ppml] Suggestion for ARIN to deligate smaller IP blocks
John Paul Morrison
jmorrison at bogomips.com
Sun Jun 10 18:03:00 EDT 2007
It costs money to get an AS number, this may be a dis-incentive.
BGP requires some thought and complexity to setup, while there are
multiple "plug and play" load balancing/NAT hack appliances out there.
BGP may not be a supported product offering on your basic service, so
you may have to upgrade your service plan and pay setup/engineering
charges to get BGP.
A PI /24 may be unroutable - you run the risk of being filtered. This
used to be a big concern a few years ago. (The fact that it doesn't seem
to be any more seems to point to the fact that the initial routing table
size panic is over).
These are all dis-incentives to running out and getting an ASN and PI
/24 unless you need it.
If you can fudge justification of a PA /24,. you can do it for a PI /24,
so I don't see the difference. If you can fudge it, that seems like an
enforcement/administrative issue, not a policy issue.
A first hurdle to getting a PI/24 allocation might be to show you are
running with a PA /24
Taking a look at the big picture - if an organization can legitimately
justify its requirements and knows enough about what it is doing to want
an ASN and a PI /24 initial allocation, I don't think ARIN should be
getting in the way. Current policy can scarcely be justified any more,
and that just leaves it looking like the anti-trust/competition limiting
policy that it inadvertently is.
We should not rely on knee-jerk reactions and circular reasoning to
shape policy - e.g. the usual address space depletion and routing table
explosion arguments, where trying to conserve the status quo for as long
as possible simply delays the adoption or development of newer
technology (IPv6 and a solution (other than Moore's Law) to routing.
I think people would be very hard pressed to prove that this policy
would "break the Internet" which would seem to be the only arguments
Absolute worst case is you may see an earlier transition to IPv6 (many
would say this is a plus!) and some routing black holes for the
newcomers who can't route their new PI /24s.
Paul_Vixie at isc.org wrote:
>> As I've said a couple times recently, I'm not opposed to / am in favor of
>> issuing PI /24s to any multihomed network.
> so, PI /24 for multihomers, but not for TE routes or lockin-avoidance? or,
> in light of how easy it would be for a TE route spewer or a lockin-avoider
> to just multihome in order to get a /24, do you really just mean "PI /24
> for anybody who asks" ?
>> If you're multihomed, your PI /24 takes up the same global table routing
>> slot your PA /24 would (less space if you had multiple PA /24s from your
>> various providers which you'd give up to get PI).
> for a PA /24 there's presumably a covering route which makes your addresses
> "reachable from the DFZ" even from places who don't hear or filter your /24.
> so, there's a bit of a qualitative difference in the case where a /24 isn't
> multihomed. i agree that if it's multihomed, PI uses less DFZ DVRP than PA.
>> If you're not multihomed, and not big enough to qualify for PI space under
>> current guidelines, sorry, you get to keep using PA.
> anybody who wants to multihome can do that pretty easily, and if that's all
> it takes to qualify for a PI /24, then we're more or less throwing open the
> doors and inviting anybody who really wants a PI /24 to ask for one. (to me
> this isn't a bad idea since the worst DFZ bloat is from TE not multihoming.)
>> Otherwise the routing tables really would explode.
> by any reasonable definition of that word, the DFZ at 220KP has exploded. so
> when we talk about explosion let's qualify it: "explode again (>1MP)." and
> after than we'll say "explode yet again (>5MP)." the community's record for
> preventing these explosions isn't good; for coping with them, slightly better.
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML