[ppml] Proposed Policy: IPv4 Micro-allocations for anycast services (experimental)

[Scott Leibrand]

David,

A very similar policy was rejected at the last ARIN meeting in L.A.  on
the grounds that a subnet of an existing network is adequate for running
anycast.  Can you clarify why this policy is required, in light of that
consensus?  I think there is significant disagreement in the community
with your statement that "many ISPs also filter routes longer than /22,
[so] it is impractical to use a longer mask for any netblock that is
utilized for an anycast service."  Do you have concrete examples to back
up this statement?

Thanks,
Scott

On 02/10/06 at 10:31am -0500, Member Services <memsvcs at arin.net> wrote:

> ARIN received the following proposed policy. In accordance with the ARIN
> Internet Resource Policy Evaluation Process, the proposal is being
> posted to the ARIN Public Policy Mailing List and being placed on ARIN's
> website.
>
> The ARIN Advisory Council (AC) will review the proposal and within ten
> working days may decide to:
> 1)  Support the proposal as is,
> 2)  Work with the author to clarify, divide or combine one or more
> policy proposals, or
> 3)  Not support the policy proposal.
>
> If the AC supports the proposal or reaches an agreement to work with the
> author, then the proposal will be posted as a formal policy proposal to
> the Public Policy Mailing List and it will be presented at the Public
> Policy Meeting. If the AC does not support the proposal, then the author
> may elect to use the petition process to advance the proposal. If the
> author elects not to petition or the petition fails, then the proposed
> policy will be considered closed.
>
> The ARIN Internet Resource Policy Evaluation Process can be found at:
> 	http://www.arin.net/policy/irpep.html
>
> Mailing list subscription information can be found at:
> 	http://www.arin.net/mailing_lists/index.html
>
> Regards,
>
> Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ### * ###
>
>
> Policy Proposal Name: IPv4 Micro-allocations for anycast services
> (experimental)
>
> 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 signficant 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 futher
> 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
>
>
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>