[ppml] Policy Proposal 2006-5: IPv4 Micro-allocations for anycast services (temporary)

[Member Services]

On February 16, 2006, the ARIN Advisory Council concluded its review of
'IPv4 Micro-allocations for anycast services (temporary)' and accepted
it as a formal policy proposal for discussion by the community. This
proposal is  designated Policy Proposal 2006-5: IPv4 Micro-allocations
for anycast services (temporary). The proposal text is below and can be
found at:

http://www.arin.net/policy/proposals/2006_5.html

All persons in the community are encouraged to discuss Policy Proposal
2006-5 in the weeks leading to the ARIN Public Policy Meeting in
Montreal scheduled for April 10-11, 2006. Both the discussion on the
Public Policy Mailing List and at the Public Policy Meeting will be used
to determine the community consensus regarding this policy proposal.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

ARIN's Policy Proposal Archive can be found at:
http://www.arin.net/policy/proposals/proposal_archive.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


### * ###


Policy Proposal 2006-5: IPv4 Micro-allocations for anycast services
(temporary)

Author: David Williamson

Proposal type: new

Policy term: temporary

Policy statement:

In the NRPM IPv4 section, renumber 4.4 to 4.4.1, and add:

4.4.2 Micro-allocations for anycast services - ARIN will make
micro-allocations to organizations wishing to deploy anycast based
services, provided they meet the following criteria:

     * All of the criteria normally required to receive IPv4 space, AND
     * The organization must have multiple (at least two) discrete
       multi-homed networks.
     * The organization must advertise directly allocated networks from
       each multi-homed site.

Micro-allocations for anycast services will be no longer than a /24.
These allocations will be made out of blocks reserved for
micro-allocation purposes.  ISPs and other organizations receiving these
micro-allocations will be charged under the ISP fee schedule, while
end-users will be charged under the fee schedule for end-users.

This policy is experimental, and is limited to 16 allocations and two
years from adoption.  In addition, organizations may receive no more
than one microallocation under this policy.

Rationale:

There are an increasing number of anycast-based applications being
offered by service providers and other organizations.  Indeed, many
basic infrastructure services (like the DNS root servers) are already
anycast based.  (See RFC 1546 for an authoritative discussion of anycast
services.)

It's worth noting that IPv6 has anycast built into the protocol itself.
  This is a sign that there is significant community interest in anycast
as a technology, and highlights the lack of IPv4 allocation policy for
anycast.

Deployment of new services is severely hampered by current IPv4
allocation policies.  For organizations that do not have legacy IP
space, justifying a /22 to serve a handful of addresses is effectively
impossible.  As many ISPs also filter routes longer than /22, it is
impractical to use a longer mask for any netblock that is utilized for
an anycast service.  This situation is also generally unfavorable to
younger organizations, while giving older organizations that do have a
surplus of legacy space a competitive advantage.

In light of this, some organizations may simply lie about their
addressing needs in order to convince an RIR or LIR that a /22 is
required, when a much smaller network would suffice.  This is not a
behavior that should be encouraged by policy.

The obvious answer is that a micro-allocation scheme needs to be created
to allow organizations deploying anycast services to acquire a network
of more appropriate size.

It is also clear that a micro-allocation policy that makes it easier for
organizations to acquire small netblocks may lead to additional improper
allocations to organizations that simply wish to acquire additional
small blocks of space.  This policy proposal attempts to address that by
requiring more stringent requirements for such allocations.

A previous policy proposal (2005-6) is similar to this proposal, but
with a few significant changes.  There was significant negative feedback
to that policy based on a couple of key difficulties, which this
proposal attempts to address.

The primary difficulty is that an anycast network looks much like a
normal multihomed network from the outside.  This led to the consensus
belief that the earlier policy proposal would be abused by organizations
that wouldn't otherwise qualify for address space.  This proposal
further restricts allocations such that only organizations that are
already demonstratably multihomed with direct allocations can possibly
qualify. Such organizations will typically have little use for a small
allocation unless they really intend to use it for a specific purpose.

In addition, this policy is marked as experimental and has a sunset
clause, which will definitively prevent widespread abuse.  It is hoped
that operational experience will show that this policy is not seeing
abuse, and it can later be modified to be permanent.  In the event that
this policy is widely abused, the total damage is limited and will be
fixed in a relatively short time span.

Timetable for implementation: immediate