From info at arin.net Fri Oct 5 09:33:14 2007 From: info at arin.net (Member Services) Date: Fri, 05 Oct 2007 09:33:14 -0400 Subject: ARIN XX Reminders Message-ID: <47063D1A.80402@arin.net> Agenda Updates The panel on Wednesday morning is "IP Markets?"; it's about "Physics, Economics, Law, and FUD (get in line early)." Thursday morning now includes a presentation called "IPv6 Support Among Commercial Firewalls." Information on all sessions is available at: http://www.arin.net/ARIN-XX/agenda.html The Open Policy Hour Sign up today to present your ideas at the ARIN XX Open Policy Hour, Tuesday, 16 October, from 6:00-7:00 PM (MDT). If you have a policy proposal you?d like to receive feedback on prior to submitting it to the community on the PPML, here is your opportunity. Those who sign up by 12 October will be given the first opportunity to speak. Send an e-mail to policy at arin.net with your name, organization, and a general description of the policy subject you wish to present. Everyone is invited to attend the session and raise ideas and suggestions. You do not need to have a formal presentation in order to participate. Signing up just guarantees you the opportunity to present. Registration and Remote Participation You still have time to register for ARIN XX. If you are unable to attend in person, you can still participate remotely. Register for the meeting at: http://www.arin.net/ARIN-XX/ Comments received from remote participants will be moderated and presented during normal question and answer periods. ARIN will use e-mail to provide the interactive portion of the remote participation effort. All remote participants are subject to the Remote Participation Acceptable Use Policy (AUP). Additional information about remote participation, including the Remote Participation AUP, is available at: http://www.arin.net/ARIN-XX/webcast.html We look forward to your participation in ARIN XX. Please contact Member Services at info at arin.net if you have any questions. Regards, Member Services Department American Registry for Internet Numbers (ARIN) From info at arin.net Sat Oct 13 21:59:28 2007 From: info at arin.net (Member Services) Date: Sat, 13 Oct 2007 19:59:28 -0600 Subject: Posting of Legacy RSA and FAQ Message-ID: <000001c80e05$dcf3a700$0a00090a@arin.net> The Legacy Registration Services Agreement (RSA), first referenced in the 11 October 2007 announcement, has been posted to the ARIN website at: http://www.arin.net/registration/agreements/legacy_rsa.pdf. A Frequently Asked Questions document is also available to assist the community at: http://www.arin.net/registration/agreements/legacy_rsa_faq.html An implementation date will be announced in the near future. Regards, Raymond A. Plzak President & CEO American Registry for Internet Numbers (ARIN) From info at arin.net Sun Oct 14 18:38:05 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:38:05 -0400 Subject: Policy Proposal 2006-7 - Staff Assessment Message-ID: <47129A4D.4000600@arin.net> Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2006-7 is available as Annex A below and at: http://www.arin.net/policy/proposals/2006_7.html II. Understanding of the proposal ARIN staff understands this proposal would add to the list of criteria for an initial allocation of IPv6 address space (NRPM section 6.5.1.1.). Specifically, in addition to the common criteria, if an ISP is not known, nor can it provide a plan, it can instead attempt to justify intent to announce the address space within one year. III. Comments A. ARIN staff 1. Change I - the statement be a ?known ISP? is still contained in this policy. This term is ambiguous and open to interpretation and should be defined. It should be noted that there is no authoritative definition for either ISP or LIR. 2. ARIN staff is concerned about confusion that may occur if the text is inserted as the author indicated (letter "d" already has an "or"). ARIN staff has suggested alternative placement; see Annex B below. 3. What criteria would staff use to verify that an organization is new to providing "Internet services"? 4. What actions should staff take at the end of 1 year if the v6 block is not announced? 5. The requirement to announce the v6 block at the end of 1 year would seem to preclude the use of this address space on a private network. Is that the intent of this proposal? B. ARIN General Counsel This policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM Policy term: permanent Policy statement: New organizations need a policy that allows them to apply for IPv6 address space. To provide this we need to insert a new additional line item to 6.5.1.1. The new line item would be line 'e' as follows: e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Rationale: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. - Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. - An ISP or LIR may decide to assign a different prefix size than /48. For example, a cellular operator may use /64. - ASN is not required because as long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. - Organization in this is defined as a Corporation, ISP, LLC et al. In SUMMARY if this policy is implemented the change to the NRPM would read as follows: 6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPV6 address space, an organization must: a. be a LIR; b. not be an end site; c. plan to provide IPV6 connectivity to which it will assign IPV6 address space, by advertising that connectivity through its single aggregated address allocation; d. be an existing, known ISP in the ARIN region or have a plan for making at least 200/48 assignments to other organizations within five years. e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Timetable for implementation: Immediate ##*## Annex B ARIN staff suggested format for the insertion of the policy text 6.5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a. be an LIR; b. not be an end site; c. plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through its single aggregated address allocation; and d. meet at least one of the following: 1. be an existing, known ISP in the ARIN region. 2. have a plan for making at least 200 /48 assignments to other organizations within five years. 3. be an organization new to providing internet services that can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. From info at arin.net Sun Oct 14 18:39:53 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:39:53 -0400 Subject: Policy Proposal 2007-13 - Staff Assessment Message-ID: <47129AB9.9090001@arin.net> Policy Proposal 2007-13 Removal of ISP Immediate Need from End-User ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_13.html II. Understanding of the proposal ARIN staff understands that this proposal would remove NRPM Section "4.3.4 Additional considerations" in order to remove text that conflicts with Section "4.2.1.6 Immediate need". III. Comments A. ARIN Staff If the immediate need clause is removed from this policy, then the immediate need policy (Number Resource Policy Manual section 4.2.1.6) needs to be amended to provide for end users. Otherwise, ARIN may not be able to meet the needs of end users who have no current address space in use. B. ARIN General Counsel No legal implications. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 120 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-13 Removal of ISP Immediate Need from End-User Author: Rob Seastrom, David Williamson, Owen DeLong Proposal type: delete Policy term: permanent Policy statement: Delete section 4.3.4, which reads: 4.3.4. Additional considerations End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4]. from the NRPM. Rationale: As discussed at ARIN XIX, section 4.3.4 creates a conflict with section 4.2.1.6 in that section 4.2.1.6 specifically excludes end users while section 4.3.4 is specifically for end users. Prior to the development of the multihoming policy for end users, the immediate need policy was required in order to support end users being able to get address space under some circumstances. The "immediate need" title is a misnomer as it is more an issue of "initial need without prior address utilization" than "immediate need". Such initial needs for end users are now addressed best through the multihoming policy. Timetable for implementation: immediate From info at arin.net Sun Oct 14 18:40:34 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:40:34 -0400 Subject: Policy Proposal 2007-14 - Staff Assessment Message-ID: <47129AE2.8080502@arin.net> Policy Proposal 2007-14 Resource Review Process ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_14.html II. Understanding of the proposal This policy proposal provides clear policy authority to audit or reclaim resources, guidelines for how it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to stop using any resources to be reclaimed. III. Comments A. ARIN Staff 1) 2c does not reconcile with the RSA, which grants ARIN authority to request any data necessary and does not specify any sort of limitation to frequency. 2) Point 4 refers to ?ARIN delegation?. Does this include legacy registrations or is it only ARIN issued resources? 3) Point 3 requires ARIN notify an organization each time a review is conducted. ARIN interprets a review to mean a full audit of an organization's resources conducted by ARIN staff. 4) Points 4 and 5 use the term ?compliance?. ARIN interprets this as bringing the organization into compliance with current policy. 5) Point 4 uses the terms ?single aggregate block?.and ?whole resources?. Are these terms used synonymously to refer to a single CIDR prefix, or to ?a contiguous range of addresses?? 6) Point 6 sets the minimum hold time at 6 months. Current staff procedure is a minimum of one year. 7) Point 6 compels ARIN to take action which doesn?t reconcile with the RSA, which (as articulated above) allows ARIN to take whatever action is necessary. 8) Author did not indicate placement in the NRPM. We would insert as "Section 12 Resource Review Process." B. ARIN General Counsel "Counsel strongly supports some version of this policy being enacted and believes adoption of this policy will save significant future legal fees. This policy proposal spells out a series of customary and contractual policies and rights that are important to make as clear as possible. Counsel does not agree with that portion of the description which states ARIN "feels that current policy does not give them the power...." And believes such powers are adequately vested in ARIN' but believes instead such powers can always be more carefully delineated for ease of understanding." IV. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimal. Barring any unforeseen resource requirements, this policy could be implemented within 30 ? 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Depending on the impact to RSD this may require additional staff. It will require the following: Guidelines Changes Registration System Changes Staff training May increase RSD workload May increase turnaround times Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-14 Resource Review Process Author: Owen DeLong, Stephen Sprunk Proposal type: modify Policy term: permanent Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are necessary to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. at any other time without cause unless a prior review has been completed in the preceding 12 months. 3. ARIN shall communicate the results of the review to the organization. 4. If the review shows that existing usage is substantially not in compliance with current allocation and/or assignment policies, the organization shall return resources as needed to bring them substantially into compliance. If possible, only whole resources shall be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Rationale: ARIN feels that current policy does not give them the power to review or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to renumber out of any resources to be reclaimed. The nature of the "review" is to be of the same form as is currently done when an organization requests new resources, i.e. the documentation required and standards should be the same. The renumbering period does not affect any "hold" period that ARIN may apply after return or revocation of resources is complete. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From info at arin.net Sun Oct 14 18:41:12 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:41:12 -0400 Subject: Policy Proposal 2007-15 - Staff Assessment Message-ID: <47129B08.7020804@arin.net> Policy Proposal 2007-15 Authentication of Legacy Resources ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_15.html II. Understanding of the proposal ARIN staff understands that the proposal would add new sections to the NRPM, 4.9 regarding legacy resources. The purpose is to encourage "legacy resource holders" to sign the RSA. III. Comments A. ARIN Staff ARIN interprets "evaluate and verify chain of custody of any resource records" as the standard ARIN vetting and verification procedures currently in use. B. ARIN General Counsel "This policy may have legal implications. The ARIN board has authorized the creation of legacy RSA 1.0 which contains very favorable terms for legacy address holders designed to entice, or provide incentives to both sign the specifically designed rsa to obtain continued future services, and to return under utilized resources to ARIN. Policy 2007-15 takes this one step further and adds the incentive of the future fixed date reduction of in-addr services, or stick, not carrot, to the policy alternatives. If the policy is adopted, there is modest risk legacy holders who have received free services in the past, without any agreement with ARIN, could attempt to litigate about such policy. Currently I am unaware of any contractually binding or implied duty of ARIN to maintain such service in the absence of policy to this effect. Therefore I have no current legal objection to the proposed policy." Resource Impact ? Significant The resource impact of implementing this policy is viewed as significant. Barring any unforeseen resource requirements, this policy could be implemented from 6 months to 1 year from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Registration Services Guidelines will be required - Staff training will be required - Additional staff may be required - Database changes - New tracking tools Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-15 Authentication of Legacy Resources Author: Andrew Dul Proposal type: New Policy term: Permanent Policy statement: Add new NRPM section 4.9 - Legacy Records 4.9 - Legacy Records Legacy resource record holders shall be permitted to sign a registration services agreement which permits the legacy organization which is currently using the resources as of January 1, 2007 to continue to use those resources as long as a valid registration services agreement is in effect for the organization. ARIN will evaluate and verify the chain of custody of any resource records prior to executing a registration services agreement with an organization. ARIN shall use all reasonable methods to attempt to contact legacy record holders starting on January 1, 2008 to notify them of this change in policy. ARIN shall also post information on the public website regarding this outreach to legacy resource holders. No changes shall be made to legacy resource records which are not covered by a registration services agreement after December 31, 2007. If a legacy resource holder requests additional IPv4 resources all IPv4 resources (legacy and non-legacy) shall be evaluated to determine utilization for additional allocations or assignments under NRPM sections 4.2 or 4.3. Rationale: An ARIN Legacy resource holder is an organization which was issued number resources prior to the formation of ARIN and whose registration information was not transferred to another RIR through the Early Registration Transfer Project (http://www.arin.net/registration/erx). Legacy resource holders were issued number resources through an informal process. This policy proposal attempts to bring these legacy resource holders into a formal agreement with ARIN, the manager of the IP numbering resources for many of the legacy record holders. This policy is similar to a policy which has been adopted in the APNIC region. (http://www.apnic.net/docs/policy/proposals/prop-018-v001.html) Some legacy resource holders have expressed concerns about committing to a registration service agreement (RSA) when the legacy resource holder cannot be assured that they will be permitted to retain their resources for the long-term. This policy proposal requests ARIN to develop a RSA which will allow legacy resource holders to continue to use IPv4 resources which were assigned or allocated prior to ARIN's formation. It is also suggested that the Board of Trustees formalize the annual maintenance fees for legacy resource holders at a level similar to the $100 USD per year for end-sites or provide fee-waivers as an incentive for legacy holders to sign a registration services agreement. The dates in this policy proposal were arbitrarily chosen based upon an expected ratification by the ARIN Board of Trustees by December 31, 2007. If this policy is implemented after December 31, 2007, the trigger dates in the policy should be adjusted appropriately. Given the informal relationship under which the resources were granted, ARIN currently maintains the records including WHOIS and in-addr.arpa delegations in a best-effort fashion. Some believe that ARIN may not be obligated to maintain these records. ARIN has also experienced some difficulty maintaining these records. Legacy records have been a popular target for hijackers, in part due to the out of date information contained in these records. Having up to date contact information and a formal relationship with legacy record holders would assist ARIN and ISP's in insuring these records are maintained accurately. Legacy resource holders who sign a RSA would continue to receive all the services that are currently provided by ARIN plus they would be eligible for any future services that ARIN may offer, such as cryptographic signing of resource records. Timetable for implementation: As stated in policy From info at arin.net Sun Oct 14 18:41:46 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:41:46 -0400 Subject: Policy Proposal 2007-16 - Staff Assessment Message-ID: <47129B2A.2050507@arin.net> Policy Proposal 2007-16 IPv4 Soft Landing ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_16.html II. Understanding of the proposal The proposal "aims to provide for a defined transition away from IPv4 address space towards IPv6 address space by imposing increasingly stricter requirements for new address allocations." III. Comments A. ARIN Staff General Comments ? 1. The policy seems to apply only to the general IPv4 ISP policy. Does this policy also apply to the other ISP additional policies like multiple discreet networks (NRPM 4.5) and cable (NRPM 4.2.6)? 2. Does this policy supersede the ISP additional request policy and any other ISP additional request policies? If so, this should be clearly stated. 3. In the policy statement, the author discusses utilization rates and refers to swip and rwhois. These terms should be removed because they are not necessarily relevant to all customers (those that assign smaller than /28s or orgs that manage dynamic address pools, Voip, etc?). 4. In the policy statement, the author refers to specific fields in the template. This should be removed since template fields will change over time. 5. A general question of fairness comes up when you consider that ISP?s will now be faced with much more difficulty in obtaining IP address space from ARIN while end users will feel no effect or change at all. Phase 0: No comments. Phase 1: No comments Phase 2: No comments Phase 3: No comments 6. Author indicated placement in the NRPM. All the text from "begin modification" to "end modification" would be placed in Section 4.2.4.1. Subsections would be created. The title of the section would be changed to "Utilization Requirements". We would strike the "80%" reference in 4.2.3.4.1. B. ARIN General Counsel Counsel does not see any legal implications with this policy. Resource Impact ? Moderate The resource impact of implementing this policy is moderate. Barring any unforeseen resource requirements, this policy could be implemented within 3-6 months from the date of the ratification of the policy by the ARIN Board of Trustees It will require the following: - Significant staff training - Template changes - New Registration Services tools - Guidelines changes - Significant increase in processing time Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy statement Policy Proposal 2007-16 IPv4 Soft Landing Author: David Conrad Proposal type: New Policy term: Permanent Policy statement: This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of: --- begin modification --- 4.2.4.1 In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation "phases" that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent. When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses. IPv4 Allocation Phases The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section. Phase: 0 Threshold: Greater than 40 /8s Requirements: Requesters must: * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization Phase: 1 Threshold: 40 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. Phase: 2 Threshold: 25 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. * Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate. * Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request. Phase: 3 Threshold: 10 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization * Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing. * Demonstrate availability of production IPv6 infrastructure and connectivity services. Notes: * Phase 0 reflects current allocation requirements. * Phases 1 through 3 are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. * If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space at the time of the request. --- end modification --- Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses for requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the documentation or reuse of public IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify conformance to the specified requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby offering an opportunity to break the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when the RIR's current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a "reasonable" amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. From info at arin.net Sun Oct 14 18:42:19 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:42:19 -0400 Subject: Policy Proposal 2007-17 - Staff Assessment Message-ID: <47129B4B.8090504@arin.net> Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_17.html II. Understanding of the proposal ARIN staff understands that the proposal would modify NRPM Section 4.6. Ignoring the parts that concern fees and waivers, the proposal would change the current policy by removing the defined timeframe for returning address space to ARIN. III. Comments A. ARIN Staff 1. There is currently an aggregation policy in NRPM 4.7. This proposal seems to be confusing and perhaps contradicting that existing policy. Does this proposal replace the existing aggregation policy 4.7 in NRPM? 2. The policy seems to suggest some type of fee waiver which does not belong within policy. See ARIN General Counsel comments below. 3. ARIN?s current practice requires a signed Registration Services Agreement (RSA) from organizations receiving number resources. The proposed policy should clarify this requirement in section 3. B. ARIN General Counsel ?I have reviewed this policy and believe it poses no significant risk of litigation by outside parties. However, in my non-legal opinion, acting as counselor to the Board and AC, the policy does something I have never previously seen and encroaches on how ARIN has operated by custom. To date, the ARIN Board of Trustees has unilaterally debated and set the rates of payment for any ARIN services. Overall, this policy proposal substitutes a policy with specific numerical promises. This would impinge on the Board's ability to holistically adjust such economic numbers, for example, to create a new incentive by going even further than the policy, or less than the policy to achieve its aims. The author and AC might consider substitution of an alternative draft policy that gives strong directional adjectival guidance to the Board, but does not contain specific amounts. For example, and I believe consistent with the proposed policy, the policy adopted can make clear the community is sending clear guidance that the economic inducements for legacy address holders to sign a new and publicly available alternative RSA for legacy holders can be accomplished more deftly by providing an RSA, not a policy. The discussion approved to accompany the policy can contain non-binding but specific recommendations for this purpose, which the Board would probably welcome. An RSA is a contract. ARIN can unilaterally bind itself in such contracts, promising consistent future terms, including any promise ARIN chooses to make to not charge for certain services. But the RSA can also be phased out, not impacting contracted parties, but not be available for future parties who do not sign up. Such flexibility in the RSA, with the Board following aspirational policy is a correct direction for the continued development of this proposal.? Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Registration Services Guidelines will be required - Staff training will be required - Tracking tools for the return of the space Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Proposal type: modify Policy term: permanent Policy statement: Modify section 4.6 as follows: 4.6 Amnesty Requests: ARIN will accept the return or relinquishment of any address space from any existing address holder. If the address holder wishes to aggregate into a single block, ARIN may work with the address holder to arrive at an allocation or assignment which is equal to or smaller than the sum of their existing blocks and which best meets the needs of the existing holder and the community. The organization returning the addresses shall have 12 months from the date they receive their new addresses to return the addresses under this policy. Organizations may request no more than 2 six month extensions to this time, which, may be granted at ARIN the discretion of ARIN staff. There shall be no fee for returning addresses under this policy. Further, organizations returning addresses under this policy shall receive the following benefits: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. The BoT shall develop an incentive program to encourage such returns. Such incentives may include fee reductions and/or other such mechanisms as the BoT deems appropriate. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that all of their IPv4 and ASN resources are henceforth subject to the RSA. Organizations taking this election shall be subject to end-user fees for their IPv4 resources not previously under an ARIN RSA. If they are already an ARIN subscriber, then IPv4 resources affected by this process may, instead, be added to their existing subscriber agreement at the address holder's discretion. Rationale: The current amnesty policy does a nice job of facilitating aggregation, which was the intent when it was drafted. However, as we approach IPv4 free-space exhaustion, the community now has an additional need to facilitate address reclamation. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process. Further, there is an unfortunate perception that doing so will require force the legacy holder into certain future disadvantages. This proposal attempts to resolve both of those issues while also providing some incentive to legacy organizations to start using IPv6 resources and bring their IPv4 resources into the ARIN process. This policy attempts to provide some benefit and remove most of the costs of making partial IPv4 returns. It also attempts to provide an incentive for these IPv4 holders to join the ARIN process. It is suggested that the BoT adopt fee incentives such as the elimination of 2 years of ARIN fees for each /20 returned. Timetable for implementation: Immediate From info at arin.net Sun Oct 14 18:42:48 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:42:48 -0400 Subject: Policy Proposal 2007-18 - Staff Assessment Message-ID: <47129B68.3070009@arin.net> Policy Proposal 2007-18 Global Policy for the Allocation of the Remaining IPv4 Address Space ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_18.html II. Understanding of the proposal ARIN staff understands that this proposal is a global proposal. It would reserve a certain number of /8s in the IANA pool to be allocated to the RIRs when the remaining IANA /8s run out. The suggested reserve is 25 /8s, 5 per each RIR. When the IANA can not fulfill the last RIR request, they will give what they can to that RIR. The IANA will then allocate the 5 /8s to each RIR. III. Comments A. ARIN Staff 1. The policy conflicts with the spirit of RFC 2050 in which fairness and efficiency of allocation by IANA to the RIRs is cited. 2. If additional addresses are made available to IANA at some point after the exhaustion phase is triggered, this policy would need to be revised before IANA could do anything with the addresses. 3. Author did not indicate placement in the NRPM. Staff would add it to Section 10. B. ARIN General Counsel "These two policies address the same issue, the global policy of what allocation should be made and when regarding the last unissued IPv4 slash 8's from the IANA. Based on legal considerations counsel has serious concerns about the implications of adopting 2007-18. Counsel does not have similar concerns about 2007-23. 2007-23 describes a policy to allocate equally the last 5 blocs of unissued slash 8's, providing one each to each of the 5 RIR's. This is a rationing mechanism to allocate the last slash 8's. 2007-18 describes much more aggressive policy which would allocate the last 25 such blocs equally, providing 5 each to each RIR. The first policy proposal, 2007-23, is more consistent with the current legal underpinnings of the RIR system, while 2007-23 substitutes a new basis of allocation, equality between RIRs, who have very different rates of utilization and need. The substitution of utilizing RIR equality instead of a utilization based allocation may have significant legal implications for ARIN. Currently, if ARIN is legally challenged about its allocation policies, and the underlying global policy, all current policies are based in need and utilization. Since the takeup rate in each RIR is very different the allocation policy proposed in 2007-23 undermines the current rationale of need and utilization based allocation, and it is inconsistent with all prior ARIN and global allocation policies. Adoption of 2007-23 discriminates against the ARIN service region and could reduce the amount of IPv4 resources available and instead shift these resources to other continents, with less actual need than the ARIN region. This will, in my opinion, raise fiduciary responsibility issues for ARIN's Board, and may lead to counsel cautioning the Board members regarding adoption of global policy that has an intentionally discriminatory impact against or adverse to ARIN's service region." Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-18 Global Policy for the Allocation of the Remaining IPv4 Address Space Author: Roque Gagliano Co-authors: Francisco Obispo, Hytham EL Nakhal, Didier Allain Kla Proposal type: new Policy term: permanent Policy statement: This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. In order to fulfill the requirements of this policy, at the time it is adopted, an identical number of IPv4 allocation units (N units) will be reserved by IANA for each RIR. The number N is defined as: 5. The reserved allocation units will no longer be part of the available space at the IANA pool. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases: 1. Existing Policy Phase: During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA cannot be fulfilled with the remaining IPv4 space available at the IANA pool. This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process will be initiated. 2. Exhaustion Phase: IANA will automatically allocate the reserved IPv4 allocation units to each RIR (N units to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units). 2.1. Size of the final IPv4 allocations: During this phase IANA will automatically allocate N allocation units to each RIR from the reserved space defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses. 2.2. Allocation of the remaining IPv4 Address space: After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST: A) Immediately notify the NRO about the activation of the second phase of this policy. B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space. C) Proceed to allocate N allocation units to each RIR from the reserved space. Rationale: The IANA pool of allocation units of IPv4 addresses (/8s) is decreasing rapidly. A new policy is proposed to replace the current "on demand" policy in order to bring certainty on how the remaining space will be allocated. This policy eliminates the pressure on the remaining central pool of addresses by allocating equal amount of allocation units (N) to each RIR. RIR may be studying slow-landing policies or the possibility to reserve specific address spaces for "critical infrastructure" or new companies in order to comply with anti-trust regulations in its region. This policy allows each RIR to adopt those policies through its PDP, which is simpler than a global policy discussion process. Each RIR will have the exact information on the amount of address spaces that they will be receiving as a last allocation from the IANA. The policy is written in such a way that the discussion could be split in two sections: first do we agree on the concept of the policy and second what is the appropriate value for the last allocation units N. Timetable for implementation: This is a Global policy that needs to be approved by all RIRs and then ratified by ASO/ICANN. It has already reached consensus at LACNIC meeting. From info at arin.net Sun Oct 14 18:43:29 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:43:29 -0400 Subject: Policy Proposal 2007-19 - Staff Assessment Message-ID: <47129B91.4050608@arin.net> Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_19.html II. Understanding of the proposal ARIN staff understands that this proposal is a global proposal. It would create policy for IANA to RIR regarding allocations of ASNs. Block size is 1024. Allocations for 12 months need. Until 31 Dec 2009, allocations of 2-byte and 4-byte blocks are separate. RIRs request additional ASNs when either at 80% or at less than two months need. III. Comments A. ARIN Staff 1. The ?Additional Allocations? section indicates an RIR can receive an additional ASN allocation when the RIR ?has assigned/allocated 80% of the previously received ASN block?. After 12/31/2009, there will be no distinction made between 2 byte AS numbers and 4 byte AS numbers per policy. Does ?previously received ASN block? literally mean the most recent ASN block (even if it was a 2 byte only block), or does it mean 80% of both the most recent 4 byte block and the most recent 2 byte block? If it?s the latter, one ASN block would never be audited, since it would never be ?the most recent ASN block allocated?. 2. The policy will be inserted in Section 10 of the NRPM. B. ARIN General Counsel "Counsel has no legal concerns regarding this policy. Counsel believes policies allocating resources based on usage and need are consistent with the operating philosophy of the RIR Community. Other policy proposals, inconsistent with this philosophy should be subject to greater scrutiny." Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs Author: Axel Pawlik Proposal type: New Policy term: renewable Policy statement: Abstract This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs). This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO). 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2009, allocations of 2-byte only and 4-byte only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 2-byte only and 4-byte only ASNs, and will operate ASN allocations from an undifferentiated 4-byte ASN allocation pool. 2. Initial Allocations Each new RIR will be allocated a new ASN block. 3. Additional Allocations An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met: 1. The RIR has assigned/allocated 80% of the previously received ASN block, or 2. The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months. An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for. 4. Announcement of IANA Allocations The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. [1. http://www.ripe.net/ripe/policies/proposals/2005-12.html] Policy Rationale Rationale: There are global policies governing the allocation of IPv4 and IPv6 blocks from the IANA to RIRs. At this point there is no specific policy regarding the allocation of Autonomous System Numbers from the IANA to the RIRs. This proposal will create a policy to fill this gap. The criteria being proposed has already been the practice between IANA and RIRs so far and it has been proven to work. It is designed to allow RIRs to request ASN blocks from the IANA in a timely fashion and maintain enough ASNs in holding to ensure that their registration services can be sustained. It is also proposed that the RIRs be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months. This will generally mean that each RIR will only need to make one ASN request from the IANA each year, thus lowering operational overhead for the RIRs. Timetable for implementation: Immediate From info at arin.net Sun Oct 14 18:43:55 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:43:55 -0400 Subject: Policy Proposal 2007-21 - Staff Assessment Message-ID: <47129BAB.8090902@arin.net> Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_21.html II. Understanding of the proposal ARIN staff understands that this proposal would make direct assignments of IPv6 space available to any organization with an efficiently utilized v4 assignment or allocation covered under an RSA. III. Comments A. ARIN Staff The title uses the words ?legacy holder? which is never mentioned within the policy text. B. ARIN General Counsel This policy does not create any legal concerns. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 ? 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required - New process to manually add RSA coverage will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use Author: Scott Leibrand Proposal type: new Policy term: permanent Policy statement: Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user organizations: Criteria), to read: To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of a direct IPv4 assignment or allocation covered by a current ARIN RSA. Rationale: Current policy allows direct IPv6 allocations and assignments to nearly all organizations with IPv4 allocations or assignments from ARIN. As a result, such organizations can get IPv6 space just as easily as they can get IPv4 space, making it easy for them to transition to IPv6 as soon as they're ready to do so. However, there are some organizations who received IPv4 /23's and /24's prior to the formation of ARIN, and use that space in a multihomed, provider-independent fashion. Under current policy, such organizations cannot get IPv6 PI space without artificially inflating host counts, and are therefore discouraged from adopting IPv6. This policy proposal aims to remove this disincentive, and allow such organizations to easily adopt IPv6. In addition, pre-ARIN assignments were issued through an informal process, and many legacy resource holders have not yet entered into a formal agreement with ARIN, the manager of many such IP numbering resources. This policy proposal would require that such assignments be brought under a current ARIN Registration Services Agreement, thereby formalizing the relationship. Some pre-ARIN assignments may not be used efficiently. As unallocated IPv4 numbering resources are approaching exhaustion, it is important to ensure efficient utilization of IPv4 assignments, and to arrange for reclamation of unused space. Therefore, this policy would require that the organization wishing to receive IPv6 PI space demonstrate efficient utilization of their IPv4 assignment. (Efficient utilization is already defined elsewhere in policy, and the exact mechanism for achieving and determining efficient use is a matter of procedure, not of policy, so detailed procedures are not included in the policy statement above. The intent is that any organization with an assignment of /23 or larger which is less than 50% utilized would renumber and return whole unused CIDR blocks as necessary to bring the remaining CIDR block to 50% utilization or higher. A /24 should be considered efficiently utilized as long as it is in use for multihoming, as /25's and smaller are not routable for that purpose.) It has been suggested that this policy would be useful only until the growth of IPv6 exceeds the growth of IPv4. I would agree with this, and would further posit that the existing "qualify ... under the IPv4 policy currently in effect" language should also be modified at that time. I have therefore proposed this policy with a policy term of "permanent", with the expectation that this section of policy (6.5.8.1) will be rewritten at the appropriate time to entirely remove all IPv4 dependencies. Timetable for implementation: immediate From info at arin.net Sun Oct 14 18:44:27 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:44:27 -0400 Subject: Policy Proposal 2007-22 - Staff Assessment Message-ID: <47129BCB.3040107@arin.net> Policy Proposal 2007-22 Expand timeframe of Additional Requests ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_22.html II. Understanding of the proposal ARIN staff understands that the proposal would change the allocation timeframe in 4.2.4.4 from six months to 12. III. Comments A. ARIN Staff 1. In addition to changing the time period from 6 months to one year, this policy removes the qualification criteria that a member be a subscriber with a direct ARIN allocation. If an organization has no allocation history with ARIN, it makes it difficult to reliably verify and evaluate a 12 month projection. 2. ARIN staff suggests changing the section name of NRPM 4.2.4.4 from "Six months" to "Twelve months". B. ARIN General Counsel Counsel does not believe this policy raises legal concerns. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimal. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required - Template changes will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-22 Expand timeframe of Additional Requests Author: Dan Alexander Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. Timetable for implementation: Immediate From info at arin.net Sun Oct 14 18:45:00 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:45:00 -0400 Subject: Policy Proposal 2007-23 - Staff Assessment Message-ID: <47129BEC.2080605@arin.net> Policy Proposal 2007-23 End Policy for IANA IPv4 allocations to RIRs ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_23.html II. Understanding of the proposal ARIN staff understands that this policy would have IANA allocate a single /8 to each of the 5 RIRs at the point when the IANA free pool hits 5 /8s. III. Comments A. ARIN Staff 1. Item 3 indicates that the RIRs will project an IANA exhaustion date. The RIRs do not generally make projections about address space, and in particular, about the IANA pool since they have no control over these resource. 2. The policy conflicts with the spirit of RFC 2050 in which fairness and efficiency of allocation by IANA to the RIRs is cited. 3. Author did not indicate placement in the NRPM. It would go in to Section 10. B. ARIN General Counsel "These two policies address the same issue, the global policy of what allocation should be made and when regarding the last un-issued IPv4 slash 8's from the IANA. Based on legal considerations counsel has serious concerns about the implications of adopting 2007-18. Counsel does not have similar concerns about 2007-23. 2007-23 describes a policy to allocate equally the last 5 blocs of un-issued slash 8's, providing one each to each of the 5 RIR's. This is a rationing mechanism to allocate the last slash 8's. 2007-18 describes much more aggressive policy which would allocate the last 25 such blocs equally, providing 5 each to each RIR. The first policy proposal, 2007-23, is more consistent with the current legal underpinnings of the RIR system, while 2007-23 substitutes a new basis of allocation, equality between RIRs, who have very different rates of utilization and need. The substitution of utilizing RIR equality instead of a utilization based allocation may have significant legal implications for ARIN. Currently, if ARIN is legally challenged about its allocation policies, and the underlying global policy, all current policies are based in need and utilization. Since the takeup rate in each RIR is very different the allocation policy proposed in 2007-23 undermines the current rationale of need and utilization based allocation, and it is inconsistent with all prior ARIN and global allocation policies. Adoption of 2007-23 discriminates against the ARIN service region and could reduce the amount of IPv4 resources available and instead shift these resources to other continents, with less actual need than the ARIN region. This will, in my opinion, raise fiduciary responsibility issues for ARIN's Board, and may lead to counsel cautioning the Board members regarding adoption of global policy that has an intentionally discriminatory impact against or adverse to ARIN's service region." Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 -90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-23 End Policy for IANA IPv4 allocations to RIRs Author: JPNIC IPv4 countdown policy team; Akinori MAEMURA, Akira NAKAGAWA, Izumi OKUTANI, Kosuke ITO, Kuniaki KONDO, Shuji NAKAMURA, Susumu SATO, Takashi ARANO, Tomohiro FUJISAKI, Tomoya YOSHIDA, Toshiyuki HOSAKA Proposal type: new Policy term:renewable Policy statement: 1) Distribute a single /8 to each RIR at the point when new IANA free pool hits 5 */8. This date is defined as "IANA Exhaustion Date". 2) It should be completely left up to each RIR communities to define a regional policy on how to distribute the remaining RIR free pool to LIRs within their respective regions after "IANA Exhaustion Date". Note 1: It is fine for an RIR to continue operations with the existing policy if that is the consensus decision of the respective RIR community. Note 2: Address recovery and re-distribution of recovered address space is another important measure for considerations, but should be treated as a separate policy proposal from distribution of new IANA pool. 3) RIRs should provide an official projection on IANA Exhaustion Date to the community through their website, at their Policy Meetings and through any other effective means. Rationale: [current problem] There are two major issues in terms of address management if no measures are taken for IPv4 address exhaustion. 1) Continue applying a global coordinated policy for distribution of the last piece(s) of RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. 2) LIRs and stakeholders remain unprepared for the situation if they are not informed If LIRs and the community are uninformed of the exhaustion, their services and networks remain unprepared to face the situation at the time of exhaustion. [Objective of the proposal] This proposal seeks to provide the following solutions to the problems listed above. 1) RIR community should be able to define their own regional policies on how to assign the last piece(s) of allocation block in order to address their own regional issues during the exhaustion period. 2) RIRs should provide official projection of the date when LIRs will be able to receive the allocations under the current criteria. The criteria should remain consistent until this date in order to avoid confusion. [Pros and Cons] Pros: + It allows each RIR community to define a policy on how to distribute the last piece(s) of allocations which best matches their situation. + It helps LIR better informed of the date when they are able to receive allocations from RIRs under the current criteria and prepare for the event. Cons: + Concerns could be raised about allocating a fixed size to all RIRs, that it artificially fastens the consumption rate of some RIR regions. However, its impact is kept to minimum by keeping the allocation size to a single /8 which makes merely 3-4 months difference. + Concerns could be raised that explicitly allowing regional policies will encourage RIR shopping. However, this should not happen if the requirements within each region is adequately reflected in each RIR's policy through PDP. RIR may also chose to add criteria to prevent LIRs from other regions submitting such requests. Timetable for implementation: Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy. From info at arin.net Sun Oct 14 18:45:38 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:45:38 -0400 Subject: Policy Proposal 2007-24 - Staff Assessment Message-ID: <47129C12.4040503@arin.net> Policy Proposal 2007-24 IPv6 Assignment Guidelines ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_24.html II. Understanding of the proposal ARIN staff understands that this proposal would replace 6.5.4.1. Instead of the assignment size being a decision of the LIR or ISP, the actual prefix to be assigned would be based on a subnet count. III. Comments A. ARIN Staff 1. Currently, there have been 54 IPv6 reassignments/reallocations larger than /48 made by ISPs to their customers. If staff is expected to review each and every one larger than /48, this could significantly increase workload and turnaround times. 2. If staff is expected to review all reassignments larger than /48, should this be done at the time the reassignment is made or at the time the organization is requesting additional IPv6 space from ARIN? B. ARIN General Counsel Counsel does not believe this policy creates any legal issues. Resource Impact ? Moderate The resource impact of implementing this policy is viewed as moderate. Barring any unforeseen resource requirements, this policy could be implemented within 3 ? 6 months from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required - Template changes will be required (text fields only, no software impact) - Sustaining this activity could require the need for additional staff and associated costs. Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-24 IPv6 Assignment Guidelines Author: Leo Bicknell and Ed Lewis Proposal type: new Policy term: permanent Policy statement: Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 with the following text: Assignments by LIRs /48 or smaller will not be reviewed by ARIN. Assignments greater than /48 will be reviewed to see if the additional space is warranted according to the 0.94 HD ratio policy. If the space is not warranted, ARIN will consider the excess space to be available for a different assignment, lowering the overall utilization score of the LIR. Rationale: The existing section 6.5.4.1 does not provide clear guidance on how ARIN should treat prefixes allocated to a site should an ISP come back for additional space in the future. This makes it difficult for LIR's to know if they are allocating in accordance with the rules under which they will be judged in the future. The existing section also provides no guidence on what the LIR or ARIN should do in the case a larger prefix is necessary. Timetable for implementation: immediate From info at arin.net Sun Oct 14 18:46:08 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:46:08 -0400 Subject: Policy Proposal 2007-25 - Staff Assessment Message-ID: <47129C30.2020303@arin.net> Policy Proposal 2007-25 IPv6 Policy Housekeeping ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_25.html II. Understanding of the proposal ARIN staff understands that this proposal would make changes to the IPv6 section of the NRPM. It would remove the prefix size from the initial IPv6 allocation criteria, move a modified version of 6.5.3 to a new location (6.5.4.4), establish criteria for assignments larger than a /48 (.94 HD-Ratio), and make reserved space (from the /44s) available for other use. III. Comments A. ARIN Staff 1. Change I - the statement be a ?known ISP? is still contained in this policy. This term is ambiguous and open to interpretation and should be defined. It should be noted that there is no authoritative definition for either ISP or LIR. 2. Change J - The section number, 6.5.3, would be retired instead of renumbering all the subsequent sections. B. ARIN General Counsel Counsel does not believe this policy creates any legal issues that need further consideration. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required - May be minor text changes to the template Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-25 IPv6 Policy Housekeeping Author: Leo Bicknell Proposal type: modify Policy term: permanent Policy statement: Change I: In section 6.5.1.1.d, replace the existing statement with the new statement: "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." Change J: Remove section 6.5.3 entirely. Update all subsequent sections to have new section numbers (6.5.[n-1]). Replace part of the text as (new) section 6.5.4.4: "All /56 and larger assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary." Change K: Section 6.5.8.2, add the following sentence to the end of the first paragraph: "An HD-Ratio of .94 must be met for all assignments larger than a /48." Add to the end of the second paragraph: "This reservation may be assigned to other organizations later, at ARIN's discretion." Change L: Section 6.5.8.3, add a sentence between the two existing sentences: "Justification will be determined based on the .94 HD-Ratio metric." Rationale: When the IPv6 policy was passed, it was considered to be an "interim" policy, and it was intended to be similar in all 5 RIR's. Since that time it has become clear the policy is no longer interim (and proposal 2007-4 was passed to change just that) and it has also been modified separately in the different RIR's. It was brought to the ARIN AC's attention that there were a number of problems with "Section 6" of the NRPM as a result of this legacy: * The policy contained a large number of items that were not policy. * The policy contained a few items that were self contradictory. * The added text was redundant in some cases with existing text. * The policy was overly vague in a few areas, leaving ARIN staff to have to make interpretations of what the policy intended. * Policy changes made since the initial IPv6 policy was adopted have not always updated all of the relevant sections due to the complexity of section 6. The intent of these changes is not to change any existing policy, but rather to remove all non-policy items, and update any ambiguous items with the way that ARIN staff is currently interprets the policy. Change I: Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 allocations, but section 6.5.1.1.d was never updated to match the change. It is believed the intent of the policy, and ARIN staff's current interpretation of the policy match the updated text. Change J: The first part is not policy, and incorrectly states there is no policy as section 6.5.4 has the policy in it. Take the one useful part and make it part of the 6.5.4 criteria. Change K: No metric is currently listed to justify a larger initial assignment. It is believed ARIN staff is currently applying the HD-Ratio similar to the ISP policy, this puts that in writing. Make it clear that the reservation may not exist in perpetuity. Change L: No metric is given to justify additional assignments. It is believed that ARIN staff is currently applying the HD_Ratio similar to the ISP policy, this puts that in writing. Timetable for implementation: Immediate From info at arin.net Wed Oct 17 09:44:02 2007 From: info at arin.net (Member Services) Date: Wed, 17 Oct 2007 09:44:02 -0400 Subject: Policy Proposal 2007-17 - Staff Assessment Message-ID: <471611A2.8070506@arin.net> Revised Staff Assessment - 17 October 2007 Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_17.html II. Understanding of the proposal ARIN staff understands that the proposal would modify NRPM Section 4.6. Ignoring the parts that concern fees and waivers, the proposal would change the current policy by changing the timeframe for returning address space to ARIN. III. Comments A. ARIN Staff There is currently an aggregation policy in NRPM 4.7. This proposal seems to be confusing and perhaps contradicting that existing policy. Does this proposal replace the existing aggregation policy 4.7 in NRPM? B. ARIN General Counsel ?I have reviewed this policy and believe it poses no significant risk of litigation by outside parties. However, in my non-legal opinion, acting as counselor to the Board and AC, the policy does something I have never previously seen and encroaches on how ARIN has operated by custom. To date, the ARIN Board of Trustees has unilaterally debated and set the rates of payment for any ARIN services. Overall, this policy proposal substitutes a policy with specific numerical promises. This would impinge on the Board's ability to holistically adjust such economic numbers, for example, to create a new incentive by going even further than the policy, or less than the policy to achieve its aims. The author and AC might consider substitution of an alternative draft policy that gives strong directional adjectival guidance to the Board, but does not contain specific amounts. For example, and I believe consistent with the proposed policy, the policy adopted can make clear the community is sending clear guidance that the economic inducements for legacy address holders to sign a new and publicly available alternative RSA for legacy holders can be accomplished more deftly by providing an RSA, not a policy. The discussion approved to accompany the policy can contain non-binding but specific recommendations for this purpose, which the Board would probably welcome. An RSA is a contract. ARIN can unilaterally bind itself in such contracts, promising consistent future terms, including any promise ARIN chooses to make to not charge for certain services. But the RSA can also be phased out, not impacting contracted parties, but not be available for future parties who do not sign up. Such flexibility in the RSA, with the Board following aspirational policy is a correct direction for the continued development of this proposal.? Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Registration Services Guidelines will be required - Staff training will be required - Tracking tools for the return of the space Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Proposal type: modify Policy term: permanent Policy statement: Modify section 4.6 as follows: 4.6 Amnesty Requests: ARIN will accept the return or relinquishment of any address space from any existing address holder. If the address holder wishes to aggregate into a single block, ARIN may work with the address holder to arrive at an allocation or assignment which is equal to or smaller than the sum of their existing blocks and which best meets the needs of the existing holder and the community. The organization returning the addresses shall have 12 months from the date they receive their new addresses to return the addresses under this policy. Organizations may request no more than 2 six month extensions to this time, which, may be granted at ARIN the discretion of ARIN staff. There shall be no fee for returning addresses under this policy. Further, organizations returning addresses under this policy shall receive the following benefits: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. The BoT shall develop an incentive program to encourage such returns. Such incentives may include fee reductions and/or other such mechanisms as the BoT deems appropriate. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that all of their IPv4 and ASN resources are henceforth subject to the RSA. Organizations taking this election shall be subject to end-user fees for their IPv4 resources not previously under an ARIN RSA. If they are already an ARIN subscriber, then IPv4 resources affected by this process may, instead, be added to their existing subscriber agreement at the address holder's discretion. Rationale: The current amnesty policy does a nice job of facilitating aggregation, which was the intent when it was drafted. However, as we approach IPv4 free-space exhaustion, the community now has an additional need to facilitate address reclamation. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process. Further, there is an unfortunate perception that doing so will require force the legacy holder into certain future disadvantages. This proposal attempts to resolve both of those issues while also providing some incentive to legacy organizations to start using IPv6 resources and bring their IPv4 resources into the ARIN process. This policy attempts to provide some benefit and remove most of the costs of making partial IPv4 returns. It also attempts to provide an incentive for these IPv4 holders to join the ARIN process. It is suggested that the BoT adopt fee incentives such as the elimination of 2 years of ARIN fees for each /20 returned. Timetable for implementation: Immediate From info at arin.net Wed Oct 17 09:46:02 2007 From: info at arin.net (Member Services) Date: Wed, 17 Oct 2007 09:46:02 -0400 Subject: Policy Proposal 2007-14 - Staff Assessment Message-ID: <4716121A.30008@arin.net> Revised Staff Assessment - 17 October 2007 Policy Proposal 2007-14 Resource Review Process ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_14.html II. Understanding of the proposal This policy proposal provides clear policy authority to audit or reclaim resources, guidelines for how it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to stop using any resources to be reclaimed. III. Comments A. ARIN Staff 1) 2c does not reconcile with the RSA, which grants ARIN authority to request any data necessary and does not specify any sort of limitation to frequency. 2) Point 3 requires ARIN notify an organization each time a review is conducted. ARIN interprets a review to mean a full audit of an organization's resources conducted by ARIN staff. 3) Point 4 uses the terms ?single aggregate block?.and ?whole resources?. Are these terms used synonymously to refer to a single CIDR prefix, or to ?a contiguous range of addresses?? 4) Point 6 compels ARIN to take action which doesn?t reconcile with the RSA, which (as articulated above) allows ARIN to take whatever action is necessary. 5) Author did not indicate placement in the NRPM. We would insert as "Section 12 Resource Review Process." B. ARIN General Counsel "Counsel strongly supports some version of this policy being enacted and believes adoption of this policy will save significant future legal fees. This policy proposal spells out a series of customary and contractual policies and rights that are important to make as clear as possible. Counsel does not agree with that portion of the description which states ARIN "feels that current policy does not give them the power...." And believes such powers are adequately vested in ARIN' but believes instead such powers can always be more carefully delineated for ease of understanding." IV. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimal. Barring any unforeseen resource requirements, this policy could be implemented within 30 ? 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Depending on the impact to RSD this may require additional staff. It will require the following: Guidelines Changes Registration System Changes Staff training May increase RSD workload May increase turnaround times Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-14 Resource Review Process Author: Owen DeLong, Stephen Sprunk Proposal type: modify Policy term: permanent Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are necessary to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. at any other time without cause unless a prior review has been completed in the preceding 12 months. 3. ARIN shall communicate the results of the review to the organization. 4. If the review shows that existing usage is substantially not in compliance with current allocation and/or assignment policies, the organization shall return resources as needed to bring them substantially into compliance. If possible, only whole resources shall be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Rationale: ARIN feels that current policy does not give them the power to review or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to renumber out of any resources to be reclaimed. The nature of the "review" is to be of the same form as is currently done when an organization requests new resources, i.e. the documentation required and standards should be the same. The renumbering period does not affect any "hold" period that ARIN may apply after return or revocation of resources is complete. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From info at arin.net Mon Oct 22 11:23:21 2007 From: info at arin.net (Member Services) Date: Mon, 22 Oct 2007 11:23:21 -0400 Subject: Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: References: Message-ID: <471CC069.6040005@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this 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. 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/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv6 Assignment Size Reduction Author: Brian Dickson Proposal Version: 1 Submission Date: Oct 18, 2007 Proposal type: modify Policy term: permanent Policy statement: 6.5.4.1. Assignment address space size 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 /120 (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): * /120 for a very small customer with one subnet, using static assignments or DHCPv6 * /116 for a small customer with a few subnets, using static assignments or DHCPv6 * /112 for a medium size customer with a significant total number of hosts and/or subnets, using static assignments and/or DHCPv6 * /96 for large customers * /80 for very large customers, or for customers using a proposed modified version of V6-autoconf (which uses EUI-48 instead of EUI-64) * /72 for customers with several subnets using modified V6-autoconf (which uses EUI-48 instead of EUI-64) * /64 when it is known that one and only one subnet is needed, for a customer that absolutely requires either traditional IPv6 autoconfiguration, or IPv6 host Interface Identifier cryptographic generation * /60 for sites where a mix of IPv6-autoconfiguration and other address assignment techiques are required * /56 for very large sites * /52 for very, very large sites * /48 for extremely large 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. Rationale: The intent is to provide more current guidance, to both ARIN members, and to ARIN staff, based on available IPv6 technology, and for the encouragement of efficient assignment of IPv6 address space. IPv6 supports numerous methods for address assignments to end nodes. Those include autoconfiguration, static assignment, and DHCPv6. Of those, only autoconfiguration requires use of /64 as the prefix size. Efficient use of IPv6 space should discourage widespread use of /64's, or for use of autoconfiguration as the sole justification for allocations of large address space. In particular, the effective lifetime of PA assignments to ISPs/LIRs, is largely a factor of internal aggregation, and the size of end assignments. Rather than meeting ISP needs by assigning very large IPv6 PA blocks, it would be wiser to encourage assignments that to not significantly use up available PA space for the ISP, even for very large customers. The overall intent is to minimize the need for any PA recipient, to return to ARIN for subsequent assignments, thus reducing the need for additional globally routable prefixes using up slots in routers in the DFZ - something that affects the long-term ability for all ISPs to continue to scale in a cost-effective manner. Timetable for implementation: Immediate From info at arin.net Mon Oct 22 11:23:36 2007 From: info at arin.net (Member Services) Date: Mon, 22 Oct 2007 11:23:36 -0400 Subject: Policy Proposal: 200-reduction-6.5.1.1.d In-Reply-To: References: Message-ID: <471CC078.2060401@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this 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. 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/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: 200-reduction-6.5.1.1.d Author: Brian Dickson Proposal Version: 1 Submission Date: Oct 18, 2007 Proposal type: modify Policy term: permanent Policy statement: In 6.5.1.1 d), where 2007-25 proposes: "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." replace with" "be an existing, known ISP in the ARIN region or have a plan for making at least 20 end-site assignments to other organizations, or for providing IPv6 transit to one or more IPv6 PI blocks belonging to other organizations, within 5 years." Rationale: The purpose of the text is to establish reasonable ways for an ISP to demonstrate that it is in fact an ISP. Any of the above listed conditions satisfy that need, and the intent is to avoid having the text of the policy prevent any legitimate ISP from receiving an initial IPv6 allocation. It does lower the bar, but in a justifiable fashion. It is not necessary for an ISP to have lots of PA assignments. It is necessary for an ISP to be announcing PA *or* PI blocks to the internet, and relaxing the criteria to recognize both possibilities jointly, makes the policy reflect the actual realities for any number of large regional ISPs, who may have sold off portions of their business but who still operate significant infrastructure. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:36:37 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:36:37 -0400 Subject: Policy Proposal 2007-19: IANA Policy for Allocation of ASN Blocks to RIRs - Last Call Message-ID: <471E3125.7090601@arin.net> Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_19.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 November 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs Author: Axel Pawlik Proposal type: New Policy term: renewable Policy statement: Abstract This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs). This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO). 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2009, allocations of 2-byte only and 4-byte only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 2-byte only and 4-byte only ASNs, and will operate ASN allocations from an undifferentiated 4-byte ASN allocation pool. 2. Initial Allocations Each new RIR will be allocated a new ASN block. 3. Additional Allocations An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met: 1. The RIR has assigned/allocated 80% of the previously received ASN block, or 2. The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months. An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for. 4. Announcement of IANA Allocations The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. [1. http://www.ripe.net/ripe/policies/proposals/2005-12.html] Rationale: There are global policies governing the allocation of IPv4 and IPv6 blocks from the IANA to RIRs. At this point there is no specific policy regarding the allocation of Autonomous System Numbers from the IANA to the RIRs. This proposal will create a policy to fill this gap. The criteria being proposed has already been the practice between IANA and RIRs so far and it has been proven to work. It is designed to allow RIRs to request ASN blocks from the IANA in a timely fashion and maintain enough ASNs in holding to ensure that their registration services can be sustained. It is also proposed that the RIRs be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months. This will generally mean that each RIR will only need to make one ASN request from the IANA each year, thus lowering operational overhead for the RIRs. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:36:50 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:36:50 -0400 Subject: Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call Message-ID: <471E3132.7000808@arin.net> Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the amended proposal and moved it to last call. The policy text was amended from "a direct IPv4 assignment or allocation" to "all direct IPv4 assignments or allocations." The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_21.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 November 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use Author: Scott Leibrand Proposal type: new Policy term: permanent Policy statement: Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user organizations: Criteria), to read: To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of all direct IPv4 assignments or allocations covered by a current ARIN RSA. Rationale: Current policy allows direct IPv6 allocations and assignments to nearly all organizations with IPv4 allocations or assignments from ARIN. As a result, such organizations can get IPv6 space just as easily as they can get IPv4 space, making it easy for them to transition to IPv6 as soon as they're ready to do so. However, there are some organizations who received IPv4 /23's and /24's prior to the formation of ARIN, and use that space in a multihomed, provider-independent fashion. Under current policy, such organizations cannot get IPv6 PI space without artificially inflating host counts, and are therefore discouraged from adopting IPv6. This policy proposal aims to remove this disincentive, and allow such organizations to easily adopt IPv6. In addition, pre-ARIN assignments were issued through an informal process, and many legacy resource holders have not yet entered into a formal agreement with ARIN, the manager of many such IP numbering resources. This policy proposal would require that such assignments be brought under a current ARIN Registration Services Agreement, thereby formalizing the relationship. Some pre-ARIN assignments may not be used efficiently. As unallocated IPv4 numbering resources are approaching exhaustion, it is important to ensure efficient utilization of IPv4 assignments, and to arrange for reclamation of unused space. Therefore, this policy would require that the organization wishing to receive IPv6 PI space demonstrate efficient utilization of their IPv4 assignment. (Efficient utilization is already defined elsewhere in policy, and the exact mechanism for achieving and determining efficient use is a matter of procedure, not of policy, so detailed procedures are not included in the policy statement above. The intent is that any organization with an assignment of /23 or larger which is less than 50% utilized would renumber and return whole unused CIDR blocks as necessary to bring the remaining CIDR block to 50% utilization or higher. A /24 should be considered efficiently utilized as long as it is in use for multihoming, as /25's and smaller are not routable for that purpose.) It has been suggested that this policy would be useful only until the growth of IPv6 exceeds the growth of IPv4. I would agree with this, and would further posit that the existing "qualify ... under the IPv4 policy currently in effect" language should also be modified at that time. I have therefore proposed this policy with a policy term of "permanent", with the expectation that this section of policy (6.5.8.1) will be rewritten at the appropriate time to entirely remove all IPv4 dependencies. Timetable for implementation: immediate From info at arin.net Tue Oct 23 13:37:02 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:37:02 -0400 Subject: Policy Proposal 2007-22: Expand timeframe of Additional Requests - Last Call Message-ID: <471E313E.3070408@arin.net> Policy Proposal 2007-22 Expand timeframe of Additional Requests The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_22.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 November 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-22 Expand timeframe of Additional Requests Author: Dan Alexander Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:37:14 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:37:14 -0400 Subject: Policy Proposal 2007-25: IPv6 Policy Housekeeping - Last Call Message-ID: <471E314A.2010201@arin.net> Policy Proposal 2007-25 IPv6 Policy Housekeeping The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_25.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 November 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-25 IPv6 Policy Housekeeping Author: Leo Bicknell Proposal type: modify Policy term: permanent Policy statement: Change I: In section 6.5.1.1.d, replace the existing statement with the new statement: "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." Change J: Remove section 6.5.3 entirely. Update all subsequent sections to have new section numbers (6.5.[n-1]). Replace part of the text as (new) section 6.5.4.4: "All /56 and larger assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary." Change K: Section 6.5.8.2, add the following sentence to the end of the first paragraph: "An HD-Ratio of .94 must be met for all assignments larger than a /48." Add to the end of the second paragraph: "This reservation may be assigned to other organizations later, at ARIN's discretion." Change L: Section 6.5.8.3, add a sentence between the two existing sentences: "Justification will be determined based on the .94 HD-Ratio metric." Rationale: When the IPv6 policy was passed, it was considered to be an "interim" policy, and it was intended to be similar in all 5 RIR's. Since that time it has become clear the policy is no longer interim (and proposal 2007-4 was passed to change just that) and it has also been modified separately in the different RIR's. It was brought to the ARIN AC's attention that there were a number of problems with "Section 6" of the NRPM as a result of this legacy: * The policy contained a large number of items that were not policy. * The policy contained a few items that were self contradictory. * The added text was redundant in some cases with existing text. * The policy was overly vague in a few areas, leaving ARIN staff to have to make interpretations of what the policy intended. * Policy changes made since the initial IPv6 policy was adopted have not always updated all of the relevant sections due to the complexity of section 6. The intent of these changes is not to change any existing policy, but rather to remove all non-policy items, and update any ambiguous items with the way that ARIN staff is currently interprets the policy. Change I: Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 allocations, but section 6.5.1.1.d was never updated to match the change. It is believed the intent of the policy, and ARIN staff's current interpretation of the policy match the updated text. Change J: The first part is not policy, and incorrectly states there is no policy as section 6.5.4 has the policy in it. Take the one useful part and make it part of the 6.5.4 criteria. Change K: No metric is currently listed to justify a larger initial assignment. It is believed ARIN staff is currently applying the HD-Ratio similar to the ISP policy, this puts that in writing. Make it clear that the reservation may not exist in perpetuity. Change L: No metric is given to justify additional assignments. It is believed that ARIN staff is currently applying the HD_Ratio similar to the ISP policy, this puts that in writing. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:37:27 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:37:27 -0400 Subject: Policy Proposal 2007-16: IPv4 Soft Landing - Revise Message-ID: <471E3157.2090806@arin.net> Policy Proposal 2007-16 IPv4 Soft Landing The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_16.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-16 IPv4 Soft Landing Author: David Conrad Proposal type: New Policy term: Permanent Policy statement: This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of: --- begin modification --- 4.2.4.1 In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation "phases" that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent. When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses. IPv4 Allocation Phases The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section. Phase: 0 Threshold: Greater than 40 /8s Requirements: Requesters must: * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization Phase: 1 Threshold: 40 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. Phase: 2 Threshold: 25 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. * Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate. * Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request. Phase: 3 Threshold: 10 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization * Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing. * Demonstrate availability of production IPv6 infrastructure and connectivity services. Notes: * Phase 0 reflects current allocation requirements. * Phases 1 through 3 are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. * If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space at the time of the request. --- end modification --- Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses for requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the documentation or reuse of public IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify conformance to the specified requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby offering an opportunity to break the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when the RIR's current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a "reasonable" amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. From info at arin.net Tue Oct 23 13:37:39 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:37:39 -0400 Subject: Policy Proposal 2007-23: End Policy for IANA IPv4 allocations to RIRs - Revise Message-ID: <471E3163.3060502@arin.net> Policy Proposal 2007-23 End Policy for IANA IPv4 allocations to RIRs The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_23.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-23 End Policy for IANA IPv4 allocations to RIRs Author: JPNIC IPv4 countdown policy team; Akinori MAEMURA, Akira NAKAGAWA, Izumi OKUTANI, Kosuke ITO, Kuniaki KONDO, Shuji NAKAMURA, Susumu SATO, Takashi ARANO, Tomohiro FUJISAKI, Tomoya YOSHIDA, Toshiyuki HOSAKA Proposal type: new Policy term:renewable Policy statement: 1) Distribute a single /8 to each RIR at the point when new IANA free pool hits 5 */8. This date is defined as "IANA Exhaustion Date". 2) It should be completely left up to each RIR communities to define a regional policy on how to distribute the remaining RIR free pool to LIRs within their respective regions after "IANA Exhaustion Date". Note 1: It is fine for an RIR to continue operations with the existing policy if that is the consensus decision of the respective RIR community. Note 2: Address recovery and re-distribution of recovered address space is another important measure for considerations, but should be treated as a separate policy proposal from distribution of new IANA pool. 3) RIRs should provide an official projection on IANA Exhaustion Date to the community through their website, at their Policy Meetings and through any other effective means. Rationale: [current problem] There are two major issues in terms of address management if no measures are taken for IPv4 address exhaustion. 1) Continue applying a global coordinated policy for distribution of the last piece(s) of RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. 2) LIRs and stakeholders remain unprepared for the situation if they are not informed If LIRs and the community are uninformed of the exhaustion, their services and networks remain unprepared to face the situation at the time of exhaustion. [Objective of the proposal] This proposal seeks to provide the following solutions to the problems listed above. 1) RIR community should be able to define their own regional policies on how to assign the last piece(s) of allocation block in order to address their own regional issues during the exhaustion period. 2) RIRs should provide official projection of the date when LIRs will be able to receive the allocations under the current criteria. The criteria should remain consistent until this date in order to avoid confusion. [Pros and Cons] Pros: + It allows each RIR community to define a policy on how to distribute the last piece(s) of allocations which best matches their situation. + It helps LIR better informed of the date when they are able to receive allocations from RIRs under the current criteria and prepare for the event. Cons: + Concerns could be raised about allocating a fixed size to all RIRs, that it artificially fastens the consumption rate of some RIR regions. However, its impact is kept to minimum by keeping the allocation size to a single /8 which makes merely 3-4 months difference. + Concerns could be raised that explicitly allowing regional policies will encourage RIR shopping. However, this should not happen if the requirements within each region is adequately reflected in each RIR's policy through PDP. RIR may also chose to add criteria to prevent LIRs from other regions submitting such requests. Timetable for implementation: Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy. From info at arin.net Tue Oct 23 13:37:51 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:37:51 -0400 Subject: Policy Proposal 2007-17: Legacy Outreach and Partial Reclamation - Revise Message-ID: <471E316F.7050206@arin.net> Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_17.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Proposal type: modify Policy term: permanent Policy statement: Modify section 4.6 as follows: 4.6 Amnesty Requests ARIN will accept the return or relinquishment of any address space from any existing address holder. If the address holder wishes to aggregate into a single block, ARIN may work with the address holder to arrive at an allocation or assignment which is equal to or smaller than the sum of their existing blocks and which best meets the needs of the existing holder and the community. There shall be no fee for returning addresses under this policy. Further, organizations returning addresses under this policy shall receive the following benefits: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. If the organization currently pays ARIN fees, their fees shall be waived for two years for each /20 equivalent returned, with any fractional /20 equivalent resulting in a one-time single year waiver. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that all of their IPv4 resources are henceforth subject to the RSA. Organizations taking this election shall be subject to end-user fees for their IPv4 resources not previously under an ARIN RSA. If they are already an ARIN subscriber, then IPv4 resources affected by this process may, instead, be added to their existing subscriber agreement at the address holder's discretion. Rationale: The current amnesty policy does a nice job of facilitating aggregation, which was the intent when it was drafted. However, as we approach IPv4 free-space exhaustion, the community now has an additional need to facilitate address reclamation. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process. Further, there is an unfortunate perception that doing so will require force the legacy holder into certain future disadvantages. This proposal attempts to resolve both of those issues while also providing some incentive to legacy organizations to start using IPv6 resources and bring their IPv4 resources into the ARIN process. This policy attempts to provide some benefit and remove most of the costs of making partial IPv4 returns. It also attempts to provide an incentive for these IPv4 holders to join the ARIN process. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:38:04 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:38:04 -0400 Subject: Policy Proposal 2007-14: Resource Review Process - Revise Message-ID: <471E317C.7090305@arin.net> Policy Proposal 2007-14 Resource Review Process The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_14.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-14 Resource Review Process Author: Owen DeLong, Stephen Sprunk Proposal type: modify Policy term: permanent Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are necessary to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. at any other time without cause unless a prior review has been completed in the preceding 12 months. 3. ARIN shall communicate the results of the review to the organization. 4. If the review shows that existing usage is substantially not in compliance with current allocation and/or assignment policies, the organization shall return resources as needed to bring them substantially into compliance. If possible, only whole resources shall be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. ARIN shall continue to maintain the resource(s) while their return or revocation is pending, except no new maintenance fees shall be assessed for the resource(s). 8. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Policy Rationale Rationale: ARIN feels that current policy does not give them the power to review or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to renumber out of any resources to be reclaimed. The nature of the "review" is to be of the same form as is currently done when an organization requests new resources, i.e. the documentation required and standards should be the same. The renumbering period does not affect any "hold" period that ARIN may apply after return or revocation of resources is complete. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:38:15 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:38:15 -0400 Subject: Policy Proposal 2007-18: Global Policy for the Allocation of the Remaining IPv4 Address Space - Abandoned Message-ID: <471E3187.6070409@arin.net> Policy Proposal 2007-18 Global Policy for the Allocation of the Remaining IPv4 Address Space The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has decided to abandon 2007-18 in favour of working with all the authors of both 2007-18 and 2007-23 to craft a cohesive policy proposal around 2007-23. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html In order for this proposal to be further considered, the author may use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 30 October 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_18.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-18 Global Policy for the Allocation of the Remaining IPv4 Address Space Author: Roque Gagliano Co-authors: Francisco Obispo, Hytham EL Nakhal, Didier Allain Kla Proposal type: new Policy term: permanent Policy statement: This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. In order to fulfill the requirements of this policy, at the time it is adopted, an identical number of IPv4 allocation units (N units) will be reserved by IANA for each RIR. The number N is defined as: 5. The reserved allocation units will no longer be part of the available space at the IANA pool. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases: 1. Existing Policy Phase: During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA cannot be fulfilled with the remaining IPv4 space available at the IANA pool. This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process will be initiated. 2. Exhaustion Phase: IANA will automatically allocate the reserved IPv4 allocation units to each RIR (N units to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units). 2.1. Size of the final IPv4 allocations: During this phase IANA will automatically allocate N allocation units to each RIR from the reserved space defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses. 2.2. Allocation of the remaining IPv4 Address space: After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST: A) Immediately notify the NRO about the activation of the second phase of this policy. B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space. C) Proceed to allocate N allocation units to each RIR from the reserved space. Rationale: The IANA pool of allocation units of IPv4 addresses (/8s) is decreasing rapidly. A new policy is proposed to replace the current "on demand" policy in order to bring certainty on how the remaining space will be allocated. This policy eliminates the pressure on the remaining central pool of addresses by allocating equal amount of allocation units (N) to each RIR. RIR may be studying slow-landing policies or the possibility to reserve specific address spaces for "critical infrastructure" or new companies in order to comply with anti-trust regulations in its region. This policy allows each RIR to adopt those policies through its PDP, which is simpler than a global policy discussion process. Each RIR will have the exact information on the amount of address spaces that they will be receiving as a last allocation from the IANA. The policy is written in such a way that the discussion could be split in two sections: first do we agree on the concept of the policy and second what is the appropriate value for the last allocation units N. Timetable for implementation: This is a Global policy that needs to be approved by all RIRs and then ratified by ASO/ICANN. It has already reached consensus at LACNIC meeting. From info at arin.net Tue Oct 23 13:38:27 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:38:27 -0400 Subject: Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - Abandoned Message-ID: <471E3193.2060700@arin.net> Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is not community consensus in favor of the proposal and abandoned it. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html In order for this proposal to be further considered, the author may use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 30 October 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2006-7.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM Policy term: permanent Policy statement: New organizations need a policy that allows them to apply for IPv6 address space. To provide this we need to insert a new additional line item to 6.5.1.1. The new line item would be line 'e' as follows: e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Rationale: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. - Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. - An ISP or LIR may decide to assign a different prefix size than /48. For example, a cellular operator may use /64. - ASN is not required because as long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. - Organization in this is defined as a Corporation, ISP, LLC et al. In SUMMARY if this policy is implemented the change to the NRPM would read as follows: 6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPV6 address space, an organization must: a. be a LIR; b. not be an end site; c. plan to provide IPV6 connectivity to which it will assign IPV6 address space, by advertising that connectivity through its single aggregated address allocation; d. be an existing, known ISP in the ARIN region or have a plan for making at least 200/48 assignments to other organizations within five years. e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:38:59 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:38:59 -0400 Subject: Policy Proposal 2007-15: Authentication of Legacy Resources - Withdrawn Message-ID: <471E31B3.1080309@arin.net> Policy Proposal 2007-15 Authentication of Legacy Resources 2007-15 was withdrawn by the author. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_15.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-15 Authentication of Legacy Resources Author: Andrew Dul Proposal type: New Policy term: Permanent Policy statement: Add new NRPM section 4.9 - Legacy Records 4.9 - Legacy Records Legacy resource record holders shall be permitted to sign a registration services agreement which permits the legacy organization which is currently using the resources as of January 1, 2007 to continue to use those resources as long as a valid registration services agreement is in effect for the organization. ARIN will evaluate and verify the chain of custody of any resource records prior to executing a registration services agreement with an organization. ARIN shall use all reasonable methods to attempt to contact legacy record holders starting on January 1, 2008 to notify them of this change in policy. ARIN shall also post information on the public website regarding this outreach to legacy resource holders. No changes shall be made to legacy resource records which are not covered by a registration services agreement after December 31, 2007. If a legacy resource holder requests additional IPv4 resources all IPv4 resources (legacy and non-legacy) shall be evaluated to determine utilization for additional allocations or assignments under NRPM sections 4.2 or 4.3. Rationale: An ARIN Legacy resource holder is an organization which was issued number resources prior to the formation of ARIN and whose registration information was not transferred to another RIR through the Early Registration Transfer Project (http://www.arin.net/registration/erx). Legacy resource holders were issued number resources through an informal process. This policy proposal attempts to bring these legacy resource holders into a formal agreement with ARIN, the manager of the IP numbering resources for many of the legacy record holders. This policy is similar to a policy which has been adopted in the APNIC region. (http://www.apnic.net/docs/policy/proposals/prop-018-v001.html) Some legacy resource holders have expressed concerns about committing to a registration service agreement (RSA) when the legacy resource holder cannot be assured that they will be permitted to retain their resources for the long-term. This policy proposal requests ARIN to develop a RSA which will allow legacy resource holders to continue to use IPv4 resources which were assigned or allocated prior to ARIN's formation. It is also suggested that the Board of Trustees formalize the annual maintenance fees for legacy resource holders at a level similar to the $100 USD per year for end-sites or provide fee-waivers as an incentive for legacy holders to sign a registration services agreement. The dates in this policy proposal were arbitrarily chosen based upon an expected ratification by the ARIN Board of Trustees by December 31, 2007. If this policy is implemented after December 31, 2007, the trigger dates in the policy should be adjusted appropriately. Given the informal relationship under which the resources were granted, ARIN currently maintains the records including WHOIS and in-addr.arpa delegations in a best-effort fashion. Some believe that ARIN may not be obligated to maintain these records. ARIN has also experienced some difficulty maintaining these records. Legacy records have been a popular target for hijackers, in part due to the out of date information contained in these records. Having up to date contact information and a formal relationship with legacy record holders would assist ARIN and ISP's in insuring these records are maintained accurately. Legacy resource holders who sign a RSA would continue to receive all the services that are currently provided by ARIN plus they would be eligible for any future services that ARIN may offer, such as cryptographic signing of resource records. Timetable for implementation: As stated in policy From info at arin.net Tue Oct 23 13:39:11 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:39:11 -0400 Subject: Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User - Withdrawn Message-ID: <471E31BF.8030001@arin.net> Policy Proposal 2007-13 Removal of ISP Immediate Need from End-User 2007-13 was withdrawn by the author. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_13.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-13 Removal of ISP Immediate Need from End-User Author: Rob Seastrom, David Williamson, Owen DeLong Proposal type: delete Policy term: permanent Policy statement: Delete section 4.3.4, which reads: 4.3.4. Additional considerations End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4]. from the NRPM. Rationale: As discussed at ARIN XIX, section 4.3.4 creates a conflict with section 4.2.1.6 in that section 4.2.1.6 specifically excludes end users while section 4.3.4 is specifically for end users. Prior to the development of the multihoming policy for end users, the immediate need policy was required in order to support end users being able to get address space under some circumstances. The "immediate need" title is a misnomer as it is more an issue of "initial need without prior address utilization" than "immediate need". Such initial needs for end users are now addressed best through the multihoming policy. Timetable for implementation: immediate From info at arin.net Tue Oct 23 13:39:24 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:39:24 -0400 Subject: Policy Proposal 2007-24: IPv6 Assignment Guidelines - Revise Message-ID: <471E31CC.1090501@arin.net> Proposal 2007-24 IPv6 Assignment Guidelines The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_24.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Proposal 2007-24 IPv6 Assignment Guidelines Author: Leo Bicknell and Ed Lewis Proposal type: new Policy term: permanent Policy statement: Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 with the following text: Assignments by LIRs /48 or smaller will not be reviewed by ARIN. Assignments greater than /48 will be reviewed to see if the additional space is warranted according to the 0.94 HD ratio policy. If the space is not warranted, ARIN will consider the excess space to be available for a different assignment, lowering the overall utilization score of the LIR. Rationale: The existing section 6.5.4.1 does not provide clear guidance on how ARIN should treat prefixes allocated to a site should an ISP come back for additional space in the future. This makes it difficult for LIR's to know if they are allocating in accordance with the rules under which they will be judged in the future. The existing section also provides no guidence on what the LIR or ARIN should do in the case a larger prefix is necessary. Timetable for implementation: immediate From info at arin.net Tue Oct 23 14:21:42 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 14:21:42 -0400 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call In-Reply-To: <471E3132.7000808@arin.net> References: <471E3132.7000808@arin.net> Message-ID: <471E3BB6.5020805@arin.net> > The policy text was amended from "a direct IPv4 > assignment or allocation" > to "all direct IPv4 assignments or allocations." Correction. Amended to "all direct IPv4 assignments and allocations." Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > Policy Proposal 2007-21 > PIv6 for legacy holders with RSA and efficient use > > The ARIN Advisory Council (AC), acting under the provisions of the ARIN > Internet Resource Policy Evaluation Process (IRPEP), determined that > there is community consensus in favor of the amended proposal and moved > it to last call. The policy text was amended from "a direct IPv4 > assignment or allocation" to "all direct IPv4 assignments or > allocations." The AC made this determination at their meeting at the > conclusion of the ARIN Public Policy meeting on 18 October 2007. The > Chair of the AC reported the results of the AC meeting during the > Members Meeting. The AC Chair's report can be found at: > http://www.arin.net/meetings/minutes/ARIN_XX/mem.html > > The policy proposal text is provided below and is also available at: > http://www.arin.net/policy/proposals/2007_21.html > > Comments are encouraged. All comments should be provided to > ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 > November 2007. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 2007-21 > PIv6 for legacy holders with RSA and efficient use > > Author: Scott Leibrand > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user > organizations: Criteria), to read: > > To qualify for a direct assignment, an organization must: > > 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or > allocation from ARIN under the IPv4 policy currently in effect, or > demonstrate efficient utilization of all direct IPv4 assignments and > allocations covered by a current ARIN RSA. > > > Rationale: > > Current policy allows direct IPv6 allocations and assignments to nearly > all organizations with IPv4 allocations or assignments from ARIN. As a > result, such organizations can get IPv6 space just as easily as they can > get IPv4 space, making it easy for them to transition to IPv6 as soon as > they're ready to do so. However, there are some organizations who > received IPv4 /23's and /24's prior to the formation of ARIN, and use > that space in a multihomed, provider-independent fashion. Under current > policy, such organizations cannot get IPv6 PI space without artificially > inflating host counts, and are therefore discouraged from adopting IPv6. > This policy proposal aims to remove this disincentive, and allow such > organizations to easily adopt IPv6. > > In addition, pre-ARIN assignments were issued through an informal > process, and many legacy resource holders have not yet entered into a > formal agreement with ARIN, the manager of many such IP numbering > resources. This policy proposal would require that such assignments be > brought under a current ARIN Registration Services Agreement, thereby > formalizing the relationship. > > Some pre-ARIN assignments may not be used efficiently. As unallocated > IPv4 numbering resources are approaching exhaustion, it is important to > ensure efficient utilization of IPv4 assignments, and to arrange for > reclamation of unused space. Therefore, this policy would require that > the organization wishing to receive IPv6 PI space demonstrate efficient > utilization of their IPv4 assignment. (Efficient utilization is already > defined elsewhere in policy, and the exact mechanism for achieving and > determining efficient use is a matter of procedure, not of policy, so > detailed procedures are not included in the policy statement above. The > intent is that any organization with an assignment of /23 or larger > which is less than 50% utilized would renumber and return whole unused > CIDR blocks as necessary to bring the remaining CIDR block to 50% > utilization or higher. A /24 should be considered efficiently utilized > as long as it is in use for multihoming, as /25's and smaller are not > routable for that purpose.) > > It has been suggested that this policy would be useful only until the > growth of IPv6 exceeds the growth of IPv4. I would agree with this, and > would further posit that the existing "qualify ... under the IPv4 policy > currently in effect" language should also be modified at that time. I > have therefore proposed this policy with a policy term of "permanent", > with the expectation that this section of policy (6.5.8.1) will be > rewritten at the appropriate time to entirely remove all IPv4 dependencies. > > Timetable for implementation: immediate > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From info at arin.net Mon Oct 29 16:47:05 2007 From: info at arin.net (Member Services) Date: Mon, 29 Oct 2007 16:47:05 -0400 Subject: Policy Proposal: globally-coordinated-RIR-pie-IPv4 Message-ID: <472646C9.3000207@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this 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. 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/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: globally-coordinated-RIR-pie-IPv4 Author: Brian Dickson Proposal Version: 1 Submission Date: 26 October 2007 Proposal type: new Policy term: renewable Policy statement: This policy concerns the globally-coordinated allocations of IPv4 address space from IANA to the RIRs. The policy is intended to be compatible with 2007-23 (in its expected final form). The overview of the policy is: At the last reasonable time to do so, divide up the remaining IPv4 space based on currently projected use between that time and the date at which no more IPv4 space is available at any RIR for new allocations. Here is how the policy is to be implemented: 1) RIRs should provide up-to-date assignment projections for their respective regions, and provide up-to-date utilization on their current IANA-assigned block(s) from which assignments are made. 2) RIRs should provide an official projection on IANA Exhaustion Date (IED) to the community through their website, at their Policy Meetings and through any other effective means. 3) When any RIR requests a /8 from IANA, the current assignment projections for that RIR should be combined with the RIR's currently available IANA blocks (i.e. from which RIR assignments are made). This should be compared with the global available IANA unused space (for allocating to RIRs), the current projected usage rate of the RIR, and the current projected IED. If the RIR projection shows that the RIR would not expect to use up two /8 blocks before IED, the "Pie-splitting" event will be triggered. 4) Splitting the Pie - the following method will be used to determine the final IPv4 global IANA allocations to the RIRs: For each RIR, the following calculation will be done: (i) Determine from the current projection, the total allocations the RIR will make from present to IED (ii) Subtract from this, unallocated RIR space already received from ARIN (if any) (iii) Round the result to the nearest /12 (iv) Subtract from this amount, one /8 (to be set aside to satisfy the 2005-23 policy proposal for "End Policy for IANA IPv4 allocations to RIRs") (v) Allocate this amount to the RIR immediately. Every effort should be made to divide these allocations among RIRs in as aggregatable a fashion as possible. 5) The allocations made will result in just 5 * /8 being left in the IANA pool, which will trigger 2007-23. 6) This in turn, will result in the last 5 * /8's being allocate to the RIR's, one for each. Rationale: The objective of this policy is to ensure that the remaining IPv4 pool is distributed so as to provide each RIR with a quantity of IPv4 addresses that will last for an expected duration. The intent is for this duration to be as close to the same for each RIR as possible. By following the rules above, the "pie split" is done: - as late as possible - as fairly as possible - in a consistent manner for all RIRs - early enough that each RIR is guaranteed at least one /8 The final /8 allocations are done *after* this allocation, so that there can be no issue of fairness, with each RIR being guaranteed to get one of the final /8's at the same time. The "pie split" is timed so that no RIR will have so much (relative) IPv4 address space, as to expect to have IPv4 space after any other RIR has exhausted its own IPv4 space. By providing a "pie split" which is based on the same data as the IED projection, the following results occur: - there is no contention over the process by which the division of resources occur - all RIRs have the ability to project, well in advance of the "pie split", exactly when their own IPv4 space will be exhausted. It will happen at the IED date -- no sooner, no later. - No RIR "shopping" is likely to occur. Consequently, no inter-RIR "land grab" is likely to occur, and thus the projections for IED itself are likely to remain consistent, as will the per-RIR projections. - LIRs are likely to view the policy as neutral, and thus fair. - Because it removes the incentive for RIR shopping, the rules preventing RIR shopping will become largely moot (but still recommended). The perception then of anti-shopping provisions might then be that it maintains stability, rather than penalizing any RIR/LIR/region. Additional Observations about Fast vs Slow RIRs Fast-consuming RIRs will contribute more heavily towards the consumption rate. In turn, these RIRs will be the largest component of the projections of IED. Low-consuming RIRs will have less impact on IED. However, the low rate means that these RIRs will have *greater* proportional accuracy when it comes to knowing how much space they need between present time and IED. (This is because, the uncertainty on allocation needs, will be the result of multiplying the uncertainty on IED date, by the rate of consumption. Low-consuming LIRs, will have less uncertainty on their penultimate allocation.) The uncertainty on exact date of IED, is expected to be largely invariant across RIRs. Any changes to individual RIR allocation trends, after the "pie split" date, are not expected to exceed the individual RIR's own uncertainty at "pie split" date. In other words, the accuracy of each RIR's IED is expected to increase over time, and to continue to fall within the range of the original upper and lower limits (based on rounding to /12) of the RIR's allocation from IANA. Timetable for implementation: immediate From info at arin.net Tue Oct 30 17:08:30 2007 From: info at arin.net (Member Services) Date: Tue, 30 Oct 2007 17:08:30 -0400 Subject: ARIN XX Meeting Report Now Available Message-ID: <001301c81b39$06013f50$528888c0@arin.net> >From 17-19 October, the ARIN community took part in the ARIN XX Public Policy and Members Meeting, held in Albuquerque, New Mexico. The report of that meeting, which includes presentations, summary notes, and transcripts of the entire meeting, is now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XX/ The URL referenced above also provides links to presentations for the Sunday IPv6 activities held jointly with NANOG 41. Please check back later this week when an archive of the meeting's webcast will be made available. ARIN would also like to extend congratulations to Rich Schultz and Elise Gerich, winners of the ARIN XX Meeting Survey Raffle! Their names were randomly selected from the ARIN XX meeting survey entries. Rich will receive an iPod nano with video and Elise will receive a D-Link 4-Port Broadband VPN Router, which was provided by Shaw Communications. We thank everyone in the community who participated in person or remotely at the meeting and those who responded to the survey.=20 Please remember to mark you calendars and plan on joining us for ARIN XXI in Denver, Colorado, 6-9 April 2008. Regards, Member Services American Registry for Internet Numbers (ARIN)