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

Status: Abandoned

Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 17 February 2006

AC intent to abandon on 14 April 2006Public Policy Mailing List

ARIN Public Policy Meeting:

ARIN XVII

ARIN Advisory Council:

16 February 2006
11 April 2006

ARIN Board of Trustees:

Revisions:

Implementation:

Author(s):

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.

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