The following is a new policy proposal that has been posted to the ARIN Public Policy Mailing List for discussion on that list.
Regards, Member Services American Registry for Internet Numbers (ARIN) -------- Original Message -------- Subject: [arin-ppml] Policy Proposal 106: Simplified IPv6 policy Date: Tue, 29 Dec 2009 11:38:45 -0500 From: Member Services <[email protected]> To: [email protected] ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with Policy Development Process. This proposal is in the first stage of the Policy Development Process. ARIN staff will perform the Clarity and Understanding step. Staff does not evaluate the proposal at this time, their goal is to make sure that they understand the proposal and believe the community will as well. Staff will report their results to the ARIN Advisory Council (AC) within 10 days. The AC will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. In the meantime, the AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 106: Simplified IPv6 policy Proposal Originator: Scott Leibrand Proposal Version: 1.0 Date: 29 December 2009 Proposal type: new Policy term: permanent Policy statement: Delete "6.1 Introduction" This is all historical. Delete "6.2 Definitions" The definitions we need are all defined in section 2. Leave 6.3 as is (renumber to 6.1) I think these still accurately reflect the Goals we want our policy to follow. Move 6.4.1 to 1.1. Retitle to "Number resources not to be considered property" and update text per below. This is a principle more general than just IPv6, and needs to be updated to be ARIN-specific and refer to the RSA. Delete 6.4.2 - 6.4.4 These principles don't seem worthy of elevation to special status. Replace 6.5 Policies for allocations and assignments with text below (renumber to 6.2) This seems to be where most of the changes and simplification are needed. Delete 6.6 References This is all historical, and doesn't need to be part of the NRPM. Delete 6.7 Appendix A: HD-Ratio We can let the HD-Ratio guide policy without making people like David's grandma do the math. Delete 6.8. Appendix B: Background information This is all historical Move 6.9 and 6.10 into 6.2.3.2 below Replacement text: 1.1. Number resources not to be considered property The policies in this document are based upon the understanding that globally-unique number resources are licensed for use rather than owned. Specifically, IP addresses and ASNs will be allocated and assigned as defined in the ARIN Registration Services Agreement. 2.8. Critical Infrastructure Providers Critical infrastructure providers of the Internet include public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. 4.4. Micro-allocation ARIN will make IPv4 micro-allocations to Critical Infrastructure Providers per section 2.8. These allocations will be no longer than a /24. Multiple allocations may be granted in certain situations. 4.4.1. Allocation and assignment from specific blocks Exchange point allocations MUST be allocated from specific blocks reserved only for this purpose. All other micro-allocations WILL be allocated out of other blocks reserved for micro-allocation purposes. ARIN will make a list of these blocks publicly available. 4.4.2. Exchange point requirements Exchange point operators must provide justification for the allocation, including: connection policy, location, other participants (minimum of two total), ASN, and contact information. 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 does not preclude exchange point operators from requesting address space under other policies. 6.2. Policies for IPv6 allocations and assignments 6.2.1. Allocations and assignments To meet the goal of Fairness, ARIN makes both allocations and assignments according to common criteria. Allocations are made to LIRs, and assignments to certain end users. 6.2.2. Assignments from LIRs/ISPs End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. 6.2.3. Allocations and assignments from ARIN 6.2.3.1 Goals To balance the goals of Aggregation, Conservation, Fairness, and Minimized Overhead, ARIN normally issues IPv6 addresses only in the discrete sizes of /48, /40, /32, /28, or /24 or larger. Each organization or discrete network may qualify for one allocation or assignment of each size, and must pay fees according to ARIN's fee schedule [https://www.arin.net/fees/fee_schedule.html] for each size issued. 6.2.3.1.1 Allocation and assignment from specific blocks Each allocation/assignment size will be made out of separate blocks reserved for that purpose. Additionally, non-routed assignments for internal infrastructure, and assignments to Critical Infrastructure Providers per section 2.8, will each be made out of separate blocks reserved for those purposes. ARIN will make a list of these blocks publicly available. 6.2.3.2 X-Small (/48) To qualify for a /48 allocation or assignment, an organization must: * Be Multihomed per section 2.7, and qualify for an ASN per section 5; or * Serve at least 1000 hosts; or * Demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA; or * Require a non-routed block for internal infrastructure; or * Be a Critical Infrastructure Provider per section 2.8. 6.2.3.3 Small (/40) To qualify for a /40 allocation or assignment, an organization must: * Have two or more Multihomed sites, each of which would qualify for a /48; or * Serve at least 2000 hosts; or * Be an LIR. 6.2.3.4 Medium (/32) To qualify for a /32 allocation or assignment, an organization must: * Have 100 or more sites, each of which would qualify for a /48; or * Be an existing, known LIR; or * Have a plan to provide IPv6 connectivity to other organizations and assign at least 100 end-site assignments to those organizations within 5 years. 6.2.3.5 Large (/28) To qualify for a /28, an organization must demonstrate the need to make assignments and/or reallocations equal to at least 25,000 /48s. 6.2.3.6 X-Large (/24) To qualify for a /24, an organization must demonstrate the need to make assignments and/or reallocations equal to at least 330,000 /48s. 6.2.3.7 XX-Large (larger than /24) Allocations or assignments larger than /24 may be made only in exceptional cases, to organizations that demonstrate the need to make assignments and/or reallocations equal to at least 4,500,000 /48s. If approved, the allocation prefix length will be based on the number of /24s justified (at 4,500,000 /48s each). 6.3. Registration ''(Copied from NRPM 6.5.5)'' When an organization holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate (information registered by ARIN may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /56 networks. When more than a /56 is assigned to an organization, the assigning organization is responsible for ensuring that the address space is registered in an ARIN database. 6.3.1. Residential Customer Privacy ''(Copied from NRPM 6.5.5.1)'' To maintain the privacy of their residential customers, an organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. 6.3.2. Reverse lookup ''(Copied from NRPM 6.5.6)'' When ARIN delegates IPv6 address space to an organization, it also delegates the responsibility to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assignee organization, upon request, the responsibility to manage the reverse lookup zone that corresponds to the assigned address. Rationale: This policy proposal attempts to simplify IPv6 policy in a number of ways. For example, it: * Deletes a number of historical sections and items that duplicate text elsewhere in the NRPM. * Removes the HD-ratio, instead incorporating values calculated from it as the basis for qualification criteria. It also replaces & rewrites section 6.5 "Policies for allocations and assignments" entirely. This rewrite: * Eliminates the different criteria for allocations (ISPs) vs. assignments (end users) and replaces them with a single common set of criteria for both classes of users. The allocation vs. assignment distinction itself is preserved, as it still forms a useful basis for a cost-recovery fee structure, and for other parts of the NRPM (such as whois policy). * Creates a size-class-based system for allocating IPv6 address blocks. This has a number of advantages over the existing policy: ** Allows for safe filtering of traffic-engineering (TE) more-specific route announcements. ** In exchange (since PA more-specifics are expected to be filterable), allows any multihomed organization to get an assignment from ARIN. The smaller number of such PI assignments (compared to TE more-specifics) should mean that such assignments will largely be accepted across the DFZ. ** Expands the use of discrete blocks from which all allocations will be of identical prefix length and categorization. This will enable safer and easier TE filtering, as mentioned above. ** Expands the availability of non-routed blocks for internal infrastructure. Since routable blocks are available to any multihomed organization, there is no longer a need to restrict the availability of blocks from the non-routable pool. ** Makes allocations available to any LIR. Note: In the event of an M&A transfer per section 8.2 that would result in more than one block of a given size class being held by the combined organization, the organization should be encouraged to renumber into a single larger block and return the smaller block(s) when feasible. However, as long as the organization doesn't require any additional resources, this policy does not force them to make any changes. OTOH, if they request a larger block and still hold two or more smaller blocks, they would be required to return the smaller block as a condition for receiving the larger one. Timetable for implementation: Immediate (as soon as practical). _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues. _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact [email protected] if you experience any issues.
