[ppml] Policy to help the little guys
bmanning at vacation.karoshi.com
bmanning at vacation.karoshi.com
Wed Mar 19 12:45:03 EDT 2008
if you have the gonadanal fortituted - go for a minimum allocation of
/32 - for all IP address families :)
bonus points for abolishing the distinction btwn PI and PA space. (but
that would have to be an independent action, imho)
On Wed, Mar 19, 2008 at 08:58:06AM -0700, David Williamson wrote:
> I'll include the text of 2007-6 below, just for fun. Given that
> opinion on that proposal was sharply divided, perhaps it's time to pull
> it out again for discussion. I'd be happy to resubmit it for the LA
> meeting. Indeed, I'd be happy to submit a modified version if we can
> get enough feedback on this list. I think /24s are the right direction.
> 2007-6 was focused on PI, but why not PA space, too?
> If there's positive feedback, I'll submit a proposal for moving both to
> a /24 minimum.
> (policy text below)
> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0
> 1. Policy Proposal Name: IPv4 PI minimum size change
> 2. Author
> 1. name: David Williamson
> 2. email: dlw+arin at tellme.com
> 3. telephone: 650-930-9180
> 4. organization: Tellme Networks
> 3. Proposal Version: 1.0
> 4. Submission Date: 2/14/2007
> 5. Proposal type: modify
> 6. Policy term: permanent
> 7. Policy statement:
> In section 126.96.36.199 of the NRPM, change all occurences of "/22" to "/24".
> (That is, replace the existing 188.8.131.52 with this text:
> For end-users who demonstrate an intent to announce the requested space
> in a multihomed fashion, the minimum block of IP address space assigned
> is a /24. If assignments smaller than a /24 are needed, multihomed
> end-users should contact their upstream providers. When prefixes are
> assigned which are longer than /20, they will be from a block reserved
> for that purpose.
> Remove references to IPv4 in section 4.4, as they are no longer
> relevant. Section 4.4 could be moved, at the discretion of the NRPM
> editors, to somewhere in section 6, for clarity.
> 8. Rationale:
> The rationale for moving the allocation "edge" for IPv4 PI space to /24
> has three fundamental points: routing slot consumption would be
> unchanged, it reflects widespread routing practices, and it discourages
> While experiments indicate that a few ISPs still try to filter at the
> /22 boundary, I have been repeatedly told that most don't filter
> anything shorter than a /24. While routing policy and allocation
> policies don't need to necessarily match, it is not unreasonable to
> have them in alignment.
> In addition, by keeping the PI allocation size for multi-homed
> organizations at /22, organizations seeking PI space that don't meet
> the requirements may be encouraged to exaggerate their address usage.
> This is something that should clearly not be encouraged.
> On the topic of routing slots, I would like to note that any org
> qualifying under the PI policies in 184.108.40.206 would also qualify for PA
> space, and would likely have an interest in multi-homing regardless of
> the usage of PA vs. PI space. In either instance, a routing slot is
> consumed by a /24. This policy change should therefore have minimal,
> if any, impact on the size of the global routing table. It merely
> gives organizations more options at a slightly smaller network size.
> Remember that for consideration under 220.127.116.11, an organiztion *must* be
> On a side note, it's tempting to remove the restriction entirely. If
> an organization only qualifies for a /28 (for example), they could
> receive an allocation of that size. Market forces would decide if that
> /28 was worth a routing slot. If the /28 contained my personal
> website, I suspect it would not be routable. If that /28 contained
> Microsoft Update, I suspect it would. In the interest of operational
> sanity and simplicity, I am not making a proposal to remove the
> restriction. (Note that section 4.1.1 explicitly notes that PI
> addresses are not guaranteed to be globally routable.)
> There is fundamental conflict between the urge for aggregation and the
> desire for conservation. The latter would prefer that organizations
> not have any excess space, while the former would prefer that fewer
> networks exist in the DFZ, regardless of wastage. Since the DFZ already
> permits deaggregation to /24, the conservation urge should be allowed
> to push to that edge.
> As noted in 4.1.5, "determination of IP address allocation size is the
> responsibility of ARIN." This proposal simply allows the community to
> request appropriately sized blocks, and ARIN to allocate prefixes of a
> size that is commensurate with established need.
> 9. Timetable for implementation: immediate
> 10. Meeting presenter: David Williamson
> END OF TEMPLATE
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
More information about the ARIN-PPML