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

[David Williamson]

Hey!

Sorry for taking so long to reply.

In my opinion, the possibility for abuse of the policy to acquire /24s
for multihoming was the primary grounds for rejection.  The length
argument struck me as somewhat secondary.  Still, it's an interesting
argument.

I did a bit of an experiment, and picked one of the three /24s I have
free and announced it.  While it's true that some providers seem to
happily forward any /24 that falls into their routing table, there are
definitely route-servers out there that aren't seeing that route.  To
be honest, I can't see why that route isn't appearing.  It's clearly
getting filtered, but that could be because it's a longer prefix out of
a netblock that has shorter (i.e., /22) allocations.  It could also be
that someone picks up route policy from a routing database that we
aren't presently in. 

That said, I'd love to hear feedback from folks at other major ISPs.
Has *everyone* relaxed the /22 route filtering limit?  The intent of
this policy is to have blocks of an appropriate size for the
application handed out in a way that will ensure global reachability.
If *any* of the top volume ISPs do filter based on RIR policy guidelines
(and several have historically), then longer prefixes from 'normal'
blocks won't really suffice.

That desire for global reachability is the one of the primary
motivations for this policy.

-David


On Fri, Feb 10, 2006 at 02:21:20PM -0500, Scott Leibrand wrote:
> 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
> >
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml