[ppml] Policy to help the little guys

[David Williamson]

On Wed, Mar 19, 2008 at 03:51:12PM +0900, Randy Bush wrote:
> i am not necessarily advocating this.  but i think the exercise of
> discussing the pros and cons might be good for us.

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