[arin-ppml] Policy Proposal 102: Reduce and Simplify IPv4 Initial Allocations
cgrundemann at gmail.com
Sat Nov 7 10:18:17 EST 2009
On Fri, Nov 6, 2009 at 18:42, James Hess <mysidia at gmail.com> wrote:
> I find myself undecided in regards to this proposal at the present
> time, with regards to support/oppose...
> On Fri, Nov 6, 2009 at 2:58 PM, Ted Mittelstaedt <tedm at ipinc.net> wrote:
>> William Herrin wrote:
>>> On Thu, Nov 5, 2009 at 1:46 PM, Member Services <info at arin.net> wrote:
>> Under this proposal they qualify for what might be termed a
>> "temporary" allocation. If they never grow, they never renumber.
> Then it's not temporary at all.. it's more like a provisional allocation.
>> If they grow, they renumber into a larger allocation that reduces
>> the burden of carrying their routes - same as the current requirements.
> Under the current requirements, they might choose not to renumber..
Under the current requirements, they would not be eligible to receive
an initial allocation at all.
>> Thus they are not really "Initial requesters" However, since
>> they are getting their first allocation, they ARE "Initial
>> requesters" - from a certain point of view.
> Um.. they can't be both "not really 'Initial requestors'" and
> Initial requestors at the same time...
> It's a confusing and contrived thing to suggest "initial allocation"
> is anything other than the very first allocation they get.
Under this proposal, if you are an ISP and you have utilized a /24
equivalent of space, you can get an initial allocation of a /23.
Later, if you need (and can justify) more space, you are given a
replacement initial allocation. This is in contrast to an
_additional_ allocation. You are required to return the original
allocation in exchange for a larger allocation - it is a replacement,
hence the wording in the proposal text.
>> Your making a claim here that the simple property of
>> being multihomed somehow acts as a deterrent to an org for
>> subnetting, and splitting their advertisements, thus
>> creating new overhead cost for everyone else.
> The cost is not based solely on whether they subnet or not, it's also
> based on whether other providers can effectively filter the
> additional noise out.
Understood, this is why we very deliberately included the line "When
prefixes are assigned which are longer than /20, they will be from a
block reserved for that purpose whenever that is feasible." This way,
you only need to adjust your filters for a given block, not across the
> A small ISP gets IPs from upstream providers out of PA blocks from
> which ARIN allocates prefixes no longer than /20.
> Providers who need table size reduction to avoid increased cost may
> have that option of filtering, discarding announcements with prefixes
> longer than /20, rely on the non-customer's ISP's covering route
> to provide connectivity.
This has been discussed at length (both on this list and elsewhere)
and it appears that everyone who filters at anything larger than the
/24 boundary understands that they must include some form of a default
route when doing so. Even in PA space, there is no guarantee that the
upstream provider is announcing a covering aggregate. Should they be?
Yes, but no one with any clue is going to bet their customer's
connectivity on that - with or without this proposal.
> For the blocks ARIN assigns /22s from, for multi-homed users,
> /22s definitely need be accepted or connectivity would be quite
> If ARIN were to allocate smaller blocks such as /23, these could
> not be filtered, since there is no upstream provider announcing an
> overall /20 PA that contains the /23.
This is already true for multihomers with /22s and the critical
infrastructure or legacy blocks which go down to /24.
> The smaller an allocation ARIN makes from any given block, the
> less effective that an aggressive filtering strategy could be.
Again, this proposal requires that all allocations smaller than /20 be
from a dedicated block (as long as that is possible) so that you can
adjust such filters accordingly. Also, if you are not using the whole
table, you probably need a default (or perhaps a process by which you
determine which routes have covering aggregates and which do not).
> When single-homed ISPs get a /23 from an upstream provider the
> DFZ _MIGHT_ see 1 additional /23 and 2 additional /24s
> being broadcast, for a total of 3 new table entries, but then
> again they might not.. the single-homed ISP may not announce a
> When single-homed ISPs get a /23 from ARIN, you can be assured,
> almost guaranteed an additional /23 appearing, and 2
> additional /24s getting announced cannot be ruled out.
> It seems like a plausible scenario, that the costs to others would
> be much greater, in the scenario where ARIN allocates a
> significant number of /23s to single-homed providers.
> I couldn't think of any plausible scenario where the costs to
> others would be less or the same, if single-homed entities are
> allowed to receive small direct allocations.
I agree - with or without this proposal, it is hard to find a likely
scenario where the cost to everyone with regard to the routing table
ever becomes less than it is now. Also, allowing a new class of
organizations access to direct allocations will likely increase the
consumption of routing table slots at least a little bit. The real
question is: In comparison with all of the other things (policy and
otherwise) that are bloating the table, is this a worthy purpose for
adding a few more entries?
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML