[ppml] Policy to help the little guys

[bmanning at vacation.karoshi.com]

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)

--bill


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.
> 
> -David
> 
> (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 4.3.2.2 of the NRPM, change all occurences of "/22" to "/24".
> 
> (That is, replace the existing 4.3.2.2 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
> waste.
> 
> 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 4.3.2.2 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 4.3.2.2, an organiztion *must* be
> multi-homed.
> 
> 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 
> _______________________________________________
> PPML
> 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:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.