[ppml] Policy to help the little guys

[bmanning at vacation.karoshi.com]

	i'll admit to not seeing a whole lot of value in a /32
	delegation, BUT I'm not as creative as some.  I can see
	some value in a /31 - for those P2P links across the legacy
	v4 internet, hooking up the otherwise unconnected v6 "galaxies"...

	and to be sure, the arin community would have to take a very long
	critical look at how to enable growth.   this is where a robust,
	painless, lowoverhead renumbering scheme would come in real handy.
	(wishing ISC had not expunged the A6 code when the IETF made A6
	 experimental... its a real pain to have to keep puting it back in)

--bill



On Wed, Mar 19, 2008 at 01:04:27PM -0500, Ray Weber wrote:
> Well /24 would have helped us "small guys" a lot before we got
> big enough and had the fortitude to need and request more.... 
> but Im not sure you need to go as crazy as /32. 
> 
> Ray Weber
> VP Network Operations
> SNEWISP llc
>  
> 
> 
> -----Original Message-----
> From: bmanning at vacation.karoshi.com
> To: David Williamson <dlw+arin at tellme.com>
> Cc: ppml at arin.net
> Date: Wed, 19 Mar 2008 16:45:03 +0000
> Subject: Re: [ppml] Policy to help the little guys
> 
> 
> 
> 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.
> _______________________________________________
> 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.