Policy Proposal 2007-6 - Staff Assessment

[Member Services]

Policy Proposal 2007-6
IPv4 PI minimum size change

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I.	Proposal

   Policy Proposal 2007-6 is available as Annex A below and at:
   http://www.arin.net/policy/proposals/2007_6.html

II.	Understanding of the proposal

   ARIN staff understands that this proposal would reduce the minimum
assignment for multihomed end-users from a /22 to a /24 IPv4 address block.

III.	Issues and concerns

   A.	ARIN Staff

     1.	There is very little qualification criteria which could lead to
policy abuse by spammers.  These entities could create many different
accounts over time as their existing space gets blacklisted or becomes
otherwise unusable.

     2.	This could significantly increase the number of requests for
ARIN services thereby requiring additional Registration Services
Department and Financial Services Department staff.

     3.	Policy applies only to end users which could be perceived as
unfair to ISPs.  This could also lead to potential abuse of the policy
if ISPs apply as end users for single /24 IPv4 address block.

     4.	It is unclear exactly how an organization can qualify for a /24
IPv4 address block under this policy.  It appears that NRPM section
4.3.3, Utilization rate, requires 25% immediate, 50% within 1 year,
would be the justification criteria.  However, NRPM section 4.2.3.6,
Reassignments to multihomed downstream customers, indicates that an ISP
can reassign a /24 IPv4 address block without regard to planned host
counts as long as the customer is multi-homed.  The question here is
does this policy allow ARIN to qualify a requestor for a /24 IPv4
address block based solely on multi-homing or should host counts also be
taken into account?

     5.	The policy does not address requests for more than one /24 IPv4
address block for multiple sites.

     6.	NRPM Section 4.4, Micro-allocation, should remain as is since it
is a policy section essential for micro-allocation for critical
infrastructure related requests.

   B.	ARIN General Counsel

     The policy as proposed poses no significant legal risks for ARIN.

IV.	Resource Impact - Minimum

The resource impact of implementing this policy is viewed as minimum.
Barring any unforeseen resource requirements, this policy could be
implemented within 90 days from the date of the ratification of the
policy by the ARIN Board of Trustees. Implementation might require the
acquisition of staff personnel or equipment. It will require the following:

- Minor update to software
- Revisions to registration guidelines
- Staff Training

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


##*##


Annex A

Policy Proposal 2007-6
IPv4 PI minimum size change

Proposal type: modify

Policy term: permanent

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.

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.

Timetable for implementation: immediate