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

[Scott Leibrand]

On 02/17/06 at 12:14pm -0800, David Williamson <dlw+arin at tellme.com> wrote:

> 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.

This matches what I would expect, and IMO is insufficient evidence of
unreachability to support a new IPv4 Micro-allocation policy.

I would modify your experiment slightly as follows:

 - Announce the /24 while continuing to announce the larger block.
 - Register the /24 in RADB or an RR it mirrors.
 - Check the route-servers as you did before.  Note the AS paths seen for
the /24.  Also note the AS paths seen for the /22 (or whatever your larger
allocation is).
 - Pull out all the AS paths seen for the /22 but not for the /24.  Using
the assumption that any such networks will forward your traffic based on
their route for the /22, reconstruct the AS path the traffic will take,
and determine where in that AS path it will reach a network which does
have your /24.

The idea here is this: say you have PA space from NSP X, and are
multihomed to NSP Y and Z as well, possibly in two different locations.
You want to run anycast using a /24 (A) you got from NSP X.  For
argument's sake, let's say that prefix A is a subnet of NSP X's /8
aggregate, and there are no other overlapping subnets of A in BGP.

In my experience, NSPs X, Y, and Z will all accept your /24 from each
other.  In addition, most other NSPs with a global presence will also
accept it.  Some regional networks on other continents will filter your
/24, but will still accept NSP X's /8 aggregate.  Ditto for some smaller
domestic ISPs who buy transit from NSPs.

In this case, a foreign NSP F, which filters /24's, will not see your /24.
Instead, they will send traffic to that netblock towards NSP X.  Let's
assume that your link to NSP X is down.  In that case, NSP X will get the
traffic, and see that their best route for it is your /24, which they're
hearing from NSP Y or Z.  They'll forward the traffic along to you, and
the only minor ill effect will be that NSP F sent the traffic via NSP X
instead of direct to Y or Z.

Now, let's consider the case where you get a /24 micro-allocation from
ARIN.  Let's assume that at least initially, some netblocks will fail to
update their filters to allow /24 announcements from ARIN's anycast
micro-allocation block.  In that case, there will be no larger aggregate
for them to fall back on, and therefore traffic to your /24 will be
blackholed.

Given these scenarios, I think it is better to do anycast out of a larger
PA or PI netblock, rather than trying to get a /24 directly from ARIN for
the purpose.

> 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.

As argued above, I don't think that /24 filtering equals unreachability in
most cases.

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

And IMO you should already have global reachability today.  Any attempts
to use PI /24 micro-allocations would IMO reduce your reachability, not
improve it.

Given all that, I will be opposed to 2006-5 unless you can show me that an
anycasted /24 out of a larger netblock is truly unreachable from
somewhere.  Given the widespread acceptance of /24 subnets, and the
overlapping coverage of a larger aggregate, I don't suspect you'll find
any such situations.

-Scott

> 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
>