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

Scott Leibrand sleibrand at internap.com
Fri Feb 10 14:21:20 EST 2006


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?


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

More information about the ARIN-PPML mailing list