[ppml] Policy Proposal 2005-6: Micro-allocations for Anycast Services
Member Services
memsvcs at arin.net
Mon Aug 22 12:46:20 EDT 2005
- Previous message: [ppml] Deadline for Policy Proposals - August 27
- Next message: [ppml] Proposed Policy: Rationalize Multi-Homing Definition and Requirement
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On August 18, 2005, the ARIN Advisory Council (AC) concluded its review of proposed policy 'Micro-allocations for Anycast Services' and agreed to forward it as a formal proposal for discussion by the community. This proposal is designated 2005-6: Micro-allocations for Anycast Services. The policy proposal text is below and can be found at: http://www.arin.net/policy/proposals/2005_6.html All persons in the community are encouraged to discuss Policy Proposal 2005-6 in the weeks leading to the ARIN Public Policy Meeting in Los Angeles, CA, scheduled for October 26-27. Both the discussion on the PPML and at the public policy meeting will be used to determine the community consensus regarding this policy proposal. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ### * ### Policy Proposal 2005-6: Micro-allocations for Anycast Services Author: David Williamson Policy term: permanent 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 identify which networks, ASNs, or sites will host the new service. * The organization must provide a description of the anycast service. 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. 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.) Deployment of new services is hampered, however, 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 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. Timetable for implementation: immediate
- Previous message: [ppml] Deadline for Policy Proposals - August 27
- Next message: [ppml] Proposed Policy: Rationalize Multi-Homing Definition and Requirement
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list